+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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > | > | > | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFDeMSPK3h2CZwO/4URAspDAJ9DxfrO4E5PR87wqKTtkbA7pL3h9ACfT+XG > L0CThEcpSvUhiuW7ojyhvlI= > =UoKu > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
