[ANN] extra-enforcer-rules version 1.0-beta-7 released

[Baptiste Mathus]

Hi,

The MojoHaus team is pleased to announce the release of the
extra-enforcer-rules version 1.0-beta-7.

These are extra rules for Apache Maven's Enforcer Plugin.

http://mojohaus.org/extra-enforcer-rules

Release Notes

https://github.com/mojohaus/extra-enforcer-rules/milestone/5?closed=1

Enjoy!

The MojoHaus team.

-- Baptiste

Re: When time do we need to delete .m2/repository

[Baptiste Mathus]

Well, it's getting slightly off topic, but maybe not.
With Maven, I strongly recommend you *totally* wipe out the local Maven
cache (aka repository, misleadingly named) on a regular basis. Like once a
week or so.
You could have a local release version, that has actually been built only
locally. So it would stay here, possibly hiding the real one, forever until
you remove it.
So, yes, using dependency:purge-local-repository can help that use
case/issue, but again IMO it's not worth it: just wipe out everything and
redownload.

In CI, because the reproducibility and non-flakiness should be valued
over/before anything else, automate this to be done every day or so.
Ideally, every single builds.
Bottom line: engineering time is orders of magnitude more expensive than
disk space and bandwidth. You don't want your build to fail (or *not* fail)
when it should (not) and have to dig into this.

Having a private repo/cache per job helps mitigate this, but certainly does
not remove the need to wipe it out as often as possible.

And it's not just me, see
http://blog.sonatype.com/2009/01/maven-continuous-integration-best-practices/

-- Baptiste

2017-09-12 14:30 GMT+02:00 John Patrick :

> I do similar to Eric for jenkins.
>
> But also for both developer builds and jenkins, I've got all projects
> setup to use the
> http://www.mojohaus.org/build-helper-maven-plugin/remove-
> project-artifact-mojo.html
> plugin. With both a default and clean phase execution. So when either
> jenkins or a developer does a clean, old artifacts are removed. This I
> find stops the need to intervention of having to manually clean up the
> local repo.
>
> I've also got a local artifactory instance running inside a vagrant
> vm, so i can safely delete my local repo if I've trouble and it can
> download what i needs to again. It also helps when working offline or
> over a slow internet connection as most things I've already download
> previously.
>
> John
>
>
>
>
> On 12 September 2017 at 12:56, Eric B  wrote:
> > I have my jenkins jobs designed to use private m2 repos per job.  I dont
> > find the need to delete them since the only transient changes are the
> > snapshots, which get reevaluated at every build anyhow.
> >
> > Thanks
> >
> > Eric
> >
> >
> > On Sep 11, 2017 2:43 PM, "Stephen Connolly" <
> stephen.alan.conno...@gmail.com>
> > wrote:
> >
> > On Fri 8 Sep 2017 at 11:22, Baptiste Mathus  wrote:
> >
> >> Le 7 sept. 2017 17:00, "Tushar Kapila"  a écrit :
> >>
> >> I had to delete a directory once as i had pressed Ctrl-C while it was
> >> downloading jars and a 0kb jar was created. This was in 2013, maybe it
> >> downloads to a temp file and then create the final file? It took
> sometime
> >> to debug. Builds were failing for no reason only on that test box, but
> >> working fine on my dev box, lots of fun.
> >>
> >> > If you don't, and
> >> > you have static (persistent) agents, very bad things will happen at
> some
> >> point.
> >>
> >> Can you explain this? What agents?
> >>
> >>
> >> Hehe, I was talking about Jenkins agents, sorry just realized I mixed my
> >> MLs. I thought I was reading Jenkinsci-users one :).
> >
> >
> > Bad Ba(p)tiste™
> >
> > ;-)
> >
> >
> >>
> >>
> >> On Thu, Sep 7, 2017 at 1:59 PM, Baptiste Mathus  wrote:
> >>
> >> > 2017-09-07 9:17 GMT+02:00 Guang Chao :
> >> >
> >> > > On Fri, Sep 1, 2017 at 11:31 AM, mingleizhang <
> zml13856086...@163.com>
> >> > > wrote:
> >> > >
> >> > > > Hello friends here.
> >> > > >
> >> > > >
> >> > > >  I would like ask a question ,it probably looks silly, but I
> >> still
> >> > > > want to know. As the subject said, when time do we need to delete
> >> > > > .m2/repository files ? Does anyone improve my mind ? Thank you
> very
> >> > much!
> >> > > >
> >> > > >
> >> > > >
> >> > > There is no need to do this unless you are out of disk space. It
> will
> >> > cause
> >> > > no harm, but maven will redownload all dependencies again. So that
> > will
> >> > > slow you down a bit.
> >> > >
> >> >
> >> > I am actually going to say the contrary. You should, at I'd even say,
> > you
> >> > *must* wipe out Maven repositories on a regula

Re: When time do we need to delete .m2/repository

[Baptiste Mathus]

Le 7 sept. 2017 17:00, "Tushar Kapila"  a écrit :

I had to delete a directory once as i had pressed Ctrl-C while it was
downloading jars and a 0kb jar was created. This was in 2013, maybe it
downloads to a temp file and then create the final file? It took sometime
to debug. Builds were failing for no reason only on that test box, but
working fine on my dev box, lots of fun.

> If you don't, and
> you have static (persistent) agents, very bad things will happen at some
point.

Can you explain this? What agents?


Hehe, I was talking about Jenkins agents, sorry just realized I mixed my
MLs. I thought I was reading Jenkinsci-users one :).


On Thu, Sep 7, 2017 at 1:59 PM, Baptiste Mathus  wrote:

> 2017-09-07 9:17 GMT+02:00 Guang Chao :
>
> > On Fri, Sep 1, 2017 at 11:31 AM, mingleizhang 
> > wrote:
> >
> > > Hello friends here.
> > >
> > >
> > >  I would like ask a question ,it probably looks silly, but I still
> > > want to know. As the subject said, when time do we need to delete
> > > .m2/repository files ? Does anyone improve my mind ? Thank you very
> much!
> > >
> > >
> > >
> > There is no need to do this unless you are out of disk space. It will
> cause
> > no harm, but maven will redownload all dependencies again. So that will
> > slow you down a bit.
> >
>
> I am actually going to say the contrary. You should, at I'd even say, you
> *must* wipe out Maven repositories on a regular basis. If you don't, and
> you have static (persistent) agents, very bad things will happen at some
> point.
>
> So, yeah, redownloading it is going to add some time to build, but this is
> a matter of speed vs. reproducibility, so better target reproduciblity/non
> flakiness then see how to optimize, not the contrary.
>
> And obviously, *NEVER, EVER share that .m2/repository between running
> builds*.
>
>
> >
> >
> > > Thanks
> > > Rice.
> >
> >
> >
> >
> > --
> > Guang <http://javadevnotes.com/java-string-to-integer-examples/>
> >
>



--
Regards
Tushar Kapila

Re: When time do we need to delete .m2/repository

[Baptiste Mathus]

2017-09-07 9:17 GMT+02:00 Guang Chao :

> On Fri, Sep 1, 2017 at 11:31 AM, mingleizhang 
> wrote:
>
> > Hello friends here.
> >
> >
> >  I would like ask a question ,it probably looks silly, but I still
> > want to know. As the subject said, when time do we need to delete
> > .m2/repository files ? Does anyone improve my mind ? Thank you very much!
> >
> >
> >
> There is no need to do this unless you are out of disk space. It will cause
> no harm, but maven will redownload all dependencies again. So that will
> slow you down a bit.
>

I am actually going to say the contrary. You should, at I'd even say, you
*must* wipe out Maven repositories on a regular basis. If you don't, and
you have static (persistent) agents, very bad things will happen at some
point.

So, yeah, redownloading it is going to add some time to build, but this is
a matter of speed vs. reproducibility, so better target reproduciblity/non
flakiness then see how to optimize, not the contrary.

And obviously, *NEVER, EVER share that .m2/repository between running
builds*.


>
>
> > Thanks
> > Rice.
>
>
>
>
> --
> Guang 
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Baptiste Mathus]

Well, as I hadn't tested this version and was just guessing /by intuition/
on what I generally use --batch-mode for, I'd disagree on your last
statement :).
But agreed it might be interesting to have some words about it in the help.
Patches/PR are always welcome.

2016-06-12 22:15 GMT+02:00 Oliver B. Fischer :

> Yes, running with -B disables the colorized output.
>
> But at least the description of this option should mention this too
> because IMHO it is not intuitive that -B disables the colors.
>
>
> WDYT?
>
> Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
>
>> Didn't test it, but using batch mode would seem natural for that IMO.
>>
>> My 2 cents
>>
>> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer :
>>
>> The colorized output is very nice, but I would like to have also a
>>> commandline option to disable it. I often redirect the output of Maven
>>> to a
>>> file to check the build. All the escape sequences are disturbing in this
>>> case.
>>>
>>> Running mvn --help I didn't see an option to disable it. Could such an
>>> option be added?
>>>
>>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fisc...@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fisc...@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Baptiste Mathus]

Didn't test it, but using batch mode would seem natural for that IMO.

My 2 cents

2016-06-12 22:04 GMT+02:00 Oliver B. Fischer :

> The colorized output is very nice, but I would like to have also a
> commandline option to disable it. I often redirect the output of Maven to a
> file to check the build. All the escape sequences are disturbing in this
> case.
>
> Running mvn --help I didn't see an option to disable it. Could such an
> option be added?
>
> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>
>> Hi to all Maven users,
>>
>>
>> is someone of you willing to do some testing on the current state of
>> development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/fawM,
>> Linux: https://s.apache.org/RQ3C
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash:
>> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
>> community...
>>
>> The current list of changes can be seen in the issue tracker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fisc...@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fisc...@jabber.org
> X http://xing.to/obf
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Filtering resources

[Baptiste Mathus]

In general, though it would surely work too, better avoid using
maven-antrun-plugin.
Maven is about standardizing your build process, using antrun is gonna add
issues with IDEs and so on.

Anyway, what you ask for doesn't seem to me to require custom filtering.
'@' is a standard delimiter (see
http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#delimiters),
so it should work out of the box.

Just enable filtering on the resources folders you want and you should be
done.

Cheers


2016-01-12 23:26 GMT+01:00 Matt Benson :

> If you just want to get it done, use the maven-antrun-plugin with Ant
> filtersets.
>
> Matt
>
> On Tue, Jan 12, 2016 at 4:14 PM, Thomas Sundberg  wrote:
> > Hi!
> >
> > I need to be able to filter files where the values to replace are defind
> as
> >
> > @aPlaceHolderThatNeedToBeSubstituted@
> >
> > Does anyone know of a good, working example where a custom resource
> > filter is implemented?
> >
> > I had a look at
> >
> http://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html
> > and it is a bit sketchy. A complete, annotated example would be nice
> > where all details needed to implement this interface
> > MavenResourcesFiltering are shared.
> >
> > A Git repo to clone would be the most awesome tip I can think of.
> >
> > Cheers,
> > Thomas
> >
> > --
> > Thomas Sundberg
> > M. Sc. in Computer Science
> >
> > Mobile: +46 70 767 33 15
> > Blog: http://thomassundberg.wordpress.com/
> > Twitter: @thomassundberg
> >
> > Better software through faster feedback
> >
> > -
> > 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: publishing sub-modules without requiring the parent module to be published?

[Baptiste Mathus]

I'm pretty sure you can't. At least on Central who IIRC checks that kind of
things.
It's indeed needed for the dependency resolution mechanism to work.
Cheers
Le 11 oct. 2015 11:50 PM, "Kevin Burton"  a écrit :

> I'm trying to open source a bunch of code in our stack.
>
> Is it possible to have a parent module private, and the child module
> public?
>
> The problem I have now is that if our customers or the open source
> community imports our modules, it needs to fetch the parent, which is
> private.
>
> I assume this is required due to maven inheritance because it needs to
> determine dependencies.
>
> I can just not specify a  but that causes other problems like the
> maven versions problem skipping it for some reason (though maybe this is a
> bug).
>
>
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

Re: Problem excluding source directory using maven-pmd-plugin with Jenkins CI

[Baptiste Mathus]

Well, it depends. If running on the command line outside Jenkins triggers
the issue, then it's more a Maven issue, hence here.

If the CLI works fine, but only fails somehow in Jenkins, then it's more
for Jenkinsci-users ML.

Cheers

2015-09-29 14:44 GMT+02:00 Rafael Fontoura :

> Hi. I have a problem using maven-pmd-plugin with Jenkins CI. Is this the
> correct mailing list to ask for help?
>
> Thank you.
>



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

Re: Creating local repository

[Baptiste Mathus]

Hi,

You don't share the "local repository", it should be seen and actually have
been called "cache". Search for tools called "Maven Repository Manager".
The famous ones out there are Archiva, Artifactory & Nexus (in alphabetical
order).

Cheers

2015-09-05 5:07 GMT+02:00 Niraj Chaudhary :

> Hi George,
>
> We had tried this earlier in my company.
> The problem is you never know what is 'all' the artifacts.
> Challenges faced:
>
> 1.One developer adding a new third-party dependency required that the
> artifact should be present in all the local dev repos for proper
> compilation.
> 2.Repo grows in size. Sharing becomes difficult.
>
> Thanks,
> Niraj
>
> On Fri, Sep 4, 2015 at 8:51 PM, George Karabotsos 
> wrote:
>
> > Hi Gail,
> >
> > The problem is that the VM is not controlled by my organization--they
> > are controlled by a third party.  As such, they are not even within our
> > intranet.
> >
> > I do have access to the master VM which has access to the internet to
> > allow me to set it up.   So what you and Michael mention, to get all
> > artifacts first, then use the -o flag from offilne VMs, should do the
> > trick.
> >
> > Thank you so much!
> >
> > Cheers,
> > George
> >
> > On Fri, Sep 4, 2015, at 10:54 AM, Gail Stewart wrote:
> > > How are you going to get the libraries you need to this server if you
> > > have
> > > no net access?
> > >
> > > I'm not sure if this would work, but one way might be to run the maven
> on
> > > a
> > > system with internet access so it populates the local repository in
> > > $HOME/.m2
> > >
> > > Tar or zip that directory up and get it to your server.  Unzip it into
> > > your
> > > $HOME/.m2 or to a common location for several developers to use.  You
> can
> > > tell maven where to find the local repo if you aren't using the default
> > > $HOME/.m2 location.
> > >
> > > Then run maven in offline mode.
> > >
> > > This is not ideal - why doesn't the server have internet access?  Could
> > > it
> > > have access to a company managed server?  If so you could setup a nexus
> > > or
> > > artifactory enterprise server - that would have internet access, but
> > > could
> > > be controlled in a secure manner.
> > >
> > >
> > > On Fri, Sep 4, 2015 at 10:27 AM, George Karabotsos 
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > Let me start by admitting I am by no means a maven expert :).
> > > >
> > > > Now I have a need to create a local file-based repository to be used
> by
> > > > maven when building my project.  I need this because I have no net
> > > > access from a set of VMs I and colleagues have to use .
> > > >
> > > > I was thinking of the following:
> > > > 1) connected to the net, normally proceed and download all necessary
> > > > artifacts
> > > > 2) copy these jars with
> > > >   > cp -r Users/gkarabotsos/.m2/repository .
> > > > 3) Add the following to my pom.xml
> > > >   
> > > > 
> > > >   localrepository
> > > >   file:///c:/repository/
> > > > 
> > > >   
> > > >
> > > > I do know that it does not work--I am guessing my c:/repository
> > > > structure does not have the correct form.
> > > >
> > > > I have also seen, in the net, commands such as the following:
> > > >
> > > > mvn install:install-file -Dfile=YOUR_JAR.jar -DgroupId=YOUR_GROUP_ID
> > > > -DartifactId=YOUR_ARTIFACT_ID -Dversion=YOUR_VERSION -Dpackaging=jar
> > > > -DlocalRepositoryPath=/var/www/html/mavenRepository
> > > >
> > > > Is this the only correct way? I have yet to try it, primarily
> because I
> > > > have a few dozen artifacts and doing so will take me a long time.
> > > >
> > > >
> > > > Cheers,
> > > > George
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Gail Stewart
> > > Sr. Release Engineer
> > >
> > > AP & Payment Automation
> > > 125 Cambridgepark Drive
> > > Cambridge, MA 02140
> > > gail.stew...@mineraltree.com
> > > 617.299.3399 x148
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>



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

Re: Finding transitive dependencies imported into our code

[Baptiste Mathus]

+1 dependency:analyze seems to be the one.
Le 7 août 2015 2:17 PM, "Ben Podgursky"  a écrit :

> I think you want mvn dependency:analyze -DfailOnWarning=true
>
>
> https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#failOnWarning
>
> On Fri, Aug 7, 2015 at 4:38 AM, Russell Gold 
> wrote:
>
> > mvn -X compile
> >
> > Look at the listing; it will show you all of the dependencies.
> >
> > > On Aug 7, 2015, at 7:14 AM, James Green 
> > wrote:
> > >
> > > See in-line
> > >
> > > On 7 August 2015 at 12:05, Björn Raupach <
> raupach.bjo...@googlemail.com>
> > > wrote:
> > >
> > >> hi,
> > >>
> > >>> On 07 Aug 2015, at 12:33, James Green 
> > wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> I want to know about any imports within our package base that are
> > >> resolved
> > >>> by a transitive dependency.
> > >>>
> > >>> There must be a command or tool for this - I'm not sure I've ever
> seen
> > >> one
> > >>> though?
> > >>
> > >> Maybe this helps: mvn dependency:resolve
> > >>
> > >
> > > Nope. Allow me to describe my use-case.
> > >
> > > I have been given a source code project. It has a dependency that we
> have
> > > no clear need for. I remove that dependency. The build now fails
> because
> > > our sources import something the now-removed dependency transitively
> > > provided.
> > >
> > > I want to know I don't have any other source-code dependencies not
> listed
> > > in .
> > >
> > > I can not see such a command listed under
> > > https://maven.apache.org/plugins/maven-dependency-plugin/
> > >
> > > Thanks,
> > >
> > > James
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Running jdeb plugin by itself .. not attached to the package lifecycle.

[Baptiste Mathus]

IMO disabling it for perf reason for snapshot might be acceptable, but in
your place I would really create and deploy the .deb at least for the
release so that you have a central place where all your released binaries
can be found.

Cheers
Le 3 août 2015 2:09 AM, "Benson Margulies"  a écrit :

> false
>
> On Sun, Aug 2, 2015 at 4:40 PM, Kevin Burton  wrote:
> > The Maven jdeb plugin (for building debian packages) recommends you set
> it
> > up like:
> >
> > 
> >   
> > package
> > 
> >   jdeb
> > 
> >
> > … but this means that if I do an
> >
> > mvn install
> >
> > that packages are built and installed into the maven repo.
> >
> > 1. this doesn’t make a ton of sense.  No one is going to install our
> .debs
> > from a maven repo.
> >
> > 2. it significantly slows down the build.  I imagine our build could be
> > from 30-200% faster if I could remove this.  It’s slowing down our
> > continuous integration system.
> >
> > What I’d like to do is run it like
> >
> > mvn jdeb:jdeb
> >
> > … but it doesn’t seem to have any goals associated.
> >
> > Any thoughts?
> >
> > --
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: jars with no pom.xml available - what to do next ?

[Baptiste Mathus]

Well, the other way, which I would recommend even more is to try and match
the closest possible public version, then use it as a dependency. Then see
if everything compiles and re-test the product carefully. That would be a
correct long-term solution. Housing a wildly uncontrolled modified version
is certainly not one.

Cheers

2015-06-08 22:26 GMT+02:00 Zk W :

> Hi Baptiste
>
> Thanks for responding.
>
> We already did your suggested step with Central Maven repo and couldnt find
> their GAV values unfortunately.
>
> We suppose we'll use fake GAV values then.
> We like to avoid missing these jars GAV coordinates if they really exist
> out there outside of Central Maven repo but we aren't sure and don't feel
> good when we cant find them since they are open source jars.
>
> Thanks
>
>
>
>
>
> On Mon, Jun 8, 2015 at 1:14 PM, Baptiste Mathus 
> wrote:
>
> > Hi,
> >
> > Not sure I understand.So guessing: you are somehow migrating from a
> typical
> > old-school project with jars committed in the project as-is, and you
> don't
> > know the version and so on.
> >
> > If so, then here's how I would proceed:
> > * compute the sha-1 hash of those jars
> > * search them though Central advanced search:
> > http://search.maven.org/#advancedsearch%7Cgav
> > * If you find them, bingo just use the GAV.
> >
> > If you don't, then you will have to somehow create a fake pom and upload
> > inside your corporate maven repository beside the jar file. In this case,
> > please make it very clear it's not an official version (like
> >
> >
> 1.2.3-internal-special-dont-know-where-the-hell-it-comes-from-and-who-touched-it-so-that-hash-does-not-match-anything-public).
> >
> > HTH
> >
> > Cheers
> >
> >
> >
> > 2015-06-08 21:46 GMT+02:00 Zk W :
> >
> > > Hi All
> > >
> > > We have a few open source jars that couldnt be found in Open Maven
> > Central
> > > repository for their pom.xml files. We like to use these for
> dependencies
> > > management in our main pom.xml.
> > >
> > > 1) What can we do to vet those jars with no pom.xml files and make them
> > > compliant for our use ?
> > > 2) How do we create these unavailable pom.xml files for these unvetted
> > jars
> > > ?
> > >
> > >
> > > Thank you.
> > >
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



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

Re: jars with no pom.xml available - what to do next ?

[Baptiste Mathus]

Hi,

Not sure I understand.So guessing: you are somehow migrating from a typical
old-school project with jars committed in the project as-is, and you don't
know the version and so on.

If so, then here's how I would proceed:
* compute the sha-1 hash of those jars
* search them though Central advanced search:
http://search.maven.org/#advancedsearch%7Cgav
* If you find them, bingo just use the GAV.

If you don't, then you will have to somehow create a fake pom and upload
inside your corporate maven repository beside the jar file. In this case,
please make it very clear it's not an official version (like
1.2.3-internal-special-dont-know-where-the-hell-it-comes-from-and-who-touched-it-so-that-hash-does-not-match-anything-public).

HTH

Cheers



2015-06-08 21:46 GMT+02:00 Zk W :

> Hi All
>
> We have a few open source jars that couldnt be found in Open Maven Central
> repository for their pom.xml files. We like to use these for dependencies
> management in our main pom.xml.
>
> 1) What can we do to vet those jars with no pom.xml files and make them
> compliant for our use ?
> 2) How do we create these unavailable pom.xml files for these unvetted jars
> ?
>
>
> Thank you.
>



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

Re: Where's the new home for the clirr-maven-plugin?

[Baptiste Mathus]

Actually, it does. appassembler-maven-plugin is a module of the multimodule
project "appassembler".
I just checked and it had the same structure at mojo.codehaus.org. (see
https://www.google.fr/search?q=appassembler%20maven%20plugin)

Cheers

2015-06-08 21:27 GMT+02:00 Sandra Parsick :

> Hi,
>
> the website for appassembler-maven-plugin doesn't follow the pattern.
> Its current website is
> http://www.mojohaus.org/appassembler/appassembler-maven-plugin/
>
> Greetz,
>
> Sandra
>
>
> Am 08.06.2015 um 09:24 schrieb Baptiste Mathus:
> > Yes, MOJO@Codehaus project was renamed MojoHaus.
> >
> > So, basically, any project you found docs for under
> > http://mojo.codehaus.org/xyz-maven-plugin should follow the
> > following pattern:
> >
> > - its sources should be found under
> > https://github.com/mojohaus/xyz-maven-plugin - its website should
> > be found under http://www.mojohaus.org/xyz-maven-plugin/
> >
> > If not, then that plugin may have been NOT migrated (for various
> > reasons, but at least temporary lack of interest from maintainers).
> > If you need them, please ping us on our ML (information about it
> > will be updated under http://www.mojohaus.org in the upcoming days
> > & weeks).
> >
> > Cheers
> >
> > 2015-06-08 0:47 GMT+02:00 Thomas Broyer :
> >
> >> https://github.com/mojohaus/clirr-maven-plugin ?
> >>
> >>
> >> On Mon, Jun 8, 2015 at 12:26 AM Martijn Dashorst <
> >> martijn.dasho...@gmail.com> wrote:
> >>
> >>> The clirr-maven-plugin was one of the unfortunate casualties
> >>> of codehaus' demise.
> >>>
> >>> It should get a new home, but my google-fu leaves me without
> >>> any results. Where does this plugin live on?
> >>>
> >>> Martijn
> >>>
> >>> -
> >>>
> >>>
> 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
>
>


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

Re: Where's the new home for the clirr-maven-plugin?

[Baptiste Mathus]

Basically yes, when done by hand.

But we obviously plan to ease that for each plugin by making it somehow a
single mvn command. (Karl-Heinz already worked on that)

Cheers
Le 8 juin 2015 5:50 PM, "Martijn Dashorst"  a
écrit :

> OK, thanks!
>
> It appears that the project was migrated, but not its site. Is that as
> simple as running a mvn site, and copying target/site to a ghpages
> branch?
>
> Martijn
>
>
> On Mon, Jun 8, 2015 at 9:24 AM, Baptiste Mathus 
> wrote:
> > Yes, MOJO@Codehaus project was renamed MojoHaus.
> >
> > So, basically, any project you found docs for under
> > http://mojo.codehaus.org/xyz-maven-plugin should follow the following
> > pattern:
> >
> >- its sources should be found under
> >https://github.com/mojohaus/xyz-maven-plugin
> >- its website should be found under
> >http://www.mojohaus.org/xyz-maven-plugin/
> >
> > If not, then that plugin may have been NOT migrated (for various reasons,
> > but at least temporary lack of interest from maintainers). If you need
> > them, please ping us on our ML
> > (information about it will be updated under http://www.mojohaus.org in
> the
> > upcoming days & weeks).
> >
> > Cheers
> >
> > 2015-06-08 0:47 GMT+02:00 Thomas Broyer :
> >
> >> https://github.com/mojohaus/clirr-maven-plugin ?
> >>
> >>
> >> On Mon, Jun 8, 2015 at 12:26 AM Martijn Dashorst <
> >> martijn.dasho...@gmail.com>
> >> wrote:
> >>
> >> > The clirr-maven-plugin was one of the unfortunate casualties of
> >> > codehaus' demise.
> >> >
> >> > It should get a new home, but my google-fu leaves me without any
> >> > results. Where does this plugin live on?
> >> >
> >> > Martijn
> >> >
> >> > -
> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Where's the new home for the clirr-maven-plugin?

[Baptiste Mathus]

Yes, MOJO@Codehaus project was renamed MojoHaus.

So, basically, any project you found docs for under
http://mojo.codehaus.org/xyz-maven-plugin should follow the following
pattern:

   - its sources should be found under
   https://github.com/mojohaus/xyz-maven-plugin
   - its website should be found under
   http://www.mojohaus.org/xyz-maven-plugin/

If not, then that plugin may have been NOT migrated (for various reasons,
but at least temporary lack of interest from maintainers). If you need
them, please ping us on our ML
(information about it will be updated under http://www.mojohaus.org in the
upcoming days & weeks).

Cheers

2015-06-08 0:47 GMT+02:00 Thomas Broyer :

> https://github.com/mojohaus/clirr-maven-plugin ?
>
>
> On Mon, Jun 8, 2015 at 12:26 AM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> wrote:
>
> > The clirr-maven-plugin was one of the unfortunate casualties of
> > codehaus' demise.
> >
> > It should get a new home, but my google-fu leaves me without any
> > results. Where does this plugin live on?
> >
> > Martijn
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>



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

Re: Codehaus Mojo repository

[Baptiste Mathus]

Please be aware that there's still work undergoing. For example, we didn't
yet republish all the websites, but should do it in the upcoming weeks.
Then things will progressively settle (still currently waiting for some
infra bricks like our nexus instance to publish our artifacts).

Please also note that *not all* mojos were migrated, some may be done in
the near future, but the majority is likely to be never migrated for lack
of maintainers (and traction in general for some I guess). So, if you need
one mojo in particular and you think it's absolutely useful and it wasn't
migrated, please advertise it/tell us.

Cheers

2015-06-03 9:34 GMT+02:00 Curtis Rueden :

> Hi Olivier,
>
> > Have a look here https://github.com/mojohaus/
>
> Mojo was split up? Fantastic! Thank you so much, nice work!
>
> Regards,
> Curtis
>
> On Wed, Jun 3, 2015 at 9:01 AM, Olivier Lamy  wrote:
>
> > Hi
> > Have a look here https://github.com/mojohaus/
> >
> > Olivier
> >
> > On 3 June 2015 at 16:57, Curtis Rueden  wrote:
> >
> > > Hi everyone,
> > >
> > > It looks like Codehaus SVN is finally kaput:
> > >
> > > $ svn checkout http://svn.codehaus.org/mojo
> > > svn: E175011: Unable to connect to a repository at URL '
> > > http://svn.codehaus.org/mojo'
> > > svn: E175011: Repository moved temporarily to '
> > http://www.codehaus.org
> > > ';
> > > please relocate
> > >
> > > But the mojo repository is not yet populated on GitHub:
> > > https://github.com/codehaus/mojo
> > >
> > > Is it planned to populate that repository? Where does the code live in
> > the
> > > meantime?
> > >
> > > Thanks,
> > > Curtis
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>



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

Re: orders of plug-in

[Baptiste Mathus]

   false >> overWriteSnapshots>
> >>   true
> >>
> >>   true<__/useSubDirectoryPerScope>
> >>   sources
> >>   
> >>   
> >>
> >>   
> >>
> >> 
> >>
> >> regards，
> >> Lin
> >>
> >> On Sat, Apr 4, 2015 at 4:23 PM, Karl Heinz Marbaise
> >> mailto:khmarba...@gmx.de>>
> >> wrote:
> >>
> >> Hi,
> >>
> >> On 4/5/15 1:09 AM, Lin Ma wrote:
> >>
> >> Hello everyone,
> >>
> >> I tried to manipulate orders of plug-in in pom.xml and
> >> always get the same
> >> results.
> >>
> >>
> >> Of which plugins would you like to change the execution
> >> order? And for
> >> what purpose?
> >>
> >>
> >>Wondering if any impact for order or plug-in, and any
> >> best
> >>
> >>
> >> practices? Thanks.
> >>
> >>
> >> So the order of executions is defined by the binding to the
> >> appropriate
> >> life cycle  as you can see here:
> >>
> >> http://maven.apache.org/ref/3.__3.1/maven-core/default-__
> >> bindings.html
> >> <http://maven.apache.org/ref/3.3.1/maven-core/default-
> >> bindings.html>
> >>
> >>
> >> Or are you talking about execution order within the same
> >> life cycle phase?
> >>
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >>
> >> --__
> >> --__-
> >> To unsubscribe, e-mail: users-unsubscribe@maven.__apache.org
> >> <mailto:users-unsubscr...@maven.apache.org>
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> <mailto:users-h...@maven.apache.org>
> >>
> >>
> >>
> >
> > Mit freundlichem Gruß
> > Karl-Heinz Marbaise
> > --
> > SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> > Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
> > Hauptstrasse 177 USt.IdNr: DE191347579
> > 52146 Würselen   http://www.soebes.de
> >
>



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

Re: How to configure maven-dependency-plugin's encoding used for unpack?

[Baptiste Mathus]

And this is actually not even always true, CP1252 is also often used on
Windows (in France for example).

Encoding is actually a quite "simple" problem, but transfer makes it
difficult to handle as each move has to take care of what it does.
As for the JIRA tickets, if you feel this is not OK, feel free to
comment/reopen/create the ones you want.
But also beware that without a patch, in that very specific situation, it's
not very likely someone else will spend time to fix it.

HTH
Cheers

2015-03-16 15:04 GMT+01:00 Markus Karg :

> Kristian,
>
> can you please reopen the item then? I mean, it simply is not fixed,
> because UTF-8 ZIPs are not a solution: Windows cannot correctly display
> them, so people on the Windows world will virtually every create CP850-ZIPs!
>
> Do you know about any plans to support this, or what is the intended
> future of this issue?
>
> Thanks
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: kristian.rosenv...@zenior.no [mailto:kristian.rosenv...@zenior.no]
> Im Auftrag von Kristian Rosenvold
> Gesendet: Montag, 16. März 2015 13:46
> An: Maven Users List
> Betreff: Re: How to configure maven-dependency-plugin's encoding used for
> unpack?
>
> I did not actually look at the implementation on the dependency plugin,
> but it is actually technically impossible to supply the encoding parameter
> to
> *unzip* via the  tag. So until this is fixed, UTF-8 zip
> archives are the only ones that will work (with plexus unzip archiver).
>
> Kristian
>
>
> 2015-03-16 13:05 GMT+01:00 Adrien Rivard :
>
> > If I'm reading the documentation correctly, 
> > only apply to filter resources, not to zip them.
> >
> > In any case I would try using utf-8.
> >
> >
> > On Mon, Mar 16, 2015 at 12:34 PM, Kristian Rosenvold <
> > kristian.rosenv...@gmail.com> wrote:
> >
> > > I dont believe there is support for specifying encoding to unzip. At
> > least
> > > assembly only provides config to zip. Call it a bug, call it a
> > > feature :(
> > >
> > > Kristian
> > >
> > >
> > > 2015-03-16 12:12 GMT+01:00 Markus Karg :
> > >
> > > > To preserve German umlauts in file names within a ZIP, we are
> using...
> > > >
> > > > 
> > > > CP850
> > > > 
> > > >
> > > > ...in the maven-assembly-plugin configuration, which is working well.
> > :)
> > > >
> > > > Next we want to use maven-dependency-plugin to unpack that ZIP.
> > > >
> > > > How can we configure maven-dependency-plugin:unpack so it will
> > > > apply
> > > CP850
> > > > when unpacking that ZIP?
> > > >
> > > > Thanks!
> > > > -Markus
> > > >
> > >
> >
> >
> >
> > --
> > Adrien Rivard
> >
>



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

Re: What is going on with maven-javadoc-plugin?

[Baptiste Mathus]

Just ich scratching and limited time, that's how OSS works.
Generally, if (like here) the code is moreover already committed, *kindly*
asking for a release on the dev ML can do the trick.

HTH

2015-03-13 2:38 GMT+01:00 Marcos Zolnowski <
marcos.zolnow...@yahoo.com.invalid>:

> From:
> http://jira.codehaus.org/browse/MJAVADOC-365?focusedCommentId=363324&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-363324"It
> has been about 6 months now since the last activity here. I wonder, what
> can be done with respect to getting a 2.11 or 2.10.2 version with this
> change applied?"
> Can anyone tell me why no one does the release of this plugin?
>



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

Re: Why would maven download a pom and not a jar?

[Baptiste Mathus]

Oh right, I didn't get your meaning. You're right, could be that, indeed.
Should check the plugin sources to be sure.

2015-03-11 7:06 GMT+01:00 Cintia Del Rio :

> When you invoke the dependency:tree, maven will download the dependency
> tree plugin and all the dependencies it needs to run that plugin.
>
>
> So I'd expect that every jar you now have in your local repository (~/.m2)
> is a dependency of the dependency:tree plugin.
>
> On 11 March 2015 at 17:02, Baptiste Mathus  wrote:
>
> > Could you rephrase? You think pom.xml is a dependency of the
> > "dependency:tree" goal? If so, then the answer is no.
> >
> > Cheers
> >
> > 2015-03-11 6:59 GMT+01:00 Cintia Del Rio :
> >
> > > Isn't it a dependency of the dependency plugin itself?
> > >
> > > On 11 March 2015 at 16:51, Baptiste Mathus  wrote:
> > >
> > > > Well, in that case, since you're asking for the dependency:tree I'm
> > even
> > > > surprised there's any jar downloaded. Maven would only need pom to
> > > compute
> > > > that. Downloading Jars is only done when needed (say for compiling,
> > etc.)
> > > >
> > > > Btw, do you really type "mvn dependency:tree pom.xml" ? What do you
> > > expect?
> > > > The "pom.xml" part is gonna lead to an error since pom.xml is not a
> > goal
> > > > and that's what's supposed to be listed after mvn.
> > > >
> > > > As for your question: I suppose oro is a transitive dependency of one
> > of
> > > > the things you depend on. mvn dependency:tree should generally show
> it
> > > btw.
> > > >
> > > > Cheers
> > > >
> > > > 2015-03-10 15:22 GMT+01:00 D C :
> > > >
> > > > > I am trying to download all dependencies from a pom file.  My steps
> > > are:
> > > > > 1. delete .m2/repository
> > > > > 2. mvn dependency:tree pom.xml
> > > > >
> > > > > Everything looks good, however as I browse the .m2 directory I can
> > see
> > > > that
> > > > > for some artifacts  maven only downloaded the pom file, and did not
> > > > > download the associated jar.  I then repeat the process on another
> > pom
> > > > > file.  This time the jar file is present for that same artifact.
> > > > >
> > > > > There are multiple artifacts that this happens on, but for
> > > > troubleshooting
> > > > > I'm just focusing on oro-2.0.8.   Neither of my poms declare oro,
> so
> > > this
> > > > > is a sub-dependency somewhere down the chain.  The process can be
> > > > > reproduced every time,  and I can see from the output that the
> > > oro-2.0.8
> > > > > pom file is downloaded from the same location (local artifactory)
> in
> > > both
> > > > > cases.
> > > > >
> > > > >
> > > > > Does anyone know why maven would download a pom file, and then not
> > > > attempt
> > > > > to download the associated jar?
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Dan
> > > > >
> > >
> >
>
>
>
> --
> ---
> Sent from TARDIS. Typos might be a timey whyney thingy.
> Enviado da TARDIS, podem existir erros devido à diferenças de espaço-tempo.
>
> Cintia Del Rio
>



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

Re: Why would maven download a pom and not a jar?

[Baptiste Mathus]

Could you rephrase? You think pom.xml is a dependency of the
"dependency:tree" goal? If so, then the answer is no.

Cheers

2015-03-11 6:59 GMT+01:00 Cintia Del Rio :

> Isn't it a dependency of the dependency plugin itself?
>
> On 11 March 2015 at 16:51, Baptiste Mathus  wrote:
>
> > Well, in that case, since you're asking for the dependency:tree I'm even
> > surprised there's any jar downloaded. Maven would only need pom to
> compute
> > that. Downloading Jars is only done when needed (say for compiling, etc.)
> >
> > Btw, do you really type "mvn dependency:tree pom.xml" ? What do you
> expect?
> > The "pom.xml" part is gonna lead to an error since pom.xml is not a goal
> > and that's what's supposed to be listed after mvn.
> >
> > As for your question: I suppose oro is a transitive dependency of one of
> > the things you depend on. mvn dependency:tree should generally show it
> btw.
> >
> > Cheers
> >
> > 2015-03-10 15:22 GMT+01:00 D C :
> >
> > > I am trying to download all dependencies from a pom file.  My steps
> are:
> > > 1. delete .m2/repository
> > > 2. mvn dependency:tree pom.xml
> > >
> > > Everything looks good, however as I browse the .m2 directory I can see
> > that
> > > for some artifacts  maven only downloaded the pom file, and did not
> > > download the associated jar.  I then repeat the process on another pom
> > > file.  This time the jar file is present for that same artifact.
> > >
> > > There are multiple artifacts that this happens on, but for
> > troubleshooting
> > > I'm just focusing on oro-2.0.8.   Neither of my poms declare oro, so
> this
> > > is a sub-dependency somewhere down the chain.  The process can be
> > > reproduced every time,  and I can see from the output that the
> oro-2.0.8
> > > pom file is downloaded from the same location (local artifactory) in
> both
> > > cases.
> > >
> > >
> > > Does anyone know why maven would download a pom file, and then not
> > attempt
> > > to download the associated jar?
> > >
> > >
> > > Thanks,
> > > Dan
> > >
>

Re: Help with warning: 'Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo'

[Baptiste Mathus]

[Don't talk tool loud about the Jenkins Maven Project Plugin, you're gonna
draw Stephen here ;-).]

IMO, this is not a Maven issue, it should be discussed on the jenkinsci
lists since as you say yourself in your last mail, this does only happen in
Jenkins not in CLI or in your IDE.
Beware that that Jenkins plugin runs Maven quite differently than on the
CLI, and thus can lead to unexpected issues (at least different ones).

Some people even argue that that plugin should indeed not be used because
of this notable difference.

Cheers

2015-03-11 0:48 GMT+01:00 Charles Chan :

> Thanks for the pointers, here are my reply.
>
> On Tue, Mar 10, 2015 at 8:43 AM, Karl Heinz Marbaise wrote:
>
> > Hi,
> >
> >
> > Do you have other warnings in your build? About missing artifacts etc. ?
> >
>
> Other than this particular message. There are no other warnings in the
> console log.
>
>
> > The class is part ofr maven-sources-plugin which is weird, cause a single
> > class can't be access if the plugin has been loaded...?
> >
>
> Not sure what to look for to answer this question.
>
> Check the log output of your build ...in particular start a clean
> > build...remove the local repository from your jenkins build...and check
> the
> > logging output carefullyusually this is caused by not correctly
> > downloaded or missing artifacts in corporate repository managers...
> >
>
> Tried:
> 1. Delete the Jenkins workspace (clean checkout)
> 2. Remove .m2 from Jenkins slave
> 3. Rebuild  same warning
>
>
> > BTW: How is Maven called ? Which Maven version do you use?
> >
>
> Maven 3.0.5 is called by Jenkins via Maven project plugin (
> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Project+Plugin).
>
> The configuration:
> * Root POM: pom.xml
> * Goals and options: source:jar
> * Maven validation level: default
> * Settings file: Use default maven settings
> * Global settings file: Use default maven global settings
>
> I also tried to add '--debug' to the MAVEN_OPTS, but it didn't show any
> more details regarding the warning.
> I also try to change validation level (default, minimal, 2.0, 3.0, 3.1,
> strict) and they all show the same error.
>
> Note: We only see this problem when compiling on Jenkin. There are no
> problem when building the project from NetBeans or command line.
>
>
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>

Re: Why would maven download a pom and not a jar?

[Baptiste Mathus]

Well, in that case, since you're asking for the dependency:tree I'm even
surprised there's any jar downloaded. Maven would only need pom to compute
that. Downloading Jars is only done when needed (say for compiling, etc.)

Btw, do you really type "mvn dependency:tree pom.xml" ? What do you expect?
The "pom.xml" part is gonna lead to an error since pom.xml is not a goal
and that's what's supposed to be listed after mvn.

As for your question: I suppose oro is a transitive dependency of one of
the things you depend on. mvn dependency:tree should generally show it btw.

Cheers

2015-03-10 15:22 GMT+01:00 D C :

> I am trying to download all dependencies from a pom file.  My steps are:
> 1. delete .m2/repository
> 2. mvn dependency:tree pom.xml
>
> Everything looks good, however as I browse the .m2 directory I can see that
> for some artifacts  maven only downloaded the pom file, and did not
> download the associated jar.  I then repeat the process on another pom
> file.  This time the jar file is present for that same artifact.
>
> There are multiple artifacts that this happens on, but for troubleshooting
> I'm just focusing on oro-2.0.8.   Neither of my poms declare oro, so this
> is a sub-dependency somewhere down the chain.  The process can be
> reproduced every time,  and I can see from the output that the oro-2.0.8
> pom file is downloaded from the same location (local artifactory) in both
> cases.
>
>
> Does anyone know why maven would download a pom file, and then not attempt
> to download the associated jar?
>
>
> Thanks,
> Dan
>



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

Re: Disabling surefire error printing to console?

[Baptiste Mathus]

What do you mean "doesn't seem to solve the situation"? Doesn't it work?

2015-03-08 20:22 GMT+01:00 Kevin Burton :

> Is there away to get surefire to ONLY show the tests which failed, and NONE
> of their output?
>
> I read through the configuration and all the options that would seem to do
> this are already enabled (defaults) … and I can’t find anything that would
> disabled it.
>
> I tried redirectTestOutputToFile and that doesn’t seem to solve the
> situation.
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
> <http://spinn3r.com>
>



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

Re: Determining the directory of test/resources from multi-modules?

[Baptiste Mathus]

Well, IIUC yes. For example you could use filtering to inject the property
saying where the test/resources are. And if you need that directly in some
code, then the templating-maven-plugin may be what you need.

Please give more precision of you need more help.

Cheers
Le 2 mars 2015 21:37, "Kevin Burton"  a écrit :

> I have a bunch of side-files I need to maintain for my unit tests.  They’re
> the results of an text extraction / mining operation.  So I need a portable
> way to learn the directory of the current module from a test.
>
> Is there an easy way to find that out?
>
> Kevin
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
> 
>

Re: write developers & contributors into Jar

[Baptiste Mathus]

Actually, maven-archiver is a shared component, somehow low-level hence
used by many plugins.

In your case, just configure the maven-jar-plugin
http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html

Cheers

2015-03-01 20:21 GMT+01:00 Ron Wheeler :

> http://maven.apache.org/shared/maven-archiver/index.html
> This plug-in seems to allow yo a way to add key/value pairs to the
> Manifest.
> manifestEntries A list of key/value pairs to add to the manifest.
>
>
>
>
> On 01/03/2015 6:41 AM, Philipp Kraus wrote:
>
>> Hello,
>>
>> I use Maven 3.0 with the developers and contributors inside the pom.xml.
>> I use also the manifestEntries with the maven-assembly-plugin to add some
>> flags to the Jar manifest file.
>> I would like to add the developer and contributors list to the Jar, but I
>> don’t know in which way I can add a list with name, email, and role types.
>> My idea is that I create a comma separated list
>> list with the data, but how can I create within the pom.xml the correct
>> output list? E.g. the pom.xml stores:
>>
>> 
>> 
>> myID
>> myName
>> myName@myDomain
>> 
>>  architect
>>  developer
>>
>> 
>> 
>>
>> so in the manifest should be a line e.g.
>>
>> Developers = myName - myName@myDomain - architect / developer,
>>
>> I have tried to define it with
>>
>> 
>> ${project.developers}
>> 
>>
>> but this writes only the Java object items to the entry. How can I create
>> a loop / xquery within the pom.xml to iterate over the developer items?
>>
>> Thanks
>>
>> Phil
>>
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


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

Re: Invoke another Maven

[Baptiste Mathus]

Hi Dan,
We're using https://github.com/TimMoore/mojo-executor for that and it's
quite doing the job.

HTH

Cheers
Le 21 févr. 2015 21:43, "Dan Tran"  a écrit :

> I have a need my maven to exec another maven build, but also inherit
> original argument as well  ( ex pickup -s option )
>
> possible?  maven-invoker-plugin seems to have the right ingredient, but it
> is more at the testing side
>
> Very much appreciate any advice
>
> -Dan
>

Re: Configure Logger (timestamps in Jenkins)

[Baptiste Mathus]

Just use a Jenkins plugin like timestamper [1], don't depend on customized
Maven binaries. The advantage of doing it at the Jenkins level is that the
whole build will be timestamped, even anything before or after the Maven
part.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Timestamper

2015-02-20 14:49 GMT+01:00 Bernd :

> Hello,
>
> since Maven 3.1 the simple logger properties are a convinient method to
> switch on (millisecond) relative time stamps in Maven.
>
> I enjoy this on the console as it does not take much room and allows to see
> potential for optimizing. This is done by switching on the timestamps (the
> empty default format is printing them as relative millis):
>
> org.slf4j.simpleLogger.showDateTime=true
>
> However I want this feature in Jenkins as well. There I have the problem
> that when using the automatic maven deploy which downloads a selected
> version from maven site and unpacks it (which is convinient to roll it out
> to the slaves) then I have no hook for making the required config file
> modification.
>
> I have also tried using the above property as a system property, but it
> does not seem to work. Jenkins can manage and distribute settings.xml but
> it seems to have no grab on the simplelogger.properties.
>
> Any idea how to solve that cleanly?
>
> Gruss
> Bernd
>



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

Re: access to license node

[Baptiste Mathus]

Le 19 févr. 2015 16:16, "Andreas Sewe" 
a écrit :
>
> Hello,
>
> > I’m using Maven 3.2 with the pom definition
> >
> > http://www.w3.org/2001/XMLSchema-instance"; xmlns="
http://maven.apache.org/POM/4.0.0";
> >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> > 4.0.0
> >
> >
> > I have added this items to my pom
> >
> > 
> > 
> > GNU General Public License 3
> > http://www.gnu.org/licenses/gpl-3.0.en.html
> > 
> > 
> >
> > and I would like to reference to the items with
> >
> > ${project.licenses.license.url}
> > ${project.licenses.license.name}
> >
> > but these lines does not work - empty result, so I would like to reread
the items of my license node, how can I do this?
>
> Have a look at . While it
> is marked as fixed, apparently things like
> ${project.licenses.0.license.name} did not (and still do not; I just

Sorry cannot check just now, but off the top of my head, shouldn't it be
more something along:
${project.licenses[0].license.name}

?

> checked) work. :-(
>
> Best wishes,
>
> Andreas
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Maven 3 with newest Checkstyle

[Baptiste Mathus]

I guess you mean you don't have any  tag in your pom.xml.

Under build/plugins declare a plugin block like this to override the
inherited version

  maven-checkstyle-plugin
  6.3


Btw, you should be aware that always "pinning" the plugin versions is a
strongly recommended practice. Indeed, one of the biggest things maven
promotes is build reproducibility, and not pinning plugins puts you at risk
of having your build suddenly falling (or worse changing behavior unseen)
because you changed your maven version, or some non standard plugin has
just been released...

Cheers
Le 14 févr. 2015 02:24, "Philipp Kraus"  a
écrit :

> Hello,
>
> I'm using Maven 3.2.5 and I would like to use the Checkstyle plugin in the
> newest version (6.3).
> The default installation is 5.8, so how can I add the 6.3 version of the
> plugin at my pom.xml and
> use it on the check goal at the validate phase?
>
> Thanks a lot
>
> Phil
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Dependency conflict resolution

[Baptiste Mathus]

Do you use dependencyManagement ?

And Jason is right: providing a test project is quicker to help you. Might
be even quicker for you than explaining it by mail.
Push it for example on your github account and post the link here.

Cheers
Le 13 févr. 2015 21:21, "Jason van Zyl"  a écrit :

> Provide a sample project with what you expect as the result for a given
> project.
>
> The dependency plugin does its own weird resolution and M2Eclipse also has
> its own resolver (which is closer to what Maven actually does vs the
> dependency plugin) and I don't really want to think about your description
> of a project. Just give us a sample project.
>
> On Feb 13, 2015, at 3:05 PM, Endo Alejandro <
> alejandro.e...@grassvalley.com> wrote:
>
> > Hello everyone
> >
> > I thought I knew how maven did dependency conflict resolution: always go
> with the version that's closest to the base pom
> >
> > However, it seems that is not the case. Here is my scenario
> >
> > I have a pom of packaging=pom, call it A, which is the base where I
> execute maven.
> >
> > So this is my simplified graph where -> denotes a maven normal
> dependency. All poms of packaging pom will be represented with upper case
> and poms of packaging jar with lowercase
> >
> > A -> b:1.0-SNAPSHOT
> > A -> C -> d -> b:1.0-RC2
> >
> > When I look at the dependency hierarchy in eclipse, or at the
> dependency:tree or dependency:copy-dependencies, maven is always choosing
> b:1.0-RC-2, which means that my understanding of shortest path is not the
> full story since in the graph b:1.0-SNAPSHOT is a direct dependency. Could
> someone clear this for me? Is it related to RC vs snapshot?
> >
> > Thank you,
> >
> > Alejandro
> >
> > 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.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> the course of true love never did run smooth ...
>
>  -- Shakespeare
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Question about next maven-fluido-skin release

[Baptiste Mathus]

Hi better ask for a release in the dev list. If the code is actually
already fixed and just needs be released there's generally committers
willing to do it.

Cheers
Le 14 févr. 2015 02:23, "Mikko Kuokkanen"  a
écrit :

> Hi.
>
> We are prototyping following combination for our web site generation:
> * maven-site-plugin 3.4
> * doxia-module-markdown 1.6
> * maven-fluido-skin 1.3.1
>
> According to fluido documentation it has nice source code prettify
> feature with line numbers. Alas, I didn't get it to work. Then I found
> this bug report http://jira.codehaus.org/browse/MSKINS-86. It seems
> that it is a bug and will be fixed in the next versions 1.3.2 and 1.4.
>
> I did not see any release date attached to those versions. Is there
> any timetable when they could be released?
>
>
> Thanks,
> Mikko Kuokkanen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: What are mobile developers best practices

[Baptiste Mathus]

Additional note: because of the way Maven now handles the sources of the
artifacts since 3.x [1], I indeed strongly recommend you to define many
settings.xml and change how/where you download artifacts from. If you do,
you're gonna have headaches with _remote.repositories files and be forced
to use mvn -llr very often.

Cheers

[1]
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository

2015-01-02 9:21 GMT+01:00 Baptiste Mathus :

> IIUC your request, then I'd advise you to simply run a local maven
> repository manager on your laptop. Then define one and only one
> settings.xml to proxy everything through that MRM.
>
> I've done that in the past with nexus, and it worked like a breathe.
>
> 2014-12-25 7:11 GMT+01:00 Mark Eggers :
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Folks,
>>
>> So I'm in a bit of a conundrum, and would like some ideas.
>>
>> Most of the time I work with my laptop connected to an internal
>> network, with its own maven repository (Nexus OSS). I proxy all
>> external repositories through this and everything works fine.
>>
>> Sometimes though, I'm out and about and need to do some work. From
>> other discussions on the mailing list, I understand that there are two
>> approaches:
>>
>> 1. work offline
>> 2. set up an additional maven repository proxy on the laptop
>>
>> I've done the second, but I'm a little confused as to how to optimally
>> configure both the proxy and settings.xml.
>>
>> Currently, I have everything in settings.xml on the laptop pointing to
>> the laptop's repository. I then have the laptop's repository pointing
>> to the internal network repository.
>>
>> This works fine while I'm connected to the internal network, but will
>> fail to resolve artifacts if I'm not connected to the internal network
>> and have not previously resolved the artifact. This behavior is
>> exactly like not running a proxy repository on the laptop.
>>
>> Another configuration would be set up the laptop repository to proxy
>> internal repositories (I have 4), but point directly to the internet
>> repositories for Maven Central and a few others I use. This will work
>> whether I'm connected to the internal network or not, but will have
>> three drawbacks.
>>
>> 1. The internal repository will not be populated with artifacts I pull
>>down from central while disconnected
>> 2. This doesn't scale well - if there are 100s of mobile developers,
>>this sends unnecessary traffic to central
>> 3. The internal proxy will not have a collection of central artifacts
>>
>> Item 1 is unavoidable. Items 2 and 3 are not so nice.
>>
>> I guess the third solution would be as follows (using Nexus OSS as an
>> example).
>>
>> 1. use one set of proxy definitions while connected internally
>>a. point to the internal proxy
>>b. this proxies internal-only repositories
>>c. this proxies central and other internet-connected repositories
>> 2. use another set of proxy definitions when mobile
>>a. activate direct connection to central (and others) when mobile
>>b. deactivate proxy connection to central (and others) when mobile
>>
>> Would the third solution be viable (except for the fact that there's a
>> lot of fiddling involved)?
>>
>> Pointers, advice, and thoughts greatly appreciated.
>>
>> . . . . 'twas the night before Christmas, and Maven abounds
>> /mde/
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBAgAGBQJUm6p8AAoJEEFGbsYNeTwtB6wIAKtgi8w9J7YUGzLPcuYBF6EU
>> kRcNUy+nfbfqDLhMY9MU9YuW/1M5MtwjYaEpDxgZKSUz75K1YEkAnGU68Y/JhtQR
>> WNk4XoHMeZmtp5ggTgJR8lLZHQqigedGy8ZvvQJQt+W4eTO4EF/CnWsh4vCIGnBF
>> Bj+jmFnvwm210hRoJmrUVezv8+zZxMxULCAUGDKX7gNOVLl+aKQvnZSOo8icSbX0
>> zrWyns+dtcMc/qC5iujW9n2WaSRLpwZFB6fiK5SPr+ZbOJTaeNh+f7GYYDSfZ5/x
>> 9Gq2leMG79zQkz3Zg9BVdX+yo8hPQFvSSLq6POQfJDT4gJ2gp0My0h0qlK5tgNk=
>> =2bNJ
>> -END PGP SIGNATURE-
>>
>> ---
>> This email is free from viruses and malware because avast! Antivirus
>> protection is active.
>> http://www.avast.com
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>

Re: What are mobile developers best practices

[Baptiste Mathus]

IIUC your request, then I'd advise you to simply run a local maven
repository manager on your laptop. Then define one and only one
settings.xml to proxy everything through that MRM.

I've done that in the past with nexus, and it worked like a breathe.

2014-12-25 7:11 GMT+01:00 Mark Eggers :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Folks,
>
> So I'm in a bit of a conundrum, and would like some ideas.
>
> Most of the time I work with my laptop connected to an internal
> network, with its own maven repository (Nexus OSS). I proxy all
> external repositories through this and everything works fine.
>
> Sometimes though, I'm out and about and need to do some work. From
> other discussions on the mailing list, I understand that there are two
> approaches:
>
> 1. work offline
> 2. set up an additional maven repository proxy on the laptop
>
> I've done the second, but I'm a little confused as to how to optimally
> configure both the proxy and settings.xml.
>
> Currently, I have everything in settings.xml on the laptop pointing to
> the laptop's repository. I then have the laptop's repository pointing
> to the internal network repository.
>
> This works fine while I'm connected to the internal network, but will
> fail to resolve artifacts if I'm not connected to the internal network
> and have not previously resolved the artifact. This behavior is
> exactly like not running a proxy repository on the laptop.
>
> Another configuration would be set up the laptop repository to proxy
> internal repositories (I have 4), but point directly to the internet
> repositories for Maven Central and a few others I use. This will work
> whether I'm connected to the internal network or not, but will have
> three drawbacks.
>
> 1. The internal repository will not be populated with artifacts I pull
>down from central while disconnected
> 2. This doesn't scale well - if there are 100s of mobile developers,
>this sends unnecessary traffic to central
> 3. The internal proxy will not have a collection of central artifacts
>
> Item 1 is unavoidable. Items 2 and 3 are not so nice.
>
> I guess the third solution would be as follows (using Nexus OSS as an
> example).
>
> 1. use one set of proxy definitions while connected internally
>a. point to the internal proxy
>b. this proxies internal-only repositories
>c. this proxies central and other internet-connected repositories
> 2. use another set of proxy definitions when mobile
>a. activate direct connection to central (and others) when mobile
>b. deactivate proxy connection to central (and others) when mobile
>
> Would the third solution be viable (except for the fact that there's a
> lot of fiddling involved)?
>
> Pointers, advice, and thoughts greatly appreciated.
>
> . . . . 'twas the night before Christmas, and Maven abounds
> /mde/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJUm6p8AAoJEEFGbsYNeTwtB6wIAKtgi8w9J7YUGzLPcuYBF6EU
> kRcNUy+nfbfqDLhMY9MU9YuW/1M5MtwjYaEpDxgZKSUz75K1YEkAnGU68Y/JhtQR
> WNk4XoHMeZmtp5ggTgJR8lLZHQqigedGy8ZvvQJQt+W4eTO4EF/CnWsh4vCIGnBF
> Bj+jmFnvwm210hRoJmrUVezv8+zZxMxULCAUGDKX7gNOVLl+aKQvnZSOo8icSbX0
> zrWyns+dtcMc/qC5iujW9n2WaSRLpwZFB6fiK5SPr+ZbOJTaeNh+f7GYYDSfZ5/x
> 9Gq2leMG79zQkz3Zg9BVdX+yo8hPQFvSSLq6POQfJDT4gJ2gp0My0h0qlK5tgNk=
> =2bNJ
> -END PGP SIGNATURE-
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

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

[Baptiste Mathus]

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

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

Re: fetching a tar.gz URL / dependency via HTTP during a build?

[Baptiste Mathus]

Not sure it would do for your use case, but you might want to try the
maven-remote-resources-plugin. You'd have the cacheing behavior standard
with it.

Cheers
Le 8 nov. 2014 20:38, "Karl Heinz Marbaise"  a écrit :

> Hi Kevin,
>
>
> On 11/8/14 8:19 PM, Kevin Burton wrote:
>
>> Nice.. it works actually.  the only problem is that it downloads the
>> file every time and it’s 180MB… there’s no way to skip it if the file
>> already exists.  hm..
>>
>
>
> so this sounds like an idea for improvement
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
>> On Sat, Nov 8, 2014 at 11:00 AM, Karl Heinz Marbaise > > wrote:
>>
>> Hi Kevin,
>>
>> to download a an file from somewhere you could use the
>> wagon-maven-plugin like this:
>>
>> 
>>org.codehaus.mojo
>>wagon-maven-__plugin
>>1.0-beta-5
>>
>>  
>>download-test-data
>>prepare-package
>>
>>  download-single
>>
>>
>>  http://archive.apache.__org/dist/abdera/1.1.2/
>> 
>>  apache-abdera-1.1.2-__src.tar.gz
>>  ${project.build.__directory}/environment/qa
>>
>>  
>>
>> 
>>
>>
>>
>> For unpacking of the tar.gz you
>> On 11/8/14 7:40 PM, Kevin Burton wrote:
>>
>> I’m trying to build .debs using jdeb and maven for various
>> projects.
>>
>> For example, there is no .deb for spark.  So I’m just taking the
>> tar.gz and
>> making a deb that installs to /usr/share/apache-spark.
>>
>> The problem is I don’t want to put the full binary into git as
>> it’s about
>> 200MB.
>>
>> I’d rather have the build fetch the tar.gz directly from Apache
>> during the
>> build, untar it, then build the deb from the output.
>>
>> Is there and way to do this or should I just write a bash script
>> which uses
>> wget to fetch the URL?
>>
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] extra-enforcer-rules 1.0-beta-3 Released

[Baptiste Mathus]

Hi,

The Mojo team is pleased to announce the release of the Extra Enforcer
Rules version 1.0-beta-2.

Apache's Maven Enforcer Plugin is used to apply and enforce rules on your
Maven projects.
The Enforcer plugin ships with a set of standard rules
The Mojo project hosts this project to provide extra rules which are not
part of the standard rule set.

http://mojo.codehaus.org/extra-enforcer-rules/

To get this update, simply specify the version in your project's plugin
configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  1.3.1
  

  org.codehaus.mojo
  extra-enforcer-rules
  1.0-beta-3

  



Release Notes :
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11062&version=19724

Bug

   - [MOJO-2037] - java.lang.AssertionError: The file xyz.jar is corrupt or
   invalid

Improvement

   - [MOJO-1988] - Make excluding test dependencies configurable
   - [MOJO-2008] - Give version of the bytecode found in a bad dependency


Enjoy,

The Mojo team.

-- Baptiste

Re: Filtering resources with variables from build-helper-maven-plugin:reserve-network-port

[Baptiste Mathus]

Hi Martin,

This should be totally feasible. Indeed, even the ITs of the plugin itself
actually use the fact that properties are indeed defined to be able to
print them out at some later point.
Would you be able to expose some demo project somewhere on GitHub for
example?

Cheers

2014-09-16 13:45 GMT+02:00 Martin Todorov :

> Hi,
>
> I've been dealing with a bit of an odd scenario where i have number of
> projects running in Jenkins which all open ports for different things
> (Jetty, Derby, various other servers). So, in order for them to not clash,
> I am using the build-helper-maven-plugin's "reserve-network-port" goal
> attached to the "initialize" phases. This all works fine. However, I would
> like to use the variables for the assigned ports to filter some values in a
> few resource files. This seems to not be working.
>
> Is it at all possible to do something like this, or is this particular
> plugin running too late (or exporting the variables within a different
> context to what is visible to the maven-resources-plugin)?
>
> Thanks in advance and looking forward to your comments!
>
> Martin Todorov
>



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

Re: Build once, deploy everywhere

[Baptiste Mathus]

*that* deploy has actually nothing to do with the deploy you want. It's
only and specifically designed to push a binary produced by the building
process to some maven repository manager (say archiva, nexus or artifactory
for example).

2014-09-10 17:07 GMT+02:00 Jan :

> Thanks All.
>
> My package is not environment specific, and currently i compile and package
> using Maven, and run deployment using Ant, coz when i tried to run maven
> deploy it was using the full life cycle goals again, instead of this is
> there any way to execute just deploy and skip all other goals?
>
>
> On Wed, Sep 10, 2014 at 9:26 AM, Graham Leggett  wrote:
>
> > On 10 Sep 2014, at 10:03, Jan  wrote:
> >
> > > Does anyone using Maven as Build Once and deploy Everywhere method?
> Like
> > > lets say i don't want to recompile my source code everytime for
> different
> > > environment DEV,SIT,UAT & PROD. I want to do my compile and package
> only
> > at
> > > DEV then deploy the artifact to all mentioned environment. Is this
> > possible
> > > using Maven, is there any reference any one could share with me Please.
> >
> > We do this extensively with maven, using the maven release plugin.
> >
> > Our artifacts are in turn installable packages (rpms in our case, but
> > could be deb, whatever) which get published into a yum repository.
> >
> > The code is "promoted" from dev to test to higher environments by hard
> > linking the packages into distinct yum repos, a yum repo for each
> > environment.
> >
> > The release created by the release plugin is built just once and
> promoted.
> > The rpms are created using the rpm-maven-plugin.
> >
> > Regards,
> > Graham
> > --
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: How to get a dependency tree view of plugin dependencies used in the build

[Baptiste Mathus]

Found that, seems to match your question:
http://stackoverflow.com/a/7079876/345845.

Karl-Heinz is everywhere :-).

2014-09-10 16:50 GMT+02:00 David Hoffer :

> Similar to dependency:tree for project dependencies how can I get a similar
> list of plugin dependencies used in the build?
>
> -Dave
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: release plug in not committing the release version anymore

[Baptiste Mathus]

Hi,
This description seems to match a known issue.
I see you're using maven release plugin 2.3.2. Upgrade to 2.5 and check if
it gifts better (see https://jira.codehaus.org/browse/MRELEASE-812 for
example).

Cheers
Le 30 août 2014 23:13, "Stefano Fornari"  a
écrit :

> Hi All,
> I realized to day that since a while mvn release:prepare does not check in
> and commit the release pom. From the investigation I've done it seems that
> the pom is actually changed, a tag is correctly created but the changed pom
> never committed. Also I do not see the usual maven generated commit
> comments on git.
>
> I am attaching the entire log, even if I could not find anything
> interesting. Has anyone experienced the same problem? Any hint on how to
> troubleshoot it?
>
> Thanks in advance,
> Ste
>
> cd /home/ste/Projects/https; JAVA_HOME=/usr/lib/jvm/jdk1.7.0
> M2_HOME=/opt/apache-maven-3.1.1 /opt/apache-maven-3.1.1/bin/mvn --debug
> release:prepare
> Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17
> 17:22:22+0200)
> Maven home: /opt/apache-maven-3.1.1
> Java version: 1.7.0_05, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/jdk1.7.0/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.13.0-35-generic", arch: "amd64", family:
> "unix"
> Populating class realm maven.ext
>   Included /opt/netbeans-8.0/java/maven-nblib/netbeans-eventspy.jar
> Error stacktraces are turned on.
> Reading global settings from /opt/apache-maven-3.1.1/conf/settings.xml
> Reading user settings from /home/ste/.m2/settings.xml
> Using local repository at /home/ste/.m2/repository
> Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> /home/ste/.m2/repository
> Scanning for projects...
> Extension realms for project ste:https:jar:0.0.5-SNAPSHOT: (none)
> Looking up lifecyle mappings for packaging jar from ClassRealm[maven.ext,
> parent: ClassRealm[plexus.core, parent: null]]
> Resolving plugin prefix release from
> [com.jayway.maven.plugins.android.generation2, org.apache.maven.plugins,
> org.codehaus.mojo]
> Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> ste:https:jar:0.0.5-SNAPSHOT
> === REACTOR BUILD PLAN 
> Project: ste:https:jar:0.0.5-SNAPSHOT
> Tasks:   [release:prepare]
> Style:   Aggregating
> ===
>
> 
> Building https 0.0.5-SNAPSHOT
> 
> Resolving plugin prefix release from
> [com.jayway.maven.plugins.android.generation2, org.apache.maven.plugins,
> org.codehaus.mojo]
> Resolved plugin prefix release to
> org.apache.maven.plugins:maven-release-plugin from POM
> ste:https:jar:0.0.5-SNAPSHOT
> Lifecycle default -> [validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy]
> Lifecycle clean -> [pre-clean, clean, post-clean]
> Lifecycle site -> [pre-site, site, post-site, site-deploy]
> === PROJECT BUILD PLAN 
> Project:   ste:https:0.0.5-SNAPSHOT
> Dependencies (collect): []
> Dependencies (resolve): []
> Repositories (dependencies): [central (http://repo.maven.apache.org/maven2
> ,
> releases)]
> Repositories (plugins) : [central (http://repo.maven.apache.org/maven2
> ,
> releases)]
> ---
> Goal:  org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli)
> Style: Aggregating
> Configuration: 
> 
>   ${addSchema}
>   
> default-value="false">${allowReleasePluginSnapshot}
>default-value="false">${ignoreSnapshots}
>   ${arguments}
>default-value="false">${autoVersionSubmodules}
>   
>
>
> ${checkModificationExcludeList}
>default-value="false">${commitByProject}
>   ${completionGoals}
>   ${developmentVersion}
>   ${dryRun}
>default-value="false">${generateReleasePoms}
>   
>   ${localCheckout}
>   
>default-value="invoker">${mavenExecutorId}
>   
>   ${password}
>   ${pomFileName}
>   ${preparationGoals}
>   
>   ${pushChanges}
>   
>   ${releaseVersion}
>   ${remoteTagging}
>   ${resume}
>   ${scmCommentPrefix}
>   
>   
>default-value="false">${suppressCommitBeforeTag}
>   ${tag}
>   ${tagBase}
>   ${tagNameFormat}
>default-value="true">${updateDependencies}
>   
> default-value="true">${updateWorkingCopyVersions}
>   ${useEditMode}
>   ${username}
>default-value="0">${waitBeforeTagging}
> 
>

Re: how maven build plugins plugin use latest version

[Baptiste Mathus]

Hi,
This is not possible with maven by design. It has to do with the "build
reproducibility" thing you'll often read here.

I think there were a recent thread about that very question, also have a
look at it if you will.

Cheers
Le 27 mai 2014 10:32, "Sartisty"  a écrit :

>
> hi, all,
> I have developed a maven build plugin and I will upgrade it
> frequently. How to use the latest release version, not modify plugin
> version in pom.xml frequently? One idea is no version setting, but it
> will generate too much warnings. Setting LATEST, it won't work.
> Is there any good solution? Glad to hear it.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Invalid pom during release perform while valid during usual mvn install

[Baptiste Mathus]

Which version of the maven-release-plugin are you using?

Cheers


2014-05-21 13:54 GMT+02:00 Tomasz Borek :

> Ave!
>
> I've a problem with mvn release:perform, which fails on invalid POM and
> cuts of it's dependencies giving me compilation failure later
>
>
> *EVEN THOUGH POM is valid.*I've arrived here via:
> http://maven.apache.org/maven-release/maven-release-plugin/mail-lists.html
>
> Full problem description is available at SO:
>
> http://stackoverflow.com/questions/23546159/false-compile-error-during-mvn-releaseperform-says-invalid-pom-while-pom-is-fin
>
> I'm quite puzzled what's going on, any pointers are welcome.
>
> pozdrawiam,
> LAFK
>



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

Re: maven-invoker-plugin: running ITs in parallel?

[Baptiste Mathus]

Thanks Karl-Heinz. My current understanding is indeed that this option is
very attractive at first, but cannot currently work in practice. Having had
a quick in the code, I didn't see any IT testing this property. I'll keep
you posted about my potential findings.

Thanks


2014-05-20 18:18 GMT+02:00 Karl Heinz Marbaise :

>
> Hi Baptiste,
>
> I'm working often with maven-invoker and have found an issue with
> parallelThreads option (http://jira.codehaus.org/browse/MINVOKER-147).
>
> The local shared repos is also a problem.
>
> The should be something like a repo per IT...
>
> Kind regards
> Karl-Heinz Marbaise
>
> > *TL;DR: does anyone use the parallelThreads option in
> maven-invoker-plugin?
>
>> Do you also have issues with concurrent local repository access? If so,
>> how
>> do you solve them?*
>>
>>
>> I've recently come across the parallelThreads option in
>> maven-invoker-plugin. After having tried to use it a few times, I'm
>> currently stuck.
>>
>> It fails randomly, and not surprisingly it seems like it comes from the
>> fact the local-repo is shared between ITs. While downloading from the MRM,
>> there's always one jars that fails to be written to the disk because of a
>> likely concurrent access.
>>
>> My first thought was to try and have a separate localRepository per IT.
>> But
>> I can't find a property or even a workaround to do that.
>>
>> Because filing an issue to m-invoker-p, I wanted to check here if I was
>> missing something.
>>
>
> -----
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

Re: maven-invoker-plugin: running ITs in parallel?

[Baptiste Mathus]

IIUC your proposition is to play with defining  value to
variabilize the value with the current project?
Unfortunately I don't think this is gonna work since  is
actually totally ignored by design. You define  once
directly in the m-invoker-p configuration block in the pom.xml.


2014-05-20 15:09 GMT+02:00 Stephen Connolly :

> Eh you might be able to...
>
> you could have the "local repo" that m-i-p "installs" into be a "remote"
> repo in your settings.xml (along with the mrm repo) and then use ${basedir}
> in the localrepo path...
>
> (Untested)
>
>
> On 20 May 2014 13:08, Baptiste Mathus  wrote:
>
> > Yup, I know this work is still underway, no problem. I realize I wasn't
> > clear enough (and my TL;DR may have been be misleading).
> >
> > I was also wondering if there was a workaround where you could define a
> > specific path *per it* for the local repository. But unfortunately from a
> > quick look at InvokerMojo.java I don't think it is possible.
> >
> > Thanks for your feedback.
> >
> >
> > 2014-05-20 13:51 GMT+02:00 Kristian Rosenvold <
> > kristian.rosenv...@gmail.com>
> > :
> >
> > >
> > > AFIK this is one is unsolved. We have a number of kludges that involve
> > > resolving all the required deps to the local repository *before*
> > > starting the parallel process, at least 2 og 3 projects do it this
> > > way. As far as I understand solving concurrent thread safe repo in the
> > > latest maven version should be trivial, but it needs to be solved in
> > > the core.
> > >
> > > Kristian
> > >
> > >
> > > 2014-05-20 9:13 GMT+02:00 Baptiste Mathus :
> > > > Hi all,
> > > >
> > > > *TL;DR: does anyone use the parallelThreads option in
> > > maven-invoker-plugin?
> > > > Do you also have issues with concurrent local repository access? If
> so,
> > > how
> > > > do you solve them?*
> > > >
> > > > I've recently come across the parallelThreads option in
> > > > maven-invoker-plugin. After having tried to use it a few times, I'm
> > > > currently stuck.
> > > >
> > > > It fails randomly, and not surprisingly it seems like it comes from
> the
> > > > fact the local-repo is shared between ITs. While downloading from the
> > > MRM,
> > > > there's always one jars that fails to be written to the disk because
> > of a
> > > > likely concurrent access.
> > > >
> > > > My first thought was to try and have a separate localRepository per
> IT.
> > > But
> > > > I can't find a property or even a workaround to do that.
> > > >
> > > > Because filing an issue to m-invoker-p, I wanted to check here if I
> was
> > > > missing something.
> > > >
> > > > Thanks for your help.
> > > >
> > > > -- Baptiste
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>



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

Re: maven-invoker-plugin: running ITs in parallel?

[Baptiste Mathus]

Yup, I know this work is still underway, no problem. I realize I wasn't
clear enough (and my TL;DR may have been be misleading).

I was also wondering if there was a workaround where you could define a
specific path *per it* for the local repository. But unfortunately from a
quick look at InvokerMojo.java I don't think it is possible.

Thanks for your feedback.


2014-05-20 13:51 GMT+02:00 Kristian Rosenvold 
:

>
> AFIK this is one is unsolved. We have a number of kludges that involve
> resolving all the required deps to the local repository *before*
> starting the parallel process, at least 2 og 3 projects do it this
> way. As far as I understand solving concurrent thread safe repo in the
> latest maven version should be trivial, but it needs to be solved in
> the core.
>
> Kristian
>
>
> 2014-05-20 9:13 GMT+02:00 Baptiste Mathus :
> > Hi all,
> >
> > *TL;DR: does anyone use the parallelThreads option in
> maven-invoker-plugin?
> > Do you also have issues with concurrent local repository access? If so,
> how
> > do you solve them?*
> >
> > I've recently come across the parallelThreads option in
> > maven-invoker-plugin. After having tried to use it a few times, I'm
> > currently stuck.
> >
> > It fails randomly, and not surprisingly it seems like it comes from the
> > fact the local-repo is shared between ITs. While downloading from the
> MRM,
> > there's always one jars that fails to be written to the disk because of a
> > likely concurrent access.
> >
> > My first thought was to try and have a separate localRepository per IT.
> But
> > I can't find a property or even a workaround to do that.
> >
> > Because filing an issue to m-invoker-p, I wanted to check here if I was
> > missing something.
> >
> > Thanks for your help.
> >
> > -- Baptiste
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

maven-invoker-plugin: running ITs in parallel?

[Baptiste Mathus]

Hi all,

*TL;DR: does anyone use the parallelThreads option in maven-invoker-plugin?
Do you also have issues with concurrent local repository access? If so, how
do you solve them?*

I've recently come across the parallelThreads option in
maven-invoker-plugin. After having tried to use it a few times, I'm
currently stuck.

It fails randomly, and not surprisingly it seems like it comes from the
fact the local-repo is shared between ITs. While downloading from the MRM,
there's always one jars that fails to be written to the disk because of a
likely concurrent access.

My first thought was to try and have a separate localRepository per IT. But
I can't find a property or even a workaround to do that.

Because filing an issue to m-invoker-p, I wanted to check here if I was
missing something.

Thanks for your help.

-- Baptiste

Re: Truncating SCM/Git URL for tagging only

[Baptiste Mathus]

Which version of the maven release plugin are you using? I'd check with at
least 2.4.2 or 2.5 since known issues with Git have been fixed in those
versions.
Le 13 mai 2014 03:07, "Neil Hunt"  a écrit :

> For some reason, when running maven release, it is giving me an invalid
> URL just for the tagging part of the push. For the pom.xml commit/push, it
> works fine and goes to appropriate URL. See below:
>
>
>
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
>
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git commit --verbose -F
> /tmp/maven-scm-217365030.commit '/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-services/pom.xml'
> '/opt/jenkins-home/jobs/Section 4362/workspace/section4362-webapp/pom.xml'
> '/opt/jenkins-home/jobs/Section 4362/workspace/section4362-static/pom.xml'
> pom.xml
>
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git symbolic-ref HEAD
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent" && git push ssh://
> g...@github.com/{org}/Section4362.git maven-release-test:maven-release-test
> [INFO] Working directory: /opt/jenkins-home/jobs/Section
> 4362/workspace/section4362-parent
> [INFO] Tagging release with the label section4362-parent-0.3...
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace" && git tag -F /tmp/maven-scm-882610155.commit
> section4362-parent-0.3
> [INFO] Working directory: /opt/jenkins-home/jobs/Section 4362/workspace
> [INFO] Executing: /bin/sh -c cd "/opt/jenkins-home/jobs/Section
> 4362/workspace" && git push ssh://g...@github.com/{org}section4362-parent-0.3
> [INFO] Working directory: /opt/jenkins-home/jobs/Section 4362/workspace
>
> You can see that for the push after the commit, it pushes to ssh://
> g...@github.com/{org}/Section4362.git ({org} scrubbed by me), whereas for
> the push after the tag, it goes to ssh://g...@github.com/{org} - URL
> should include /Section4362.git at the end. All my pom files specify the
> correct: scm:git:ssh://g...@github.com/{org}/Section4362.git
>
> How would URL be changing for tag push and where would it get it from?
> Build is obviously failing at that step saying unable to connect to repo.
>

Re: [ANN] buildnumber-maven-plugin 1.3 Released

[Baptiste Mathus]

Just a small guess: if you're using a versioning control system (svn,git it
mercurial supported), the build number won't indeed change if you're
building the same source code many times: it will reflect the current state
of your tree (say revision for svn, or sha-1 for Git).

HTH
Cheers
Le 3 mai 2014 18:46, "Karl Heinz Marbaise"  a écrit :

>
> Hi Bruce,
>
>
> > Hi,
>
>>
>> How does this work? I tried twice but the build number is still the same.
>>
> What does this mean?
>
> What did you tried? Can you show the pom file you used? Can you show the
> output you've got?
>
> Kind regards
> Karl-Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] buildnumber-maven-plugin 1.3 Released

[Baptiste Mathus]

Hi,

The Mojo team is pleased to announce the release of the
buildnumber-maven-plugin version 1.3.

This mojo is designed to get a unique build number for each time you build
your project. So while your version may remain constant at 1.0-SNAPSHOT for
many iterations until release, you will have a build number that can
uniquely identify each build during that time.

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

To get this update, simply specify the version in your project's plugin
configuration:

org.codehaus.mojo
 buildnumber-maven-plugin< /artifactId>
1.3


Release Notes
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12124&version=18855

Enjoy,

The Mojo team.

-- Baptiste

RE: ForkedBooter in 2.2.1 does not honor MAVEN_OPTS

[Baptiste Mathus]

Yes, it does not isolate your tests from your main maven build. So if for
example your tests require too much memory, the OOME will kill the whole
maven build.

BTW, as maven 2.x is in the title, you should be aware it's now
deprecated/end of life.

Cheers
Le 25 avr. 2014 03:22, "victropolis"  a écrit :

>
> Is there any downside to using never?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/ForkedBooter-in-2-2-1-does-not-honor-MAVEN-OPTS-tp5764410p5791911.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: Unpacking a zip file from the source tree

[Baptiste Mathus]

There's an ongoing issue at The Codehaus about login/account creation
complexity. IIUC this was done after some heavy spamming attack.
Anyway, to create an account go to http://xircles.codehaus.org/ and with
that account you'll be able to access and create issues in jira.codehaus.org
.

Cheers


2014-04-19 20:22 GMT+02:00 :

>
> On Sat, 19 Apr 2014 09:36:13 -0700
> Dan Tran  wrote:
>
> > Hi,
> >
> > Could you file a Jira case against truezip-m-p with a producible pom?
>
> 'Lo.
>
> I can't seem to find the registration link to allow me to post issues on
> the Truezip Jira. The login prompt says "To request an account, please
> contact your JIRA administrators"...
>
> M
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

Re: Unpacking a zip file from the source tree

[Baptiste Mathus]

May maven-remote-resources-plugin be helping?


2014-04-18 12:10 GMT+02:00 :

>
> Hello.
>
> I have a zip file in the src directory of a project. I want to unpack
> this zip file and insert the contents into the generated site directory
> during the site phase.
>
> What is the correct way to do this?
>
> There's the "dependency:unpack" goal, but that only seems capable of
> working with dependencies (which this zip file isn't). There's the
> TrueZip plugin, but quite frankly, it seems defective (it silently
> fails to do anything, and the documentation is no help at all).
>
> M
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

Re: Strange maven central response - do you see the same thing??

[Baptiste Mathus]

FWIW, just tried from Toulouse, France:
http://repo.maven.apache.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexeindeed
redirects to
http://central.maven.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/

HTH


2014-04-18 11:03 GMT+02:00 Mirko Friedenhagen :

> I guess Karl-Heinz and I are accessing from Germany, so maybe there is some
> routing problem on your side?
>
> Regards
> Mirko
> --
> Sent from my mobile
> On Apr 18, 2014 10:27 AM, "Dan Tran"  wrote:
>
> > My browser cannot even browse those links.  perhaps my virus checker is
> > culprit?
> >
> > It is a strange day!
> >
> > -D
> >
> >
> > On Fri, Apr 18, 2014 at 1:14 AM, Mirko Friedenhagen <
> > mfriedenha...@gmail.com
> > > wrote:
> >
> > > Same for me, repo.maven.apache.org redirects to central.maven.org with
> > the
> > > given URL.
> > >
> > > Regards
> > > Mirko
> > > --
> > > Sent from my mobile
> > > On Apr 18, 2014 10:09 AM, "Karl Heinz Marbaise" 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > if i try the given URL:
> > > > > http://repo.maven.apache.org/maven2/org/apache/maven/scm/
> > > > maven-scm-provider-cvsexe
> > > >
> > > > I'm redirected to :
> > > >
> > > > http://central.maven.org/maven2/org/apache/maven/scm/
> > > > maven-scm-provider-cvsexe/
> > > >
> > > > ..
> > > >
> > > > Kind regards
> > > > Karl-Heinz Marbaise
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: Generating Incorrect fat jar using maven-assembly-plugin in maven 2 with war packaging

[Baptiste Mathus]

Hi,
Which version of the war plugin are you using?

BTW, you say it's OK with maven 3. Can't you just upgrade? Maven 2 is many
years old and has already been officially end of lifed (
http://maven.apache.org/maven-2.x-eol.html).

And about what you're doing: I'm unsure about why you seem to unnecessarily
try to package a fat jar although your target is a war?

Cheers
Le 16 avr. 2014 00:44, "Narayanan Krishnamoorthy"  a
écrit :

> Hi all,
>
> I have a default pom file in our codebase that has "war" packaging.
>
> We wanted to also generate a normal jar file (lean) and a fat jar with
> dependencies along with the war file in our build using the same pom.xml.
>
> $ mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.7.0_45
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x" version: "10.8.5" arch: "x86_64" Family: "mac"
>
> We added the following plugins - maven–assembly-plugin to generate the far
> jar and maven-jar-plugin to generate the lean jar.
>
>
> 
> maven-assembly-plugin
> 
> 
>
> jar-with-dependencies
> 
> 
> 
> 
> assembly-all
> package
> 
> single
> 
> 
> 
> 
>
>   
>   org.apache.maven.plugins
>   maven-jar-plugin
>   
>   
>   make-a-jar
>   compile
>   
>   jar
>   
>   
>   
>   
>
> On mvn clean install,
> It is generating all the 3 files : war, lean jar and far jar.
>
> But the problem is the jar-with-dependencies (fat jar) generated is
> getting built in the wrong way. Its size becomes double that of the same
> jar built by using Maven 3.0.4 (yes, I tried upgrading the maven to 3.0.4
> to test and everything is good
> With maven 3).
>
> The problem is only with maven 2 and to me it looks like since the overall
> packaging phase of the pom is war , it is generating a wrong fat jar using
> the maven-assembly-plugin.  Many src classes are missing from the fat jar.
>
> Anyone faced this issue with maven 2 and war packaging. Maven 3.0.4 is
> just fine while generating the fat jar.
>
> Does maven-assembly-plugin have some restrictions with maven 2 and war
> packaging ?
>
> Is there an alternate plugin to generate a jar with dependencies other
> than maven-assembly-plugin ?
>
> Thanks in advance
> Narayanan
>
>

Re: Maven Download and Regular Expression

[Baptiste Mathus]

Hi,
Have a look at Maven indexer?
Cheers
Le 9 avr. 2014 03:40, "MukeshKumar Bhansali" <
mukeshkumar.bhans...@amdocs.com> a écrit :

> Hi Folks,
> I have a different requirement and not getting any hint.
>
> The Requirement is like :
>
> I want to download an artifact from Nexus using Maven, But I have
>
>
> 1)  groupId
>
> 2)  version
>
> 3)  Partial artifactId ( prefix and suffix of artifactId means not the
> exact one)
>
>
> Example :
> In case of this artifact :
>
> groupId :  org.nihiocs.hudson.plugins
> artifactId :   jobTreeMaker
> version :   main
>
> I have following information
>
> groupId :  org.nihiocs.hudson.plugins
> artifactId :   job*Maker (Prefix and Suffix)
> version :   main
> So in this case how I can download this artifact ?
>
> It is also ok if I downloads entire
> org/nihiocs/Hudson/plugins  ( org.nihiocs.hudson.plugins ) Directory.
>
> I like it to done by maven only but it is ok if ant comes in action.
>
> Thanks.
>
>
> MUKESH KUMAR BHANSALI
>
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Scanning for Projects... before

[Baptiste Mathus]

You're very likely to send some day an old version of a false releases,
actually a snapshot, to production with this technique.
I guess you should at least send a mail to some managers to explain things
are going to go wrong some day. At least you will have taken your
responsibility and they can't pretend it's your fault.

Also, I hope nobody will ever use a vanilla version of Maven on their dev
box since they're never going to get the rotten new releases downloaded :-/.


2014-04-04 9:06 GMT+02:00 eugene :

> Christian, you have no idea how much I wish this were a possibility, but
> this is the way the company has handled things for years.
> Changing this behavior would mean a revolution in their understanding,
> and I sure do not want to start one just yet. :)
>
> There is a much cooler way  to do it actually... since we have Jenkins
> that builds the jobs (way too many to hook a pre-build event on them
> directly), we could implement an Extension Point for the Maven Reporter
> Plugin that has one called PreBuild - the only problem is that it works
> only for Maven 2 from what I tested. I asked their forums about this
> issue, no response so far.
>
> On 4/4/14, 9:59 AM, Christian Domsch [via Maven] wrote:
> > Well that is essentially a *very* basic way of my CI approach :) But it
> > means you have to do it everywhere you have maven installed and need
> > that behaviour. Also has the drawback of injecting this behaviour in any
> > maven runs.
> >
> > So, as mentioned before a few times: switch to some standard use of
> > maven :)
> >
> > On 04.04.2014 08:55, eugene wrote:
> >
> > > I think we have found one...
> > >
> > > We can create a wrapper around MavenCli and replace it in m2.conf...
> > >
> > > On 4/2/14, 8:35 PM, Wayne Fay [via Maven] wrote:
> > >>>> repo unless their are snapshots, right? Well snapshot is not an
> > option
> > >>>> right now (due to corporate things).
> > >>> It is one of Maven's cardinal assumptions that release versions are
> > >>> immutable. If you need different contents, use either: A) a different
> > >> As Curtis already mentioned, you are unlikely to find a solution by
> > >> continuing to head in this direction. Find another approach - most
> > >> likely one that involves a process running outside of Maven before
> > >> your build kicks off.
> > >>
> > >> Wayne
> > >>
> > >> -
> > >> To unsubscribe, e-mail: [hidden email]
> > >> 
> > >> For additional commands, e-mail: [hidden email]
> > >> 
> > >>
> > >>
> > >>
> > >>
> > 
> > >> If you reply to this email, your message will be added to the
> > >> discussion below:
> > >>
> >
> http://maven.40175.n5.nabble.com/Scanning-for-Projects-before-tp5790393p5790420.html
> > >>
> > >> To unsubscribe from Scanning for Projects... before, click here
> > >> <
> > >> NAML
> > >>
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
> > >>
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> http://maven.40175.n5.nabble.com/Scanning-for-Projects-before-tp5790393p5790474.html
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> >
> > 
> > If you reply to this email, your message will be added to the
> > discussion below:
> >
> http://maven.40175.n5.nabble.com/Scanning-for-Projects-before-tp5790393p5790475.html
> >
> > To unsubscribe from Scanning for Projects... before, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5790393&code=ZXVnZW4ucmFiaWlAZ21haWwuY29tfDU3OTAzOTN8MTA1NjEzNjg3MA==
> >.
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Scanning-for-Projects-before-tp5790393p5790476.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>



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

Re: Enforcer plugin

[Baptiste Mathus]

Not sure I understand: did you use a standard rule or did you finally write
& use your own one? If the latter, seing the code somewhere may help. If
using a standard one, then creating a testcase project is definitely the
best way to get answers and then the potential fix.

Cheers


2014-04-03 4:22 GMT+02:00 Mark Eggers :

>
> On 4/2/2014 5:25 PM, Mark Eggers wrote:
>
>> Folks,
>>
>> I've gotten my classifier artifact to build and install in our local
>> repository. Specifying the classifier gets the appropriate artifact, and
>> removing the classifier gets the [other] appropriate artifact.
>>
>> Now I'm a bit paranoid that the artifact with the classifier will leak
>> out into other releases, so I thought I would write an enforcer rule.
>>
>> I thought that the following would work:
>>
>> 
>>  
>>  org.mdeggers:*:*:*:*:DEBUG
>>  
>> 
>>
>> based on:
>>
>> http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
>>
>> While this certainly blocked the following dependency:
>>
>> 
>>  org.mdeggers
>>  SampleBuild
>>  1.5
>>  war
>>  DEBUG
>> 
>>
>> with the message:
>> Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5
>>
>> It also blocked the following dependency:
>>
>> 
>>  org.mdeggers
>>  SampleBuild
>>  1.5
>>  war
>> 
>>
>> with the message:
>> Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5
>>
>> This I did not expect. The messages are also a bit suspect in that they
>> don't match the pattern given in the documentation.
>>
>> I looked on JIRA and found the following (based on another thread):
>>
>> http://jira.codehaus.org/browse/MENFORCER-74
>> http://jira.codehaus.org/browse/MENFORCER-75
>> http://jira.codehaus.org/browse/MENFORCER-72
>>
>> These are all closed with a 'fixed' designation for release 1.3.
>>
>> I'm using version 1.3.1
>>
>> However, I briefly looked at the code here:
>>
>> http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-
>> 1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins/
>> enforcer/BannedDependencies.java?revision=1502671&view=markup
>>
>>
>> and classifier does not seem to have made it in.
>>
>> Have I walked through this correctly? If so, is there a fix (other than
>> not using classifiers, or just hoping that a DEBUG classifier doesn't
>> make it into a release)?
>>
>> Thanks,
>> Mark
>>
>> /mde/
>>
>
> Works with 2.0-SNAPSHOT of the maven enforcer plugin.
>
>
> /mde/
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

Re: Javadoc plugin with Javadoc 8: error fetching URLs

[Baptiste Mathus]

Just a guess: Maven basically only delegates to the javadoc tool provided
by the JDK. Did you try without Maven?
Java 8's javadoc has been added a much more stringent parser, so you might
be encountering
http://blog.joda.org/2014/02/turning-off-doclint-in-jdk-8-javadoc.html ?


2014-03-28 22:15 GMT+01:00 Laird Nelson :

> Running a few of my projects under Java 8, I found that the
> maven-javadoc-plugin won't accept  configuration items that work
> under Javadoc 6.
>
> For example, I have this:
>
> http://mvel.codehaus.org/javadoc/2.0
>
>
> With Javadoc 8 installed, whatever the maven-javadoc-plugin is doing to
> feed this URL to javadoc isn't working and I get:
>
> [WARNING] javadoc: warning - Error fetching URL:
> http://mvel.codehaus.org/javadoc/2.0
>
>
> This works fine using Javadoc 6.
>
> Is this a known issue, or should I file a bug?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>



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

Re: Overriding dependency scope

[Baptiste Mathus]

IIUC, you have a unique parent pom (likely a "corporate pom"), let's can
him P. P says scope is test for groovy-all.

You have modules m1, m2... who all inherits P.

In some module mN, you need groovy-all with scope compile.

But m1 actually depends on mN and will crash since the dependency onto
groovy-all isn't retrieved?

If so, then this is expected. Dependency mgmt overrides the dependencies
scope. One possible solution to centralize many redefinitions is to create
an intermediate parent for those modules where you need groovy-all with
scope compile.
I think that's what Mirko was proposing.

Does that help?
Le 28 mars 2014 15:08, "Mirko Friedenhagen"  a
écrit :

> Alexander,
>
> AFAIK you may override the scope in the inheriting poms. If I remember
> correctly I did this with junit as I needed it for an selenium test
> project, where I had put base tests beneath src/main (to recite Brecht: oh,
> don't ask why).
>
> Regards
> Mirko
> --
> Sent from my mobile
> On Mar 28, 2014 2:59 PM, "Alexander Kriegisch" 
> wrote:
>
> > I have a situation as follows:
> >
> >   - Multi-module project (~30 modules)
> >
> >   - Certain test dependencies (e.g. groovy-all) needed by nearly all
> > sub-modules are declared directly with test scope in the parent POM
> > (not just dependencyManagement, but also dependency). I know this is
> > considered to be bad practice but it saves a lot of redundant
> > dependency duplication.
> >
> >   - One new sub-module now actually also needs groovy-all, but with a
> > compile scope. So my wish (although seemingly unsupported by Maven)
> > is to override the default scope for this sub-module so as for the
> > dependency to be actually available during runtime.
> >
> > How can I do this or work around the need to duplicate my test
> > dependencies in 30 modules just so as to be able to define the scope for
> > the new module? AFAIK a POM can only inherit from one POM. But can I
> > somehow use an "included POM" in my 30 modules in order to be able to
> > centrally manage the test dependencies? Sorry if I am explaining this
> > wrong or using incorrect erms, but I am by no means a Maven pro.
> > Hopefully I was at least able to make my intent clear. I am looking for
> > good advice beyond lecturing about how I should really, really declare
> > everything 30 times in order to do it the Maven way. I am looking for
> > alternatives, am willing to learn and hoping to get constructive answers.
> >
> > Thanks you all in advance
> > --
> > Alexander Kriegisch
> >
> >
> >
>

Re: OutOfMemoryError with maven-javadoc-plugin

[Baptiste Mathus]

Did you make sure you put -J-Xmx and not only -Xmx ?


2014-03-28 12:24 GMT+01:00 Martin Hoeller :

> Hi Baptiste!
>
> I tried it but it didn't change anything. Still OutOfMemoryError :(
>
> -martin
>
> On 28 Mär 2014, Baptiste Mathus wrote:
>
> > Sorry, I haven't used javadoc for years now, but as javadoc is an
> external
> > tool, I guess you should specify additionalJOption?
> >
> http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalJOption
> >
> > Cheers
> >
> >
> > 2014-03-28 10:36 GMT+01:00 Martin Hoeller :
> >
> > > Hi!
> > >
> > > I have a quite large multimodule project with >150 modules. When
> > > executing "mvn site" the maven-javadoc-plugin is executed with default
> > > configuration. After some time of execution it fails in "aggregate"
> goal
> > > and I get a
> > >
> > >   Exception in thread "main" java.lang.OutOfMemoryError: GC overhead
> limit
> > > exceeded"
> > >
> > > I know, I can adjust MAVEN_OPTS to give it more memory and I tried it
> with
> > > MAVEN_OPTS="-Xmx1536m -Xms512m -XX:MaxPermSize=512m" and with
> > > MAVEN_OPTS="-Xmx1280m -Xms256m -XX:MaxPermSize=768m". Both just leading
> > > to another OutOfMemoryError (but no GC overhead limit exceeded).
> > >
> > > I'm currently using maven 3.1.1 and tested with m-javadoc-p 2.8 and
> 2.9.1
> > > (no difference).
> > >
> > > So my question is: does any body have some idea how to tweak parameters
> > > to solve this issue?
> > >
> > > My current workaround is to disable aggregation in  section
> as
> > > described here [0]. But this is really just a workaround, no solution
> :(
> > >
> > > thx for your help,
> > > - martin
> > >
> > > [0]
> > >
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective-javadocs-report.html
> > >
> >
> >
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
>
>
> --
> Martin Höller   | martin.hoel...@xss.co.at
> *x Software + Systeme   | http://www.xss.co.at/
> Karmarschgasse 51/2/20  | Tel: +43-1-6060114-40
> A-1100 Vienna, Austria  | Fax: +43-1-6060114-71
>



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

Re: maven release-plugin 2.5 bug - releasing snapshots...

[Baptiste Mathus]

Weird, many users reported the 2.5 had fixed their issues.

What (version) are you actually using for:
* maven
* maven-release-plugin (triple-check you hadn't redefined maven-scm-*
dependency somewhere)
* svn ? Git ? Something else ?

On a unrelated subject : issuing a "mvn clean install deploy" command shows
a tiny misunderstanding of how Maven works. You're asking maven to install
twice (said differently "deploy" already includes the steps from "install").

Cheers


2014-03-28 10:59 GMT+01:00 ghostwolf59 
:

> Hi,Occasionally we have a need to perform a formal release on unfinished
> work
> so it can be tracked.These snapshot releases would in effect be releases
> identical to a formal release with the exception that the snapshot for a
> set
> release is tagged with a time stamp when released into archiva's snapshot
> repository.We used to get around this by issuing the mvn clean
> release:prepare release:perform where we overwrite the proposed/suggested
> release at the prompt by qualifying the release number followed by
> appending
> "-SNAPSHOT"The build would be done identical to a formal release where the
> scm branch is created for the snapshot in  our svn source repo and the
> built
> snapshot would be released into our internal "snapshot" repo (oppose to
> formal non snapshot releases that ends up in the "releases" repo)This used
> to work really well but recently I don't seem to be able to overwrite the
> version at the prompt - when I do it simple prompts me again
> <
> http://maven.40175.n5.nabble.com/file/n5789837/release-version-prompt-v.2.5.jpg
> >
> It's a weird one - this have been proven to be working previously but
> suddenly it don't seem to work any more.The release plugin i currently use
> is v2.5 - in the past I used v 2.2.2 successfully.By reverting back to
> v2.2.2 of org.apache.maven.plugins.maven.release-plugin this work perfectly
> <
> http://maven.40175.n5.nabble.com/file/n5789837/release-version-prompt-v2.2.2.jpg
> >
> Is this a known issue and is it linked to v2.5 of the maven release plugin
> ?I can do snapshot releases using mvn clean install deploy but that would
> not branch tag the source and would not generate site infoBottom line -
> does
> anyone know how this can be done using the most recent
> maven-release-plugin?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: OutOfMemoryError with maven-javadoc-plugin

[Baptiste Mathus]

Sorry, I haven't used javadoc for years now, but as javadoc is an external
tool, I guess you should specify additionalJOption?
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#additionalJOption

Cheers


2014-03-28 10:36 GMT+01:00 Martin Hoeller :

> Hi!
>
> I have a quite large multimodule project with >150 modules. When
> executing "mvn site" the maven-javadoc-plugin is executed with default
> configuration. After some time of execution it fails in "aggregate" goal
> and I get a
>
>   Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
> exceeded"
>
> I know, I can adjust MAVEN_OPTS to give it more memory and I tried it with
> MAVEN_OPTS="-Xmx1536m -Xms512m -XX:MaxPermSize=512m" and with
> MAVEN_OPTS="-Xmx1280m -Xms256m -XX:MaxPermSize=768m". Both just leading
> to another OutOfMemoryError (but no GC overhead limit exceeded).
>
> I'm currently using maven 3.1.1 and tested with m-javadoc-p 2.8 and 2.9.1
> (no difference).
>
> So my question is: does any body have some idea how to tweak parameters
> to solve this issue?
>
> My current workaround is to disable aggregation in  section as
> described here [0]. But this is really just a workaround, no solution :(
>
> thx for your help,
> - martin
>
> [0]
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective-javadocs-report.html
>



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

Re: centralized settings.xml vs local question

[Baptiste Mathus]

Couldn't you set up a tailored release job in your CI server. Then you
would had handle authorizations there?
This is somehow what we do. And developers all have the same settings.xml
file.

HTH
 Le 24 mars 2014 00:34, "ghostwolf59" 
a écrit :

>
> Hi,
> I am a strong advocate of maven & Archiva where I administer our
> departments
> archiva & svn and site server server where we use maven to build/release
> stuff.
>
> I don't claim to be an expert in the field (but I am not completely dumb
> either when it comes to this :) - so if my question is silly please don't
> knock me to bad :)
>
> The way we currently go about setting up new developers centers around the
> following...
>
> Each developer ensure they configure their client to point to a set maven
> release (currently 3.0.4)
>
> Each developer will then have a unique personal account created in archiva
> giving them the appropriate access to release or not
>
> As part of this I manually encrypt this archiva user psw using mvn
> --encrypt-password 
> where I create a tailored settings.xml where I add the encrypted password
> to
> each repo they are meant to have release access to (all developers can
> access resources to do local builds as guest - but only authorized users
> can
> do official releases *(prod state) )
>
> The problem I have with this is 1. many settings.xml to manage 2. problems
> or global changes may affect every single developer resulting in that I
> need
> to roll out new settings.xml to each developers.
>
> My simply question is ... Can this be centralized somehow meaning that the
> clients settings.xml somehow refers to groups located on the remote archiva
> server
>
> If this were possible I would cut down the maintenance and remove the
> hassle
> of distributing tailored settings.xml when people come on board.
>
> I can not accept a scenario where each developer uses the same global
> credentials
>
> cheers
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/centralized-settings-xml-vs-local-question-tp5789050.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: properties that are not being resolved

[Baptiste Mathus]

Hi,
Out of curiosity, why don't you use the seemingly equivalent mojo
buildnumber maven plugin? May not be your issue, but may be the plugin
you're using doesn't create properties in the right way (no offense, just
trying to guess)?
My 2 cents
Le 23 mars 2014 22:37, "Henrik Østerlund Gram"  a
écrit :

> I stumbled over some rather strange behaviour regarding properties.  It
> seems properties generated by one plugin are not always resolved for other
> plugins and I can't figure out why.
>
> I use a plugin to make info about the git branch available in the
> properties so it can be passed to other plugins.  The particular plugin
> does not seem important, but I've included it here for sake of
> completeness:
>
> 
> com.code54.mojo
> buildversion-plugin
>  1.0.3
> 
> .MM.dd HH:mm
>  
> 
> 
>  
> set-properties
> 
>  
> 
> 
>
> But when I referenced the properties set by the plugin in an env entry for
> the maven ear plugin, the properties were not resolved at all:
>
> 
> 
> Middleware build information
>  java:app/env/sw-version
> java.lang.String
>  ${build-commit} @ ${build-tstamp} built on
> ${maven.build.timestamp}
> 
> 
>
> Just to be sure, I used the latest maven and tried both version 2.9 of the
> plugin and the latest from the repo with the same result.
>
> The only way I managed to fix this was to patch the maven-ear-plugin
> itself, adding the following code in GenerateApplicationXmlMojo.execute():
>
> // Fix env variable substitutions
> Properties props = project.getProperties();
> PlexusConfiguration[] entries = envEntries.getChildren();
> if (entries != null) {
> for (PlexusConfiguration entry : entries) {
> if ("env-entry".equals(entry.getName())) {
> PlexusConfiguration[] envEntryChildren = entry.getChildren();
> if (envEntryChildren != null) {
> for (PlexusConfiguration envEntryChild : envEntryChildren)
> {
>
> envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> props));
> }
> }
> }
> }
> }
>
> Then it worked just fine, but I don't understand why this is necessary.  I
> thought whatever called the plugin was supposed to have done the variable
> substitution already.  So clearly the properties were present at the time
> of executing the plugin, but they werent being automaticly substituted.
>
> To add to the confusion, using ${project.version} in the env-entry-value
> was resolved just fine, but just not the properties coming from another
> plugin despite the plugins being run in the correct order.
>
> To further add to the confusion, I then used maven ant-run plugin, echoing
> the values of properties which worked just fine (!)
>
> While I solved the problem for me by making a locally patched version of
> the ear plugin, it's not really a solution I favour, so I hope someone can
> provide a better and more permanent fix.
>
> Regards,
> Henrik Gram
>

Re: The par packaging not working

[Baptiste Mathus]

Hi,

Out of curiosity, what's a par packaging? The only links I found on the Web
talks about perl, are they perl archive or so?

Just had a quick at https://maven.apache.org/plugins/ and didn't find
anything related to par. I've personnally never heard of it. Can you
provide us with more details?

Cheers


2014-03-20 14:30 GMT+01:00 lilyevsky :

>
> The "par" packaging is not working. It is dependent on the
> org.apache.maven.plugins:maven-par-plugin, but this plugin does not exist.
> Is it deprecated?
> I am using the latest maven 3.2.1.
> How should I make the par package these days? I know this thing is
> relatively simple: just a collection of jars plus manifest with a few
> special entries. But I don't want to re-invent the wheel.
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/The-par-packaging-not-working-tp5788937.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
>
>


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

Re: [ANN] Apache Maven PMD Plugin 3.1 Released

[Baptiste Mathus]

I think this is related to
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html

Can you try just moving your pmd configuration inside  tag?
Also make sure you update maven-site-plugin version to the latest version.

Btw, if you're from maven 2 to maven 3, far better use the latest 3.2.1.

Cheers


2014-03-19 12:13 GMT+01:00 Krithika Shanmugam :

>
>
>
> Dennis Lundberg  apache.org> writes:
>
> >
> > The Maven team is pleased to announce the release of the Apache Maven PMD
> Plugin, version 3.1
> >
> > A Maven plugin for the PMD toolkit, that produces a report on both code
> rule violations and detected copy and paste
> > fragments,
> > as well as being able to fail the build based on these metrics.
> >
> > http://maven.apache.org/plugins/maven-pmd-plugin/
> >
> > You should specify the version in your project's plugin configuration:
> >
> > 
> >   org.apache.maven.plugins
> >   maven-pmd-plugin
> >   3.1
> > 
> >
> > Release Notes - Apache Maven PMD Plugin - Version 3.1
> >
> > Bug
> > * [MPMD-179] Plugin generates reports incompatible with the 'maven-jxr-
> plugin' version 2.4
> > * [MPMD-176] upgrade to last 5.0.5
> > * [MPMD-172] Warning about missing XRef for module with no source
> > * [MPMD-168] Skip report generation if results are empty
> > * [MPMD-167] CPD performance issues
> > * [MPMD-166] Plugin fails when switching from 2.7.1 to 3.0.1
> >
> > Improvement
> > * [MPMD-180] Remove redundant "Report" word on report name labels
> > * [MPMD-175] Work around PMD bug #1155 which crashes the plugin with an
> empty ruleset element.
> > * [MPMD-169] Support multi-threaded mode of PMD 5
> >
> > New Feature
> > * [MPMD-181] Add flag to capture Benchmark information
> >
> > Enjoy,
> >
> > -The Maven team
> >
>
>
> Hi,
>
> I've written one custom PMD rule and integrated with Jenkins. Maven build
> version was 2.2.1. But if the Maven build version is changed from 2.2.1 to
> 3.0.4, the maven plugin doesn't pick my new custom rule, instead it runs
> with the default rulesets and doesn't throw any error message. Any inputs?
>
> Parent pom:
> --
> 
> 
> org.apache.maven.plugins
> maven-pmd-plugin
> true
> 3.1
> 
> true
> true
> utf-8
> 100
> 1.7
> 
> 
> ${basedir}/LoggingCustomRules.xml
> 
> 
> 
>   
> 
>
> I'm running PMD for child projects.
>
> Regards,
> Krithika
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


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

Re: m-invoker-p: only 2 out of 3 ITs executed

[Baptiste Mathus]

Thanks Thomas, that did it.
I actually saw the parameter but overlooked it 'cause I thought it would
recursively find every poms or so and wasn't designed for my use case. I
was wrong.

For the record, pomIncludes parameter is actually a list, hence must be
declared:


 *



Cheers


2014-03-18 11:22 GMT+01:00 Thomas Broyer :

>
> http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#pomIncludessays
> :
>
> > If this parameter is not set, the plugin will search for all
> pom.xml files one
> > directory below projectsDirectory (i.e. */pom.xml).
>
> It's indeed initialized to "*/pom.xml" in the code:
>
> https://github.com/apache/maven-plugins/blob/maven-invoker-plugin-1.8/src/main/java/org/apache/maven/plugin/invoker/AbstractInvokerMojo.java#L206
>
> So, from the doc, apparently, it should work if you use
> *
>
>
> On Tue, Mar 18, 2014 at 11:08 AM, Baptiste Mathus  >wrote:
>
> > Hi all,
> >
> > Had a quick look in JIRA, but didn't find anything obvious.
> >
> > I have 3 ITs in my src/it folder for my maven plugin. Only 2 get
> executed.
> > The 3rd one executes correctly if I explicitly match it using
> > -Dinvoker.test=forgotten-test*
> >
> > Note that this IT doesn't have a pom.xml at its root, and is
> > using invoker.project property.
> >
> > Haven't had a look in the m-invoker-p code, but if anyone has a hint
> about
> > this, or can point me to an existing JIRA that'd help.
> >
> > Thanks
> >
> > --
> > Baptiste  MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> >
>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>



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

m-invoker-p: only 2 out of 3 ITs executed

[Baptiste Mathus]

Hi all,

Had a quick look in JIRA, but didn't find anything obvious.

I have 3 ITs in my src/it folder for my maven plugin. Only 2 get executed.
The 3rd one executes correctly if I explicitly match it using
-Dinvoker.test=forgotten-test*

Note that this IT doesn't have a pom.xml at its root, and is
using invoker.project property.

Haven't had a look in the m-invoker-p code, but if anyone has a hint about
this, or can point me to an existing JIRA that'd help.

Thanks

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

Re: Help with converting existing ant build to maven is required

[Baptiste Mathus]

Well, though I agree Maven isn't designed to be an end-user tool, using it
to build the end-user distribution is actually totally supported.
IMO, if what you're trying to do is building your product from some sources
and binaries, then Maven can obviously do it.

If what you need for production is an installer, then creating an installer
using izpack is indeed a good idea, but you would just build that installer
during your Maven build (http://izpack.codehaus.org/izpack-maven-plugin/e.g.).

You seem to actually have two kind of phases:
* the first one, typically compile and package your sources using binaries
coming from a repo manager (be it a corporately managed one, or directly
from Central)
* the second one, creating the end-user distribution, is typically done
with Maven using maven-assembly-plugin.

Don't hesitate to ask questions, because I don't think we've gone so far
until now to understand your building steps.

Cheers


2014-03-13 14:24 GMT+01:00 Maxim Solodovnik :

> Thanks Ron,
>
> I'll take a look at it, but I'm afraid distribute application in "partially
> compiled state" is not an option.
> Currently it works out of the box and this is the requirement.
>
> Will try to study maven and postpone the migration for now
>
>
> On Thu, Mar 13, 2014 at 8:18 PM, Ron Wheeler <
> rwhee...@artifact-software.com
> > wrote:
>
> > IMHO, Maven is a software build tool and trying to make it a installation
> > tool is much too hard.
> >
> > You might find that your life will be a lot easier with IzPack as the
> tool
> > to create your installer.
> > It will allow you to package up your maven artifacts with other resources
> > into different OS-specific installers that can be distributed easily.
> > It supports install time execution of your procedures so that you can
> > start RED-5 or execute the flex processes required to build and install
> the
> > Flash assets.
> >
> >
> > Ron
> >
> >
> >
> > On 13/03/2014 4:51 AM, Maxim Solodovnik wrote:
> >
> >> Hello Baptiste,
> >>
> >> Thanks for your quick reply!
> >>
> >> Red5-server is "custom tomcat" (zip/tgz with scripts, libraries, configs
> >> etc.).
> >> We need to pack it in our distribution, not sure if it can be done
> "Maven
> >> way" :(
> >>
> >> 2) tgz contains flex based Flash compiler with all necessary libraries
> and
> >> binaries necessary to build Flash part of our application.
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Mar 13, 2014 at 5:15 AM, Baptiste Mathus  wrote:
> >>
> >>  IIUC, your project openmeetings depends on red5 libraries.
> >>>
> >>> About your questions:
> >>>
> >>> 1) Not actually a Maven issue, but you seem to think the way to go it
> to
> >>> build that dependency. As the project is ASLv2, you would far better
> make
> >>> sure/ask it be uploaded to Maven Central. Then just just the
> 
> >>> in a normal way/
> >>> Maven is actually very straightforward if you follow the Maven Way
> (yeah,
> >>> sounds like a sect somehow, you may think ;-)).
> >>>
> >>> 2) Once again, what does contain that tgz? If it contains jars and so
> on,
> >>> then forget about downloading and decompressing it during your buil. Or
> >>> you're gonna a world of despair. Just upload those libs under some
> >>> sensible
> >>> coordinates in a corporate (or better, in Maven Central if the project
> is
> >>> OSS), and add the dependency.
> >>>
> >>> Please ask more questions/give more precisions if you want more precise
> >>> help.
> >>>
> >>> HTH
> >>>
> >>>
> >>> 2014-03-12 17:51 GMT+01:00 Maxim Solodovnik :
> >>>
> >>>  Hello All,
> >>>>
> >>>> I'm new to maven and not very familiar with all its plugins.
> >>>>
> >>>> I need to move project [1] from ant+ivy to maven
> >>>> The problems are:
> >>>>
> >>>> 1) this project is build on top of [2] maven project (we need the
> exact
> >>>> structure and all libraries from this project) *[first problem: i
> don't
> >>>> know how to do it]*
> >>>>I did it using ant as follows:
> >>>>a) using SVN download the project sources
> >>>>b) build it using maven
> >>>>

Re: Help with converting existing ant build to maven is required

[Baptiste Mathus]

IIUC, your project openmeetings depends on red5 libraries.

About your questions:

1) Not actually a Maven issue, but you seem to think the way to go it to
build that dependency. As the project is ASLv2, you would far better make
sure/ask it be uploaded to Maven Central. Then just just the 
in a normal way/
Maven is actually very straightforward if you follow the Maven Way (yeah,
sounds like a sect somehow, you may think ;-)).

2) Once again, what does contain that tgz? If it contains jars and so on,
then forget about downloading and decompressing it during your buil. Or
you're gonna a world of despair. Just upload those libs under some sensible
coordinates in a corporate (or better, in Maven Central if the project is
OSS), and add the dependency.

Please ask more questions/give more precisions if you want more precise
help.

HTH


2014-03-12 17:51 GMT+01:00 Maxim Solodovnik :

> Hello All,
>
> I'm new to maven and not very familiar with all its plugins.
>
> I need to move project [1] from ant+ivy to maven
> The problems are:
>
> 1) this project is build on top of [2] maven project (we need the exact
> structure and all libraries from this project) *[first problem: i don't
> know how to do it]*
>   I did it using ant as follows:
>   a) using SVN download the project sources
>   b) build it using maven
>   c) unpack artifact and use it's structure in my build
>
> Currently this project was moved to git and I was hoping it will be
> possible to using maven scm:git for this, not sure how :(
>
> 2) this project need to download tgz file with required framework, extract
> it somewhere and use extracted file to perform the build *[second problem:
> is this possible?]*
>
> Any help is highly appreciated
>
> [1]
>
> https://svn.apache.org/viewvc/openmeetings/trunk/singlewebapp/build.xml?view=markup
> [2] https://github.com/Red5/red5-server
>
> --
> WBR
> Maxim aka solomax
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: maven won't resolve from central log4j:log4j:1.2.8 through 1.2.15

[Baptiste Mathus]

File an issue there: https://issues.sonatype.org/browse/mvncentral

Cheers


2014-03-12 22:36 GMT+01:00 Mauri, Richard :

> Hi, any word on how to fix the maven central repo so we can proceed with
> resolving (mvn dependency:tee) log4j:log4j:[1.2.8] ?
>
> It¹s curious why we can request with soft version 1.2.8 but not absolute
> [1.2.8]
>
> What has to happen to fix the maven central repos?
>
> On 3/10/14, 9:32 AM, "Anders Hammar"  wrote:
>
> >Yes, something seems wrong with the metadata file. It should list all
> >versions.
> >
> >/Anders (mobile)
> >Den 10 mar 2014 17:25 skrev "Adrien Rivard" :
> >
> >> Does'nt seem to work for me either when hitting maven central directly.
> >> Works ok when using my usual MRM.
> >>
> >> If I'm not wrong
> >> http://repo.maven.apache.org/maven2/log4j/log4j/maven-metadata.xml
> >>should
> >> return all versions while it returns only 2 .
> >>
> >>
> >>
> >>
> >> On Mon, Mar 10, 2014 at 4:37 PM, Mauri, Richard  >> >wrote:
> >>
> >> > I am still having trouble.
> >> > It certainly should be easy to reproducee no?
> >> > It is a trivial settings.xml and pom.xml and mvn dependency:tree goal
> >> >
> >> > Thanks for helping, but please keep at it :-)
> >> >
> >> > On 3/10/14, 6:15 AM, "Wayne Fay"  wrote:
> >> >
> >> > >>> Where did this repo.maven.apache.org url come from?
> >> > >>
> >> > >> Wayne, it's a correct URL for the central repository. It's the one
> >>we
> >> > >> define in the super-POM since Maven 3.0.something.
> >> > >
> >> > >Doh, well ignore that then. I should have done 30 seconds of
> >>searching
> >> > >before sending that one. :)
> >> > >
> >> > >But just FYI, when I myself tried accessing that URL last night, I
> >>had
> >> > >problems in my browser. First it was HTTPS problems as the URL did
> >>not
> >> > >match the server name being reported (I have the HTTPS Everywhere
> >> > >plugin turned on). I clicked "ignore" and went to the site and got
> >> > >HTTP 404 errors at /log4j/log4j/maven-metadata.xml so I moved up to
> >> > >/log4j/log4j and had the same errors. I did not grab the error but it
> >> > >was something related to Varnish cache - when I cause a 404 now, the
> >> > >error appears different.
> >> > >
> >> > >So at the very least, the mirror I was on (fastly.net) was having
> >> > >issues - and potentially this was mirrored to others, possibly
> >> > >explaining the troubles (??). I had no such trouble hitting the old
> >> > >standby of repo1.maven.org and resolving the files etc. These errors
> >> > >made me question the URL entirely.
> >> > >
> >> > >I hit it again just now and dns sends me to fastly.net again but
> this
> >> > >time the files are there.
> >> > >
> >> > >So, I would ask Richard to try again and see if things work better
> >> > >today, or if he is having the same troubles.
> >> > >
> >> > >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
> >> >
> >> >
> >>
> >>
> >> --
> >> Adrien Rivard
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>

Re: Maven Release Plugin throws Authentication Required error

[Baptiste Mathus]

Hi,
First try do to that without using Jenkins at all. This is a pure maven
configuration thing. You just seem to be missing the  authentication part
(see username and password parameters maybe).

When you manage to release some dummy versions of your project, then and
only then try doing it from Jenkins or any other automated system.

Cheers
Le 6 mars 2014 15:14, "D Vijay"  a écrit :

> Dear All,
>
>
> I need help in configuring the Maven Release plugin. I am trying to
> configure the plugin in Jenkins job. I am getting authentication exception.
> For invoking maven release plugin do we need to have svn client from where
> we are invoking the release? PFA the errors & the configuration that I used
> for this.
>
> My requirement is to configure maven release plugin as follows:
>
> 1. My current version is at 1.0.0-SNAPSHOT and once testing is done and
> ready for movement to production the maven release plugin will be invoked
> from Jenkins job to move the code from branch to trunk.
> 2. The configuration has to check out the source from branch, update all
> the POMs to version 1.0.0, tag the source code and check in the code at
> trunk location. The tags folder will contain the tagged version at 1.0.0
> (as best practice we need to change the version from 1.0.0-SNAPSHOT to
> 1.0.0 once the product is ready for production, right? or while moving to
> UAT itself it should be done?).
> 3. Also, the next snapshot version will be updated to 1.0.1-SNAPSHOT(which
> is configurable in release plugin) and checked in at branch level for the
> next development.
>
> I am able to configure this, but somehow it is not working. I am getting
> authentication exception.
> svn: Authentication required for 
> '
> >'.
>
>
> Thank you,
>
> Vijay.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Could not create staless EJB whith maven 3.2.1 but working fine with version 3.0.5

[Baptiste Mathus]

Hi,
The best way to have it looked into is to create a test project and attach
it to an issue report.
Just out of curiosity, are you having an issue with a plugin or a simple
"multi modules project"?
Cheers
Le 5 mars 2014 16:36,  a écrit :

> With maven version 3.2.1, in fact same issue since version 3.1.1, I get
> the exception SCHWERWIEGEND: EJB5070: Exception creating stateless session
> bean : [RequirementBeanSL]
> when building the concerned  module with tests. Changing back to run the
> same tests with maven version 3.0.5, all tests run fine and pass.
>
> I repeat, starting the run configuration within eclipse Kepler, selecting
> either the external maven runtime version 3.2.1 or version 3.0.5 I get the
> exception or the tests runs fine!
>
> (The injected bean is a dummy bean to provoke exceptions and to test
> proper behavior of the program under erroneous conditions.)
>
> From the log extracts below, we can see in both cases the interface
> declarations of both kind of beans being injected. For instance
> IRequirementsSL_
>
> When running with 3.0.5 no exception happens and we get INFO:
> ProjectFactory#getProjects reading line:1; then the  line 2, etc.
>
> when running with 3.2.1 (same with 3.1.1) the mentioned exception happens,
> telling the implementation of the interface IRequirementsSL_ i.e.
> RequirementBeanSL could not be created.
> The issue started with version 3.1.x and still exist in version 3.2.1. The
> implementing bean is not found any more when declaring the interface,
> while with maven 3.0.5 the implementation of the interface is found and
> used.
>
> I would very much appreciate any hint on how to work around this problem.
> Of course, I could simple stick to maven version 3.0.5 as this works. But
> in the long run I would prefer to keep pace with the newer versions.
>
> Thanks in advance.
>
> Log-Extract running maven version 3.2.1:
> INFO: Testing RequirementsWithAcceptanceByList
> Response code = 404
> 05.03.2014 15:37:56
> ch.commcity.reports.servlet.ReportsDispatcherExceptionsTest callServlet
> INFO: callServlet entered
> 05.03.2014 15:37:56
> ch.commcity.reports.servlet.ReportsDispatcherExceptionsTest callServlet
> INFO: callServlet request is:
>
> http://localhost:8181/reports/dispatcher?documentId=RequirementPreview&docKind=ODT&reqPK=41
> 05.03.2014 15:37:56 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: ReportsDispatcher#doGet called!
> 05.03.2014 15:37:56 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: doGet: value of injected projectBean is:
> ch.commcity.monterosa.ejb.IProjectsSL_526301960
> 05.03.2014 15:37:56 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: doGet: value of injected requirementsBean is:
> ch.commcity.monterosa.ejb.IRequirementsSL_71899727
> 05.03.2014 15:37:56 ch.commcity.reports.test.util.ProjectFactory
> getProjects
> INFO: modified is: Sat Nov 17 09:43:24 CET 2012
> 05.03.2014 15:37:56 ch.commcity.reports.test.util.ProjectFactory
> getProjects
> INFO: created is: Wed Jan 18 17:25:13 CET 2012
> 05.03.2014 15:37:56 ch.commcity.reports.test.util.ProjectFactory
> getProjects
> INFO: modified is: Fri Dec 14 17:00:59 CET 2012
> 05.03.2014 15:37:56 ch.commcity.reports.test.util.ProjectFactory
> getProjects
> INFO: created is: Wed Jan 18 15:58:09 CET 2012
> 05.03.2014 15:37:56 com.sun.ejb.containers.StatelessSessionContainer
> createStatelessEJB
> SCHWERWIEGEND: EJB5070: Exception creating stateless session bean :
> [RequirementBeanSL]
> 05.03.2014 15:37:56 com.sun.ejb.containers.BaseContainer postInvoke
> WARNUNG: EJB5184:A system exception occurred during an invocation on EJB
> RequirementBeanSL, method: public ch.commcity.monterosa.ejb.IRequirement
>
> ch.commcity.monterosa.ejb.with.exceptions.RequirementBeanSL.getRequirement(java.lang.Long)
> throws BusinessPersistencyException
> 05.03.2014 15:37:56 com.sun.ejb.containers.BaseContainer postInvoke
> WARNUNG:
> javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException:
> Could not create stateless EJB
>
> Same extract running version 3.0.5
> INFO: Testing RequirementsWithAcceptanceByList
> Response code = 404
> 05.03.2014 15:43:47
> ch.commcity.reports.servlet.ReportsDispatcherExceptionsTest callServlet
> INFO: callServlet entered
> 05.03.2014 15:43:47
> ch.commcity.reports.servlet.ReportsDispatcherExceptionsTest callServlet
> INFO: callServlet request is:
>
> http://localhost:8181/reports/dispatcher?documentId=RequirementPreview&docKind=ODT&reqPK=41
> 05.03.2014 15:43:47 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: ReportsDispatcher#doGet called!
> 05.03.2014 15:43:47 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: doGet: value of injected projectBean is:
> ch.commcity.monterosa.ejb.IProjectsSL_1930087059
> 05.03.2014 15:43:47 ch.commcity.reports.servlet.ReportsDispatcher doGet
> INFO: doGet: value of injected requirementsBean is:
> ch.commcity.monterosa.ejb.IRequirementsSL_1232712678
> 05.03.2014 15:43:47 ch.commcity.repor

Re: Hi I have following issue building STUDIO PLATFORM MODULE:

[Baptiste Mathus]

Hi,
As you feared in introduction, this is indeed not the right mailing IIUC.
You're trying to build "Bonita studio", and that build is using Maven. You
should actually contact Bonita's team.
Cheers
Le 28 févr. 2014 00:20, "roberto777"  a écrit :

> Not sure if this is the place for this, but I have following error message
> while building studio platform module.
> any help would be really appreciate.
>
>
> $ mvn clean install -e -Pmirrored -Dp2MirrorUrl=file//E:\BONITA\6.1 [INFO]
> Error stacktraces are turned on. [INFO] Scanning for projects... [INFO]
> [INFO] Using the builder
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder
> with a thre ad count of 1 [INFO] [INFO]
> 
> [INFO] Building platform 6.2.1 [INFO]
> 
> [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ platform
> --- [INFO] Deleting c:\Users\daniel castro\bonita-studio\platform\target
> [INFO] [INFO] --- maven-antrun-plugin:1.7:run (Generate target file) @
> platform --- [WARNING] Parameter tasks is deprecated, use target instead
> [INFO] Executing tasks main: [echo] P2 Mirror Repository =
> file//E:BONITA6.1
> [copy] Copying 1 file to c:\Users\daniel castro\bonita-studio\platform
> [INFO] Executed tasks [INFO] [INFO] ---
> tycho-packaging-plugin:0.18.0:package-target-definition
> (default-package-target-definition) @ platform --- [INFO] [INFO] ---
> target-platform-validation-plugin:0.18.0:validate-target-platform (default)
> @ platform --- [INFO] Validating c:\Users\daniel
> castro\bonita-studio\platform\platform.target... [INFO] Failed, see Error
> log below [ERROR] Validation found errors in 1 .target files: Could not
> resolve content of platform.target [INFO]
> 
> [INFO] BUILD FAILURE [INFO]
> 
> [INFO] Total time: 3.129 s [INFO] Finished at: 2014-02-26T15:56:37-04:00
> [INFO] Final Memory: 9M/240M [INFO]
> 
> [ERROR] Failed to execute goal
>
> org.eclipse.tycho.extras:target-platform-validation-plugin:0.18.0:validate-target-plat
> form (default) on project platform: Validation found errors in 1 .target
> files: [ERROR] Could not resolve content of platform.target [ERROR] ->
> [Help
> 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute
> goal org.eclipse.tycho.extras:target-platfo
> rm-validation-plugin:0.18.0:validate-target-platform (default) on project
> platform: Validation found errors in 1 .tar get files: Could not resolve
> content of platform.target at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuild
> er.java:51) at
>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:157) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597) at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Validation found
> errors in 1 .target files: Could not resolve content of platform.target at
>
> org.eclipse.tycho.extras.tpvalidator.TPValidationMojo.execute(TPValidationMojo.java:90)
> at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more [ERROR] [ERROR] Re-run Maven using the -X switch to en

Re: Where the binnary of mvn knows which mojo do i want to execute?

[Baptiste Mathus]

What are you trying to do actually? Plugin development? Understanding Maven
to patch it? Just want to use it and stuck somewhere?


2014-02-24 13:25 GMT+01:00 enrique bernal ruiz :

> I am novice using mvn and having a look to /usr/bin/mvn, I can see the eval
> method, but I can not understand where the mojo is called.
> Please can anyone explain how the eval method works?
> I would be very pleased if someone could help me.
>
> That is my eval
> method/
>
> eval "${JAVACMD}" \
>   ${MAVEN_OPTS} \
>   -classpath "${CLASSWORLDS_JAR}" \
>   "-Dclassworlds.conf=${M2_HOME}/bin/m2.conf" \
>   "-Dmaven.home=${M2_HOME}"  \
>   "-Dos.arch=`uname -m`" \
>   ${CLASSWORLDS_LAUNCHER} $(${QUIET_FLAG} && echo \-q) $(${OFFLINE_FLAG} &&
> echo \-o) ${QUOTED_ARGS} ${MAVEN_ARGS}
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

Re: Looking for org.apache.poi 3.10-FINAL

[Baptiste Mathus]

2014-02-17 7:55 GMT+01:00 David Law :

> Ron, Wayne,
>
> this wasted several days (elapsed) of my time:
> I spent ages trying out options & trying to figure out what I'd done
> wrong...
> ...rebuilding & updating indices, hacking through to
> workspace\.metadata\.plugins\org.eclipse.m2e.logback.configuration,
> to set logging to ALL, but even ALL  was somewhat sparse.
>

M2E is not Maven per-se. When a question is about a particular tool, I'd
advice you to try and target the most specific ML/support system:
https://eclipse.org/m2e/support/



> I tried Google & found loads of hits that had nothing to do with it.
> I found nothing at apache maven or maven central or m2eclipse.
> I tried the POI Forum, but it became clear that wasn't the problem.
>
> As Wayne rightly points out "where is the right place to document it?".
> With a complex issue like this with multiple components where do you start?
> But thats all the more reason to document it somewhere...


> Right now it seems to me not to be a maven problem as such.
> Its about how maven central creates its indices & how m2e uses them.
> So in theory it needs to be documented in both, correspondingly
> cross-referenced.
> But as the m2e FAQ is subscription-only it would seem the only place is the
> maven central FAQ.  And its so important, it should be a point in its
> own right:
>
> "Why can't I see new artifacts in my client (e.g. m2eclipse)?"
> (Tip -> you can get as-yet-unindexed artifacts explicitly...blah, blah)
>

Again, not the best ML to discuss it.


>
> And then there's the question, why does m2e use the high-latency index?

If its performance/server-load, then it could be
> a rethink of the index-structure is necessary.
> Is that a maven issue?
> I have some ideas there...
>

Definitely not Maven related. Maven core has nothing to do with the indexes
you describe, doesn't know/need it.
It's more an IDE/search engine facility to help people find versions. I
personally almost never use those for example.

Cheers

Re: Possible build collision between CI snapshot build and Release build

[Baptiste Mathus]

OK, so this has to be CVCS (svn and so on) specific?
I didn't check if the release-plugin commits + push each time. If this is
so, it should be fixed so that this cannot happen.

I would say that though this is a valid technical concern, it's very
unlikely to happen in real life.

Let's take an example with a well known CI server, and specifically with
svn:

* You start a release. At the end of the release:prepare, the
release-plugin commits the poms just before copying the path to the tags
directory, then reverting the poms to the next snapshot development version.
* Unfortunately, the CI kicks in just there, just after that commit, and
before the trunk comes back to snapshot.
* In Jenkins (and Hudson), there's a default delay of some seconds,
historically to support VCS like CVS that wouldn't commit files in an
atomic manner
* So, Jenkins is gonna wait those seconds before actually starting the
build. Then it asks the VCS once more if a new change occurred. So, the
probability to encounter this issue is even lower...

So, all in all, if that's the issue you're talking about. Not sure it's
worth to worry a lot :-).

Btw, if you use a repo manager with a staging area, then at worse you're
gonna create a staging repo from the CI build in addition to your release
build. So, in the end you won't be able to push many releases under the
same names and your release should still be able to proceed.

HTH



2014-02-15 16:51 GMT+01:00 Thomas Broyer :

> On Sat, Feb 15, 2014 at 4:18 PM, Baptiste Mathus 
> wrote:
>
> > Hi Dan,
> > Not sure what you mean. You say "CI", are you taking about a specific
> > server? If Jenkins for example, wouldn't it then be more a Jenkins user
> ml
> > question?
> >
> > And I don't see how a snapshot build could interfere with another build
> > with a release version.
> > Could you give details about your issue so that we can help you?
> >
>
> mvn release:prepare does a first commit with the POM modified with the
> no-SNAPSHOT version, then another commit with the POM modified with the
> "next" SNAPSHOT version.
> If a build is triggered for the first commit and basically does a "mvn
> install" or, worse, a "mvn deploy", then it'll end up deploying your
> release version, the very same that "mvn release:perform" will deploy too
> (very same version information, not necessarily the same artifact: might
> not deploy javadoc and sources for example, or the artifact might be
> slightly different because you have plugins in a profile triggered only on,
> or never on, release builds).
> I think that what Dan referred to as a "CI snapshot build" is the kind of
> build triggered by a commit (which generally builds snapshots).
>
>
> >
> > Cheers
> > Le 15 févr. 2014 07:01, "Dan Tran"  a écrit :
> >
> > > Hello
> > >
> > >
> > > It is possible that while release:prepare cutting the tag and CI for
> > > snapshot build wakeup at the same time.  Is there a way to prevent
> this?
> > > like a a profile to fail the build if the version happen to be a
> release
> > > version.  Ie is there a way to detect this in a profile?
> > >
> > > I currently have to keep remind my self to turn off CI snapshot build
> > while
> > > release is in progress, and too many to remember.
> > >
> > > Advice is greatly appreciated
> > >
> > > -Dan
> > >
> >
>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>



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

Re: Possible build collision between CI snapshot build and Release build

[Baptiste Mathus]

Hi Dan,
Not sure what you mean. You say "CI", are you taking about a specific
server? If Jenkins for example, wouldn't it then be more a Jenkins user ml
question?

And I don't see how a snapshot build could interfere with another build
with a release version.
Could you give details about your issue so that we can help you?

Cheers
Le 15 févr. 2014 07:01, "Dan Tran"  a écrit :

> Hello
>
>
> It is possible that while release:prepare cutting the tag and CI for
> snapshot build wakeup at the same time.  Is there a way to prevent this?
> like a a profile to fail the build if the version happen to be a release
> version.  Ie is there a way to detect this in a profile?
>
> I currently have to keep remind my self to turn off CI snapshot build while
> release is in progress, and too many to remember.
>
> Advice is greatly appreciated
>
> -Dan
>

Re: maven-ear-plugin silently overrides libraries

[Baptiste Mathus]

That's the way to go. Even more if you're able to attach a test project.
One report without report is far less likely to be worked on.
Cheers
Le 13 févr. 2014 14:06, "Reto Hablützel"  a écrit :

> So what's the status on this? Shall I create a ticket?
>
>
> On Fri, Feb 7, 2014 at 5:04 PM, Ron Wheeler
> wrote:
>
> > Exclusions will not help in this case.
> > Looking through the dependency hierarchy will at least get you to see the
> > problem earlier which I think was the nature of your question.
> >
> > It appears from my brief reading and fun with making servlets run in
> > production that classloaders merge classes by name.
> > Maven does not.
> >
> > I am a bit surprised that groupId does not count.
> >
> > If one uses a lot of third -party libraries, it would seem inevitable
> that
> > you could need com.artifact-software:utilities:1.0 at the same time as
> > ch.rethab:utilities:1.0 at the same time.
> > The classloader is not going to cause any problem but if Maven throws out
> > one of these as a duplicate, you will be missing classes at run-time.
> >
> > It is difficult to force everyone to create unique artifactIds unless you
> > get rid of the GroupId altogther and make GAV ->  and put the group
> > name into the artifactID.
> >
> > This seems to be a design flaw if it is true.
> >
> > Ron
> >
> >
> > On 07/02/2014 9:43 AM, Reto Hablützel wrote:
> >
> >> Sure, but exclusions don't do the trick if you need both of them, do
> >> they? I am talking about completely independent libraries that happen to
> >> have the same artifactId.
> >>
> >> Those were actually both libraries of mine and I could obviously fix
> this
> >> issue rather simply, but I was just thinking that it would be helpful to
> >> have at least a warning or something from maven - regardless of the IDE.
> >>
> >> - Reto
> >>
> >>
> >> On Fri, Feb 7, 2014 at 3:33 PM, Ron Wheeler  >> com > wrote:
> >>
> >> If your IDE supports Maven (Eclipse/STS for example), you will see
> >> the conflict in the dependency hierarchy view and you can fix it
> >> with the right exclusions.
> >>
> >> It is almost always worth a quick look through the dependency
> >> hierarchy view if you use a lot of third party libraries.
> >> Not everyone updates their dependencies when they build a
> >> shareable library.
> >> You can sometimes get some pretty old versions of things dragged
> >> in with the latest version of otherwise well-written libraries.
> >> Exclusions need to be added to get what you want in your artifacts.
> >>
> >> Ron
> >>
> >>
> >> On 07/02/2014 9:21 AM, Reto Hablützel wrote:
> >>
> >> Hi there,
> >>
> >> I built an ear using the maven-ear-plugin (version 2.6).
> >>
> >> The ear is configured such that it includes two libraries into
> >> the lib
> >> folder, both with the same artifactId as well as the same
> >> version, but a
> >> different groupId. Now if I simply call 'mvn package' only the
> >> first one is
> >> included, but no warning whatsoever appears. Only once I turn
> >> on debugging
> >> (mvn --debug package), I see one subtle message:
> >> [DEBUG] Skipping artifact [jar:com.foo:bar:1.0] as it is
> >> already up to date
> >> at [lib/bar-1.0.jar]
> >>
> >> Wouldn't it make sense to either include the groupId in the
> >> filename or at
> >> least make a check (that includes the groupId) beforehand if
> >> there are any
> >> conflicts?
> >>
> >> Cheers,
> >> Reto
> >>
> >>
> >>
> >> -- Ron Wheeler
> >> President
> >> Artifact Software Inc
> >> email: rwhee...@artifact-software.com
> >> 
> >>
> >> skype: ronaldmwheeler
> >> phone: 866-970-2435, ext 102
> >>
> >>
> >>
> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> 
> >>
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> >>
> >>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
>

RE: SCM requires that command line svn be used?

[Baptiste Mathus]

It says authentication required. Did you provide/configure the necessary
credentials?
Le 13 févr. 2014 12:21, "doddalas"  a écrit :

> Hi,
>
> I am getting the same error. Can you please help me if you have fixed this
> issue. Do we need to configure anything specifically for https svn URLs? I
> have given credentials in maven settings and svn configuration in pom
> files.
> Any my release plugin is as follows:
>
> 
> org.apache.maven.plugins
> maven-release-plugin
> 2.4.2
> 
> 
>
> com.google.code.maven-scm-provider-svnjava
>
> maven-scm-provider-svnjava
> 1.6
> 
> 
> 
> 
> javasvn
> 
> 
> https://mydomain.com/svn/New_FW/CI_POC/tags
>
> forked-path
> 
> 
> PFB the error that I am getting:
>
> [INFO] Building Service 1.0.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-release-plugin:2.4.2:prepare (default-cli) @ Service ---
> [INFO] Change the default 'svn' provider implementation to 'javasvn'.
> [INFO] Verifying that there are no local modifications...
> [INFO]   ignoring changes on: **\release.properties, **\pom.xml.next,
> **\pom.xml.releaseBackup, **\pom.xml.backup, **\pom.xml.branch,
> **\pom.xml.tag
> [INFO] SVN status directory:
> D:\Softwares\jenkins\jobs\Perform_Release\workspace
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Service ... FAILURE
> [14.743s]
> [INFO] ServiceEJB  SKIPPED
> [INFO] SpringMVC323REST .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 17.859s
> [INFO] Finished at: Thu Feb 13 10:37:59 IST 2014
> [INFO] Final Memory: 9M/55M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli)
> on
> project Service: Unable to check for local modifications
> [ERROR] Provider message:
> [ERROR] SVN status failed.
> [ERROR] Command output:
> [ERROR] svn: Authentication required for ''
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare
> (default-cli) on project Service: Unable to check for local modifications
> Provider message:
> SVN status failed.
> Command output:
> svn: Authentication required for ''
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/SCM-requires-that-command-line-svn-be-used-tp119251p5784375.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: Code coverage with debug logs: 100% branch coverage not possible?...

[Baptiste Mathus]

following problem:
> >>>>> In many projects we use a Logger (doesn't matter which
> >>>>> implementation). It is often recommend to test if the debug level is
> >>>>> activated before logging a debug trace like the following:
> >>>>> if (logger.isDebugEnabled()) {
> >>>>> logger.debug("blah " + i + " in the loop that contains " + max);
> >>>>> }
> >>>>> Now when you run unit tests on this kind of code you need to make a
> >>>> choice:
> >>>>
> >>>>> run tests with INFO level or run tests with ALL traces activated. I
> >>>>> choose the second option in order to:
> >>>>> * Check that debug traces doesn't throw unwanted exception
> (like
> >>>>> NPE)
> >>>>> * Have a better code coverage in term of covered lines
> >>>>> But in term of branches coverage we could never have a 100% :(
> >>>>> To me the only way to cover this is to run the tests suite 2 times:
> >>>>> one with INFO traces configured, and another one with ALL traces
> >>>>> activated.
> >>>>> Did you face this issue and how did you solve it ?
> >>>>> Thanks,
> >>>>> Benoît.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Paul
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > -
> > 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
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>

Re: Deep dependency analysis

[Baptiste Mathus]

I'd look at the code behind dependency: analyze
I guess the improvement by logging the class level usage might be doable.

My 2 cents
Le 3 févr. 2014 20:48, "Benoît Berthonneau"  a
écrit :

> Hi All,
>
>
>
> Do you know any maven plugin that could say which classes (from
> dependencies) are used by the maven project (class by class) ?
>
> I looked at the maven dependency plugin but doesn’t seem to provide this
> kind of deep analysis…
>
>
>
> The idea behind my question is to know if a dependency is really useful or
> just because of a “little” API (something like StringUtility class) called
> by only one class…
>
>
>
> Thanks,
>
> Benoît.
>
>

Re: turns EAR into an OSGi

[Baptiste Mathus]

Hi,
Seems not so much a maven question. More an OSGi one.
IMO, you should start by thinking about or explaining what you would expect
maven to do.

Knowing both Java EE and OSGi (here it's bundles) a bit, I can't see even
doing it manually anything obvious to something approaching a conversion.
Le 20 janv. 2014 18:39, "acostela"  a écrit :

> Hi everybody.
>
> I'm a bit new with maven. I've worked with it before but no in the depth
> that I need now. I have searched trough internet and inside this forum and
> I
> didn't found anything conclusive to my question.
>
> I have an Enterprise Java application that it's build with Maven and it has
> several modules in it. I have some EJBs other kind of classes and packages
> like Jars etc. I use an ear package to build all together into an .ear
> package. I would like to turns this into an OSGi. Can I do this with maven?
> What it's the best way to achieve this?
>
> Thank you very much to everybody.
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929.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: Property that indicates a snapshot or release build?

[Baptiste Mathus]

+1.
At least I agree I don't think there's already a property for that.
Le 19 janv. 2014 22:20, "Dan Tran"  a écrit :

> Sounds like a candidate enhancement for build-helper-maven-plugin
>
> -D
>
>
> On Sunday, January 19, 2014, Graham Leggett  wrote:
>
> > On 19 Jan 2014, at 6:20 PM, Anders Hammar  >
> > wrote:
> >
> > > Don't understand. You need to, through code, get hold of the artifact
> > > objects.
> >
> > I am trying to get access to this from a property.
> >
> > What I need is a property that I can embed in a path inside the pom. If
> > the artefact is a release, the property is one value, while if the
> artefact
> > is a snapshot, the property is another. The project.version property
> comes
> > achingly close, but won't work for me because it will change on every
> > release.
> >
> > Regards,
> > Graham
> > --
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> 
> >
> >
>

Re: Depend on a jar via another pom file

[Baptiste Mathus]

Well, what "scope" are used here? Thus is a central element to manage
transitivity.

Btw, you should never rely on a dependency to get a dependency you're also
using. You must redeclare it in your own pom. (mvn dependency:analyze can
also help you here).

Cheers
Le 8 janv. 2014 16:59, "Omar@Gmail"  a écrit :

> I have a maven module (lets call it M) that requires aspectjrt but M
> already depends on another pom file that has aspectjrt within its
> dependency tree  like so:
>
> M ->  middle pom -> aspectjrt
>
> The problem is M would not compile unless I express the aspectjrt
> dependency directly in the M pom file, why?
>
> Is there a way for M to get apsectjrt via the middle pom without directly
> depending on aspectjrt?
>

Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

[Baptiste Mathus]

Hi,
Stephen already answered along those lines. What are you missing?
Cheers


2014/1/9 S. Ali Tokmen 

> Hi Anders
>
> Thanks for your reply - and happy new year :)
>
> Is there any way I can inject / read the whole plugin configuration from
> the plugin?
>
> Best regards
>
> S. Ali Tokmen
> http://ali.tokmen.com/
>
> My IM, GSM, PGP and other contact details
> are on http://contact.ali.tokmen.com
>
> On 08/01/14 20:00, Anders Hammar wrote:
> > AFAIK there is no support for this. If you think there should be, please
> > file a ticket [1].
> >
> > /Anders
> >
> > [1] http://jira.codehaus.org/browse/MNG/
> >
> >
> > On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen  >wrote:
> >
> >> Dear Maven users
> >>
> >> I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
> >> plugin; and would have a question with regards to how parameters are
> >> managed.
> >>
> >> We defined our MOJOs with parameters (you can see
> >>
> >>
> http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
> >> for example), but what happens is that if a user unwillingly puts a
> >> parameter in the wrong place then the plugin execution doesn't stop.
> >>
> >> As an example, I can write the below POM and build still works (even
> >> thought the MOJO has no parameter called "foo"):
> >>
> >>   
> >> org.codehaus.cargo
> >> cargo-maven2-plugin
> >> 1.4.6
> >> 
> >>   
> >> bar
> >>   
> >> 
> >>   
> >>
> >> Is there any way I can instruct by MOJO to fail if there is an unknown
> >> parameter?
> >>
> >> Please advise
> >>
> >> Thank you
> >>
> >> --
> >>
> >> S. Ali Tokmen
> >> http://ali.tokmen.com/
> >>
> >> My IM, GSM, PGP and other contact details
> >> are on http://contact.ali.tokmen.com
> >>
> >>
> >> -
> >> 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
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>

Re: During plugin development, what is the context classloader set to?

[Baptiste Mathus]

Hi,
ClassWorlds is your friend if you need to do classloader fine-tuning.

For example (taken in an old poc, so this should be adapted to use
annotations etc.), something along the following would create a classpath
with test scope elements.

...
public class SomeMojo extends AbstractMojo
{
/**
 * @parameter expression="${project.testClasspathElements}"
 */
private
List<http://www.google.com/search?sitesearch=java.sun.com&q=allinurl%3Aj2se%2F1+5+0%2Fdocs%2Fapi+List>
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html>>
 testProjectArtifacts;
...
protected
ClassLoader<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html>
 getClassLoader()
{
try
{
ClassWorld world = new ClassWorld();
ClassRealm realm = world.newRealm("project");
for
(String<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html>
artifact
: testProjectArtifacts)
{
getLog().debug("Constituent : " + artifact);
realm.addConstituent(new
File<http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html>
(artifact).toURL());
}
return realm.getClassLoader();
}
catch
(Exception<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Exception.html>
 e)
{
throw new
RuntimeException<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/RuntimeException.html>
("WTF", e);
}
}

HTH


2014/1/8 Laird Nelson 

> I have a plugin that I'm writing that needs to do two things during the
> course of its execution:
> Load a resource from the current project's classpath
> Load a resource from its own guts
>
> This is a fallback kind of thing: if the plugin can't find anything
> appropriate on the project classpath, then and only then do I want it to
> examine its own .jar file for the resource in question.
>
> My hunch is that there are probably already two classloaders set up for
> just this purpose.
>
> I am guessing (haven't tried yet) that the project classpath is probably
> visible to Thread.currentThread().getContextClassLoader().  Is that right?
>
> I'm also guessing (haven't tried yet) that from within my mojo
> this.getClass().getClassLoader() will return me a ClassLoader that is set
> up to be able to see my mojo's innards.  Is that right?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <http://about.me/lairdnelson>

Re: short and snappy description of what Maven is

[Baptiste Mathus]

Lost battle imo.
Not sure there's a way to describe the difference between maven and gradle
in a way everyone would agree on...
Le 7 janv. 2014 03:42, "Ron Wheeler"  a
écrit :

> I am not sure that you want to start a range war in the opening paragraph.
> If there is a concise second or third sentence that clearly explains the
> difference between Ant and Maven, it would be a great idea to add that.
> If Gradle is likely to be in the running for a new developer, it might be
> interesting to have a sentence explaining the difference. Need to be
> careful not to turn off a new person by an obscure argument that does not
> address the decision points in a way that a new person would understand.
>
> Ron
>
> On 06/01/2014 4:33 PM, Stephen Connolly wrote:
>
>> I don't want a religious war. If Gradle or ANT are a better fit for the
>> way
>> some people think about building software... well good for them... and the
>> faster we can help them realise that Maven takes a different tack the
>> better.
>>
>> I happen to believe that the power of Maven comes from being model driven
>> rather than procedural, which ultimately allows for a richer IDE
>> experience, but consequently you lose some flexibility in your build
>> process. It is a tradeoff I happen to like the Maven balance of, but I am
>> not so arrogant to presume that Maven's balance suits everyone.
>>
>> The Maven repository has grown beyond just Maven, so that is no longer a
>> key differentiator for Maven.
>>
>> The differentiator is in the declarative build rather than procedural
>> build...
>>
>> With Ant you have a mostly pure procedural build.
>>
>> With Maven you have a mostly pure declarative build.
>>
>> With Gradle you have a hodge-podge mix of both.
>>
>> (By declarative, I mean jar is all I need to
>> declare, maven knows how everything fits into that)
>>
>> So let's let others go to the tools that suit their tastes, and the faster
>> that we help them there, the less bitching about how "Maven is crap
>> (because it doesn't suit my taste)" we will hear.
>>
>> It's like marmite: you either love it or hate it!
>>
>>
>> On 6 January 2014 20:08, Russell Gold  wrote:
>>
>>  Several sentences sounds good. But here’s another question. Comparing
>>> Maven to ant is almost too easy in terms of advantages. Is gradle now a
>>> serious competitor (I had been working on converting an enormous project
>>> to
>>> maven, but the architect decided to switch to gradle, so I am
>>> particularly
>>> sensitive to the issue). I can see some superficial advantages of gradle
>>> that might appeal to some projects. Is it better to ignore or address
>>> this?
>>>
>>> On Jan 6, 2014, at 3:02 PM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>>  On Monday, 6 January 2014, Ron Wheeler wrote:

  I think that the target has to be people deciding whether to try Maven.
> They initially want to know what it does and why it is better than Ant
>
 or
>>>
 whatever they are using now.
>
> Trying to teach Maven in a single sentence is too much to ask.
>
> "Maven is a build tool which consumes and produces artifacts managed in
>
 a
>>>
 repository." doesn't sound like it will help build my application.
> At the start, one doesn't have any artifacts or own a repository.
>
> "Apache Maven is a convention-over-configuration build tool which has
> great dependency management features."
>

 I think we should hint at the descriptive philosophy rather than the
 procedural philosophy most tools take


  is pretty clear for a single sentence description and it true.
> Maybe we can come up with a follow-up sentence to amplify/explain this
>
 one.
>>>
 Most programmers or project managers should be able to find the time to
> read 2 or maybe 3 sentences before deciding on a build tool.
> As long as each sentence draws the person deeper into Maven, that would
> work.
>

 Yes that is the idea


  Ron
>
>
> On 06/01/2014 12:57 PM, Russell Gold wrote:
>
>  Of course, you could say that about Gradle, too. And ant now does have
>> the ability to use those dependency features.
>>
>> I went through this when creating my video course (not in the sig
>>
> because
>>>
 this is work email). It’s not clear to me that you can make a one
>>
> sentence
>>>
 description that will provide sufficiently useful information unless
>> something like:
>>
>> "Maven is a build tool which consumes and produces artifacts managed
>>
> in a
>>>
 repository."
>>
>> But that is not going to help people coming new to the project.
>>
>> I think I am missing the motivation here.Is the target for this
>> description people deciding whether to try Maven? People trying to
>>
> learn
>>>
 how to use it?
>>
>> On Jan 6, 2014, at 12:43 PM, Lyons, Roy 

Re: Using Plugin Truncated Name

[Baptiste Mathus]

Hi Omar,
Well, what Stephen advices *is* actually at least a part of the solution
you're looking for.

Stephen says you MUST NOT use the org.apache.maven.plugins and
maven-yourplugin-plugin naming scheme because this is a naming strategy
reserved for core maven plugins.
See the first section of
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html for
example.

In your case, maybe even more specifically this page:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html

(btw, note the sentence "If your plugin's artifactId fits this pattern,
Maven will automatically map your plugin to the correct prefix in the
metadata stored within your plugin's groupId path on the repository").

HTH
Cheers


2014/1/6 Omar@Gmail 

> Thanks Stephen,
>
> What you suggest sounds like good practice (not sure why though) however
> not a fix for my issue.
>
> The fix is as follows: - somehow your response inspired me :)
>
> In the pom.xml file of the custom plugin there is a plugin configured
> maven-plugin-plugin in that plugin add configuration
>
> pce
>
> I then installed the plugin and I tried mvn pce:pull and that worked fine.
> Job done.
>
>
>
> On 6 January 2014 12:44, Stephen Connolly
> wrote:
>
> > On 6 January 2014 12:40, Omar@Gmail  wrote:
> >
> > > I have written my own maven mojo plugin and wish to use the truncated
> > name
> > > instead of the long name to invoke it, like so:
> > >
> > > Instead of
> > > mvn org.apache.maven.plugins:maven-pce-plugin:pull
> > >
> > > I want use:
> > >
> > > mvn pce:pull
> > >
> > > But even though I put it under group 'org.apache.maven.plugins' and
> named
> > > it maven-pce-plugin I still get error message:
> > >
> >
> > No don't put it there... you don't own that group Id.
> >
> > Put it in your own groupId and then in your settings.xml just add your
> > group Id as the 
> > http://maven.apache.org/settings.html#Plugin_Groups
> >
> >
> > > No plugin found for prefix 'pce' in the current project and in the
> plugin
> > > groups [*org.apache.maven.plugins*, org.codehaus.mojo] available from
> the
> > > repositories [local (C:\Users\omar\.m2\repository), central (
> > > http://repo.maven.apache.org/maven2)]
> > >
> > > What am I doing wrong? thanks for the help.
> > >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Re: Armed with a collection of Artifacts, what is the Maven Way™ to resolve them?

[Baptiste Mathus]

Does
http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java
help
you?

Cheers


2014/1/6 Laird Nelson 

> On Sun, Jan 5, 2014 at 3:56 PM, Laird Nelson  wrote:
>
> > What is the Maven Way™ to resolve these Artifacts?
> >
>
> For completeness, I also looked at
>
> http://maven.apache.org/guides/introduction/introduction-to-artifact-resolution.htmlbut
> this didn't seem to have ever been completed.
>
> Thanks,
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>



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

Re: New logo?

[Baptiste Mathus]

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



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

Re: Premature decomposition of projects

[Baptiste Mathus]

I guess Jeff is only speaking about version ranges, not snapshots.

If so, I'm +1 with Jeff. I don't think version ranges should ever be used.

Cheers
Le 23 nov. 2013 00:18, "Ziga GREGORIC"  a écrit :

> Jeff, maybe I'm missing the point, but to have the possibility to define a
> SNAPSHOT version of a dependency is the beauty of maven IMHO.
>
> Having said that, I would not feel safe in a large project where lots of
> dependencies are SNAPSHOT dependencies. But when you have a continuous
> integration server, all these SNAPSHOT dependencies will be in 'latest'.
> Ok, it's not really easy, as one might have more than one build agent,
> which implies the need for snapshot maven repository, but this is another
> topic (also on the first link of that thread, but I don't wanna go in
> there).
>
> When a release (with maven-release-plugin) is just a click of a button
> away, you can easily release a milestone version (1.2.03-M1), so the big
> majority of the team can work without the need to build internal SNAPSHOT
> dependencies or mixing own SNAPSHOTS with SNAPSHOTS from team's maven
> repository. Using this approach, you easily get repeatable builds. Only the
> team, intentionally working on both the main project and the dependency
> 'foo', would set 'foo' to SNAPSHOT in the main project. When 'foo' becomes
> feature complete, 'foo' get's released and its version incremented in the
> main project.
>
> The other way is to use buildnumber-maven-plugin, which would fetch source
> control revision number, branch name, which you can put into MANIFEST.MF -
> have a look at
> http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html
>
> @Viktor, I agree on you last point. When you high cohesion on maven project
> level, bring the projects together as a multi module maven project and
> versioning is no longer an issue for modules.
> The issue with snapshot repository is that you have to define who can
> publish and who can use these snapshot artifacts. When we need multiple
> build executors (build agents), and we have a project with a SNAPSHOT
> dependency on another project, we must have a snapshot maven repository and
> build agents configured to publish these SNAPSHOTs with every build. But
> this does not mean that every developer has to use this snapshot maven
> repository. I'd actually try to keep developers away from snapshots
> repository. This automatically forces the 'main' project to be easy on
> number of SNAPSHOT dependencies. If you have one, everyone is aware of it,
> as it has to be build separately (and one is sure of what revision that
> is).
>
> Sorry for my TL;DR style comment. I just wanted to share my experience
> dealing with non identified versions.
>
> Ziga
>
>
>
> On Fri, Nov 22, 2013 at 10:26 PM, Jeff MAURY  >wrote:
>
> > Having a build using non identified dependencies (LATEST,...) is a VERY
> bad
> > practice: the build is not reproducible and your team will not have
> > attentions on dependencies versions.
> > A non existing case for me.
> >
> > Jeff
> >
> >
> > On Fri, Nov 22, 2013 at 5:11 PM, Viktor Sadovnikov  > >wrote:
> >
> > > Hello,
> > >
> > > Here is an interesting article about dependencies management and builds
> > > with Maven, which can become unnecessary overcomplicated
> > > http://bit.ly/1dn9ZZL
> > >
> > > With regards,
> > > Viktor
> > >
> >
> >
> >
> > --
> > Jeff MAURY
> >
> >
> > "Legacy code" often differs from its suggested alternative by actually
> > working and scaling.
> >  - Bjarne Stroustrup
> >
> > http://www.jeffmaury.com
> > http://riadiscuss.jeffmaury.com
> > http://www.twitter.com/jeffmaury
> >
>

Re: Premature decomposition of projects

[Baptiste Mathus]

Wasn't it just the mvn -U to force updating snapshots you were looking for?

Cheers


2013/11/22 Russell Gold 

> It’s also an attempt to create a modular system, in hopes of minimizing
> codebase size and providing custom functionality. It’s thus closely related
> to a lot of the modularity ideas that have come and gone over time, without
> the judgment of what is properly a “module.” I’ve seen multi-hundred module
> projects.
>
> On Nov 22, 2013, at 1:33 PM, Ron Wheeler 
> wrote:
>
> > Looks like a kludge to get around a poor SOA architecture with too many
> inter-module dependencies and an unwillingness to build mock objects for
> testing.
> >
> > In our house, SNAPSHOTS posted to Nexus come with a warranty that they
> meet a subset of the spec that is known.
> > If someone doesn't like that level of instability, they should make mock
> objects that they understand.
> >
> > Ron
> >
> >
> > On 22/11/2013 11:11 AM, Viktor Sadovnikov wrote:
> >> Hello,
> >>
> >> Here is an interesting article about dependencies management and builds
> >> with Maven, which can become unnecessary overcomplicated
> >> http://bit.ly/1dn9ZZL
> >>
> >> With regards,
> >> Viktor
> >>
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> Author, Getting Started with Apache Maven <
> http://www.packtpub.com/getting-started-with-apache-maven/video>
>
> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
> and listen to the Misfile radio play <
> http://www.fuzzyfacetheater.com/misfile/>!
>
>
>
>
>
>
>
>


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

Re: Using Jenkins Mask Password plugin

[Baptiste Mathus]

Hi,
This list is for Maven users. What you ask should be posted on the Jenkins
users mailing list : https://groups.google.com/forum/#!forum/jenkinsci-users

Cheers


2013/11/13 Anand Sudabattula 

> Hi
>
> We like to mask the password that is provided thro’ cq.password parameter
> in Maven Goals using Mask Password plugin.
>
> I was reading about this plugin and found that it support only ANT based
> builds.
>
> I am new to Jenkins, please advise.
>
> Thanks in advance.
> Regards
> Anand
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

[ANN] extra-enforcer-rules 1.0-beta-2 Released

[Baptiste Mathus]

Hi,

The Mojo team is pleased to announce the release of the Extra Enforcer
Rules version 1.0-beta-2.

Apache's Maven Enforcer Plugin is used to apply and enforce rules on your
Maven projects.
The Enforcer plugin ships with a set of standard rules
The Mojo project hosts this project to provide extra rules which are not
part of the standard rule set.

http://mojo.codehaus.org/extra-enforcer-rules/

To get this update, simply specify the version in your project's plugin
configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  1.3.1
  

  org.codehaus.mojo
  extra-enforcer-rules
  1.0-beta-2

  


Basically, this releases mainly includes an evolution for the
enforceBytecodeVersion rule to be able to exclude some classes from the
enforcement (thanks Jesse & Kohsuke).

Release 
Notes
* Bug
** [MOJO-1980] - Add assertion message when corrupt classfile is detected
in enforceBytecodeVersion

* Improvement
** [MOJO-1976] - Artifact exclusion list for enforceBytecodeVersion

Enjoy,

The Mojo team.

-- Baptiste

Re: best way to attach source for debugging maven plugin

[Baptiste Mathus]

Hi,
I think you are just gonna have to retrieve the code manually inside your
ide.
Cheers
Le 6 nov. 2013 03:34, "Steve Cohen"  a écrit :

> I'm using Eclipse (with m2eclipse).  Basic problem there is that plugins
> are not normally dependencies of a maven project, therefore do not show up
> anywhere where I can apply the Maven-get source function.  I suppose I
> could make them dependencies but that seems wrong.
>
>
> On 11/05/2013 05:51 PM, Russell Gold wrote:
>
>> Bringing in the source should be a function of your editor. What are you
>> using? It works fine for me in IntelliJ
>>
>> - Russ
>>
>> On Nov 5, 2013, at 6:09 PM, Steve Cohen  wrote:
>>
>>  On 11/05/2013 04:22 PM, Olivier Lamy wrote:
>>>
 Use mvnDebug cli instead of mvn

 --
 Olivier
 On Nov 6, 2013 8:09 AM, "Steve Cohen"  wrote:

  I have a need to debug the maven-assembly-plugin which is not
> functioning
> correctly.  I have found the instructions for setting up a debugging
> environment for maven itself within eclipse.
>
> What is the best way to get the source for this plugin so that it can
> be
> used by the debugging process.  I know I can download it from svn, and
> attach in Eclipse, but is there a maven command to do that?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
  Thanks, I am using the mvnDebug cli.  That does seems to bring in the
>>> Maven (core and plugin source) but it does not bring in the source for the
>>> Codehaus Plexus stuff called by the plugin, which I also need to see for
>>> this debugging.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>> -
>> Author, Getting Started with Apache Maven > getting-started-with-apache-maven/video>
>>
>> Come read my webnovel, Take a Lemon ,
>> and listen to the Misfile radio play > com/misfile/>!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven compiler plugin

[Baptiste Mathus]

+1.
And BTW you should be aware that calling a dedicated goal should actually
be a rare use case using Maven. Maybe even more calling the compiler
outside the standard lifecycle.
Just type mvn compile for your first case and mvn test-compile for the
second one (not that last one would also compile SRC/main sources btw).
Cheers
Le 10 oct. 2013 14:44, "Russell Gold"  a écrit :

> Hi Irfan,
>
> The behavior you describe sounds surprising. Can you attach a full listing
> of the run when you do mvn compile:compile?
>
> Thanks,
> Russ
>
> On Oct 9, 2013, at 11:42 PM, Irfan Sayed  wrote:
>
> > hi,
> >
> > i am using maven compiler plugin. i havent mentioned anything related to
> > plugin in POM.xml
> >
> > i have just used the command on command prompt
> > mvn compiler:compile
> > what is happening is , above command compiles the test classes also .
> > however which should not be the case
> >
> > in my opinion, only main java source files should get compiled and when i
> > execute compiler:testcompile goal , then only test classes should get
> > compile
> >
> > please suggest how to just compile main source files and skip test cases
> > compilation
> >
> > regards
>
> -
> Author, Getting Started with Apache Maven <
> http://www.packtpub.com/getting-started-with-apache-maven/video>
>
> Come read my webnovel, Take a Lemon ,
> and listen to the Misfile radio play <
> http://www.fuzzyfacetheater.com/misfile/>!
>
>
>
>
>
>
>
>