Hi John, John Casey wrote on Monday, November 14, 2005 6:09 PM:
> -----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, this is ugly :) > 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. Depends on your setup. I use for the dependencies User Library definitions (which is not handled by the plugin also) to ensure version consistency. > 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. No, I just verified this. If the projects are dependent, the Call Hierarchy find calls also in other projects (unless *you* limit Call Hierarchy to search not in the complete workspace). > 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). The biggest problem is, that you do no longer really know, what dependencies you are using in which project. All artifacts are available in all projects and you can create circular references very easily. We had a major headache, when we made some JBuilder projects M1 compatible, just because JBuilder originally had all in one big project. > 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. ... exaclty :) As long as the monolithic project is not the default and forces unaware users to create such unwanted dependencies, I do not care. I just don't want to fix the poms for a whole team becuase the users do no longer care about their deps. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
