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  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"  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  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  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 :
>>
>> > 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 :
>> >
>> >> 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
>
-- 
-
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]

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

> and it happens at deploy phase only
>
> -D
>
> On Fri, May 12, 2017 at 12:01 PM, Dan Tran  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 
> > 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 
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 
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  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 
> > 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]

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  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 
> 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 
> wrote:
> >>>
> >>>> Olivier fixed the doco so that should do out shortly.
> >>>>
> >>>> On Mar 18, 2015, at 9:48 AM, Anders Hammar  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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>&

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

> MNG-5789 created to monitor this.
> Thanks for reporting!
>
> /Anders
>
> On Thu, Mar 19, 2015 at 8:52 AM, Arend v. Reinersdorff 
> 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  wrote:
> >
> > > Olivier fixed the doco so that should do out shortly.
> > >
> > > On Mar 18, 2015, at 9:48 AM, Anders Hammar  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: [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=imghp&tbm=isch&q=maven+logo&oq=maven+logo
> >
> >
> >
> http://www.bing.com/images/search?q=maven+logo&go=Submit&qs=n&form=QBLH&scope=images&pq=maven+logo
> >
> > Our current logo, with a single highlighted letter stands out quite well
> > from the other "maven" logos, so keeping a highlighted letter and an
> italic
> > rendered font maintains continuity with our current logo.
> >
> > By changing the highlighted letter to the `v` and by using two Apache
> > feathers to create the `v`, we connect our logo back to Apache... we are
> > Apache Maven after all.
> >
> > The `v` is also the common short term for version (e.g.v3 is short for
> > version 3). Apache Maven puts a lot of emphasis on versions of
> dependencies
> > and plugins... you could say that versions are very important to Maven.
> >
> > The colours of the feather were changed to solid colours to match the owl
> > mascot's scarf, beak and eyebrows
> >
> > Voting rules
> > =
> >
> > Anyone who is subscribed to the dev or users list is eligible to vote.
> >
> > If you vote multiple times, only your final vote will be counted.
> >
> > The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014
> >
> > The vote is for all three changes as one single change. Partial votes
> > (e.g. for the logo but not the mascot, or vice-versa) will not be
> counted.
> >
> > I, as the caller of the vote, reserve the right to cancel the vote if
> this
> > vote is putting the harmony of the community at risk.
> >
> > If a majority of the PMC believe that this vote is putting the harmony of
> > the community at risk, then the PMC may cancel this vote (though if even
> a
> > small minority of the PMC were of that belief, I will more than likely
> have
> > cancelled the vote before the PMC would need to decide... I'm just
> stating
> > this FTR)
> >
> > The decision will be a simple majority, there will be no special veto
> > powers.
> >
> > +1: [ ] Change the logo to the proposed logo and adopt the owl as project
> > mascot
> > 0: [ ] No opinion
> > -1: [ ] No change
> >
> > Please only respond with +1, 0 or -1. If you want to discuss the proposed
> > changes please use a different thread. This thread is for voting only.
> >
> > -Stephen
> >
>



-- 
-
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  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
 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  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 ]
> > 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
> > >
> > 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/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  :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
> > > >
> > 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
> > > >
>

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=1&modificationDate=1389373170779&api=v2
>
>
> On 10 January 2014 16:40, Kristian Rosenvold
> wrote:
>
> > 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 
> >
> > > 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"  >
> > > 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 
> > > >
> > > >> 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
> > > >>

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

> On Thu, Jan 02, 2014 at 03:53:46PM -0500, Jeffrey E Care wrote:
> > Stephen Connolly  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: 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  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]

t/jrobocom-**aggregator<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<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<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-unsubscribe@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.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: 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"
 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: [VOTE] Retire Maven Model Converter

[Arnaud Héritier]

+1

-
Arnaud

Le 20 juil. 2013 à 19:27, Dennis Lundberg  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
 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"  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
>>  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
 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,  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


  my-group
  my-artifact
  ${my-version}
  sources


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


On Tue, Dec 18, 2012 at 2:34 AM, anjibman  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
>
> 
>   my-group
>   my-artifact
>   ${my-version}
> 
>
> 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  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:


  org.apache.maven.shared
  maven-dependency-analyzer
  1.3



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

Re-post

Le 14 juin 2012 à 16:36, "Arnaud Héritier"  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  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: jdocbook

[Arnaud Héritier]

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

Le 14 juin 2012 à 16:40, Wayne Fay  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:  
> 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]

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

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

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

> 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.2>bin\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.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  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 
> > 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  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"  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  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
>>>  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.

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  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: 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  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 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"  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: Welcome Wayne Fay to the Maven PMC

[Arnaud Héritier]

Welcome Wayne!

Arnaud

On Sat, Jan 15, 2011 at 9:15 PM, Wayne Fay  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 
> wrote:
> > Congrats Wayne!
> >
> > On Sat, Jan 15, 2011 at 7:14 AM, Mark Struberg 
> wrote:
> >
> >> Congratulations Wayne!
> >>
> >> Keep up the good work ;)
> >>
> >> LieGrue,
> >> strub
> >>
> >> --- On Sat, 1/15/11, Olivier Lamy  wrote:
> >>
> >> > From: Olivier Lamy 
> >> > Subject: Re: Welcome Wayne Fay to the Maven PMC
> >> > To: "Maven Users List" 
> >> > Date: Saturday, January 15, 2011, 11:38 AM
> >> > Welcome aboard !
> >> >
> >> > --
> >> > Olivier
> >> >  Le 15 janv. 2011 02:08, "Brian Fox" 
> >> > 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=10500&version=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:
>
>src/main/config
>config
>true
>
>quartz.properties
>
>
> 
> 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 wrote:
> 
>> 2010/10/26 Babak Farhang :
>>> 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
>  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:
> 
> 
> ...
> 
> 
> -
> 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 Hammar  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 Kracken  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:
> 
> 
>   org.apache.maven.plugins
>   maven-deploy-plugin
>   2.4
>   
>   
>   deploy-client-jar
>   deploy
>   
>   deploy-file
>   
>   
>   
> dist/${project.artifactId}Client.jar
>   
> http://ourhostname:8081/nexus/content/repositories/${deployAs}
>   ${project.groupId}
>   
> ${project.artifactId}Client
>   ${project.version}
>   jar
>   false
>   
>   
>   
>   deploy-client-sources-jar
>   deploy
>   
>   deploy-file
>   
>   
>   
> dist/${project.artifactId}Client-sources.jar
>   
> http://ourhostname:8081/nexus/content/repositories/${deployAs}
>   ${project.groupId}
>   
> ${project.artifactId}Client
>   ${project.version}
>   jar
>   sources
>   false
>   
>   
>   
>   deploy-client-javadoc-jar
>   deploy
>   
>   

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)
>  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  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: 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 
>> wrote:
>>> 2010/10/4 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.
>>> 
>>> 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]

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  wrote:
>> 2010/10/4 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.
>> 
>> 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]

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  wrote:
>> On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar  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:
>  
>
>  default
>  
>true
>  
>  
>file:///c:/test123
>  
>  
>
>  test123
>  test
>  ${repos.url}
>
>  
>
>  
> 
> And something like this goes in my pom files:
>  
>
>  myrepos
>  ${repos.url}
>
>  
> 
> 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: [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-i&version=13142&styleName=Text&projectId=10500&Create=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 true 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:///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:
> 
> 
>org.apache.maven.plugins
>maven-release-plugin
>2.0
>
>
> false
>clean install
>clean install
>-Dmaven.test.skip
>svn:///data/svn/client/myapp/tags 
> 
>true
>
>
> 
> 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 :


  ...
  

  
org.apache.maven.plugins
maven-jar-plugin
2.3.1

  
false
  

...
  

  
  ...


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

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