On 31 Aug 07, at 9:20 AM 31 Aug 07, Brett Porter wrote:
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,
You can I'm just saying this is undesirable in stable environment.
Who might have been caught out with the faulty release of Archetype
if we didn't catch it and it wasn't locked down in a given environment?
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.
Not at all. It has be easy to experiment, no argument there. But
what's killing people is the stable build requirement. The enforcer
can either be turned on in a profile to check, I've had one client
who wants it on all the time as configuring plugins is not the
developer's job. But there is no question if you want stability in a
corporate environment you must lock down everything and this I hear
over and over again from clients. Build/SCM leads care less about
experimentation and more about stability. There's not reason we can't
make both work easily.
- 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.
Why is it a problem? For someone working even a couple hours a week
on builds, and normally we're talking full time people this is not a
problem in practice. You can't hide the version set in a plugin pack
where people can't see the versions being used easily. I'm against
that because I've seen what users want in corporate environments.
They want stability and they want to see exactly what's being used
without having to run a report.
- 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.
It's still better then putting it in the SuperPOM. If we're providing
the pre-defined sets what is the point in separating the
specification of one plugin from the rest? As simple as it may seem
what if we did lock that version down and there was something wrong
with it? We should manage them from one place. The SuperPOM is the
place for our directory structure defaults and locations. Plugin
configuration is the domain of the user.
- 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?
A snippet of a POM that can be used as a mixin.
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.
It can already be done in a pretty sane way now with the enforcer
plugin. The plugin snippets could be created right now, we could put
them somewhere, and people could use them starting tomorrow. This
would actually be helpful. This would be a full solution. Snippets +
Enforcer plugin. The ability to mixin a snippet would make this
easier but we're most of the way to a solution already even for 2.0.x
users.
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]
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]
