Hi Eugene, I see three points why it should be possible to manage the buildpath and runtime classpath in the standard Eclipse UI (and it shouldn't be ignored). But first of all I have to say that if you decide to not allow this Eclipse feature, you should "disable" the UI. Else it is realy confusing and it took me some time to find out.
- From my point of few I can't see any imperatives to disable the feature. It was possible to handle the maven classpath container with additional classpath entries, why it should be forbidden? - Base on the first point, why to forbid something if it's not necessary to forbid it. And I don't like the idea that if you have an eclipse project with maven support then you have to manage any configuration using maven. As I understand maven so far, the idea is to help people doing things easier and not to force the people doing something. I get your point that you can do everything you have done in the Eclipse UI with maven, but I don't hold, that you have to do it with maven. - The last point is related to the practice. I joined a project and got the task to build up the build environment. Starting from dozens of Eclipse projects which only could be build and deployed in the Eclipse I had the idea to use maven to define the build definition. The Maven Eclipse Plugin is being used to have Eclipse building the projects based on the same build definition. That was my idea from a build managers view point. By contrast there are around 40 developers in the project and they are not realy interested in Maven and that it's used for integration and release builds and they don't have deep knowledge about Maven. They know Eclipse and how to work with this IDE. Therefore we doen't have absolutistic approach and use Maven for everything. As long a definition is not necessary for integration and release build we don't care if it's only defined in the IDE. A reason why we cannot say, we use Maven for everything is the lack of knowledge about Maven in the project. And because of a strict project plan we don't have the time to stop the project for let us say one or two weeks and make Maven education. We need a smooth approach with training on the job. And this is only possible if we can use Maven in collaboration with the techniques we already know. I realy hope it will be possible to manage the buildpath and runtime classpath in the standard Eclipse UI. An possible idea could be to disable it by default but it should be switchable by preferences. If you have any questions, don't hesitate to contact me. Regards, Thomas On Wed, Mar 19, 2008 at 8:42 PM, Eugene Kuleshov <[EMAIL PROTECTED]> wrote: > Thomas, > > Can you please elaborate on the use cases why you need to edit the > classpath outside of Maven? It would help us better to understand the > issues you having. > > On a good side, I just talked with JDT folks here at EclipseCon and > they have suggested few options that we might be able to use to improve > the situation, but like I said it would be great to better understand > your use cases. > > Thanks > > Eugene > > > > > Thomas Tardy wrote: > > Hello Eugene, > > > > thanks for your reply. I realy hope it will be possible to configure > > the classpath of launchers and applications as usual. I get your > > point, that if you use maven managed projects, you should define the > > classpath in maven. But I think you should allow exceptions. From my > > point of view it should be possible to edit this classpathes. > > > > Regards, > > Thomas > > > > On Wed, Mar 19, 2008 at 6:49 PM, Eugene Kuleshov <[EMAIL PROTECTED]> wrote: > > > >> Thomas Tardy wrote: > >> > >>> I updated from version 0.0.12 to 0.9.0 a few days ago and it looks to > >>> that everything is working well. Therefore I think that the issue > >>> described in the following is more a missunderstanding from my side > >>> than a bug. > >>> > >>> In eclipse you have the possibility to configure the classpath of a > >>> launcher and this was working well with m2eclipse v0.0.12. Since I > >>> updated the plugin to v0.9.0 the classpath of the launcher is always > >>> being restored to the default when I launch it. Can anybody tell me > >>> what I'm doing wrong respectively how to do the same thing with the > >>> v0.9.0. > >>> > >> Thomas, your observations are correct, and what happens is that we > >> always use corresponding Maven-managed classpath for JUnit and Java app > >> launch configurations (test and runtime scope accordingly). > >> > >> As you noticed, it is still possible to edit both buildpath and > >> runtime classpath using a standard Eclipse UI and it is confusing that > >> edited configuration is not being used. We haven't decided if we should > >> look if we can disable such editing in JDT UI if Maven dependency > >> management is enabled, or if we should use these changes at a price of > >> breaking command line Maven build. > >> > >> Anyways, in a mean time you can add additional dependencies to the > >> pom.xml using test and runtime scopes, so they will be used by launch > >> configurations. > >> > >> regards, > >> Eugene > >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
