On 13 Apr 07, at 5:10 AM 13 Apr 07, ArneD wrote:
Hi everybody,
from a corporate user's point of view, I believe, the following
points are
important:
1. Corporate users want to be completely decoupled from what's
happening on
repo1.
No they don't. In my experience they have wanted to shield all their
developers from central but generally still have someone who
maintains a connection to central. Whether they mirror its contents
inside their firewall, create internal repositories by running builds
and turning local repos into remote repos for their developers, or
using a proxy. All three are prevalent use cases.
That corporate users want something consistent and reliable is for
certain, but cutting off the network effect that Maven provides is
generally not desirable and defeats one of Maven's greatest virtues
in that new things are immediately available for use. That we have
bugs with the snapshot mechanism and not fully worked out patterns
for versioning of parent POM and plugins just comes with Maven not
being fully mature but don't throw the baby out with the bath water.
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.
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.
In contrast, if you download Ant, for example, you get all core ant
tasks. Yes, it it possible to download other tasks from elsewhere,
but what
you get out-of-the-box contains the most important things. The same
if you
download the Eclipse SDK. It is not just the Eclipse runtime but
instead a
bundle of the runtime and plugins. It is good to be able to use new
plugins
by just declaring them (as long as you have a connection to repo1),
but the
Maven core plugins should be usable out-of-the-box, without a
connection to
repo1.
I don't believe this is what most users want. I believe they would be
more interested in setting up a complete environment for their
developers and bundling is not very help here. Someone has to manage
how developers work behind a firewall and this person is generally
the one who populates an internal repository. Some tooling here would
be far more useful.
3. Many corporate users prefer to wait for stable releases instead
of using
beta versions. When using a stable Maven release, say 2.0.6, you
should get
latest stable (!) versions of Maven plugins. For example, you do
not want to
use maven-assembly-plugin 2.2-beta1 just because it has been
uploaded to
ibiblio. But: You want it out-of-the-box. The last thing that
newbies want
is to be forced to manually find out the latest version numbers and
declare
them.
This is why we are promoting the requirement of specifying versions
in addition to making it easy to find out those versions. Many users
want different versions and we can't accommodate every possibility
but putting this power in the users hands you can do whatever you like.
We had the notion of a plugin registry which was used locally by a
developer but not enforceable team wide. I think this is the feature
people are looking for. Some manifest that can be enforced and used
as a mixin so that we don't have to bake it into Maven yet something
we can provide. But we're always going to get a cross-section of
users who want one thing and not another which is why we generally
decide something and make everyone do it as the overall benefit to
the group is higher. If we baked in versions some would complain
loudly "I have no control over the versions of plugins", or if we
provided an override mechanism some would expect the manifest to win,
or the POM to be dominant.
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. Making a
static glob is not the solution.
To adress these issues, may I suggest the following:
- Build Maven distributions that include a super POM that declares the
latest stable(!) version of all core Maven plugins (i.e. the
plugins hosted
on maven.apache.org).
That's not ever going to be baked in.
- 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.
Jason.
Regards
- Arne
--
View this message in context: http://www.nabble.com/Remove-auto-
resolution-of-plugin-versions-from-Maven-2.1-
tf3560617s177.html#a9975501
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]
