Jason van Zyl wrote:
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.
I haven't used the enforcer myself yet. How would "turn on the enforcer
rule" look inside a pom?
If this pom section is simple enough, I think people who care about
reproducibility will use it. Would it be possible to combine this with a
warning?
If someone is running a build without the enforcer rules they'd get a
warning saying:
"It's bad practice not to lock down all plugin versions. Please
consider adding this
... <-- enforcer pom section goes here
to your pom.xml. It helps make your builds reproducible."
It should be possible to turn this warning off by adding a property or
something like it to your pom.
<properties>
<warnAboutUnlockedPluginVersions>false</warnAboutUnlockedPluginVersions>
</properties>
This requires the user to take an extra step to say that they don't care
about it. At the same time we promote the best practice.
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]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]