You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2005/11/14 01:08:32 UTC
making behaviour of ide plugins consistent
Hi,
Can we discuss how to make the ide plugins behave consistently? It
appears that, in particular, there are a lot of discussions about
Eclipse and direct project references, and as I'm not a user I don't
really follow them - but I'm concerned that they might be arriving at a
different solution to what is already in place for the idea plugin.
So, could folks provide feedback on this strategy, and if there are any
other places that might differ (eg source/javadoc binding), please
comment on that.
For project references: the idea plugin uses a reference if and only if
the project exists in the reactor - ie, you run it from the root and it
creates all the files and the single project file. If run from a
subdirectory later, it will not create a link, but use the JAR from the
repository.
I think I'd want to enhance that to use a reference if it is found in
the USD/workspace - but that's not there just yet as there isn't an API
for the USD, it's only used in finding parent POMs.
Thoughts?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Milos Kleint <mk...@gmail.com>.
btw the same project interdependecies resolution is done in mevenide for
netbeans (both for m1 and m2)
since that one is an IDE plugin, not maven plugin, it allows to dynamically
change the jar/project linking on project open/close.
for example if I work on mevenide, then maven dependencies are only
referenced as jars in the repo, but once I open the maven-artifact, then the
dependency in other projects is changed to point to the project rather then
the jar. Assuming the versions in dependency and project match.
projects with modules allow to open multiple projects at once, eg opening
the whole maven codebase.
Milos
On 11/14/05, Kaare Nilsen <ka...@gmail.com> wrote:
>
> Ok.. after some thought I need to reevaluate my opinion on this.
> I have now played a little with the eclipse plugin, and well.. i must
> admit that i like the way it behaves. So using project references for
> projects in the same reactor build where the version of the project in
> the reactor, and the version of the dependency seems like a good
> default behaviour to me.
>
>
>
> On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> > My mistake
> > You are right Mark. So it seems like the eclipse plugin does it alot
> > like what Brett are describing.. But again.. this is to automagically
> > for me ;)
> >
> >
> >
> > On 14/11/05, Mark Hobson <ma...@gmail.com> wrote:
> > > The eclipse plugin *does* create different project files depending on
> > > where it's run. It uses project references if the other projects are
> > > within the reactor build. It's also very particular regarding
> > > versions, as this thread details:
> > >
> > >
> http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272
> > >
> > > I agree we need to be consistent across IDEs and would like things to
> > > be simplified and configurable.
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > > On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> > > > Well, no..
> > > > I think that what you are describing is somewhat to magical for me
> ;)
> > > > You say that the idea plugin creates different projects depending on
> > > > where you run the command, i personally finds that very confusing.
> In
> > > > my opinion a plugin after configured in the module pom (or a parent)
> > > > should behave consistently, and create equivalent projects on every
> > > > run, not depending on where the command is executed.
> > > >
> > > > The eclipse plugin creates project references if they share the same
> > > > parent pom (i have seen there are ppl out there struggeling with
> that,
> > > > but in my experience it works) no matter if you run the plugin from
> > > > the root or in a subdirectory.
> > > > Personally i find this to be a more consise solution.
> > > >
> > > > hehe, i litteraly can se my self trying to explain it to a coworker.
> > > > "Oh.. yeah.. by the way. please do remember to check where your run
> > > > your project generation. The result may vary", and then i can
> imagine
> > > > the look of confusion i would get back ;)
> > > >
> > > > So If an IDE project is generated for a module in a multimodule
> > > > project, it should always by default use project references.
> > > >
> > > > But then again. perhaps the notion of project generation strategy
> > > > would be a cool common setting.
> > > > like this (using one of the values inside[] )
> > > > ...
> > > > <configuration>
> > > > <projectReferenceStrategy>
> > > > [direct,directIfSameVersion,repsitory,snapshot-repository]
> > > > </projectReferenceStrategy>
> > > > ...
> > > >
> > > >
> > > >
> > > > On 14/11/05, Brett Porter <br...@apache.org> wrote:
> > > > > Yes, I definitely agree with that. This discussion should be about
> the
> > > > > default, but be configurable.
> > > > >
> > > > > So, you say the eclipse plugin does well - is it the same or
> different
> > > > > to the idea plugin as I described it?
> > > > >
> > > > > - Brett
> > > > >
> > > > > Kaare Nilsen wrote:
> > > > > > Then supply good default behaviour (where i really do think the
> > > > > > current eclipseplugin does a good job). And finally let the
> users
> > > > > > choose how they want to use it.
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: making behaviour of ide plugins consistent
Posted by Kaare Nilsen <ka...@gmail.com>.
Ok.. after some thought I need to reevaluate my opinion on this.
I have now played a little with the eclipse plugin, and well.. i must
admit that i like the way it behaves. So using project references for
projects in the same reactor build where the version of the project in
the reactor, and the version of the dependency seems like a good
default behaviour to me.
On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> My mistake
> You are right Mark. So it seems like the eclipse plugin does it alot
> like what Brett are describing.. But again.. this is to automagically
> for me ;)
>
>
>
> On 14/11/05, Mark Hobson <ma...@gmail.com> wrote:
> > The eclipse plugin *does* create different project files depending on
> > where it's run. It uses project references if the other projects are
> > within the reactor build. It's also very particular regarding
> > versions, as this thread details:
> >
> > http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272
> >
> > I agree we need to be consistent across IDEs and would like things to
> > be simplified and configurable.
> >
> > Cheers,
> >
> > Mark
> >
> > On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> > > Well, no..
> > > I think that what you are describing is somewhat to magical for me ;)
> > > You say that the idea plugin creates different projects depending on
> > > where you run the command, i personally finds that very confusing. In
> > > my opinion a plugin after configured in the module pom (or a parent)
> > > should behave consistently, and create equivalent projects on every
> > > run, not depending on where the command is executed.
> > >
> > > The eclipse plugin creates project references if they share the same
> > > parent pom (i have seen there are ppl out there struggeling with that,
> > > but in my experience it works) no matter if you run the plugin from
> > > the root or in a subdirectory.
> > > Personally i find this to be a more consise solution.
> > >
> > > hehe, i litteraly can se my self trying to explain it to a coworker.
> > > "Oh.. yeah.. by the way. please do remember to check where your run
> > > your project generation. The result may vary", and then i can imagine
> > > the look of confusion i would get back ;)
> > >
> > > So If an IDE project is generated for a module in a multimodule
> > > project, it should always by default use project references.
> > >
> > > But then again. perhaps the notion of project generation strategy
> > > would be a cool common setting.
> > > like this (using one of the values inside[] )
> > > ...
> > > <configuration>
> > > <projectReferenceStrategy>
> > > [direct,directIfSameVersion,repsitory,snapshot-repository]
> > > </projectReferenceStrategy>
> > > ...
> > >
> > >
> > >
> > > On 14/11/05, Brett Porter <br...@apache.org> wrote:
> > > > Yes, I definitely agree with that. This discussion should be about the
> > > > default, but be configurable.
> > > >
> > > > So, you say the eclipse plugin does well - is it the same or different
> > > > to the idea plugin as I described it?
> > > >
> > > > - Brett
> > > >
> > > > Kaare Nilsen wrote:
> > > > > Then supply good default behaviour (where i really do think the
> > > > > current eclipseplugin does a good job). And finally let the users
> > > > > choose how they want to use it.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Kaare Nilsen <ka...@gmail.com>.
My mistake
You are right Mark. So it seems like the eclipse plugin does it alot
like what Brett are describing.. But again.. this is to automagically
for me ;)
On 14/11/05, Mark Hobson <ma...@gmail.com> wrote:
> The eclipse plugin *does* create different project files depending on
> where it's run. It uses project references if the other projects are
> within the reactor build. It's also very particular regarding
> versions, as this thread details:
>
> http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272
>
> I agree we need to be consistent across IDEs and would like things to
> be simplified and configurable.
>
> Cheers,
>
> Mark
>
> On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> > Well, no..
> > I think that what you are describing is somewhat to magical for me ;)
> > You say that the idea plugin creates different projects depending on
> > where you run the command, i personally finds that very confusing. In
> > my opinion a plugin after configured in the module pom (or a parent)
> > should behave consistently, and create equivalent projects on every
> > run, not depending on where the command is executed.
> >
> > The eclipse plugin creates project references if they share the same
> > parent pom (i have seen there are ppl out there struggeling with that,
> > but in my experience it works) no matter if you run the plugin from
> > the root or in a subdirectory.
> > Personally i find this to be a more consise solution.
> >
> > hehe, i litteraly can se my self trying to explain it to a coworker.
> > "Oh.. yeah.. by the way. please do remember to check where your run
> > your project generation. The result may vary", and then i can imagine
> > the look of confusion i would get back ;)
> >
> > So If an IDE project is generated for a module in a multimodule
> > project, it should always by default use project references.
> >
> > But then again. perhaps the notion of project generation strategy
> > would be a cool common setting.
> > like this (using one of the values inside[] )
> > ...
> > <configuration>
> > <projectReferenceStrategy>
> > [direct,directIfSameVersion,repsitory,snapshot-repository]
> > </projectReferenceStrategy>
> > ...
> >
> >
> >
> > On 14/11/05, Brett Porter <br...@apache.org> wrote:
> > > Yes, I definitely agree with that. This discussion should be about the
> > > default, but be configurable.
> > >
> > > So, you say the eclipse plugin does well - is it the same or different
> > > to the idea plugin as I described it?
> > >
> > > - Brett
> > >
> > > Kaare Nilsen wrote:
> > > > Then supply good default behaviour (where i really do think the
> > > > current eclipseplugin does a good job). And finally let the users
> > > > choose how they want to use it.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Mark Hobson <ma...@gmail.com>.
The eclipse plugin *does* create different project files depending on
where it's run. It uses project references if the other projects are
within the reactor build. It's also very particular regarding
versions, as this thread details:
http://www.nabble.com/eclipse%3Aeclipse-and-direct-project-references-t488871.html#a1329272
I agree we need to be consistent across IDEs and would like things to
be simplified and configurable.
Cheers,
Mark
On 14/11/05, Kaare Nilsen <ka...@gmail.com> wrote:
> Well, no..
> I think that what you are describing is somewhat to magical for me ;)
> You say that the idea plugin creates different projects depending on
> where you run the command, i personally finds that very confusing. In
> my opinion a plugin after configured in the module pom (or a parent)
> should behave consistently, and create equivalent projects on every
> run, not depending on where the command is executed.
>
> The eclipse plugin creates project references if they share the same
> parent pom (i have seen there are ppl out there struggeling with that,
> but in my experience it works) no matter if you run the plugin from
> the root or in a subdirectory.
> Personally i find this to be a more consise solution.
>
> hehe, i litteraly can se my self trying to explain it to a coworker.
> "Oh.. yeah.. by the way. please do remember to check where your run
> your project generation. The result may vary", and then i can imagine
> the look of confusion i would get back ;)
>
> So If an IDE project is generated for a module in a multimodule
> project, it should always by default use project references.
>
> But then again. perhaps the notion of project generation strategy
> would be a cool common setting.
> like this (using one of the values inside[] )
> ...
> <configuration>
> <projectReferenceStrategy>
> [direct,directIfSameVersion,repsitory,snapshot-repository]
> </projectReferenceStrategy>
> ...
>
>
>
> On 14/11/05, Brett Porter <br...@apache.org> wrote:
> > Yes, I definitely agree with that. This discussion should be about the
> > default, but be configurable.
> >
> > So, you say the eclipse plugin does well - is it the same or different
> > to the idea plugin as I described it?
> >
> > - Brett
> >
> > Kaare Nilsen wrote:
> > > Then supply good default behaviour (where i really do think the
> > > current eclipseplugin does a good job). And finally let the users
> > > choose how they want to use it.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Kaare Nilsen <ka...@gmail.com>.
Well, no..
I think that what you are describing is somewhat to magical for me ;)
You say that the idea plugin creates different projects depending on
where you run the command, i personally finds that very confusing. In
my opinion a plugin after configured in the module pom (or a parent)
should behave consistently, and create equivalent projects on every
run, not depending on where the command is executed.
The eclipse plugin creates project references if they share the same
parent pom (i have seen there are ppl out there struggeling with that,
but in my experience it works) no matter if you run the plugin from
the root or in a subdirectory.
Personally i find this to be a more consise solution.
hehe, i litteraly can se my self trying to explain it to a coworker.
"Oh.. yeah.. by the way. please do remember to check where your run
your project generation. The result may vary", and then i can imagine
the look of confusion i would get back ;)
So If an IDE project is generated for a module in a multimodule
project, it should always by default use project references.
But then again. perhaps the notion of project generation strategy
would be a cool common setting.
like this (using one of the values inside[] )
...
<configuration>
<projectReferenceStrategy>
[direct,directIfSameVersion,repsitory,snapshot-repository]
</projectReferenceStrategy>
...
On 14/11/05, Brett Porter <br...@apache.org> wrote:
> Yes, I definitely agree with that. This discussion should be about the
> default, but be configurable.
>
> So, you say the eclipse plugin does well - is it the same or different
> to the idea plugin as I described it?
>
> - Brett
>
> Kaare Nilsen wrote:
> > Then supply good default behaviour (where i really do think the
> > current eclipseplugin does a good job). And finally let the users
> > choose how they want to use it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Brett Porter <br...@apache.org>.
Yes, I definitely agree with that. This discussion should be about the
default, but be configurable.
So, you say the eclipse plugin does well - is it the same or different
to the idea plugin as I described it?
- Brett
Kaare Nilsen wrote:
> Then supply good default behaviour (where i really do think the
> current eclipseplugin does a good job). And finally let the users
> choose how they want to use it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by Kaare Nilsen <ka...@gmail.com>.
In my opinion, giving the choise to the individual developer would be
the best solution.
When plugins tries to get "too smart" they often fail, and a lot of
discussions appear. It should not be the responsibility of the plugin
writer to tell people how they must manage their IDE's projects.
Rather the plugin writers should provide good default behaviour and
then allow the users of the plugin to change that behaviour if it does
not suit their needs.
Lets take a project i am in as an example:
We have currently 22 modules/projects in our reactor, and our
developers works on one or possible 2 or 3 concurrently.
Due to how the eclipse plugin currently works each developer needs to
have their workspace cluttered with 20 projects they are not working
on, and really don't care about. As the one respopnsible of
introducing maven to the team, I do come short of explaining to them
why they have to have all the projects open. And if some of you out
there could come up with the answer here, then honestly you are not
really listening to what they are saying.
And as i am sayning in the issue http://jira.codehaus.org/browse/MNG-955
Why do we really need to make this so difficult.
So to make a long story short. My opinion is:
Yes it would be a good idea to have the plugins behave consistenly,
they perhaps could share a configuration object that holds the common
settings.
Then supply good default behaviour (where i really do think the
current eclipseplugin does a good job). And finally let the users
choose how they want to use it.
On 14/11/05, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Can we discuss how to make the ide plugins behave consistently? It
> appears that, in particular, there are a lot of discussions about
> Eclipse and direct project references, and as I'm not a user I don't
> really follow them - but I'm concerned that they might be arriving at a
> different solution to what is already in place for the idea plugin.
>
> So, could folks provide feedback on this strategy, and if there are any
> other places that might differ (eg source/javadoc binding), please
> comment on that.
>
> For project references: the idea plugin uses a reference if and only if
> the project exists in the reactor - ie, you run it from the root and it
> creates all the files and the single project file. If run from a
> subdirectory later, it will not create a link, but use the JAR from the
> repository.
>
> I think I'd want to enhance that to use a reference if it is found in
> the USD/workspace - but that's not there just yet as there isn't an API
> for the USD, it's only used in finding parent POMs.
>
> Thoughts?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: making behaviour of ide plugins consistent
Posted by Vincent Massol <vm...@pivolis.com>.
+1 to all of this.
In addition, multiple projects simply do not work in Eclipse. There are too
many issues:
- you have to manually create root projects
- you can't see the SCM status of files in those root projects (you know the
beloved ">" or "*" marker that tells you that something has been modified.
- you can't check-in files in those root projects
- you can't easily share IDE configuration files and settings between those
projects (the .settings directory in Eclipse)
- you can't commit atomically or easily changes done on several subprojects.
If you try using the synchronization perspective then Eclipse will give an
error because it'll try to check changes for the root projects but they're
not SCM-enabled. In addition if you've made any changes there you'll forget
to commit them.
Basically the biggest issue is that you use multiple projects in Eclipse
you'll have to forget about using SCM features of the IDE.
I also like the idea of multiple projects. It's just that Eclipse doesn't
currently support them and I agree with John's points.
Thanks
-Vincent
> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> Sent: lundi 14 novembre 2005 18:09
> To: Maven Developers List
> Subject: Re: making behaviour of ide plugins consistent
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is going to sound completely ugly, but what I've found to work best
> when I have multiple interrelated (ie. same application) projects is to
> create one massive eclipse project with all the subprojects' source
> roots mapped as src dirs, all the resource roots mapped as class dirs,
> and all the dependencies added for all subprojects. Yes, when your
> subprojects depend on different versions of a single dependency, you may
> have problems. However, this should never be the case when a set of
> projects will always be used together - those version conflicts will
> have to be resolved at some point.
>
> The reason I prefer this approach is to preserve the call hierarchy
> within the application as a whole. If I have projects A and B, such that
> B -> A, then I can navigate to the implementation of a particular method
> from it's usage. This is true regardless of which approach is taken,
> provided either project references are intact, or source attachments are
> used. HOWEVER, if I have the method implementation in front of me, and
> need to open the call hierarchy to see where that method is called, I'm
> limited to the current project and its dependencies. If the dependency
> projects call this code, it's a Bad Thing, but that's tangential to the
> topic at hand. The point is I can't see where the client projects (the
> projects dependent on the one with the method implementation) call that
> particular method. It may seem trivial, but I use this feature of
> eclipse dozens of times a day when I'm code-reading (to learn a new API,
> for example).
>
> I know that most people won't like this approach, because it generates
> an 800# gorilla of a project, and can make it hard to navigate all the
> myriad source dirs. Still, it does have its uses, and I find this
> feature indispensible. It'd be a shame to have to let it go just so I
> can use Maven to generate my Eclipse project files...
>
> What about having multiple mojos, each implementing a different project
> file-generation strategy?? So, "normal" usage might be:
>
>
> mvn eclipse:eclipse -Declipse.workspace=/path/to/workspace
>
>
> My particular usage might be handled by:
>
>
> mvn eclipse:monolithic
>
>
> Beyond this, I think there's a lot of value in having a series of
> projects depend on the artifacts of their dependency projects. It tends
> to enforce cleaner separation of APIs, and keeps your IDE more lined up
> with your build environment...it also keeps the versions of your
> dependencies up to date.
>
> Just my 2c.
>
> - -john
>
> Brett Porter wrote:
> | Hi,
> |
> | Can we discuss how to make the ide plugins behave consistently? It
> | appears that, in particular, there are a lot of discussions about
> | Eclipse and direct project references, and as I'm not a user I don't
> | really follow them - but I'm concerned that they might be arriving at a
> | different solution to what is already in place for the idea plugin.
> |
> | So, could folks provide feedback on this strategy, and if there are any
> | other places that might differ (eg source/javadoc binding), please
> | comment on that.
> |
> | For project references: the idea plugin uses a reference if and only if
> | the project exists in the reactor - ie, you run it from the root and it
> | creates all the files and the single project file. If run from a
> | subdirectory later, it will not create a link, but use the JAR from the
> | repository.
> |
> | I think I'd want to enhance that to use a reference if it is found in
> | the USD/workspace - but that's not there just yet as there isn't an API
> | for the USD, it's only used in finding parent POMs.
> |
> | Thoughts?
> |
> | - Brett
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> | For additional commands, e-mail: dev-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDeMSPK3h2CZwO/4URAspDAJ9DxfrO4E5PR87wqKTtkbA7pL3h9ACfT+XG
> L0CThEcpSvUhiuW7ojyhvlI=
> =UoKu
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: making behaviour of ide plugins consistent
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is going to sound completely ugly, but what I've found to work best
when I have multiple interrelated (ie. same application) projects is to
create one massive eclipse project with all the subprojects' source
roots mapped as src dirs, all the resource roots mapped as class dirs,
and all the dependencies added for all subprojects. Yes, when your
subprojects depend on different versions of a single dependency, you may
have problems. However, this should never be the case when a set of
projects will always be used together - those version conflicts will
have to be resolved at some point.
The reason I prefer this approach is to preserve the call hierarchy
within the application as a whole. If I have projects A and B, such that
B -> A, then I can navigate to the implementation of a particular method
from it's usage. This is true regardless of which approach is taken,
provided either project references are intact, or source attachments are
used. HOWEVER, if I have the method implementation in front of me, and
need to open the call hierarchy to see where that method is called, I'm
limited to the current project and its dependencies. If the dependency
projects call this code, it's a Bad Thing, but that's tangential to the
topic at hand. The point is I can't see where the client projects (the
projects dependent on the one with the method implementation) call that
particular method. It may seem trivial, but I use this feature of
eclipse dozens of times a day when I'm code-reading (to learn a new API,
for example).
I know that most people won't like this approach, because it generates
an 800# gorilla of a project, and can make it hard to navigate all the
myriad source dirs. Still, it does have its uses, and I find this
feature indispensible. It'd be a shame to have to let it go just so I
can use Maven to generate my Eclipse project files...
What about having multiple mojos, each implementing a different project
file-generation strategy?? So, "normal" usage might be:
mvn eclipse:eclipse -Declipse.workspace=/path/to/workspace
My particular usage might be handled by:
mvn eclipse:monolithic
Beyond this, I think there's a lot of value in having a series of
projects depend on the artifacts of their dependency projects. It tends
to enforce cleaner separation of APIs, and keeps your IDE more lined up
with your build environment...it also keeps the versions of your
dependencies up to date.
Just my 2c.
- -john
Brett Porter wrote:
| Hi,
|
| Can we discuss how to make the ide plugins behave consistently? It
| appears that, in particular, there are a lot of discussions about
| Eclipse and direct project references, and as I'm not a user I don't
| really follow them - but I'm concerned that they might be arriving at a
| different solution to what is already in place for the idea plugin.
|
| So, could folks provide feedback on this strategy, and if there are any
| other places that might differ (eg source/javadoc binding), please
| comment on that.
|
| For project references: the idea plugin uses a reference if and only if
| the project exists in the reactor - ie, you run it from the root and it
| creates all the files and the single project file. If run from a
| subdirectory later, it will not create a link, but use the JAR from the
| repository.
|
| I think I'd want to enhance that to use a reference if it is found in
| the USD/workspace - but that's not there just yet as there isn't an API
| for the USD, it's only used in finding parent POMs.
|
| Thoughts?
|
| - Brett
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
| For additional commands, e-mail: dev-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDeMSPK3h2CZwO/4URAspDAJ9DxfrO4E5PR87wqKTtkbA7pL3h9ACfT+XG
L0CThEcpSvUhiuW7ojyhvlI=
=UoKu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org