RE: making behaviour of ide plugins consistent
+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
RE: making behaviour of ide plugins consistent
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]
Re: making behaviour of ide plugins consistent
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: making behaviour of ide plugins consistent
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
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 [EMAIL PROTECTED] 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making behaviour of ide plugins consistent
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
