Re: Buildinfo. Maven plugin metadata.
Thanks for the reply Jason.
What is the name of John Caseys plugin?
Ill have a look at it.
Cheers
Ian Berry
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, 27 August 2007 9:27 AM
To: Maven Developers List
Subject: [***POSSIBLE SPAM***] - Re: Maven plugin metadata - Email has
different SMTP TO: and MIME TO: fields in the email addresses
You can probably save yourself some time and use John Casey's. He
probably has a newer variant, plus he's got a plugin to pin down the
snapshot versions so he's probably got most things you need. He'll
probably respond when he gets back from the weekend.
On 26 Aug 07, at 4:13 PM 26 Aug 07, Ian Berry wrote:
> Hi,
>
>
>
> I am developing a buildinfo plugin, listing all dependencies and
> plugins
> used during a build.
>
>
>
> For snapshot dependencies, and snapshot plugins, I would like to
> get the
> build timestamp and build number to include in the output.
>
>
>
> I have successfully gained this metadata information for
> snapshot-dependencies, but I can't get the metadata for
> snapshot-plugins.
>
>
>
> To get the plugin artifacts, I use ${project.pluginArtifacts} (or
> project.getPluginArtifacts())
>
> The artifacts returned, have not metadata attached, i.e.
> artifact.getMedatadatalist().size() returns 0;
>
>
>
> How can I get a build timestamp and build number for a snapshot-
> plugin?
>
> In my local repository, the snapshot-plugins have a
> maven-metadata-snapshot.xml.
>
>
>
> Thanks,
>
>
>
>
>
> Ian Berry
>
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] bring shade-maven-plugin to apache
It makes uberjar thingies and does some class filtering muck to protect
includeded dependencies kinda in the same light as jarjar.
--jason
-Original Message-
From: James William Dumay <[EMAIL PROTECTED]>
Date: Mon, 03 Sep 2007 12:56:57
To:[EMAIL PROTECTED]
Cc:Maven Developers List
Subject: Re: [vote] bring shade-maven-plugin to apache
What does the shade plugin do?
James
On Mon, 2007-09-03 at 02:53 +, Jason Dillon wrote:
> Why does it need to move? Why not move it out of the sandbox and use it asis?
>
> --jason
>
>
> -Original Message-
> From: "Brian E. Fox" <[EMAIL PROTECTED]>
>
> Date: Sun, 2 Sep 2007 22:37:12
> To:"Maven Developers List"
> Subject: [vote] bring shade-maven-plugin to apache
>
>
> The shade-maven-plugin is currently in the codehaus mojo sandbox. This
> plugin is used by maven core to package the uberjar for distribution and
> should be moved to the maven project.
>
>
>
> Please vote {+1,0,-1], vote is open for 72 hrs.
>
>
>
> +1
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] bring shade-maven-plugin to apache
It's used by maven to build maven itself, so it's essentially a core plugin
now. The core functionality should coexist with the rest of the maven project.
This vote really is if the maven team wants to bring the code in house. If it
is forked and left at mojo or just plain moved would be a question for the mojo
team. (ie choose to delete from their sandbox or maintain it separately)
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon
Sent: Sunday, September 02, 2007 10:53 PM
To: Maven Developers List
Subject: Re: [vote] bring shade-maven-plugin to apache
Why does it need to move? Why not move it out of the sandbox and use it asis?
--jason
-Original Message-
From: "Brian E. Fox" <[EMAIL PROTECTED]>
Date: Sun, 2 Sep 2007 22:37:12
To:"Maven Developers List"
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] bring shade-maven-plugin to apache
What does the shade plugin do?
James
On Mon, 2007-09-03 at 02:53 +, Jason Dillon wrote:
> Why does it need to move? Why not move it out of the sandbox and use it asis?
>
> --jason
>
>
> -Original Message-
> From: "Brian E. Fox" <[EMAIL PROTECTED]>
>
> Date: Sun, 2 Sep 2007 22:37:12
> To:"Maven Developers List"
> Subject: [vote] bring shade-maven-plugin to apache
>
>
> The shade-maven-plugin is currently in the codehaus mojo sandbox. This
> plugin is used by maven core to package the uberjar for distribution and
> should be moved to the maven project.
>
>
>
> Please vote {+1,0,-1], vote is open for 72 hrs.
>
>
>
> +1
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] bring shade-maven-plugin to apache
Why does it need to move? Why not move it out of the sandbox and use it asis?
--jason
-Original Message-
From: "Brian E. Fox" <[EMAIL PROTECTED]>
Date: Sun, 2 Sep 2007 22:37:12
To:"Maven Developers List"
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[vote] bring shade-maven-plugin to apache
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
Re: [PROPOSAL] Local Repository Separation
On 2 Sep 07, at 6:35 PM 2 Sep 07, Brett Porter wrote: On 02/09/2007, at 11:37 PM, Brian E. Fox wrote: I know its another directory, but the following might be more straightforward: . |-- metadata | |-- apache.snapshots | |-- central | |-- codehaus.snapshots | `-- ... |-- release-cache |-- snapshot-cache `-- workspace |-- default |-- workspace1 `-- ... I'm not sure why the metadata should be separate, but I can see the release-cache, snapshot-cache and workspaces being useful. I like this suggestion better than the original. The locking would be nice too. the metadata separation is a bit of a toss up for me - it would have the benefit of being able to interchange a local and remote repository instead of the metadata format being separate. I added it in here as a related change because of that benefit, but it isn't really related to the initial requirements. If we're not using repository ids, how are you going to designate the source. If you are going to use URLs and someone changes it, how are you going to guarantee consistency? I don't think there's any value in separating the metadata. If you're going to use transactions now you need two instead of one to lay down the files. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Local Repository Separation
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote: I know its another directory, but the following might be more straightforward: . |-- metadata | |-- apache.snapshots | |-- central | |-- codehaus.snapshots | `-- ... |-- release-cache |-- snapshot-cache `-- workspace |-- default |-- workspace1 `-- ... I'm not sure why the metadata should be separate, but I can see the release-cache, snapshot-cache and workspaces being useful. I like this suggestion better than the original. The locking would be nice too. the metadata separation is a bit of a toss up for me - it would have the benefit of being able to interchange a local and remote repository instead of the metadata format being separate. I added it in here as a related change because of that benefit, but it isn't really related to the initial requirements. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
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 and 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 - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
>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 and 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
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 - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Same here. Thanks, Stéphane On 9/2/07, Arik Kfir <[EMAIL PROTECTED]> wrote: > Hi, > > As a heavy Maven **user**, what would be best for us is having some plugin > (could be the enforcer, or another) automatically generate this > configuration for us into the POM. Something along the lines of: > > mvn enforcer:lock-plugins > > This command will find the most appropriate version of relevant plugins and > modify my POM(s) to explicitly specify them. Later on, I can either manually > modify my POM when I want to upgrade a plugin, or run another command, e.g: > > mvn enforcer:update-all-plugins > > or: > > mvn enforcer:update-plugin > -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin > -Dversion=latest/2.9.9.9 > > Current behavior should remain, if only not to upset the many non-enterprise > users which use Maven more "lightly". > > HTH, > Arik. > > On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: > > > > B > > > > Totally agree with Wayne here. > > > > -D > > > > On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > [X] (B) Retain the current behaviour, but make using the enforcer a > > > > best practice to do the above, or some other control mechanism such > > > > as having the repository manager handle the available plugins > > > > > > I am thinking about the new user experience and winning more converts. > > As such, I think the current behavior is best. Once they get using Maven > > more seriously (and in corporate environments that know what they're doing), > > I think adding the Enforcer configuration and locking versions down will > > come naturally. But *requiring* it seems excessive -- unless we're doing > > that ourselves somewhere, with plugin packs or similar, then I feel better > > about it. > > > > > > Wayne > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck" -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
I think this might be the most practical solution. Yes, perhaps the functionality belongs with some type of pom/release/build/CM topic'd plugin, but that is a secondary issue! Tools like the archetypes can create them/have them created in the pom too, e.g. if "genAllDeps=true". > -Original Message- > From: Arik Kfir [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 02, 2007 1:34 PM > To: Maven Developers List > Subject: Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or > later > > Hi, > > As a heavy Maven **user**, what would be best for us is having some plugin > (could be the enforcer, or another) automatically generate this > configuration for us into the POM. Something along the lines of: > > mvn enforcer:lock-plugins > > This command will find the most appropriate version of relevant plugins and > modify my POM(s) to explicitly specify them. Later on, I can either manually > modify my POM when I want to upgrade a plugin, or run another command, e.g: > > mvn enforcer:update-all-plugins > > or: > > mvn enforcer:update-plugin > -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin > -Dversion=latest/2.9.9.9 > > Current behavior should remain, if only not to upset the many non-enterprise > users which use Maven more "lightly". > > HTH, > Arik. > > On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: > > > > B > > > > Totally agree with Wayne here. > > > > -D > > > > On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > > [X] (B) Retain the current behaviour, but make using the enforcer a > > > > best practice to do the above, or some other control mechanism such > > > > as having the repository manager handle the available plugins > > > > > > I am thinking about the new user experience and winning more converts. > > As such, I think the current behavior is best. Once they get using Maven > > more seriously (and in corporate environments that know what they're doing), > > I think adding the Enforcer configuration and locking versions down will > > come naturally. But *requiring* it seems excessive -- unless we're doing > > that ourselves somewhere, with plugin packs or similar, then I feel better > > about it. > > > > > > Wayne > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The upcoming doxia release depends upon PLXCOMP-80, need help applying patch
Thanks Jason! Jason van Zyl wrote: Patched and released. You just need to wait for the sync. On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote: Hi I'm going through the last remaining issues for the upcoming release of doxia 1.0-alpha-9. One of these issues is http://jira.codehaus.org/browse/PLXCOMP-80 It has a patch attached and is dead simple. I'd be grateful if someone with karma at Plexus could apply the patch and propose a release of plexus-velocity-1.1.7. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
On 2 Sep 07, at 11:33 AM 2 Sep 07, Arik Kfir wrote: Hi, As a heavy Maven **user**, what would be best for us is having some plugin (could be the enforcer, or another) automatically generate this configuration for us into the POM. Something along the lines of: mvn enforcer:lock-plugins That's not the enforcer's job but yes a simple tool to grab the latest set of stable plugin. Place it in a POM of your choice where everything done is visible. This command will find the most appropriate version of relevant plugins and modify my POM(s) to explicitly specify them. Later on, I can either manually modify my POM when I want to upgrade a plugin, or run another command, e.g: mvn enforcer:update-all-plugins Exactly. or: mvn enforcer:update-plugin -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin -Dversion=latest/2.9.9.9 Current behavior should remain, if only not to upset the many non- enterprise users which use Maven more "lightly". HTH, Arik. On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: B Totally agree with Wayne here. -D On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: [X] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins I am thinking about the new user experience and winning more converts. As such, I think the current behavior is best. Once they get using Maven more seriously (and in corporate environments that know what they're doing), I think adding the Enforcer configuration and locking versions down will come naturally. But *requiring* it seems excessive -- unless we're doing that ourselves somewhere, with plugin packs or similar, then I feel better about it. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
> [ ] (A) Having a way to include a set of plugins in one small POM > [ ] (B) Pasting a snippet in from the web site is sufficient > [X] (D) Undecided I personally don't mind pasting a snippet and I think this is a good idea no matter what happens -- perhaps it could be included in the release notes for each version. I can also see the use of mixins. Especially if the Maven team is the one providing the mixin, and each mixin is linked to a specific Maven release version as a set of "working, integration-tested plugin versions for this release" which a lot of people expect from the tool. 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 and in non-pom files which really makes no sense at all. Instead of all this mixin stuff (and perhaps this isn't really related), I think we need to "fix" the way we develop and release plugins, and perhaps this means changing the way versions are resolved etc (which we've discussed before -- should [1.1, ) include alphas and betas etc -- I say no). I don't think we should have *any* plugin at an "alpha" phase for more than 30 days. Same goes for "beta". Instead we should create pools of unit and integration tests, verify that things aren't broken when we add new functionality, and *release* new versions of plugins. I'd be super happy if a SINGLE rfe or bug fix in a plugin results in a new version (1.1.2 to 1.1.3). Instead we have months and even years in between plugin releases, and people are using alphas and betas and even adding snapshot repos to their poms etc, resulting in less stable builds than we can and should be delivering. Stability != no new releases. Wayne On 9/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > What are the real requirements? > > They are: > > 1) An easy way to get a set of stable plugins that work together > 2) To easily see what versions are contained in this set > 3) To easily change or augment what is in this set > > The current mechanism + toolings works. I know what's going to happen > with plugin packs. Someone is going to want to change a version of a > plugin they are using and "How do I find out what versions of plugins > am I using", "How do I override what version of a plugin I'm using if > it's specified in a plugin pack?", "Does plugin management win if > it's in a plugin pack?". "I found a bug in the way plugin packs are > processed and I can't get a plugin version I need, is there a work > around?". "How do I configure plugins that have been defined in the > plugin pack". So people are going to have to end up redeclaring bits > to get configuration and execution information locked down and then > you end up with a terrible configuration management problem. > > A fully, and clear, literal way to define this is what is most > practical. The questions below are also framed to bias the answers. > For A, plugin packs are not the only solution. In very practical > terms the total number of plugins is not that high. What people want > to know is the stable set. The core processing required for the > notion of a plugin pack will not be straight forward and it's not > necessary and adds almost no value and I'm certain it will lead to > greater complexity. > > Users want 1), 2), and 3). The current mechanism plus minimal > tooling, or no tooling if people cut and paste (big deal) covers > those requirements. Plugin packs cover 1) and then it becomes another > nightmare to maintain. I am not in favor of plugin packs. > > On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: > > > Like the other poll, I'd like to hear from as many people as > > possible their opinion this topic (even if you just want to say '0' > > so we know where you stand). > > > > [ ] (A) Having a way to include a set of plugins in one small POM > > fragment would be a useful feature to have (if you have a use case > > other than the already stated "standard plugins", please specify) > > [ ] (B) Pasting a snippet in from the web site is sufficient > > [ ] (C) No opinion > > [ ] (D) Undecided > > [ ] (E) Other (please specify) > > > > Thanks, > > Brett > > > > -- > > Brett Porter - [EMAIL PROTECTED] > > Blog: http://www.devzuz.org/blogs/bporter/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EM
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
Hi, As a heavy Maven **user**, what would be best for us is having some plugin (could be the enforcer, or another) automatically generate this configuration for us into the POM. Something along the lines of: mvn enforcer:lock-plugins This command will find the most appropriate version of relevant plugins and modify my POM(s) to explicitly specify them. Later on, I can either manually modify my POM when I want to upgrade a plugin, or run another command, e.g: mvn enforcer:update-all-plugins or: mvn enforcer:update-plugin -DgroupId=org.apache.maven.plugins-DartifactId=maven-jar-plugin -Dversion=latest/2.9.9.9 Current behavior should remain, if only not to upset the many non-enterprise users which use Maven more "lightly". HTH, Arik. On 9/2/07, Dan Tran <[EMAIL PROTECTED]> wrote: > > B > > Totally agree with Wayne here. > > -D > > On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > > [X] (B) Retain the current behaviour, but make using the enforcer a > > > best practice to do the above, or some other control mechanism such > > > as having the repository manager handle the available plugins > > > > I am thinking about the new user experience and winning more converts. > As such, I think the current behavior is best. Once they get using Maven > more seriously (and in corporate environments that know what they're doing), > I think adding the Enforcer configuration and locking versions down will > come naturally. But *requiring* it seems excessive -- unless we're doing > that ourselves somewhere, with plugin packs or similar, then I feel better > about it. > > > > Wayne > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
B Totally agree with Wayne here. -D On 9/2/07, Wayne Fay <[EMAIL PROTECTED]> wrote: > > [X] (B) Retain the current behaviour, but make using the enforcer a > > best practice to do the above, or some other control mechanism such > > as having the repository manager handle the available plugins > > I am thinking about the new user experience and winning more converts. As > such, I think the current behavior is best. Once they get using Maven more > seriously (and in corporate environments that know what they're doing), I > think adding the Enforcer configuration and locking versions down will come > naturally. But *requiring* it seems excessive -- unless we're doing that > ourselves somewhere, with plugin packs or similar, then I feel better about > it. > > Wayne > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The upcoming doxia release depends upon PLXCOMP-80, need help applying patch
Patched and released. You just need to wait for the sync. On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote: Hi I'm going through the last remaining issues for the upcoming release of doxia 1.0-alpha-9. One of these issues is http://jira.codehaus.org/browse/PLXCOMP-80 It has a patch attached and is dead simple. I'd be grateful if someone with karma at Plexus could apply the patch and propose a release of plexus-velocity-1.1.7. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Need for plugin packs / mixins for plugins
What are the real requirements? They are: 1) An easy way to get a set of stable plugins that work together 2) To easily see what versions are contained in this set 3) To easily change or augment what is in this set The current mechanism + toolings works. I know what's going to happen with plugin packs. Someone is going to want to change a version of a plugin they are using and "How do I find out what versions of plugins am I using", "How do I override what version of a plugin I'm using if it's specified in a plugin pack?", "Does plugin management win if it's in a plugin pack?". "I found a bug in the way plugin packs are processed and I can't get a plugin version I need, is there a work around?". "How do I configure plugins that have been defined in the plugin pack". So people are going to have to end up redeclaring bits to get configuration and execution information locked down and then you end up with a terrible configuration management problem. A fully, and clear, literal way to define this is what is most practical. The questions below are also framed to bias the answers. For A, plugin packs are not the only solution. In very practical terms the total number of plugins is not that high. What people want to know is the stable set. The core processing required for the notion of a plugin pack will not be straight forward and it's not necessary and adds almost no value and I'm certain it will lead to greater complexity. Users want 1), 2), and 3). The current mechanism plus minimal tooling, or no tooling if people cut and paste (big deal) covers those requirements. Plugin packs cover 1) and then it becomes another nightmare to maintain. I am not in favor of plugin packs. On 1 Sep 07, at 7:53 PM 1 Sep 07, Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated "standard plugins", please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Plugin packs and concrete versioning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
> [X] (B) Retain the current behaviour, but make using the enforcer a > best practice to do the above, or some other control mechanism such > as having the repository manager handle the available plugins I am thinking about the new user experience and winning more converts. As such, I think the current behavior is best. Once they get using Maven more seriously (and in corporate environments that know what they're doing), I think adding the Enforcer configuration and locking versions down will come naturally. But *requiring* it seems excessive -- unless we're doing that ourselves somewhere, with plugin packs or similar, then I feel better about it. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
>> 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. > > ... > >... >required|warn|latest >... > > ... > >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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
>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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Local Repository Separation
>I know its another directory, but the following might be more >straightforward: >. >|-- metadata >| |-- apache.snapshots >| |-- central >| |-- codehaus.snapshots >| `-- ... >|-- release-cache >|-- snapshot-cache >`-- workspace > |-- default > |-- workspace1 > `-- ... I'm not sure why the metadata should be separate, but I can see the release-cache, snapshot-cache and workspaces being useful. I like this suggestion better than the original. The locking would be nice too. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Plugin packs and concrete versioning
>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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The upcoming doxia release depends upon PLXCOMP-80, need help applying patch
Hi I'm going through the last remaining issues for the upcoming release of doxia 1.0-alpha-9. One of these issues is http://jira.codehaus.org/browse/PLXCOMP-80 It has a patch attached and is dead simple. I'd be grateful if someone with karma at Plexus could apply the patch and propose a release of plexus-velocity-1.1.7. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
B Raphaël 2007/9/2, Brett Porter <[EMAIL PROTECTED]>: > I'd like to hear from as many people as possible their opinion this > topic (even if you just want to say '0' so we know where you stand). > > [ ] (A) All plugin versions must be specified by the project or its > parent hierarchy somewhere, at the cost of some verbosity (though we > should look at ways to make this easier/smaller/etc per the current > discussion) > [ ] (B) Retain the current behaviour, but make using the enforcer a > best practice to do the above, or some other control mechanism such > as having the repository manager handle the available plugins > [ ] (C) No opinion > [ ] (D) Undecided > [ ] (E) Other (please specify) > > Thanks, > Brett > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > >
Re: [poll] Need for plugin packs / mixins for plugins
A Raphaël 2007/9/2, Brett Porter <[EMAIL PROTECTED]>: > Like the other poll, I'd like to hear from as many people as possible > their opinion this topic (even if you just want to say '0' so we know > where you stand). > > [ ] (A) Having a way to include a set of plugins in one small POM > fragment would be a useful feature to have (if you have a use case > other than the already stated "standard plugins", please specify) > [ ] (B) Pasting a snippet in from the web site is sufficient > [ ] (C) No opinion > [ ] (D) Undecided > [ ] (E) Other (please specify) > > Thanks, > Brett > > -- > Brett Porter - [EMAIL PROTECTED] > Blog: http://www.devzuz.org/blogs/bporter/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [PROPOSAL] Plugin packs and concrete versioning
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: 4.0.0 test test Test 1.0-SNAPSHOT org.apache.maven.plugins.packs maven-java-plugin-pack 1.0 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
Re: [PROPOSAL] Plugin packs and concrete versioning
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: 4.0.0 test test Test 1.0-SNAPSHOT org.apache.maven.plugins.packs maven-java-plugin-pack 1.0 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
Re: [poll] Need for plugin packs / mixins for plugins
A Brett Porter wrote: Like the other poll, I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) Having a way to include a set of plugins in one small POM fragment would be a useful feature to have (if you have a use case other than the already stated "standard plugins", please specify) [ ] (B) Pasting a snippet in from the web site is sufficient [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] Requiring users to specify plugin versions in Maven 2.1 or later
B With the following proviso: I'd like to see main Maven releases more often, and have those main releases specify a suite of endorsed plugin versions for that Maven release. That way, if I want a stable reproducible build, I just continue to use the version of Maven that I built with. It will keep using the same versions of all the endorsed plugins unless I override them. If I want to bump a specific plugin, I just provide a version for that in my pom. If I want to bump them all, I just down load the latest Maven release and try building. -Stephen. Brett Porter wrote: I'd like to hear from as many people as possible their opinion this topic (even if you just want to say '0' so we know where you stand). [ ] (A) All plugin versions must be specified by the project or its parent hierarchy somewhere, at the cost of some verbosity (though we should look at ways to make this easier/smaller/etc per the current discussion) [ ] (B) Retain the current behaviour, but make using the enforcer a best practice to do the above, or some other control mechanism such as having the repository manager handle the available plugins [ ] (C) No opinion [ ] (D) Undecided [ ] (E) Other (please specify) Thanks, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] toolchains
Hello, See: http://docs.codehaus.org/display/MAVEN/Toolchains Text included below for inline comments (which I'll feed back into the document as needed). Milos Goal Have a way for plugins to discover what JDK (or other tools) are to be used, without configuring the plugins. The current Maven way of achieving this is to run Maven itself with the required JDK. After toolchains, the JDK that Maven is running within, shall be irrelevant to the project in question. Motivation Current way or enforcing project's JDK version (via the enforcer or otherwise) by forcing the user to run Maven itself with the given JDK version breaks embedded use. Additionally toolchains will allow a type of user interaction that IDE users are used to. Just set the JDK to the project and go. Design Note: I'll be focusing on JDK toolchain. I don't have enough background information for other types of toolchains. The associated issue is: MNG-468 3 basic points of view: 1. Plugin denotes what toolchain type it requires for it's operation. So compilation, surefire, jnlp, ... need a JDK toolchain instance for example. The actual instance of the toolchain is passed into the plugin by the infrastructure (using Build context?). If no toolchain of given type is available to the infrastructure, the build fails. The JDK toolchain shall have a fallback default value of the JDK maven runs with. Others might not have such a default value. Q1: how shall the plugin tell what toolchains it needs? parameter? parameter's or mojo's @toolchain annotation? 2. User defines the toolchain instances that are available in his current setup. Shall be project independent, stored in $HOME/.m2/toolchains.xml file? Could look like this: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07 3. Project shall be allowed to state which instance of the given toolchain type it requires for the build. Therefore making sure that all plugins use jdk15 for example. if such toolchain instance is not found in user's local setup, the build shall fail early. Q2: how to mark that in the pom? Shall also be profile-able, eg. have different configurations run with different instances of toolchains.. a new pom element? eg. jdk jdk15 or rather some backward compatible solution? Possibly something along the lines of the enforcer plugin? A toolchain-plugin would be responsible for picking the correct instances and make it available for other plugins to use (in the build content). maven-toolchain-plugin jdk15 toolkit22 Backward compatibility Can we achieve backward compatibility with 2.0.x or do we have to go with 2.1 only? It would be nice if at least plugins that start using toolchains would not require 2.1. The only roadblock for backward compatibility is the build-context that is needed for inter-plugin communication. Build-context seems to be relatively independent of the rest of maven, just requires plexus container that is newer than the one used in 2.0.x. Can we upgrade? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
