On Thu, Mar 20, 2008 at 3:36 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 20-Mar-08, at 12:39 AM, Thomas Tardy wrote: > > > 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 en? > > > > If it is enabled then there is no parity between headless mode and > what happens in the UI and that simply is not a viable option. I see > little value for a Maven-based project to not add dependencies as is > normal in Maven. Additionally trying to manage both methods and > reconciling them is really pointless. The intersection that is really > important is making sure the classpath containers offered up by > different tools cooperate and we're working on that. > > What exactly is your usecase for the mixed model. It's theoretically > nice to talk about this but what is your reasoning for wanting this?
I get your point, but I think not everything what is executable in Eclipse has to be executable in a headless maven environment. > > > > - 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. > > > > That you simply don't like it is not a persuasive argument. Sure, but it's not the point that I don't like to manage the classpathes in maven. I don't like the idea that I have to. > > > > - 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. > > > > Ok, that's a better explanation. This is something we're definitely > trying to work out with users. But this argument is almost akin to > saying for WTP projects I don't want anyone to know about WTP. But we > are talking with people at EclipseCON about a couple options. One > would be to use AspectJ to intercept normal Eclipse actions and funnel > them into Maven. The other is simply having Maven just understand > different kinds of builds, say a project with just a manifest. So we > are working on those options but the Maven integration is just that, > for people who want to use Maven. Using Maven in headless mode, and > just completely hiding Maven in the IDE is not a place we've reached > yet but is a path we want to move toward. I have to agree on your points, but I don't like absolutistic approaches. In our project it isn't possible to use maven and every devoloper requires deep knowledge. An I think that's the consequence if the decision is to only allow configuring classpathes via maven. In our company (and it's not one of the smallest) we are fare away from saying that maven is known by every developer. This means, that it's the task of the project to teach the developers. And because it's not feasible to do this for 40 developers this would mean, that we have to stop using maven and go back to e.g. ant scripts. I realy hope that this will not be the case. Anyway, I realy have to thank Eugene and Jason for their great work! Thanks, Thomas > > > > > 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 > > > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more > examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > > > > > > > --------------------------------------------------------------------- > 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
