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?
- 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.
- 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 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
