On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<name>Test</name>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<pluginPacks>
<pluginPack>
<groupId>org.apache.maven.plugins.packs</groupId>
<artifactId>maven-java-plugin-pack</artifactId>
<version>1.0</version>
</pluginPack>
</pluginPacks>
</plugins>
</build>
</project>
You don't need that to start, the minimal POM is fine for someone
starting. For corporate build you have to lock everything down. You
can have no variability until someone decides it can change. That is
the only way to have something as stable as checking in all the JARs.
We don't need that plugin packs element. The vast majority of time in
maintaining a build is not the initial setup, it's the maintenance.
No one I have been with, sitting on a production build, is adverse to
locking down the versions in a parent POM.
If we can do that with mixins, that's great.
I definitely don't think we can require people to paste things in
if it becomes a core requirement, though - the "smallest POM
example" gets another 30 lines. That's almost 3 times the size of
above, and 5 times the original. Remember, we already get
complaints that the POM is too verbose - let's listen to those
users on this one :)
Do you think anyone thinks this is a burden if it guarantees them
stability? They don't, and tooling would make it dead simple. Sit
with the users, with their builds and it's not a burden. You are
removing their ability to mix and match their versions with one
element that gives them no visibility.
Another issue what would need to be addressed is the archetypes -
do we need to re-release the quickstart archetype all the time,
does it stick to an old version, or does it start substituting in
version values itself?
For anyone starting new they can get whatever version is the latest,
for anyone in a corporate environment it would again be locked down.
People experimenting for the first time can do whatever they want. It
doesn't affect a team.
It's probably worth considering whether other people have a use for
plugin packs. Has anyone seen a use case for a related set of
plugins outside of the packagings defined by Maven? Maybe NMaven?
All people care about is the plugins they use and how to make sure
what is used is consistent.
- No versions of anything should be declared in the Super POM. This
should be totally externalized.
I special cased the clean plugin only because it's just dumb to have
to define that in every project, it so rarely changes.
It's a slippery slope that's not needed for a single plugin. With the
snipet published as mentioned above, this is about 60 seconds for
someone to fix (again only if they have decided to use the enforcer)
Yeah, but for "mvn clean" to not work without it is a bit scary.
Maven starts getting a bad rep from all the projects that use Maven
to build and forget to declare it.
No it's not. Once someone on the build/scm team has set it up it's
not seen by the developers. Everything has to be locked down.
Maybe it isn't such a special case :) Maybe it is time to start
thinking about pushing all the "standard plugin" versions into the
super POM again.
-1
Absolutely not. It's just not the place to put them. The Super POM
will remain largely unchanging between versions and will serve as the
housing for default locations. The set of viable plugins over time
will shift and the set of plugins that people actually use cannot be
covered by notion of a plugin pack. Anyone who has a build who needs
it to be stable will understand the plugins they use, version them
all and stabilize the entire environment.
Now that the standard plugins are relatively stable, this may not
be such an issue as it was originally and gets us the hard
requirement while keeping brevity.
This is really not an issue. It's always the job of a team or small
group of people to stabilize this. Plugin packs will not help because
the second they use plugins outside the scope of the pack they are
again in the same position of locking down versions in the way Brian
and I describe which is what happens in real life. There is no way
you can pre-determine what set of plugins people will use and so the
mechanism to lock them all down should be the same. Not a mix of
plugin packs and then doing what I suggest. It should be the same.
This is not a difficult task. It simply isn't. It takes very little
time right now and a plugin to piece together a snippet of all the
latest releases would go a long way to helping people get what they
need.
Anyway, we can always boil this proposal down to the elements that
still remain once the mixins are implemented. We still need to force
the versions to be specified at least.
I used to be in the camp that it should be required by maven core. I
think that all the work around making that requirement not cumbersome
has me rethinking that position. I think that a recommended best
practice of using the enforcer rule along with easy access to the
configuration needed to make it work is all that's needed. Give
people
who don't care the option to ignore it and give the people who do the
tools and the config and we're all happy.
Funny, because I was in the other camp for that reason and got
convinced to jump the fence :)
I'd ideally like to find if there is an easy way for us to require
people to do the right thing here.
They turn on the enforcer rule and then everything breaks until it's
defined which is the way it has to be to guarantee stability.
Also worth mentioning is that the rules interface was designed to
allow
other modules the ability to execute the rules. Once I complete the
refactor (possibly tonight) then the rules themselves will be outside
the plugin jar. This means ide tools could incorporate this check
along
with some special ability to fix the poms.
This is great stuff - will be very useful.
My only caution there has always been that anything that needs a
tooling solution makes me think Maven is too hard to use on it's
own - I'd still like us to think through the other things as well.
These people are not retarded. They can set up these rules and locked
down versions. These are not the things that make Maven hard, people
are accustomed to configuration management. Tops you have 25 plugins
that need to be versioned. This is not difficult, we can make it
easier. Ask people what makes Maven hard and they will tell you "when
something goes wrong it's almost impossible to find out what's
wrong". A black box of a plugin pack is no guarantee we picked
something that works with any other plugin that may be introduced
into the system.
It seems there's two issues and the proposal (and related things)
hinge on that, so I think I'm going to run two separate polls to
see where the devs stand on the separate issues.
No one wants a black box, they want to see what they are using in
files they can see in their system. Anyone wanting otherwise cannot
know what their developer are using and therefore can guarantee no
level of stability.
Thanks!
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
