sorry for the brevity - I'm heading off to bed and am afk for a day
and a bit so wanted to get a quick response in...
On 01/09/2007, at 1:45 AM, Jason van Zyl wrote:
A couple notes that you can incorporate from experiences I've had
based on a client setup:
- The enforcer plugin now has a rule to fully lock down all plugin
versions
right, so that's the tooling referred to? I thought it just checked,
didn't actually apply the changes?
- You do have to lock down all plugins including things like
"eclipse:eclipse" because these are used extensively by many groups
and these changing can have serious repercusions in a build
environment. Everything must be locked down for it to be stable. So
someone can start a new project to try something but when it
officially becomes part of the build that must be communicated to
the build team and the plugin needs to be locked down. A single
point that can vary, let's say the eclipse plugin that has a bug
and many people are screwed. It's easy to either use a POM that
doesn't have enforcement turned on by not inheriting from the POM
with the rule declaration, or an option to turn off enforcement
which would always be turned on for blessed builds.
I agree that you want to flip the switch that enforces it in most
cases, but I think maybe this could be configurable. I don't want to
lose the ability to run archetype:create on a default install, or to
be able to try out other plugins not defined in the POM. This is
especially the case for distributed source code - you don't want to
ask a user to have to edit a POM to add the IDEA plugin they love
just because the project only defines the eclipse configuration.
I'm concerned that begin too heavy handed on this loses sight of the
new user experience a bit.
- Putting all versions in an organization POM is not that
loathsome. It's 30 minutes work but it could be easier. I locked
down everything with a client including eclipse, idea, and site
plugins pretty shortly. It now works great. So in practice this is
not that bad.
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.
- One mixin with a plugin configuration chunk and someone would be
done. If we provided a loosely couple set of plugins we think work
then people can grab those and put them in their POM. We can have a
tool to help them. OBSERVATION: I've noted that build/scm people
want to see these versions in an actual file. So being able to grab
the recommended set, grab a snippet and check it in. From what I'm
seeing the mixins would allow people to put all their version
information in one place. A reference to some artifact seems to
make people uncomfortable.
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.
- 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.
- We don't need any new internal mechanism to model this. We can
make snippets for people to use, and they will mix and match
because they will. We just need to get them started. A snippet
inside pluginManagement will do.
Snippet? Are you saying cut and paste, or another name for a mixin,
or something else?
Cleaning up the internal model, and providing mixins and we have
what we need.
I'm happy to use mixins instead if they exist - I just didn't want to
risk missing getting this in because the other feature wasn't there.
The lifecycle doesn't need to be refactored for this
Not sure what you mean - I didn't think I suggested refactoring the
lifecycle for this (I did say there was some optional, related work
that could be done at the end).
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.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
