On 01/09/2007, at 8:00 AM, Brian E. Fox wrote:
It only checks for the condition and fails the build. It currently
does
not make changes or suggestions. The enforcer is about enforcing, not
fixing ;-) but the rule could be executed by another plugin and
used as
a starting place to lookup for suggestions.
Cool.
I'm concerned that begin too heavy handed on this loses sight of the
new user experience a bit.
This is where the plugin comes in handy. It's only turned on by those
who want it. We can add the configuration to ignore certain plugins
like
clean.
Right - I definitely agree for today. I'll come back to Maven 2.1
with your point at the end.
I think the long term maintenance of that is a problem. We're already
seeing it with the parent POM structure and locked down versions we
have here.
I disagree strongly here. Since I started with Maven about 2 yrs ago,
I've had an internal company super-pom that all projects derive
from. I
use it expressly for the purpose of maintaining pluginManagement
across
the board and occasionally dependencyManagement but very sparingly. I
have not found this to be cumbersome at all. I would periodically scan
for new plugin releases and then someone on the CM team would test
them
out before we rolled it out. Occasionally this means changes to our
poms
to support new config etc, but the good thing is these changes can be
committed along with the bump to the next internal super-pom. That
means
we don't break outstanding developer branches, etc. I really think
that
manually maintaining these versions is the safest way to have control
over your project.
I will agree that sometimes it isn't as required to lock down every
version and in those cases (I don't do that in any of my maven
plugins),
don't use the enforcer, or tell it to ignore certain plugins you don't
care about.
Sorry, I was certainly agreeing it's the right way to do it - I just
think we've seen occasional problems in Maven where it's not quite as
easy as Jason described. Though I'd say that was likely due to
pinning to unstable alpha plugins more than anything else, so I'll
trust your experience on this one.
I tried to address this by using a POM as the source so you can just
see it and grab it - did I miss something? Obviously generic mixins
would be better, but I haven't seen a proposal for that yet.
I think we can do this just by generating a sample pluginManagement
snippet on the site somewhere. I don't think anything fancy is needed,
simply providing the snipet so someone can copy and paste will be more
than sufficient. Having it generated with the current latest release
would then make it a good starting point as most people would want the
latest by default and would only resort to reverting if they hit a
problem with a particular plugin.
I think it can be easier. Jason and I typically have a slide in our
Maven presentations that show what a minimal Maven POM looks like:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<name>Test</name>
<version>1.0-SNAPSHOT</version>
</project>
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>
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 :)
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?
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?
- 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.
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. 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.
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.
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.
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.
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]
