On 13 Apr 07, at 11:33 AM 13 Apr 07, ArneD wrote:
Jason,
thanks a lot for your answer.
I did not want to suggest that every Maven user should be forced to
work
decoupled from repo1. But currently it is much harder than it
should be, and
this should be improved.
I agree. We really need some simple tools and better documentation
here as there are many people who do have some simple strategies.
The most common one I know of is one person building everything and
then flipping the local repository that was populated and turn that
into the remote repository that the other developers use. You have to
account for the metadata and we have some tools for this but it's not
very easy to do. Some nice tools and IDE integration would make this
very easy to do. It should be seamless.
And I do agree that the separation of the Maven
core and the plugins has its benefits, and the default distribution
should
be without plugins.
But it should be easy for those who want to work independently of
central to
do it. Currently it is a pain.
Yes, it is and as a result we have people rsyncing the entire
repository even though they need only 5% of the contents.
Jason.
Jason van Zyl-2 wrote:
Many even don't want to proxy repo1 but instead manage their own
repository. This is especially true for build artifacts (but it is
also
desirable for Maven plugins which currently would be a pain).
2. Many users don't want to make a distinction between Maven itself
and the
Maven core plugins (compile, jar, ...).
This also not true in my experience. Core plugins are not distributed
with Maven because we have consciously decoupled the lifecycle of
plugins from the core because any plugins we house here may, in fact,
be release two or three times between major releases of Maven and
binding these versions in the core would be a bad idea.
Well, why not release Maven more often then? For those who need a
freshly
released plugin version urgently, there still could be an override
mechanism.
Eclipse.org makes coordinated releases of many sub-projects. The
sub-projects do have an independent lifecycle, but there are
coordinated
schedules when bundles are published. So each user knows: Every
June there's
a new major Eclipse release, and between these releases there's a
public
visible schedule when new Milestone releases are published.
From a user's point of perspective, this is easy to understand, as
you don't
*have to* track the versions of all sub-projects like the Platform,
EMF,
BIRT, ... You still *can* if you want. Users who want to stick to
stable
versions simply wait until the next major release (published once a
year in
the case of Eclipse).
Currently, when downloading the
Maven distribution, it is in a way uncomplete as even the core
plugins are
missing.
That is intentional and won't change as the default distribution, but
we certainly could provide another if necessary or better yet provide
decent tooling so that it's very simple to setup Maven + a given
manifest of tools you want for a development team.
+1. Both can be good options.
Again, ultimately what you want is what everyone wants. An easy way
to have an initial setup, yet configurable, and provide rock solid
consistent builds. And that's what we're trying to achieve.
Good!
Making a static glob is not the solution.
Okay, I see that you run into other problems when delivering the
plugin
versions within the Maven Super POM...
At the end of the day, what I mainly wanted to throw into the
discussion is:
- Maven should be usable almost out-of-the-box even for those users
that
want to be completely independent from central. Currently this is
far too
much pain. I agree to you, better tooling can be a good solution.
But to me,
this tooling seems to be far away...(?)
- Users (including but not limited to newbies) should be *able* to
see Maven
+ the main plugins as "The Maven build system", if they so want.
You should
not force *every* user to keep an eye on the versions of the core,
all the
plugins and so on. One solution could be to make coordinated
releases with a
publicly visible and reliable schedule like they do on eclipse.org.
- Provide a downloadable distribution that is completely
independent of
repo1, i.e. a distribution that contains all Maven core plugins (in
form of
a pre-filled local repository, for example) in the latest stable
version
That's entirely possible, and we could definitely do something like
that if was deemed something of value by users.
I think it would indeed be of great value to many users, as long as
tools
that make it really easy to package it together on your own aren't
available.
- Arne
--
View this message in context: http://www.nabble.com/Remove-auto-
resolution-of-plugin-versions-from-Maven-2.1-
tf3560617s177.html#a9981105
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
