Re: Model Version 5.0.0
For this, there is already an enforcer rule available: https://github.com/gary-rowe/BitcoinjEnforcerRules Domi On 24.03.2014, at 20:31, Martijn Dashorst wrote: > On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> I see the checksums then as being another potential side artifact... No >> need for modelVersion 5.0.0 >> > > I see it differently: the checksum validates the GAV coordinates. "I mean > 'com.example.foo:foo:1.0', specifically verify that it matches this > signature 'sha1:1234567890abcdef'. > > For example, this enables me to check if a different version of an artefact > was uploaded to the same GAV than I expected (and reportedly the original > author too). > > A plugin right now could capture them and deploy to repo, and you could >> have same plugin verify the resolved dependencies against the same file. >> > > This assumes the whole chain of parties is to be trusted. That nobody will > try to side-load a version from a different repository. > > I find the idea of adding a checksum to a dependency interesting. While I > don't care for the extra fields in the POM, it opens a better venue of > vetting the dependencies. > > Martijn - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.2.1 release notes
If no one else minds I'll convert it all to single markdown document. On Mar 24, 2014, at 7:50 PM, Olivier Lamy wrote: > sounds good go for that > > On 25 March 2014 10:13, Jason van Zyl wrote: >> Fat fingers. I meant to say a single curated set of release notes. >> >> On Mar 24, 2014, at 3:49 PM, Olivier Lamy wrote: >> >>> so need some work. >>> The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 >>> release notes has been made using markdown. >>> If someone has idea go for it (ATM I don't have enough time for that). >>> >>> Cheers >>> Olivier >>> >>> On 25 March 2014 09:27, Olivier Lamy wrote: working on fixing that. As the format has changed (apt -> md) the velocity script cannot see it. On 25 March 2014 08:45, Andrew Holland wrote: > Hi, > > Maven 3.2.1 release notes seem to be missing from > http://maven.apache.org/release-notes-all.html > > Regards > > Andy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> >>> >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> First, the taking in of scattered particulars under one Idea, >> so that everyone understands what is being talked about ... Second, >> the separation of the Idea into parts, by dividing it at the joints, >> as nature directs, not breaking any limb in half as a bad carver might. >> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) >> >> >> >> >> >> >> >> >> > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To think is easy. To act is hard. But the hardest thing in the world is to act in accordance with your thinking. -- Johann von Goethe
Re: Maven 3.2.1 release notes
sounds good go for that On 25 March 2014 10:13, Jason van Zyl wrote: > Fat fingers. I meant to say a single curated set of release notes. > > On Mar 24, 2014, at 3:49 PM, Olivier Lamy wrote: > >> so need some work. >> The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 >> release notes has been made using markdown. >> If someone has idea go for it (ATM I don't have enough time for that). >> >> Cheers >> Olivier >> >> On 25 March 2014 09:27, Olivier Lamy wrote: >>> working on fixing that. >>> As the format has changed (apt -> md) the velocity script cannot see it. >>> >>> On 25 March 2014 08:45, Andrew Holland wrote: Hi, Maven 3.2.1 release notes seem to be missing from http://maven.apache.org/release-notes-all.html Regards Andy >>> >>> >>> >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> >> >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > > > > > > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SCM Web URL?
Le mardi 25 mars 2014 12:02:51 Olivier Lamy a écrit :
> On 21 March 2014 22:31, Hervé BOUTEMY wrote:
> > I'm not in phase with such analysis
> >
> > that's:
> > 1. something logic: if you have ${url} for a path, ${url}/sub-directory is
> > expected for the url to the sub-directory. Anything more complex should be
> > avoided as much as possible. POM inheritance actually only supports this
> > simple (yet sensible) algorithm.
> >
> > 2. it works for svnview, viewvc, Fisheye, github and a lot of other web
> > access tools, but not for gitview as configured at ASF (gitview can
> > support it, I found documentation)
> >
> >
> > As reported on the list a few monthes ago (the intent was to discuss about
> > it, but I got no reply), on Maven core, I configured github mirror [1]
> Yup configuring to use github mirror is a good idea.
> We could do that for all?
it's only a matter of convention to define (and document in [1]?)and update
each root pom.xml in every git repo
Regards,
Hervé
[1] http://maven.apache.org/developers/conventions/git.html
>
> > We had multiple options:
> > - do such github mirror link for every Maven component migrating to git
> > - work with ASF infra (don't know who precisely) to see if ASF gitview
> > configuration could be improved to support such feature
> >
> > Since there was no reply and I could not make a decision by myself, I
> > considered nobody was interested in improving git support for Maven
> >
> > Regards,
> >
> > Hervé
> >
> > [1]
> > http://maven.apache.org/ref/3.2.1/maven-plugin-api/source-repository.html>
> > Le vendredi 21 mars 2014 11:46:12 Olivier Lamy a écrit :
> >> that's default inheritance from svn heritage :-)
> >>
> >> use https://git-wip-us.apache.org/repos/asf?p=maven-scm.git
> >>
> >> On 21 March 2014 11:41, Chris Graham wrote:
> >> > Hi All.
> >> >
> >> > In looking at:
> >> >
> >> > http://maven.apache.org/scm/maven-scm-plugin/source-repository.html
> >> >
> >> > I can wee the Web Access link as:
> >> >
> >> > https://git-wip-us.apache.org/repos/asf?p=maven-scm.git/maven-scm-plugi
> >> > n
> >> >
> >> > but it returns a 404!
> >> >
> >> > What is it meant to be?
> >> >
> >> > -Chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: SCM Web URL?
On 21 March 2014 22:31, Hervé BOUTEMY wrote:
> I'm not in phase with such analysis
>
> that's:
> 1. something logic: if you have ${url} for a path, ${url}/sub-directory is
> expected for the url to the sub-directory. Anything more complex should be
> avoided as much as possible. POM inheritance actually only supports this
> simple (yet sensible) algorithm.
>
> 2. it works for svnview, viewvc, Fisheye, github and a lot of other web access
> tools, but not for gitview as configured at ASF (gitview can support it, I
> found documentation)
>
>
> As reported on the list a few monthes ago (the intent was to discuss about it,
> but I got no reply), on Maven core, I configured github mirror [1]
Yup configuring to use github mirror is a good idea.
We could do that for all?
>
> We had multiple options:
> - do such github mirror link for every Maven component migrating to git
> - work with ASF infra (don't know who precisely) to see if ASF gitview
> configuration could be improved to support such feature
>
> Since there was no reply and I could not make a decision by myself, I
> considered nobody was interested in improving git support for Maven
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/ref/3.2.1/maven-plugin-api/source-repository.html
>
> Le vendredi 21 mars 2014 11:46:12 Olivier Lamy a écrit :
>> that's default inheritance from svn heritage :-)
>>
>> use https://git-wip-us.apache.org/repos/asf?p=maven-scm.git
>>
>> On 21 March 2014 11:41, Chris Graham wrote:
>> > Hi All.
>> >
>> > In looking at:
>> >
>> > http://maven.apache.org/scm/maven-scm-plugin/source-repository.html
>> >
>> > I can wee the Web Access link as:
>> >
>> > https://git-wip-us.apache.org/repos/asf?p=maven-scm.git/maven-scm-plugin
>> >
>> > but it returns a 404!
>> >
>> > What is it meant to be?
>> >
>> > -Chris
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: git commit: [MNG-5608] added a warning on ${project.basedir} use for profile activation
ok, I'll have a look to try to move code
Regards,
Hervé
Le lundi 24 mars 2014 19:14:02 Robert Scholte a écrit :
> In fact, a ModelValidator validates both the rawModel and effectiveModel[1]
>
> regards,
> Robert
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-bui
> lder/src/main/java/org/apache/maven/model/validation/ModelValidator.java;h=3
> 4bd97a5dc3d0a2d5f694d069ab80328d4adee1c;hb=HEAD1
>
> Op Mon, 24 Mar 2014 00:20:06 +0100 schreef Hervé BOUTEMY
>
> :
> > I don't think so: DefaultModelValidator is the *effective model*
> > validator
> > It contains validations that happen when everything is done: it's too
> > late for
> > profile activation controls
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 23 mars 2014 20:29:42 Robert Scholte a écrit :
> >> Hi Hervé,
> >>
> >> I think this should have been fixed in the
> >> org.apache.maven.model.validation.DefaultModelValidator.
> >> That's the location where all these kinds of validations are done.
> >> A ProfileActivator has only one task: Determines whether the specified
> >> profile is active in the given activator context.
> >>
> >> regards,
> >> Robert
> >>
> >> Op Sun, 23 Mar 2014 19:58:28 +0100 schreef :
> >> > Repository: maven
> >> >
> >> > Updated Branches:
> >> > refs/heads/master 3c7744a9a -> 64c419506
> >> >
> >> > [MNG-5608] added a warning on ${project.basedir} use for profile
> >> > activation
> >> >
> >> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> >> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/64c41950
> >> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/64c41950
> >> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/64c41950
> >> >
> >> > Branch: refs/heads/master
> >> > Commit: 64c41950671b6b5472532cd2e34f28fff17c5fee
> >> > Parents: 3c7744a
> >> > Author: Hervé Boutemy
> >> > Authored: Sun Mar 23 19:58:26 2014 +0100
> >> > Committer: Hervé Boutemy
> >> > Committed: Sun Mar 23 19:58:26 2014 +0100
> >> >
> >> > --
> >> >
> >> > .../maven/model/profile/activation/FileProfileActivator.java | 8
> >> >
> >> >
> >> >
> >> > 1 file changed, 8 insertions(+)
> >> >
> >> > --
> >>
> >> http://git-wip-us.apache.org/repos/asf/maven/blob/64c41950/maven-model-bu
> >> i
> >>
> >> lder/src/main/java/org/apache/maven/model/profile/activation/FileProfileA
> >> c
> >>
> >> > tivator.java
> >> > --
> >> > diff --git
> >>
> >> a/maven-model-builder/src/main/java/org/apache/maven/model/profile/activa
> >> t
> >>
> >> > ion/FileProfileActivator.java
> >>
> >> b/maven-model-builder/src/main/java/org/apache/maven/model/profile/activa
> >>
> >> > tion/FileProfileActivator.java index 039c37b..ae20762 100644
> >> > ---
> >>
> >> a/maven-model-builder/src/main/java/org/apache/maven/model/profile/activa
> >> t
> >>
> >> > ion/FileProfileActivator.java +++
> >>
> >> b/maven-model-builder/src/main/java/org/apache/maven/model/profile/activa
> >> t
> >>
> >> > ion/FileProfileActivator.java @@ -116,6 +116,14 @@ public class
> >> > FileProfileActivator
> >> >
> >> > return null;
> >> >
> >> > }
> >> >
> >> > } );
> >> >
> >> > +
> >> > +if ( path.contains( "${project.basedir}" ) )
> >> > +{
> >> > +problems.add( new ModelProblemCollectorRequest(
> >> > Severity.WARNING, Version.BASE )
> >> > +.setMessage( "Failed to interpolate file
> >> > location " + path + " for profile " + profile.getId() + ":
> >> > ${project.basedir} expression not supported during profile activation,
> >> > use ${basedir} instead" )
> >> > +.setLocation( file.getLocation( missing ?
> >> > "missing" : "exists" ) ) );
> >> > +}
> >> > +
> >> >
> >> > }
> >> > else if ( path.contains( "${basedir}" ) )
> >> > {
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.2.1 release notes
Fat fingers. I meant to say a single curated set of release notes. On Mar 24, 2014, at 3:49 PM, Olivier Lamy wrote: > so need some work. > The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 > release notes has been made using markdown. > If someone has idea go for it (ATM I don't have enough time for that). > > Cheers > Olivier > > On 25 March 2014 09:27, Olivier Lamy wrote: >> working on fixing that. >> As the format has changed (apt -> md) the velocity script cannot see it. >> >> On 25 March 2014 08:45, Andrew Holland wrote: >>> Hi, >>> >>> Maven 3.2.1 release notes seem to be missing from >>> http://maven.apache.org/release-notes-all.html >>> >>> Regards >>> >>> Andy >> >> >> >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Maven 3.2.1 release notes
How about moving to a single curating release notes file with the latest version at the top. The aggregation of the release notes from all over the place is a little funky. I would vote for removing the magic and just use a single well-crafted file describing all the releases. On Mar 24, 2014, at 3:49 PM, Olivier Lamy wrote: > so need some work. > The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 > release notes has been made using markdown. > If someone has idea go for it (ATM I don't have enough time for that). > > Cheers > Olivier > > On 25 March 2014 09:27, Olivier Lamy wrote: >> working on fixing that. >> As the format has changed (apt -> md) the velocity script cannot see it. >> >> On 25 March 2014 08:45, Andrew Holland wrote: >>> Hi, >>> >>> Maven 3.2.1 release notes seem to be missing from >>> http://maven.apache.org/release-notes-all.html >>> >>> Regards >>> >>> Andy >> >> >> >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Model Version 5.0.0
Hello, it is not yet finished, and I am not sure if it actually would work for most scenarios. But I was starting a plugin which allows to maintain and create a "checksum lock file" for dependencies. The basic idea is, that when I distribute a released maven project (source) via for example Git, I want to enable the builders to check if they are actually using the same dependencies than I was locking. https://github.com/ecki/lockdep-maven-plugin This is somewhat inspired by this: https://github.com/nicoulaj/checksum-maven-plugin The idea is especially to catch overwritten repository releases and rough proxies. With the extra lock file it should be easier to adopt to new versions. Greetings Bernd Am Mon, 24 Mar 2014 11:19:30 +0100 schrieb Baptiste Mathus : > Hi, > > Sorry if it's the wrong thread, just let me know. > > I thought I'd dump that thought I've had for some time here: was > enriching a bit the block already discussed? > > So that one can somehow express a tag. I'm posting this > here since this would also require a pom upgrade. > I've re-read the recent threads but didn't find anything about it. > Also crawled JIRA without luck (though I guess this has already been > reported somewhere). > > Something like > > ** > * ...* > * ...* > * ...* > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > ** > > WDYT? > > Cheers > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte : > > > Hi, > > > > I think this is good start and I would expect that the planned > > consumer pom.xml would still validate against the model 4.0.0 xsd, > > since now it is the standard file being uploaded and used by a lot > > of build management tools. > > If there are some flaws in the current XML, this could be the right > > moment to design a new consumer specific XML, maybe together with > > the Aether team for example. > > > > Robert > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > stephen.alan.conno...@gmail.com>: > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. > > What we/I > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > >> inheritance interpolated and properties resolved > >> > >> On Tuesday, 25 February 2014, Jörg Hohwiller > >> wrote: > >> > >> Hi there, > >>> > >>> just for the record to this thread: > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > >>> The plugin allows to generate a consumer POM and apply it to the > >>> current MavenProject (via setFile). > >>> So we can already test various impacts of what can, will and > >>> should happen > >>> when a "consumer POM" is installed, signed, deployed instead of > >>> the original pom.xml file that can later on be in future model > >>> formats. > >>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added > >>> to sandbox". > >>> Hope to hear from you. > >>> > >>> Kind regards > >>> Jörg > >>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > >>> > >>> On 25 November 2013 03:28, Stephen Connolly > wrote: > [del] > > Given that we have decided that the reporting stuff possibly > was a > > mistake... Well let's drop that > > > > Given that profiles do not make sense in deployed poms... Drop > > them too > > > > We think is evil... Let's drop that... We've > > dropped build > > and reporting=> no need for pluginRepositories at all so. > > > > I'm in favour of cleaning out elements that cause problems > > when they > are tweaked in a the non-Maven Way. > The emails to the users list would be reduce and there is less > chance of causing confusion. > > Applying the "current" best practises and baking them into the > poms is a good thing. > > > > >>> > >>> > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.2.1 release notes
so need some work. The release-notes-all.apt.vm expect to parse apt file but the 3.2.1 release notes has been made using markdown. If someone has idea go for it (ATM I don't have enough time for that). Cheers Olivier On 25 March 2014 09:27, Olivier Lamy wrote: > working on fixing that. > As the format has changed (apt -> md) the velocity script cannot see it. > > On 25 March 2014 08:45, Andrew Holland wrote: >> Hi, >> >> Maven 3.2.1 release notes seem to be missing from >> http://maven.apache.org/release-notes-all.html >> >> Regards >> >> Andy > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.2.1 release notes
working on fixing that. As the format has changed (apt -> md) the velocity script cannot see it. On 25 March 2014 08:45, Andrew Holland wrote: > Hi, > > Maven 3.2.1 release notes seem to be missing from > http://maven.apache.org/release-notes-all.html > > Regards > > Andy -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3.2.1 release notes
Hi, Maven 3.2.1 release notes seem to be missing from http://maven.apache.org/release-notes-all.html Regards Andy
Re: [VOTE] Retire Maven Reactor Plugin
+1 Best regards / Met vriendelijke groet, Kees van Dieren Squins IT Solutions BV Oranjestraat 30 2983 HS Ridderkerk The Netherlands Mobile: +31 (0)6 30413841 www.squins.com Chamber of commerce Rotterdam: 24435103 2014-03-22 22:52 GMT+01:00 Karl Heinz Marbaise : > Hi, > > based on the decision we have made on the 18. february 2014 to define End > Of Life of Maven 2 http://maven.apache.org/maven-2.x-eol.html > > I would suggest to retire the Maven Reactor Plugin. > The last release has been made on 23rd of september 2008 version 1.0. > > Apart from that the complete functionality is now part of Maven 3. > > I therefor propose that we retire maven-foo-plugin. > > If this vote is successful I will make one final release of the plugin, > making it clear on the plugin site that it has been retired. After that the > source code will be moved into the "retired" area in Subversion. > > The process for retiring a plugin is described here: > http://maven.apache.org/developers/retirement-plan-plugins.html > > The vote is open for 72 hours. > > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > Kind regards > Karl-Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Model Version 5.0.0
On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I see the checksums then as being another potential side artifact... No > need for modelVersion 5.0.0 > I see it differently: the checksum validates the GAV coordinates. "I mean 'com.example.foo:foo:1.0', specifically verify that it matches this signature 'sha1:1234567890abcdef'. For example, this enables me to check if a different version of an artefact was uploaded to the same GAV than I expected (and reportedly the original author too). A plugin right now could capture them and deploy to repo, and you could > have same plugin verify the resolved dependencies against the same file. > This assumes the whole chain of parties is to be trusted. That nobody will try to side-load a version from a different repository. I find the idea of adding a checksum to a dependency interesting. While I don't care for the extra fields in the POM, it opens a better venue of vetting the dependencies. Martijn
Re: [RESULT] [VOTE] Retire Maven Reactor Plugin
Hi, sorry i missed Robert Scholte +1 (binding)... Kind regards Karl-Heinz Marbaise On 3/24/14 12:11 PM, Karl Heinz Marbaise wrote: Hi, the vote has passed with the following results: +1 (binding): Hervé Boutemy, Olivier Lamy, Kristian Rosenvold, Stephen Connolly, Stephane Nicoll, +1 (non binding): Mirko Friedenhagen, Jason van Zyl, Toni Chemit, Anders Hammar, Dominik Bartholdi I will continue with the steps required to retire this plugin. Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Model Version 5.0.0
I see the checksums then as being another potential side artifact... No need for modelVersion 5.0.0 A plugin right now could capture them and deploy to repo, and you could have same plugin verify the resolved dependencies against the same file. On Monday, 24 March 2014, Baptiste Mathus > wrote: > I guess if you manage to lose your repo, there could be either a special > switch to disable it, or maybe better, being able to fix selectively those > exceptions in *your* pom like you currently do for versions of a > transitively retrieved artifact. > > > Why > > I'd say because you'd like to prevent some kind or AIDM attack (Artifact In > The Middle ;-)), which you're currently unable to detect if the upstream > repo has been hacked? > > Not saying this is something that *must* be there in M4 or so, but I guess > this would be cool for Maven to be able to support that kind of use-case. > > I'm not paranoid myself, but I guess there's a lot of companies that would > like this feature (when you see how much Sonatype invested in > security/blabla detection for nexus, I guess that's because it's somehow > been asked by some customers. Note I don't count myself in them.). > > But maybe this isn't something that should go in the block, > but in a dedicated plugin. The thing is, you then fall back again on the > problem of DRY having to somehow repeat GAV coordinates somewhere to > describe that additional metadata. > > Anyway, I find it at least interesting to have that debate. > > 2014-03-24 12:23 GMT+01:00 Stephen Connolly < > stephen.alan.conno...@gmail.com > >: > > > Why? Sounds like just one more thing that could go wrong, plus if you > lost > > your repo and are rebuilding all from source because the timestamps will > > differ, so the .zip checksums will differ too > > > > On Monday, 24 March 2014, Baptiste Mathus wrote: > > > > > Hi, > > > > > > Sorry if it's the wrong thread, just let me know. > > > > > > I thought I'd dump that thought I've had for some time here: was > > enriching > > > a bit the block already discussed? > > > > > > So that one can somehow express a tag. I'm posting this here > > > since this would also require a pom upgrade. > > > I've re-read the recent threads but didn't find anything about it. Also > > > crawled JIRA without luck (though I guess this has already been > reported > > > somewhere). > > > > > > Something like > > > > > > ** > > > * ...* > > > * ...* > > > * ...* > > > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > > > ** > > > > > > WDYT? > > > > > > Cheers > > > > > > > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte > > > > >: > > > > > > > Hi, > > > > > > > > I think this is good start and I would expect that the planned > consumer > > > > pom.xml would still validate against the model 4.0.0 xsd, since now > it > > is > > > > the standard file being uploaded and used by a lot of build > management > > > > tools. > > > > If there are some flaws in the current XML, this could be the right > > > moment > > > > to design a new consumer specific XML, maybe together with the Aether > > > team > > > > for example. > > > > > > > > Robert > > > > > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > > > stephen.alan.conno...@gmail.com >: > > > > > > > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What > > > we/I > > > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > > > >> inheritance interpolated and properties resolved > > > >> > > > >> On Tuesday, 25 February 2014, Jörg Hohwiller > > > > > > > > >> wrote: > > > >> > > > >> Hi there, > > > >>> > > > >>> just for the record to this thread: > > > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > > > >>> The plugin allows to generate a consumer POM and apply it to the > > > current > > > >>> MavenProject (via setFile). > > > >>> So we can already test various impacts of what can, will and should > > > >>> happen > > > >>> when a "consumer POM" is installed, signed, deployed instead of the > > > >>> original pom.xml file that can later on be in future model formats. > > > >>> > > > >>> See thread on dev mojo with subject "consumer-maven-plugin added to > > > >>> sandbox". > > > >>> Hope to hear from you. > > > >>> > > > >>> Kind regards > > > >>> Jörg > > > >>> > > > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > > > >>> > > > >>> On 25 November 2013 03:28, Stephen Connolly > > > > wrote: > > > [del] > > > > > > Given that we have decided that the reporting stuff possibly was > a > > > > mistake... Well let's drop that > > > > > > > > Given that profiles do not make sense in deployed poms... Drop > them > > > too > > > > > > > > We think is evil... Let's drop that... We've > dropped > > > > build > > > > and reporting=> no need for pluginRepositories at all so. > > > > > > > > I'm in favour of cleaning out elements that cause problems when > > they > > > are
Re: Model Version 5.0.0
On Mon, Mar 24, 2014 at 7:29 PM, Robert Scholte wrote: > I have to admit I have never used it, but aren't the -c / -C Maven > commandline options meant for this? > Only if you trust the repository where you get the checksums from. The idea advocated by Baptiste is that as a project owner you specify not only which GAV you require but also the checksum of a dependency: this way you can retrieve the checksum from the original project and make sure everybody gets the 'official' version. This also ensures that nobody can tamper with uploading a new version to a repository under the same GAV. Now probably this will not be very practical to introduce on a large project (try to find the correct signatures for each dependency in for example a standard Maven build for a hello world application), but for some venues this might actually make sense-where security and accountability is paramount. Martijn
Re: Model Version 5.0.0
I have to admit I have never used it, but aren't the -c / -C Maven commandline options meant for this? Robert Op Mon, 24 Mar 2014 13:33:11 +0100 schreef Baptiste Mathus : I guess if you manage to lose your repo, there could be either a special switch to disable it, or maybe better, being able to fix selectively those exceptions in *your* pom like you currently do for versions of a transitively retrieved artifact. Why I'd say because you'd like to prevent some kind or AIDM attack (Artifact In The Middle ;-)), which you're currently unable to detect if the upstream repo has been hacked? Not saying this is something that *must* be there in M4 or so, but I guess this would be cool for Maven to be able to support that kind of use-case. I'm not paranoid myself, but I guess there's a lot of companies that would like this feature (when you see how much Sonatype invested in security/blabla detection for nexus, I guess that's because it's somehow been asked by some customers. Note I don't count myself in them.). But maybe this isn't something that should go in the block, but in a dedicated plugin. The thing is, you then fall back again on the problem of DRY having to somehow repeat GAV coordinates somewhere to describe that additional metadata. Anyway, I find it at least interesting to have that debate. 2014-03-24 12:23 GMT+01:00 Stephen Connolly : Why? Sounds like just one more thing that could go wrong, plus if you lost your repo and are rebuilding all from source because the timestamps will differ, so the .zip checksums will differ too On Monday, 24 March 2014, Baptiste Mathus wrote: > Hi, > > Sorry if it's the wrong thread, just let me know. > > I thought I'd dump that thought I've had for some time here: was enriching > a bit the block already discussed? > > So that one can somehow express a tag. I'm posting this here > since this would also require a pom upgrade. > I've re-read the recent threads but didn't find anything about it. Also > crawled JIRA without luck (though I guess this has already been reported > somewhere). > > Something like > > ** > * ...* > * ...* > * ...* > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > ** > > WDYT? > > Cheers > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte > >: > > > Hi, > > > > I think this is good start and I would expect that the planned consumer > > pom.xml would still validate against the model 4.0.0 xsd, since now it is > > the standard file being uploaded and used by a lot of build management > > tools. > > If there are some flaws in the current XML, this could be the right > moment > > to design a new consumer specific XML, maybe together with the Aether > team > > for example. > > > > Robert > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > stephen.alan.conno...@gmail.com >: > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What > we/I > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > >> inheritance interpolated and properties resolved > >> > >> On Tuesday, 25 February 2014, Jörg Hohwiller > > > >> wrote: > >> > >> Hi there, > >>> > >>> just for the record to this thread: > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > >>> The plugin allows to generate a consumer POM and apply it to the > current > >>> MavenProject (via setFile). > >>> So we can already test various impacts of what can, will and should > >>> happen > >>> when a "consumer POM" is installed, signed, deployed instead of the > >>> original pom.xml file that can later on be in future model formats. > >>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added to > >>> sandbox". > >>> Hope to hear from you. > >>> > >>> Kind regards > >>> Jörg > >>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > >>> > >>> On 25 November 2013 03:28, Stephen Connolly > > wrote: > [del] > > Given that we have decided that the reporting stuff possibly was a > > mistake... Well let's drop that > > > > Given that profiles do not make sense in deployed poms... Drop them > too > > > > We think is evil... Let's drop that... We've dropped > > build > > and reporting=> no need for pluginRepositories at all so. > > > > I'm in favour of cleaning out elements that cause problems when they > are tweaked in a the non-Maven Way. > The emails to the users list would be reduce and there is less chance > of causing confusion. > > Applying the "current" best practises and baking them into the poms is > a good thing. > > > > >>> > >>> > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor
Re: git commit: [MNG-5608] added a warning on ${project.basedir} use for profile activation
In fact, a ModelValidator validates both the rawModel and effectiveModel[1]
regards,
Robert
[1]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/validation/ModelValidator.java;h=34bd97a5dc3d0a2d5f694d069ab80328d4adee1c;hb=HEAD1
Op Mon, 24 Mar 2014 00:20:06 +0100 schreef Hervé BOUTEMY
:
I don't think so: DefaultModelValidator is the *effective model*
validator
It contains validations that happen when everything is done: it's too
late for
profile activation controls
Regards,
Hervé
Le dimanche 23 mars 2014 20:29:42 Robert Scholte a écrit :
Hi Hervé,
I think this should have been fixed in the
org.apache.maven.model.validation.DefaultModelValidator.
That's the location where all these kinds of validations are done.
A ProfileActivator has only one task: Determines whether the specified
profile is active in the given activator context.
regards,
Robert
Op Sun, 23 Mar 2014 19:58:28 +0100 schreef :
> Repository: maven
>
> Updated Branches:
> refs/heads/master 3c7744a9a -> 64c419506
>
> [MNG-5608] added a warning on ${project.basedir} use for profile
> activation
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/64c41950
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/64c41950
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/64c41950
>
> Branch: refs/heads/master
> Commit: 64c41950671b6b5472532cd2e34f28fff17c5fee
> Parents: 3c7744a
> Author: Hervé Boutemy
> Authored: Sun Mar 23 19:58:26 2014 +0100
> Committer: Hervé Boutemy
> Committed: Sun Mar 23 19:58:26 2014 +0100
>
> --
>
> .../maven/model/profile/activation/FileProfileActivator.java | 8
>
>
>
> 1 file changed, 8 insertions(+)
>
> --
>
>
>
http://git-wip-us.apache.org/repos/asf/maven/blob/64c41950/maven-model-bui
>
lder/src/main/java/org/apache/maven/model/profile/activation/FileProfileAc
> tivator.java
> --
> diff --git
>
a/maven-model-builder/src/main/java/org/apache/maven/model/profile/activat
> ion/FileProfileActivator.java
>
b/maven-model-builder/src/main/java/org/apache/maven/model/profile/activa
> tion/FileProfileActivator.java index 039c37b..ae20762 100644
> ---
>
a/maven-model-builder/src/main/java/org/apache/maven/model/profile/activat
> ion/FileProfileActivator.java +++
>
b/maven-model-builder/src/main/java/org/apache/maven/model/profile/activat
> ion/FileProfileActivator.java @@ -116,6 +116,14 @@ public class
> FileProfileActivator
>
> return null;
>
> }
>
> } );
>
> +
> +if ( path.contains( "${project.basedir}" ) )
> +{
> +problems.add( new ModelProblemCollectorRequest(
> Severity.WARNING, Version.BASE )
> +.setMessage( "Failed to interpolate file
> location " + path + " for profile " + profile.getId() + ":
> ${project.basedir} expression not supported during profile activation,
> use ${basedir} instead" )
> +.setLocation( file.getLocation( missing ?
> "missing" : "exists" ) ) );
> +}
> +
>
> }
> else if ( path.contains( "${basedir}" ) )
> {
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Model Version 5.0.0
I guess if you manage to lose your repo, there could be either a special switch to disable it, or maybe better, being able to fix selectively those exceptions in *your* pom like you currently do for versions of a transitively retrieved artifact. > Why I'd say because you'd like to prevent some kind or AIDM attack (Artifact In The Middle ;-)), which you're currently unable to detect if the upstream repo has been hacked? Not saying this is something that *must* be there in M4 or so, but I guess this would be cool for Maven to be able to support that kind of use-case. I'm not paranoid myself, but I guess there's a lot of companies that would like this feature (when you see how much Sonatype invested in security/blabla detection for nexus, I guess that's because it's somehow been asked by some customers. Note I don't count myself in them.). But maybe this isn't something that should go in the block, but in a dedicated plugin. The thing is, you then fall back again on the problem of DRY having to somehow repeat GAV coordinates somewhere to describe that additional metadata. Anyway, I find it at least interesting to have that debate. 2014-03-24 12:23 GMT+01:00 Stephen Connolly : > Why? Sounds like just one more thing that could go wrong, plus if you lost > your repo and are rebuilding all from source because the timestamps will > differ, so the .zip checksums will differ too > > On Monday, 24 March 2014, Baptiste Mathus wrote: > > > Hi, > > > > Sorry if it's the wrong thread, just let me know. > > > > I thought I'd dump that thought I've had for some time here: was > enriching > > a bit the block already discussed? > > > > So that one can somehow express a tag. I'm posting this here > > since this would also require a pom upgrade. > > I've re-read the recent threads but didn't find anything about it. Also > > crawled JIRA without luck (though I guess this has already been reported > > somewhere). > > > > Something like > > > > ** > > * ...* > > * ...* > > * ...* > > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > > ** > > > > WDYT? > > > > Cheers > > > > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte > > >: > > > > > Hi, > > > > > > I think this is good start and I would expect that the planned consumer > > > pom.xml would still validate against the model 4.0.0 xsd, since now it > is > > > the standard file being uploaded and used by a lot of build management > > > tools. > > > If there are some flaws in the current XML, this could be the right > > moment > > > to design a new consumer specific XML, maybe together with the Aether > > team > > > for example. > > > > > > Robert > > > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > > stephen.alan.conno...@gmail.com >: > > > > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What > > we/I > > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > > >> inheritance interpolated and properties resolved > > >> > > >> On Tuesday, 25 February 2014, Jörg Hohwiller > > > > > >> wrote: > > >> > > >> Hi there, > > >>> > > >>> just for the record to this thread: > > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > > >>> The plugin allows to generate a consumer POM and apply it to the > > current > > >>> MavenProject (via setFile). > > >>> So we can already test various impacts of what can, will and should > > >>> happen > > >>> when a "consumer POM" is installed, signed, deployed instead of the > > >>> original pom.xml file that can later on be in future model formats. > > >>> > > >>> See thread on dev mojo with subject "consumer-maven-plugin added to > > >>> sandbox". > > >>> Hope to hear from you. > > >>> > > >>> Kind regards > > >>> Jörg > > >>> > > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > > >>> > > >>> On 25 November 2013 03:28, Stephen Connolly > > > wrote: > > [del] > > > > Given that we have decided that the reporting stuff possibly was a > > > mistake... Well let's drop that > > > > > > Given that profiles do not make sense in deployed poms... Drop them > > too > > > > > > We think is evil... Let's drop that... We've dropped > > > build > > > and reporting=> no need for pluginRepositories at all so. > > > > > > I'm in favour of cleaning out elements that cause problems when > they > > are tweaked in a the non-Maven Way. > > The emails to the users list would be reduce and there is less > chance > > of causing confusion. > > > > Applying the "current" best practises and baking them into the poms > is > > a good thing. > > > > > > > > >>> > > >>> > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > -- > > Baptiste MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un
Re: Model Version 5.0.0
2014-03-24 12:52 GMT+01:00 Gary Gregory : > You'd need a checksum for jar, javadoc, sources and so on. Also what about > md5 vs sha1? > Well. For javadoc and sources I don't see really the need, though granted it might be half-baked to not be able to handle these if we realize we actually need them afterwards. (And now that I come to think of it, tools like GWT actually only really need sources and not jars... Right). About sha1 vs. md5, that's why I proposed a construct in the same vein of the scm *connection tag : hashAlgorithm:hash sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62 > > Gary > > Original message > From: Baptiste Mathus > Date:03/24/2014 06:19 (GMT-05:00) > To: Maven Developers List > Subject: Re: Model Version 5.0.0 > > Hi, > > Sorry if it's the wrong thread, just let me know. > > I thought I'd dump that thought I've had for some time here: was enriching > a bit the block already discussed? > > So that one can somehow express a tag. I'm posting this here > since this would also require a pom upgrade. > I've re-read the recent threads but didn't find anything about it. Also > crawled JIRA without luck (though I guess this has already been reported > somewhere). > > Something like > > ** > * ...* > * ...* > * ...* > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > ** > > WDYT? > > Cheers > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte : > > > Hi, > > > > I think this is good start and I would expect that the planned consumer > > pom.xml would still validate against the model 4.0.0 xsd, since now it is > > the standard file being uploaded and used by a lot of build management > > tools. > > If there are some flaws in the current XML, this could be the right > moment > > to design a new consumer specific XML, maybe together with the Aether > team > > for example. > > > > Robert > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > stephen.alan.conno...@gmail.com>: > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What > we/I > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > >> inheritance interpolated and properties resolved > >> > >> On Tuesday, 25 February 2014, Jörg Hohwiller > >> wrote: > >> > >> Hi there, > >>> > >>> just for the record to this thread: > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > >>> The plugin allows to generate a consumer POM and apply it to the > current > >>> MavenProject (via setFile). > >>> So we can already test various impacts of what can, will and should > >>> happen > >>> when a "consumer POM" is installed, signed, deployed instead of the > >>> original pom.xml file that can later on be in future model formats. > >>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added to > >>> sandbox". > >>> Hope to hear from you. > >>> > >>> Kind regards > >>> Jörg > >>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > >>> > >>> On 25 November 2013 03:28, Stephen Connolly > wrote: > [del] > > Given that we have decided that the reporting stuff possibly was a > > mistake... Well let's drop that > > > > Given that profiles do not make sense in deployed poms... Drop them > too > > > > We think is evil... Let's drop that... We've dropped > > build > > and reporting=> no need for pluginRepositories at all so. > > > > I'm in favour of cleaning out elements that cause problems when they > are tweaked in a the non-Maven Way. > The emails to the users list would be reduce and there is less chance > of causing confusion. > > Applying the "current" best practises and baking them into the poms is > a good thing. > > > > >>> > >>> > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Model Version 5.0.0
You'd need a checksum for jar, javadoc, sources and so on. Also what about md5 vs sha1? Gary Original message From: Baptiste Mathus Date:03/24/2014 06:19 (GMT-05:00) To: Maven Developers List Subject: Re: Model Version 5.0.0 Hi, Sorry if it's the wrong thread, just let me know. I thought I'd dump that thought I've had for some time here: was enriching a bit the block already discussed? So that one can somehow express a tag. I'm posting this here since this would also require a pom upgrade. I've re-read the recent threads but didn't find anything about it. Also crawled JIRA without luck (though I guess this has already been reported somewhere). Something like ** * ...* * ...* * ...* * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* ** WDYT? Cheers 2014-02-26 21:50 GMT+01:00 Robert Scholte : > Hi, > > I think this is good start and I would expect that the planned consumer > pom.xml would still validate against the model 4.0.0 xsd, since now it is > the standard file being uploaded and used by a lot of build management > tools. > If there are some flaws in the current XML, this could be the right moment > to design a new consumer specific XML, maybe together with the Aether team > for example. > > Robert > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > stephen.alan.conno...@gmail.com>: > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What we/I >> want from a consumer pom is more than modelVersion 4.0.0 pom with >> inheritance interpolated and properties resolved >> >> On Tuesday, 25 February 2014, Jörg Hohwiller >> wrote: >> >> Hi there, >>> >>> just for the record to this thread: >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. >>> The plugin allows to generate a consumer POM and apply it to the current >>> MavenProject (via setFile). >>> So we can already test various impacts of what can, will and should >>> happen >>> when a "consumer POM" is installed, signed, deployed instead of the >>> original pom.xml file that can later on be in future model formats. >>> >>> See thread on dev mojo with subject "consumer-maven-plugin added to >>> sandbox". >>> Hope to hear from you. >>> >>> Kind regards >>> Jörg >>> >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: >>> >>> On 25 November 2013 03:28, Stephen Connolly wrote: [del] Given that we have decided that the reporting stuff possibly was a > mistake... Well let's drop that > > Given that profiles do not make sense in deployed poms... Drop them too > > We think is evil... Let's drop that... We've dropped > build > and reporting=> no need for pluginRepositories at all so. > > I'm in favour of cleaning out elements that cause problems when they are tweaked in a the non-Maven Way. The emails to the users list would be reduce and there is less chance of causing confusion. Applying the "current" best practises and baking them into the poms is a good thing. >>> >>> > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Model Version 5.0.0
Why? Sounds like just one more thing that could go wrong, plus if you lost your repo and are rebuilding all from source because the timestamps will differ, so the .zip checksums will differ too On Monday, 24 March 2014, Baptiste Mathus wrote: > Hi, > > Sorry if it's the wrong thread, just let me know. > > I thought I'd dump that thought I've had for some time here: was enriching > a bit the block already discussed? > > So that one can somehow express a tag. I'm posting this here > since this would also require a pom upgrade. > I've re-read the recent threads but didn't find anything about it. Also > crawled JIRA without luck (though I guess this has already been reported > somewhere). > > Something like > > ** > * ...* > * ...* > * ...* > * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* > ** > > WDYT? > > Cheers > > > 2014-02-26 21:50 GMT+01:00 Robert Scholte > >: > > > Hi, > > > > I think this is good start and I would expect that the planned consumer > > pom.xml would still validate against the model 4.0.0 xsd, since now it is > > the standard file being uploaded and used by a lot of build management > > tools. > > If there are some flaws in the current XML, this could be the right > moment > > to design a new consumer specific XML, maybe together with the Aether > team > > for example. > > > > Robert > > > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > > stephen.alan.conno...@gmail.com >: > > > > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What > we/I > >> want from a consumer pom is more than modelVersion 4.0.0 pom with > >> inheritance interpolated and properties resolved > >> > >> On Tuesday, 25 February 2014, Jörg Hohwiller > >> > > > >> wrote: > >> > >> Hi there, > >>> > >>> just for the record to this thread: > >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. > >>> The plugin allows to generate a consumer POM and apply it to the > current > >>> MavenProject (via setFile). > >>> So we can already test various impacts of what can, will and should > >>> happen > >>> when a "consumer POM" is installed, signed, deployed instead of the > >>> original pom.xml file that can later on be in future model formats. > >>> > >>> See thread on dev mojo with subject "consumer-maven-plugin added to > >>> sandbox". > >>> Hope to hear from you. > >>> > >>> Kind regards > >>> Jörg > >>> > >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: > >>> > >>> On 25 November 2013 03:28, Stephen Connolly > > wrote: > [del] > > Given that we have decided that the reporting stuff possibly was a > > mistake... Well let's drop that > > > > Given that profiles do not make sense in deployed poms... Drop them > too > > > > We think is evil... Let's drop that... We've dropped > > build > > and reporting=> no need for pluginRepositories at all so. > > > > I'm in favour of cleaning out elements that cause problems when they > are tweaked in a the non-Maven Way. > The emails to the users list would be reduce and there is less chance > of causing confusion. > > Applying the "current" best practises and baking them into the poms is > a good thing. > > > > >>> > >>> > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > -- Sent from my phone
[RESULT] [VOTE] Retire Maven Reactor Plugin
Hi, the vote has passed with the following results: +1 (binding): Hervé Boutemy, Olivier Lamy, Kristian Rosenvold, Stephen Connolly, Stephane Nicoll, +1 (non binding): Mirko Friedenhagen, Jason van Zyl, Toni Chemit, Anders Hammar, Dominik Bartholdi I will continue with the steps required to retire this plugin. Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Model Version 5.0.0
Hi, Sorry if it's the wrong thread, just let me know. I thought I'd dump that thought I've had for some time here: was enriching a bit the block already discussed? So that one can somehow express a tag. I'm posting this here since this would also require a pom upgrade. I've re-read the recent threads but didn't find anything about it. Also crawled JIRA without luck (though I guess this has already been reported somewhere). Something like ** * ...* * ...* * ...* * sha1:2cfc5458ff56d559316b901a348bbcad01d3ce62* ** WDYT? Cheers 2014-02-26 21:50 GMT+01:00 Robert Scholte : > Hi, > > I think this is good start and I would expect that the planned consumer > pom.xml would still validate against the model 4.0.0 xsd, since now it is > the standard file being uploaded and used by a lot of build management > tools. > If there are some flaws in the current XML, this could be the right moment > to design a new consumer specific XML, maybe together with the Aether team > for example. > > Robert > > Op Wed, 26 Feb 2014 01:59:29 +0100 schreef Stephen Connolly < > stephen.alan.conno...@gmail.com>: > > > That is a modelVersion 4.0.0 consumer pom unless I am mistaken. What we/I >> want from a consumer pom is more than modelVersion 4.0.0 pom with >> inheritance interpolated and properties resolved >> >> On Tuesday, 25 February 2014, Jörg Hohwiller >> wrote: >> >> Hi there, >>> >>> just for the record to this thread: >>> I wrote consumer-maven-plugin and added it to MOJOs sandbox. >>> The plugin allows to generate a consumer POM and apply it to the current >>> MavenProject (via setFile). >>> So we can already test various impacts of what can, will and should >>> happen >>> when a "consumer POM" is installed, signed, deployed instead of the >>> original pom.xml file that can later on be in future model formats. >>> >>> See thread on dev mojo with subject "consumer-maven-plugin added to >>> sandbox". >>> Hope to hear from you. >>> >>> Kind regards >>> Jörg >>> >>> Am 24.11.2013 23:04, schrieb Barrie Treloar: >>> >>> On 25 November 2013 03:28, Stephen Connolly wrote: [del] Given that we have decided that the reporting stuff possibly was a > mistake... Well let's drop that > > Given that profiles do not make sense in deployed poms... Drop them too > > We think is evil... Let's drop that... We've dropped > build > and reporting=> no need for pluginRepositories at all so. > > I'm in favour of cleaning out elements that cause problems when they are tweaked in a the non-Maven Way. The emails to the users list would be reduce and there is less chance of causing confusion. Applying the "current" best practises and baking them into the poms is a good thing. >>> >>> > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: MRELEASE-431
Hi again Robert, I checked in the odd-even module in r1580793 - every feedback/suggestion/... is, as usual, much more than welcome and appreciated :) All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 22, 2014 at 1:10 PM, Robert Scholte wrote: > Hi Simone, > > I've added the projectVersionPolicyId to the releaseDescriptor. We might > need to add dependencyVersionPolicyId, parentVersionPolicyId and > pluginVersionPolicyId in the future as well. > So the manager is ready to switch from implementation, which should be > enough for unittesting. > We still need to make it available for the plugin. > > I think most version policies should have their own project+release-cycle, > but it seems like the odd-even is a common policy, so I don't mind making it > a separate module which will be part of the maven-release project. > We can probably do something like enforcer: make a standard-policies module > with common implementation. > Although for now I wouldn't make it add it as dependency to the manager, > users can do that themselves if they want. > > Robert > > > Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi > : > > >> Hi again Robert, >> >> IIUC the VersionPolicy resolution in `Map >> versionPolicies` is strict to "default" only, moreover I didn't >> understand where/how to specify, in the plugin configuration, the >> `hint` of my VersionPolicy implementation... >> >> As a side note, I already have, in my local copy of the source code, a >> separated module with the odd-even policy implementation, included in >> the build - if there are not objections, I'd commit it, just let me >> know! >> >> All the best! >> -Simo >> http://people.apache.org/~simonetripodi/ >> http://twitter.com/simonetripodi >> >> >> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte >> wrote: >>> >>> Hi Simone, >>> >>> http://svn.apache.org/r1578613 contains the default implementation for >>> the >>> maven-release-manager. >>> Now it should be quite easy to test other policies. >>> >>> thanks, >>> >>> Robert >>> >>> ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) >>> >>> Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi >>> : >>> >>> Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi wrote: > > > Hi Robert, > > yes I agree, while making my prototype - it will be opensourced, by > the way - I also realised that my Policy implementation is the wrong > Maven phase: when asking for the next release version, it is supposed > that current doesn't exist yet (unless someone publishes the SNAPSHOT, > even locally) so artifact diff cannot be executed. > That would force users configuring the release plugin in order to > invoke the `package` first... > > I don't have strong opinions ATM on how the new interface should look > alike... > > Thanks a lot for you efforts! > -Simo > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi > > > On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte > wrote: >> >> >> Hi Simone, >> >> I think what you want is a way to make clear what kind of release it >> will >> be: major, minor, bugfix/micro. >> That's something which can be added to the request and looks >> reasonable >> for >> all policies. I'm not sure if an enum is correct here, any founded >> suggestion is welcome. >> However, the calculation what kind of of release it should be, belongs >> in >> another class in my opinion. >> So let's think of another interface :) >> >> Robert >> >> >> Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi >> : >> >> >>> Hi Rob, >>> >>> thanks a lot for the detailed feedback, very appreciated :) >>> >>> I just realise I didn't pass you enough informations to better >>> understand the new context we are working on: in the OSGi world, >>> aside >>> the odd-even policy, we would like to wrap BND[1] APis which allow >>> compare two bundles and understand, via bytecode analysis[2], which >>> should be the suggested version; that is why I need the >>> ArtifactResolver, in order to get the latest released artifact (or >>> specify the version, somehow) and compare it to the one is going to >>> be >>> released, in order let BND calculate the suggested version. >>> >>> I hope that scenario makes more clea
[CHANGES PLUGIN] 'webUser' is ignored for JIRA report
Hello,
I want to generate a JIRA report using Changes Plugin. I've managed to
re-produce a situation which is contradictory:
1. I use Maven and POM to generate the JIRA report.
2. I checkout 2.9 source and use a JUnit test class to verify.
In case (1), the following Maven configuration is used:
org.apache.maven.plugins
maven-changes-plugin
2.9
true
true
Closed,Resolved
USER
PASS
Then using mvn -X changes:jira-report, I get the following:
---
ID: 2
Address: https://MYJIRA.COM/issuetracker/rest/api/2/status
Http-Method: GET
Content-Type: */*
Headers: {Accept=[application/json], Content-Type=[*/*]}
--
[DEBUG] Accept: application/json
[DEBUG] Content-Type: */*
[DEBUG] No Trust Decider for Conduit
'{https://MYJIRA.COM/issuetracker}WebClient.http-conduit'. An
afirmative Trust Decision is assumed.
[DEBUG] Response Code: 200 Conduit:
{https://MYJIRA.COM/issuetracker}WebClient.http-conduit
[DEBUG] Content length: -1
[DEBUG] Header fields:
null: [HTTP/1.1 200 OK]
Transfer-Encoding: [chunked]
Date: [Mon, 24 Mar 2014 08:23:14 GMT]
Keep-Alive: [timeout=15, max=99]
Via: [1.1 MYJIRA.COM]
Set-Cookie:
[atlassian.xsrf.token=AMUY-0X4J-KTOA-WYA4|faf5142cf78de245e3573fc6cd122b41d1a0fe8e|lout;
Path=/issuetracker]
Connection: [Keep-Alive]
Content-Type: [application/json;charset=UTF-8]
X-AUSERNAME: [anonymous]
X-AREQUESTID: [563x130866x1]
Server: [Apache-Coyote/1.1]
Cache-Control: [no-cache, no-store, no-transform]
[DEBUG] Adding interceptor
org.apache.cxf.interceptor.LoggingInInterceptor@5af3a14 to phase
receive
[DEBUG] Chain org.apache.cxf.phase.PhaseInterceptorChain@574e6595 was
created. Current flow:
receive [LoggingInInterceptor]
[DEBUG] Invoking handleMessage on interceptor
org.apache.cxf.interceptor.LoggingInInterceptor@5af3a14
[INFO] Inbound Message
ID: 2
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: {Cache-Control=[no-cache, no-store, no-transform],
connection=[Keep-Alive],
content-type=[application/json;charset=UTF-8], Date=[Mon, 24 Mar 2014
08:23:14 GMT], Keep-Alive=[timeout=15, max=99],
Server=[Apache-Coyote/1.1],
Set-Cookie=[atlassian.xsrf.token=AMUY-0X4J-KTOA-WYA4|faf5142cf78de245e3573fc6cd122b41d1a0fe8e|lout;
Path=/issuetracker], transfer-encoding=[chunked], Via=[1.1
MYJIRA.COM], X-AREQUESTID=[563x130866x1], X-AUSERNAME=[anonymous]}
Payload: []
In the above note that HTTPS is used, result Payload is empty and "webUser"
is *ignored* (as anonymous) and Authorization Header is missing.
Additionally, Maven ends with the following exception which makes sense
based on the code:
org.apache.maven.plugin.MojoFailureException: Could not find status Closed.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:276)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:253)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:210)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:128)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
In case (2), the source for the plugin version 2.9 is checked out. A simple
unit test is written to simulate the same configuration:
RestJiraDownloader d = new RestJiraDownloader();
Log log = new DefaultLog(new ConsoleLogger(Logger.LEVEL_DEBUG, "test"));
d.setLog(log);
d.project = new MavenProject();
d.project.setIssueManagement(new IssueManagement());
d.project.getIssueManagement().setUrl(
"https://MYJIRA.COM/issuetracker/browse/CSP";);
d.project.getIssueManagement().setSystem("JIRA");
d.setWebUser("USER");
d.setWebPassword("PASS");
d.setUseJql(true);
d.setStatusIds("Resolved,Closed");
Map params = JiraHelper
.getJiraUrlAndProjectName(d.project.getIssueManagement()
.getUrl());
String jiraUrl = params.get("url");
String project = params.get("project");
System.out.println("JIRA: " + jiraUrl + " | project: " + project);
Thread.currentThread().setContextClassLoader(
WebClient.class.getClassLoader());
WebClient client = d.setupWebClient(jiraUrl);
d.doSessionAuth(client);
d.resolveIds(client, project);
System.out.println(d.resolvedStatusIds);
Some small tweaks are made
Re: MRELEASE-431
Hello Robert, thanks a lot for your help, much more than appreciated! > > I've added the projectVersionPolicyId to the releaseDescriptor. We might > need to add dependencyVersionPolicyId, parentVersionPolicyId and > pluginVersionPolicyId in the future as well. > So the manager is ready to switch from implementation, which should be > enough for unittesting. > We still need to make it available for the plugin. > do you already have an idea how? I may can provide a patch for that... > I think most version policies should have their own project+release-cycle, > but it seems like the odd-even is a common policy, so I don't mind making it > a separate module which will be part of the maven-release project. > We can probably do something like enforcer: make a standard-policies module > with common implementation. I am by your side! > Although for now I wouldn't make it add it as dependency to the manager, > users can do that themselves if they want. > +1, I didn't touch indeed anything else than the new module and the reactor indeed, the odd-even policy impl has not to be part of the > Robert All the best, -Simo -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi > > > Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi > : > > >> Hi again Robert, >> >> IIUC the VersionPolicy resolution in `Map >> versionPolicies` is strict to "default" only, moreover I didn't >> understand where/how to specify, in the plugin configuration, the >> `hint` of my VersionPolicy implementation... >> >> As a side note, I already have, in my local copy of the source code, a >> separated module with the odd-even policy implementation, included in >> the build - if there are not objections, I'd commit it, just let me >> know! >> >> All the best! >> -Simo >> http://people.apache.org/~simonetripodi/ >> http://twitter.com/simonetripodi >> >> >> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte >> wrote: >>> >>> Hi Simone, >>> >>> http://svn.apache.org/r1578613 contains the default implementation for >>> the >>> maven-release-manager. >>> Now it should be quite easy to test other policies. >>> >>> thanks, >>> >>> Robert >>> >>> ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) >>> >>> Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi >>> : >>> >>> Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi wrote: > > > Hi Robert, > > yes I agree, while making my prototype - it will be opensourced, by > the way - I also realised that my Policy implementation is the wrong > Maven phase: when asking for the next release version, it is supposed > that current doesn't exist yet (unless someone publishes the SNAPSHOT, > even locally) so artifact diff cannot be executed. > That would force users configuring the release plugin in order to > invoke the `package` first... > > I don't have strong opinions ATM on how the new interface should look > alike... > > Thanks a lot for you efforts! > -Simo > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi > > > On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte > wrote: >> >> >> Hi Simone, >> >> I think what you want is a way to make clear what kind of release it >> will >> be: major, minor, bugfix/micro. >> That's something which can be added to the request and looks >> reasonable >> for >> all policies. I'm not sure if an enum is correct here, any founded >> suggestion is welcome. >> However, the calculation what kind of of release it should be, belongs >> in >> another class in my opinion. >> So let's think of another interface :) >> >> Robert >> >> >> Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi >> : >> >> >>> Hi Rob, >>> >>> thanks a lot for the detailed feedback, very appreciated :) >>> >>> I just realise I didn't pass you enough informations to better >>> understand the new context we are working on: in the OSGi world, >>> aside >>> the odd-even policy, we would like to wrap BND[1] APis which allow >>> compare two bundles and understand, via bytecode analysis[2], which >>> should be the suggested version; that is why I need the >>> ArtifactResolver, in order to get the latest released artifact (or >>> specify the version, somehow) and compare it to the one is going to >>> be >>> released, in order let
[ANN] Apache Maven Shared Jarsigner 1.3.2 Released
The Maven team is pleased to announce the release of the Apache Maven Jarsigner, version 1.3.2 This component provides some utilities to sign/verify jars/files in your Mojos. http://maven.apache.org/shared/maven-jarsigner/ To use the Maven Jarsigner, add the following dependency to your project: org.apache.maven.shared maven-jarsigner 1.3.2 Release Notes - Maven Shared Components - Version maven-jarsigner-1.3.2 ** Bug * [MSHARED-316] - Can not pass storetype nor storepass to a verify request ** Improvement * [MSHARED-321] - Mask passwords in logs ** Task * [MSHARED-322] - Use maven-shared-utils 0.6 Enjoy, -The Maven team tony. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Shared Utils 0.6 released
The Apache Maven team is pleased to announce the release of the
maven-shared-utils, version 0.6
This project aims to be a functional replacement for
{{{http://plexus.codehaus.org/plexus-utils}plexus-utils}} in Maven.
It is not a 100% API compatible replacement though but a replacement
:
lots of methods got cleaned up, generics got added and we dropped a
lot of unused code. Although all
the classes are in different packages from plexus-utils, if the method
is present it will have the same
semantics, facilitating easy conversion.
http://maven.apache.org/shared/maven-shared-utils/
Release Notes - Maven Shared Components - Version maven-shared-utils-0.6
** Improvement
* [MSHARED-320] - Be able to mask some arguments in the commandLine API
Enjoy,
-The Apache Maven team
tony.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Jarsigner Plugin 1.3.2 Released
The Maven team is pleased to announce the release of the Maven Jarsigner Plugin, version 1.3.2. This plugin signs and verifies the project artifacts using the jarsigner tool. See the plugin's site for more details: http://maven.apache.org/plugins/maven-jarsigner-plugin/ This plugin is meant to supercede the existing jar:sign and jar:verify goals from the Maven Jar Plugin which will be deprecated in a future release. To use the updated plugin in your projects, you need to add the following snippet to the plugins or plugin management section of your POM: org.apache.maven.plugins maven-jarsigner-plugin 1.3.2 ... Release Notes - Maven Jar Signer Plugin - Version 1.3.2 ** Bug * [MJARSIGNER-34] - The 'verify' goal of the plugin is passing '-keystore' but not '-storetype'. * [MJARSIGNER-35] - verbose mode shows keystore password in clear text ** Task * [MJARSIGNER-36] - Use maven-shared-utils 0.6 and maven-jarsigner 1.3.2 Enjoy, The Maven team. tony. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
