Re: [VOTE] Release Apache Maven WAR Plugin version 3.2.0

[Baptiste Mathus]

+1.

Tested on Jenkins, especially after
https://github.com/jenkinsci/jenkins/pull/3052

Thanks a lot!

2017-10-02 15:21 GMT+02:00 Dejan Stojadinović :

> +1 (non-binding).
>
> Tested as usual (big project with dozen of plugins).
>
> Regards,
> Dejan
>
> On 2017-09-30 17:55, Karl Heinz Marbaise  wrote:
> > Hi,
> >
> > We solved 3 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318121&version=12341372
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MWAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1371
> > https://repository.apache.org/content/repositories/maven-
> 1371/org/apache/maven/plugins/maven-war-plugin/3.2.0/maven-
> war-plugin-3.2.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-war-plugin-3.2.0-source-release.zip sha1:
> > 5c661f4554616147491036dfac689ba9db90cec2
> >
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > 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: [RESULT] Re: Please retweet and vote

[Baptiste Mathus]

Hello,

Only lurking those days, but chiming in quickly here :-).

2017-09-10 20:54 GMT+02:00 Robert Scholte :

> On Sun, 10 Sep 2017 20:21:11 +0200, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> On Sun 10 Sep 2017 at 19:04, Tibor Digana  wrote:
>>
>> Hi All,
>>>
>>> Are we facing new API regarding networking and security useful in Java 8?
>>>
>>> When I first saw these options I asked myself what benefit would have the
>>> User and Jenkins from Java 8.
>>> And second question was whether we would be so flexible to rewrite the
>>> code
>>> and use Lambda fully anywhere in the code.
>>>
>>
>>
>> There is the social aspect. If you are a potential new contributor to
>> Maven
>> and you look at our heavy Java 1.3 convention codebase (ok, I'm being a
>> demagogue, it's had a bit updated to 5.0) are you going to be encouraged
>> to
>> step forward?
>>
>> How can you make small improvements and demonstrate you are a safe pair of
>> hands to gain the commit bit?
>>
>> Now if we have the opertunity to make lots of tidy up and you can show you
>> are a safe pair of hands, retaining binary compatibility with older
>> plugins, making the code more readable, finding file handle leaks, etc...
>> well now you have a welcome path to demonstrate your skills while
>> gaining familiarity with the codebase so that when we turn around to start
>> on Maven 5.0.x you can join in the fun.
>>
>> Now that is not a technical argument, but we are a community first... so
>> maybe the technical arguments are not so right to push!
>>
>>
> bq. but we are a community first
>
> What's the definition of community: the large user group or the few we're
> hoping to find who can help working on Maven?
> And if we're focusing on the latter, shouldn't the twitter question be:
>
> I want to become a Maven developer
> [] right now!
> [] only if Maven requires Java 8 ( so I can use lambda's, etc.)
>

This is definitely one the things we put forward for moving Jenkins to Java
8 recently [1], keeping contribution appealing.
Because, well, that's great the Maven community would try to help large
companies not be bothered by any kind of upgrade, like Free Enterprise
software support :-).
But I think this is a dead-end, those kind of teams/companies won't upgrade
*anyway*.

Looking at the stats, I would think there's actually not much debate:
people not wanting to upgrade, well, won't upgrade... And proportion is not
that high.
What is the actual issue anyway? They will keep using 3.5.x for 3 years? So
what, I bet they already do. No, wait, they're not, they're using 2.2.1.
I just checked, the company I left 1 year ago is still running 3.2.1, and I
don't expect them to upgrade anytime soon...

Maven backward compatibility is great, so IMO don't bother spending time
with JDK7.
The Maven dev team should IMO concentrate of making Maven great, not
supporting a big variety of versions/flavours developers will hate the
codebase each time they remember "urgh, I can't use this!".
The less combinatorials, the better for anyone working on her/his free time
:-\.

My 2 cents

-- Baptiste
[1] https://jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/

Re: Apache Build Server Jobs

[Baptiste Mathus]

Not in opposition BTW. You can perfectly create and version pipeline jobs
through Job DSL.
Granted if using multibranch pipeline jobs, then the frontier becomes even
more tenuous as the project build description then lays in the code itself.
But still you can handle creating/versioning the job (envelope) though Job
DSL.
Le 10 févr. 2016 11:39 PM, "Stephen Connolly" <
stephen.alan.conno...@gmail.com> a écrit :

> I'd rather use pipeline or literate so we get better branch support, but I
> need to bash Andrew on the head first
>
> On Wednesday 10 February 2016, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > after a request to INFRA they have installed Jenkins Job DSL Plugin very
> > quickly (Thanks to Andrew Bayer) where i will start some experiments to
> > improve our CI jobs and make them reproducible which means they are being
> > checked into version control.. furthermore i would like to improve our CI
> > support...in particular having different jobs for every plugin (some
> other
> > things i have in mind)...but i don't like to do this via UI..so i will do
> > this via jenkins job dsl...
> >
> > So i have started very small part here:
> > https://svn.apache.org/repos/asf/maven/jenkins-seeding (not much in
> there
> > at the moment) but this will be improved over the next weeks
> >
> > I'm preparing this via Docker images locally on my machine and do some
> > tests locally before moving this to Apache Build Server ...
> >
> > So be prepared to see jobs which start with the prefix "jobdsl-*" in the
> > Maven area...Those jobs are only my experiments and are at the moment not
> > valid...until i say different...
> >
> > All other jobs are left untouched
> >
> > Those jobs ("jobdsl-*") are in the first step only experiments to see if
> i
> > have found everything which is needed (Configuration etc.)...
> >
> > If this is finished we can migrate to the full version controled part and
> > move away from UI configured jobs...
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>

Re: maven git commit: [MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore

[Baptiste Mathus]

+1 to simply remove the variable.
That's what I've been doing and advising for years.

Settings M2_HOME only highers the risk to get to weird issues for newcomers
with NoClassDefFoundError where actually M2_HOME points to a different
maven root that the binary in the PATH.

2016-01-27 11:23 GMT+00:00 Christian Schulte :

> Am 27.01.2016 um 11:02 schrieb Arnaud Héritier:
>
>> -1
>> See https://issues.apache.org/jira/browse/MNG-5607
>> Ok to introduce MVN_HOME with M2_HOME value as default when defined (and
>> then remove M2_HOME in Maven 4)
>> But replacing M2_HOME by MVN_HOME in 3.4 seems to be a risky change for
>> our
>> ecosystem (IDE, CI servers, ...) and not only for the local user
>> environment
>>
>> WDYT ?
>>
>> Cheers
>>
>>
> The first commit removes support for M2_HOME in 3.4 completely. The second
> commit only renames a variable used in the script. M2_HOME is just not
> needed and is even confusing. People relying on M2_HOME should just setup
> theire PATH properly, IMHO. That's what most of them do anyway. You see
>
> export PATH=$M2_HOME/bin:$PATH
>
> almost everywhere. I am pretty sure there are a lot of people who do not
> even notice that setting M2_HOME to something not matching theire PATH is
> not what they want. Having a 'mvn' script in my PATH and having that script
> use a M2_HOME variable to launch something not in my PATH is flawed. I
> thought that was the reason for the request to remove that variable. No big
> deal reverting those commits, of course.
>
> So +1 for removing that variable completely in 3.4 or whatever version is
> appropriate for such a change.
>
> Regards,
> --
> Christian
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: What happened to Maven Eclipse Plugin?

[Baptiste Mathus]

+1. Using M2E almost daily (i.e. when doing Java programming).
M2E has been improving a lot since its beginning. And has been stable for
us for many years already.

The biggest issue at that time was actually generally not M2E itself, but
the M2E-WTP /bridge/ which was indeed way more unstable (which I didn't use
personnally), and from what I've been told this one has also got better.
If someone still thinks the maven-eclipse-plugin has value, then I suggest
that person considers stepping up to maintain that plugin.


2015-12-26 2:12 GMT+01:00 Jeff Jensen :

> >
> > Do those of you who are Eclipse users find m2e adequate?
>
>
> I've successfully used m2e for many years on many different systems
> (different customers).  I suggest asking about any issues on the m2e users
> list.
>
>
> On Fri, Dec 25, 2015 at 2:37 PM, Gary Gregory 
> wrote:
>
> > I'm still surprised that no one wants to maintain this. Do those of you
> who
> > are Eclipse users find m2e adequate? I don't. Unless I do not know how to
> > set it up. For example, importing the log4j2 projects creates some
> projects
> > with errors.
> >
> > Gary
> > On Dec 24, 2015 2:44 PM, "Michael Osipov" <1983-01...@gmx.net> wrote:
> >
> > > Hi Robert,
> > >
> > > back in October the result of the retirement vote [1] was positive.
> > > The plugin is still online without notice, issues are still open in
> JIRA
> > > and no repo is at GitHub.
> > >
> > > Did you simply forget that?
> > >
> > > Michael
> > >
> > > [1] https://www.mail-archive.com/dev%40maven.apache.org/msg107104.html
> > >
> > > -
> > > 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: Maven Release Plugin with Git broken?

[Baptiste Mathus]

Hi Robert, not a developer list question, better use the users list for
that kind of questions.
Indeed, like what Karl-Heinz says, I suspect you're trying to release from
a submodule/subdirectory.

Cheers

2015-10-07 9:23 GMT+02:00 Karl Heinz Marbaise :

> Hi Robert,
>
> Is this  a mult module project ? Have you defined the scm connection only
> in the root module ? Are you trying to release from the root of ?
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/7/15 4:48 AM, Robert Patrick wrote:
>
>> Hi,
>>
>>
>>
>> Sorry for the noise but it seems like the Maven Release Plugin 2.5.2
>> (with Maven 3.3.3) is not doing what I would have expected with a Git
>> repo.  As you can see below, the "git push" command is mangling the
>> repository by tacking the artifactId of my multi-module project onto the
>> end of the connection url, which is causing our Gitlab server to rightfully
>> complain that the repository does not exist.
>>
>>
>>
>> [INFO] Checking in modified POMs...
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> add -- parent/pom.xml util/pom.xml consumer/pom.xml pom.xml
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> rev-parse --show-toplevel
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> status --porcelain .
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> commit --verbose -F /tmp/maven-scm-1310627247.commit parent/pom.xml
>> util/pom.xml consumer/pom.xml pom.xml
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> symbolic-ref HEAD
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> push 
>> g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module
>> refs/heads/master:refs/heads/master
>>
>>
>>
>> My scm section of my parent pom (whjch all poms inherent from) looks like
>> this:
>>
>>
>>
>>
>>  scm:git:g...@orahub.oraclecorp.com:
>> robert.patrick/snapshots-test.git
>>  scm:git:g...@orahub.oraclecorp.com:
>> robert.patrick/snapshots-test.git
>>
>>
>>
>>
>> So why is Maven trying to use HYPERLINK "mailto:g...@orahub.oraclecorp.com
>> :robert.patrick/snapshots-test.git/snapshots-multi-module"g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module
>> in the git push command?
>>
>>
>>
>> Am I just doing something stupid or is this really busted?
>>
>>
> -
> 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: [VOTE] Retire Maven Eclipse Plugin / Donation to Mojohaus

[Baptiste Mathus]

+0.5.

Having been using M2E for almost 10 years, granted, was touchy in the
beginning, but wo issue nowaways,
I guess that if it comes to MojoHaus we should put a notice for newcomers
that they're likely more looking for M2E than using it.

Btw, if it comes to MojoHaus I suppose you plan to change
maven-eclipse-plugin to eclipse-maven-plugin, or do you plan to keep the GA
as-is for backward compat?

Cheers

2015-10-04 11:18 GMT+02:00 Robert Scholte :

> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for Eclipse is good and stable.
> The maven-eclipse-plugin has a lot of integration tests which should be
> rewritten, because it always launches a new Maven fork and it takes ages to
> complete. This simply blocks good continuous integration of the plugins.
> I know there are still some projects with can't use the Maven Integration
> of Eclipse and depend on this plugin, so the sources need to stay available
> for users so the can extend it for their own usage.
>
> I therefor propose that we retire maven-eclipse-plugin for the Apache
> Maven project and donate it to the Mojohaus project
>
> 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...
>
> -
> 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: [Mojohaus] Have we guidelines for cutting releases?

[Baptiste Mathus]

https://groups.google.com/forum/m/#!forum/mojohaus-dev :)
Le 19 juin 2015 5:08 PM, "Stephen Connolly" 
a écrit :

> And yet no pointer to the new list ;-) (I havent used it enough already
> that the borg-mail web client shows it in autocomplete)
>
> On 19 June 2015 at 15:47, Baptiste Mathus  wrote:
>
> > I guess you talk about the users list, that one we agreed on hijacking,
> > yes, not the dev one :-).
> >
> > 2015-06-19 15:52 GMT+02:00 Stephen Connolly <
> > stephen.alan.conno...@gmail.com
> > >:
> >
> > > I though we were hijacking the maven list... but if I had that wrong,
> > > that's fair enough
> > >
> > > On 19 June 2015 at 07:39, Baptiste Mathus  wrote:
> > >
> > > > Didn't you send to the wrong list?
> > > >
> > > > 2015-06-18 23:59 GMT+02:00 Dan Tran :
> > > >
> > > > > do we still stage at nexus.codehaus.org?
> > > > >
> > > > > Thanks
> > > > >
> > > > > -D
> > > > >
> > > > > On Thu, Jun 18, 2015 at 12:50 PM, Stephen Connolly <
> > > > > stephen.alan.conno...@gmail.com> wrote:
> > > > >
> > > > > > More asking about what minimum parent version, etc and have any
> > > > releases
> > > > > > been cut yet to prove the process
> > > > > >
> > > > > > On Thursday, June 18, 2015, Manfred Moser 
> > > > wrote:
> > > > > >
> > > > > > > I assume whatever was done at codehaus in the past.
> > > > > > >
> > > > > > > But from my perspective - you think its ready. Just do it ;-)
> > > > > > >
> > > > > > > manfred
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Stephen Connolly wrote on 18.06.2015 09:32:
> > > > > > >
> > > > > > > > https://github.com/mojohaus/extra-enforcer-rules/
> > > > > > > >
> > > > > > > > is one I'd like to cut...
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > 
> > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > > 
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Sent from my phone
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Baptiste  MATHUS - http://batmat.net
> > > > Sauvez un arbre,
> > > > Mangez un castor !
> > > >
> > >
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>

Re: [Mojohaus] Have we guidelines for cutting releases?

[Baptiste Mathus]

I guess you talk about the users list, that one we agreed on hijacking,
yes, not the dev one :-).

2015-06-19 15:52 GMT+02:00 Stephen Connolly :

> I though we were hijacking the maven list... but if I had that wrong,
> that's fair enough
>
> On 19 June 2015 at 07:39, Baptiste Mathus  wrote:
>
> > Didn't you send to the wrong list?
> >
> > 2015-06-18 23:59 GMT+02:00 Dan Tran :
> >
> > > do we still stage at nexus.codehaus.org?
> > >
> > > Thanks
> > >
> > > -D
> > >
> > > On Thu, Jun 18, 2015 at 12:50 PM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > More asking about what minimum parent version, etc and have any
> > releases
> > > > been cut yet to prove the process
> > > >
> > > > On Thursday, June 18, 2015, Manfred Moser 
> > wrote:
> > > >
> > > > > I assume whatever was done at codehaus in the past.
> > > > >
> > > > > But from my perspective - you think its ready. Just do it ;-)
> > > > >
> > > > > manfred
> > > > >
> > > > >
> > > > >
> > > > > Stephen Connolly wrote on 18.06.2015 09:32:
> > > > >
> > > > > > https://github.com/mojohaus/extra-enforcer-rules/
> > > > > >
> > > > > > is one I'd like to cut...
> > > > > >
> > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > 
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > 
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [Mojohaus] Have we guidelines for cutting releases?

[Baptiste Mathus]

Didn't you send to the wrong list?

2015-06-18 23:59 GMT+02:00 Dan Tran :

> do we still stage at nexus.codehaus.org?
>
> Thanks
>
> -D
>
> On Thu, Jun 18, 2015 at 12:50 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > More asking about what minimum parent version, etc and have any releases
> > been cut yet to prove the process
> >
> > On Thursday, June 18, 2015, Manfred Moser  wrote:
> >
> > > I assume whatever was done at codehaus in the past.
> > >
> > > But from my perspective - you think its ready. Just do it ;-)
> > >
> > > manfred
> > >
> > >
> > >
> > > Stephen Connolly wrote on 18.06.2015 09:32:
> > >
> > > > https://github.com/mojohaus/extra-enforcer-rules/
> > > >
> > > > is one I'd like to cut...
> > > >
> > >
> > >
> > > ---------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> 
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Full migration to Git

[Baptiste Mathus]

2015-06-01 19:13 GMT+02:00 Kristian Rosenvold 
:

> Re-running the clone from a backup of asf svn is time consuming but might
> be the way to go, because we could probably get the correct layout in one
> go. (But it's dooog slow and will be even worse multiplied by X)
>

Yes. That's indeed the way I chose to follow for Mojo because after
twiddling a bit with filter-branch, I was quite sure it would be slower but
a lot easier to just git svn clone mojo by mojo (hence the csv file,
specifying the tags&branches for each mojo [1]). I also

And I can certainly relate about the sluggishness. It took about 2 or 3
minutes even for very small mojos, and I had the whole SVN imported locally.

In that current case, I've always seen svn repositories available at GitHub
as automated facilities somehow only to be able to file PR against the svn
trunk, but not as real Git clone that could be used for a migration.


> Alternately one could probably get around the strange layout of the current
> git-svn clone by doing some hardcore conditional filter-branching to
> rewrite the root directory of only those commits that are not already at
> the root. This is not your average git-svn rewrite and we're *way* beyond
> powerpoint presentations here.
>
> But bottom line, it's just a dirty job that someone has to do :)
>

Yep. But even if I'm not even sure every required commits are here, I'm not
sure that would be interesting to do it apart from learning a bit more
black magic :).



>
>  Kristian
>


[1] https://github.com/mojohaus/convert-to-git/blob/master/repo-infos.csv

Re: How do I merge pull request on GitHub?

[Baptiste Mathus]

Beware that using the diff format, you're gonna lose the commit information
(author, committer...). With SVN you don't have any other choice, but with
Git it would be a waste IMO.

Cheers

2015-05-29 13:29 GMT+02:00 Tamas Cservenak :

> Sry, I sent the “resolved” URL, here is the real one:
>
> https://github.com/apache/maven-plugins/pull/48.diff
>
>
> --
> Thanks,
> ~t~
>
> On 29 May 2015 at 13:27:47, Tamas Cservenak (ta...@cservenak.net) wrote:
>
> Dennis,
>
> you can take PRs as patches from GH by appending “.patch” or “.diff” to PR
> URL,
> here is your example:
>
>
> https://patch-diff.githubusercontent.com/raw/apache/maven-plugins/pull/48.diff
>
> Then, apply that patch “manually” to sources and then commit. Is a bit
> hassle but that’s all to it. Having all this in git would be way more
> simpler.
>
> HTH
>
> --
> Thanks,
> ~t~
>
> On 29 May 2015 at 11:00:59, Dennis Lundberg (denn...@apache.org) wrote:
>
> Thanks Stevo,
>
> Interesting read for me that is less than fluent in git. In this case
> I unfortunatelly cannot use those instructions as maven-plugins does
> not have a git repo at Apache. It is versioned in svn and is probably
> using some svn->git mirroring software to end up on the GitHub mirror
> at
> https://github.com/apache/maven-plugins
>
> Do you know if the Apache GitHub repo is read-only? Would it be
> possible to merge the PR at GitHub and get that commit propagated back
> to our canonical svn repo?
>
> If I understand your instructions correctly the modifications goes
> something like this:
> contributor branch@github --> git-wip-us.apache.org --> Apache GitHub
> mirror
>
> What I think that I need is this:
> contributor branch@github --> Apache GitHub mirror --> svn.apache.org
>
>
> On Fri, May 29, 2015 at 9:38 AM, Stevo Slavić  wrote:
> > On Apache Mahout project we have nice docs on the workflow to merge or
> > reject PRs submitted to github mirror. Maybe it works for you too.
> >
> > Kind regards,
> > Stevo Slavic.
> >
> > On Fri, May 29, 2015 at 9:27 AM, Dennis Lundberg 
> wrote:
> >
> >> Hi
> >>
> >> I'm going through the issue list in JIRA for maven-pmd-plugin and want
> >> to apply some patches that have been submitted as pull requests to our
> >> GitHub mirror. But I cannot find a way to merge the pull requests. On
> >> the page of the pull request it says:
> >>
> >> This pull request can be automatically merged by project collaborators.
> >> Only those with write access to this repository can merge pull requests.
> >>
> >> Am I missing some permissions or am I just lacking Git(Hub) knowledge?
> >> My github id is dennisl. Here is an example:
> >> https://github.com/apache/maven-plugins/pull/48
> >>
> >> --
> >> Dennis Lundberg
> >>
> >> ---------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
>
> --
> Dennis Lundberg
>
> -
> 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: Full migration to Git

[Baptiste Mathus]

See https://github.com/mojohaus/convert-to-git for MojoHaus (previously
Mojo@Codehaus).
Though a bit rough a the main script being a bit oriented towards the Mojo
SVN, it has no real specificities wrt SVN->Git migration, so it should be
at least a good starting point.

I can privide help, or help anyone wanting to try and use it, and document
what needs be. Just tell me.

Cheers

2015-05-31 6:26 GMT+02:00 Barrie Treloar :

> On 31 May 2015 at 08:18, Jason van Zyl  wrote:
>
> > I’m sure those responsible for the migration of the Mojo project monorepo
> > into the separated repos will help us.
>
>
> I ask because I'm going to be facing the same thing at work soon-ish, so
> there is a good chance of finding some capacity during work hours to help
> out with this migration to gain some skillz.
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [ANNOUNCEMENT] End Of Life of Maven 2.2.1 - Plugins / JDK Roadmap

[Baptiste Mathus]

+1 congrats to all and particularly indeed to you Karl-Heinz with the
dozens of releases you personally pushed out in the past months.

2015-05-28 13:54 GMT+02:00 Jason van Zyl :

> Karl,
>
> Thanks so much for your continued effort to get all these plugins out. You
> really do an incredible amount of work and we're all better for it!
>
> On May 28, 2015, at 2:51 AM, Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > we have accomplished the whole release line which means all plugins are
> now at minium of Maven 2.2.1 (inkl. Java 1.5) except the known exceptions...
> >
> >
> https://builds.apache.org/view/All/job/dist-tool-plugin/site/dist-tool-prerequisites.html
> >
> >
> > Congrats to all who supported and helped here.
> >
> > Kind regards
> > Karl Heinz marbaise
> >
> >
> > On 3/20/15 10:39 PM, Karl Heinz Marbaise wrote:
> >> Dear Maven Users,
> >>
> >> based on the End of Life of Maven 2.2.1 (a year ago) now the time has
> >> come to make the final releases of Apache Maven Plugins which support
> >> Maven 2.X.
> >>
> >> If you continue to use Maven 2.2.1 or earlier you have to be aware of
> >> using an completely unsupported Maven version as well as unsupported
> >> Maven plugins for the future.
> >>
> >> If you want to have access to new features and bug fixes it is really
> >> necessary to update to new Maven versions.
> >>
> >> The next Maven version which will go the same way as Maven 2.2.1
> >> will be Maven 3.0.5.
> >>
> >> We have documented the final releases of plugins which support Maven
> >> 2.2.1 in relationship with JDK 1.5.
> >>
> >> The complete list can be found here:
> >>
> >> http://maven.apache.org/maven-2.x-eol.html
> >>
> >> The next step on our roadmap is to lift all plugin versions to 3.0.0 to
> >> make clear those plugins will only work with Maven 3.0+ furthermore the
> >> Java minimum requirement will be lifted to JDK 1.6 as well.
> >>
> >> No "rule" without exceptions. Here they come:
> >>
> >>  * maven-site-plugin (Version 3.4)
> >>See the docs of the plugin for usage in Maven 2.X
> >>
> >>  * maven-compiler-plugin (Version 3.2)
> >>which works with Maven 2.2.1.
> >>
> >>  * maven-plugin-plugin (Version 3.4)
> >>which works with Maven 2.2.1
> >>
> >>  * maven-pmd-plugin (Version 3.4)
> >>which works with Maven 2.2.1 but needs JDK 1.6
> >>
> >> The following plugins already have the Maven 3.0+ requirement:
> >>
> >> * maven-scm-publish-plugin (Version 1.1)
> >> * maven-shade-plugin (Version 2.3)
> >>
> >> Currently the plan is to make those plugins which are already at 3.X
> >> being lifted to version 3.5.0 for Maven 3.X only:
> >>
> >>  * maven-site-plugin (Version 3.5.0)
> >>
> >>  * maven-compiler-plugin (Version 3.5.0)
> >>
> >>  * maven-plugin-plugin (Version 3.5.0)
> >>
> >>  * maven-pmd-plugin (Version 3.5.0)
> >>
> >> All other plugins will get a version 3.0.0 to identify Maven 3.X only
> >> plugins and the JDK minimum will be 1.6.
> >>
> >> Example:
> >>   So to make things more clearer here is an example:
> >>
> >>   Currently we have the maven-clean-plugin with version 2.6.1.
> >>
> >>   This plugin supports Maven 2.2.1 and JDK 1.5 minimum.
> >>
> >>   This plugin will get a new major release with version 3.0.0
> >>   which has the Maven minimum 3.0 AND Java minimum 1.6.
> >>
> >> Kind regards
> >> - The Apache Maven Team
> >>
> >> -
> >> 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
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Three people can keep a secret provided two of them are dead.
>
>  -- Benjamin Franklin
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> 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: SSL certificate problem with git-wip-us.apache.org

[Baptiste Mathus]

Maybe try the solutions there:
http://stackoverflow.com/questions/11621768/how-can-i-make-git-accept-a-self-signed-certificate/19363404#19363404

My 2 cents

2015-05-11 13:58 GMT+02:00 Igor Fedorenko :

> Does anyone know how to fix ssl error below when using git (from
> macports) on osx 10.9.5? Everything works just fine on ubuntu, so I
> think this is osx or macports issue.
>
> mpb:maven igor$ git pull --rebase
> fatal: unable to access
> 'https://git-wip-us.apache.org/repos/asf/maven.git/': SSL
> certificate problem: unable to get local issuer certificate
>
> --
> Regards,
> Igor
>
> -
> 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: [IMPORTANT NOTICE] Jira migration from Codehaus to Apache on April 4th

[Baptiste Mathus]

@Eric, Codehaus is shutting down: read https://codehaus.org/.

So the answer is yes. And there's not much time left.

Cheers

2015-04-03 9:42 GMT+02:00 Eric Barboni :

> Hi Hervé
>  should the same process be done for archiva continuum and groovy ?
>
> Regards
> Eric
> Le Vendredi 3 Avril 2015 08:37 CEST, Hervé BOUTEMY 
> a écrit:
>
> > Hi Maven devs,
> >
> > After Jira migration to ASF, we'll need to create groups to give required
> > privileged access to issues to the team.
> >
> > We need to know the Jira username of everybody, which unfortunately is
> not
> > required to be the same as your Apache id.
> > I started the list in http://svn.apache.org/r1670998
> >
> > Please update your Jira username.
> >
> > Thank you
> >
> > Hervé
> >
> > Le vendredi 3 avril 2015 08:17:37 Hervé Boutemy a écrit :
> > > The migration will start in 12h: every Jira project at Codehaus to be>
> migrated to ASF will be marked read-only
> > >
> > > Remember to check your Jira account email settings both at Codehaus
> and ASF
> > > if you want to be sure of the result at ASF.
> > > And everything is tracked at
> > > https://issues.apache.org/jira/browse/INFRA-9116
> > >
> > > -The Apache Maven team
> > >
> > > Le mardi 31 mars 2015 23:24:21 Hervé BOUTEMY a écrit :
> > > > Hi,
> > > >
> > > > Schedule confirmed:
> > > > 20150403-2000 UTC => projects freeze in Codehaus
> > > > 20150405 => projects available in ASF
> > > >
> > > > Don't forget to check account emails if you already have an account
> at ASF
> > > >
> > > > -The Apache Maven team
> > > >
> > > > Le mercredi 25 mars 2015 03:44:07 Hervé Boutemy a écrit :
> > > > > Hi,
> > > > >
> > > > > As announced in our quarterly report from january, we were
> studying Jira
> > > > > migration from Codehaus to Apache: the migration will happen
> during the
> > > > > week- end of April 4th.
> > > > >
> > > > > We'll create the exact same Jira projects at ASF  than what we
> have at
> > > > > Codehaus, copy the whole content and mark Codehaus read-only.
> > > > > See https://issues.apache.org/jira/browse/INFRA-9116 for exact
> list.
> > > > >
> > > > > For example, it was done a few years ago with (near empty) MPOM,
> which
> > > > > was
> > > > > moved from http://jira.codehaus.org/browse/MPOM to
> > > > > https://issues.apache.org/jira/browse/MPOM
> > > > >
> > > > >
> > > > > How will username migration from Codehaus to ASF happen?
> > > > >
> > > > > When migrating existing content, user accounts will be migrated too
> > > > > (that's
> > > > > the way Jira works).
> > > > >
> > > > > To avoid creating accounts that already exist at Apache, matching
> will
> > > > > be
> > > > > done on account's e-mail address. The mapping will look something
> like:
> > > > >
> > > > > for each e-mail/username pair in the Codehaus content
> > > > >
> > > > >   if the email is associated with a user in the ASF Jira instance,
> > reuse:
> > > > > update the username from imported content to the ASF username>
> > >
> > > > >   else we'll create a new account in the ASF Jira instance:
> > > > > if the username already exists in the ASF Jira instance
> (another
> > > > > email)
> > > > >
> > > > >   update the imported username to append -[SUFFIX] to the end>
> > >
> > > > > else
> > > > >
> > > > >   use the imported username/email as is
> > > > >
> > > > > The exact [SUFFIX] still needs to be defined.
> > > > >
> > > > > If you want to be sure of your username at Apache Jira, please
> take a
> > > > > look
> > > > > at your e-mail at Codehaus and check that it matches the e-mail at
> your
> > > > > Apache Jira account.
> > > > >
> > > > >
> > > > > If you have any question, don't hesitate to ask.
> > > > >
> > > > > We'll keep you informed as the operation is planned more in
> details.
> > > > >
> > > > > -The Apache Maven team
> > > > >
> > > > >
> -
> > > > > 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
> >
>
>
>
>
>
>
> -
> 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: [VOTE] Maven 3.3.1 Release

[Baptiste Mathus]

+1.

2015-03-16 2:56 GMT+01:00 Jason van Zyl :

> Great. I plan to let it free for St Patrick's beers early evening tomorrow
> EST.
>
> On Mar 15, 2015, at 5:12 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I hope to haves testing done tomorrow
> >
> > On 13 March 2015 at 20:21, Jason van Zyl  wrote:
> >
> >> Hi,
> >>
> >> Time to release Maven 3.3.1!
> >>
> >> Here is a link to Jira with 37 issues resolved:
> >>
> >>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=21013
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-1151/
> >>
> >> The distributable binaries and sources for testing can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/
> >>
> >> Specifically the zip, tarball, and source archives can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.tar.gz
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.tar.gz
> >>
> >> Source release checksum(s):
> >> apache-maven-3.3.1-src.zip sha1:
> 93b2e7efaec93437aee67f0618fc77793e20a828
> >>
> >> Staging site:
> >> http://takari.io/maven-3.3.1/
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> Thanks,
> >>
> >> The Maven Team
> >> -
> >> 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, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> I never make the mistake of arguing with people for whose opinions I have
> no respect.
>
> -- Edward Gibbon
>
>
>
>
>
>
>
>
>
>
>
>
> -
> 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: Adding @Nonnull annotations to EnforcerRule

[Baptiste Mathus]

Hi,

I went ahead and filed https://jira.codehaus.org/browse/MENFORCER-227 and
attached the associated ~5 lines patch.
For reference I used the dependency mentioned by Kristian here
http://mail-archives.apache.org/mod_mbox/maven-dev/201409.mbox/%3CCAJZRQKyicOyE-W57cuUnFnFzvihZyhDqCx0TGpDy-i=olx2...@mail.gmail.com%3E

Thanks for any feedback.

2015-02-20 16:41 GMT+01:00 Baptiste Mathus :

> Hi guys,
>
> Just tried on IRC without much success. Using JSR305 annotations on some
> internal enforcer rules, we encounter some issue like for example the
> checker thinking the helper reference could be passed null in the execute
> method [1].
>
> It would help to declare it like this instead:
>
> void execute(@Nonnull EnforcerRuleHelper helper)
>
>
>
> What's your take on this?
>
> I can file a JIRA and attach the associated patch, but I thought I'd dump
> the question here first. I know those annotations have started to be using
> inside the core, so I suppose that shouldn't be an issue there too?
>
> Is this something you'd be OK to integrate inside the enforcer-api?
>
> Thanks
>
> [1]
> https://maven.apache.org/enforcer/enforcer-api/apidocs/org/apache/maven/enforcer/rule/api/EnforcerRule.html#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
>
> --
> Baptiste
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>

Adding @Nonnull annotations to EnforcerRule

[Baptiste Mathus]

Hi guys,

Just tried on IRC without much success. Using JSR305 annotations on some
internal enforcer rules, we encounter some issue like for example the
checker thinking the helper reference could be passed null in the execute
method [1].

It would help to declare it like this instead:

void execute(@Nonnull EnforcerRuleHelper helper)



What's your take on this?

I can file a JIRA and attach the associated patch, but I thought I'd dump
the question here first. I know those annotations have started to be using
inside the core, so I suppose that shouldn't be an issue there too?

Is this something you'd be OK to integrate inside the enforcer-api?

Thanks

[1]
https://maven.apache.org/enforcer/enforcer-api/apidocs/org/apache/maven/enforcer/rule/api/EnforcerRule.html#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)

-- 
Baptiste

Re: Open JIRA issues/retiring plugins

[Baptiste Mathus]

Agree with Anders:

* +1 to deprecate maven-eclipse-plugin (coming from an happy M2E user from
years), the community must acknowledge that this plugin is not the way to
go and there's a modern an well-maintained alternative.
* -1 to deprecate maven-archetype-plugin IMO it's still one of those
plugins that you'll find in almost every docs, internal or external, to
bootstrap project developments. I don't see an alternative as-of today.

* -0 maven-docck-plugin: it's still referenced here at MOJO
http://mojo.codehaus.org/development/performing-a-release.html#Preparing_for_the_First_Production_Release
but I don't know its feature enough to have a strong opinion on this one.
Just thought I would point this reference out.

No opinion for this others.


2015-02-02 10:32 GMT+01:00 Anders Hammar :

> I strongly second that the maven-eclipse-plugin be retired. For us working
> in Eclipse, the m2e integration is the way to go. Also, there has not been
> any active work on that plugin for many years and I think we should clearly
> indicate to the community that there is very little hope anyone would fix
> any issues that people (still) using m-eclipse-p run into.
>
> However, I don't think that the maven-archetype-plugin should be retired.
> Although there might not be very much work on it, it is used in many Get
> Started guides on the Internet.
>
> /Anders
>
> On Mon, Feb 2, 2015 at 10:23 AM, Michael Osipov <1983-01...@gmx.net>
> wrote:
>
> > Hi folks,
> >
> > I have performed another cleanup on JIRA in the last couple of days, most
> > of on old issues.
> > Right now, we have more than 2000 open issues. Not manageble from my
> point
> > of view.
> >
> > I have noticed that several plugins haven't been touched in years. What
> is
> > the status of
> > the following plugins:
> >
> > http://maven.apache.org/plugins/maven-docck-plugin/
> > http://maven.apache.org/plugins/maven-doap-plugin/
> > http://maven.apache.org/plugins/maven-repository-plugin/
> > http://maven.apache.org/plugins/maven-stage-plugin/
> > http://maven.apache.org/plugins/maven-eclipse-plugin/
> > http://maven.apache.org/plugins/maven-verifier-plugin/
> > http://maven.apache.org/plugins/maven-patch-plugin/
> > http://maven.apache.org/plugins/maven-pdf-plugin/
> > http://maven.apache.org/archetype/maven-archetype-plugin/
> >
> > Is anyone working on them or planning to release a version? Any thoughts
> > or objections?
> >
> > I'd like to retire them and clean up JIRA plugin by plugin.
> >
> > Michael
> >
> > -
> > 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 !
> nbsp;!
>

Re: Remove M2_HOME setup from download page instructions

[Baptiste Mathus]

@Robert yup my bad for being somehow unclear.
The -1 was answering to the fact that M2_HOME may be useful in some cases.

So I'm indeed +1 for removing it from the docs.

Cheers
Le 27 janv. 2015 19:14, "Robert Scholte"  a écrit :

> @Baptiste, so I guess your vote is actually +1 to remove it from
> documentation, right?
> M2_HOME is automatically set by the shell or batch script.
>
> The M2_HOME variable is here used to easily switch between different Maven
> distributions. But with this name this can indeed cause
> NoClassDefFoundErrors.
> For the majority of the community it's not interesting to have multiple
> versions of Maven and to switch often.
> So this M2_HOME might be confusing. Instead just add
> apache-maven-3.x.x/bin to your path.
> You have my +1 for this change.
>
> Also, there's no need to add JAVA_HOME/bin to the path. Maven picks it up
> as an environment variable, it won't scan the path searching for the java
> executable. So I'd like to see that removed as well.
>
> thanks,
> Robert
>
> Op Tue, 27 Jan 2015 10:04:28 +0100 schreef Baptiste Mathus  >:
>
>  -1 it's a problematic variable, removing it is a good idea IMO, and
>> changing mvn version is indeed just a matter of updating your path.
>>
>> I've been hit many a time by an updated PATH pointing to a different mvn
>> version than the one referenced by M2_HOME, which ends with
>> NoClassDefFoundError or something like that IIRC.
>> That's why I've personally been advising maven users I encounter to never
>> ever set that variable for years.
>>
>> Cheers
>>
>> 2015-01-27 7:19 GMT+01:00 Anders Hammar :
>>
>>  > I would still suggest to make sure its documented somewhere. I find it
>>> > incredibly useful to just change M2_HOME to simply switch Maven
>>> versions.
>>> >
>>>
>>> +1, very useful but I guess it doesn't require the name M2_HOME.
>>>
>>> /Anders
>>>
>>> >
>>> > manfred
>>> >
>>> > Mirko Friedenhagen wrote on 26.01.2015 21:40:
>>> >
>>> > > Dan, go ahead, I have not set this variable for years.
>>> > >
>>> > > Regards
>>> > > Mirko
>>> > > --
>>> > > Sent from my mobile
>>> > > On Jan 27, 2015 5:52 AM, "Dan Tran"  wrote:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> Any objection  to remove the need to setup M2_HOME env variable at
>>> maven
>>> > >> download page?
>>> > >>
>>> > >>
>>> > >> Thanks
>>> > >>
>>> > >> -Dan
>>> > >>
>>> > >>  https://jira.codehaus.org/browse/MNGSITE-223
>>> > >>
>>> > >
>>> >
>>> >
>>> > -
>>> > 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 !
>>> nbsp;!
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Remove M2_HOME setup from download page instructions

[Baptiste Mathus]

-1 it's a problematic variable, removing it is a good idea IMO, and
changing mvn version is indeed just a matter of updating your path.

I've been hit many a time by an updated PATH pointing to a different mvn
version than the one referenced by M2_HOME, which ends with
NoClassDefFoundError or something like that IIRC.
That's why I've personally been advising maven users I encounter to never
ever set that variable for years.

Cheers

2015-01-27 7:19 GMT+01:00 Anders Hammar :

> > I would still suggest to make sure its documented somewhere. I find it
> > incredibly useful to just change M2_HOME to simply switch Maven versions.
> >
>
> +1, very useful but I guess it doesn't require the name M2_HOME.
>
> /Anders
>
> >
> > manfred
> >
> > Mirko Friedenhagen wrote on 26.01.2015 21:40:
> >
> > > Dan, go ahead, I have not set this variable for years.
> > >
> > > Regards
> > > Mirko
> > > --
> > > Sent from my mobile
> > > On Jan 27, 2015 5:52 AM, "Dan Tran"  wrote:
> > >
> > >> Hi,
> > >>
> > >> Any objection  to remove the need to setup M2_HOME env variable at
> maven
> > >> download page?
> > >>
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >>  https://jira.codehaus.org/browse/MNGSITE-223
> > >>
> > >
> >
> >
> > -
> > 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 !
> nbsp;!
>

Re: Releases, Continuous Delivery and the Future

[Baptiste Mathus]

Well, I for one find the x.y.z-nn somehow unusual. I'd prefer something
simple like x.y.z and I don't give a f*ck if some numbers are skipped.

+1 with Stephen: I've never seen someone complain about missing versions
neither on ML nor IRL. Sure, I suppose people might wonder where the 4.x
went if the next mvn version was to be 5.0, but apart (and even though)
from the major version, I don't see any developer ever complaining about
that.

Just then let's indeed have a changelog somewhere just for reference that
confirms that the x.y.foo was skipped and never released.
But I'm sure few people will have a look at it and it won't be a concern.

IMO, there are in fact 3 main cases:

1) people stuck with a corp version won't ever deal with that issue and use
what's provided
2) people wanting the latest version, will just go on the website on
download the first link seemingly being the latest one
3) people wanting to do a careful upgrade (certainly most often for the 1/
group, think build/release engineering team) would just carefully read the
release notes to see what bump is safe to do (this is typically what we do
for Jenkins for example)

My 2 cents.


2014-12-28 22:00 GMT+01:00 Brian E. Fox :

>
>
> > On Dec 14, 2014, at 8:29 PM, Jason van Zyl  wrote:
> >
> > What we want is a form of continuous delivery where a version like 3.2.4
> is the version that we call it to the outside world (some refer to it as
> the marketing version) and the qualifier changes from build to build so we
> have:
> >
> > 3.2.4-qualifier
> >
> > And for simplicity's sake let's just say the qualifier is a build number
> so we end up with:
> >
> > 3.2.4-01
> > 3.2.4-02
> > ...
> > 3.2.4-NN
>
> +1
>
> This really the only viable scheme I've seen used over the years. It's how
> we do it at Sonatype and it's never been an issue that the public version
> is shown with some -build number.
>
> We will want to ensure that only one release version gets published though
> to reduce confusion. Since everything is staged, this should happen
> normally.
>
> For plugins, which are commonly referred to by users in their poms, this
> might turn out to be a problem as it increases the maintenance load but I
> think we start trying it and if there is an issue we go to an alternate
> approach.
> -----
> 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 !
> nbsp;! 
>

Re: [VOTE] Name our mascot: "Shotgun" vs "The Maven Owl"

[Baptiste Mathus]

Same here, good point. -gun.
B
Le 16 déc. 2014 22:46, "Matt Stephenson"  a écrit :

> A
>
> On Mon, Dec 15, 2014 at 2:39 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > After the run-off round, we are left with two names standing.
> >
> > This second vote will be a straight and simple majority wins.
> >
> > The vote will be open for at least 72 hours (with the potential of an
> > extension until I send a message saying that the polls are closed)
> >
> > There will be no discussion in this thread, we have talked it all enough
> > already. If you want to discuss something, please use a different thread.
> >
> > Vote:
> >
> > [A]: Shotgun
> > [B]: The Maven Owl
> >
> > Thank you very much for your time
> >
> > -Stephen
> >
>

Re: [VOTE] Change project logo and adopt owl as mascot

[Baptiste Mathus]

+1.

Though I quite also like the comment about having some form of M on the
chest (say like a superman S), but I'm late to the train here.
Le 28 nov. 2014 10:38, "Dennis Lundberg"  a écrit :

> +1
>
> On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly
>  wrote:
> > For anyone who has been living under a rock, here is the background
> >
> > Background
> > =
> >
> > I think everyone can agree that the site needs a reorganisation and a
> > rewrite. Users cannot find what they need, and the end result is that
> > people keep on abusing maven rather than having maven help them.
> >
> > Try as I might, I have been unable to motivate myself to do the
> > reorganisation with the current dated look and feel of the site... I am
> not
> > saying that picking a new logo and selecting a mascot will result in
> making
> > progress, but it can't hurt and I believe it will help
> >
> > Proposed changes
> > ===
> >
> > 1. Change the logo font to Alte Haas Grotesk Bold with italics applied by
> > Inkscape
> > 2. Change the highlighted letter from 'a' to 'v' and replace the v with
> two
> > Apache Feathers
> > 3. Adopt the (currently unnamed) owl as our mascot
> >
> > Here is a link to the font:
> >
> > http://www.dafont.com/alte-haas-grotesk.font
> >
> > Here is a large version of the owl and the logo:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png
> >
> > A regular version of the own and the logo, e.g. a size suitable for use
> in
> > the top of the standard maven sites:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final.png
> >
> > (Note that in all likelihood, the mascot would probably end up on the
> other
> > side of the title bar from the logo... and that is IF the mascot ends up
> on
> > the title bar)
> >
> > Here is both of those rendered in a site (as it can be helpful to see the
> > graphics adjacent to text)
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-context.png
> >
> >
> > Logo Rational
> > ===
> >
> > If we do some searches for the Maven logo:
> >
> >
> https://www.google.com/search?site=imghp&tbm=isch&q=maven+logo&oq=maven+logo
> >
> >
> http://www.bing.com/images/search?q=maven+logo&go=Submit&qs=n&form=QBLH&scope=images&pq=maven+logo
> >
> > Our current logo, with a single highlighted letter stands out quite well
> > from the other "maven" logos, so keeping a highlighted letter and an
> italic
> > rendered font maintains continuity with our current logo.
> >
> > By changing the highlighted letter to the `v` and by using two Apache
> > feathers to create the `v`, we connect our logo back to Apache... we are
> > Apache Maven after all.
> >
> > The `v` is also the common short term for version (e.g.v3 is short for
> > version 3). Apache Maven puts a lot of emphasis on versions of
> dependencies
> > and plugins... you could say that versions are very important to Maven.
> >
> > The colours of the feather were changed to solid colours to match the owl
> > mascot's scarf, beak and eyebrows
> >
> > Voting rules
> > =
> >
> > Anyone who is subscribed to the dev or users list is eligible to vote.
> >
> > If you vote multiple times, only your final vote will be counted.
> >
> > The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014
> >
> > The vote is for all three changes as one single change. Partial votes
> (e.g.
> > for the logo but not the mascot, or vice-versa) will not be counted.
> >
> > I, as the caller of the vote, reserve the right to cancel the vote if
> this
> > vote is putting the harmony of the community at risk.
> >
> > If a majority of the PMC believe that this vote is putting the harmony of
> > the community at risk, then the PMC may cancel this vote (though if even
> a
> > small minority of the PMC were of that belief, I will more than likely
> have
> > cancelled the vote before the PMC would need to decide... I'm just
> stating
> > this FTR)
> >
> > The decision will be a simple majority, there will be no special veto
> > powers.
> >
> > +1: [ ] Change the logo to the proposed logo and adopt the owl as project
> > mascot
> > 0: [ ] No opinion
> > -1: [ ] No change
> >
> > Please only respond with +1, 0 or -1. If you want to discuss the proposed
> > changes please use a different thread. This thread is for voting only.
> >
> > -Stephen
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] removing Maven 3.1.1 from proposed downloads

[Baptiste Mathus]

> no outstanding change in 3.2.x that blocks 3.1.x users from upgrading to
3.2.x, isn't it?

Didn't double checked, but IIRC 3.1.1 still uses JDK5. 3.2.x uses JDK 6.
That may be a change you want to have in mind, though I personally don't
care about JDK 5.

+1 indeed.

Cheers

Le mer. 29 oct. 2014 03:24, Hervé BOUTEMY  a écrit :


we currently propose 3 versions: 3.0.5, 3.1.1 and 3.2.3
which suppose we may release 3.0.6, 3.1.2 and 3.2.4 in the future

I see why we would release 3.0.6: Aether change force some users to stay to
3.0.x, and I started to define some backports I'd like to put in it [1]

But I don't see why we would release 3.1.2: AFAIK, there is no outstanding
change in 3.2.x that blocks 3.1.x users from upgrading to 3.2.x, isn't it?


Then IMHO, we should remove 3.1.1 from top download links, and only propose
3.0.5 and 3.2.3
This wouldn't only make our roadmap easier to understand

Any objection?

Hervé

[1]
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20703

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.2.2

[Baptiste Mathus]

+1 (non-binding)


2014-06-20 15:41 GMT+02:00 Jason van Zyl :

> Ok, I'll summarize the results over the weekend, write up the release
> notes and roll it out over the weekend.
>
> On Jun 20, 2014, at 3:30 AM, Arnaud Héritier  wrote:
>
> > +1
> >
> > Tested on several projects for few days and no issue encountered
> >
> >
> > On Fri, Jun 20, 2014 at 8:51 AM, Olivier Lamy  wrote:
> >
> >> +1
> >>
> >> --
> >> Olivier
> >> On Jun 18, 2014 2:04 AM, "Jason van Zyl"  wrote:
> >>
> >>> Hi,
> >>>
> >>> Time to release Maven 3.2.2!
> >>>
> >>> Here is a link to Jira with 27 issues resolved:
> >>>
> >>>
> >>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20042
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-1025/
> >>>
> >>> The distributable binaries and sources for testing can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1025/org/apache/maven/apache-maven/3.2.2/
> >>>
> >>> Specifically the zip, tarball, and source archives can be found here:
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1025/org/apache/maven/apache-maven/3.2.2/apache-maven-3.2.2-bin.zip
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1025/org/apache/maven/apache-maven/3.2.2/apache-maven-3.2.2-bin.tar.gz
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1025/org/apache/maven/apache-maven/3.2.2/apache-maven-3.2.2-src.zip
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1025/org/apache/maven/apache-maven/3.2.2/apache-maven-3.2.2-src.tar.gz
> >>>
> >>> Source release checksum(s):
> >>> apache-maven-3.2.2-src.zip sha1:
> c4017fa1f4f2f203c132d5168b0c0eed4c4fdf9c
> >>>
> >>> Staging site:
> >>> http://people.apache.org/~jvanzyl/maven-3.2.2/
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>> Thanks,
> >>>
> >>> The Maven Team
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
>
>
>
>
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: ETA for maven-scm 1.10 ?

[Baptiste Mathus]

Sorry for the lag. 1.9.1 would be perfect anyway :). Though my other
message also shows I actually missed a step :).
Thanks


2014-06-02 19:36 GMT+02:00 Robert Scholte :

>
> Hi,
>
> Looks more like a 1.9.1 to me[1]
>
> There are still some issues open which were marked to be fixed with 1.10[2]
>
> Robert
>
> btw, Arnaud came with a nice tweet: https://twitter.com/aheritier/
> status/473393039302733824
>
>
> [1] https://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&jqlQuery=project+%3D+SCM+AND+fixVersion+%3D+%
> 221.10%22+AND+status+%3D+Closed+ORDER+BY+priority+DESC&mode=hide
> [2] https://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&jqlQuery=project+%3D+SCM+AND+fixVersion+%3D+%
> 221.10%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide
>
>
>
> Op Mon, 02 Jun 2014 16:26:32 +0200 schreef Baptiste Mathus  >:
>
>
>  Hi everybody,
>>
>> Just wanted to ask if someone in the Maven team was planning to do a
>> release of maven-scm in the upcoming weeks?
>>
>> I'm personnally waiting for some small improvements and be very glad to be
>> able to use it in a released version.
>>
>> FWIW, I just checked and there're 41 commits since last 1.9 release.
>> $ git log --oneline maven-scm-1.9..master | wc -l
>> 41
>>
>> Thanks a lot!
>>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

SCM-741 followup and ValidateMojo requiresProject=false

[Baptiste Mathus]

Hi all,

I've just discovered something with Maven that was not obvious to me. As
this seems a wee bit weird, I wanted to ask here about the behaviour.

I was unaware that, IIUC:
*"Mojos declaring requiresProject=false, even when ran inside a multimodule
project, will actually run non recursively".*

Does this statement seem perfectly normal to you?

I for one was actually very surprised. Anyway.

What I need is a way to recursively validate  (svn, currently)
information on a big multimodule project.

If the above is indeed normal, is the right way to just create a new Mojo
like *ValidateProjectMojo extends ValidateMojo* that would redefine
requiresProject to true to run recursively as I need it to do?

Thanks for your hints.

-- 
Baptiste

ETA for maven-scm 1.10 ?

[Baptiste Mathus]

Hi everybody,

Just wanted to ask if someone in the Maven team was planning to do a
release of maven-scm in the upcoming weeks?

I'm personnally waiting for some small improvements and be very glad to be
able to use it in a released version.

FWIW, I just checked and there're 41 commits since last 1.9 release.
$ git log --oneline maven-scm-1.9..master | wc -l
41

Thanks a lot!
-- 
Baptiste

Re: Github pull requests for Maven Core

[Baptiste Mathus]

Hi,

What do you mean by "squashing" commits?

Do you mean:
*  intermediate crappy/local commits that were incorrectly pushed as-is
without having been "rebased interactively" to provide a clean and
understandable history (see the link provided by Hervé as an example)
* or that any PR should be squashed into one and only one commit?

I totally agree with the first proposition, but would disagree with the
latter.

Thanks for the clarification.


2014-05-30 15:57 GMT+02:00 Jason van Zyl :

> I'm happy to look at pull requests but in the future can anyone making a
> pull request please squash your commits before making the pull request.
>
> Eventually I want to use Gerrit and create a mechanism where pull requests
> can be tested against the ITs to make it easier for contributors to know
> they haven't broken anything.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> We know what we are, but know not what we may be.
>
>   -- Shakespeare
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: [FYI] maven-scm-plugin IT is failing since Feb 25

[Baptiste Mathus]

+1 with Robert's solution (though I don't remember it was the actual issue
for that ci build failure some weeks ago...).

That's something I've also been planning to do after working recently with
buildnumber. BTW, not sure yet why, but sometimes IT won't fail doing a svn
info under the hood although the error message "... Please upgrade your
working copy" has been displayed. Will have to check if the error
swallowing comes from maven-scm or buildnumber itself.
Cheers
Le 7 mai 2014 00:15, "Hervé BOUTEMY"  a écrit :

>
> I think Roberts' idea about "svu upgrade"ing is good
> just need to revert locally and test, or we'll get the same problem in some
> time, when svn 1.9 is out
>
> Regards,
>
> Hervé
>
> Le mardi 6 mai 2014 15:00:58 Dan Tran a écrit :
> > Thanks Hervé, it works on my local windows build with svn client 1.8.5
> >
> > -D
> >
> > On Tue, May 6, 2014 at 2:30 PM, Hervé BOUTEMY 
> wrote:
> > > I updated content to svn 1.8: not really a long term solution, but at
> > > least
> > > give us time to find a better solution
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le lundi 5 mai 2014 23:43:45 Dan Tran a écrit :
> > > > perhaps, we need to disable this specific test for now?
> > > >
> > > > -D
> > > >
> > > > On Mon, May 5, 2014 at 9:18 PM, Dan Tran  wrote:
> > > > > Looks like we stuck without a new snapshot until this is fixed!!
> > > > >
> > > > > -D
> > > > >
> > > > > On Mon, May 5, 2014 at 6:49 PM, Hervé BOUTEMY
> > >
> > > wrote:
> > > > >> seems related to SCM-741: the IT added contains a copy of .svn
> > > > >> content
> > > > >> taken
> > > > >> from svn 1.7 (format 29), and I suppose Jenkins uses svn 1.8 which
> > >
> > > has a
> > >
> > > > >> different one (format 31)
> > > > >>
> > > > >> don't know how wa can improve the IT to be more tolerant to svn
> > >
> > > version
> > >
> > > > >> updates
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Hervé
> > > > >>
> > > > >> Le lundi 5 mai 2014 09:03:37 Dan Tran a écrit :
> > > > >> > change list  https://builds.apache.org/job/maven-scm/changes
> > > > >> >
> > > > >> > -D
> > > > >> >
> > > > >> > On Mon, May 5, 2014 at 9:01 AM, Dan Tran 
> wrote:
> > > > >> > > https://builds.apache.org/job/maven-scm/
> > > > >> > >
> > > > >> > > Thanks
> > > > >> > >
> > > > >> > > -D
> > > > >>
> > > > >>
> -
> > > > >> 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: [Committer School] ARCHETYPE-456

[Baptiste Mathus]

ne of its
> > dependencies could not be resolved: Could not find artifact
> > org.apache.maven.archetype:archetype-packaging:jar:2.3-SNAPSHOT in
> > local.central (file:///Users/stephenc/.m2/repository)
> > at
> >
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:208)
> > at
> >
> org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:380)
> > at
> >
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:239)
> > at
> >
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:110)
> > at
> >
> org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:43)
> > at
> >
> org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1069)
> > at
> >
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:385)
> > at
> >
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:368)
> > at
> >
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:561)
> > at
> >
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:353)
> > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:672)
> > at
> >
> org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:663)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:250)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> > at
> >
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > Caused by: org.eclipse.aether.resolution.ArtifactResolutionException:
> > Could not find artifact
> > org.apache.maven.archetype:archetype-packaging:jar:2.3-SNAPSHOT in
> > local.central (file:///Users/stephenc/.m2/repository)
> > at
> >
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:459)
> > at
> >
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)
> > at
> >
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:367)
> > at
> >
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:200)
> > ... 24 more
> > Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could
> > not find artifact
> > org.apache.maven.archetype:archetype-packaging:jar:2.3-SNAPSHOT in
> > local.central (file:///Users/stephenc/.m2/repository)
> > at
> >
> org.eclipse.aether.connector.wagon.WagonRepositoryConnector$6.wrap(WagonRepositoryConnector.java:1012)
> > at
> >
> org.eclipse.aether.connector.wagon.WagonRepositoryConnector$6.wrap(WagonRepositoryConnector.java:1004)
> > at
> >
> org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:725)
> > at
> >
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:744)
> > [ERROR] Unknown packaging: maven-archetype @ line 29, column 14
> > [ERROR]
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions,
> > please read the following articles:
> > [ERROR] [Help 1]
> >
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> > [ERROR] [Help 2]
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> >
>
> Thus while the patch will pass tests from a polluted local repo as soon as
> somebody tries to cut the official release, release:prepare will barf out.
>
> The tests need tweaking
>
>
> On 28 April 2014 12:35, Baptiste Mathus  wrote:
>
> > Hi all,
> >
> > http://jira.codehaus.org/browse/ARCHETYPE-456
> >
> > If you think anything is missing or disagree with the issue rationale,
> just
> > let know. We're currently having a local release for that patch and I'd
> be
> > really happy to know I'll be able to get rid of it some day (or not ;-)).
> >
> > Thanks
> >
> > --
> > Baptiste
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Committer School] ARCHETYPE-456

[Baptiste Mathus]

Hi all,

http://jira.codehaus.org/browse/ARCHETYPE-456

If you think anything is missing or disagree with the issue rationale, just
let know. We're currently having a local release for that patch and I'd be
really happy to know I'll be able to get rid of it some day (or not ;-)).

Thanks

-- 
Baptiste

Re: "Not a local repository. It is a local repository cache." (was: Fwd: Why Is Maven Ignoring My Local Repo?)

[Baptiste Mathus]

I also think that installing locally is somehow to be seen as a hack. And
though I do it myself on a regular basis while developing, I indeed never
see it as a sustainable place for my artifacts, only deploy is (and still
temporary for non releases).

Yes, I think we should rename that tag.

And if not we should stop telling people it must not be seen as a
repository, but as a cache...
 Le 15 avr. 2014 11:32, "Igor Fedorenko"  a écrit :

>
>  currently works as both a cache or artifacts from
> remote repositories and as a repository of locally installed artifacts.
> Do you suggest we get rid of "locally installed" functionality (which I
> personally very much in favour) or you want to just change the name
> (which I think will be confusing)?
>
> --
> Regards,
> Igor
>
> On 2014-04-15, 4:53, Baptiste Mathus wrote:
>
>> Hi all,
>>
>> Wondering, though not strictly 4.0.0 restricted, shouldn't a decision be
>> made about that vocabulary and reflect this in the docs and settings.xml
>> tags and so on?
>>
>> I mean, I myself often explain it's not really a local repo, more a cache,
>> but the tag names and the docs makes it hard to spread the word.
>>
>> In settings.xml :  could be renamed to  or
>>  ?
>>
>> In the docs, e.g. https://maven.apache.org/pom.html there're many
>> references to a "local repository".
>>
>> WDYT?
>>
>> Cheers
>>
>> -- Forwarded message --
>> From: Stephen Connolly 
>> Date: 2014-04-15 10:12 GMT+02:00
>> Subject: Re: Why Is Maven Ignoring My Local Repo?
>> To: Maven Users List 
>>
>>
>> It's not a local repository. It is a local repository cache.
>>
>> There are files there that record where the artifacts were cached *from*.
>>
>> If the artifact is there but the cache file is not or indicates a
>> different
>> source from the allowed sources for your build, then Maven will ignore the
>> artifact in your cache and check the remote sources.
>>
>>
>> On 15 April 2014 02:02, Eric Kolotyluk  wrote:
>>
>>  I seem to keep running into this problem regularly for things not in
>>> Maven
>>> Central
>>>
>>> [ERROR] Failed to execute goal
>>>
>> org.apache.maven.plugins:maven-site-plugin:3.3:site
>>
>>> (default-site) on project csharp-windows-elevate: Execution default-site
>>>
>> of
>>
>>> goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Plugin
>>> org.apache.maven.plugins:maven-site-plugin:3.3 or one of its
>>> dependencies
>>> could not be resolved: Could not find artifact
>>>
>> net.trajano.wagon:wagon-git:jar:1.0.1-SNAPSHOT
>>
>>> in local-nexus (http://localhost:8081/nexus/content/groups/public) ->
>>> [Help 1]
>>>
>>> I can see the artifact in my local repo, but maven somehow feels, because
>>> it cannot find it in my nexus repository, then it does not exist.
>>>
>>> The side problem is, even though nexus can see the artifact in its index,
>>> it refuses to download it.
>>>
>>> Why do maven and nexus work so hard at ignoring artifacts?
>>>
>>> Cheers, Eric
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-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 Indexer code to git?

[Baptiste Mathus]

Wouldn't be the solution to just remove the svn trunk & branches, and only
leave the tags in the last revision?

Or intermediately, leave the trunk path to be found, but remove anything
but that file "MOVED_TO_GIT"?


2014-04-16 22:31 GMT+02:00 Mirko Friedenhagen :

>
> +1 for Git and please include the new repository location in the
> MOVED_TO_GIT file as suggested by Dennis :-)
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Wed, Apr 16, 2014 at 9:20 PM, Dennis Lundberg 
> wrote:
> > Hi
> >
> > No objections from me, but a request.
> >
> > Please put a file in the root of the old svn repo called MOVED_TO_GIT or
> > something similar, so that it is clear that it has moved. I wasted some
> > time the other week trying to commit to plugin-testing before I realized
> > that the svn repo was read-only...
> >
> > --
> > Dennis Lundberg
> > Den 15 apr 2014 08:40 skrev "Olivier Lamy" :
> >
> >> Hi,
> >>
> >> Someone with a strong opposition to move maven-indexer code to git?
> >> If no one complains within 72H, I will ask migration to infra.
> >>
> >> Cheers,
> >> --
> >> 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
> >>
> >>
>
> -
> 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 !

"Not a local repository. It is a local repository cache." (was: Fwd: Why Is Maven Ignoring My Local Repo?)

[Baptiste Mathus]

Hi all,

Wondering, though not strictly 4.0.0 restricted, shouldn't a decision be
made about that vocabulary and reflect this in the docs and settings.xml
tags and so on?

I mean, I myself often explain it's not really a local repo, more a cache,
but the tag names and the docs makes it hard to spread the word.

In settings.xml :  could be renamed to  or
 ?

In the docs, e.g. https://maven.apache.org/pom.html there're many
references to a "local repository".

WDYT?

Cheers

-- Forwarded message --
From: Stephen Connolly 
Date: 2014-04-15 10:12 GMT+02:00
Subject: Re: Why Is Maven Ignoring My Local Repo?
To: Maven Users List 


It's not a local repository. It is a local repository cache.

There are files there that record where the artifacts were cached *from*.

If the artifact is there but the cache file is not or indicates a different
source from the allowed sources for your build, then Maven will ignore the
artifact in your cache and check the remote sources.


On 15 April 2014 02:02, Eric Kolotyluk  wrote:

> I seem to keep running into this problem regularly for things not in Maven
> Central
>
> [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:site
> (default-site) on project csharp-windows-elevate: Execution default-site
of
> goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed: Plugin
> org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies
> could not be resolved: Could not find artifact
net.trajano.wagon:wagon-git:jar:1.0.1-SNAPSHOT
> in local-nexus (http://localhost:8081/nexus/content/groups/public) ->
> [Help 1]
>
> I can see the artifact in my local repo, but maven somehow feels, because
> it cannot find it in my nexus repository, then it does not exist.
>
> The side problem is, even though nexus can see the artifact in its index,
> it refuses to download it.
>
> Why do maven and nexus work so hard at ignoring artifacts?
>
> Cheers, Eric
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Why is dependency:unpack evil

[Baptiste Mathus]

FWIW, we've used that in the past to store and version our PMD & checkstyle
rules configs for the organization for example. IMO, indeed more maven-ish
in the sense that you only describe the resource you need (/what/), but not
the /how/ (which scripting-like things like dependency:unpack tends to do).

HTH


2014-04-14 15:05 GMT+02:00 Dominik Bartholdi :

>
> Thanks Babtiste,
> I never used the m-remote-resource-p so far, but after reading through the
> docu it seem to fit into my needs.
> …maybe the name is a bit misleading - I think m-shared-resources-p would
> disci be it a lot better.
> I’ll take a closer look at it and if it fits, I have to start a lengthy
> discussion in our organization :)
> Domi
>
> On 14.04.2014, at 14:20, Baptiste Mathus  wrote:
>
> > Sorry, coming in a bit late here, but isn't is more a use-case for
> > m-remote-resources-p?
> >
> > Cheers
> >
> >
> > 2014-04-13 15:43 GMT+02:00 Dominik Bartholdi :
> >
> >> We use the dependency:unpack to get hold on a couple of WSDL files
> >> packaged within a WAR (or jar, zip).
> >> These WSDLs the are the input to generate the client site code with
> >> jaxws-m-p - coping these files into our repo is definitely nothing we
> want
> >> to do and accessing these files nine via http is not an option either.
> >> Domi
> >>
> >>
> >> On 12.04.2014, at 18:38, Jason van Zyl  wrote:
> >>
> >>> On Apr 12, 2014, at 11:32 AM, Benson Margulies 
> >> wrote:
> >>>
> >>>>
> >>>> I'm much more here. For example, I might have 250,000 words of text
> >>>> annotated for training a statistical model. I have a maven build that
> >>>> needs to grab unpack that pile into some location, run a plugin that
> >>>> performs some data normalization, and then feed the location into a
> >>>> maven plugin of mine that trains the model.
> >>>
> >>> This definitively seems like the wrong place to do this, in the build
> >> system. This is not a build time activity, it seems like part of an ETL
> >> flow of a data acquisition application.
> >>>
> >>>> I guess I could model this
> >>>> as dependencies, if the scope system allowed me to manage all of this
> >>>> at a safe distance from the classpath, but as it is it works fine as
> >>>> 'putting together a bunch of files.'
> >>>
> >>> The question is why would you model something like this at all in
> Maven.
> >> Just because you might be able to doesn't mean you should. You can, but
> >> your specific use case doesn't seem appropriate for a build system.
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> I think that Hervé is trying to help me by suggesting that I
> shouldn't
> >>>>>> need the dependency: that just calling out the coordinates to
> >>>>>> something like :unpack should result in resolution via injection.
> >>>>>>
> >>>>>> Then what changes?
> >>>>>>
> >>>>>>
> -
> >>>>>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> ---------
> >>>> 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
> >>> -
> >>>
> >>> Our achievements speak for themselves. What we have to keep track
> >>> of are our failures, discouragements and doubts. We tend to forget
> >>> the past difficulties, the many false starts, and the painful
> >>> groping. We see our past achievements as the end result of a
> >>> clean forward thrust, and our present difficulties as
> >>> signs of decline and decay.
> >>>
> >>> -- Eric Hoffer, Reflections on the Human Condition
> >>
> >>
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
>
>
> -
> 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: Why is dependency:unpack evil

[Baptiste Mathus]

Sorry, coming in a bit late here, but isn't is more a use-case for
m-remote-resources-p?

Cheers


2014-04-13 15:43 GMT+02:00 Dominik Bartholdi :

> We use the dependency:unpack to get hold on a couple of WSDL files
> packaged within a WAR (or jar, zip).
> These WSDLs the are the input to generate the client site code with
> jaxws-m-p - coping these files into our repo is definitely nothing we want
> to do and accessing these files nine via http is not an option either.
> Domi
>
>
> On 12.04.2014, at 18:38, Jason van Zyl  wrote:
>
> > On Apr 12, 2014, at 11:32 AM, Benson Margulies 
> wrote:
> >
> >>
> >> I'm much more here. For example, I might have 250,000 words of text
> >> annotated for training a statistical model. I have a maven build that
> >> needs to grab unpack that pile into some location, run a plugin that
> >> performs some data normalization, and then feed the location into a
> >> maven plugin of mine that trains the model.
> >
> > This definitively seems like the wrong place to do this, in the build
> system. This is not a build time activity, it seems like part of an ETL
> flow of a data acquisition application.
> >
> >> I guess I could model this
> >> as dependencies, if the scope system allowed me to manage all of this
> >> at a safe distance from the classpath, but as it is it works fine as
> >> 'putting together a bunch of files.'
> >
> > The question is why would you model something like this at all in Maven.
> Just because you might be able to doesn't mean you should. You can, but
> your specific use case doesn't seem appropriate for a build system.
> >
> >>
> >>>
> >>>
> >>>> I think that Hervé is trying to help me by suggesting that I shouldn't
> >>>> need the dependency: that just calling out the coordinates to
> >>>> something like :unpack should result in resolution via injection.
> >>>>
> >>>> Then what changes?
> >>>>
> >>>> -
> >>>> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> -
> >> 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
> > -
> >
> > Our achievements speak for themselves. What we have to keep track
> > of are our failures, discouragements and doubts. We tend to forget
> > the past difficulties, the many false starts, and the painful
> > groping. We see our past achievements as the end result of a
> > clean forward thrust, and our present difficulties as
> > signs of decline and decay.
> >
> > -- Eric Hoffer, Reflections on the Human Condition
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Releasing maven-buildnumber-plugin as-is?

[Baptiste Mathus]

Hi Michael,

Any ETA for MBUILDNUM-101 you wanted to try and tackle?

Cheers


2014-03-19 22:18 GMT+01:00 Baptiste Mathus :

> Hi,
> For reference which JIRA would you like to handle?
>
> I'll wait at least for your answer before starting the release.
>
> Cheers
>
>
> 2014-03-18 22:02 GMT+01:00 Baptiste Mathus :
>
> Sure.
>>
>> And about account creation for JIRA, you have to go through
>> http://xircles.codehaus.org to create it (this account will be usable on
>> all codehaus tools where rights are granted).
>>
>> For the record, as the account creation is not obvious anymore and as we
>> often receive this request, I've filed
>> http://jira.codehaus.org/browse/HAUS-2368.
>>
>> Cheers
>>
>>
>> 2014-03-18 20:19 GMT+01:00 Anders Hammar :
>>
>> Attach a patch to the ticket and I'm sure Baptiste, or someone else, can
>>> apply it before release.
>>>
>>> /Anders
>>>
>>>
>>> On Tue, Mar 18, 2014 at 8:17 PM, Michael Osipov 
>>> wrote:
>>>
>>> > Am 2014-03-18 15:29, schrieb Baptiste Mathus:
>>> >
>>> >> Hi,
>>> >>
>>> >> There seems to be a need for a release for buildnumber with
>>> @threadSafe
>>> >> added.
>>> >> https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups.
>>> >>
>>> >> I can act as RM if nobody objects against this release now. That'll
>>> help
>>> >> users.
>>> >>
>>> >> If anyone wants to try and tackle some more things on this plugin,
>>> just
>>> >> let
>>> >> me know we can obviously wait.
>>> >>
>>> >
>>> > Actually, I would want to fix one issue but I do not have the
>>> permission
>>> > in JIRA nor do I have write access to that repo.
>>> >
>>> > Michael
>>> >
>>> > -
>>> > 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 !
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Operating system requirement

[Baptiste Mathus]

+1, my repo is about 1.3GB so saying "500+ MB or more depending on your
usage" seems sensible.




2014-03-28 13:09 GMT+01:00 Anders Hammar :

> > The requirements also says:
> >
> > "Disk No minimum requirement. Approximately 100MB will be used for
> > your local repository, however this will vary depending on usage ..."
> >
> > AFAICT there _is_ a minimum requirement which is needed to store a
> > basic set of plugins.
> > And of course there is the Maven application itself, though that is
> > tiny (under 6Mb for 3.0.5)
> >
> > 100MB is quite a small repository; they can easily grow to 1GB or more.
> >
>
> So you think we should change to for example:
> "Approximately 10MB is required for the Maven installation itself. In
> addition to that, additional disk space will be used for your local Maven
> repository. The size of your local repository will vary depending on usage
> but calculate for at least 500MB."
>
> Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is even
> smaller. Stating approx 10MB will give us some space.
>
> My local repo is 1.5GB so I'm guessing an average dev would need at least
> 500MB.
>
> ok?
>
> /Anders
>
>
> >
> > > /Anders
> > >
> > > [1] http://maven.apache.org/download.cgi#Requirements
> >
> > -----
> > 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 !

Getting back maven-scm build to green?

[Baptiste Mathus]

Hi,

To stay on the track of Mirko's last email, my original PR for SCM-741 [1]
seems to make the IT fail in maven-scm CI [2].

After analyzing the failure logs, I've created another PR that should
hopefully fix the issue (first PR worked locally, but the issue seems
specific to CI env) :
https://github.com/apache/maven-scm/pull/11

If someone can have a look, I'll be glad to help if anything else is
necessary.

Cheers

[1] https://github.com/apache/maven-scm/pull/8
[2] https://builds.apache.org/job/maven-scm

-- 
Baptiste

Re: Model Version 5.0.0

[Baptiste Mathus]

FWIW, I'm aware it's easily feasible to add that checksum validation in a
plugin, but you'll still have to repeat the coordinates.
And that very thing was my point: I don't think having to repeat those
coordinates to add metadata is great.

Not even saying this *must* go in modelVersion 5, I just wanted that debate
to happen at least for future reference if people wonder why maven pom
can't store that dependency metadata (DRY'ly alongside its data, I mean).

Cheers


2014-03-25 6:36 GMT+01:00 Dominik Bartholdi :

>
> 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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Model Version 5.0.0

[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'

Re: Model Version 5.0.0

[Baptiste Mathus]

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

[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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Releasing maven-buildnumber-plugin as-is?

[Baptiste Mathus]

Hi,
For reference which JIRA would you like to handle?

I'll wait at least for your answer before starting the release.

Cheers


2014-03-18 22:02 GMT+01:00 Baptiste Mathus :

> Sure.
>
> And about account creation for JIRA, you have to go through
> http://xircles.codehaus.org to create it (this account will be usable on
> all codehaus tools where rights are granted).
>
> For the record, as the account creation is not obvious anymore and as we
> often receive this request, I've filed
> http://jira.codehaus.org/browse/HAUS-2368.
>
> Cheers
>
>
> 2014-03-18 20:19 GMT+01:00 Anders Hammar :
>
> Attach a patch to the ticket and I'm sure Baptiste, or someone else, can
>> apply it before release.
>>
>> /Anders
>>
>>
>> On Tue, Mar 18, 2014 at 8:17 PM, Michael Osipov 
>> wrote:
>>
>> > Am 2014-03-18 15:29, schrieb Baptiste Mathus:
>> >
>> >> Hi,
>> >>
>> >> There seems to be a need for a release for buildnumber with @threadSafe
>> >> added.
>> >> https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups.
>> >>
>> >> I can act as RM if nobody objects against this release now. That'll
>> help
>> >> users.
>> >>
>> >> If anyone wants to try and tackle some more things on this plugin, just
>> >> let
>> >> me know we can obviously wait.
>> >>
>> >
>> > Actually, I would want to fix one issue but I do not have the permission
>> > in JIRA nor do I have write access to that repo.
>> >
>> > Michael
>> >
>> > -
>> > 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: Releasing maven-buildnumber-plugin as-is?

[Baptiste Mathus]

Sure.

And about account creation for JIRA, you have to go through
http://xircles.codehaus.org to create it (this account will be usable on
all codehaus tools where rights are granted).

For the record, as the account creation is not obvious anymore and as we
often receive this request, I've filed
http://jira.codehaus.org/browse/HAUS-2368.

Cheers


2014-03-18 20:19 GMT+01:00 Anders Hammar :

> Attach a patch to the ticket and I'm sure Baptiste, or someone else, can
> apply it before release.
>
> /Anders
>
>
> On Tue, Mar 18, 2014 at 8:17 PM, Michael Osipov 
> wrote:
>
> > Am 2014-03-18 15:29, schrieb Baptiste Mathus:
> >
> >> Hi,
> >>
> >> There seems to be a need for a release for buildnumber with @threadSafe
> >> added.
> >> https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups.
> >>
> >> I can act as RM if nobody objects against this release now. That'll help
> >> users.
> >>
> >> If anyone wants to try and tackle some more things on this plugin, just
> >> let
> >> me know we can obviously wait.
> >>
> >
> > Actually, I would want to fix one issue but I do not have the permission
> > in JIRA nor do I have write access to that repo.
> >
> > Michael
> >
> > ---------
> > 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: Releasing maven-buildnumber-plugin as-is?

[Baptiste Mathus]

@Anders: sure, I know and I'm sorry, that was unintended. Both lists start
with dev@ I wasn't cautious enough :).



2014-03-18 15:46 GMT+01:00 jieryn :

>
> I've been running a local release of this plugin internally for a
> while now, no problems detected.
>
> Than you, Baptiste!
>
> On Tue, Mar 18, 2014 at 10:29 AM, Baptiste Mathus 
> wrote:
> > Hi,
> >
> > There seems to be a need for a release for buildnumber with @threadSafe
> > added.
> > https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups.
> >
> > I can act as RM if nobody objects against this release now. That'll help
> > users.
> >
> > If anyone wants to try and tackle some more things on this plugin, just
> let
> > me know we can obviously wait.
> >
> > Cheers
> >
> > -- Baptiste
>
> -----
> 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 !

Releasing maven-buildnumber-plugin as-is?

[Baptiste Mathus]

Hi,

There seems to be a need for a release for buildnumber with @threadSafe
added.
https://jira.codehaus.org/browse/MBUILDNUM-115 and its dups.

I can act as RM if nobody objects against this release now. That'll help
users.

If anyone wants to try and tackle some more things on this plugin, just let
me know we can obviously wait.

Cheers

-- Baptiste

Re: MRELEASE-431

[Baptiste Mathus]

2014-03-13 19:19 GMT+01:00 Robert Scholte :

> To say it in your own words: IMHO I think you're wrong here ;)
>
> Version policy is about calculating the next version based on an input
> version.
> These are valid examples:
> default policy:
> getReleaseVersion("1-SNAPSHOT") = 1
> getReleaseVersion("1.0-SNAPSHOT") = 1.0
> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
> getDevelopmentVersion("1") = 2-SNAPSHOT
> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
>
> odd-even
> getReleaseVersion("1.0-SNAPSHOT") = 1.1
> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
>
> the metadata gives the following opportunity:
> suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
> you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 ->
> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
>
> I think it's weird to depend the policy on the GAV. Just choose a proper
> policy for your project.
>

FWIW, I'm also interested by this feature to further standardize our
release process. And we'd ideally need at least the artifactId to be able
to calculate the next developmentVersion. To make it short, the suffix of
our artifactIds describe if it's an internal implementation project, or if
it's an globally visible interface.

In the second case, since this is a publicly published/used, the versioning
is not the same and kind of more agressively checked (which seems similar
to what Simone is describing in their bytecode analysis approach).

HTH

-- Baptiste

Re: Convert everything to Git

[Baptiste Mathus]

Hi all,

Wondering, wouldn't maven-release be a good next candidate for a Git
migration?
I'm currently working locally with the maven-release github mirror, but
just had to checkout svn trunk to have a look at MRELEASE-431's robert's
current proposal (yes, I could've also git svn'ed it).

Cheers


2014-02-20 23:13 GMT+01:00 Fred Cooke :

> +
> +org.apache.maven.wagon
> +wagon-ssh-external
> +${extension.version.wagon}
> +
>
> It was SSH settings that were not being respected. Things like ports and
> ssh hosts vs DNS lookups, etc.
>
> There were other issues with multi-module-parents vs ONLY-parents vs
> aggregator poms. MRELEASE-814
>
> https://jira.codehaus.org/browse/MRELEASE-812
> https://jira.codehaus.org/browse/MRELEASE-815
>
> Other issues were m-site-p in terms of variables and inheritance and
> uploads, which work OK for general generation.
>
> IIRC the results of these bugs was that I had a lot of unwanted duplication
> of config that I couldn't inherit because it got mal-processed. Nothing
> worse, but duplication is evil and makes baby Jesus and other equally
> ordinary small children cry.
>
> Then there are things that are just generally broken and don't affect git
> worse than other SCMs
>
>  
>
> But I'm OT now.
>
> Fred.
>
>
> On Fri, Feb 21, 2014 at 10:58 AM, Mark Derricutt  wrote:
>
> > On 21 Feb 2014, at 10:27, Jason van Zyl wrote:
> >
> >  I only release core and that works fine which begs the question: do we
> >> want to normalize our repository structure to simplify the tooling
> >> requirements. What exactly doesn't work? Trying to release a single
> thing
> >> out of a repository containing many things?
> >>
> >
> > A stock m-r-p config will break using the latest releases of git ( due to
> > depending on an old version of the -scm- artefacts ) which I've mentioned
> > before, and I believe there are commits awaiting release to resolve this.
> >
> > m-r-p also _really_ likes to release from the root directory of a
> > repository, so doing independent releases from sub directories/modules is
> > difficult ( there is a setting which lets this work, but that's just
> > unpleasant ) - but due to git's tagging/branching being repository wide
> > just releasing an individual module really is unpleasant.
> >
> > Basically, if modules have a constant release cadence/version numbering
> > scheme, they can release together in a single repo, otherwise they should
> > be separate. This however I don't see as a "problem with git tooling in
> > maven" - just good practise.
> >
> > Mark
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: [gsoc] Is there a Maven opportunity for Google Summer of Code students?

[Baptiste Mathus]

Maybe contribute an detailed mode for a "maven profiler mode" feature
(using an eventspy for example). Say something that would display timing
informations about plugins executions durations and so on. Imo, this is
something everybody looks at when a build becomes longer.

I've seen implementations here and there, but doing something that would
make it into core (at least meaning in the standard distribution) in the
short term would definitely be something greatly useful and visible to
maven end users.
Le 10 mars 2014 14:45, "Benson Margulies"  a écrit :

> Realistically, look to plugins more than the core, if you ask me.
> There's the new not-quite-consumer-pom which might have a subtask. Or
> pick any of the common plugins and see what's out here.
>
> On Mon, Mar 10, 2014 at 9:42 AM, Carlos Sanchez  wrote:
> > There's a student interesting on doing the GSoC with the Maven project
> so I
> > was trying to figure out a meaningful project, not to small, not too
> large,
> > focusing on the top voted issues in jira.
> > But most of them are related to POM and profiles new
> features/improvements
> > which are not clearly defined/agreed on yet.
> >
> > Anyone has other suggestions?
> >
> > Cheers
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Developing Maven Archetype

[Baptiste Mathus]

Well, IMO an archetype is by definition something rarely used: you often
work on an existing project, but are unlikely to create a new one every day.
So, you may have a very specific use-case, and that is often the cause of
something not working the way one want on a specific situation.

I was talking about templating-m-p in Eclipse because I thought you may
somehow be able to use the m2e.version property to activate a special dev
profile that would for example define your archetype sources as the source
for filtering, re/define some kind of hardcoded dev properties and so on to
be able to iterate inside the IDE. Not that clean, sounding a bit hacky as
I said, but may seem acceptable since it's only for use when the project is
open in the IDE.

You also have to develop your archetype's ITs to ensure it keeps working
[1]. But I suppose you already do so.

Cheers

-- Baptiste
[1]
https://maven.apache.org/archetype/maven-archetype-plugin/integration-test-mojo.html


2014-03-09 22:06 GMT+01:00 Petar Tahchiev :

> Hello,
>
> thanks for your responses. Yes, unforutnately, I do need parameterized Java
> code (package names, classnames, also xml files, etc..). As I said it's
> pretty complicated project.
> I looked at templating-maven-plugin but it seems that filtering the
> standard src/main/java folder is not supported. Also, I may not understand
> the quite your suggestion, but using the templating-maven-plugin will also
> break Eclipse as I will be still having ${packageName} in my sources.
>
> I'm kind of surprised that no one else has had this problem before. Does
> this mean that the archetypes are only supposed to work with simple
> projects that are not continuously developed?
>
>
> 2014-03-09 22:50 GMT+02:00 Baptiste Mathus :
>
> > Just a quick thought, maybe using some hacky form of a development
> profile
> > using the templating-maven-plugin to filter those properties could help?
> >
> >
> > 2014-03-09 20:47 GMT+01:00 Benson Margulies :
> >
> > > Are you sure that you absolutely need parameterized Java code? There's
> > > really no good way to work with it. You could instead use the
> > > maven-shade-plugin to customer-ize your results as part of their
> > > build.
> > >
> > >
> > > On Sun, Mar 9, 2014 at 3:36 PM, Petar Tahchiev 
> > > wrote:
> > > > Hey guys,
> > > >
> > > > here's an interesting question: how do you develop your maven
> > > archetypes? I
> > > > have a web-project that consists of lots of controllers and jsps,
> and I
> > > > have been developing this for a long time, and I want to keep
> > developing
> > > > it. I also want to provide this project to my clients as an archetype
> > so
> > > > they can be up-and-running as quickly as possible.
> > > >
> > > > I thought of creating an archetype from my project every time I
> release
> > > the
> > > > archetype, but that seems really unefficient as I release new
> versions
> > > very
> > > > often, and also the archetype is quite complicated.
> > > >
> > > > I also thought to create the archetype once, and keep developing it
> in
> > > > Eclipse, but that's not possible because for instance the package
> names
> > > > look like this:
> > > >
> > > > package ${packageName};
> > > >
> > > > and of-course Eclipse complains.
> > > >
> > > > So my questions is - if you have a complicated archetype that you
> keep
> > > > developing over time, how do you develop it? Is there an
> > Eclipse/IntelliJ
> > > > plugin for archetype developing?
> > > >
> > > > --
> > > > Regards, Petar!
> > > > Karlovo, Bulgaria.
> > > > ---
> > > > Public PGP Key at:
> > > >
> > >
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > > > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > >
> > > -
> > > 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 !
> >
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Developing Maven Archetype

[Baptiste Mathus]

Just a quick thought, maybe using some hacky form of a development profile
using the templating-maven-plugin to filter those properties could help?


2014-03-09 20:47 GMT+01:00 Benson Margulies :

> Are you sure that you absolutely need parameterized Java code? There's
> really no good way to work with it. You could instead use the
> maven-shade-plugin to customer-ize your results as part of their
> build.
>
>
> On Sun, Mar 9, 2014 at 3:36 PM, Petar Tahchiev 
> wrote:
> > Hey guys,
> >
> > here's an interesting question: how do you develop your maven
> archetypes? I
> > have a web-project that consists of lots of controllers and jsps, and I
> > have been developing this for a long time, and I want to keep developing
> > it. I also want to provide this project to my clients as an archetype so
> > they can be up-and-running as quickly as possible.
> >
> > I thought of creating an archetype from my project every time I release
> the
> > archetype, but that seems really unefficient as I release new versions
> very
> > often, and also the archetype is quite complicated.
> >
> > I also thought to create the archetype once, and keep developing it in
> > Eclipse, but that's not possible because for instance the package names
> > look like this:
> >
> > package ${packageName};
> >
> > and of-course Eclipse complains.
> >
> > So my questions is - if you have a complicated archetype that you keep
> > developing over time, how do you develop it? Is there an Eclipse/IntelliJ
> > plugin for archetype developing?
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>
> -
> 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: Branch the parent pom hierarchy for Java 1.6 + Maven 3

[Baptiste Mathus]

Le 23 févr. 2014 21:20, "Stephen Connolly" 
a écrit :
>
> On Sunday, 23 February 2014, Michael Osipov  wrote:
>
> > Am 2014-02-23 19:06, schrieb Benson Margulies:
> >
> >> I propose to make releases of our parent stack that are suitable for
> >> components and plugins that are making the leap to Java 1.6 and Maven
> >> 3 as their base requirements.
> >>
> >> What do people think is the right approach in terms of what stays on
> >> trunk and what goes on a branch, and whether to do anything
> >> distinctive to the version numbers?
> >>
> >
> > Finally, someone's stepping up for such a good change. Though, I think
> > some important stuff needs to be considered first:
> >
> > 1. Announce 2.x EOL and give people at least 3 months to switch.
>
>
> Already done and site updated

Was there also an announce on the users list? I couldn't find it. I think
it would also be a good thing to do.

Re: Java 1.5

[Baptiste Mathus]

+1 to dump Java5 compat. In about 2 months, even Java 6 will rapidly become
old. We're already using Java 1.7 at our shop, and plan to migrate to 1.8
asap. And we're really not a startup kind of company ;-). And I'm sure the
features in 1.8 (compared to the ones in the previous version) is gonna
accelerate the move. Sure you'll always companies where migration is said
to be hard, but any move being made would be considered hard to absorb by
those anyway... :)

Stephen, when talking about version policy in the current context, do you
mean something like "any plugin could from now on be released with 1.6+
requirement, you would just have to make sure to bump the MAJOR (or only
minor?) version number to acknowledge the change" ?


2014-02-22 21:26 GMT+01:00 Stephen Connolly :

> If a plugin depends on Maven 2.2.1 through 3.1.1 then we are stuck with
> Java 1.5
>
> Hence my version policy that you lot are all ignoring commenting on... No
> comments means I'll just put it up for a vote ;-)
>
> Sent from my iPhone
>
> > On 22 Feb 2014, at 20:10, "Arnaud Héritier"  wrote:
> >
> > ;) AFAIR for core yes. New releases (thus 3.2) should be certified 1.6+
> >
> >
> > For plugins it's another story I suppose depending of the version of
> maven core they are supposed to support..
> > —
> > Sent from Mailbox for iPhone
> >
> >> On Sat, Feb 22, 2014 at 9:04 PM, Jason van Zyl  wrote:
> >>
> >> Didn't we decide that everything can be 1.6? I remember because it was
> one of Stephen's overly long emails :-)
> >> jvz
> >>> On Feb 22, 2014, at 11:02 AM, Benson Margulies 
> wrote:
> >>>
> >>> How much longer with this Java 1.5 business? It' a giant pain.
> >>>
> >>> -
> >>> 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
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>

Re: [DISCUSS] Adopt a version policy and a support policy to go with it.

[Baptiste Mathus]

Le 21 févr. 2014 16:39, "Igor Fedorenko"  a écrit :
>
> I think this is reasonable.
>
> One observation. Maven does not have an API, plugins and projects can
> access pretty much anything from the core. Add to this three distinct
> user communities -- (end) users, plugin developers and embedders -- and
> I think pretty much any change will break somebody. This means that
> INCREMENTAL version component will be more or less reserved for release
> respins and many dependency changes will require MAJOR bump. Not saying
> there is anything wrong with this, just something we'll need to educated
> our users about.

Not sure it's really that feasible for maven core, but wouldn't be at least
a part of the solution to clarify what's considered internal and what's
considered API/SPI? Maybe renaming or moving some packages to ones
containing 'internal' or things like that?
At least
>
> --
> Regards,
> Igor
>
>
>
>
> On 2/21/2014, 10:10, Stephen Connolly wrote:
>>
>> For discussion... and tearing into... and Chris shouting out that IBM
>> supports Java 6 for yonks...
>>
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>>
>> I think we need a version policy and the best way to get one is to put a
>> draft together and let people edit it to something that we all can be
happy
>> with.
>>
>> Constructive feedback welcome... in fact committers editing the doc is
>> encouraged...
>>
>> Please leave the DRAFT heading at the top.
>>
>> If a consensus emerges we will have a vote and put the resulting policy
on
>> the project site as opposed to a draft document on the wiki.
>>
>> -Stephen
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: What is in a version? (was Towards faster releases)

[Baptiste Mathus]

version...
> > or perhaps just forgetting that the scope of patch/incremental versions
> is
> > what I suggest it is.
> >
> > So my question to the Maven developers is this:
> >
> > What types of things should be eligible for a patch/incremental release
> of
> > Maven?
> >
> > Is it "backwards-compatible bug fixes" only?
> >
> > Is it "backwards-compatible bug fixes and api improvements"?
> >
> > Is it "any bug fix and backwards-compatible api improvements"?
> >
> > Is it something else?
> >
> > Keep in mind that users out there could well be expecting something
> > semver-ish... as that is a meme that seems to me to be catching on...
> >
> > FYI: If the consensus view is different from `"backwards-compatible bug
> > fixes" only` then there is no point in pursuing my plan of weekly checks
> > for a new patch release and cutting such a release if it is releasable,
> and
> > I will drop them (we can keep the tooling I have put in place as it will
> > help improve our quality... and I intend improving that tooling anyway).
> > But if the consensus is that patch/incremental versions should be
> > `"backwards-compatible bug fixes" only` then I see no good reason why we
> > should hold onto those fixes any longer than a week after they have been
> > committed. New features can go straight into the 3.3.x branch and I (and
> > others) can cherry pick the fixes from the 3.3.x branch back to 3.2.x and
> > cut those releases when they are ready. (Which was what I thought my
> > proposal was... but re-reading I ack that it was not as obvious to the
> > reader as it was to the writer ;-) )
> >
> > -Stephen
> >
> >   [1]: http://semver.org/
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: RFC: http://jira.codehaus.org/browse/MASSEMBLY-681

[Baptiste Mathus]

Hi,
IIUC, you're talking about the injection difference that may be introduced
between an absent and empty tag.

If so, then by the way, the current situation is even worse than that :
putting "*"* or "*  "* results by default in
the same thing: considered unspecified, and so null (or default-value) is
injected.
(Unless you use the special  xml:space="preserve" attribute, only for
m3.1+, see [1] for example).

I think that it's something that should be considered at least for m4.
(or before, but not sure it's feasible to do it in a reasonably compatible
way [in modello I guess?]. Maybe with additional compatibility switches for
@Parameter, like defautValueBehaviour or something like that).

Currently, IMO the least surprise principle isn't respected.
As a user, for the build-helper:regex-property goal, for example. I can
specify a regex and a replacement.

When I say

   - "" [empty string/absent tag]"
   - ""
   - " "


I mean different things. And currently Maven will merge all those 3 cases
in one, as if the tag was left unspecified. For Maven usage, I would argue
only the first case should trigger the defaultValue injection.

So, to sum up, I agree with you. I think it's currently missing. Plugin
developers could still be explicitly allowed to ask Maven injection to
merge some of the cases above, but not as a default behaviour (or maybe
only before m4 with a warning).

[1]
https://svn.codehaus.org/mojo/trunk/mojo/build-helper-maven-plugin/src/it/mbuildhelper-34/pom.xml
coming
from MNG-5380


2014-02-17 12:21 GMT+01:00 Karl Heinz Marbaise :

> Hi,
>
> I have taken a deeper look into the above issue...
>
> In short:
> 
>   
> 
>
> If finalName is defined in configuration the name should be left
> empty...But here the problem is that the injection mechanism says ok the
> finalName is empty so we use the default value...
>
>
> From my point of view it looks like lacking some functionality which
> can be solved by using some code ...I have create an example project where
> i can handle thatOr it might be possible to add an option like
> noFinalNameto handle the situation
>
> But the question is: Do you think that's going into the right direction to
> support such functionality (which might occure in several plugins) or would
> be better to go a different way...
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -----
> 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: [VOTE] Release Maven 3.2.1

[Baptiste Mathus]

+1 (non-binding).


2014-02-16 4:59 GMT+01:00 Mark Derricutt :

> +1 here, seems to be working for all my projects.
>
> Don't seem to be getting the aether lock up either now, now I'm just
> suffering version-range hell of mixed feature branches there ( a hell of my
> own making ;p )
>
> Mark
>
>
> On 15 Feb 2014, at 6:58, Jason van Zyl wrote:
>
>  Specifically the zip, tarball, and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-
>> 1006/org/apache/maven/apache-maven/3.2.1/apache-maven-3.2.1-bin.zip
>>
>
> -
> 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: Convert everything to Git

[Baptiste Mathus]

OK.
But for the record, I was not (yet) proposing to release using the
submodule repo.

More the strategy proposed by Mark: use submodules 'just" to ease
retrieving a whole lot of projects under a working directory tree, and then
release project by project (=repo by repo) as-of today.
Anyway, I suppose that if this workflow was to become required/on the
critical path, this bug would receive more attention to get tackled.


2014-02-14 9:33 GMT+01:00 Tomasz Krakowiak :

> Are you aware that maven-release-plugin isn’t currently working with git
> submodules because of http://jira.codehaus.org/browse/SCM-530 ?
>
> (I’m just warning you, so you wouldn’t have painful surprise one day)
>
>
> Wiadomość napisana przez Hervé BOUTEMY  w dniu 14
> lut 2014, o godz. 09:19:
>
> > No doubt it can be done in general, but the question is on ASF
> (canonical) git
> > repo [1]
> > at the moment, everything seems flat
> > IMHO, some git expert should work with infra to make it more structured
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://git-wip-us.apache.org/repos/asf
> >
> > Le vendredi 14 février 2014 20:23:34 Fred Cooke a écrit :
> >> I have my private git repo setup in a nested way. No reason you
> couldn't do
> >> that the same for this.
> >>
> >> baseurl/org/apache/mvn/core/componentA.git
> >>
> >> etc.
> >>
> >> Unsure if this addresses your concerns or not, but it's certainly neat
> and
> >> tidy at the server end, and the user can duplicate the path structure
> the
> >> same at home.
> >>
> >> Fred.
> >>
> >> On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY  >wrote:
> >>> I'm not a git expert: if there are solutions, yes, they have to be
> found,
> >>> explained, tested, before we launch "convert everything to git"
> >>>
> >>> thank you for any good idea and then any tests from people wanting the
> >>> great
> >>> migration to happen (without wreaking havoc)
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit :
> >>>> Jenkins could build from a super-repo that uses git submodule.
> >>>>
> >>>> Since a quite a few versions ago, git-submodules can now follow a
> branch
> >>>> rather than a fixed SHA1.
> >>>>
> >>>> So you could build/test monolithically, branch/commit individually.
> >>>>
> >>>> Compromise maybe?
> >>>>
> >>>> On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote:
> >>>>> each entry would mean 1 git repo + 1Jenkins job (or even more, since
> >>>>> plugins
> >>>>> have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1
> >>>>> for Maven
> >>>>> 3.1.x)
> >>>>> IMHO, we're not ready for such granularity, neither at git nor
> Jenkins
> >>>>> level
> >>>>
> >>>> -
> >>>> 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
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: Convert everything to Git

[Baptiste Mathus]

git clone --recursive
https://github.com/Batmat/asciidoctor-maven-plugin-issue-494-html5-backend-not-working?


2014-02-14 9:21 GMT+01:00 Hervé BOUTEMY :

> found the doc: seems interesting
>
> any live example to show?
> or a demo on skins, for example, ie not much submodules, so it seems a good
> cancidate for tests
>
> Regards,
>
> Hervé
>
> Le vendredi 14 février 2014 08:46:32 Baptiste Mathus a écrit :
> > +1 on the submodule solution. We started using it some months ago since
> the
> > branch option came out.
> > As a simplistic analogy, you can see it as svn: externals equivalent.
> >
> > It helps developers (and ci configuration) to retrieve many related
> > projects in only one clone command.
> >
> > My 2 cents
> >
> > Le 14 févr. 2014 05:10, "Mark Derricutt"  a écrit :
> > > Jenkins could build from a super-repo that uses git submodule.
> > >
> > > Since a quite a few versions ago, git-submodules can now follow a
> branch
> > > rather than a fixed SHA1.
> > >
> > > So you could build/test monolithically, branch/commit individually.
> > >
> > > Compromise maybe?
> > >
> > > On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote:
> > >  each entry would mean 1 git repo + 1Jenkins job (or even more, since
> > >
> > >> plugins
> > >> have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1
> for
> > >> Maven
> > >> 3.1.x)
> > >> IMHO, we're not ready for such granularity, neither at git nor Jenkins
> > >> level
> > >
> > > -
> > > 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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Maven Issue - pluginManagement - build Area Plugin

[Baptiste Mathus]

Seems like this super pom is versioned at github under the sonatype
organization (?).

Cf. scm tag in
http://repo1.maven.org/maven2/org/codehaus/codehaus-parent/4/codehaus-parent-4.pom
But https://github.com/sonatype/codehaus-parent gives a 404...

Anyone?



2014-02-14 9:01 GMT+01:00 Karl Heinz Marbaise :

> Hi Anders,
>
>
> > I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
>
> Good to know...
>
>
>  Unfortunately the codehaus-parent seems to be in a unmaintained state.
>>
>
> Who is responsible for the codehaus-parent ? Can we (or i) take the issue
> and fix it ?
>
>
>
>> /Anders
>>
>> [1] http://jira.codehaus.org/i#browse/HAUS-2245
>>
>>
>> On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise > >wrote:
>>
>>  Hi,
>>> i have a question. The following situation. Pom file which uses the
>>> following parent:
>>>
>>>  
>>>  org.codehaus
>>>  codehaus-parent
>>>  4
>>>  
>>>
>>>  
>>>${mavenVersion}
>>>  
>>>
>>> and the following part in my pom file:
>>>
>>>  
>>>  
>>>  
>>>  
>>>  org.apache.maven.plugins
>>>  maven-enforcer-plugin
>>>  1.3.1
>>>  
>>>  
>>>  
>>>  
>>>  
>>>org.apache.maven.plugins
>>>maven-enforcer-plugin
>>>
>>>  
>>>enforce-maven
>>>
>>>... The rule does not matter..
>>>
>>>
>>> So if i call (Maven 2.2.1)
>>>
>>> mvn clean package I got the following error:
>>>
>>> [INFO] [clean:clean {execution: default-clean}]
>>> [INFO] 
>>> 
>>> [ERROR] BUILD ERROR
>>> [INFO] 
>>> 
>>> [INFO] Failed to configure plugin parameters for:
>>> org.apache.maven.plugins:
>>> maven-enforcer-plugin:1.0
>>>
>>> Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be
>>> instantiated
>>>
>>> So if i call with Maven 3.0.5:
>>>
>>> [ERROR] Failed to execute goal org.apache.maven.plugins:
>>> maven-enforcer-plugin:1.0:enforce (enforce-maven) on project
>>> test-enforcer: Unable to parse configuration of mojo
>>> org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for parameter
>>> requireSameVersions: Abstract class or interface
>>> 'org.apache.maven.enforcer.rule.api.EnforcerRule'
>>> cannot be instantiated -> [Help 1]
>>>
>>> Maven 3.1.X and Maven 3.2.X tested as well...
>>>
>>> So this looks to me that the pluginManagement does not overwrite the
>>> version 1.0 which is defined in the codehaus-parent. To be honest the
>>> codehaus-parent does not define it via pluginManagement it just uses the
>>> following:
>>>
>>> 
>>>  
>>>  
>>>  org.apache.maven.plugins
>>>  maven-enforcer-plugin
>>>  1.0
>>>  
>>>  
>>>  enforce-maven
>>>  
>>>  enforce
>>>  
>>>  
>>>  
>>>  
>>>
>>> (,2.1.0),(2.1.0,2.2.0),(2.2.0,)
>>>  Maven 2.1.0 and 2.2.0
>>> produce
>>> incorrect GPG signatures and checksums respectively.
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>
>>>
>>> First the codehaus-parent seemed to be wrong...so i can't overwrite the
>>> version of the plugin by using a pluginManagement block in inherited
>>> project which forces me to define the version explicitly in my pom in the
>>> build block to get that working

Re: Convert everything to Git

[Baptiste Mathus]

+1 on the submodule solution. We started using it some months ago since the
branch option came out.
As a simplistic analogy, you can see it as svn: externals equivalent.

It helps developers (and ci configuration) to retrieve many related
projects in only one clone command.

My 2 cents
Le 14 févr. 2014 05:10, "Mark Derricutt"  a écrit :

> Jenkins could build from a super-repo that uses git submodule.
>
> Since a quite a few versions ago, git-submodules can now follow a branch
> rather than a fixed SHA1.
>
> So you could build/test monolithically, branch/commit individually.
>
> Compromise maybe?
>
>
> On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote:
>
>  each entry would mean 1 git repo + 1Jenkins job (or even more, since
>> plugins
>> have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for
>> Maven
>> 3.1.x)
>> IMHO, we're not ready for such granularity, neither at git nor Jenkins
>> level
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven 2.x is end of life

[Baptiste Mathus]

Hi Jörg,
> multi-projects in correct order and therefore will not produce artifacts
with bogus SNAPSHOTs

Maybe you could (re)point out the corresponding JIRAs?

Because as a maven user, I wonder what triggers these issues for you. We
have tens of multi-projects with interdependencies being currently
developed, and I'd be interested to hear about the (problematic) use case
we don't encounter.


2014-02-13 18:05 GMT+01:00 Jörg Schaible :

> Daniel Kulp wrote:
>
> >
> > On Feb 13, 2014, at 11:18 AM, Stephen Connolly
> >  wrote:
> >
> >> I suggest you convince at least one of these people:
> >> https://people.apache.org/committers-by-project.html#maven that they
> >> should act as release manager.
> >>
> >> EOL just means we will not be making new releases, and it will be moved
> >> to the archive section of the downloads.
> >
> > Well, one more thing:  if it’s officially EOL, there is a much higher
> > chance that plugins would be marked as using 3.x as a minimum and will no
> > longer work with 2.1.1.   API’s and such that the plugins use will likely
> > get updated to 3.x level.  Etc….
>
> Right. The question is already if 2.2.1 runs on Java 8 or if we have a
> compatible release plugin that allows us to switch from subversion to git.
> With EOL of M221 those situations will grow rapidly.
>
> > Anyway, I’m +1 to dropping 2.x support.
>
> I'd switch immediately to a working 3.x version.
>
> >> You will still be able to download it. You will still be able to get the
> >> source code. We just will be recognising the fact that there is nobody
> >> who wants to cut a release from the 2.x codebase.
>
> See above. 2.2.1 can become a dead end faster than wanted.
>
> >> Hopefully focusing on the 3.x codebase will allow us to iron out the
> bugs
> >> you feel are present in 3.x and thus preventing you from migrating...
>
> What else can we do apart from digging into Maven/Aether code ourselves?
> Providing an example project and an IT did not help to make any progress.
>
> - Jörg
>
>
>
> -
> 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 ! nbsp;! 
>

Fwd: maven-scm - Build # 827 - Failure

[Baptiste Mathus]

Ahem, it's embarassing... :-).

The IT I added in the patch is failing, but in its very beginning when it's
trying to decrypt the dummy password in the src/it/settings.xml [1]
I looked into the issue, and I'm not sure how to solve it (just re-checked,
the IT works fine on my machine).

Any idea of how to solve this?

The simplest solution might be to simply get rid of the  block here
[2], but as I cannot test it on the target CI system, would prefer not to
propose random commits to try and kill the issue :-).

Or maybe this is something that's solveable on the Jenkins job
configuration side?

Thanks

Cheers

[1]
https://builds.apache.org/job/maven-scm/ws/maven-scm-plugin/target/it/scm-741-validate-scm-url-matches-working-copy/build.log
[2]
https://github.com/apache/maven-scm/pull/8/files#diff-1154d0ea8f6b5143a055345bf1fae166R24

-- Forwarded message --
From: Apache Jenkins Server 
Date: 2014-02-13 17:31 GMT+01:00
Subject: maven-scm - Build # 827 - Failure
To: notificati...@maven.apache.org, bat...@batmat.net


The Apache Jenkins build system has built maven-scm (build #827)

Status: Failure

Check console output at https://builds.apache.org/job/maven-scm/827/ to
view the results.

Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas

[Baptiste Mathus]

;-).
We simply added the jenkins repos in our nexus instance, as this is what
our/a MRM is designed for, but I see your point when you're inside an rigid
organization and you just want to work. My goal is surely not to say proxy
is useless, but more something like "are you sure you're using it for the
right reasons?"
Anyway, I see your point :-).


2014-02-13 9:47 GMT+01:00 Mirko Friedenhagen :

> Baptiste,
>
> when you do not control Nexus but have to go through a proxy for http and
> want to develop Jenkins plugins you need such voodoo :-) .
>
> Regards
> Mirko
> --
> Sent from my mobile
> On Feb 13, 2014 8:56 AM, "Baptiste Mathus"  wrote:
>
> > Btw (apart from the fact that kind of question should better be asked on
> > users ML), it seems a bit weird to me at first sight you're actually
> having
> > to configure both a nexus server, and a proxy.
> >
> > For instance, we exclusively use a nexus server to do the actual
> > proxying(+hosting) of anything that maven has to download inside the
> > company. Not sure what's your use case to need to not go through your
> maven
> > repo manager any time.
> >
> > My 2 cents.
> >
> >
> > 2014-02-13 8:17 GMT+01:00 Anders Hammar :
> >
> > > It would be great if you could file a JIRA ticket so that the docs can
> be
> > > fixed, see [1]!
> > > Use the website JIRA project.
> > >
> > > /Anders
> > >
> > > [1] http://maven.apache.org/issue-tracking.html
> > >
> > >
> > >
> > > On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian 
> > > wrote:
> > >
> > > > I develop behind a proxy.  Some of our servers sit behind that proxy
> as
> > > > well, including our Nexus Repository.  I have configured my
> > settings.xml
> > > to
> > > > point to our proxy but to ignore the hosts that are behind that
> proxy.
> > >  If
> > > > I use a comma-delimited list in my nonProxyHosts, Maven seems to
> ignore
> > > > that list and apply the proxy to those hosts as well.  If I use a
> > > > pipe-delimited list in my nonProxyHosts, everything works great and
> > Maven
> > > > does NOT try to apply the proxy to those hosts.
> > > >
> > > > According to this document only pipes are acceptable as delimiters,
> > which
> > > > is what I observed:
> > > > https://maven.apache.org/guides/mini/guide-proxies.html
> > > >
> > > > According to this document either pipes or commas are acceptable as
> > > > delimiters which is incorrect according to my observation:
> > > > https://maven.apache.org/settings.html (Proxies header)
> > > >
> > > > This is an example of the proxies block in my settings.xml file that
> > does
> > > > not work.  When Maven needs to hit 123.456.789.111 or my.nexus.host,
> it
> > > > applies the proxy to it.
> > > >
> > > >   
> > > >
> > > > 
> > > >
> > > >   My Proxy
> > > >
> > > >   true
> > > >
> > > >   http
> > > >
> > > >   
> > > >
> > > >   
> > > >
> > > >   my.proxy.com
> > > >
> > > >   80
> > > >
> > > >
> > > > localhost,123.456.789.*,my.nexus.host
> > > >
> > > > 
> > > >
> > > >   
> > > >
> > > > This example WORKS.  Proxy is ignored for any requests to
> > 123.456.789.111
> > > > or my.nexus.host, etc.
> > > >
> > > >
> > > >   
> > > >
> > > > 
> > > >
> > > >   My Proxy
> > > >
> > > >   true
> > > >
> > > >   http
> > > >
> > > >   
> > > >
> > > >   
> > > >
> > > >   my.proxy.com
> > > >
> > > >   80
> > > >
> > > >
> > > > localhost|123.456.789.*|my.nexus.host
> > > >
> > > > 
> > > >
> > > >   
> > > >
> > > > Environment:
> > > > Maven 3.1.1
> > > > Mac OS-X 10.9
> > > >
> > > > Also reproduced this issue on:
> > > >
> > > > Apache Maven 3.0.4
> > > >
> > > > Ubuntu 11.04
> > > >
> > > >
> > > >
> > > > -
> > > > 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 ! nbsp;!
> > >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas

[Baptiste Mathus]

Btw (apart from the fact that kind of question should better be asked on
users ML), it seems a bit weird to me at first sight you're actually having
to configure both a nexus server, and a proxy.

For instance, we exclusively use a nexus server to do the actual
proxying(+hosting) of anything that maven has to download inside the
company. Not sure what's your use case to need to not go through your maven
repo manager any time.

My 2 cents.


2014-02-13 8:17 GMT+01:00 Anders Hammar :

> It would be great if you could file a JIRA ticket so that the docs can be
> fixed, see [1]!
> Use the website JIRA project.
>
> /Anders
>
> [1] http://maven.apache.org/issue-tracking.html
>
>
>
> On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian 
> wrote:
>
> > I develop behind a proxy.  Some of our servers sit behind that proxy as
> > well, including our Nexus Repository.  I have configured my settings.xml
> to
> > point to our proxy but to ignore the hosts that are behind that proxy.
>  If
> > I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore
> > that list and apply the proxy to those hosts as well.  If I use a
> > pipe-delimited list in my nonProxyHosts, everything works great and Maven
> > does NOT try to apply the proxy to those hosts.
> >
> > According to this document only pipes are acceptable as delimiters, which
> > is what I observed:
> > https://maven.apache.org/guides/mini/guide-proxies.html
> >
> > According to this document either pipes or commas are acceptable as
> > delimiters which is incorrect according to my observation:
> > https://maven.apache.org/settings.html (Proxies header)
> >
> > This is an example of the proxies block in my settings.xml file that does
> > not work.  When Maven needs to hit 123.456.789.111 or my.nexus.host, it
> > applies the proxy to it.
> >
> >   
> >
> > 
> >
> >   My Proxy
> >
> >   true
> >
> >   http
> >
> >   
> >
> >   
> >
> >   my.proxy.com
> >
> >   80
> >
> >
> > localhost,123.456.789.*,my.nexus.host
> >
> > 
> >
> >   
> >
> > This example WORKS.  Proxy is ignored for any requests to 123.456.789.111
> > or my.nexus.host, etc.
> >
> >
> >   
> >
> > 
> >
> >   My Proxy
> >
> >   true
> >
> >   http
> >
> >   
> >
> >   
> >
> >   my.proxy.com
> >
> >   80
> >
> >
> > localhost|123.456.789.*|my.nexus.host
> >
> > 
> >
> >   
> >
> > Environment:
> > Maven 3.1.1
> > Mac OS-X 10.9
> >
> > Also reproduced this issue on:
> >
> > Apache Maven 3.0.4
> >
> > Ubuntu 11.04
> >
> >
> >
> > -
> > 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 ! nbsp;!
>

[Committer School] I would like to become a committer

[Baptiste Mathus]

Hi all,

Some of you already know me through MOJO and my posts here, and I would
like to try to get more involved in that Apache Maven tool I really like.

I am interested in the following areas:
enforcer, scm, release, and some others when needed...

If anyone knows any issues that I could take a look at I would be very much
appreciated.

I've recently proposed a patch for
ARCHETYPE-456,
and currently working on SCM-741 [1] (my next goal is to see how this
improvement can also be wired into the release-plugin and
tackle MRELEASE-445 to validate the svn tagBase before starting, something
that already bit me in the past).

Thanks

[1] https://jira.codehaus.org/browse/SCM-741
   and my current github branch
https://github.com/Batmat/maven-scm/tree/SCM-741
   (already working on my machine, but missing tests because
I'm somehow unable to run the whole test suite on my machine without it
failing (even without my changes) :-/)


-- Baptiste

PS : btw, as most apache maven projects are also present on github, I
wonder if there's a preferred patch format. Is
http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patchan
up-to-date reference?

Re: How alive is Plexus?

[Baptiste Mathus]

+1, if what you're looking for is essentially classpath isolation
management, then ClassWorlds is one way to go.
Btw, I think you might find many examples in different maven plugins.

My 2 cents


2014-02-08 19:04 GMT+01:00 Jason van Zyl :

>
> On Feb 8, 2014, at 12:42 PM, Benson Margulies 
> wrote:
>
> > On Sat, Feb 8, 2014 at 12:32 PM, Benson Margulies 
> wrote:
> >> On Sat, Feb 8, 2014 at 12:22 PM, Jason van Zyl  wrote:
> >>> The original Plexus implementation is dead and has been for quite a
> while, even for us. We don't actually use Plexus the container anymore. The
> extensions that were written for Plexus that sit atop Sisu is the effective
> Plexus implementation we are using today. What this is in practice, for us,
> is supporting the Plexus way of finding component metadata and
> automatically creating the bindings we need so that those Plexus components
> run in Guice. But Maven runs on top of Guice via Sisu, not Plexus. Maven's
> core doesn't use any of the plexus lifecycle support either. That said we
> have tons of components and plugins out in the wild that use the Plexus
> idioms and we'll have to support that for many years even if there is no
> trace of Plexus in Maven's core. Which is why we have the Sisu plexus shim.
> >>>
> >>> I am pretty close to removing all Plexus annotations from Maven's core
> and with a bit of work in the CLI the core will be almost entirely JSR330
> running on Guice, but Guice itself is visible in a few places where we have
> some custom scopes and where the Injector is brought to life.
> >>>
> >>> If you don't need any dynamic creation of bindings like we do (our
> plugin and extension mechanism) then I highly recommend you take a look at
> Dagger. This is the DI container that Square created and looks like more
> Google people are working on it now than Square employees. This looks like
> the successor to Guice and is 24 classes currently, easy to read and works
> super well in constrained environments like Android and therefore is super
> fast for normal applications.
> >>>
> >>> https://github.com/square/dagger
> >
> > I don't see any classpath management in here. So what's your view about
> that?
>
> You can use something like ClassWorlds or JBoss Modules or roll your own.
>  Dagger is only about DI which is a good thing.
>
> >
> >>
> >> I'll go read. Thanks.
> >>
> >>>
> >>> On Feb 8, 2014, at 11:43 AM, Benson Margulies 
> wrote:
> >>>
> >>>> Since the mailing list archive links on
> >>>> http://plexus.codehaus.org/mail-lists.html are dead, I thought that
> >>>> I'd probably reach relevant people here.
> >>>>
> >>>> I'm using Sisu/Guice in a project, and I'm looking for a _lightweight_
> >>>> way to add classpath isolation. OSGi goes not qualify. Does anyone
> >>>> still care for plexus?
> >>>>
> >>>> -
> >>>> 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
> >>> -
> >>>
> >>> We all have problems. How we deal with them is a measure of our worth.
> >>>
> >>> -- Unknown
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> > -
> > 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
> -
>
> We know what we are, but know not what we may be.
>
>   -- Shakespeare
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: IOUtil.contentEqualsIgnoreEOL ?

[Baptiste Mathus]

Interesting, so I guess the long-term plan about custom deps is still
something to discuss ;-).
Anyway, if anyone wants cares about that jira some day, I'll be happy to
rewrite the patch as adviced if deemed necessary.

Baptiste


2014-02-05 23:30 GMT+01:00 Robert Scholte :

> How about org.codehaus.plexus.util.StringUtils#unifyLineSeparators(String)
> ?
>
> We're already using plexus-utils, so that saves us another dependency :)
>
> Robert
>
> Op Wed, 05 Feb 2014 22:07:51 +0100 schreef Barrie Treloar <
> baerr...@gmail.com>:
>
>
>  On 6 February 2014 06:45, Baptiste Mathus  wrote:
>>
>>> Anyone?
>>> I suppose I have my answer, I'll leave the current patch as-is :-)
>>>
>>
>> Isn't the long term plan to drop anything custom and use existing code?
>> If its already in commons-io just use that instead.
>>
>> -
>> 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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Plugins with parameters and defaultValue

[Baptiste Mathus]

Here's the thread:
http://maven.40175.n5.nabble.com/Maven2-Maven3-plugin-development-Ensuring-only-the-available-parameters-are-allowed-tp5780854p5780948.html

Maybe I'd try something along those lines:

Plugin plugin = lookupThePluginYouWant(project.getBuildPlugins());
Xpp3Dom config = (Xpp3Dom) plugin.getConfiguration();
// Unleash hell

?

HTH


2014-02-05 Karl Heinz Marbaise :

> Hi Baptiste,
>
>
>
> > Hi,
>
>> I think I remember a recent answer from Stephen about plugin conf,
>> saying basically you'd just have to fall back to xpath project/build and
>> then see what's present.
>>
> First thanks for the hint...
>
> Any knowledge where to search for ?
>
> Or Stephen ? Do you have a hint ?
>
> Does exist an example within the apache maven plugins for such thing?
>
> Kind regards
> Karl-Heinz Marbaise
>
>
>
> -
> 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 ! nbsp;! 
>

Re: IOUtil.contentEqualsIgnoreEOL ?

[Baptiste Mathus]

Anyone?
I suppose I have my answer, I'll leave the current patch as-is :-)


2014-01-28 Baptiste Mathus :

> Hi all,
>
> I created ARCHETYPE-456 yesterday for m-archetype-p to support comparing
> directories for integration-testing ignoring the EOL/newline encoding [1].
> Currently, I put that code directory in the plugin. But I guess it'd
> better be placed alongside already existing IOUtil.contentEquals() method?
>
> I can create the associated JIRA and patch if seen as useful. But I'd like
> to check here before this wouldn't be seen as the wrong choice. This will
> prevent me from preparing a svn patch if this is gonna be rejected anyway
> :-).
>
> Btw, interestingly, this "contentEqualsIgnoreEOL" already exists in Apache
> commons-io [1].
>
> Thanks
>
> Cheers
>
> [1] https://jira.codehaus.org/browse/ARCHETYPE-456
> [2] 
> http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#contentEqualsIgnoreEOL(java.io.Reader,
> java.io.Reader)
>
> --
> Baptiste
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Plugins with parameters and defaultValue

[Baptiste Mathus]

Hi,
I think I remember a recent answer from Stephen about plugin conf, saying
basically you'd just have to fall back to xpath project/build and then see
what's present.

My 2 cents


2014-01-30 Karl Heinz Marbaise :

> Hi,
>
> just a question concerning the usage of default values in a mojo...
>
> If i define a default value for a parameter in a Mojo like the following:
>
> @Parameter( defaultValue = "${project.build.finalName}", required = true )
> private String finalName;
>
> So the question is:
>
> Can i see the difference in the mojo code if someone in the pom file has
> written:
>
>   
> or
>   just omit it.
>
> or is this not possible ?
>
>
> In my opinion it's not possible to distinguish between those two cases.
>
> Any ideas ?
>
> Thanks in advance.
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> 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 ! nbsp;! 

Re: [PATCH] Allow spaces in javadoc exclude list

[Baptiste Mathus]

Hi,
It was possible historically, but I think it was disabled due to spamming
issue.
Anyway, the best way to create an account on codehaus is by using xircles:
http://xircles.codehaus.org/signup

This will help you have only one account for jira and possibly the other
services of Codehaus.

HTH

Cheers


2014-01-28 Omair Majid 

> * Paul Benedict  [2014-01-28 15:34]:
> > Your best course is to create a new ticket for the Maven Javadoc plugin,
> > and then attach your patch to the ticket:
> > http://jira.codehaus.org/browse/MJAVADOC
>
> Thanks for the pointer. Filing a bug was my first thought too, but I
> don't have an account on jira.codehaus.org and I don't see a way of
> signing up for one.
>
> Thanks,
> Omair
>
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>
> -
> 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 ! nbsp;! 
>

IOUtil.contentEqualsIgnoreEOL ?

[Baptiste Mathus]

Hi all,

I created ARCHETYPE-456 yesterday for m-archetype-p to support comparing
directories for integration-testing ignoring the EOL/newline encoding [1].
Currently, I put that code directory in the plugin. But I guess it'd better
be placed alongside already existing IOUtil.contentEquals() method?

I can create the associated JIRA and patch if seen as useful. But I'd like
to check here before this wouldn't be seen as the wrong choice. This will
prevent me from preparing a svn patch if this is gonna be rejected anyway
:-).

Btw, interestingly, this "contentEqualsIgnoreEOL" already exists in Apache
commons-io [1].

Thanks

Cheers

[1] https://jira.codehaus.org/browse/ARCHETYPE-456
[2] 
http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#contentEqualsIgnoreEOL(java.io.Reader,
java.io.Reader)

-- 
Baptiste

Re: exclude on scope import

[Baptiste Mathus]

+1, we've been using this trick for some years now to be sure nobody could
send their logs basically to /dev/null without being noticed.
In the meantime, as we actually control the corp pom, we also both added
the exclusions everywhere we could + enabled a bannedDependencies on
commons-logging.

Granted, it kind of became a " (2) belt(s) and braces" solution, but this
works perfectly fine :-).

HTH


2014/1/20 Aldrin Leal 

> (TL;DR: Use this repo and the versions on your dependencyMgmt:
> http://version99.qos.ch/)
>
> a hack, but works like a charm:
>
>
> http://day-to-day-stuff.blogspot.com.br/2007/10/announcement-version-99-does-not-exist.html
>
>
> --
> -- Aldrin Leal, 
> Master your EC2-fu! Get the latest ekaterminal public beta
> http://www.ingenieux.com.br/products/ekaterminal/
>
>
> On Mon, Jan 20, 2014 at 6:12 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > The hack way I would use is to create an intermediate "wrapper" project
> and
> > then you can define exclusions on that wrapper at the pom level directly.
> >
> > Other than that you just have to wait for model version 5.0.0 when the
> >  element that I want to introduce would allow either slf4j's
> > binder to advertise that it "provides" commons-logging, or you would be
> > able to state that in your  directly
> >
> >
> > On 20 January 2014 09:03, Stephane Nicoll 
> > wrote:
> >
> > > Hi,
> > >
> > > Has anybody thought (or worked on) the ability to exclude dependencies
> > from
> > > the import of a pom for a given project.
> > >
> > > Let's say that project S uses commons-logging and we use that project
> in
> > > our project. We have something like
> > >
> > > 
> > >   
> > >   the-s-project
> > >   ...
> > >   pom
> > >   import
> > > 
> > >
> > > Now I'd like to exclude the "commons-logging" dependency from the whole
> > > project so that I can use the slf4j binder instead.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > S.
> > >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: [VOTE] Apache Maven SCM 1.9 (take 3)

[Baptiste Mathus]

+1, non-binding.

PS : FTR, I suppose we're talking about
the fa42b42693571297b323f474f9228ce99ffaf662 git sha1 tag.




2014/1/8 Robert Scholte 

> +1 (binding)
>
> Robert
>
> Op Tue, 07 Jan 2014 19:22:38 +0100 schreef domi :
>
>
>  Hi,
>>
>> We fixed 11 issues. The new feature is the jgit provider (based on jgit).
>> Details:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?
>> projectId=10527&version=18783
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/maven-009/
>>
>> Staged site: http://maven.apache.org/scm-archives/scm-LATEST/
>>
>> Sources release:
>> https://repository.apache.org/content/repositories/maven-
>> 009/org/apache/maven/scm/maven-scm/1.9/maven-scm-1.9-source-release.zip
>>
>> Source release checksum(s):
>> maven-scm-1.9-source-release.zip sha1: e1e6323c43ba9ceaa4cb62d94b7cb9
>> 266c8f1897
>> Vote open for 72H
>>
>> [+1]
>> [0]
>> [-1]
>>
>> Thanks
>> Dominik Bartholdi
>>
>
> ---------
> 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 ! nbsp;! 
>

Re: New logo?

[Baptiste Mathus]

; On 21 December 2013 12:25, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >>> Having thought about it overnight... if people really want to go
> with a
> > >>> non-stylised raven we can always ask for permission:
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-9.png
> > >>>
> > >>> OTOH here is a different stylised version
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-10.png
> > >>>
> > >>> Finally, here is a raven totem
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-11.png
> > >>>
> > >>> I think this last one could be put in a forest with sky background...
> > >>> just haven't had time to do it
> > >>>
> > >>>
> > >>> On 20 December 2013 22:26, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>>> I think we can't go with the raven
> > >>>>
> > >>>> http://www.prweb.com/releases/2012/3/prweb9334175.htm
> > >>>>
> > >>>> Given that a different non-competing user of the name is using a
> raven
> > >>>> in their logo
> > >>>>
> > >>>> On Friday, 20 December 2013, Manfred Moser wrote:
> > >>>>
> > >>>>> >
> > >>>>> > On Dec 20, 2013, at 1:01 PM, Manfred Moser
> > >>>>>
> > >>>>> > wrote:
> > >>>>> >
> > >>>>> >> I would move the Raven closer to the word Maven but otherwise
> this
> > >>>>> looks
> > >>>>> >> good imho. Of course I am not sure if everyone would recognize
> it
> > >>>>>as
> > >>>>> a
> > >>>>> >> raven ..
> > >>>>> >
> > >>>>> > That¹s my problemŠ.  doesn¹t look like a raven to me at all.
> > >>>>> >
> > >>>>> > When I first looked at it, I guess the ³mouth + tough² part
> seemed
> > >>>>>to
> > >>>>> look
> > >>>>> > more like the Seattle SeaHawks logo stuck on a boot with a weird
> > >>>>> swirly
> > >>>>> > thing at the ankle.
> > >>>>> >
> > >>>>> > In other words, a little to ³abstract² for me.   :-)
> > >>>>>
> > >>>>> Fair enough. I guess living in the pacific northwest I am exposed
> to
> > >>>>> these
> > >>>>> depictions a lot so I can tell. But globally we might have to make
> > >>>>>it a
> > >>>>> bit clearer. Good input ;-)
> > >>>>>
> > >>>>> manfred
> > >>>>>
> > >>>>>
> -
> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Sent from my phone
> > >>>>
> > >>>
> > >>>
> > >>
> >
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: New logo?

[Baptiste Mathus]

2013 12:25, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >>> Having thought about it overnight... if people really want to go
> with a
> > >>> non-stylised raven we can always ask for permission:
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-9.png
> > >>>
> > >>> OTOH here is a different stylised version
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-10.png
> > >>>
> > >>> Finally, here is a raven totem
> > >>>
> > >>> http://people.apache.org/~stephenc/maven-logo-contest/maven-11.png
> > >>>
> > >>> I think this last one could be put in a forest with sky background...
> > >>> just haven't had time to do it
> > >>>
> > >>>
> > >>> On 20 December 2013 22:26, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>>> I think we can't go with the raven
> > >>>>
> > >>>> http://www.prweb.com/releases/2012/3/prweb9334175.htm
> > >>>>
> > >>>> Given that a different non-competing user of the name is using a
> raven
> > >>>> in their logo
> > >>>>
> > >>>> On Friday, 20 December 2013, Manfred Moser wrote:
> > >>>>
> > >>>>> >
> > >>>>> > On Dec 20, 2013, at 1:01 PM, Manfred Moser
> > >>>>>
> > >>>>> > wrote:
> > >>>>> >
> > >>>>> >> I would move the Raven closer to the word Maven but otherwise
> this
> > >>>>> looks
> > >>>>> >> good imho. Of course I am not sure if everyone would recognize
> it
> > >>>>>as
> > >>>>> a
> > >>>>> >> raven ..
> > >>>>> >
> > >>>>> > That¹s my problemŠ.  doesn¹t look like a raven to me at all.
> > >>>>> >
> > >>>>> > When I first looked at it, I guess the ³mouth + tough² part
> seemed
> > >>>>>to
> > >>>>> look
> > >>>>> > more like the Seattle SeaHawks logo stuck on a boot with a weird
> > >>>>> swirly
> > >>>>> > thing at the ankle.
> > >>>>> >
> > >>>>> > In other words, a little to ³abstract² for me.   :-)
> > >>>>>
> > >>>>> Fair enough. I guess living in the pacific northwest I am exposed
> to
> > >>>>> these
> > >>>>> depictions a lot so I can tell. But globally we might have to make
> > >>>>>it a
> > >>>>> bit clearer. Good input ;-)
> > >>>>>
> > >>>>> manfred
> > >>>>>
> > >>>>>
> -
> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Sent from my phone
> > >>>>
> > >>>
> > >>>
> > >>
> >
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener

[Baptiste Mathus]

Well, Maven is already voted to go onto Java6 from now on ;-).

Anyway, as I say, I know this isn't for tomorrow. But there's another
thing, there was not a lot of exciting features attracting developers
between Java 5 and 7 (Coin was too small to really be a major reason for a
mainstream migration).

But the traction from lambda, default methods, better type inference,
date/time api and so on should help migrate a bit quicker.
Let's hope this will happen for some maven components in the next 3 or 4
(and not 10) years if we are optimists.


2013/12/20 Igor Fedorenko 

> Java 8 isn't out yet... Maven is still limited java 5... so yeah, we'll
> get there... eventually... around 2023 or so.
>
> Please excuse my sarcasm, I just couldn't resist :-)
>
> --
> Regards,
> Igor
>
>
> On 12/20/2013, 9:40, Baptiste Mathus wrote:
>
>> Sure, it'll take time, but the good news is Java8's default methods are
>> certainly going to progressively cause deprecation of that
>> convention/naming convention.
>>
>>
>> 2013/12/20 Igor Fedorenko 
>>
>>  I don't think this is eclipse-specific, but IBM did analysis of
>>> java-based API evolution and documented the results at eclipse [1].
>>>
>>> The document is quite thorough and I usually use it as a reference when
>>> I need to develop API for long-term maintenance.
>>>
>>> The "2 Convention" is explained in the part 3.
>>>
>>> [1] http://wiki.eclipse.org/Evolving_Java-based_APIs
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> On 12/19/2013, 23:21, Hervé BOUTEMY wrote:
>>>
>>>  IIUC, numbered interfaces + abstract implementations are roughly Eclipse
>>>> way
>>>> of solving this requirement about API evolution, isn't it?
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>> Le jeudi 19 décembre 2013 07:43:03 Igor Fedorenko a écrit :
>>>>
>>>>  On 12/18/2013, 16:42, Olivier Lamy wrote:
>>>>>
>>>>>  if you need to add new parameters in the future, you won't have to add
>>>>>> this new MojoExecutionListener2 extends MojoExecutionListener (IMHO
>>>>>> it's just ugly but that's my POV) just add those new fields in
>>>>>> MojoExecutionEvent etc...
>>>>>>
>>>>>> Anyway I only talk by experience and you are the guy who write the
>>>>>> code so do as you want.
>>>>>> This API can be here for  a while so if it's easy to enhance it it's
>>>>>> better.
>>>>>>
>>>>>> BTW I just wonder why you don't want to use this pattern with a bean
>>>>>> rather than a method with a lot of parameters.
>>>>>>
>>>>>>
>>>>> API clarity and consistency are the reasons I have slight preference to
>>>>> explicitly pass parameters to callback methods.
>>>>>
>>>>> MojoExecutionListener2 will still be required to introduce new callback
>>>>> methods, and I like having single/consistent API evolution approach
>>>>> that
>>>>> covers all scenarios.
>>>>>
>>>>> When parameters are passed in explicitly, clients do not have to guess
>>>>> what is available to them. It also makes it little easier to reason
>>>>> what
>>>>> API version a client expects just by looking at implements
>>>>> MojoExecutionListener vs MojoExecutionListener2.
>>>>>
>>>>> At any rate, I don't think this matter much in this particular case, so
>>>>> I'll introduce event objects in next couple of days.
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>>   On 19 December 2013 07:32, Igor Fedorenko 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>  Olivier, Robert,
>>>>>>>
>>>>>>> Do you insist on event objects or can live with my initial
>>>>>>> implementation?
>>>>>>>
>>>>>>> I am not sure if I explained this clearly enough, but I never
>>>>>>> suggested
>>>>>>> changing existing method signatures in the future. If we need to add
>>>>>>> new parameters or new callback methods in the future, w

Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener

[Baptiste Mathus]

6:45:14 +0100 schreef Igor Fedorenko
>>>>>>
>>>>>> :
>>>>>>
>>>>>>> On 12/16/2013, 7:39, Olivier Lamy wrote:
>>>>>>>
>>>>>>>> On Dec 16, 2013 11:27 PM, "Igor Fedorenko" 
>>>>>>>>
>>>>>>> wrote:
>>
>>>  On 12/16/2013, 5:27, Olivier Lamy wrote:
>>>>>>>>>
>>>>>>>>>> +/**
>>>>>>>>>>>
>>>>>>>>>>>  + * Extension point that allows build extensions observe and
>>>>>>>>>>>> possibly
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> veto mojo executions.
>>>>>>>>
>>>>>>>>  + *
>>>>>>>>>>>> + * @see WeakMojoExecutionListener
>>>>>>>>>>>> + * @since 3.1.2
>>>>>>>>>>>> + * @provisional This interface is part of work in progress and
>>>>>>>>>>>> can be
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> changed or removed without notice.
>>>>>>>>
>>>>>>>>  + */
>>>>>>>>>>>> +public interface MojoExecutionListener
>>>>>>>>>>>> +{
>>>>>>>>>>>> +public void beforeMojoExecution( MavenSession session,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> MavenProject project, MojoExecution execution, Mojo mojo )
>>>>>>>>
>>>>>>>>  +throws MojoExecutionException;
>>>>>>>>>>>> +
>>>>>>>>>>>> +public void afterMojoExecutionSuccess( MavenSession
>>>>>>>>>>>> session,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> MavenProject project, MojoExecution execution,
>>>>>>>>
>>>>>>>>  +   Mojo mojo )
>>>>>>>>>>>> +throws MojoExecutionException;
>>>>>>>>>>>> +
>>>>>>>>>>>> +public void afterExecutionFailure( MavenSession session,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> MavenProject project, MojoExecution execution, Mojo mojo,
>>>>>>>>
>>>>>>>>  +   Throwable cause );
>>>>>>>>>>>> +}
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I wonder if it will be easier for future enhancement to use a bean
>>>>>>>>>> with fields for those objects.
>>>>>>>>>> MojoExecutionListenerEvent with getMavenSession() etc...
>>>>>>>>>>
>>>>>>>>>> Maybe will be simpler to add getter to this bean than changing the
>>>>>>>>>> signature of the interface.
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Good idea. Any objections against MojoExecutionEvent and
>>>>>>>>> ProjectExecutionEvent names?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sounds good
>>>>>>>>
>>>>>>>
>>>>>>> So I tried this and I am not sure I like the result.
>>>>>>>
>>>>>>> Event objects make it harder to see (at a glance) what parameters are
>>>>>>> provided to the callbacks, especially because not all callbacks have
>>>>>>> the
>>>>>>> same set of parameters. This muddies the API, I think.
>>>>>>>
>>>>>>> Event objects make it possible to add new callback parameters but
>>>>>>> won't
>>>>>>> help if we need to add new callbacks.
>>>>>>>
>>>>>>> I think MojoExecutionListener2/3/4/etc provides reasonably good
>>>>>>> evolution path for this API.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>> 
>>>>>>> -
>>>>>>> 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
>>>
>>
>>
>> -
>> 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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Java 8 update status

[Baptiste Mathus]

Btw, one of the ASM core committers is also an expert group member of the
JSR335 (java8/lambdas). So I suppose that if ASM isn't able to support
java8 bytecode yet, that should be fixable quite quickly.


2013/12/19 Stuart McCulloch 

> On 19 Dec 2013, at 09:50, Kristian Rosenvold 
> wrote:
>
> > That's me being imprecise based on something I picked off google; i
> changed
> > the wiki.
> >
> > It would appear to me that the ASM based plugins are in for a decent bit
> of
> > work (at least shade seems to be). Some of them are using fairly old
> > versions of asm too, and I considered
> > porting shade to 4.2 to minimize diff up to 5.0.  Do you know anything
> > about the differences between asm 4.2 and 5.0 are significant in terms of
> > api breakage ?
>
> One of the key goals in ASM 4 was to improve backwards (binary)
> compatibility of releases going forwards:
>
> http://asm.ow2.org/history.html
>
> So far I’ve found ASM 5 beta to be a drop-in replacement for ASM 4 from a
> client perspective, so +1 on moving those plugins up to 4.2 to begin with.
>
> ( then people can always try out ASM 5 beta by adding it as a dependency
> to the plugin declaration in the pom.xml )
>
> > Kristian
> >
> > 2013/12/19 Stuart McCulloch 
> >
> >> On 19 Dec 2013, at 08:08, Kristian Rosenvold <
> kristian.rosenv...@zenior.no>
> >> wrote:
> >>
> >>> I figured we could use the wiki page to eventually document for end
> users
> >>> which versions need to be used to solve known problems etc. While we're
> >>> still fixing them and we're still ea it's probably a good place for
> just
> >>> sharing knowledge, since general stuff will tend to get hidden in jira.
> >>> jMNG-5551 is good for keeping tabs on what's actually known :)
> >>
> >> Just wondering about the comment "Current ASM-5 beta not usable” - in
> what
> >> way is it not usable and has it been reported upstream?
> >>
> >>> Kristian
> >>>
> >>> 2013/12/19 Kristian Rosenvold 
> >>>
> >>>> I just created
> >>>> https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to
> >> track
> >>>> the status of java 8 migration "problems". This includes the bug
> number
> >> for
> >>>> the bugs.sun.com bug report I just filed yesterday that makes
> verifier
> >>>> break.
> >>>>
> >>>> Kristian
> >>
> >>
> >> -
> >> 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
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: New logo?

[Baptiste Mathus]

For those like me who were wondering what Jason was speaking about, I guess
this is it:
http://www.billcasselman.com/new_columns_2010/beaver_as_dirty_word.htm


2013/12/18 Jason van Zyl 

> On Dec 18, 2013, at 10:20 AM, Benson Margulies 
> wrote:
>
> > Personally, I think we need a new POM version to drive us forward.
> >
>
> I agree. If no one else gets to it I'll write up something over the
> holidays to distill what Stephen has written and try and formalize some
> minimal requirements and desires.
>
> > As a visual goes, I'd look for something like a beaver (who builds
> > things) wearing geek eye-glasses (indicating 'it's a maven').
> >
>
> For the love of god (if that happens to be your thing) please do not use a
> beaver. Go ask your closest English speaking North American why that's not
> a good choice. No one wants to see the maven-beaver-plugin.
>
> >
> > On Wed, Dec 18, 2013 at 10:18 AM, Stephen Connolly
> >  wrote:
> >> Tomcat... well they have a cat... fair enough
> >>
> >> Hadoop... has an elephant
> >>
> >> Hama has a hippo
> >>
> >> Solr has a sunrise
> >>
> >> Jackrabbit has a rabbit
> >>
> >> Chemistry has a test tube
> >>
> >> Openoffice has some abstract flying birds on a blue sky
> >>
> >> Karaf has a beaker with a feather on top
> >>
> >> ODE has a conductor with a feather instead of a batton
> >>
> >> Ant has the ant
> >>
> >> Flex has some strange abstract flexy thing
> >>
> >> Marmotta has a gopher
> >>
> >> Hive has an elephant-bee hybrid
> >>
> >> ...
> >>
> >> There is a limit to how many visually distinct animals you can render
> for a
> >> 75px tall image placeholder...
> >>
> >> But seriously, we just want something that is more than just our name
> in a
> >> fancy font. I think we need a mascot to help drive us onwards...
> >>
> >> -Stephen
> >>
> >>
> >>
> >> On 18 December 2013 13:27, Benson Margulies 
> wrote:
> >>
> >>> A large, not very bright, species of deer that wears giant antlers and
> >>> attacks what it doesn't understand. If that's what strikes you all as
> >>> a great metaphor for us, Maven, or both, go right ahead.
> >>>
> >>> -
> >>> 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
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
>
>
>
>
>
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: New logo?

[Baptiste Mathus]

+1 with the idea of a beaver or so. An animal building things would be a
better match for Maven.
The one you designed is already in the right direction. I would imagine one
with an additional pencil on the ear and a helmet like this one for
example:
http://us.123rf.com/400wm/400/400/vasca/vasca1112/vasca11125/11698348-draw-of-funny-beaver-working-in-helmet.jpg
.



2013/12/18 Stephen Connolly 

> For Benson... and just to put another one in the hat...
>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-4.png
>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-4-big.png
>
>
> On 18 December 2013 15:38, Jason van Zyl  wrote:
>
> > On Dec 18, 2013, at 10:20 AM, Benson Margulies 
> > wrote:
> >
> > > Personally, I think we need a new POM version to drive us forward.
> > >
> >
> > I agree. If no one else gets to it I'll write up something over the
> > holidays to distill what Stephen has written and try and formalize some
> > minimal requirements and desires.
> >
> > > As a visual goes, I'd look for something like a beaver (who builds
> > > things) wearing geek eye-glasses (indicating 'it's a maven').
> > >
> >
> > For the love of god (if that happens to be your thing) please do not use
> a
> > beaver. Go ask your closest English speaking North American why that's
> not
> > a good choice. No one wants to see the maven-beaver-plugin.
> >
> > >
> > > On Wed, Dec 18, 2013 at 10:18 AM, Stephen Connolly
> > >  wrote:
> > >> Tomcat... well they have a cat... fair enough
> > >>
> > >> Hadoop... has an elephant
> > >>
> > >> Hama has a hippo
> > >>
> > >> Solr has a sunrise
> > >>
> > >> Jackrabbit has a rabbit
> > >>
> > >> Chemistry has a test tube
> > >>
> > >> Openoffice has some abstract flying birds on a blue sky
> > >>
> > >> Karaf has a beaker with a feather on top
> > >>
> > >> ODE has a conductor with a feather instead of a batton
> > >>
> > >> Ant has the ant
> > >>
> > >> Flex has some strange abstract flexy thing
> > >>
> > >> Marmotta has a gopher
> > >>
> > >> Hive has an elephant-bee hybrid
> > >>
> > >> ...
> > >>
> > >> There is a limit to how many visually distinct animals you can render
> > for a
> > >> 75px tall image placeholder...
> > >>
> > >> But seriously, we just want something that is more than just our name
> > in a
> > >> fancy font. I think we need a mascot to help drive us onwards...
> > >>
> > >> -Stephen
> > >>
> > >>
> > >>
> > >> On 18 December 2013 13:27, Benson Margulies 
> > wrote:
> > >>
> > >>> A large, not very bright, species of deer that wears giant antlers
> and
> > >>> attacks what it doesn't understand. If that's what strikes you all as
> > >>> a great metaphor for us, Maven, or both, go right ahead.
> > >>>
> > >>> -
> > >>> 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
> > >
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> >
> >
> >
> >
> >
> >
> >
> >
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Baptiste Mathus]

t;>
>>>>>   I am getting an error from line #236 of build.xml (java.io.
>>>>> FileNotFoundException:
>>>>>  ...full path to pom.properties file)
>>>>>
>>>>>   Apparently the pom.properties file that is expected to be the
>>>>> bootstrap
>>>>>  area for that target (compile-boot) to run, is missing.
>>>>>
>>>>>   The missing file "pom.properties" is indeed located in the source
>>>>> code
>>>>>  tree in:
>>>>>
>>>>>   maven-core/src/test/resources/META-INF/maven/org.apache.
>>>>>
>>>>  >>> maven/maven-core
>>
>>>
>>>>>   I am new to Maven, but it appears that an entry in
>>>>>  maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is
>>>>>  needed in order to get it copied over to the bootstrap area during the
>>>>>  building of the target "generate-sources".
>>>>>
>>>>>   My environment variables are set as follows:
>>>>>
>>>>>   JAVA_HOME = /Library/Java/Home
>>>>>   ANT_HOME   = /Developer/Java/Ant
>>>>>   M2_HOME = /usr/local/maven-3.0.4
>>>>>
>>>>>   I also set M3_HOME = /usr/local/maven-3.0.4  in case that was needed
>>>>>  instead of M2_HOME
>>>>>
>>>>>   I do not have CLASSPATH defined at all.
>>>>>
>>>>>   What am I missing here to get Maven to build?  Any tips or hints
>>>>> would
>>>>>  be greatly appreciated!
>>>>>
>>>>>   Thanks,
>>>>>
>>>>>   --Ed
>>>>>   --
>>>>>   E. J. Mansky II
>>>>>   Eikonal Research Institute
>>>>>   Bend, Oregon
>>>>>
>>>>>   
>>>>> -
>>>>>   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
>>>>
>>>>
>>>
>>>  --
>>>  E. J. Mansky II
>>>  Eikonal Research Institute
>>>  Bend, Oregon
>>>
>>>  -
>>>  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 ! nbsp;! 
>>>
>>>
>
> --
> E. J. Mansky II
> Eikonal Research Institute
> Bend, Oregon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Baptiste Mathus]

Well, I agree. I was just pointing that out because that might not actually
be what Ed actually wants.
I had this fuzzy feeling when reading his mails (and not seing a sentence
assertively stating that he didn't want to use the already provided
binaries, which is fine in the ASF you're totally right).

I was somehow under the impression that Ed might be trying to build Maven
because that seemed the only way to use Maven on a PPC architecture or so.

But, sure, if Ed is actually trying to build because he wants to use a
version he built himself, we can help

Cheers


2013/11/7 Benson Margulies 

> The Apache Software Foundation releases open _source_ products. If one
> of our users wants to build the product from source, instead of using
> our convenience binaries, we should be helping, not pushing them to
> the binaries.
>
> On Thu, Nov 7, 2013 at 8:37 AM, Baptiste Mathus  wrote:
> > Hi,
> > I'm under the impression this question should have actually been asked on
> > the user ML.
> > You seem to be trying to build Maven although you shouldn't have to do.
> >
> > So, what are you actually trying to achieve currently?
> >
> > Maven is a pure Java tool, so unless you're actually trying to hack on
> > Maven itself (which would mean I was wrong and you're writing to the
> right
> > list), you can use stock maven binaries available from the maven website.
> > As you're already able to run Ant, which is also pure Java, Maven would
> run
> > fine too (nothing architecture/OS specific).
> >
> > HTH
> >
> > Cheers
> >
> >
> >
> > 2013/11/7 Ed Mansky 
> >
> >> I saw the requirement for Ant 1.8 or later. The encoding option in the
> >> echo task is new since Ant 1.7.
> >>
> >> To install ant 1.7, 1.8 or 1.8.4 requires JUnit to already be present.
> >> Unfortunately, to build JUnit you need maven in place.
> >>
> >> Hence my attempt to install/build maven.
> >>
> >> I found that I was able to build and install maven version 2.2.1 fine on
> >> Tiger/ppc.
> >>
> >> Apparently there have been a lot of changes in the build.xml file
> between
> >> 2.2.1 and 3.x versions of maven.
> >>
> >> Now, typing "mv install" in the Junit folder results in "Unable to build
> >> project ...junit/pom.xml; it requires Maven version 3.0.4"
> >>
> >> which is a different issue involving building junit 4 with maven 2.
> >>
> >> --Ed
> >>
> >>
> >>
> >>
> >>  The README.bootstrap.txt from the source tree states the pre-requisites
> >>> for building the bootstrap code are:
> >>>
> >>> - Java 1.5
> >>> - Ant 1.8 or later
> >>>
> >>> Whereas you're using Ant 1.6.5 - this is likely the problem, because
> >>> 1.6.5 doesn't support the use of an encoding in the echo task (this is
> what
> >>> creates that particular pom.properties file)
> >>>
> >>> On 6 Nov 2013, at 14:36, Ed Mansky wrote:
> >>>
> >>>   Hi all,
> >>>>
> >>>>  I am trying to install Maven from source code on a PowerMac G4 PPC
> 7450
> >>>> running 10.4.11 and with
> >>>>  Java JDK 1.5 and Ant 1.6.5 installed.
> >>>>
> >>>>  I am getting an error from line #236 of build.xml
> (java.io.FileNotFoundException:
> >>>> ...full path to pom.properties file)
> >>>>
> >>>>  Apparently the pom.properties file that is expected to be the
> bootstrap
> >>>> area for that target (compile-boot) to run, is missing.
> >>>>
> >>>>  The missing file "pom.properties" is indeed located in the source
> code
> >>>> tree in:
> >>>>
> >>>>  maven-core/src/test/resources/META-INF/maven/org.apache.
> >>>> maven/maven-core
> >>>>
> >>>>  I am new to Maven, but it appears that an entry in
> >>>> maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is
> >>>> needed in order to get it copied over to the bootstrap area during the
> >>>> building of the target "generate-sources".
> >>>>
> >>>>  My environment variables are set as follows:
> >>>>
> >>>>  JAVA_HOME = /Library/Java/Home
> >>>>  ANT_HOME   = /Devel

Re: Install question for Maven 3.0 on PPC/10.4.11/ant 1.6.5

[Baptiste Mathus]

Hi,
I'm under the impression this question should have actually been asked on
the user ML.
You seem to be trying to build Maven although you shouldn't have to do.

So, what are you actually trying to achieve currently?

Maven is a pure Java tool, so unless you're actually trying to hack on
Maven itself (which would mean I was wrong and you're writing to the right
list), you can use stock maven binaries available from the maven website.
As you're already able to run Ant, which is also pure Java, Maven would run
fine too (nothing architecture/OS specific).

HTH

Cheers



2013/11/7 Ed Mansky 

> I saw the requirement for Ant 1.8 or later. The encoding option in the
> echo task is new since Ant 1.7.
>
> To install ant 1.7, 1.8 or 1.8.4 requires JUnit to already be present.
> Unfortunately, to build JUnit you need maven in place.
>
> Hence my attempt to install/build maven.
>
> I found that I was able to build and install maven version 2.2.1 fine on
> Tiger/ppc.
>
> Apparently there have been a lot of changes in the build.xml file between
> 2.2.1 and 3.x versions of maven.
>
> Now, typing "mv install" in the Junit folder results in "Unable to build
> project ...junit/pom.xml; it requires Maven version 3.0.4"
>
> which is a different issue involving building junit 4 with maven 2.
>
> --Ed
>
>
>
>
>  The README.bootstrap.txt from the source tree states the pre-requisites
>> for building the bootstrap code are:
>>
>> - Java 1.5
>> - Ant 1.8 or later
>>
>> Whereas you're using Ant 1.6.5 - this is likely the problem, because
>> 1.6.5 doesn't support the use of an encoding in the echo task (this is what
>> creates that particular pom.properties file)
>>
>> On 6 Nov 2013, at 14:36, Ed Mansky wrote:
>>
>>   Hi all,
>>>
>>>  I am trying to install Maven from source code on a PowerMac G4 PPC 7450
>>> running 10.4.11 and with
>>>  Java JDK 1.5 and Ant 1.6.5 installed.
>>>
>>>  I am getting an error from line #236 of build.xml 
>>> (java.io.FileNotFoundException:
>>> ...full path to pom.properties file)
>>>
>>>  Apparently the pom.properties file that is expected to be the bootstrap
>>> area for that target (compile-boot) to run, is missing.
>>>
>>>  The missing file "pom.properties" is indeed located in the source code
>>> tree in:
>>>
>>>  maven-core/src/test/resources/META-INF/maven/org.apache.
>>> maven/maven-core
>>>
>>>  I am new to Maven, but it appears that an entry in
>>> maven-core/src/main/mdo/toolchains.mdo for this file in META-INF is
>>> needed in order to get it copied over to the bootstrap area during the
>>> building of the target "generate-sources".
>>>
>>>  My environment variables are set as follows:
>>>
>>>  JAVA_HOME = /Library/Java/Home
>>>  ANT_HOME   = /Developer/Java/Ant
>>>  M2_HOME = /usr/local/maven-3.0.4
>>>
>>>  I also set M3_HOME = /usr/local/maven-3.0.4  in case that was needed
>>> instead of M2_HOME
>>>
>>>  I do not have CLASSPATH defined at all.
>>>
>>>  What am I missing here to get Maven to build?  Any tips or hints would
>>> be greatly appreciated!
>>>
>>>  Thanks,
>>>
>>>  --Ed
>>>  --
>>>  E. J. Mansky II
>>>  Eikonal Research Institute
>>>  Bend, Oregon
>>>
>>>  ---------
>>>  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
>>
>
>
> --
> E. J. Mansky II
> Eikonal Research Institute
> Bend, Oregon
>
> -
> 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 ! nbsp;! 
>

Re: JAVA_HOME in release plugin

[Baptiste Mathus]

Hi Berndt,
If I understand correctly your issue is actually not a maven one but
related to maven integration in Jenkins.
This is not the right mailing list for this issue, please address it to
Jenkins developers ml.
About your patch attachment, it didn't go through the ml. It's generally
better to attach it directly to the related issue.

Cheers
Le 22 oct. 2013 18:18, "Bernd"  a écrit :

> Hello,
>
> there are some bugs[1] in regard to Jenkins/Maven-Release-Plugin where the
> forked maven instance picks up the wrong Java version (and therefore
> creates problems with compiler settings-bootclasspath and similiar).
>
> There are some Jenkins discussions around that, but I think the actual
> problem is, that the release plugin actually added a attribute to the mojo
> for javaHome but never uses it.
>
> Find attached a proof of concept patch (untested and missing null checks)
> with the code I think is missing.
>
> BTW: there is another thing, calling the maven start script might
> introduce all kinds of unwanted configurations, especially starting
> mavenrc_prebuild.bat/sh. So I would actually also add the MAVE_SKIP_RC=true
> environemnt variable, I am just not sure if unconditional or not.
>
> It seems there is no Jira for this, but I might be wrong?
>
> Greetings
> Bernd
>
> 1 https://issues.jenkins-ci.org/browse/JENKINS-6763
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: Can we parameterised pom.xml's tag to run depending on parameter set?

[Baptiste Mathus]

Hi,
Please better address this kind of questions to the users list next time.
As for your question, well what you ask seems actually to be the use case
for profiles. Just add the additional executions in the profile you want.
Cheers
Le 11 oct. 2013 01:26, "Archana Mundaye"  a
écrit :

> In  we have  which we can use to say whether we want
> to run that profile.
> In my one  section there are many different  sections
> under  tag. But I want to run only few  sections out
> of all present under .
>
> Do we have any option to make  section parameterised?
>
> Thanks and regards,
> Archana
>

Re: [VOTE] Release Maven 3.1.1

[Baptiste Mathus]

Le 13 sept. 2013 19:00, "sebb"  a écrit :
>
> On 12 September 2013 21:52, Baptiste Mathus  wrote:
> > 2013/9/12 sebb 
> >
> >> On 12 September 2013 14:52, Arnaud Héritier 
wrote:
> >> > On Thu, Sep 12, 2013 at 3:44 PM, sebb  wrote:
> >> >
> >> >> On 10 September 2013 16:33, Daniel Kulp  wrote:
> >> >> >

> >> > Like we already say I think we aren't convinced about this because it
> >> will
> >> > imply to recopy these files across ~50 projects (plugins, shared
libs)
> >> and
> >> > thus update them the day we'll decide/need to do it. That's why we
always
> >> > prefered to bundle them at build time.
> >>
> >> The point is:
> >> the N&L files should be at the top-level of SCM.
> >> That is because SCM URLs are published, so the readers need to know
> >> the what the license conditions are.
> >>
> >
> > Wasn't it explained that SCM is actually a convenience, and that only
the
> > released source tarballs would actually matter here?
>
> It's not the case that SCM is only a convenience; the SCM locations
> are published to end-users on the web-site and in the POMs.
>
> And the SCM is anyway public.

Well, according to this thread
http://mail-archives.apache.org/mod_mbox/maven-dev/201308.mbox/%3CCA+nPnMwE=ON4AfAmFq3dvnpMdcsKt0u3G=RYvQWiZsmL=ea...@mail.gmail.com%3Eand
Stephen's answer, that was my understanding and I don't remember
someone pointing to somewhere at apache docs stating this is actually wrong.

> > In this case, Arnaud's point about only adding them at build time is
really
> > valid here.
>
> Not sure what you are referring to here, but the build is not relevant
> to this discussion.

Once again, in the above linked thread, my readings make me think there
were already answers from pmc that you would then have to "agree to
disagree" on this point.
And this is also the understanding I have from last Arnaud's answer above.

> >>
> >> The fact that having the N&L files there would likely have ensured
> >> they were in the source archive is an added bonus; it's not the
> >> primary reason for having them at the top-level of SCM.
> >>
> >
> > In the source, but possibly different in many places and having to
maintain
> > their sameness, that's again Arnaud's point.
> >
> > As an external observer and a developer, not duplicating files in many
> > places as they should really be the same seem quite a sound PMC choice
to
> > me.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: [VOTE] Release Maven 3.1.1

[Baptiste Mathus]

2013/9/12 sebb 

> On 12 September 2013 14:52, Arnaud Héritier  wrote:
> > On Thu, Sep 12, 2013 at 3:44 PM, sebb  wrote:
> >
> >> On 10 September 2013 16:33, Daniel Kulp  wrote:
> >> >
> >> > -1
> >> >
> >> > The src.tar.gz and src.zip files have lost their top level NOTICE and
> >> LICENSE files.   This is a regression from 3.1.0 (and 3.0.5).   That
> >> definitely needs to be fixed.  I don't have time today to look into
> that,
> >> but might tomorrow if someone doesn't beat me to it.
> >>
> >> The N&L files should also be present at the top-level of SCM.
> >> That is not a release-blocker per se, however if they had been there
> >> they would likely also be in the source archives at the top-level,
> >> which is a release blocker IMO.
> >>
> >
> >
> > Like we already say I think we aren't convinced about this because it
> will
> > imply to recopy these files across ~50 projects (plugins, shared libs)
> and
> > thus update them the day we'll decide/need to do it. That's why we always
> > prefered to bundle them at build time.
>
> The point is:
> the N&L files should be at the top-level of SCM.
> That is because SCM URLs are published, so the readers need to know
> the what the license conditions are.
>

Wasn't it explained that SCM is actually a convenience, and that only the
released source tarballs would actually matter here?
In this case, Arnaud's point about only adding them at build time is really
valid here.


>
> The fact that having the N&L files there would likely have ensured
> they were in the source archive is an added bonus; it's not the
> primary reason for having them at the top-level of SCM.
>

In the source, but possibly different in many places and having to maintain
their sameness, that's again Arnaud's point.

As an external observer and a developer, not duplicating files in many
places as they should really be the same seem quite a sound PMC choice to
me.

Re: What is the correct Git SCM URL for a branch?

[Baptiste Mathus]

See http://maven.apache.org/pom.html#SCM Hervé is talking about
xpath:/SCM/url which is indeed a scm web ui and said (developer)Connection
would be discussed in another thread.

Cheers
Le 24 août 2013 16:57, "Fred Cooke"  a écrit :

> I understood that the purpose of the SCM *URL* was to be able to *use*
> it with a tool (where browser != tool), as such, there is only one
> correct URL, the rest are paths for browsing on a file system or
> web-front end. I did this knowing it would fail to illustrate the
> point:
>
> fred@cheetah:~/workspaces$ git clone
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> Cloning into 'maven-2.2.x'...
> fatal:
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x/info/refs
> not found: did you run git update-server-info on the server?
>
> On Sat, Aug 24, 2013 at 4:49 PM, Hervé BOUTEMY 
> wrote:
> > I made some research and tests and here are my findings
> >
> > for the scm url, ie. web access like we have ViewVC url for svn, git
> provides
> > GitWeb equivalent to ViewVC (even if a lot of other solutions exist [1]),
> > which is what is configured on Apache git http
> > Then the GitWeb url format is in the git documentation [2]
> >
> > With this format, you can refer to branches, tags and revisions, like
> > following examples:
> >
> > branches:
> >   HEAD:
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD
> >   maven-3.0.x:
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-3.0.x
> >   maven-2.2.x:
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> >
> > tags:
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.1.0
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.0.5
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-2.2.1
> >
> > revisions: (same examples as previous tags)
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/5a0e6574404b4964522d90c3438e25574a95466c
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/fbdd91ba01387485598935fe7d340261239e6a31
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/238f83f8230b1e0ad3239ca7e4f849591331c801
> >
> >
> > From the GitWeb url format documentation [2], we should be able to
> navigate
> > into the reporitory directories by ading ":/", but it fails on
> Apache
> > GitWeb installation:
> >
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD:/maven-core
> > it works on Git's GitWeb installation
> >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> >
> > I don't know why Apache GitWeb is failing: previous version? some
> > configuration?
> > I know that even if the feature worked, this wouldn't permit us to let
> Maven
> > calculate automatically child scm url from parent, since the format
> requires
> > ':/' to be added for the first directory:
> >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2
> >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> > For actuel Maven to correctly calculate the second from the first, we
> would
> > need to write
> >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:
> > or  http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/
> > which are both unsupported by GitWeb actually
> >
> > Notice GitHub's url format works like a charm:
> > https://github.com/apache/maven/tree/maven-3.1.0
> > https://github.com/apache/maven/tree/maven-3.1.0/maven-core
> > https://github.com/apache/maven/tree/maven-3.0.x
> > https://github.com/apache/maven/tree/maven-3.0.x/maven-core
> >
> >
> > Should we configure scm url to point to GitHub mirror instead of Apache
> > canonical repo?
> >
> > I still didn't had a look at the way release plugin can transform branch
> url
> > to release url during pom.xml modification: I wanted to share these
> findings
> > first
> >
> > I had some thought about scm connection and developerConnection, but it's
> > another story and this mail is already quite long: we'll see it after we
> > improve web access support.
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1]
> >
> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Web_Interfaces
> >
> > [2] http://git-scm.com/docs/gitweb.html#_actions,_and_urls
> >
> > Le samedi 10 août 2013 13:12:00 Dennis Lundberg a écrit :
> >> Hi,
> >>
> >> I'm looking at the sources for Maven core in Git, which I'm learning
> >> as I go along.
> >>
> >> "master" is at version 3.1.1-SNAPSHOT and has this in its pom.xml
> >>   
> >>
> >> scm:git:https://git-wip-us.apache.org/repos/asf/maven.git
>  >> ection>
> >> scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.
> >> git
> >> https://git-wip-us.apache.org/repos/asf?p=maven.git
> >> HEAD
> >>   
> >>
> >> The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT and has this in its
> >> pom.xml 
> >>
> >> scm:git:https://git-wip-us.apache.org/repos/asf/maven.git
>  >> ection>
> >> scm:git:
> https://git-wip-us.apache.org/repos/asf/maven.
> >> git
> >> https://git-wip-us.apac

Re: Adding support for new dependency mediation strategy

[Baptiste Mathus]

Well, you might still be able to put put that kind of configuration inside
 or inside some plugin configuration block?
Le 23 août 2013 21:14, "Phillip Hellewell"  a écrit :

> Wow, I had no idea about this whole issue with being unable to move forward
> with the POM.  This is a really tough problem.  I just didn't even think
> about that because I'm used to working with XML parsers that don't even do
> schema validation.
>
> So I guess I'm pretty much stuck, because I can't put mediation settings in
> settings.xml or else I lose predictability, and I can't put them in the pom
> without a schema change (unless someone can tell me where to "sneak" them
> into the existing schema; j/k).
>
> Sadly, even if I wanted to just do it in-house and not try and contribute
> back, and even though I can get all our devs to install our custom build of
> mvn that recognizes the new schema, I'd still be hosed because we use
> external tools like Nexus and Jenkins that may parse the pom and barf on
> invalid XML.  We can't possibly build and maintain patches against all
> these external tools :(
>
> Phillip
>

Re: Adding support for new dependency mediation strategy

[Baptiste Mathus]

Wondering: is this strategy still gonna choose the newest version specified
even if I specify a version inside my pom? Or is it only gonna be used
between dependencies?

If the latter, I may agree it can be of interest.
But with the first I guess it would get crazy not being able to force the
version to be used.

Cheers
 Le 21 août 2013 01:08, "Phillip Hellewell"  a écrit :

> On Tue, Aug 20, 2013 at 3:15 PM, Jörg Schaible 
> wrote:
> >
> > Can you also tell, why you really want to do this? If you really want
> > "predictability", then use a shared parent, declare all involved
> > dependencies there in a dependencyManagement section and declare your
> direct
> > dependencies without any version. This way you can specify any version
> > explicitly.
>
> We have a shared parent, but we don't use dependencyManagement.
> Although we considered using it, we ultimately decided it would make
> things harder for us.
>
> Until recently we never had to worry about dependency mediation
> because we never allowed any version conflicts (we wrote a plugin to
> fail the build on any version clash).  Now we are wanting to allow it
> with some of our components.
>
> We already have predictability now, and we'll continue to have
> predictability with new mediation strategies, as long as we do it
> right.  Which means it needs to be controlled by a setting in the
> (parent) pom, not in settings.xml that users can tweak.  Also, it is
> important to use the "nearest definition" strategy by default for
> backwards compatibility.
>
> The "nearest definition" is not the be-all end-all best strategy for
> resolving version conflicts.  The "newest version" is a very desired
> strategy.  Failing is a very desired strategy.  Maven will be
> extremely more useful and valuable if it supports these other
> strategies.  Other tools out there like Gradle support different
> strategies (btw, Gradle defaults to "newest").
>
>
> http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:version_conflicts
>
> Phillip
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[Baptiste Mathus]

Le 15 août 2013 10:51, "Jörg Schaible"  a
écrit :
>
> Hi Oliver,
>
> Olivier Lamy wrote:
>
> > On 15 August 2013 08:53, sebb  wrote:
> >> On 14 August 2013 21:21, Dennis Lundberg  wrote:
> >>> On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
> >>>
>  On 13 August 2013 18:58, Dennis Lundberg  wrote:
>  > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
>  >> On 12 August 2013 20:10, Jason van Zyl  wrote:
>  >>>
>  >
>  > I have now read the threads that are referring to, and have not
>  > found a single link to any ASF rule stating that we need to
>  > include these things in a VOTE thread.
>  
>   So how do you propose that reviewers check the provenance of the
>   files in the source release?
>  >>>
>  >>> Are you looking for files that are in a distribution that didn't
>  >>> come
>  from source control? Everything else as far as provenance goes is
>  covered. Errant content is a potential problem, but everything in a
>  distribution should come from source control which no one has access
to
>  until they have a signed CLA on file.
>  >>
>  >> Yes. That is where the whole saga started.
>  >>
>  >> Proving provenance is why the SCM coordinates are needed for the
>  >> vote.
>  >>
>  >> The SCM details may also be useful to discover files accidentally
>  >> omitted from the source archive.
>  >
>  > You want to compare the contents of the *-source-release.zip with
>  > something from SCM, to make nothing bad has crept into the source
>  > bundle. So you need to know where in SCM you can find it. Have I
>  > understood you correctly?
> 
>  It's vital to be able to link the files in the source release
>  archive(s) to their origin in SCM.
> 
>  The provenance of any source files the ASF releases must be clearly
>  traceable.
> 
> >>>
> >>> This information is clearly traceable and available to anyone who
wants
> >>> to review a release made by the Maven project. Our process uses the
> >>> Release Plugin, which will put the POM from the SCM tag in the staging
> >>> directory along with the source-release.zip. In that POM wou will find
> >>> the URL to the original sources in SCM.
> >>>
> >>
> >> As has already been pointed out, SVN tags are not immutable, so the
> >> tag name alone is not sufficient.
> >
> > I think Stephen perfectly sum up the situation.
> > If you're not happy follow that.
> >
> > But please STOP the troll!
>
> The Maven PMC has made clear, that it knows about the problems and want to
> ignore it. However, please understand that Sebb is playing devil's
advocate
> here, because the same release process is used for other Apache projects
> where the PMCs will *not* ignore this flaws. Sebb is more or less
pestering
> you, because he is tired of having the same discussions in projects where
he
> *is* PMC and is therefore responsible for the release. So, it is a bit
short
> sighted to declare him as troll, simply because you (the Maven PMC)
decided
> to ignore the problem.

Having followed all the debates, I think it's certainly wrong to state the
problem has been "ignored". There were actually *many* answers, and it has
merely been disagreed on.

I've personally already expressed my take on it:
* I basically don't really mind
* adding this information would be nothing (a few seconds of work) compared
to the weight of re-reading always the same mails here :)

Cheers

Re: Maven 3.1.0 not adding assemblies to reactor

[Baptiste Mathus]

Hi,

Just a thought, could you please retry with -llr mvn option and see how it
goes?

Thanks


2013/8/9 Stanislav Ochotnicky 

> During rebuild of our Java packages for Fedora 20 we have encountered an
> interesting issue with Maven 3.1.0[1]
>
> When pom.xml is referencing assemblies in other module they are not
> resolved
> unless they are already in local or remote repository (i.e. reactor
> resolution
> of assemblies fails). Maven 3.0.5 works fine.
>
> I couldn't see anything in the release notes that would suggest this
> change was
> intentional, but before I file a bug maybe someone can correct me.
>
> Attached is a simple reproducer prepared by Mikolaj Izdebski
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=991454
>
> --
> Stanislav Ochotnicky 
> Software Engineer - Developer Experience
>
> PGP: 7B087241
> Red Hat Inc.   http://cz.redhat.com
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <http://cz.redhat.com>

Re: maven-scm-provider-jgit

[Baptiste MATHUS]

Maybe there's a difference between java/maven versions in use?

Where does it [not] work? Olivier? Domi, what was the version you
tested/dev'd it against?


2013/8/8 Stephen Connolly 

> On 8 August 2013 02:12, Olivier Lamy  wrote:
>
> > mvn clean install -pl :maven-scm-provider-jgit -am
>
>
> works on my mac
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Fwd: Name of a new Apache plugin for maven?

[Baptiste MATHUS]

2013/8/6 Barrie Treloar 

> On 6 August 2013 16:39, christofer.d...@c-ware.de
>  wrote:
> > Ok ...
> >
> > well I did read that naming info, I was just confused how to actually
> read it :-)
> >
> > "Apache Maven" "plugin" or "Apache" "Maven plugin" ... you see there are
> two semantics on how you could understand this. In my case it would
> actually be a "Maven plugin" from an Apache Project, but it's not a plugin
> from the "Apache Maven" Project ;-)
> >
> > But I the Definition regarding the Location of the sources is far less
> ambiguous.
> >
>
> Patches to improve documentation most welcome :)
>

Patches to improve documentation most welcome :)

Hi,

I've attached a small improvement proposal on
https://jira.codehaus.org/browse/MNGSITE-180 to try being clearer about the
naming pattern.
If someone can review and commit it if OK, that'd be great.

Cheers

-- Baptiste