You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/08/31 16:33:45 UTC
[PROPOSAL] Plugin packs and concrete versioning
I have revised the proposal I made earlier based on Jason and John's
feedback.
See: http://docs.codehaus.org/display/MAVEN/Plugin+packs+and+concrete
+versioning
Text included below for inline comments (which I'll feed back into
the document as needed).
Context
Currently, plugin versions, if unspecified, resolve to the "latest"
from the repository, which (depending on the repositories included)
can include snapshots. It also means that builds change change
without the POM changing.
In addition to the ones the users specify, several plugins with no
version attached are implied by the lifecycle, making it quite
cumbersome to specify all the plugins that a build might use in the
POM to ensure that the versions are locked down over time.
While this situation is problematic, the alternative of requiring
every single plugin version be provided is too cumbersome and verbose
a task in many situations - particularly in the case of the implied
plugins.
It should also be noted that anything in the Maven installation
itself (such as the settings, or in the past the plugin registry) is
not an adequate solution - the POM must be the definitive reference
for how to build the software and changing Maven installations should
have no effect.
Out of Scope
The original discussion also touched on the following, which are
related but separate issues:
- locking down versions at release time where they were not specified
(a more general problem, as it includes not only RELEASE/LATEST, but
ranges too).
- separation of "declaration" from "instantiation" for a POM.
Solution
Required Plugin Versions
After implementation, Maven will require the version in plugin
definitions that are bound to the lifecycle in the POM from
modelVersion 4.1.0+. Plugins will not be resolved to the latest
version (except for the CLI exception listed below).
However, in 4.0.0 modelVersions, Maven will continue to allow the
RELEASE as the version for backwards compatibility.
Super POM
The Super POM should declare a default version of the clean plugin as
a special case. This will not be the case for the site plugin, or
standard packaging plugins.
Plugin Packs
The additional requirement to declare all versions is not an
inconvenience when the plugin is already declared - just one
additional line.
However, for the implied plugins (jar, compile, resources, etc) -
this would involve an undesirable amount of boilerplate. To better
facilitate this, we should add the concept of plugin packs.
After the releases of one or more included plugins, a pack release
can be made that includes the plugins and their versions. This is
achieved through the deployment of a POM project that declares a
number of plugins - this has the advantage of having the same syntax,
as well as easy cut-and-paste if necessary. For example, the Java
plugin pack:
<project>
<groupId>org.apache.maven.plugins.packs</groupId>
<artifactId>maven-java-plugins</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.2</version>
</plugin>
...
</plugins>
</build>
<reporting>
<plugins>
...
</plugins>
</reporting>
</project>
To incorporate this into a project:
<project>
...
<packaging>jar</packaging>
<pluginPacks>
<pluginPack>
<groupId>org.apache.maven.plugins.packs</groupId>
<artifactId>maven-java-plugins</artifactId>
<version>1.0</version>
</pluginPack>
</pluginPacks>
...
</project>
Only the build and reporting plugins sections of the POM will be
incorporated into the project - not the plugin management or other
sections such as configuration. In addition, if multiple plugin packs
are declared, they should be applied sequentially, overriding any prior.
Note: this facility could later be addressed by mixins in the POM.
h4. Plugin Management
The plugin management section, when declaring a version, must always
win over all plugin packs.
A version will not be required in the plugin management section
(which can still be used to apply configuration to an already-defined
plugin, including those called from the CLI).
CLI
When running a goal from the command line, it should seek the plugin
from those defined in the POM (including their versions). If the
plugin is not defined in the project at all (or in the case that
there is no project, such as with archetype:create), at present the
current rules will be retained. It should be a recommended best
practice to declare any plugins you use from the command line in the
POM that are not once-off goals.
A future enhancement may be to be able to (and if so, require) plugin
versions to be declared in the Maven settings files.
Optional: Decouple Packaging Lifecycle Definition
The definition of lifecycles and packaging types currently occurs in
the maven-core's components.xml, with others defined in plugins via
extensions. With the possible exception of the POM packaging, these
can all be moved into the plugins that define the main package goal.
Given this, the user will be required to declare the plugin that
contains the packaging (including it's version). Like the earlier
requirement, this must not apply to POM's with the previous model
version.
Note that a plugin may still contain one or more packaging.
The lifecycle still does not declare plugin versions - this is to be
defined in the plugin packs.
Optional: Additional Tooling
It would be beneficial to write a plugin that can look at the current
versions in a project, and suggest possible updates available in the
repository (and apply them in an interactive fashion). This may suit
the maven-pom-plugin.
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by William Ferguson <Wi...@yarris.com>.
I agree that the ability to lock down a build is important for release management, but part of the beauty of Maven is the ability to concisely declare a build and at the same time benefit from incremental improvements in various components of it.
Inhouse, we use a buildinfo-plugin (from "Better Builds ..") to capture all the build information and this data is packaged up with each built artifact. So it is always possible to recreate a build exactly.
This gives us the ability to assimilate new plugin versions without needing to modify POMs or parent POMs.
I'd hate to lose that.
So I would rather see this requirement fulfilled by a mechanism that can be switched on or off as needed like the enforcer-plugin.
William
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Sunday, 2 September 2007 1:26 AM
To: Maven Developers List
Subject: [***POSSIBLE SPAM***] - Re: [PROPOSAL] Plugin packs and concrete versioning - Email has different SMTP TO: and MIME TO: fields in the email addresses
On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote:
> Le samedi 1 septembre 2007, Brian E. Fox a écrit :
>> 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.
> +1
>
> IMHO, a link to it should be added to http://maven.apache.org/
> plugins/, because it's the same information in another format.
> Plugins groups (or packs) are already organized here, and can be
> represented in the pluginManagement snippet as XML comments
>
> WDYT?
>
Yes, that's all that's necessary. As noted previously we already have, even for 2.0.x users, a way with the enforcer plugin to help greatly stabilize builds and if we started publishing these snippets tomorrow we'll go another big step. How we make this more seamless can come in time but it can all come in the form of external tooling to find the snippets. We could even fake mixins in this particular case by making people use a certain comment element and we could insert this snippet. When mixins are supported we can transition over to using that without much problem. I don't think the idea of a plugin pack buys us anything configuration management wise as we 1) loose visibility of plugin versioning which is important in a corporate build, 2) don't need anything special in the model to represent this, it just makes things more complicated.
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Jason van Zyl <ja...@maven.org>.
On 1 Sep 07, at 4:35 AM 1 Sep 07, Hervé BOUTEMY wrote:
> Le samedi 1 septembre 2007, Brian E. Fox a écrit :
>> 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.
> +1
>
> IMHO, a link to it should be added to http://maven.apache.org/
> plugins/,
> because it's the same information in another format.
> Plugins groups (or packs) are already organized here, and can be
> represented
> in the pluginManagement snippet as XML comments
>
> WDYT?
>
Yes, that's all that's necessary. As noted previously we already
have, even for 2.0.x users, a way with the enforcer plugin to help
greatly stabilize builds and if we started publishing these snippets
tomorrow we'll go another big step. How we make this more seamless
can come in time but it can all come in the form of external tooling
to find the snippets. We could even fake mixins in this particular
case by making people use a certain comment element and we could
insert this snippet. When mixins are supported we can transition over
to using that without much problem. I don't think the idea of a
plugin pack buys us anything configuration management wise as we 1)
loose visibility of plugin versioning which is important in a
corporate build, 2) don't need anything special in the model to
represent this, it just makes things more complicated.
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Jason Dillon <ja...@planet57.com>.
Sorry, I've not read this entire thread, but have a quick comment...
This idea of plugin packs could easily be extended to the more
generic pom inclusion stuff I've talked about previously. There
other things besides plugin version binding that could be bundled up
into a reusable package (like a common IDE configuration profile for
example).
Sure, grouping up plugins bound to specific versions is very handy
and should help simplify many projects (and even help reduce build
fragility), but IMO it would be a whole lot nicer to see a general
import some pom (by artifact:groupId:version) and merge the contents
into the current poms for execution.
--jason
On Sep 1, 2007, at 4:35 AM, Hervé BOUTEMY wrote:
> Le samedi 1 septembre 2007, Brian E. Fox a écrit :
>> 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.
> +1
>
> IMHO, a link to it should be added to http://maven.apache.org/
> plugins/,
> because it's the same information in another format.
> Plugins groups (or packs) are already organized here, and can be
> represented
> in the pluginManagement snippet as XML comments
>
> WDYT?
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 1 septembre 2007, Brian E. Fox a écrit :
> 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.
+1
IMHO, a link to it should be added to http://maven.apache.org/plugins/,
because it's the same information in another format.
Plugins groups (or packs) are already organized here, and can be represented
in the pluginManagement snippet as XML comments
WDYT?
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Jason van Zyl <ja...@maven.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Plugin packs and concrete versioning
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>> 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?
>I'm not 100% certain, but I think that would require pulling some of
the
>enforcer logic into the core...
>This might be a good thing, i.e. just having a setting in the pom that
>controls whether to enforce plugin versions or not.
><project>
> ...
> <build>
> ...
> <plugin-versions>required|warn|latest</plugin-versions>
> ...
> </build>
> ...
></project>
>The super-pom can set this to warn. Corporate builds can set to
>required once they have a build working. Non-corporate builds can set
>to latest if they want turn off warnings
Well, this could be considered too I suppose with a flag as you
mentioned. However this can be achieved already with the plugin. Just
define the enforcer in the corp super-pom using a property in the
"message" and "warn" values. Then you can set the properties with a
default but override them in your projects.
Having it separate in a plugin means a little bit more configuration but
gains more flexibility. Releases of the plugins can/should occur more
frequently than maven itself and changes don't require new model
versions to use them.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Stephen Connolly <st...@one-dash.com>.
Dennis Lundberg wrote:
> 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?
I'm not 100% certain, but I think that would require pulling some of the
enforcer logic into the core...
This might be a good thing, i.e. just having a setting in the pom that
controls whether to enforce plugin versions or not.
<project>
...
<build>
...
<plugin-versions>required|warn|latest</plugin-versions>
...
</build>
...
</project>
The super-pom can set this to warn. Corporate builds can set to
required once they have a build working. Non-corporate builds can set
to latest if they want turn off warnings
>
> 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 - brett@apache.org
>>> Blog: http://www.devzuz.org/blogs/bporter/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Dennis Lundberg <de...@apache.org>.
Brian E. Fox wrote:
>> I haven't used the enforcer myself yet. How would "turn on the enforcer
>
>> rule" look inside a pom?
>
> See here for an example. Note that multiple rules can be configured at
> once. (also this rule is in the current snapshot rev)
> http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi
> nVersions.html
>
>> 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?
>
> Yes it is because all the rules take a message parameter where you can
> put any message you deem useful. It will use this message and append to
> it any specific warnings generated by the rule.
>
> The rules can also be set as warnings not hard failures.
So, we could put the enforcer configuration, found on the link you
provided, in the super pom and tell it to warn but not fail. That would
be the default configuration. If someone wanted hard failures they would
simply override the "hardFailure" configuration option in their
corporate parent pom.
> --Brian
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Plugin packs and concrete versioning
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>I haven't used the enforcer myself yet. How would "turn on the enforcer
>rule" look inside a pom?
See here for an example. Note that multiple rules can be configured at
once. (also this rule is in the current snapshot rev)
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi
nVersions.html
>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?
Yes it is because all the rules take a message parameter where you can
put any message you deem useful. It will use this message and append to
it any specific warnings generated by the rule.
The rules can also be set as warnings not hard failures.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Dennis Lundberg <de...@apache.org>.
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 - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Brett Porter <br...@apache.org>.
On 03/09/2007, at 8:46 AM, Brian E. Fox wrote:
>> Everything else you said below makes sense and is pretty much in line
>> with my experience, so I think it's best to defer this for a general
>> mixins proposal (if at all).
>
> I'm pretty sure that a general ability to "include" or "mixin" some
> other piece of xml into the pom would come in handy, but this is a
> totally different topic and would need some thought around
> inheritance,
> deployment, etc. I agree with with Wayne's comments in the poll
> thread:
>
> " I am concerned though that providing mixins will send us further
> down
> the path of moving more and more pieces out of the pom which is not
> the
> right move IMO. If we add plugin+version in mixin v1, then people will
> want plugin+version+configuration in mixin v2, and in a short
> period of
> time we'll have re-invented <parent> and <pluginManagement> in non-pom
> files which really makes no sense at all."
>
> If we do mixins, we need to be careful that we don't open things up
> too
> much and make total messes out of the build. I could see this leading
> towards ant like craziness when things aren't linear (inheritance) or
> self contained..
Agreed :)
- Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Plugin packs and concrete versioning
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Everything else you said below makes sense and is pretty much in line
>with my experience, so I think it's best to defer this for a general
>mixins proposal (if at all).
I'm pretty sure that a general ability to "include" or "mixin" some
other piece of xml into the pom would come in handy, but this is a
totally different topic and would need some thought around inheritance,
deployment, etc. I agree with with Wayne's comments in the poll thread:
" I am concerned though that providing mixins will send us further down
the path of moving more and more pieces out of the pom which is not the
right move IMO. If we add plugin+version in mixin v1, then people will
want plugin+version+configuration in mixin v2, and in a short period of
time we'll have re-invented <parent> and <pluginManagement> in non-pom
files which really makes no sense at all."
If we do mixins, we need to be careful that we don't open things up too
much and make total messes out of the build. I could see this leading
towards ant like craziness when things aren't linear (inheritance) or
self contained..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Brett Porter <br...@apache.org>.
Hi Brian,
Thanks for the great response - comments inline...
On 02/09/2007, at 11:30 PM, Brian E. Fox wrote:
>> The misunderstanding seems to be:
>> 1) that I thought we were going to require plugin versions to be
>> specified in the future. You seem to say that is no longer the case.
>
> I think you're right here. After reading your response to my
> comments, I
> realized my (and I think Jason's) assumption is that the core doesn't
> require the versions.
Yep, since that was my original gut feeling many moons ago, and since
we're seeing the same feeling from the poll, I agree this is the best
way to go (in conjunction with some warnings/assistance like you are
discussing with Dennis).
> First, what exactly is in the java pack 1.0? (which plugins and which
> versions?) What happens if I don't want 1 of the plugins in the
> pack...I'm back to defining the pluginManagement section for that one.
> Over time, you will find that you get pMgt creep and soon the pack
> isn't
> really useful anymore because you've had to redefine too many
> versions.
I've always been a big fan of help:effective-* for this. Even today
you can look at the POM and see something different to what is used,
or have to hunt around through all the parents due to the existence
of *Management sections.
However, it makes a good point, and is something that is not in
favour of mixins in general.
Everything else you said below makes sense and is pretty much in line
with my experience, so I think it's best to defer this for a general
mixins proposal (if at all).
Thanks,
Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Plugin packs and concrete versioning
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>The misunderstanding seems to be:
>1) that I thought we were going to require plugin versions to be
>specified in the future. You seem to say that is no longer the case.
I think you're right here. After reading your response to my comments, I
realized my (and I think Jason's) assumption is that the core doesn't
require the versions. We're using a plugin to get this behavior. You
mentioned that if tooling is required, that's a sign of a problem. I
don't think I really agree since all of maven is basically a plugin.
Plugins are nice because people can choose to use them if they want or
develop their own. Back when we discussed having the versions required,
lots of people spoke up and said they wouldn't like that. I think this
is the best solution between flexibility and lock down and it's up to
the user / CM team to decide.
In my instance, the developers essentially don't touch the poms, this is
the job of the CM team. We let them add dependencies as needed but then
the CM team reviews for consistency and conflicts. Without locking down,
we had so many problems with "well, it works on our machines." Granted
it was alpha/beta m2 but it was still a major issue and can be today
with any plugin release that potentially changes behavior (for good or
bad, a change needs to be understood).
The enforcer was originally created because I continued to have
compatibility issues within the team because they weren't all running
the same "blessed" maven version. We discussed this functionality in
core and it was decided to be a plugin, I don't see any difference here.
We're just talking about having the tools to allow people to do what
they want/need without being overly heavy handed.
>2) that you think I'm trying to make it a black box. I'm simply
>looking for a more concise way to express exactly what you are saying
>already.
I can tell you that the simple pack config looks appealing at first
glance. However, if this existed today here's what I believe corp users
would experience:
First, what exactly is in the java pack 1.0? (which plugins and which
versions?) What happens if I don't want 1 of the plugins in the
pack...I'm back to defining the pluginManagement section for that one.
Over time, you will find that you get pMgt creep and soon the pack isn't
really useful anymore because you've had to redefine too many versions.
The other problem I see is that changing too many plugins at once would
make it hard to identify any changes/issues and any new bugs that creep
in. We used to update a bunch of plugins at once in between releases but
quickly found this not to be a good idea.
When I see a new plugin release that we might want to bump up, we review
the release notes and jiras fixed in the release. Then we will make the
change and test it out on the CM team boxes. If it's a significant
plugin change (or maven change), I've been known to have a developer
compare the resulting artifacts (wars mostly) to ensure the same libs
are included. Only after we decide this plugin works as good as the last
and make any changes to use new features does the company super-pom get
updated and rolled out in the scm.
I can't imagine trying to do this with a handful of plugins at once.
Between that and the pMgt creep I mentioned above, I doubt seriously
that I would even consider looking at the packs for my Corp builds. I
think that's really the crux of the problem with them. Someone who is
really trying to lock down their versions will be diligent enough to
really understand what they need in each plugin. I think it is really
just a crutch between the builds that don't need lock down and the corp
ones who won't/can't use it.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Brett Porter <br...@apache.org>.
Jason,
I completely agree with everything you said below, in terms of what
users want at least. So I'm obviously not communicating what I want
well, since you seem to have completely missed my point in every
response.
The misunderstanding seems to be:
1) that I thought we were going to require plugin versions to be
specified in the future. You seem to say that is no longer the case.
2) that you think I'm trying to make it a black box. I'm simply
looking for a more concise way to express exactly what you are saying
already.
That's why I started the two poll threads - I'd appreciate it if you
could respond there so I am 100% clear on where you are coming from.
Hopefully we'll hear from plenty of other folks too that don't have
time to wade through this thread...
- Brett
On 02/09/2007, at 2:37 PM, 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.
>
>>> 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 - brett@apache.org
>> Blog: http://www.devzuz.org/blogs/bporter/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Jason van Zyl <ja...@maven.org>.
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 - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Brett Porter <br...@apache.org>.
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 - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Plugin packs and concrete versioning
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Comments inline also
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Friday, August 31, 2007 12:20 PM
To: Maven Developers List
Subject: Re: [PROPOSAL] Plugin packs and concrete versioning
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?
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.
>>
>> - 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.
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.
>>
>> - 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.
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.
>>
>> - 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.
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.
>>
>> - 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)
>>
>> - 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?
Discussed above.
>> 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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Jason van Zyl <ja...@maven.org>.
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
- 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.
- 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.
- 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.
- No versions of anything should be declared in the Super POM. This
should be totally externalized.
- 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.
So in short you can effectively do this now using the Enforcer
plugin. The fallout of this is we discovered the model is tampered
with as Brian had to do some trickery to look at every plugin element
accurately as all plugin versions were getting filled in internally
when they actually weren't in the POM. With model tampering fixed,
and the build plan in place it would be very easy for us to enforce
this (it already is but the plugin does and unnecessary dance to
achieve this) but it's highly effective.
Brian has pretty much provided the stability. Cleaning up the
internal model, and providing mixins and we have what we need. The
lifecycle doesn't need to be refactored for this and we don't need a
model for pluginPacks, a simple import will do. Anyone who wants this
sort of stability can model this with the trunk version of the
enforcer plugin.
On 31 Aug 07, at 7:33 AM 31 Aug 07, Brett Porter wrote:
> I have revised the proposal I made earlier based on Jason and
> John's feedback.
>
> See: http://docs.codehaus.org/display/MAVEN/Plugin+packs+and
> +concrete+versioning
>
> Text included below for inline comments (which I'll feed back into
> the document as needed).
>
> Context
>
> Currently, plugin versions, if unspecified, resolve to the "latest"
> from the repository, which (depending on the repositories included)
> can include snapshots. It also means that builds change change
> without the POM changing.
>
> In addition to the ones the users specify, several plugins with no
> version attached are implied by the lifecycle, making it quite
> cumbersome to specify all the plugins that a build might use in the
> POM to ensure that the versions are locked down over time.
>
> While this situation is problematic, the alternative of requiring
> every single plugin version be provided is too cumbersome and
> verbose a task in many situations - particularly in the case of the
> implied plugins.
>
> It should also be noted that anything in the Maven installation
> itself (such as the settings, or in the past the plugin registry)
> is not an adequate solution - the POM must be the definitive
> reference for how to build the software and changing Maven
> installations should have no effect.
>
> Out of Scope
>
> The original discussion also touched on the following, which are
> related but separate issues:
> - locking down versions at release time where they were not
> specified (a more general problem, as it includes not only RELEASE/
> LATEST, but ranges too).
> - separation of "declaration" from "instantiation" for a POM.
>
> Solution
>
> Required Plugin Versions
>
> After implementation, Maven will require the version in plugin
> definitions that are bound to the lifecycle in the POM from
> modelVersion 4.1.0+. Plugins will not be resolved to the latest
> version (except for the CLI exception listed below).
>
> However, in 4.0.0 modelVersions, Maven will continue to allow the
> RELEASE as the version for backwards compatibility.
>
> Super POM
>
> The Super POM should declare a default version of the clean plugin
> as a special case. This will not be the case for the site plugin,
> or standard packaging plugins.
>
> Plugin Packs
>
> The additional requirement to declare all versions is not an
> inconvenience when the plugin is already declared - just one
> additional line.
>
> However, for the implied plugins (jar, compile, resources, etc) -
> this would involve an undesirable amount of boilerplate. To better
> facilitate this, we should add the concept of plugin packs.
>
> After the releases of one or more included plugins, a pack release
> can be made that includes the plugins and their versions. This is
> achieved through the deployment of a POM project that declares a
> number of plugins - this has the advantage of having the same
> syntax, as well as easy cut-and-paste if necessary. For example,
> the Java plugin pack:
>
> <project>
> <groupId>org.apache.maven.plugins.packs</groupId>
> <artifactId>maven-java-plugins</artifactId>
> <version>1.0</version>
> <packaging>pom</packaging>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-jar-plugin</artifactId>
> <version>2.1</version>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.2</version>
> </plugin>
> ...
> </plugins>
> </build>
> <reporting>
> <plugins>
> ...
> </plugins>
> </reporting>
> </project>
>
> To incorporate this into a project:
>
> <project>
> ...
> <packaging>jar</packaging>
>
> <pluginPacks>
> <pluginPack>
> <groupId>org.apache.maven.plugins.packs</groupId>
> <artifactId>maven-java-plugins</artifactId>
> <version>1.0</version>
> </pluginPack>
> </pluginPacks>
> ...
> </project>
>
> Only the build and reporting plugins sections of the POM will be
> incorporated into the project - not the plugin management or other
> sections such as configuration. In addition, if multiple plugin
> packs are declared, they should be applied sequentially, overriding
> any prior.
>
> Note: this facility could later be addressed by mixins in the POM.
>
> h4. Plugin Management
>
> The plugin management section, when declaring a version, must
> always win over all plugin packs.
>
> A version will not be required in the plugin management section
> (which can still be used to apply configuration to an already-
> defined plugin, including those called from the CLI).
>
> CLI
>
> When running a goal from the command line, it should seek the
> plugin from those defined in the POM (including their versions). If
> the plugin is not defined in the project at all (or in the case
> that there is no project, such as with archetype:create), at
> present the current rules will be retained. It should be a
> recommended best practice to declare any plugins you use from the
> command line in the POM that are not once-off goals.
>
> A future enhancement may be to be able to (and if so, require)
> plugin versions to be declared in the Maven settings files.
>
> Optional: Decouple Packaging Lifecycle Definition
>
> The definition of lifecycles and packaging types currently occurs
> in the maven-core's components.xml, with others defined in plugins
> via extensions. With the possible exception of the POM packaging,
> these can all be moved into the plugins that define the main
> package goal.
>
> Given this, the user will be required to declare the plugin that
> contains the packaging (including it's version). Like the earlier
> requirement, this must not apply to POM's with the previous model
> version.
>
> Note that a plugin may still contain one or more packaging.
>
> The lifecycle still does not declare plugin versions - this is to
> be defined in the plugin packs.
>
> Optional: Additional Tooling
>
> It would be beneficial to write a plugin that can look at the
> current versions in a project, and suggest possible updates
> available in the repository (and apply them in an interactive
> fashion). This may suit the maven-pom-plugin.
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Plugin packs and concrete versioning
Posted by Arnaud HERITIER <ah...@gmail.com>.
...
> A future enhancement may be to be able to (and if so, require) plugin
> versions to be declared in the Maven settings files.
....
but in that case it could be interesting to be able to have an extend
mechanism of settings using the repository like a parent pom. The idea
is to be able to define custom settings for a corporate environment, a
project team in a common place. The problem then, will be to be able
to reproduce a build. In that case we could have a reference to it in
the pom (it could be quickly difficult to resolve versions)
Arnaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org