Re: [VOTE] Require Java 17 for Maven 4

[Arnaud Héritier]

+1. It’s time to move on.

Arnaud Héritier
Twitter/GitHub/... : aheritier


Le mer. 28 févr. 2024 à 08:31, Benjamin Marwell  a
écrit :

> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
>
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
>
> PR: https://github.com/apache/maven/pull/1430
>
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
>
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
>
> ---
>
> Vote open for 72 hours:
>
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
>
> ---
>
> - Ben
>
> [1*]: https://www.apache.org/foundation/voting.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Maven Compiler + Annotations processor question

[Arnaud Héritier]

Hi team,

  That's a long time I didn't play with annotations processors and there is
something I don't understand.
  Maybe I get it wrong with annotations processors and/or with Maven
  What I want to accomplish is very similar to this post on stackoverflow:
https://cloudbees.atlassian.net/wiki/spaces/CE/blog/1294434773/Info%2BA%2Bnew%2Bhome%2Bfor%2BFastThread
  To summarise we have an annotation processor that we want to run the
module sources to generate automatically some tests.
  The problem is in the maven configuration. The proposed solution should
work from my POV:




org.apache.maven.plugins
maven-compiler-plugin



generate-test-classes

compile




org.my.UnitTestGenerationProcessor


${project.build.directory}/generated-test-sources/test-annotations

only






org.codehaus.mojo
build-helper-maven-plugin


add-test-source
generate-test-sources

add-test-source




${project.build.directory}/generated-test-sources/test-annotations








But it doesn't work and the call of generate-test-classes tries to compile
the generated test sources (even if proc=only) and it fails because the
Test classes are missing the test dependencies.

Any idea of what we could do wrong ?

-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Maven Dependencies Pop Quiz

[Arnaud Héritier]

On the last page, when you end the test, there is a button to display the
result.
I missed it too the first time.

On Thu, Mar 26, 2020 at 7:08 PM Andres Almiray  wrote:

> That's strange, you should get the number of correct answers at the end of
> the quiz although I don't know if it actually shows you which answers were
> incorrect when that's the case.
>
> All data and results will be made public once the quiz is closed.
>
> Thank you for participating.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Mar 26, 2020 at 7:04 PM jieryn  wrote:
>
> > Kind of frustrating to not be shown my score at the end...
> >
> > On Thu, Mar 26, 2020 at 1:01 PM Andres Almiray 
> wrote:
> > >
> > > Hello everyone!
> > >
> > > If I can ask you for 15 minutes of your time, I've put of a 14 question
> > pop
> > > quiz on dependency resolution. I'm hopeful that this quiz will let us
> > > realize a few things about the dependency resolution mechanism and its
> > > rules, perhaps address concerns in the future and make Maven better as
> a
> > > result.
> > >
> > > The quiz can be found at https://bit.ly/maven-dependencies-popquiz and
> > is
> > > totally anonymous (no email address collected). Unless you feel like
> > > sharing your name ;-)
> > >
> > > Some preliminary numbers to this date:
> > >
> > >  - 3 people have 13 correct answers
> > >  - 3 people have 12correct answers
> > >  - 10 people have 11 correct answers
> > >
> > > The current median is 8. Some quick feedback left:
> > >
> > >  - pretty tricky, even for an almost 20 year maven dude. good job!
> > >  - I've never seen documentation on this
> > >  - Good food for thought. I guess I generally hope Maven does what I
> > expect
> > > and when it doesn't, I start specifying more exactly what I want.
> > >
> > > Please feel free to share it with your colleagues and friends. More
> > entries
> > > mean more data and better results. Thank you!
> > >
> > > Cheers,
> > > Andres
> > >
> > > ---
> > > Java Champion; Groovy Enthusiast
> > > http://andresalmiray.com
> > > http://www.linkedin.com/in/aalmiray
> > > --
> > > What goes up, must come down. Ask any system administrator.
> > > There are 10 types of people in the world: Those who understand binary,
> > and
> > > those who don't.
> > > To understand recursion, we must first understand recursion.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: the problem of maven3 in centos7

[Arnaud Héritier]

Hi Michael

  Such kind of question should be better handled on the Maven users list.
  As far as I can see you have a problem of (transitive) dependency which
is using a system scope with an hardcoded path (/usr/lib/...) that you
don't have on your system

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies

  I won't privately reply more but if you subscribe to the Maven Users list
you will be able to receive more help

Cheers

On Thu, Nov 14, 2019 at 1:02 AM Michael  wrote:

> Mr. Arnaud Héritier
>I'm a maven3 user from china, you can call me Michael. Please
> pardon me as my English isn't very good.
>Here is the problem about meven3 when I use it in Centos7, I try to
> solve the problem with google and baidu, but I failed. So I write this
> letter, hope you can help me to fix it.
>
>
>  but thd jdk settings is good:
>
>  and the mvn -v is good too:
>
> and rpm -qa|grep java
>
>
>

-- 

Arnaud

Re: [VOTE] Retire Maven OSGi

[Arnaud Héritier]

+1

Le ven. 23 août 2019 à 15:17, Robert Scholte  a
écrit :

> Hi,
>
> The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects,
> including our ambitious ideas for the next major version(s) of Maven
> itself.
> To be able to gain more focus we need to criticize the current
> subprojects
> and decide if it is worth maintaining.
>
> https://maven.apache.org/shared/maven-osgi/ describes the main purpose
> in
> one line: Library for Maven-OSGi integration.
> There have been only 2 releases: 0.1.0 in July 2007 and 0.2.0 in December
> 2007 and just one open issue by Stuart McCulloch regarding an unclosed jar.
> It is unclear to me if this library is still used. The library is based
> on
> just 3 files: interface, default implementation and dedicated exception.
> Either the library is complete or never used anymore. In both cases I see
> no real reason to maintain it.
>
> I therefore propose that we retire the maven-osgi library.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
> [https://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
>
> --
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [VOTE] Retire Maven Ant Plugin

[Arnaud Héritier]

Whaouuu it's still here !!!
+1

On Tue, May 28, 2019 at 10:51 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> +100 from me...
>
> Kind regard
> Karl Heinz Marbaise
>
> On 28.05.19 20:54, Robert Scholte wrote:
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects and decide if it is worth maintaining.
> >
> > The goal of the Apache Maven Ant Plugin it to generate Ant build files
> based on a pom.xml and was released for the last time in December 2014. Due
> to the different ways that Ant and Maven work I don't think it makes
> sense anymore to maintain a plugin to transform Maven files to Ant.
> > See https://maven.apache.org/plugins/maven-ant-plugin/ [
> https://maven.apache.org/plugins/maven-ant-plugin/]
> >
> > To be clear, this is NOT the plugin you can use to run Ant within Maven;
> that's the maven-antrun-plugin.
> >
> > I therefore propose that we retire the maven-ant-plugin.
> >
> > I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: misleading docmentation

[Arnaud Héritier]

Hi Nir

  Thanks for your feedback.
  I admit that I really hate when the property name is different than the
configuration parameter but it seems properly defined in the doc :

*allowTimestampedSnapshots:*
Whether to allow timestamped SNAPSHOT dependencies. Default is to fail when
finding any SNAPSHOT.

   - *Type*: boolean
   - *Since*: 2.0-beta-7
   - *Required*: No
   - *User Property*: ignoreSnapshots
   - *Default*: false


http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots

You have to use
true in the plugin
configuration but -DignoreSnapshots=true in command line in that case


Regards

PS : I moved the discussion to the user dev mailing list where you receive
more help than directly from few commiters




On Thu, Oct 26, 2017 at 11:02 PM, Nir Bar-on  wrote:

> Hi all,
> I found misleading documentation in maven release plugin.
> it took me hours find it ..and to solve my issue because documentation was
> wrong .. i was about to drop the use of the plugin and start to think on
> another way to do "release.."
>
> the issue is that on documentation for the goal release:prepare, the
> parameter name is *"allowTimestampedSnapshots"*
> but it doesn't have any effect in case you have snapshot dependency.
> because on the source code of the plugin the value of the parameter name is
>
> * "ignoreSnapshots"*
>
>  the fix can be changing the documentation ..or changing the parameter
> name in the code
>
>
> [image: Inline image 1]
> resouces
> https://stackoverflow.com/questions/245932/how-to-release-a-
> project-which-depends-on-a-3rd-party-snapshot-project-in-
> maven/3959507#3959507
>
>
> 
> http://svn.apache.org/viewvc/maven/release/tags/maven-
> release-2.5.3/maven-release-plugin/src/main/java/org/
> apache/maven/plugins/release/PrepareReleaseMojo.java?view=markup
>
> 
>
>
> 
>
> Please confirm that this will be fixed ...
> Thanks!
> Nir
>
>
> 
>
>
> 
>
>
> 
>
>
> 
>
>


-- 

Arnaud

Re: Maven Docker Images

[Arnaud Héritier]

These images are kindly managed by a PMC member of our project (Carlos) but
yes they aren't managed directly by the project

We can easily see with him to improve this IMO.

When he started that (several years ago) Docker wasn't what it is nowadays.
With docker being mainstream I agree that we can reconsider this.

The docker image build/distribution could perhaps be part of our release
process.

WDYT Carlos ?

On Thu, Oct 19, 2017 at 4:16 AM, Mike Drob <md...@apache.org> wrote:

> I guess the natural follow-on question is whether the Maven community
> would consider publishing an official set of images? Or alternatively
> whether they should send a takedown notice to protect their brand and
> trademarks...
>
> On 2017-10-18 18:36, "Manfred Moser" <manf...@simpligility.com> wrote:
> > No. As you can see from the github URL this is NOT an apache URL.
> >
> > https://github.com/carlossg/docker-maven
> >
> >
> > Mike Drob wrote on 2017-10-18 16:32:
> >
> > > Hello,
> > >
> > > Are the images at https://hub.docker.com/r/_/maven/ considered to be
> official
> > > maven docker images and blessed/published by the PMC?
> > >
> > > Thanks,
> > > Mike
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Jenkins Maven build not seeing my .mvn folder?

[Arnaud Héritier]

It is https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5889


Le mar. 6 juin 2017 à 20:27, Arnaud Héritier <aherit...@gmail.com> a écrit :

> The problem with extensions is different. And I don't think we'll fix it.
> The problem .mvn and usage of -f is a maven bug fixed in 3.5.0 or 3.5.1
>
> Le mar. 6 juin 2017 à 19:36, Pascal <pascal.gr...@gmail.com> a écrit :
>
>> The existing bug to support core extensions:
>> https://issues.jenkins-ci.org/browse/JENKINS-30058
>>
>> As I said, the only solution so far is to use a Freestyle project. You can
>> find more details in the bug comments.
>>
>> Pascal
>>
>>
>> 2017-06-06 19:27 GMT+02:00 Pascal <pascal.gr...@gmail.com>:
>>
>> > Hello,
>> >
>> > I fear you have done everything correctly and the issue is with the
>> > Jenkins Maven plugin. There is already a bug report in the Jenkins Maven
>> > Plugin, but it's hard to find. If I recall how to find it, I will post
>> it
>> > here.
>> >
>> > Unfortunately, it does not look like an easy bug, so you cannot use the
>> > "Maven" Job type in Jenkins together with the .mvn folder feature.
>> However,
>> > what you can do is create a Freestyle Job and add a build step "Call
>> Maven
>> > goals".
>> >
>> > Cheers,
>> >
>> > Pascal
>> >
>> >
>> > 2017-06-06 18:13 GMT+02:00 Eric B <ebenza...@gmail.com>:
>> >
>> >> Hi,
>> >>
>> >> I'm cross posting this to StackOverflow (
>> >> https://stackoverflow.com/q/44394234/827480) b/c I'm not truly
>> convinced
>> >> this is a maven question per say.  Rather I think it is more something
>> due
>> >> to my Jenkins job config that is causing some issues, but I am hoping
>> that
>> >> maven users here may have encountered this in Jenkins as well.  Either
>> >> that, or maybe someone can point out that I'm using the .mvn folder
>> >> incorrectly.
>> >>
>> >> Essentially, I have a multi-module maven project that is set up as:
>> >>
>> >> |.mvn
>> >>  \-maven.config
>> >>  \-jvm.config
>> >> |superpom
>> >>  \-pom.xml (main project parent pom, includes module defns)
>> >> |module1
>> >>  \-pom.xml (parent points to ../superpom/pom.xml)
>> >>  \src
>> >>   \...
>> >> |module2
>> >>  \-pom.xml (parent points to ../superpom/pom.xml)
>> >>  \src
>> >>   \...
>> >>
>> >> My maven.config file is defined as:
>> >>
>> >> -Dsign.alias=cert
>> >> -Dsign.storepass=changeit
>> >> -Dsign.keypass=changeit
>> >> -Dcheckstyle.skip=true
>> >> -Dcobertura.skip=true
>> >> -Dpmd.skip=true
>> >> -DskipTests=true
>> >> -DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
>> >> -DuserName=test
>> >> -Dpassword=test
>> >> -f superpom/pom.xml
>> >>
>> >> If I run my maven build from the command line, everything builds as
>> >> expected. ie:
>> >>
>> >> [project]$ mvn clean install
>> >>
>> >> However, when I configure my jenkins job, it is failing as though it is
>> >> not
>> >> seeing/reading the .mvn/ folder/files. In fact, to be honest, I'm not
>> >> entirely sure how to configure my maven project in Jenkins. If I leave
>> my
>> >> ROOT pom definition as blank, then Jenkins complains it doesn't have a
>> >> pom.xml file.
>> >>
>> >> If I specify my root pom as superpom/pom.xml then it isn't loading any
>> of
>> >> my config files.
>> >>
>> >> To be safe, I've even tried adding my .mvn folder in my superpom
>> folder,
>> >> but that too is ignored.
>> >>
>> >> jenkins.log:
>> >>
>> >> [superpom] $ /var/jenkins_home/tools/hudson.model.JDK/JDK_7/bin/java
>> >> -cp /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-
>> >> agent-1.8.1.jar:/var/jenkins_home/tools/hudson.tasks.Maven_
>> >> MavenInstallation/Maven_3.3.9/boot/plexus-classworlds-2.5.2.
>> >> jar:/var/jenkins_home/tools/hudson.tasks.Maven_
>> >> MavenInstallation/Maven_3.3.9/conf/logging
>> >> jenkins.maven3.agent.Maven33Main
>> >>
>> /var/jenkins_home/tools/hudson.tasks.

Re: Jenkins Maven build not seeing my .mvn folder?

[Arnaud Héritier]

The problem with extensions is different. And I don't think we'll fix it.
The problem .mvn and usage of -f is a maven bug fixed in 3.5.0 or 3.5.1

Le mar. 6 juin 2017 à 19:36, Pascal <pascal.gr...@gmail.com> a écrit :

> The existing bug to support core extensions:
> https://issues.jenkins-ci.org/browse/JENKINS-30058
>
> As I said, the only solution so far is to use a Freestyle project. You can
> find more details in the bug comments.
>
> Pascal
>
>
> 2017-06-06 19:27 GMT+02:00 Pascal <pascal.gr...@gmail.com>:
>
> > Hello,
> >
> > I fear you have done everything correctly and the issue is with the
> > Jenkins Maven plugin. There is already a bug report in the Jenkins Maven
> > Plugin, but it's hard to find. If I recall how to find it, I will post it
> > here.
> >
> > Unfortunately, it does not look like an easy bug, so you cannot use the
> > "Maven" Job type in Jenkins together with the .mvn folder feature.
> However,
> > what you can do is create a Freestyle Job and add a build step "Call
> Maven
> > goals".
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > 2017-06-06 18:13 GMT+02:00 Eric B <ebenza...@gmail.com>:
> >
> >> Hi,
> >>
> >> I'm cross posting this to StackOverflow (
> >> https://stackoverflow.com/q/44394234/827480) b/c I'm not truly
> convinced
> >> this is a maven question per say.  Rather I think it is more something
> due
> >> to my Jenkins job config that is causing some issues, but I am hoping
> that
> >> maven users here may have encountered this in Jenkins as well.  Either
> >> that, or maybe someone can point out that I'm using the .mvn folder
> >> incorrectly.
> >>
> >> Essentially, I have a multi-module maven project that is set up as:
> >>
> >> |.mvn
> >>  \-maven.config
> >>  \-jvm.config
> >> |superpom
> >>  \-pom.xml (main project parent pom, includes module defns)
> >> |module1
> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >>  \src
> >>   \...
> >> |module2
> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >>  \src
> >>   \...
> >>
> >> My maven.config file is defined as:
> >>
> >> -Dsign.alias=cert
> >> -Dsign.storepass=changeit
> >> -Dsign.keypass=changeit
> >> -Dcheckstyle.skip=true
> >> -Dcobertura.skip=true
> >> -Dpmd.skip=true
> >> -DskipTests=true
> >> -DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
> >> -DuserName=test
> >> -Dpassword=test
> >> -f superpom/pom.xml
> >>
> >> If I run my maven build from the command line, everything builds as
> >> expected. ie:
> >>
> >> [project]$ mvn clean install
> >>
> >> However, when I configure my jenkins job, it is failing as though it is
> >> not
> >> seeing/reading the .mvn/ folder/files. In fact, to be honest, I'm not
> >> entirely sure how to configure my maven project in Jenkins. If I leave
> my
> >> ROOT pom definition as blank, then Jenkins complains it doesn't have a
> >> pom.xml file.
> >>
> >> If I specify my root pom as superpom/pom.xml then it isn't loading any
> of
> >> my config files.
> >>
> >> To be safe, I've even tried adding my .mvn folder in my superpom folder,
> >> but that too is ignored.
> >>
> >> jenkins.log:
> >>
> >> [superpom] $ /var/jenkins_home/tools/hudson.model.JDK/JDK_7/bin/java
> >> -cp /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-
> >> agent-1.8.1.jar:/var/jenkins_home/tools/hudson.tasks.Maven_
> >> MavenInstallation/Maven_3.3.9/boot/plexus-classworlds-2.5.2.
> >> jar:/var/jenkins_home/tools/hudson.tasks.Maven_
> >> MavenInstallation/Maven_3.3.9/conf/logging
> >> jenkins.maven3.agent.Maven33Main
> >> /var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.3.9
> >> /var/jenkins_home/war/WEB-INF/lib/remoting-3.7.jar
> >> /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-
> >> interceptor-1.8.1.jar
> >> /var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven3-
> >> interceptor-commons-1.8.1.jar
> >> 38679
> >> <===[JENKINS REMOTING CAPACITY]===>channel started
> >> using settings config with name Settings.xml
> >> Replacing all maven server entries not found in credentials list is true
> >> Executing Maven:  -B -f
> >> /var/jenkins_home/workspace/JB4(Maven)/superpom/pom.xml
> >> -Dmaven.repo.local=/var/jenkins_home/workspace/JB4(Maven)/.repository
> >> -s /tmp/settings4167440206098086967.xml clean install
> >> [INFO] Scanning for projects...
> >>
> >>
> >> I'm not sure if I am using the .mvn folder incorrectly, if there is
> >> something wrong with my Jenkins job configuration.
> >>
> >> Am I doing this right?  Am I missing a step somewhere?
> >>
> >> Thanks,
> >>
> >> Eric
> >>
> >
> >
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Excessive download/upload of maven-metadata.xml during maven deploy

[Arnaud Héritier]

Are you defining a mirror in your maven settings ?
How many different snapshots repositories are defined in your project and
it's transitive dependencies (hard to define but from central it should
never be the case)
My guess is that in your project and transitive dependencies you are
defining ~20 snapshots repositories (with different identifiers).
When you upload upload an artifact, maven doesn't know where each artifact
comes from and thus it is asking to each repository if there are some
metadata for it.
It you have a catch-all mirror defined in your settings it could end to
have maven asking 20 times the same metadata to your mirror (Maven doesn't
compare at all the repositories URLs to see if some repositories with
different identifiers are targeting the same url)


On Fri, May 12, 2017 at 9:31 PM, Dan Tran <dant...@gmail.com> wrote:

> and it happens at deploy phase only
>
> -D
>
> On Fri, May 12, 2017 at 12:01 PM, Dan Tran <dant...@gmail.com> wrote:
>
> >
> > my particular module has one optional RPM dependency. this means it only
> > downloads one dependency and no transitive
> >
> > not sure why this cause the strange metadata download behavior
> >
> > -D
> >
> >
> > On Fri, May 12, 2017 at 3:49 AM, Robert Scholte <rfscho...@apache.org>
> > wrote:
> >
> >> My guess: references to snapshots or version ranges in one of your
> >> (transitive) dependencies.
> >>
> >> Robert
> >>
> >
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Color logging in Maven 3.3.3

[Arnaud Héritier]

yes we need to fix this in maven core
We did it in this branch : https://github.com/apache/maven/tree/slf4j-log4j2
See
https://github.com/apache/maven/commit/dbad2e536a7024a277eef1c56eaa2286f9f2a7f9
And especially the fix in
maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
Arnaud


On Thu, Apr 30, 2015 at 6:30 AM, Gary Gregory garydgreg...@gmail.com
wrote:

 I thought this error message was no longer supposed to be displayed:

 [WARN] The SLF4J binding actually used is not supported by Maven:
 org.apache.logging.slf4j.Log4jLoggerFactory
 [WARN] Maven supported bindings are:
 [WARN] (from

 jar:file:/C:/Java/apache-maven-3.3.3/lib/maven-embedder-3.3.3.jar!/META-INF/maven/slf4j-configuration.properties)
 - ch.qos.logback.classic.LoggerContext
 - org.slf4j.helpers.Log4jLoggerFactory
 - org.slf4j.impl.SimpleLoggerFactory

 I created these steps as a reminder to myself:

 https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color/

 Am I missing something?

 Thank you,
 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Maven and pre-emptive authentication

[Arnaud Héritier]

Is it related to comments in https://jira.codehaus.org/browse/WAGON-405 ???
For sure the documentation can be updated if required

On Tue, Mar 31, 2015 at 9:57 AM, James Green james.mk.gr...@gmail.com
wrote:

 So how does one update the documentation to state that pre-emptive
 authentication is not possible..?

 On 30 March 2015 at 13:31, Gordon Cody gordon.c...@zafin.com wrote:

  Hello James
 
  It really does try twice. The first time it tries with no credentials
  supplied.
  This came to our attention when we upgraded from maven-2.0.9 to
  maven-3.0.5.
 
  We found out at that time that it had to do with being compliant to some
  web specification and there was no way to force it to use credentials on
  the first attempt.
 
  The delay is a mere fraction of a second for most files. On larger files
 it
  can be slightly irritating.
  We now avoid deploying ear files altogether by using the skip argument of
  the deploy plugin.
 
 
  Regards, Gord Cody
 
 
 
  On Mon, Mar 30, 2015 at 4:34 AM, James Green james.mk.gr...@gmail.com
  wrote:
 
   I am a little confused. According to:
  
   https://maven.apache.org/guides/mini/guide-http-settings.html
  
   Maven 3.0.4 defaults to pre-emptive authentication for HTTP PUTs.
  
   According to my haproxy logs, each PUT is done twice:
  
   1. PUT happens, receives a 401 response from Nexus
   2. PUT happens, receives a 201 response from Nexus
  
   Our installed version:
   ii  maven 3.0.4-2
 Java software project management and comprehension tool
  
   Is the documentation simply wrong or am I somehow mis-interpreting
  things?
  
   Thanks,
  
   James
  
 
 
 
  --
  Best Regards, Gord Cody
 
  Release Manager  Zafin Labs Americas Inc.
  179 Colonnade Road-Suite 100, Ottawa ON, Canada
  Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1 613-601-2734
  Web: http://zafin.com  Email: gordon.c...@zafin.com
 
  --
  Zafin - Canada
 
  --
  http://zafin.com
 
  http://zafin.com/
 
  --
 
  Connect with us
 
   http://www.youtube.com/user/ZafinGlobal
  http://www.linkedin.com/company/Zafin  http://twitter.com/Zafin
 
  News and Events
 
  Zafin joins the Deloitte Fast 50 and Fast 500 Rankings
  
 
 http://zafin.com/press-releases/zafin-ranks-16th-on-the-2014-deloitte-technology-fast-50-list/
  
 
  
 
 http://zafin.com/press-releases/zafin-ranks-16th-on-the-2014-deloitte-technology-fast-50-list/
  
 




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Documentation (wrongly?) says Maven 3.3.1 runs with Java 1.6

[Arnaud Héritier]

I'm a little bit lost with the download page
Several time it references Maven 3.2 but this one isn't available any more
(only in archives)
But 3.2 is the one to use for Java 6 users ? (If we exclude the usage of
toolschain)
I'm not sure why we are keeping 3.0, 3.1 and not 3.2

On Thu, Mar 19, 2015 at 10:05 AM, Anders Hammar and...@hammar.net wrote:

 MNG-5789 created to monitor this.
 Thanks for reporting!

 /Anders

 On Thu, Mar 19, 2015 at 8:52 AM, Arend v. Reinersdorff ar...@arendvr.com
 wrote:

  ok, thanks for the clarification.
 
  The system requirements on the download page are correct now.
  But the README.txt in the distribution is still wrong.
 
  Regards,
  Arend
 
 
  On Wed, Mar 18, 2015 at 2:54 PM, Jason van Zyl ja...@takari.io wrote:
 
   Olivier fixed the doco so that should do out shortly.
  
   On Mar 18, 2015, at 9:48 AM, Anders Hammar and...@hammar.net wrote:
  
That is correct, the docs haven't been updated. Maven 3.3+ requires
 JDK
   1.7.
   
/Anders (mobile)
Den 18 mar 2015 09:37 skrev Arend v. Reinersdorff 
 ar...@arendvr.com
  :
   
Hi,
   
Maven 3.3.1 requires Java 1.7:
- [MNG-5780] - upgrade Java minimum version prerequisite from Java 6
  to
Java 7
- When I try to run Maven 3.3.1 with Java 1.6 I get the exception:
Exception in thread main java.lang.UnsupportedClassVersionError:
org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0
   
   
But the documentation says the system requirements are still at Java
   1.6:
- On the download page:
   http://maven.apache.org/download.cgi#Requirements
- In README.txt when downloading Maven 3.3.1:
 System Requirements
 ---
 JDK:
   1.6 or above (this is to execute Maven - it still allows you to
  build
against 1.3
   and prior JDK's).
   
I assume the requirement is really Java 1.7 but the documentation
 has
   not
been updated?
   
Regards,
Arend
   
  
   Thanks,
  
   Jason
  
   --
   Jason van Zyl
   Founder, Takari and Apache Maven
   http://twitter.com/jvanzyl
   http://twitter.com/takari_io
   -
  
   happiness is like a butterfly: the more you chase it, the more it will
   elude you, but if you turn your attention to other things, it will come
   and sit softly on your shoulder ...
  
   -- Thoreau
  
  
  
  
  
  
  
  
  
  
  
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Documentation (wrongly?) says Maven 3.3.1 runs with Java 1.6

[Arnaud Héritier]

Hi,

  I tested 3.3 a little bit and didn't find any issue
  But it requires Java 7 if you need to build with an older version of Java
you'll have to setup a toolchain
  You can always find old releases from :
http://archive.apache.org/dist/maven/maven-3/
http://archive.apache.org/dist/maven/binaries/


cheers

On Thu, Mar 19, 2015 at 11:23 AM, Björn Raupach 
raupach.bjo...@googlemail.com wrote:

 Hi group,

 I have the same problem. Looking for the 3.2.x releases. Can’t upgrade to
 3.3.x yet.

 Or is it save to skip 3.2.x for now?

 /Björn

  On 19 Mar 2015, at 11:01 , Arnaud Héritier aherit...@gmail.com wrote:
 
  I'm a little bit lost with the download page
  Several time it references Maven 3.2 but this one isn't available any
 more
  (only in archives)
  But 3.2 is the one to use for Java 6 users ? (If we exclude the usage of
  toolschain)
  I'm not sure why we are keeping 3.0, 3.1 and not 3.2
 
  On Thu, Mar 19, 2015 at 10:05 AM, Anders Hammar and...@hammar.net
 wrote:
 
  MNG-5789 created to monitor this.
  Thanks for reporting!
 
  /Anders
 
  On Thu, Mar 19, 2015 at 8:52 AM, Arend v. Reinersdorff 
 ar...@arendvr.com
  wrote:
 
  ok, thanks for the clarification.
 
  The system requirements on the download page are correct now.
  But the README.txt in the distribution is still wrong.
 
  Regards,
  Arend
 
 
  On Wed, Mar 18, 2015 at 2:54 PM, Jason van Zyl ja...@takari.io
 wrote:
 
  Olivier fixed the doco so that should do out shortly.
 
  On Mar 18, 2015, at 9:48 AM, Anders Hammar and...@hammar.net wrote:
 
  That is correct, the docs haven't been updated. Maven 3.3+ requires
  JDK
  1.7.
 
  /Anders (mobile)
  Den 18 mar 2015 09:37 skrev Arend v. Reinersdorff 
  ar...@arendvr.com
  :
 
  Hi,
 
  Maven 3.3.1 requires Java 1.7:
  - [MNG-5780] - upgrade Java minimum version prerequisite from Java 6
  to
  Java 7
  - When I try to run Maven 3.3.1 with Java 1.6 I get the exception:
  Exception in thread main java.lang.UnsupportedClassVersionError:
  org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0
 
 
  But the documentation says the system requirements are still at Java
  1.6:
  - On the download page:
  http://maven.apache.org/download.cgi#Requirements
  - In README.txt when downloading Maven 3.3.1:
  System Requirements
  ---
  JDK:
1.6 or above (this is to execute Maven - it still allows you to
  build
  against 1.3
and prior JDK's).
 
  I assume the requirement is really Java 1.7 but the documentation
  has
  not
  been updated?
 
  Regards,
  Arend
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder, Takari and Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  happiness is like a butterfly: the more you chase it, the more it will
  elude you, but if you turn your attention to other things, it will
 come
  and sit softly on your shoulder ...
 
  -- Thoreau
 
 
 
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail/GTalk: aheritier AT gmail DOT com
  Twitter/Skype : aheritier

 -BEGIN PGP PUBLIC KEY BLOCK-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org

 mQENBE04AUEBCAC5Bu91Mtbjo7dnYWli6c7BMExsND8x+IsHazbGwQ/UAw0RY5hm
 rAkrxLYams2E/AsTq3FEdHExeLFei7BOdjNgg7iMvozcB2C5PTHSQyBpqbgF5/zo
 /eN7Rj5yl/r4AddGhpp88jg7B9PkF/Vs2ZPDACxVxXtDVp+//6pp/DTLohLIhx7j
 X1V2VDvbg9G3cFRHqng6qX/yXP0Zgy42ISd5qFQQP8tTZMt/ocN7+XeLT/JFkWNQ
 lAcORZ8/On7szNeqU3iqUrwvFu5tH2BkVbvL2/sV+TXsppbLR5trSMKChAXx/xR1
 7oa2I0raXg0dKsIAN+Zp9FvIMvBbd2KihjbjABEBAAG0LkJqb2VybiBSYXVwYWNo
 IDxyYXVwYWNoLmJqb2VybkBnb29nbGVtYWlsLmNvbT6JATgEEwECACIFAk04AUEC
 GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHyO/bs4ZyFdStwH/2s1zaz0
 NJcwF1PloylFngNlSTXCuMjj3HupUGfOygQJwWN3Ta1fv2vkmVPpT+0D+Ht3zopA
 P/039qgrMtQoIIUbVnHjykfb/bQmJWtB9VqDbBe/rWytaSpEiJvrD3NiRVLGpjHe
 P5Cwg6ayBEWrZo+79BlmXcurZp3L2X6V+0SensAQFpKIpPa8k4lHLjsRzTq8lkta
 2ORCvy9pmsWv91SmFXrcBv/mpSoZ8svbUvbJJulzmrVQUQE5s5BW7n46EbqmVqJR
 Th3SkIQtwC0Hs945p25hgK80dBQSHqP6P4lrnrFo6TCbnLMcAdd0scPa9kJmrnvv
 yHUmK8EffB5400i5AQ0ETTgBQQEIAPXiOZgblIz1wFuaxeaBGS3A37lFgpffm0Dl
 jofMC/B1i4BSZHz0U5NO7O1KJ3afRSU74ffCUmANIM+O9SopA8zlW/clSig9IRJj
 sYpi84OCsPT1kCMKpRARYChEPspitDeasrUmDQ3MbgH8vT0t2HWHEQdy4huGhBKm
 stm4eV331i7AMbhy3zspZYVbfMz3qV3WVf8g1wGiNadCjBTl8sbzlW5IaJFFV+Fx
 Ij6yzcco+1onHirxHm9Zdp/91hBZEiHbEAiGmKW6YIPvdLDITlFeRLf+X9D7/wpA
 ebAqr0Ta4g2XXCdwqwS6bakTOftvUB4wAnh7jDFsF7diLMbc8C8AEQEAAYkBHwQY
 AQIACQUCTTgBQQIbDAAKCRB8jv27OGchXSK4B/4pwSVL4fhJvwHh9eT40CD6D80D
 3gg6l2BpYCs/pfvM+zfC0pP7YTZpTK+EXlC6SdralurYg4IgODQ1QijpG8j9jh09
 Zb74SlLpZrrsB4jSXRrl/QHfFPdbZ7ONW8cRrNrrguCuVv6x0xCWkBzS+GyJKSUP
 2uYxzWq8

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

[Arnaud Héritier]

+1

thx

On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 +1

 On 25 November 2014 at 10:57, Stephen Connolly 
 stephen.alan.conno...@gmail.com 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=imghptbm=ischq=maven+logooq=maven+logo
 
 
 
 http://www.bing.com/images/search?q=maven+logogo=Submitqs=nform=QBLHscope=imagespq=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
 




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Jococo report using Jenkins without the need to configure jacoco-maven-plugin? possible?

[Arnaud Héritier]

something like this works for me :

mvn org.jacoco:jacoco-maven-plugin:0.7.1.201405082137:prepare-agent verify

+

sonar runner as post build



On Wed, Aug 6, 2014 at 4:31 PM, Justin Georgeson jgeorge...@lgc.com wrote:

 I believe you still need to configure jacoco-maven-plugin so that your
 tests are run with instrumentation, but you don't need to do the reporting
 part with maven. Jenkins will read the .exec file that Jacoco generates
 during test execution and publish reports from that.

  -Original Message-
  From: Dan Tran [mailto:dant...@gmail.com]
  Sent: Tuesday, August 05, 2014 9:31 PM
  To: Maven Users List
  Subject: Jococo report using Jenkins without the need to configure
 jacoco-
  maven-plugin? possible?
 
  Hello,
 
  I have an impression that I dont need bring in jacoco-maven-plugin to my
  poms, and just have Jenkins to run it at post build and magic will
 happen at
  Jenkins page.
 
  So far, I have no luck with that
 
  Any got this working?
 
  Thanks
 
  -Dan

 --
 This e-mail, including any attached files, may contain confidential and
 privileged information for the sole use of the intended recipient.  Any
 review, use, distribution, or disclosure by others is strictly prohibited.
  If you are not the intended recipient (or authorized to receive
 information for the intended recipient), please contact the sender by reply
 e-mail and delete all copies of this message.




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Welcome our new VP of Apache Maven, Hervé Boutemy

[Arnaud Héritier]

Congratulations Hervé. 


Thanks a lot Stephen for this year. 
—
Sent from Mailbox

On Sat, Jul 19, 2014 at 11:42 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:

 The role of VP of maven is more a technical and legal responsibility in
 that the ASF board requires an officer of the foundation to delegate the
 powers vested in the PMC to.
 A few years back, John Casey suggested that we should try rotating this
 burden amongst the PMC on a yearly-ish basis.
 I have been PMC chair for the last year, and it has been fun times, but
 when I took the unlucky victim role I said it would be for one year only.
 True to my word, I asked the PMC to nominate a replacement. Hervé was
 selected and at the most recent board meeting I was released from these
 responsibilities with board approving Hervé as our new VP
 Everyone please congratulate Hervé on being our next unlucky victim!
 Please also remember that it is the community that determines the direction
 of this project. The PMC is there to ensure the project plays by the rules,
 the PMC chair is here to serve the project, board and PMC.
 I wish Hervé all the best for his stint... And I won't fear taking the
 baton up again next time ;-)
 - Stephen
 -- 
 Sent from my phone

Re: New logo?

[Arnaud Héritier]

My brother played a little bit this week-end with our logo and especially
with our Apache Feather
[image: Inline image 1]
[image: Inline image 2]
I added them in the wiki :
https://cwiki.apache.org/confluence/display/MAVEN/Logo+contest
He will try to give more ideas soon

HTH

cheers

Arnaud


On Mon, Jan 13, 2014 at 1:26 PM, Will Hoover java.whoo...@gmail.com wrote:

 I have a wiki account (whoover), but it doesn't look like I have access to
 edit the page.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Friday, January 10, 2014 3:24 PM
 To: Maven Users List
 Subject: Re: New logo?

 Somebody with wiki access will add it for you If you have a wiki
 account, I *should* be able to give you access to add it yourself... I'm
 only the flipping PMC chair like... But for the life of me I cannot find
 out
 *how* to do so :-O

 On Friday, 10 January 2014, Will Hoover wrote:

  Here's one that may be a little more logo-ready than the last one I sent.
  How can I get it added to the wiki?
 
  http://s10.postimg.org/gceih8g95/maven3.png
 
  -Original Message-
  From: Arnaud Héritier [mailto:aherit...@gmail.com javascript:;]
  Sent: Thursday, January 09, 2014 12:48 PM
  To: Maven Users List
  Subject: Re: New logo?
 
  Added in the list :
  https://cwiki.apache.org/confluence/display/MAVEN/Logo+contest
 
 
  On Thu, Jan 9, 2014 at 6:35 PM, Will Hoover
  java.whoo...@gmail.comjavascript:;
  wrote:
 
   Here's a VERY rough draft of a possible logo (I'm sure someone else
   can make it look more sleek):
  
   http://s21.postimg.org/41q3n4mk7/maven.png
  
   -Original Message-
   From: t.cserve...@gmail.com javascript:;
   [mailto:t.cserve...@gmail.comjavascript:;]
  On Behalf
   Of Tamás Cservenák
   Sent: Thursday, January 09, 2014 11:33 AM
   To: Maven Users List
   Subject: Re: New logo?
  
   About raven, is already taken:
   http://www.maven.co/
  
   Some sneaky peaks for same named (but non related sites) -- just
   to see what others came up with:
   http://www.maven-sf.com/
   http://lasp.colorado.edu/home/maven/
   http://www.php-maven.org/
  
   And my personal fav:
   http://mavenberlin.com/en
  
   Their stylised M made out of two triangles is just great.
  
  
   And then, as I also like abstract things a bit more than explicit
   drawings representing explicit stuff/beings, I figured what might
   represent visually Maven (I admit, was inspired with MavenBerlin
   intersecting triangles, as there, it reflects the intersection of
  multidisciplinary creativity):
   a mountain(s), a twin peak (M), you have to climb. (and
   everyone finish their story, mountain might be effort, knowledge,
 sweat
   or whatever :D )
  
   Something like these
  
   http://www.leelau.net/2005/clemenceau/Miscellanous/traverseduplicate
   mo
   untainnwview04.jpg
  
   http://3.bp.blogspot.com/-JFyYp4QeFvU/Td_kvtpZNBI/AFk/_axAJl
   lI
   gF8/s1600/snowcap2.png
  
   And finally, just a quick quick silly draft of logos, two versions.
  
   First, is obviously what maven is today/ :D
  
   Second is the one with stylized peaks, variations on M as mountain
   idea:D
  
   http://screencast.com/t/JSpjKNrhBJLJ
  
  
  
  
  
  
   On Thu, Jan 9, 2014 at 4:51 PM, Mark H. Wood
   mw...@iupui.edujavascript:;
  wrote:
  
On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
 All of the logos are OK, but none of them really symbolize
 anything in particular about Maven. IMO the best logos
 encapsulate the purpose of the project somehow, either overtly,
 covertly or both.
   
Good point.  I was associating with the name Maven, looking for
a symbol of in-depth understanding of a specialized field.
   
http://en.wiktionary.org/wiki/maven
   
So, what does Maven do?  It passes unique source and object code
inputs through a standardized process, guided by an expression of
the relationships among those inputs, to assemble a well-specified
configuration of runnable code.  What does that look like?
   
--
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.
   
  
  
   
   - To unsubscribe, e-mail:
   users-unsubscr...@maven.apache.orgjavascript:;
   For additional commands, e-mail:
   users-h...@maven.apache.orgjavascript:;
  
  
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:;
  For additional commands, e-mail: users-h...@maven.apache.org
 javascript:;
 
 

 --
 Sent from my phone


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

Re: New logo?

[Arnaud Héritier]

it could be seen also as a coffee machine taking beans in entry to produce
a cup of java
The - is that it is fully java minded while Maven tried to conquer (with
few success) others platforms (C++ ...)
Note : Also the coffee machine can replace some others activities while
maven is building :-)
http://blog.octo.com/wp-content/uploads/2009/09/maven-building.png



On Fri, Jan 10, 2014 at 6:00 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Do you mean something like maven-16 that I just uploaded to the contest
 wiki page?

 https://cwiki.apache.org/confluence/download/attachments/38569278/maven-16.png?version=1modificationDate=1389373170779api=v2


 On 10 January 2014 16:40, Kristian Rosenvold
 kristian.rosenv...@gmail.comwrote:

  Way cool; this toy is a nordic classic (in wood). I can see Jar  War
  on the boxes.
 
  http://www.sprell.no/produktbilder/2013/Brio_Putteboks_rød.jpg
 
  For some reason I'm not entirely sure I understand I also enjoy the
 train:
 
 
 
 http://playworldcorp.com/wp-content/uploads/2012/03/wooden-toys_playworld_corp.jpg
 
  I suppose it's because it's a goods train (not a passenger train), and
 the
  individual carriages contain my jar files...
 
  Kristian
 
 
 
  2014/1/10 Lyons, Roy roy.ly...@cmegroup.com
 
   HAH.  I like that.  It makes me think of the kids toy where you put
  shapes
   into holes.
  
  
 
 http://www.toysrus.com/graphics/media/trus/Aplusplus/2012/2501235/MATTEL-25
   01235-01.jpg
  
   Each block shape represents a type of output (.war, .jar, .ear, .so,
  .dll,
   .zip, .someotherextensionthatyoudreamup)
  
   Each hole represents a workflow to make that happen.  Ok its a little
 bit
   reverse order, and more like
  http://static.ddmcdn.com/gif/play-doh-12.jpg
  
  
  
  
   Anyhow, I like the cookie cutter approach to a logo because it goes
  with
   Kristian's sentiment (which I happen to agree with once I read it).
  
   Perhaps even an actual logo as a set of cookie cutters (kind of like
   http://ecx.images-amazon.com/images/I/41BUOIKf4zL.jpg which is funny
   because it has all kinds of animals in it too )
  
  
  
  
   On 1/10/14 1:20 AM, Kristian Rosenvold kristian.rosenv...@gmail.com
 
   wrote:
  
   I think the association-work around what maven /is/ is a great way to
   approach a logo contest elsewhere. I have worked with some great
 graphic
   designers in my time, and the kind input the good ones want are
  typically
   related around your thoughts/feelings around the product rather than
  which
   particular animal you prefer, which is a bit of a secondary kind of
  input
   along with all different kinds of other constraints/ideas (the boss
   prefers
   blue).
   
   When I first encountered maven I had come to the realization that all
 my
   ant projects were basically the same, and that there was no reason for
   customizing
   what was basically a standard process. So maven gives me associations
  to a
   mass-production line at a factory, rather than a tailor making
  individual
   processes. Furthermore, the lifecycle amplifies the idea of a
   conveyor-belt
   mass-production line; all parts move through the same conveyor belt
   process, stopping at
   individual stages to get work done. I would almost be willing to think
  of
   a
   waterfall (Uh-oh...)
   
   So it would appear to me that I'm not thinking of an animal at all !
   
   Kristian
   
   
   
   
   
   
   
   2014/1/9 Mark H. Wood mw...@iupui.edu
   
On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
 All of the logos are OK, but none of them really symbolize
 anything
  in
 particular about Maven. IMO the best logos encapsulate the purpose
  of
   the
 project somehow, either overtly, covertly or both.
   
Good point.  I was associating with the name Maven, looking for a
symbol of in-depth understanding of a specialized field.
   
http://en.wiktionary.org/wiki/maven
   
So, what does Maven do?  It passes unique source and object code
inputs through a standardized process, guided by an expression of
 the
relationships among those inputs, to assemble a well-specified
configuration of runnable code.  What does that look like?
   
--
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.
   
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: New logo?

[Arnaud Héritier]

I agreed about the animal/mascot choice and its meaning.
We come back to another thread (on dev ML AFAIR) : what Maven is for you ?
How to describe it (easily) ? What is differentiating it from others tools
like Makefile, ant, gradle, builder 

Arnaud


On Thu, Jan 9, 2014 at 4:39 PM, Mark H. Wood mw...@iupui.edu wrote:

 On Thu, Jan 02, 2014 at 03:53:46PM -0500, Jeffrey E Care wrote:
  Stephen Connolly stephen.alan.conno...@gmail.com wrote on 01/02/2014
  02:06:55 PM:
 
   I personally liked the anteater idea... We can ask the Ant PMC if we
  have a
   winning logo that we are worried about
 
  While some Ant folks might appreciate the tongue-in-cheek nature of an
  anteater logo, I think it be seen by many more folks as unnecessarily
  antagonistic.

 Perhaps.  I think it's a cute idea, but I feel that Maven and Ant have
 different jobs, so for many it might be puzzling instead.  I think
 there'd be quite a number of questions why's your mascot an anteater,
 of all things?

 --
 Mark H. Wood, Lead System Programmer   mw...@iupui.edu
 Machines should not be friendly.  Machines should be obedient.




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: New logo?

[Arnaud Héritier]

Added in the list :
https://cwiki.apache.org/confluence/display/MAVEN/Logo+contest


On Thu, Jan 9, 2014 at 6:35 PM, Will Hoover java.whoo...@gmail.com wrote:

 Here's a VERY rough draft of a possible logo (I'm sure someone else can
 make it look more sleek):

 http://s21.postimg.org/41q3n4mk7/maven.png

 -Original Message-
 From: t.cserve...@gmail.com [mailto:t.cserve...@gmail.com] On Behalf Of
 Tamás Cservenák
 Sent: Thursday, January 09, 2014 11:33 AM
 To: Maven Users List
 Subject: Re: New logo?

 About raven, is already taken:
 http://www.maven.co/

 Some sneaky peaks for same named (but non related sites) -- just to see
 what others came up with:
 http://www.maven-sf.com/
 http://lasp.colorado.edu/home/maven/
 http://www.php-maven.org/

 And my personal fav:
 http://mavenberlin.com/en

 Their stylised M made out of two triangles is just great.


 And then, as I also like abstract things a bit more than explicit drawings
 representing explicit stuff/beings, I figured what might represent visually
 Maven (I admit, was inspired with MavenBerlin intersecting triangles, as
 there, it reflects the intersection of multidisciplinary creativity):
 a mountain(s), a twin peak (M), you have to climb. (and everyone
 finish their story, mountain might be effort, knowledge, sweat or
 whatever :D )

 Something like these

 http://www.leelau.net/2005/clemenceau/Miscellanous/traverseduplicatemountainnwview04.jpg

 http://3.bp.blogspot.com/-JFyYp4QeFvU/Td_kvtpZNBI/AFk/_axAJllIgF8/s1600/snowcap2.png

 And finally, just a quick quick silly draft of logos, two versions.

 First, is obviously what maven is today/ :D

 Second is the one with stylized peaks, variations on M as mountain idea:D

 http://screencast.com/t/JSpjKNrhBJLJ






 On Thu, Jan 9, 2014 at 4:51 PM, Mark H. Wood mw...@iupui.edu wrote:

  On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
   All of the logos are OK, but none of them really symbolize anything
   in particular about Maven. IMO the best logos encapsulate the
   purpose of the project somehow, either overtly, covertly or both.
 
  Good point.  I was associating with the name Maven, looking for a
  symbol of in-depth understanding of a specialized field.
 
  http://en.wiktionary.org/wiki/maven
 
  So, what does Maven do?  It passes unique source and object code
  inputs through a standardized process, guided by an expression of the
  relationships among those inputs, to assemble a well-specified
  configuration of runnable code.  What does that look like?
 
  --
  Mark H. Wood, Lead System Programmer   mw...@iupui.edu
  Machines should not be friendly.  Machines should be obedient.
 


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




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Changes in how exclusions are applied transitively ?

[Arnaud Héritier]

Maybe it is documented in aether release note ?
We probably should add a link to it or include it in our release note.
This is the problem to have a core component outside of the project.
It makes it difficult to have a global overview of all changes done in
the project itself and all its dependencies updates.

-
Arnaud

Le 28 juil. 2013 à 11:55, Stanimir Stamenkov s7a...@netscape.net a écrit :

 [See my reply below the quote.]

 Wed, 24 Jul 2013 20:20:49 +0200, /Grégory Joseph/:

 I can't seem to find an accurate trace of this in the release notes,
 so I thought I'd just ping the list - Changes in how exclusions are
 applied transitively between Maven 2.2.1 and 3.1 ?

 Here's a situation: A has dependencies on B and C. Both transitively
 depend on D  (through X, which is irrelevant, I think)  but B excludes
 it (on its dep declaration of X)

 With 2.2.1, D was (wrongly imo) excluded from A (depending on
 dependency order, seemingly)

 With 3.1, it appears to behave correctly.

 Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
 where I need to work around the bug, currently by removing the
 exclusions. That's currently OK, but at some point, those exclusions
 will be re-added (in A or in a new project) and we'll face the same
 issue again, without any clue as to why.

 How have people dealt with this so far ?

 I'm not sure I fully understand you, but I'm also stuck with Maven
 2.2.1 currently, and I've noticed when excluding a transitive
 dependency it excludes it from other dependencies which have it as a
 transitive dependency.  The other dependencies I don't want to
 exclude the transitive dependency from are either test or
 provided (needed only during build, actually).  To workaround this
 I've declared the dependency I want to exclude as provided in a
 'dependencyManagement' section, so it doesn't get included
 automatically in WAR and similar packages.  See if this approach
 might help you, too.

 --
 Stanimir

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


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

Re: maven-release-plugin with github project

[Arnaud Héritier]

Someone show me a similar issue with the release plugin in a project
using git where the parent/reactor is at the same level than modules
(moreover each modules where git submodules AFAIR )

The usage of relative path with in the reactor breaks the release.
There is an issue in Jira with a patch but AFAIR there was only the
code fix (no new test ..)

-
Arnaud

Le 27 juil. 2013 à 18:14, alejandro.e...@miranda.com
alejandro.e...@miranda.com a écrit :



 I'm  trying to release a multimodule maven project cloned in github. My  
 project has the parent pom as a submodule of the root aggregator. if i  run 
 the release in dryRun mode it works fine, however if I run it for  real this 
 is what i get near the end


 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml 
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml  
 jrobocom-samples/legends/pom.xml jrobocom-samples/simple/pom.xml  
 jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git commit --verbose -F 
 /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml 
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml  
 jrobocom-samples/legends/pom.xml jrobocom-samples/simple/pom.xml  
 jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git push  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  master:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Parent POM  SKIPPED
 ...
 [INFO] Bank-jumper ... SKIPPED
 [INFO] The overall aggregator  FAILURE [3:30.447s]
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 3:32.658s
 [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
 [INFO] Final Memory: 9M/44M
 [INFO] 
 
 [ERROR]  Failed to execute goal  
 org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  (default-cli) on 
 project jrobocom-aggregator: Unable to commit files
 [ERROR] Provider message:
 [ERROR] The git-push command failed.
 [ERROR] Command output:
 [ERROR]  fatal:  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  not 
 found: did you run git update-server-info on the server?
 [ERROR] - [Help 1]


 If  I run that same git push command by hand it does give me that error,  
 however, if i run the push with the url just up to .git and remove the 
 /jrobocom-aggregator it works fine

 Where  does the MRP take the push url from? i'm running mvn from the root  
 aggregator since i want to release all submodules together but i don't  see 
 why the push url should include the aggregator's artifact id

 What am i doing wrong? this seems like the canonical release procedure

 This  is the aggregator POM (before running the release) in case anyone is  
 interested https://github.com/theHilikus/JRoboCom/blob/master/pom.xml  and 
 from there you can find all the other poms

 Thank you,
 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.

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

Re: maven-release-plugin with github project

[Arnaud Héritier]

] --**--**
 
 [ERROR]  Failed to execute goal org.apache.maven.plugins:**
 maven-release-plugin:2.4.1:**prepare (default-cli) on project
 jrobocom-aggregator: Unable to commit files
 [ERROR] Provider message:
 [ERROR] The git-push command failed.
 [ERROR] Command output:
 [ERROR]  fatal: https://github.com/theHilikus/**JRoboCom.git/jrobocom-**
 aggregator/info/refshttps://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refsnot
  found: did you run git update-server-info on the server?
 [ERROR] - [Help 1]


 If  I run that same git push command by hand it does give me that error,
  however, if i run the push with the url just up to .git and remove the
 /jrobocom-aggregator it works fine

 Where  does the MRP take the push url from? i'm running mvn from the
 root  aggregator since i want to release all submodules together but i
 don't  see why the push url should include the aggregator's artifact id

 What am i doing wrong? this seems like the canonical release procedure

 This  is the aggregator POM (before running the release) in case anyone
  is  interested https://github.com/theHilikus/**
 JRoboCom/blob/master/pom.xmlhttps://github.com/theHilikus/JRoboCom/blob/master/pom.xml
  and from there you can find all the other poms

 Thank you,
 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.


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


 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.


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




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [VOTE] Retire Maven Model Converter

[Arnaud Héritier]

+1

-
Arnaud

Le 20 juil. 2013 à 19:27, Dennis Lundberg denn...@apache.org a écrit :

 Hi,

 The only consumer of Maven Model Converter we have left at the Apache
 Maven project is Maven One Plugin. If the vote for the retirement of
 Maven One Plugin succeeds we should also retire Maven Model Converter.
 The last release was made almost six years ago. Last time I checked
 Maven Model Converter was also used by the Apache Archiva project. The
 retirement plan is to move the component to the Apache Archiva
 project, if they want it.

 http://maven.apache.org/shared/maven-model-converter/

 I therefor propose that we retire maven-model-converter.

 If this vote is successful I will make one final release of the
 component (there are some issues that have been fixed) making it clear
 on the component site that it has been retired. After that the source
 code will be moved to the Apache Archiva project in Subversion, or if
 they do not want it to 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...

 --
 Dennis Lundberg

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


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

Re: Maven 2 tree vs Maven 3 list

[Arnaud Héritier]

Even if I find this bug critical I think nobody had the time to study
it more deeply (me the first) and for now I'm always downgrading to
maven 2 and the dependency plugin 2.4 when I have to use either the
tree or the list goals (which is a mess).

Like you I provided some logs but I didn't succeeded to create an easy
test case to create an integration test case.

Aether is sadly a bug black box for many of us which explains why it's
not easy to fix.

-
Arnaud

Le 12 févr. 2013 à 08:09, Richard Vowles
rich...@bluetrainsoftware.com a écrit :

 So do we know if they are being worked on?

 Is there a page somewhere that might explain where to start to find aether
 bugs? I remember the last time I looked and it was seriously confusing :-)

 Thanks for the heads up.
 On Feb 12, 2013 7:26 PM, Arnaud Héritier aherit...@gmail.com wrote:

 Yes there are some known issues already open in the dependency plugin
 Jira. The bug is somewhere in the dependency walker of aether. It
 seems that aether has the right deps but it doesn't allow plugins (I
 had the bug in dependency plugin but also in enforcer) to browse these
 deps accordingly to what it has in memory.

 -
 Arnaud

 Le 12 févr. 2013 à 06:55, Richard Vowles
 rich...@bluetrainsoftware.com a écrit :

 I made a bug report focused on the disappearing dependencies in Aether.

 http://jira.codehaus.org/browse/MNG-5433

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



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

Re: Maven 2 tree vs Maven 3 list

[Arnaud Héritier]

Yes there are some known issues already open in the dependency plugin
Jira. The bug is somewhere in the dependency walker of aether. It
seems that aether has the right deps but it doesn't allow plugins (I
had the bug in dependency plugin but also in enforcer) to browse these
deps accordingly to what it has in memory.

-
Arnaud

Le 12 févr. 2013 à 06:55, Richard Vowles
rich...@bluetrainsoftware.com a écrit :

 I made a bug report focused on the disappearing dependencies in Aether.

 http://jira.codehaus.org/browse/MNG-5433

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

Re: 1.0.0-SNAPSHOT considered older than 1.0.0?

[Arnaud Héritier]

I don't have the time to check the doc but if it's not in, this is a big
error (don't hesitate to open an issue)
A SNAPSHOT is the development version before producing the release.
A SNAPSHOT is older than its release
1.0.0-SNAPSHOT - 1.0.0- 1.0.1-SNAPSHOT - 1.0.1 - ..

Cheers


On Thu, Dec 20, 2012 at 3:02 PM, org.apache.maven.u...@io7m.com wrote:

 Hi.

 I can't find any documentation on the Maven site about snapshots. I'm
 trying to determine whether a snapshot is considered to be older or
 newer than the version number prefix.

 Is 1.0.0-SNAPSHOT considered to be the current HEAD, having a
 theoretical 1.0.0 at some point in the past, or is 1.0.0-SNAPSHOT
 considered to be a precursor to some future 1.0.0 release?

 The only information I can find seems to be off-site at:


 https://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-IncorporatingSNAPSHOTversionsintothespecification

 The Maven user guide mentions that snapshots will be described later
 in the guide - but they aren't.

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




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Getting code from dependency

[Arnaud Héritier]

in my-artifact module you configure the source lugin to deploy the jar with
these sources and then in your project you use it with the classifier
sources

dependency
  groupIdmy-group/groupId
  artifactIdmy-artifact/artifactId
  version${my-version}/version
  classifiersources/classifier
/dependency

http://maven.apache.org/plugins/maven-source-plugin/index.html


On Tue, Dec 18, 2012 at 2:34 AM, anjibman anji...@hotmail.com wrote:

 Hi All,

 I am trying to find a tag/way so that I can get the source code for the
 dependency in Maven. I have dependency as

 dependency
   groupIdmy-group/groupId
   artifactIdmy-artifact/artifactId
   version${my-version}/version
 /dependency

 I have other dependencies also but I want source code from this dependency
 only.

 Thanks



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Getting-code-from-dependency-tp5738980.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Seeking feedback on “Recursive Maven considered harmful”

[Arnaud Héritier]

The problem is also with Java itself.
Let's take a project with a war depending of a jar produced by another
module or an ear relying on several war and you cannot use anymore
something below install (it should be package to at least find the archive
in the target dir and not to have to find it in the local repo)
But yes all plugins should have an update/incremental behavior but it's not
easy to do because there are many factors that may require to rebuild some
parts of your project (You may edit your settings.xml, a pom.xml ).
It's not (sadly) as simple as one source file - one compiled file because
of all things possible with java (inner-classes, code generation from
annotations ...) or with some additional libs. The problem is that an
incremental build that mostly work may be worst than no incremental build
at all because instead of loosing always many time to have a secured result
you can regularly lost a lot of time because of a random behavior.
Otherwise I'm agree with the blog post and would dream to have something as
performant as what we can have with make.

Arnaud


On Mon, Dec 17, 2012 at 1:45 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 And I try to remove such bugs as and when I find them... but yes I agree
 it's a pain... but people should be more aware that it is a hack and they
 would be better served by fixing the root cause... not applying the
 install hack


 On 17 December 2012 12:26, Benson Margulies bimargul...@gmail.com wrote:

  with respect to 'the install hack': If I had a dollar for every
  occasion where a bug in a plugin or the core required me to use it,
  I'd be a richer man by a considerable amount.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

[ANN] Maven Dependency Analyzer 1.3 Released

[Arnaud Héritier]

The Maven team is pleased to announce the release of the Maven Dependency 
Analyzer, version 1.3

Analyzes the dependencies of a project for undeclared or unused artifacts.

http://maven.apache.org/shared/maven-dependency-analyzer/

You should specify the version in your project's dependency configuration:

dependency
  groupIdorg.apache.maven.shared/groupId
  artifactIdmaven-dependency-analyzer/artifactId
  version1.3/version
/dependency


Release Notes - Maven Dependency Analyzer - Version 1.3

Improvement
* [MSHARED-207] update to Java 5

New Feature
* [MSHARED-253] add a way to force used dependencies when they are detected as 
unused (because of bytecode analysis)

Task
* [MSHARED-209] update asm version


Enjoy,

-The Maven team

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

Re: Arguments for Maven vs. Gradle

[Arnaud Héritier]

I find also such discussion interesting
it is always good to know what is existing arround and if some inputs may
drive to improve Maven itself.
The fact to know also why Maven is here is an important thing to better us
it.
This is especially what we did with Nicolas De loof in our French book few
years ago and readers loved a lot because they were able to understand why
some choices were done in maven ..

About Gradle, I studied it and tries to use it but for now I'm always not
convinced about its ideology. I like to be free of my choices but I'm not
sure that it is always a good thing. Standardization may be seen as a
limitation but for whom ? For the team using it ? For people who will join
later the project and will find something known ? For the transversal team
in a company that will support dev teams ? Depending of the context, the
enforced standardisation may be a good thing. I'm sure that a gradle
build in experts hands may be magical but how often will it be the case and
for how many times ?

What is fun is that this debate Gradle vs Maven makes me think to the
debate Git vs SVN we have on the dev list. What do we prefer ? Something
powerful but perhaps to not put in all hands ? Or a common tool that is
just doing the job ?

Arnaud


On Tue, Sep 11, 2012 at 10:33 PM, Graham Leggett minf...@sharp.fm wrote:

 On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote:

  I don't think it's useful to debate build tools and their builders or
  tools on this list.

 I believe it is very useful. Many new users to maven don't fully
 understand the problem maven tries to solve, and a discussion like this one
 will hopefully shed more light on why maven approaches the build problem as
 it does.

 Regards,
 Graham
 --




-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: jdocbook

[Arnaud Héritier]

And you may be polite ...
The jdocbook plugin isn't developed by the ASF team but I confirm (at
least before) that it was annoying to use because it defines a custom
packaging, thus you need to configure it and it has no option to be
skipped.
The only solution is to skip its module by defining it in a profile in
the parent project but I'm not a big fan of such solution.

Le 14 juin 2012 à 16:29, Wayne Fay wayne...@gmail.com a écrit :

 What is the way to exclude this fucking lame and useless jdocbook from
 build ?

 No one can help you without more information about your build.
 Probably you need to ask whoever in your organization set up your
 project/build for help to turn off the jdocbook plugin if you are not
 happy with the results of the plugin.

 Wayne

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


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

Re: jdocbook

[Arnaud Héritier]

Yea. They can insult us but not in the other direction ;)

Le 14 juin 2012 à 16:40, Wayne Fay wayne...@gmail.com a écrit :

 ok this is too funny. had to share with the list.

 my reply resulted in a bounce back from a list subscriber @ cme group
 due to a naughty word which i changed so this email will not bounce
 again...

 -- Forwarded message --
 From:  forefrontserversecurity-smapexh...@cmegroup.com
 Date: Thu, Jun 14, 2012 at 9:29 AM
 Subject: Microsoft Forefront Server Security Notification: CME Group
 has blocked an email due to inappropriate content


 Your email did not reach its intended recipient(s) due to being
 blocked for containing inappropriate content.

 The message sent with Subject, Re: jdocbook, was flagged by the
 system automatically for containing the following inappropriate
 content:

 KEYWORD= CMEG Filterlist: fxcking

 To remedy this, please remove the inappropriate content and resend it.

 If you feel that this email was erroneously blocked, please have the
 recipient at The CME Group contact The Customer Support Group and
 provide the information below:

 Subject:  Re: jdocbook
 Location: SMAPEXHUB2



 What is the way to exclude this fxcking lame and useless jdocbook from
 build ?

 No one can help you without more information about your build.
 Probably you need to ask whoever in your organization set up your
 project/build for help to turn off the jdocbook plugin if you are not
 happy with the results of the plugin.

 Wayne

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


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

Re: jdocbook

[Arnaud Héritier]

Re-post

Le 14 juin 2012 à 16:36, Arnaud Héritier aherit...@gmail.com a écrit :

 And you may be polite ...
 The jdocbook plugin isn't developed by the ASF team but I confirm (at
 least before) that it was annoying to use because it defines a custom
 packaging, thus you need to configure it and it has no option to be
 skipped.
 The only solution is to skip its module by defining it in a profile in
 the parent project but I'm not a big fan of such solution.

 Le 14 juin 2012 à 16:29, Wayne Fay wayne...@gmail.com a écrit :

 What is the way to exclude this x lame and useless jdocbook from
 build ?

 No one can help you without more information about your build.
 Probably you need to ask whoever in your organization set up your
 project/build for help to turn off the jdocbook plugin if you are not
 happy with the results of the plugin.

 Wayne

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


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

Re: Maven stats shows huge peak

[Arnaud Héritier]

Many people gave a try to Gradle and came back to Maven :-)

More seriously, no idea. Perhaps a bug ?!


On Sun, Mar 11, 2012 at 11:45 PM, Johan Vogelzang johan.vogelz...@gmail.com
 wrote:

 Hi all,

 On the Maven stats page you can see the download statistics of Maven.
 Can anyone explain the huge peak around mid February 2012?

 http://people.apache.org/~vgritsenko/stats/projects/maven.html

 Thanks in advance,

 Regards,
 Johan.




-- 
-
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aherit...@gmail.com
Twitter/Skype : aheritier

Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)

[Arnaud Héritier]

Not only properties like I explained it here :
http://jira.codehaus.org/browse/MRELEASE-724

Arnaud

On Tue, Jan 3, 2012 at 4:18 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Hi,

 I just found a regression:

 http://jira.codehaus.org/browse/MNG-5224

 I think it is serious enough to recommend users avoid using the above
 combination if you rely on properties in a settings.xml profile to GPG
 sign your releases. (i.e. anyone pushing to Central)

 -Stephen

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

How to build of an eclipse infocenter webapp with Maven

[Arnaud Héritier]

Hi all,

  Is there someone who know if it is possible to automate the generation of
an infocenter webapp with maven ?
  Manual steps as described below are just too tedious and dangerous for
the maintainability :
http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/guide/ua_help_war.htm

Cheers,

Arnaud

Re: How to build of an eclipse infocenter webapp with Maven

[Arnaud Héritier]

ok thx Stephen
Let's see what we can do together (damned eclipse ecosystem )

Arnaud

On Mon, Oct 17, 2011 at 3:45 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I was trying this earlier last week...

 Here's the issues I have hit:

 1. It seems that the servlet bridge does not (obviously) work with Jetty 8
 2. Most of the deps are not in central

 If you can live with Jetty 6, it's quite easy though... you just
 abandon half the maven machinary, expand the infocenter webapp into
 src/main/webapp and then use the maven dependency plugin's
 copy-dependencies to copy the jar with the help content into place.

 I'm currently exploring using felix to replace most of the eclipse
 bundles and get something working on top of that... might have to
 unwind a lot of the eclipse code just to use, what is in essence, a
 couple of .jsp's

 Ho-hum

 -Stephen

 2011/10/17 Arnaud Héritier aherit...@gmail.com:
  Hi all,
 
   Is there someone who know if it is possible to automate the generation
 of
  an infocenter webapp with maven ?
   Manual steps as described below are just too tedious and dangerous for
  the maintainability :
 
 http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/guide/ua_help_war.htm
 
  Cheers,
 
  Arnaud
 

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

Re: Archiva vs. Nexus

[Arnaud Héritier]

This is a bug, it is sure.
Probably due to spaces in your path (programs don't love them in general).

Arnaud

On Mon, Jul 25, 2011 at 9:06 PM, Eric Kolotyluk eric.koloty...@gmail.comwrote:

 So I downloaded Nexus 1.9.2, watched the video, read the user manual on
 starting Nexus, entered

 C:\Program Files (Open)\Sonatype\nexus-oss-**
 webapp-1.9.2-bundle\nexus-oss-**webapp-1.9.2bin\jsw\windows-**x86-64\nexus
 start

 and got back

 FATAL  | wrapper  | Unable to open configuration file. C:\Program Files
 (Open)\Sonatype\nexus-oss-**webapp-1.9.2-bundle\nexus-oss-**
 webapp-1.9.2\start
 Press any key to continue . . .

 First impressions are very important - this one was pretty bad. How much
 time am I supposed to waste now trying to figure out how to actually start
 Nexus?

 Maybe Archiva actually works according to the documentation...

 Cheers, Eric


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

Re: Maven 3.0 Artefact/Dependency version discussion request

[Arnaud Héritier]

For now it is just impossible to use properties in GAV for various technical
and also philosophical reasons.
You may not be agree with the philosophy behind this choice but it is sure
that for now it is more secure in Maven to avoid this usage as it creates
many issues.

About the philosophy even if I can be agree that having in the project
version the one of the SCM may be useful it is with really few SCMs.
For exemple with CVS it is impossible as each file has a different version.
And For a DSCM like Git  co your version will be a hash and thus you won't
be able to sort them.

Arnaud


On Thu, May 26, 2011 at 5:24 PM, Manfred Moser manf...@mosabuam.com wrote:

 Why dont you use the buildnumber plugin? That might be able to do it for
 you..

 http://mojo.codehaus.org/buildnumber-maven-plugin/

  For what it's worth, I agree with you both (version strings should be
  controlled via the -ahem- version control system), but I am willing to
  allow Maven (more to the point, the maven-release-plugin) to take care
  of the version strings for me.
 
  However, if you don't want to, you can still do it yourself with Maven
  3 ... but you *can't* do it with properties at the command-line; you
  *will* need to update the poms.  Just do it outside of maven before
  you perform the final build - should not be hard.  If doing that is
  too much to ask ... then, yeah, Maven may not be the right framework
  for you.  But consider that you will need to do *something* similar --
  either you write your own around maven, or you write your own around
  some other system.
 
  On Tue, May 17, 2011 at 11:12 AM, Russ Tremain ru...@releasetools.org
  wrote:
  +1.
 
  this is the major reason I won't be upgrading to maven 3.
 
  I do think that versions should be fixed at maven deploy time - i.e.,
  when artifacts are deployed to the repository.
 
  -Russ
 
  At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
 Hi,
 
 I am also getting grief from maven for using variables in my version
  fields.
 For me, this is unavoidable. Let me explain...
 
 In my parent pom I have:
 
 ${productVersion}
 
 And in my properties I have:
 
 0-SNAPSHOT
 13.0.${productRevision}
 
 On a developer's machine, this produces a version number of
 
  13.0.0-SNAPSHOT
 
 Which is exactly what I want.
 
 However, in my hudson CI server, as part of the maven command I have:
 
   -DivpnRevision=$SVN_REVISION-nt3
 
 The $SVN_REVISION variable is provided by hudson. It contains the svn
 revision number that has just been built, and the '-nt3' bit is the
 environment it was built for.
 
 I do this because subversion is my revision control system and it,
  rightly,
 controls the revision number (the clue as to it's purpose is in it's
  name).
 This is not a job I want to hand off to maven, for many reasons.
 
 If I use maven 3 for my builds, then my IDEs (both eclipse and intellij)
  are
 totally messed up -- maven 3 messes up the classpath because it can't
  deal
 with the variables. So, I'm stuck on maven 2.
 
 Now, I don't see this as providing the slightest obstacle to my ability
  to
 get repeatable builds. Rather, it's the opposite -- if I want to repeat
  a
 build all I have to know is the subversion revision number of the build
  I
 want and I can check out that revision and rebuild to recreate an exact
  copy
 of the original.
 
 Just because maven thinks that an alternative approach is 'convention'
 doesn't mean that I shouldn't be able to achieve this. CoC is supposed
  to
 allow one the choice of following convention, but provide the ability to
  use
 configuration where the convention does not fit one's requirements.
 
 So, what to do?
 
 Bryan
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Heap overflow in deploy:deploy

[Arnaud Héritier]

I'm using the webdav wagon to bypass this problem. But yes we should try to 
propose something better. 
Patches are welcome ;) 

Le 7 mai 2011 à 10:32, Stephen Connolly stephen.alan.conno...@gmail.com a 
écrit :

 select a different wagon. it's documented on one of the mini howtos in the
 wagon sub-site (I'm on a phone so have a look yourself)
 
 - Stephen
 
 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 7 May 2011 04:37, Phillip Hellewell ssh...@gmail.com wrote:
 With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; any
 ETA on when it will be fixed? Could Maven use an alternative to
 httpclient?
 
 I have a component with five zip classifiers ranging in size from 80MB to
 800MB. I had to adjust my max heap size to 2.5GB before it would deploy
 without a heap overflow.
 
 Phillip
 
 On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran dant...@gmail.com wrote:
 
 It is a known problem where maven (wagon) uses jvm's httpclient to do
 the upload.
 
 -D
 
 On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler
 rwhee...@artifact-software.com wrote:
 On 13/10/2010 7:29 PM, Phillip Hellewell wrote:
 
 I'm using Maven 2.2.1 and getting a heap overflow when trying to
 deploy an artifact about 50MB in size. I'm deploying to an Nexus
 server (HTTP).
 
 I added @set MAVEN_OPTS=-Xms128m -Xmx512m to my mvn.bat and now it
 is
 working.
 
 But my question is, why should uploading a file require so much
 memory? It's not like it tries to read the whole file into memory, or
 does it? If so, that seems kinda dumb.
 
 We have seen this one as well.
 Probably more of a comment on the guys that set the default way too
 low.
 Who would buy a computer with 512Mb of memory and no paging space?
 I suspect that the guys that write the code that we use, do not have
 real
 world examples where you need to move 50 Mb around.
 We had the problem with CXF (Apache web services) where we could not
 deploy
 the basic library jar to Nexus without setting the Eclipse parameters
 for
 a
 JVM fork to something more in keeping with the natural capacity of our
 actual workstations (2Gb physical memory with 4Gb of cache) .
 I just set the JVM options to -Xmx1024m to start, on any Java program,
 since the JVM is already running in a virtual machine (Linux or Vista)
 anyway that can easily deal with a 1Gb task if it does not use the
 memory.
 
 Ron
 
 Phillip
 
 P.S. Here's the trace:
 
 java.lang.OutOfMemoryError: Java heap space
 at java.util.Arrays.copyOf(Unknown Source)
 at java.io.ByteArrayOutputStream.write(Unknown Source)
 at sun.net.www.http.PosterOutputStream.write(Unknown Source)
 at
 org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492)
 at
 org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457)
 at
 
 org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411)
 at
 org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392)
 at
 
 org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365)
 at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:163)
 at
 
 
 org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317)
 at
 
 
 org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227)
 at
 
 
 org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
 at
 org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190)
 at
 
 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 at
 
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at
 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
 Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at

Re: central repo?

[Arnaud Héritier]

Hi,

You can continue to browse the repository from here :
http://search.maven.org/#browse%7C47

Is it what you searched ?

Arnaud

On Thu, May 5, 2011 at 12:09 AM, Nord, James jn...@nds.com wrote:

 Hi all,

 What happened recently to the central repos and their mirrors (uk).

 When I try to browse I now get redirected to search.maven.org which is not
 a good thing when trying to work out why something isn't working as expected
 when proxied via a repo manager.

 Also I guess these searches run of the index - but as far as I have always
 been led to believe the indexes are correct on Sunday only, and don't help
 when the metadata is incorrect.

 How can I get back to the old bog standard directory listings produced by
 the web server?

 /james



 


 **
 This message is confidential and intended only for the addressee. If you
 have received this message in error, please immediately notify the
 postmas...@nds.com and delete it from your system as well as any copies.
 The content of e-mails as well as traffic data may be monitored by NDS for
 employment and security purposes. To protect the environment please do not
 print this e-mail unless necessary.

 NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
 4EX, United Kingdom. A company registered in England and Wales. Registered
 no. 3080780. VAT no. GB 603 8808 40-00

 **

Re: Welcome Evgeny Mandrikov to Apache Maven Dev Team

[Arnaud Héritier]

Welcome Evgeny !!!

Arnaud

On Sun, Jan 30, 2011 at 9:29 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 welcome

 - Stephen

 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 30 Jan 2011 19:52, Olivier Lamy ol...@apache.org wrote:
  Hello,
 
  We just voted him as a committer.
 
  So Welcome Evgeny !
 
  Thanks,
  --
  Apache Maven Team
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

Re: Supporting branches in Maven

[Arnaud Héritier]

We are also only using a change in the version.
We often use the release:branch mojo to create the branch but sometimes we
do it manually with versions:set to update all versions.

Arnaud

On Sun, Jan 30, 2011 at 10:42 PM, Evgeny Goldin evge...@gmail.com wrote:


 Thanks, I see release:branch is the common way so it means we're doing
 basically the same.

 -
 Best regards,

 Evgeny

 http://evgeny-goldin.com/ evgeny-goldin.com

 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Supporting-branches-in-Maven-tp3363522p3363783.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Welcome Wayne Fay to the Maven PMC

[Arnaud Héritier]

Welcome Wayne!

Arnaud

On Sat, Jan 15, 2011 at 9:15 PM, Wayne Fay wayne...@gmail.com wrote:

 Thanks to all. Looking forward to participating in the PMC and yes,
 helping out with documentation etc. ;-)

 Wayne

 On Sat, Jan 15, 2011 at 11:53 AM, Paul Benedict pbened...@apache.org
 wrote:
  Congrats Wayne!
 
  On Sat, Jan 15, 2011 at 7:14 AM, Mark Struberg strub...@yahoo.de
 wrote:
 
  Congratulations Wayne!
 
  Keep up the good work ;)
 
  LieGrue,
  strub
 
  --- On Sat, 1/15/11, Olivier Lamy ol...@apache.org wrote:
 
   From: Olivier Lamy ol...@apache.org
   Subject: Re: Welcome Wayne Fay to the Maven PMC
   To: Maven Users List users@maven.apache.org
   Date: Saturday, January 15, 2011, 11:38 AM
   Welcome aboard !
  
   --
   Olivier
Le 15 janv. 2011 02:08, Brian Fox bri...@infinity.nu
   a écrit :
I'm sure you all know Wayne since he's been around
   forever answering
user list questions. We recently voted him in both as
   a committer and
a PMC member, so please join me in congratulating him.
   We're secretly
hoping that he'll use his commit rights to start
   improving the
documentation since he's so good at answering
   questions ;-)
   
Welcome Wayne!
   
--Brian Fox
Apache Maven PMC Chair
   
   
   -
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
  
 
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

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

Re: [PLEASE TEST] Apache Maven 3.0.2-RC1

[Arnaud Héritier]

No problem with my tests.

Arnaud

On Wed, Jan 5, 2011 at 10:20 PM, Benjamin Bentmann 
benjamin.bentm...@udo.edu wrote:

 Hi,

 we're aiming at a bugfix release of Maven 3 in the next week and following
 tradition we invite interested users in taking the RC for a test drive in
 order to detect and fix potential regressions since version 3.0.1 before the
 actual release of 3.0.2.

 For the duration of the RC testing, sources and binaries are staged at:

 https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/

 As usual, the changes since the previous release are listed in JIRA:

 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16952

 Thanks,


 -The Maven Team

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

Re: faster release:perform

[Arnaud Héritier]

I think no because what we want it is to be sure that what we publish is coming 
from what you have in the branch (no more, no less).
Using a switch in SVN could keep various unwanted local files.


Arnaud Héritier
aherit...@apache.org

On Dec 1, 2010, at 8:50 PM, Phillip Hellewell wrote:

 Would it make sense when using SVN to have release:perform do an svn
 switch (to the tag created by release:prepare) rather than check out
 the tag?
 
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Assembly Plugin 2.2 File Filtering

[Arnaud Héritier]

Couldn't it be the same problem as in resources plugin (there are using same 
libraries to do that) which stops if you have a @ character alone :
http://jira.codehaus.org/browse/MRESOURCES-104

On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:

 Hello,
 
 I have an assembly with files which should be copied and filtered:
fileSet
directorysrc/main/config/directory
outputDirectoryconfig/outputDirectory
filteredtrue/filtered
excludes
excludequartz.properties/exclude
/excludes
/fileSet
 
 Files are copied but not filtered (${...} are still here)
 
 The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
 It it a known bug or a problem in my configuration?
 
 Gérald
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: [ANN] Sonar 2.3 released

[Arnaud Héritier]

On Oct 28, 2010, at 5:04 PM, Olivier Gaudin wrote:

 
 The Sonar Team is pleased to announce the release of Sonar 2.2. This version
 ships with several new features :

^^
2.3 release :-)

 it is now possible to activate several times the Checkstyle rule Illegal
 Regular Expression with different parameters and priority or the PMD rule
 XPath with different XPath expressions. This feature was a requirement to
 start working on a architecture rule engine (don't access the **.db.**
 packages from the **.client.** packages, don't use java.util.Vector, don't
 access **.web.** packages from **.dao.** packages, ...)
 backup and restore quality profiles
 ability to activate at once all the rules returned by a search
 new rules API
 ability to add static resources to plugins
 support for quality models ( http://en.wikipedia.org/wiki/ISO/IEC_9126 ISO
 9126  for example) through a new meta-model and a new API
 new Findbugs rules
 
 To find out more on those features, you can explore them in screenshots [1]. 
 
 
 On top of those features, this release contains more than 70 improvements
 and bug-fixes [2]. To enjoy the new version, you can download it straight
 away [3]. 
 
 
 
 - The Sonar Team
 
 
 
 Links
 
 [1] Sonar 2.2 in screenshots :
^^
2.2 :-)

 http://www.sonarsource.org/sonar-2-3-in-screenshots/ 
 
 [2] Release notes : http://www.sonarsource.org/downloads/#2.3 
 
 [3] Download : http://sonar.codehaus.org/downloads 
 
 

Copy/Paste is dangerous :-)

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

Re: avoiding parent pom version number duplication

[Arnaud Héritier]

 
 On Tue, Oct 26, 2010 at 21:00, Arnaud bourree arnaud.bour...@gmail.comwrote:
 
 2010/10/26 Babak Farhang farh...@gmail.com:
 Hi everyone,
 
 I have a nested, multi-module project in which every module's pom
 inherits from a root pom. I'd like to find a way to avoid duplicating
 the parent pom version number in every submodule. The aim is to keep
 the version number for these submodules in sync with one another, from
 one release to the next. Here's a strategy I've tried using
 profiles.xml that doesn't quite work.

It is impossible for now.
It is forbidden/not recommended to use properties in GAV 
(GroupId/ArtifactId/Version)
The minimum you can do now is to set the version in the parent pom and in each 
child in the parent section
For dependencies between modules you can use ${project.version}
In a near future (Maven 3.1 in theory) you won't have anymore to set the 
version in the parent element if your module defines the relative path to its 
parent or if it follows the convention to have it in its parent directory
To ensure to keep the same version everywhere you use the release plugin which 
will update them for you.
The versions plugin could help you too.

Cheers


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

Re: [Repetitive]: Maven does not live up to its promises

[Arnaud Héritier]

Thus what you are waiting for are :
- Maven polyglot which will allow to write the pom in various formats 
(simplified xml, groovy, whatever) : http://polyglot.sonatype.org/
- Mixins which will allow to inject part of poms and thus ease how we can reuse 
them : http://www.sonatype.com/people/2008/11/maven-project-model/

It's cool, it's on its way ...


On Oct 25, 2010, at 2:26 PM, Benson Margulies wrote:

 I've tried to come up with a 'moderate' reprocessing of this dispute
 before, and for some reason I'm going to try again.
 
 The fundamental idea of Maven is that a build can be described with a
 small number of facts. This is possible if the right conventions are
 analyzed, designed, and implemented into the build system.
 
 If a build can be described as a small number of facts, XML is an
 unobjectional representation for those facts. If a POM fits on a page,
 verbosity of XML is just not an issue.
 
 Further, historically, Maven came behind Ant. If there's one thing
 worse that a few facts in XML, it's many, many, facts, and a small
 procedural language, in XML.
 
 For many purposes, and on many occasions, Maven succeeds in the
 'fundamental idea' above.
 
 There is, however, a however. In some cases, POMs grow hair. Posters
 to this list sometimes seem to believe that every bit of that hair is
 illegitimate -- that it either reflects ignorance of 'the maven way,'
 or it reflects insufficient willingness to create new maven plugins.
 
 I think that this is an oversimplification. Start setting up a
 release, or the maven-eclipse-plugin, or a non-trivial web
 application, and you will find that your POM gets bigger and bigger
 and harder and harder to manage and understand. Cases that I'm
 familiar with include trying to cope with the interactions of
 reporting/ plugins and ordinary plugins. In my opinion, XML does add
 a bit of salt to these wounds.
 
 However, over-focussing on the supposed intrinsic evil of XML, either
 on the complaint or the defense side, is a distraction. In my opinion,
 the real question is, What would it take to keep 'maven way' POMs
 from growing and ramifying out of maintainability?
 
 Generalize the 'main versus site' lifecycle to allow multiple
 lifecycle definitions, defined once, and reused in many poms?
 
 Some way to package up a gang of plugin specs for reuse?
 
 Support for 'include'?
 
 Tighter XML for common cases? My favorite in this area is goals. Oh
 how I wish for:
 
 execution id='id' phase='phase' goal='goal'
 ...
 /execution
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Using Maven 1 repositories with Maven 3

[Arnaud Héritier]

As some others said, the real solution for you is to use a repository manager.
It will bring many advantages to manage binaries coming from outside and it 
will give you a transparent access to maven 1 and 2 repositories


On Oct 24, 2010, at 11:25 PM, Zak Mc Kracken wrote:

 Hi Anders,
 
 thank you for your reply. Do you mean I can do the conversion as a repository 
 user? I need to access 3rd party repositories, I cannot change them. By the 
 way, this also means that The 5 years is up is not a message for me :-) 
 Maybe I could stop using java.net, but I have other dependencies in the same 
 situation that are not so easy to be moved out or upgraded (I should trace 
 all of them, check if there is a more recent version in M2 repos, 
 transitively check all the dependency tree, it was becoming a nightmare when 
 I decided that for the moment I won't migrate to M3, unless I can arrange M1 
 support in that version too).
 
 Marco.
 
 
 
 On 24/10/2010 20:25, Anders Hammar wrote:
 And by the way, you should really try to stop using the java.net repo. I'll
 quote Stephen Connolly, friends don't let friends use the java.net maven
 repositories. :-)
 
 /Anders
 
 On Sun, Oct 24, 2010 at 21:22, Anders Hammarand...@hammar.net  wrote:
 
 You need to get a repo manager like Nexus set up, which is able to convert
 from Maven 1 to Maven 2 repo format.
 
 /Anders
 
 On Sun, Oct 24, 2010 at 20:35, Zak Mc Krackenzakmc...@yahoo.it  wrote:
 
 Hi all,
 
 sorry if the question has already been asked, I cannot find anything on
 the mailing list archive.
 
 Subject should be clear enough, I have a project with many dependencies on
 Maven 1 3rd-party repositories that I cannot migrate (e.g.: java.net).
 Isn't there a way to continue to use them? Like a plug-in to be declared in
 my POM? If yes, please, could someone provide a usage example?
 
 I really need that, otherwise I will need to stay with Maven 2, until more
 people migrate to the 3.
 
 Thanks in advance for any help.
 
 Marco.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: [Maven Shell] - How to upgrade from maven 3.0-alpha-6 to maven 3.0

[Arnaud Héritier]

0.11-SNAPSHOT was updated to include it :

http://repository.sonatype.org/content/repositories/snapshots/org/sonatype/maven/shell/mvnsh-assembly/0.11-SNAPSHOT/

Arnaud

On Oct 23, 2010, at 11:10 PM, Stan wrote:

 Hello,
 
 I tried to upgrade from *maven 3.0-alpha-6* to *maven 3.0* within *maven
 shell*.
 I copied all the jar files from *apache-maven-3.0\lib* to *mvnsh-0.10\lib*
 And I removed all **alpha*.jar*
 
 When I execute a maven command in the maven shell, I get the following
 exception:
 
 *java.lang.IllegalAccessError: class
 org.sonatype.maven.shell.maven.internal.ConsoleMavenTransferListener cannot
 access its superclass org.apache.maven.cli.AbstractMavenTransferListener*
 
 I checked that these classes are in the jar files.
 
 Did anyone meet the same problem and solve it?
 
 Thanks.
 Stan.


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

Re: maven is a swamp

[Arnaud Héritier]

 
 
 But the payoff is you don't need code completion! You just put in a )/}/] or 
 so, and your code is completed! Any yes, any competent text editor can check 
 for braces mismatches etc.
 
 I recognize the concern, I just don't see it as valid. I've been programming 
 in Python for twenty years now. I won't say it's always the case, but in a 
 large number of cases, the terseness you gain in your code more than offsets 
 things like code completion, static analysis, etc.
 
 And yes, I specifically intend this to apply to XML. I can't see how moving 
 to a YAML model would be anything but a win for maven.
 
 
 http://github.com/sonatype/polyglot-maven/blob/master/pmaven-yaml/src/test/resources/pom.config.yml
 
 Already works with Maven's current core. Along with Scala, Clojure, and Ruby.
 
 A fact to note though is that I've asked over 2k people over the last two 
 years at talks and in any average crowd the people who care to have a 
 different format or DSL is around 3%.
 

Me too. 
Xml verbosity and usage is sincerely not the major complain I received when 
doing various talks. 
And Maven 3.x will help those who are allergic to it.

Arnaud


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

Re: Error 400 when deploying releases to Nexus

[Arnaud Héritier]

Did you have a look at nexus logs to see what is wrong on its side ??
This is perhaps a problem of repository target settings

On Oct 6, 2010, at 11:23 AM, NickDeGraeve wrote:

 
 I'm trying to get a legacy project to build with Maven. I'm not allowed to do
 a complete makeover because of time constraints so for the time being I just
 call the necessary Ant target.
 
 The Ant build produces an EAR, a client JAR (with the interfaces for the
 Swing client) and its Javadoc and sources JARs. 
 
 The EAR is deployed by default. For the other JARs I have in the POM 3
 deploy:deploy-file configurations. We deploy our artifacts to Nexus.
 
 If the artifacts are deployed as SNAPSHOT everything goes according to plan
 but when deploying as release the deploy fails after the upload of the
 sources JAR. The Nexus returns a HTTP 400 error: 
 
 [INFO] Error installing artifact's metadata: Error while deploying metadata:
 Failed to transfer file:
 http://ourhostname:8081/nexus/content/repositories/releases/com/jnj/gtsc/agent/business/agentClient/2.3.0-RC1/agentClient-2.3.0-RC1.pom.
 Return code is: 400
 
 Any idea how to fix this?
 
 Extract of build log:
 ---
 [INFO] [deploy:deploy {execution: default-deploy}]
 Uploading:
 http://ourhostname:8081/nexus/content/repositories/releases/com/jnj/gtsc/agent/business/agent/2.3.0-RC1/agent-2.3.0-RC1.ear
 18180K uploaded  (agent-2.3.0-RC1.ear)
 [INFO] Retrieving previous metadata from nexus
 [INFO] repository metadata for: 'artifact com.jnj.gtsc.agent.business:agent'
 could not be found on repository: nexus, so will be created
 [INFO] Uploading repository metadata for: 'artifact
 com.jnj.gtsc.agent.business:agent'
 [INFO] Uploading project information for agent 2.3.0-RC1
 [INFO] [deploy:deploy-file {execution: deploy-client-jar}]
 Uploading:
 http://ourhostname:8081/nexus/content/repositories/releases/com/jnj/gtsc/agent/business/agentClient/2.3.0-RC1/agentClient-2.3.0-RC1.jar
 718K uploaded  (agentClient-2.3.0-RC1.jar)
 [INFO] Retrieving previous metadata from remote-repository
 [INFO] repository metadata for: 'artifact
 com.jnj.gtsc.agent.business:agentClient' could not be found on repository:
 remote-repository, so will be created
 [INFO] Uploading repository metadata for: 'artifact
 com.jnj.gtsc.agent.business:agentClient'
 [INFO] Uploading project information for agentClient 2.3.0-RC1
 [INFO] [deploy:deploy-file {execution: deploy-client-sources-jar}]
 Uploading:
 http://ourhostname:8081/nexus/content/repositories/releases/com/jnj/gtsc/agent/business/agentClient/2.3.0-RC1/agentClient-2.3.0-RC1-sources.jar
 696K uploaded  (agentClient-2.3.0-RC1-sources.jar)
 [INFO] Retrieving previous metadata from remote-repository
 [INFO] Uploading repository metadata for: 'artifact
 com.jnj.gtsc.agent.business:agentClient'
 [INFO] Uploading project information for agentClient 2.3.0-RC1
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Error installing artifact's metadata: Error while deploying metadata:
 Failed to transfer file:
 http://ourhostname:8081/nexus/content/repositories/releases/com/jnj/gtsc/agent/business/agentClient/2.3.0-RC1/agentClient-2.3.0-RC1.pom.
 Return code is: 400
 
 Extract of POM:
 
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-deploy-plugin/artifactId
   version2.4/version
   executions
   execution
   iddeploy-client-jar/id
   phasedeploy/phase
   goals
   goaldeploy-file/goal
   /goals
   configuration
   
 filedist/${project.artifactId}Client.jar/file
   
 urlhttp://ourhostname:8081/nexus/content/repositories/${deployAs}/url
   groupId${project.groupId}/groupId
   
 artifactId${project.artifactId}Client/artifactId
   version${project.version}/version
   packagingjar/packaging
   uniqueVersionfalse/uniqueVersion
   /configuration
   /execution
   execution
   iddeploy-client-sources-jar/id
   phasedeploy/phase
   goals
   goaldeploy-file/goal
   /goals
   configuration
   
 filedist/${project.artifactId}Client-sources.jar/file
   
 urlhttp://ourhostname:8081/nexus/content/repositories/${deployAs}/url
   groupId${project.groupId}/groupId
   
 artifactId${project.artifactId}Client/artifactId
   version${project.version}/version

Re: Can't specify distributionManagement in settings.xml

[Arnaud Héritier]

Wrong :-)
Let me try to explain ...
Your approach to allow to override this parameter using a property is good.
I'm doing it to validate a new version of my repository manager and so on.
But how you are doing it is wrong.
You should avoid to use a profile with activeByDefault activation. Why ? 
Because unlike its name could make you think, by default isn't always activated 
but only if no other profile is used. Thus as soon as you'll use another 
profile (for a release, a ci server, ...) this one won't be here, your property 
won't be set, and your deployment will fail.
The recommended solution is to define a default value in the property of you 
pom outside of any profile.
This one will be the real default. You'll have it in any case except if you 
override the value :
- with a property set in a profile activated in the project
- with a property set in a profile activated in your user settings
- with a property set in the command line (-D)
You can find a sample of that in my corporate pom : 
http://svn.exoplatform.org/projects/parent/trunk/pom.xml
You'll notice I'm using a lot of properties to allow users/projects to easily 
override settings they want to change without having to wrige a large block of 
xml settings.

Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com

Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier 
Blog : http://aheritier.net

On Oct 4, 2010, at 9:04 PM, Phillip Hellewell wrote:

 On Mon, Oct 4, 2010 at 12:43 PM, Phillip Hellewell ssh...@gmail.com wrote:
 On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar and...@hammar.net wrote:
 Are you seeing the pattern yet? Don't fight Maven!
 
 Hehe, yeah I am.  But using a parent pom for this setting is still not
 making complete sense to me, so I've got to play with it some more and
 hopefully it will.
 
 Ok, I figured out what I feel is a valid and good solution.  Not sure
 why I didn't think of this before, but in the default profile in my
 settings.xml I can simply define a property called repos.url, right
 where I define my repository.  Then I can use that same property in my
 distributionManagement section in any of my poms that I want to.
 
 So something like this goes in my settings.xml:
  profiles
profile
  iddefault/id
  activation
activeByDefaulttrue/activeByDefault
  /activation
  properties
repos.urlfile:///c:/test123/repos.url
  /properties
  repositories
repository
  idtest123/id
  nametest/name
  url${repos.url}/url
/repository
  /repositories
/profile
  /profiles
 
 And something like this goes in my pom files:
  distributionManagement
repository
  idmyrepos/id
  url${repos.url}/url
/repository
  /distributionManagement
 
 The other advantage here is that I can pass in repos.url on the
 command-line with -D if I want to deploy to another repository.
 
 I hope you won't tell me this is the wrong way, because it seems
 like a perfectly valid approach to me.
 
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Can't specify distributionManagement in settings.xml

[Arnaud Héritier]

yes, which is a best practice :-)
It can work like that too :
- In your pom you put the distributionMgt with the property
- in your settings you create a profile with this property but instead of using 
an activation activateByDefault  you define it in activatedProfiles list.
It will work but I think Maven 3 will write a warning because your build is 
dependent of your environment (which is wrong).

In Maven 3 we didn't touch to settings nor pom but we have always in mind to 
propose more interesting features in a near future. Like mixins which will 
allow to integrate several parts of pom or settings

Arnaud



On Oct 4, 2010, at 9:39 PM, Phillip Hellewell wrote:

 On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com wrote:
 2010/10/4 Arnaud Héritier aherit...@gmail.com:
 Wrong :-)
 Let me try to explain ...
 Your approach to allow to override this parameter using a property is good.
 I'm doing it to validate a new version of my repository manager and so on.
 But how you are doing it is wrong.
 
 I didn't know I could define properties outside of a profile section.
 Let me give it a try...
 
 Crap, you can't do that in a settings.xml.  To do it outside of a
 profile section it has to be in a pom, so that leads me back to having
 to use a parent or corporate pom :(
 
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Can't specify distributionManagement in settings.xml

[Arnaud Héritier]

It is interesting to have it variable in several cases :
- You want to validate your builds on several environments. I'm just moving my 
infrastructure and I'm very happy to have that because I'm able to run a 
secondary build environment (svn/hudson/nexus) without touching our production 
used by developers
- You want to deploy the project in another repository because you are forking 
it (for an OSS project) and you can redefine this property instead of using the 
-DaltDeploymentRepository of the deploy plugin which has severals bugs.


On Oct 4, 2010, at 9:43 PM, Thiessen, Todd (Todd) wrote:

 Hehe. It always gets back to that.
 
 Not sure why your hung up over it ;-).
 
 What Arnaud is saying does make more sense to me. There is at least a fixed 
 place in some POM in source control which defines the default location of 
 where to deploy to. At least this is tracable.
 
 I am not really all that found of making it a variable though. That just 
 sounds like extra work for very little gain.
 
 -Original Message-
 From: Phillip Hellewell [mailto:ssh...@gmail.com]
 Sent: Monday, October 04, 2010 3:40 PM
 To: Maven Users List
 Subject: Re: Can't specify distributionManagement in settings.xml
 
 On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com
 wrote:
 2010/10/4 Arnaud Héritier aherit...@gmail.com:
 Wrong :-)
 Let me try to explain ...
 Your approach to allow to override this parameter using a property is
 good.
 I'm doing it to validate a new version of my repository manager and so
 on.
 But how you are doing it is wrong.
 
 I didn't know I could define properties outside of a profile section.
 Let me give it a try...
 
 Crap, you can't do that in a settings.xml.  To do it outside of a
 profile section it has to be in a pom, so that leads me back to having
 to use a parent or corporate pom :(
 
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Can't specify distributionManagement in settings.xml

[Arnaud Héritier]

mvn deploy -DaltDeploymentRpository=...
But some times ago there was a bug which disallow to use it without a 
distribMgt part in the pom :(


Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com

Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier 
Blog : http://aheritier.net

On Oct 4, 2010, at 9:48 PM, Phillip Hellewell wrote:

 On Mon, Oct 4, 2010 at 1:43 PM, Thiessen, Todd (Todd)
 tthies...@avaya.com wrote:
 Hehe. It always gets back to that.
 
 Not sure why your hung up over it ;-).
 
 Well, I'm going to do some more tests now to see if I can get this
 working with a parent pom.  If I run into an error that I can't figure
 out you'll probably hear from me :)
 
 But I do have one question first.  Is there any possible way to do a
 deploy without any distributionManagement section in your pom, and
 to just pass the URL on the command-line?
 
 Phillip
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: [PLEASE TEST] Apache Maven 3.0-RC1

[Arnaud Héritier]

Benjamin I just found this problem : http://jira.codehaus.org/browse/MNG-4813
It is failing for all alpha/beta I tested thus it isn't a problem in RC itself.
It occurs with an old version of the jdocbook plugin we are always using in 
GateIn and few others projects.

Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com

Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier 
Blog : http://aheritier.net

On Sep 15, 2010, at 10:34 PM, Benjamin Bentmann wrote:

 Hi,
 
 in preparation for the release of Apache Maven 3.0, the Maven team is seeking 
 your help to discover regressions since Maven 2.x. Everybody interested in 
 taking a preview of the upcoming release for a test drive can get source and 
 binary bundles from this URL:
 
 https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/
 
 Before reporting any issues found during testing, please be sure to have a 
 close look at the compatibility notes for Maven 3.x:
 
 https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
 
 If you encounter unexpected build issues, please fill a report in JIRA that 
 provides sufficient information to reproduce and analyze the issue:
 
 http://jira.codehaus.org/browse/MNG
 
 The fixes contained in this release candidate since the 3.0-beta-3 release 
 can also be seen in JIRA:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-iversion=13142styleName=TextprojectId=10500Create=Create
 
 Thanks,
 
 
 -The 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Release Plugin Failing on Commit

[Arnaud Héritier]

What is your svn version ?

Aren't you facing to this bug : http://jira.codehaus.org/browse/MRELEASE-375
Using the option remoteTaggingtrue/remoteTagging should slve it.

(It is weird but I was sure we had a note somewhere about this annoying issue 
we had a long time ago, but I didn't find it)

cheers

Arnaud


On Sep 4, 2010, at 12:16 AM, Neil Chaudhuri wrote:

 I am using version 2.0 of the release plugin to tag a new version of my 
 multi-module application, but at the end when it goes to commit to SVN SCM, I 
 get the following:
 
 [INFO] Unable to tag SCM
 Provider message:
 The svn tag command failed.
 Command output:
 svn: Path 'svn://SVN IP/data/svn/client/myapp/tags/myapp-1.1.rc4' does not 
 exist in revision 5218
 
 To be fair, that's true--myapp-1.1.rc4 isn't a folder in the SVN tags folder. 
 But I figured the plugin would create it and put my source code underneath.
 
 Another weird thing is that the poms are updated to 1.1.rc4 and committed to 
 the trunk and checked out to my local machine. The expected behavior is for 
 1.1.rc5-SNAPSHOT to be in the trunk and on my local while the 1.1.rc4 is in 
 the tagged version.
 
 Here is the plugin configuration:
 
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0/version
configuration

 updateWorkingCopyVersionsfalse/updateWorkingCopyVersions
preparationGoalsclean install/preparationGoals
goalsclean install/goals
arguments-Dmaven.test.skip/arguments
tagBasesvn://SVN IP/data/svn/client/myapp/tags 
 /tagBase
autoVersionSubmodulestrue/autoVersionSubmodules
/configuration
/plugin
 
 Any advice on how to get the expected behavior is appreciated.
 
 Thanks.


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

Re: exclude META-INF/maven dirs

[Arnaud Héritier]

The question could be why ??
The solution is :

project
  ...
  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
  archive
addMavenDescriptorfalse/addMavenDescriptor
  /archive
/configuration
...
  /plugin
/plugins
  /build
  ...
/project

See : 
http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#archive
http://maven.apache.org/shared/maven-archiver/index.html


cheers

Arnaud

On Sep 2, 2010, at 11:48 PM, woods5242-photogra...@yahoo.com wrote:

 Hi,
 New to maven.
 
 I have a basic project setup which is packaging a jar using the 
 maven-compiler-plugin.
 
 My resulting JAR is getting a /META-INF/maven directory with a bunch of stuff 
 in 
 it. How do I remove this or ensure that mvn package does not generate it?
 
 thanks
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: Correcting a groupID

[Arnaud Héritier]

I think it could help you : 
http://maven.apache.org/guides/mini/guide-relocation.html

Cheers

Arnaud

On Aug 23, 2010, at 2:20 PM, sebb wrote:

 Apache Commons NET currently uses the groupId commons-net. However, it
 should really use the groupId org.apache.commons.
 
 Is it possible to set up the Maven repos so that this change is
 transparent to users?
 
 Or does changing a groupId necessarily involve change for end-users?
 
 ==
 
 AIUI, a redirect pom can be created, which will cause references to
 commons-net to be seen as org.apache.commons, at least when
 downloading.
 
 For example:
 NET 2.0 groupId = commons-net
 Create NET 2.x with groupId org.apache.commons
 
 Then a project that references commons-net:commons-net:2.x will
 download org.apache.commons:commons-net:2.x
 (though there will be a warning logged)
 
 [For example, see JDom 1.1, which changed groupId jdom = org.jdom]
 
 However, what happens if a project has (transitive) dependencies on
 both versions of Net?
 Does Maven know how to resolve these correctly so that only the 2.x
 release of Net is used?
 
 Or is it necessary to change the Net package name in order to avoid conflict?
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: force maven to redownload/refresh released dependencies

[Arnaud Héritier]

I see only one case where it could be useful, it is when we use staging 
repositories and have to update our released binaries.
It is a shame to have to manually remove binaries previously downloaded (and it 
is error prone).
I agree that never updating released binaries is a maven fundamental and we'll 
never change that.
But we'll have to improve tooling around staging to easily allow to cleanup the 
local repository (or a part of it) for QA teams and others involved in staging 
process.
Cheers,

Arnaud


On Jul 30, 2010, at 6:39 PM, Jason van Zyl wrote:

 Maven won't do that, and we would never make that possible. If you require 
 this you have something seriously wrong with your project infrastructure. 
 Seriously bad project infrastructure smell.
 
 On Jul 30, 2010, at 12:01 PM, Shan Syed wrote:
 
 is there a way to force a project to refresh certain dependencies every
 build? i.e. replicate SNAPSHOT behaviour with released artifacts
 
 S
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 
 
 


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

Re: Maven Meetup Locations

[Arnaud Héritier]

Go go go Frenchies
Vote for Paris  :-)

Arnaud

On Jun 21, 2010, at 9:57 PM, Jason van Zyl wrote:

 Link pasted incorrectly:
 
 http://www.sonatype.com/people/2010/06/sonatypes-coming-to-a-city-near-you/
 
 On Jun 21, 2010, at 3:55 PM, Jason van Zyl wrote:
 
 The Maven Meetups Sonatype puts on have been very popular in the past. We're 
 starting to take input from users on where they should be in the future:
 
 Sonatype’s coming to a city near you
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 {script:nopre:/Users/jvanzyl/signature/signature.sh}
 
 
 


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

Re: Maven 3 and M2_HOME environment variable

[Arnaud Héritier]

I think we didn't yet defined if we'll change it like for ~/.m2 directory
In all cases we'll do it in a compatible way. We'll use the new value if it is 
defined and fall back to the old one if it doesn't exist.

Arnaud Héritier
aherit...@apache.org

On Jun 5, 2010, at 10:09 AM, Jemos Infra wrote:

 Hi all, 
 
 In Maven 3, will the Maven environment variable still be M2_HOME? Has
 this been done for backward compatibility?
 
 Regards,
 
 M.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: New PMC Member

[Arnaud Héritier]

Congratulations Paul !

Arnaud

On May 14, 2010, at 11:34 PM, Brian Fox wrote:

 The Maven PMC recently voted to invite Paul Gier to join us as a
 member of the PMC Committee. He accepted and is now officially part of
 the Maven PMC. Congratulations Paul!
 
 If you'd like to read more about what his exactly means, take a look
 at http://www.apache.org/foundation/how-it-works.html
 
 --Brian Fox
 Maven PMC Chair.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


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

Re: [ANN] Apache Maven 3.0-beta-1 Released

[Arnaud Héritier]

Yes i began to study this issue I discovered two days ago
The issue was introduced in 2.4 and is in all 2.4.x releases.
I think it is enough critical to try to fix it quickly (And we can loose
many time before finding it and applying the workaround - myself 30 min)
I'm studying plexus-interpolator code to see how to do that (PLXCOMP-150)
and I'll try to submit a patch (I'm not commiter on plexus)
I already prepared the IT for the resources plugin.

Arnaud


On Thu, Apr 29, 2010 at 9:27 AM, Frederic Camblor fcamb...@gmail.comwrote:

 For you information,

 Because of http://jira.codehaus.org/browse/MRESOURCES-104, there will be
 regressions in 3.0-beta1 on filtering of ressources files containing a @
 inside it (like urls or datasources) if you relies on the super pom
 definition of the maven-resources-plugin (aligned from 2.3 to 2.4.2 between
 mvn 2.2.1 and 3.0-beta1)

 Frederic

 On Thu, Apr 29, 2010 at 1:53 AM, Hervé BOUTEMY herve.bout...@free.fr
 wrote:

  FYI, this has just been fixed (thanks Kristian).
 
  The fix is in Maven 3 trunk, then won't be available to general public
  before
  Maven 3.0-beta-2 release: no ETA ;)
 
  I just compiled Maven trunk for myself then maven-site-plugin 3.0 branch,
  and
  everything is now ok.
 
 
  Regards,
 
  Hervé
 
  Le samedi 24 avril 2010, Kristian Rosenvold a écrit :
   This will be fixed real soon, the site plugin needs a minor update.
  
   On Fri, Apr 23, 2010 at 11:06 PM, Kathryn Huxtable 
  
   kath...@kathrynhuxtable.org wrote:
Any reason why mvn clean package on the checked out source would
  yield:
   
[INFO] --- maven-compiler-plugin:2.1:compile (default-compile) @
maven-site-plugin ---
[INFO] Compiling 23 source files to
   
  /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT
   /target/classes [INFO]
- [ERROR]
COMPILATION ERROR :
[INFO] -
[ERROR]
   
  /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT
  
 
 /src/main/java/org/apache/maven/plugins/site/DefaultMavenReportExecutor.ja
   va:[209,41] cannot find symbol
symbol  : method
   
  calculateForkedExecutions(org.apache.maven.plugin.MojoExecution,org.apach
   e.maven.execution.MavenSession) location: interface
org.apache.maven.lifecycle.LifecycleExecutor
   
[ERROR]
   
  /Users/huxtable/Documents/workspace/maven-site-plugin-3.0-beta-1-SNAPSHOT
  
 
 /src/main/java/org/apache/maven/plugins/site/DefaultMavenReportExecutor.ja
   va:[213,45] cannot find symbol
symbol  : method
   
  executeForkedExecutions(org.apache.maven.plugin.MojoExecution,org.apache.
   maven.execution.MavenSession) location: interface
org.apache.maven.lifecycle.LifecycleExecutor
   
[INFO] 2 errors
[INFO] -
[INFO]
   
  
[INFO] BUILD FAILURE
   
-K
   
On Apr 23, 2010, at 3:42 PM, Kathryn Huxtable wrote:
 Great! I'll try it out and let you know.

 You're probably already doing integration testing, so you probably
   
already know anything I'll report. I'l check the JIRA before I
complain...
   
 Thanks!

 -K

 On Apr 23, 2010, at 3:02 PM, Hervé BOUTEMY wrote:
 this one isn't done by Jason, but this won't give you an ETA
 neither
 ;)

 maven-site-plugin 3.0-beta-1 shouldn't be far: see [1]
 you can install it for yourself and see if it works

 we will probably put the release out in the next weeks

 Regards,

 Hervé
   
   
 
 https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+and+site+plug
   in
   
 Le vendredi 23 avril 2010, Kathryn Huxtable a écrit :
 I know Jason says he won't give ETAs, but is there any ETA on the
 site reporting? I make a lot of use of it, and I doubt I'm alone.

 My personal preference is to find some way to integrate the
 docbkx
   
plugin
   
 with the site framework. I've got some code that does this for
  Maven
 2, and it works for Maven 3, but the reports aren't generated.

 -K

 On Apr 23, 2010, at 8:05 AM, Benjamin Bentmann wrote:
 The Maven team is pleased to announce the release of Apache
 Maven
 3.0-beta-1.

 Maven is a project comprehension and build tool, designed to
 simplify
   
the
   
 process of maintaining a healthy development lifecycle for your
   
project.
   
 You can read more here:

 http://maven.apache.org/

 Downloads of source and binary distributions are listed in our
   
download
   
 section:

 http://maven.apache.org/download.html

 A major goal of Maven 3.0 is to be compatible, to the extent
 possible, with existing plugins and projects designed for Maven
  2.x.
 Users interested