-----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]
