You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2007/09/01 00:00:22 UTC
RE: [PROPOSAL] Plugin packs and concrete versioning
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 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 "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