Re: Where does shaded JAR get its POM?

[Benson Margulies]

On Mon, Sep 4, 2017 at 2:23 AM, Anders Hammar  wrote:
> On Mon, Sep 4, 2017 at 11:09 AM, Thomas Broyer  wrote:
>
>> AFAIK, as soon as you use a  in a dependency, the transitive
>> dependencies from its POM aren't used (actually, Maven might even not
>> download the POM at all in this case); so you should be OK using
>> shaded.
>>
>
> I don't think that's correct. One of the drawbacks with using classifiers
> is that there is just ONE pom, which is used for all artifacts.

+1

>
> /Anders
>
>
>> Note however that, this shaded JAR still depends on Guava, SLF4J API and
>> Immutables, so you'll have to add explicit dependencies on those.
>>
>> On Mon, Sep 4, 2017 at 7:36 AM Sander Verhagen 
>> wrote:
>>
>> > Hi list,
>> >
>> >
>> > Different microservices at one company often have some shared
>> > infrastructure, such as for Service Discovery. I'm looking to use the
>> > awesome Consul Client for Java (
>> > https://github.com/OrbitzWorldwide/consul-client), and build a library
>> > that our various (Maven-based Java) microservices can use. In order to
>> make
>> > our library not too invasive in terms of dependency resolution, I like
>> the
>> > idea of using Consul Client's "shaded JAR". I believe shaded JARs weren't
>> > really meant to be consumed by other Maven projects. But this may be a
>> > reasonable exception. But when you look at the output of such project
>> (like
>> > here:
>> > https://repo1.maven.org/maven2/com/orbitz/consul/consul-client/0.16.3/),
>> > you'll see a POM file with all the original dependencies, oblivious to
>> the
>> > shading. Is there any known pattern of dealing with that? Like: "POM
>> > classifiers" - I know, I made that up. I also know there's an option to
>> > generate a "dependency reduced POM", but what good does that do if I
>> can't
>> > depend on it? Should this project be generating two separate artifacts?
>> >
>> > (P.S.: I can certainly file an issue with the Consul Client project, but
>> I
>> > want to be more helpful than that, and offer a concrete suggestion or a
>> PR.)
>> >
>> > Thanks, Sander.
>> >
>> >
>> >
>> > Sander Verhagen
>> > [  san...@sanderverhagen.net  ]
>> >
>> >
>>

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

Re: Excluding certain files from compilation or checking

[Benson Margulies]

You have excluded it from the checkstyle plugin, but it's the Java
compiler which is discontented. You need to configure the compiler
plugin, as well.

On Sat, Aug 26, 2017 at 12:03 PM, Seth Goldstein  wrote:
> I would have expected that too, however:
>
>   
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.17
> 
>   
> validate
> validate
> 
>   check
> 
>   
> 
> 
>   config/checkstyle.xml
>   **/.,*.java
> 
>   
>
> And it reports that:
>
> [ERROR]
> /mnt/shared/seth/courses/619/f17/src/my-app/src/main/java/com/mycompany/app/.,foo.java:[7,7]
> error: class App is public, should be declared in a file named App.java
>
> So, still getting .,* files.  Wish this would work properly.
>
>
> --
> Seth Copen Goldstein
> Carnegie Mellon University
> Computer Science Dept
> 7111 GHC
> 412-268-3828
>
> On Sat, Aug 26, 2017 at 6:47 AM, Robert Scholte 
> wrote:
>
>> I would expect it to be **/.*
>> **/ means zero or more directories
>> .* any file with a dot followed by anything
>>
>> Robert
>>
>> ps. repeating the same element within configuration like you did with
>>  means the last one will win.
>>
>>
>> On Fri, 25 Aug 2017 23:26:58 +0200, Seth Goldstein  wrote:
>>
>> I am trying to exclude all files that begin with '.,' from being checked or
>>> compiled.  Is there a quick and easy way to do this?  The following does
>>> NOT work:
>>>
>>>   
>>> org.apache.maven.plugins
>>> maven-checkstyle-plugin
>>> 2.17
>>> 
>>>   
>>> validate
>>> validate
>>> 
>>>   check
>>> 
>>>   
>>> 
>>> 
>>>   .,*.java
>>>   **/.,*.java
>>>   **/**/.,*.java
>>>   **/**/**/.,*.java
>>>   **/**/**/**/.,*.java
>>>   **/**/**/**/**/.,*.java
>>>  src/main/java/com/mycompany/app/.,*.java
>>> 
>>>   
>>>
>>> Any suggestions?
>>>
>>> -seth
>>>
>>
>> -
>> 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: rat:check bad default?

[Benson Margulies]

On Fri, Jul 21, 2017 at 2:24 PM, Robert Scholte  wrote:
> Hi,
>
> just wondering, are both plugins part of the effective pom?
> When using a plugin prefix like "rat", Maven should first go over all
> plugins and verify if the prefix matches.
> Ensuring that org.apache.rat is above org.codehaus.mojo should help.

The Old Codehaus Rat is nowhere in our poms. The behavior is as if, in
the absence of a settings.xml for the user, org.codehaus.moho is
registered as a plugin group above org.apache.rat.

>
> thanks,
> Robert
>
> On Fri, 21 Jul 2017 19:48:08 +0200, Jason Kuster
>  wrote:
>
>> Hi,
>>
>> I had a problem which I was fighting with for a few hours before figuring
>> out. I was trying to run the rat plugin manually against my project by
>> invoking `mvn rat:check`. It was failing to pick up the configuration I
>> was
>> putting in my pom no matter what I did.
>>
>> I finally noticed after a while that I was configuring
>> org.apache.rat:apache-rat-plugin in my pom, but that mvn rat:check was
>> executing the `rat-maven-plugin` instead. It appears that the codehaus rat
>> maven plugin (last developed in 2007) is what is resolved by invoking
>> `rat`, and that running the modern rat plugin requires fully qualifying
>> the
>> name on the command line. I have two questions.
>>
>> First, is it possible to set an override in my project's pom to clarify
>> that when I or another developer execute `mvn rat:check` I mean
>> org.apache.rat:apache-rat-plugin instead of
>> org.codehaus.mojo:rat-maven-plugin?
>>
>> Second, is it possible to fix this on a more global scale so that other
>> folks don't run into the same problem in the future?
>>
>> Best,
>>
>> Jason
>
>
> -
> 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: rat:check bad default?

[Benson Margulies]

AFAIK, That can't be in pom, only settings, and there are many people
who would have to deal with this. Is the problem just that
org.codehaus.mojo is set up in the superpom as a popular destination?


On Fri, Jul 21, 2017 at 12:10 PM, John Patrick  wrote:
> Does this help?
> https://maven.apache.org/settings.html#Plugin_Groups
>
> Maybe something like this...
>
> 
> org.apache.maven.plugins
> org.apache.rat
> org.mojohaus.mojo
> org.codehaus.mojo
> 
>
> With codehaus dead, either moved to github or mojohaus, the scan
> ordering might need to be changed for future releases.
>
> Not sure if you can do it within the pom.xml, or it's purely a
> settings.xml change needed.
>
> John
>
>
> On 21 July 2017 at 18:48, Jason Kuster  wrote:
>> Hi,
>>
>> I had a problem which I was fighting with for a few hours before figuring
>> out. I was trying to run the rat plugin manually against my project by
>> invoking `mvn rat:check`. It was failing to pick up the configuration I was
>> putting in my pom no matter what I did.
>>
>> I finally noticed after a while that I was configuring
>> org.apache.rat:apache-rat-plugin in my pom, but that mvn rat:check was
>> executing the `rat-maven-plugin` instead. It appears that the codehaus rat
>> maven plugin (last developed in 2007) is what is resolved by invoking
>> `rat`, and that running the modern rat plugin requires fully qualifying the
>> name on the command line. I have two questions.
>>
>> First, is it possible to set an override in my project's pom to clarify
>> that when I or another developer execute `mvn rat:check` I mean
>> org.apache.rat:apache-rat-plugin instead of
>> org.codehaus.mojo:rat-maven-plugin?
>>
>> Second, is it possible to fix this on a more global scale so that other
>> folks don't run into the same problem in the future?
>>
>> Best,
>>
>> Jason
>
> -
> 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: Compiling from source with no previous Maven installed.

[Benson Margulies]

Maven is 100% Java. If you have a working JDK, you can expect any
binary Maven distro to unpack and then be usable to build other
versions. if you don't have a working JDK, you can't use Maven.


On Fri, May 19, 2017 at 4:35 AM, Ray Sheppard  wrote:
> Hello,
>   I have tried to find the proper directions in the documentation. However,
> all documentation seems to assume there is already a Maven installed or that
> I am simply installing binaries.  I am on an AMD/ XK-7 Cray.  I can not just
> plug in generic binaries and hope they understand the CLE 5.2 operating
> system.  However, there is no previous Maven installed.  I have installed
> JAVA JDK 1.8.0 already. Any help appreciated.
> Thanks,
> Ray
>
> -
> 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: dependency question

[Benson Margulies]

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
 wrote:
> I'm still a little confused about the answers I'm getting.  So, if build A is 
> being updated with a new build number(even for a snapshot), and build B has 
> it as a dependency in it's pom.file, how does the pom file in Build B need to 
> look like in the dependency section so that it does get the latest snapshot 
> build of build A ?

This conversation seems to keep mixing up SNAPSHOT version processing
with various conventions for using version ranges.

If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
to the repositories to look for the latest snapshot build.

Snapshots have risks and do not provide a repeatable build. Then
again, neither do ranges.

If you don't want to use snapshots, then you write the dependency in
the consumer with a range

(1.0-2.0]

or whatever makes sense. This will cause builds of the consumer to go
out to repositories and try to find the newest version within the
range. it's up to you to bump the version in the producer, manually or
with the maven-release-plugin.




>
> Scenario:
>
> Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot and 
> they are all being uploaded to a repository.
>
> What will the pom file in build B look like so that the next time build B is 
> executed,  3-snapshot for build A will be picked up ?
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, April 7, 2017 10:50 AM
> To: Maven Users List 
> Subject: Re: dependency question
>
> Hi Russlel,
> On 07/04/17 17:29, Russell Gold wrote:
>
>> That’s the way it works: when you specify a snapshot, it takes the latest.
>
> This is not 100% true, cause it depends on the update policy you have
> defined in your settings either explicit or by default the updates will
> be checked every 24 hours...
>
> If you like to force this you can use mvn -U ...or define a different
> updatePolicy in your settings.xml for the appropriate repository.
>
> By using mvn -U you make sure for running this build Maven will check if
> there are newer SNAPSHOT version available for dependencies which have
> defined a SNAPSHOT version
>
> This is working for a single module project...but if you have a multi
> module build (Project C: A1 build before A2) which takes for example 5
> minutes to build ...this is no longer 100% true...
>
> Now let us assume you have another project B which dependends on two
> different artifacts (A1, A2) of Project C ...this means in consequence
> those artifacts are build at two different times...
>
> This means it could happen that your build of Project B consumes A2 from
> build #10 but A1 from build #9 ...
>
>
> In practical it usually works without any issue using the mvn -U ...but
> you should be aware of this issue...
>
>
> The only solution which I have found to make 100% sure is to use the
> output during the build of the project A and use those parsed
> informations about the SNAPSHOT versions and inject them into my current
> build ...(https://github.com/khmarbaise/deployment-recorder-extension
> not ready yet)...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>> There are some corner cases where it won’t. I think it only checks for a new 
>> snapshot every few hours or so, so if you are putting out a lot you might 
>> conceivably miss one. You can reset that if you need to
>> .
>>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector  
>>> wrote:
>>>
>>> If the builds for A are always getting a unique build number as a snapshot 
>>> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
>>> there a way to name the A snapshot builds with a unique build number each 
>>> time for this scenario.
>>>
>>> -Original Message-
>>> From: Russell Gold [mailto:russell.g...@oracle.com]
>>> Sent: Thursday, April 6, 2017 2:27 PM
>>> To: Maven Users List 
>>> Subject: Re: dependency question
>>>
>>> The simplest way is simply to use a snapshot version of A. That way B will 
>>> always use the latest snapshot. When you finally release A, you can have B 
>>> point to the released version instead of the snapshot.
>>>
 On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  
 wrote:

 I have to 2 java projects a and b in maven.  The B project uses the A 
 build as a dependency.  How do I ensure the whenever the A project has a 
 new build,  the B project will always use that latest build in A.  A is 
 being built with a unique build number each time it gets built.  So is A 
 has build # 10 as the newest build,  the B project has to use build #10 of 
 A.


 Hector Magnanao Jr.
 SCM Analyst
 SAP Fieldglass
 Skype:  (331) 702-6142
 Mobile:  (847) 857-8401
 Email: hector.magna...@sap.com

Re: vcmcvsssh.jar

[Benson Margulies]

On Sun, Mar 5, 2017 at 1:35 PM, Martin Gainty  wrote:
> can you suggest a developer list that is responsible for maintaining eclipse 
> 2.0?

You are joking, right? Maintain? It's ancient and obsolete. It might
be archived somewhere.

>
>
> vielen danke her eckenfels
>
> Martin
> __
>
>
>
> 
> From: Bernd Eckenfels 
> Sent: Sunday, March 5, 2017 3:24 PM
> To: users@maven.apache.org; Maven Users List
> Subject: Re: vcmcvsssh.jar
>
> Hello,
> I guess you better ask the Eclipse Team project. I would suspect you find the 
> libraries only in the historic Eclipse 2.0 archives.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
>
>
>
> On Sun, Mar 5, 2017 at 7:45 PM +0100, "Martin Gainty"  
> wrote:
>
>
>
>
>
>
>
>
>
>
> anyone know where i can acquire org.eclipse.vcm library?
>
> the eclipse vcm library is supposed to be available in vcmcvsssh.jar which i 
> cannot locate
>
>
> Thanks!
>
> Martin
> __
>
>
>
>
>
>
>

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

Anyone have evidence that javadoc:aggregate-jar works as a goal in a pom file?

[Benson Margulies]

The maven javadoc plugin source tree has no IT's for the aggregate-jar
goal. When I try it in a seemingly obvious way, it fails by feeding
the javadoc tool no java files to process.

Can someone point to a working example?

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

Managing offline links across a multi-module project with javadoc

[Benson Margulies]

I just tried to configure some offline links in pluginManagement. I
find that this doesn't not seem to be possible, since the pathnames
are interpreted relative to each module. Has anyone else come up with
a solution to this?

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

Re: Excluding -beta-N from a range

[Benson Margulies]

On Sun, Jan 15, 2017 at 3:01 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi,
>
> On 13/01/17 16:37, Benson Margulies wrote:
>>
>> On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz <fscha...@assona.net>
>> wrote:
>>>
>>> Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
>>>
>>>> I agree with them that this is counter-intuitive. The whole point of
>>>> -beta-1 is to introduce new, incompatible, stuff. The whole point of
>>>> that range is to exclude it.
>
>
> If you introduce incompatible stuff you should call it 3.X cause based on
> SemVer[1] this would be the way to go...

Yes, indeed, that's exactly what we are doing. We make incompatible
changes, and we move the version from 1.x.y to 2.0.0-beta-1-SNAPSHOT,
and we're still included in the range 2), the job of which is to
_exclude_ 2.0.

>
>
> [1]: http://semver.org/
>
>>>
>>> Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
>>> that the final 2.0.0 release will include everything that's in this
>>> beta, thus the range quite correctly contains it...?
>>
>>
>>
>> The range [1,2) excludes 2.0.0.
>
>> So, by your logic, which is my logic,
>>
>> it should also exclude the beta.
>
>
> The range [1,2) excludes 2.0.0 cause 2 is equal to 2.0 and equal to 2.0.0
> BUT 2.0.0-beta is less than 2.0 which means it is included the range
> ...cause based on the timeline 2.0-beta is before 2.0
>
> So in the end it does not exclude the beta...
>
>>>
>>> If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
>>> release, wouldn't it be better called 2.0.1-beta1?
>>>
>>> Just curious because we had some discussions about versioning strategies
>>> here, too, a while ago.
>
>
> Yes I agree...
>
> If you having changes which will not being part of 2.0.0 you should call
> that 2.1.0-beta BUT NOT 2.0.0-beta1 be aware of the timeline
>
> 1.0 ... 2.0.0-beta1  2.0.0 ... 2.0.1 ... 2.1.0 ..
>
> If you like having something which should be introduces after releasing
> 2.0.0 you have to call it 2.0.1-WhatEver or 2.1.0-WhatEver...
>
>
> Kind regards
> Karl Heinz Marbaise
>
>>>
>>> Regards,
>>>
>>> Flo
>>
>>
>
> -
> 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: Excluding -beta-N from a range

[Benson Margulies]

On Thu, Jan 12, 2017 at 11:42 PM, Florian Schätz <fscha...@assona.net> wrote:
> Am Donnerstag, den 12.01.2017, 14:22 -0800 schrieb Benson Margulies:
>
>> I agree with them that this is counter-intuitive. The whole point of
>> -beta-1 is to introduce new, incompatible, stuff. The whole point of
>> that range is to exclude it.
>
> Doesn't 2.0.0-beta1 imply that it's a beta for the 2.0.0 release, so
> that the final 2.0.0 release will include everything that's in this
> beta, thus the range quite correctly contains it...?


The range [1,2) excludes 2.0.0. So, by your logic, which is my logic,
it should also exclude the beta.
>
> If the stuff from the 2.0.0-beta1 will not be part of the final 2.0.0
> release, wouldn't it be better called 2.0.1-beta1?
>
> Just curious because we had some discussions about versioning strategies
> here, too, a while ago.
>
> Regards,
>
> Flo

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

Re: Excluding -beta-N from a range

[Benson Margulies]

On Thu, Jan 12, 2017 at 2:57 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:
> Hi Benson,
>
>> I did not know how to tell them how to write a range that has the
>> desired effect. Is there one?
>
> Would it work to use a hacky range like:
> [1.0.0,1..]

That is my fallback advice to them, indeed.

The no '.0.0' release advise will be a bitter pill to swallow.



> ?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>
>
> On Thu, Jan 12, 2017 at 4:52 PM, Mark Derricutt <m...@talios.com> wrote:
>
>> Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact
>> for this exact reason.
>>
>> Always start with .1
>>
>> Mark
>>
>> --
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
>>
>> On 13 Jan 2017, at 11:22, Benson Margulies wrote:
>>
>> > I did not know how to tell them how to write a range that has the
>> > desired effect. Is there one?
>>

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

Excluding -beta-N from a range

[Benson Margulies]

Coworkers of mine just got bit, badly, by the following:

a range like:

[1.0.0,2.0.0)

INCLUDES

2.0.0-beta-1.

I agree with them that this is counter-intuitive. The whole point of
-beta-1 is to introduce new, incompatible, stuff. The whole point of
that range is to exclude it.

I did not know how to tell them how to write a range that has the
desired effect. Is there one?

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

Re: Download & Caching Text Artifacts (XML schema) with Maven

[Benson Margulies]

Svante,

I bet that problem isn't 'unchangeable', but rather the license.

Anyway, it's easy to do what you want.

Read http://central.sonatype.org/pages/ossrh-guide.html.

You will probably want to put the schema into a zip or tar file, though you
can leave it 'naked'. You set up a github.com repo with a pom that uses the
build-helper-maven-plugin to attach the schema file(s) and then you can run
'mvn deploy'.

Then use the maven-dependency-plugin to pull it down in your build.

--benson



On Sun, Dec 4, 2016 at 6:22 AM, Svante Schubert 
wrote:

> Hi,
>
> In the Apache ODF Toolkit (incubating) project we are generating Java
> classes from the ODF XML schema. For this reason, we need to download the
> OASIS ODF XML schema, as Apache does not allow to have unchangeable
> artifacts within the source repository. On the other hand, I would love to
> build offline, without the need to download these schemas over and over
> again for every build. Similar as other Maven dependencies these schemas
> would be great to store within .m2
>
> What is the common Maven way to do such thing. Do you have any pointers,
> examples of a similar problem solution?
>
> Kind regards,
> Svante
> ᐧ
>

Re: Structuring bigger Maven projects

[Benson Margulies]

An alternative, which I never fully explored, is the CI/CD approach.
Don't use the release plugin. Use -D, or an extension, to set a
unique, non-snapshot, version for each build, and then use version
ranges for the dependencies. I built an experimental extension at my
last job to automatically set a rev property from the current git
commit, but it wasn't entirely satisfactory.


On Wed, Nov 30, 2016 at 1:44 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
>
>
> On 30/11/16 19:18, Florian Schätz wrote:
>>>
>>> A library project to be
>>> shared between multiple applications each having its own release-cycle
>>> should not be part of a multi-module project used to build such an
>>> application and should be an independent project with its own
>>> release-cycle.
>>
>>
>> While this is of course a good idea, especially when starting to create
>> new applications, the library projects will grow with the applications
>> and not independently of them. We cannot start by first investing months
>> to create the perfect will-work-for-ten-years library and only then
>> start coding the application that will, in the first months, only use
>> 10% of all these features. So, realistically, during a development
>> cycle, both the application and the library will grow... (which doesn't
>> mean that we cannot separate them)
>>
>> Which leads me, for example, to the problem that I still want to
>> automate as much as possible. I would like, for example, to click one
>> button in my build server, perhaps enter some parameters and get a new
>> release candidate of the libraries from the current release branch,
>> update the dependency version of the application to this rc version,
>> make the application an rc (from the application's release branch),
>> install them both into the repository, tag the current status on git and
>> deploy the rc application onto the server.
>>
>> Especially for bigger projects, I want to keep the amount of manual work
>> needed as small as possible. As much building should be done
>> automatically, if possible. And I would like not having to code a
>> jenkins or maven plugin for that purpose (but of course, I would, if
>> needed, no problem there).
>
>
>
> You can simply use maven-release-plugin (in Maven itself) which you can used
> to  fully automatically create releases of your project...This will need
> only a plugin in Jenkins which handles all those stuff...correctly
> configured things like scm entries in your pom file tagging in Git will be
> done as well
>
> Sometimes you might need to improve that using the versions-maven-plugin in
> combination with some pipeline steps in Jenkins...which prevents some
> drawbacks of the maven-release-plugin
>
>
> May be you need to think about using the Maven integration in Jenkins or
> using freestyle projects or better start using pipelines ...(I often
> observed performance drawbacks in relationship with Maven integration in
> Jenkins)...
>
>
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
> -
> 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: Need to fully understand bad implications of combined aggregator and parent pom

[Benson Margulies]

My experience is precisely the opposite of yours. The most common
practice is for the parent to be the aggregator; it's hard to get the
site plugin, for example, to work right with your preferred structure
where they are different.

I have built many projects with the the one-parent structure, and they
typically have interdependencies between the modules, and they work
fine.  Can you boil this down to a failing case on github? Can you
share some poms?


On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID  wrote:
> A while ago, I started working on an existing project with many developers.  
> The codebase has a large multi-project Maven build.  The top directory is 
> both an "aggregator" and "parent" POM, as it has a "modules" list, and all of 
> the child modules have it as their parent POM, for dependencies and plugins.
>
> I've always believed this is a defective architecture.  I believe that the 
> top-level directory should have an "aggregator" POM that just lists the 
> modules to build, and a subdirectory of the top-level directory should have a 
> project that just defines the parent POM, which defines dependencies and 
> plugins for subprojects to use.
>
> Although I feel this is a "cleaner" architecture, I've never been able to 
> cite specific problems with the other approach, besides the fact that module 
> changes and dependency/plugin changes go in the same file, which is still a 
> "cleanliness" argument.
>
> Today I think I saw a real reason why the present architecture is a problem, 
> but I need to be certain the problem I'm seeing is caused by this, and that 
> the better architecture fixes this problem, and whether there is a simple 
> workaround in the meantime.
>
> I've been modifying the build to use a completely new intranet maven repo and 
> completely different groupids for the build artifacts.
>
> I saw errors like this (with elisions):
> ---
> [INFO] Reactor Summary:
> [INFO]
> [INFO] big-parent . FAILURE [  5.230 
> s]
> [INFO] some-other-module... SKIPPED
> [INFO] another-module.. SKIPPED
> [INFO] .SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 8.063 s
> [INFO] Finished at: 2016-11-29T16:23:36-08:00
> [INFO] Final Memory: 41M/1093M
> [INFO] 
> 
> [ERROR] Failed to execute goal on project some-other-module: Could not 
> resolve dependencies for project 
> com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not find 
> artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in 
> mycomp-public-group 
> (http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/mycomp-public-group/)
>  -> [Help 1]
> [ERROR]
> ---
>
> The "big-parent" module is the top-level directory that is both the 
> aggregator and parent pom.
>
> Conceptually, I think this is happening because Maven is trying to evaluate 
> dependencies before those dependencies are built.  Again, I think the 
> "separated" architecture will resolve this, but before I implement that, I 
> need to understand exactly what is going on here.
>
> In my local workspace, I got around this by simply "cd"ing to the 
> "another-module" directory and doing a "mvn install", then "cd"ing to 
> "some-other-module", doing the same, and then doing the same again at the top 
> level. The reality was messier than this, because I had quite a few modules 
> that I had to build manually this way.
>
> Assuming I'm right that separating the "parent" function from the 
> "aggregator" function would resolve this, can someone explain exactly what is 
> happening here, how my assumed solution would resolve this, and whether 
> there's a cleaner temporary workaround besides "cd"ing into each directory to 
> do a separate install?
>
> -
> 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

When does 'mvn clean' look for dependencies?

[Benson Margulies]

In spite of the 'warning', this fails the build. Maven 3.3.9.

[INFO] Scanning for projects...
[INFO] Inspecting build with total of 1 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 1 executions of maven-deploy-plugin replaced with
nexus-staging-maven-plugin
[INFO]
[INFO]

[INFO] Building rosapi-headless-doc 1.4.102-SNAPSHOT
[INFO]

[WARNING] The POM for
com.basistech.ws:rosapi-headless-framework:jar:1.4.102-SNAPSHOT
is missing, no dependency information available

Re: Comparing specifying repositories in pom vs. settings.xml?

[Benson Margulies]

Our experience is that the not-central repos aren't reliable over the
medium term. So, if we can't get it to go to central, we copy it into
our own copy of Nexus. This is, of course, not a helpful strategy for
anything that has to be maintained 'out in the open'.

On Wed, Oct 19, 2016 at 11:16 AM, KARR, DAVID  wrote:
>> -Original Message-
>> From: Mark H. Wood [mailto:mw...@iupui.edu]
>> Sent: Wednesday, October 19, 2016 5:55 AM
>> To: users@maven.apache.org
>> Subject: Re: Comparing specifying repositories in pom vs. settings.xml?
>>
>> OK, I'm going to learn a lot from this thread.
>>
>> On Tue, Oct 18, 2016 at 06:57:42AM -0700, Robert Patrick wrote:
>> > But in a large corporate environment, the centralized repository
>> manager can house hundreds/thousands of repositories so unless you want
>> to virtualize the entire set of repositories (which tends to make the
>> repository manager slower), you still need to specify the repositories
>> to search, right?
>>
>> We have a local Nexus instance, and besides a mirror of Central and a
>> couple of others, there are just two non-mirror repositories:
>> local-snapshots and local-releases.  Why would you have more than these?
>
> Our "Nexus instance" maintains artifacts for a very large number of projects, 
> most of which are managed by different teams that prefer, and often require 
> (by NDA, et cetera), to keep their artifacts separate from the artifacts from 
> other projects.  It's not unusual for some people to work on different sets 
> of projects, requiring different sets of repositories.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: maven-clean-plugin on strike, sort of?

[Benson Margulies]

There turned out to be leftover java processes from surefire bugs(?)
that were indeed constantly creating more content.


On Fri, Oct 14, 2016 at 8:58 AM, Rich Seddon <rsed...@sonatype.com> wrote:
> A guess...  there may be a process spawned by your tests that is still
> running, and is recreating this directory.
>
> On Friday, October 14, 2016, jieryn <jie...@gmail.com> wrote:
>
>> And the dir mismatch in your example is just because of multiple runs?
>>
>> On Thu, Oct 13, 2016 at 8:50 PM, Benson Margulies <bimargul...@gmail.com
>> <javascript:;>> wrote:
>> > ➜ tests git:(master) ls -l
>> > /Users/benson/x/rosapi1.5/itests/tests/target/pax/
>> 6c7a5d80-3080-482f-abb4-394d9a782ef2/data
>> > total 24
>> > -rw-r--r--  1 benson  staff  5 Oct 13 20:47 port
>> > -rw-r--r--  1 benson  staff  7 Oct 13 20:47 rosette-usage.yaml
>> > -rw-r--r--  1 benson  staff  7 Oct 13 20:47 rosette-usage.yaml.backup
>> >
>> > rm -rf is perfectly capable of deleting it.
>> >
>> > and yet, mvn clean fails.  Any ideas? It's repeatable.
>> >
>> > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
>> > clean project: Failed to delete
>> > /Users/benson/x/rosapi1.5/itests/tests/target/pax/
>> 4ba14215-319e-4688-95a0-d00997dd5fdc/data
>> > at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:215)
>> > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
>> DefaultBuildPluginManager.java:134)
>> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:207)
>> > ... 20 more
>> > Caused by: java.io.IOException: Failed to delete
>> > /Users/benson/x/rosapi1.5/itests/tests/target/pax/
>> 4ba14215-319e-4688-95a0-d00997dd5fdc/data
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:249)
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:191)
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
>> > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:117)
>> > at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:193)
>> > ... 22 more
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> <javascript:;>
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> <javascript:;>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org <javascript:;>
>> For additional commands, e-mail: users-h...@maven.apache.org
>> <javascript:;>
>>
>>

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

maven-clean-plugin on strike, sort of?

[Benson Margulies]

➜ tests git:(master) ls -l
/Users/benson/x/rosapi1.5/itests/tests/target/pax/6c7a5d80-3080-482f-abb4-394d9a782ef2/data
total 24
-rw-r--r--  1 benson  staff  5 Oct 13 20:47 port
-rw-r--r--  1 benson  staff  7 Oct 13 20:47 rosette-usage.yaml
-rw-r--r--  1 benson  staff  7 Oct 13 20:47 rosette-usage.yaml.backup

rm -rf is perfectly capable of deleting it.

and yet, mvn clean fails.  Any ideas? It's repeatable.

Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
clean project: Failed to delete
/Users/benson/x/rosapi1.5/itests/tests/target/pax/4ba14215-319e-4688-95a0-d00997dd5fdc/data
at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:215)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: java.io.IOException: Failed to delete
/Users/benson/x/rosapi1.5/itests/tests/target/pax/4ba14215-319e-4688-95a0-d00997dd5fdc/data
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:249)
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:191)
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)
at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:117)
at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:193)
... 22 more

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

Re: Jenkins and Maven

[Benson Margulies]

So, here's a specific puzzle. I want to enable multiple branches in
the Jenkins job and concurrent builds. How do I avoid two jobs trying
to write the same local repo at the same time?

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

Re: Jenkins and Maven

[Benson Margulies]

Thanks, Stephen.

Now, if surefile would stop failing with:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test
(default-test) on project rosapi-front-end-anvils-transport: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.18:test failed.
NullPointerException -> [Help 1]

after printing its summary message, all would be well.


On Thu, Oct 13, 2016 at 10:16 AM, swapnil barwat
<swapnilbar...@gmail.com> wrote:
> +1 for pipeline build.
>
> On Thu, Oct 13, 2016 at 10:15 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> https://javaadventure.blogspot.ie/2013/11/jenkins-
>> maven-job-type-considered-evil.html
>> is the message from your friendly neighbourhood Apache Maven PMC member and
>> Jenkins committer!
>>
>> Two options:
>> 1. (oldschool) Freestyle Job with a Maven build step
>> 2. (coolkids) Multibranch Pipeline Job with a Jenkinsfile in the
>> repository... At present the Jenkinsfile will have to invoke Maven via a
>> shell/batch step... which gets a tad ugly
>>
>> node() {
>>   withMaven(...) {
>>   if (isUnix()) {
>> sh 'mvn clean verify'
>>   } else {
>> bat 'mvn clean verify'
>>   }
>>   junit '**/target/surefire-reports/*.xml, **/target/failsafe-reports/*.
>> xml'
>>   // plus whatever else you are having yourself
>>   }
>> }
>>
>> There is a dedicated `mvn` step in the works... not here yet... and there
>> is a newer better syntax for Jenkinsfile in progress:
>> https://github.com/jenkinsci/pipeline-model-definition-plugin
>>
>> So hopefully, you'll soon be able to do
>>
>> pipeline {
>>   agent label:'linux'
>>   stages {
>> stage('Build') {
>>   // the syntax to specify the Maven tool version is still in progress
>>   steps {
>> mvn 'clean verify'
>> // remains to be seen if the `mvn` step will auto-junit
>>   }
>> }
>>   }
>>   notifications {
>> always {
>>   mail ...
>> }
>>   }
>> }
>>
>> On 13 October 2016 at 14:59, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>>
>> > We've about had it with bamboo, and are dusting off our old Jenkins
>> > instance.
>> >
>> > I recall some messages here about things _not_ to do with Jenkins and
>> > Maven. Do we avoid the 'maven build type' altogether and just run
>> > Maven from the shell, or is my memory faulty? Anything else.
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
>
>
> --
> regards..
> Swapnil Barwat

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

Jenkins and Maven

[Benson Margulies]

We've about had it with bamboo, and are dusting off our old Jenkins instance.

I recall some messages here about things _not_ to do with Jenkins and
Maven. Do we avoid the 'maven build type' altogether and just run
Maven from the shell, or is my memory faulty? Anything else.

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

Re: Aw: Re: Re: [Regression] Declared properties could not be modified anymore within a plugin

[Benson Margulies]

Now I get the same thing you do. I better see what's broken in my builds.


On Mon, Oct 10, 2016 at 10:00 AM, Benson Margulies
<bimargul...@gmail.com> wrote:
> That's odd. Let me run my test again.
>
>
> On Mon, Oct 10, 2016 at 8:44 AM, Robert Patrick
> <robert.patr...@oracle.com> wrote:
>> I can confirm that it is not possible to override a project property in a 
>> plugin with Maven 3.3.9.  I am not sure what the expected behavior is but 
>> trying to override a pre-initialized value (from command-line -Ds, 
>> .mvn/maven.config, or the POM) from a plugin has no effect...
>>
>>
>> -Original Message-
>> From: M. Richey [mailto:mric...@gmx.de]
>> Sent: Monday, October 10, 2016 4:16 AM
>> To: users@maven.apache.org
>> Cc: Maven Users List
>> Subject: Aw: Re: Re: [Regression] Declared properties could not be modified 
>> anymore within a plugin
>>
>> Thanks Benson, but it does not work for me.
>>
>> During the execution it says:
>>
>> [main] [DEBUG] define property osgi-version = "1.0.0.v20161010082844"
>>
>> But in the MANIFEST.MF it says:
>>
>> Manifest-Version: 1.0
>> Built-By: maik
>> demo: bad
>> Created-By: Apache Maven 3.3.9
>> Build-Jdk: 1.8.0_66
>>
>> So, as I said before, during the execution the property gets set and the 
>> pre-initialized value is used afterwards.
>>
>> Best regards,
>>
>> Maik
>>
>>
>>> Gesendet: Samstag, 08. Oktober 2016 um 16:45 Uhr
>>> Von: "Benson Margulies" <bimargul...@gmail.com>
>>> An: "Maven Users List" <users@maven.apache.org>
>>> Betreff: Re: Re: [Regression] Declared properties could not be
>>> modified anymore within a plugin
>>>
>>> https://github.com/benson-basis/prop-override-example
>>>
>>> Seems to be a demo that
>>>
>>> https://github.com/basis-technology-corp/basis-build-helper-maven-plug
>>> in
>>>
>>> overrides properties.
>>>
>>> Using:
>>>
>>> private void defineProperty(String name, String value) {
>>> if (getLog().isDebugEnabled()) {
>>>   getLog().debug("define property " + name + " = \"" + value + "\"");
>>> }
>>> project.getProperties().put(name, value); }
>>>
>>>
>>> On Tue, Oct 4, 2016 at 4:03 PM, Benson Margulies <bimargul...@gmail.com> 
>>> wrote:
>>> > On Tue, Oct 4, 2016 at 5:35 AM, M. Richey <mric...@gmx.de> wrote:
>>> >> Thanks Benson to point that out, it's a good example.
>>> >>
>>> >> We have several use cases where we modify properties with our plugins. 
>>> >> We have a large variety of our software which to build for up to three 
>>> >> brands. For which brand a specific software is to build is defined 
>>> >> outside the poms and provided by our plugin. As we all know you can't 
>>> >> loop inside the poms. So we execute a plugin once for each brand to find 
>>> >> out if this variant should be build for the brand specified. Therefore 
>>> >> we defined a property in the pom.xml, pre-initialized with a default 
>>> >> value, and if the software should be build for one brand, the brand is 
>>> >> appended to the list, i.e. the value of the property, during the 
>>> >> execution of our plugin. So the value of the property may be something 
>>> >> like "default,brand1,brand3" after the executions of the plugin.
>>> >>
>>> >> So for us it is a blocker at the moment that one can't modify properties 
>>> >> during the execution of a plugin anymore.
>>> >>
>>> >> Benson, you said you have some of these working with 3.3.9. Can you give 
>>> >> an example of a plugin where this is working? I would like to see how 
>>> >> they are doing it in their code.
>>> >
>>> > I'd better do a test to ensure that they are working as well as I
>>> > think they are and then get back to you.
>>> >>
>>> >> Kind regards,
>>> >>
>>> >> Maik
>>> >>
>>> >>
>>> >>
>>> >>> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
>>> >>> Von: "Benson Margulies" <bimargul...@gmail.com>
>>> >>> An: "Maven Users List"

Re: Aw: Re: Re: [Regression] Declared properties could not be modified anymore within a plugin

[Benson Margulies]

That's odd. Let me run my test again.


On Mon, Oct 10, 2016 at 8:44 AM, Robert Patrick
<robert.patr...@oracle.com> wrote:
> I can confirm that it is not possible to override a project property in a 
> plugin with Maven 3.3.9.  I am not sure what the expected behavior is but 
> trying to override a pre-initialized value (from command-line -Ds, 
> .mvn/maven.config, or the POM) from a plugin has no effect...
>
>
> -Original Message-
> From: M. Richey [mailto:mric...@gmx.de]
> Sent: Monday, October 10, 2016 4:16 AM
> To: users@maven.apache.org
> Cc: Maven Users List
> Subject: Aw: Re: Re: [Regression] Declared properties could not be modified 
> anymore within a plugin
>
> Thanks Benson, but it does not work for me.
>
> During the execution it says:
>
> [main] [DEBUG] define property osgi-version = "1.0.0.v20161010082844"
>
> But in the MANIFEST.MF it says:
>
> Manifest-Version: 1.0
> Built-By: maik
> demo: bad
> Created-By: Apache Maven 3.3.9
> Build-Jdk: 1.8.0_66
>
> So, as I said before, during the execution the property gets set and the 
> pre-initialized value is used afterwards.
>
> Best regards,
>
> Maik
>
>
>> Gesendet: Samstag, 08. Oktober 2016 um 16:45 Uhr
>> Von: "Benson Margulies" <bimargul...@gmail.com>
>> An: "Maven Users List" <users@maven.apache.org>
>> Betreff: Re: Re: [Regression] Declared properties could not be
>> modified anymore within a plugin
>>
>> https://github.com/benson-basis/prop-override-example
>>
>> Seems to be a demo that
>>
>> https://github.com/basis-technology-corp/basis-build-helper-maven-plug
>> in
>>
>> overrides properties.
>>
>> Using:
>>
>> private void defineProperty(String name, String value) {
>> if (getLog().isDebugEnabled()) {
>>   getLog().debug("define property " + name + " = \"" + value + "\"");
>> }
>> project.getProperties().put(name, value); }
>>
>>
>> On Tue, Oct 4, 2016 at 4:03 PM, Benson Margulies <bimargul...@gmail.com> 
>> wrote:
>> > On Tue, Oct 4, 2016 at 5:35 AM, M. Richey <mric...@gmx.de> wrote:
>> >> Thanks Benson to point that out, it's a good example.
>> >>
>> >> We have several use cases where we modify properties with our plugins. We 
>> >> have a large variety of our software which to build for up to three 
>> >> brands. For which brand a specific software is to build is defined 
>> >> outside the poms and provided by our plugin. As we all know you can't 
>> >> loop inside the poms. So we execute a plugin once for each brand to find 
>> >> out if this variant should be build for the brand specified. Therefore we 
>> >> defined a property in the pom.xml, pre-initialized with a default value, 
>> >> and if the software should be build for one brand, the brand is appended 
>> >> to the list, i.e. the value of the property, during the execution of our 
>> >> plugin. So the value of the property may be something like 
>> >> "default,brand1,brand3" after the executions of the plugin.
>> >>
>> >> So for us it is a blocker at the moment that one can't modify properties 
>> >> during the execution of a plugin anymore.
>> >>
>> >> Benson, you said you have some of these working with 3.3.9. Can you give 
>> >> an example of a plugin where this is working? I would like to see how 
>> >> they are doing it in their code.
>> >
>> > I'd better do a test to ensure that they are working as well as I
>> > think they are and then get back to you.
>> >>
>> >> Kind regards,
>> >>
>> >> Maik
>> >>
>> >>
>> >>
>> >>> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
>> >>> Von: "Benson Margulies" <bimargul...@gmail.com>
>> >>> An: "Maven Users List" <users@maven.apache.org>, i...@soebes.de
>> >>> Betreff: Re: [Regression] Declared properties could not be
>> >>> modified anymore within a plugin
>> >>>
>> >>> On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
>> >>> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > On 30/09/16 15:20, mric...@gmx.de wrote:
>> >>> >>
>> >>> >> Hi all,
>> >>> >>
>> >>> >> we discovered a p

Re: Re: [Regression] Declared properties could not be modified anymore within a plugin

[Benson Margulies]

https://github.com/benson-basis/prop-override-example

Seems to be a demo that

https://github.com/basis-technology-corp/basis-build-helper-maven-plugin

overrides properties.

Using:

private void defineProperty(String name, String value) {
if (getLog().isDebugEnabled()) {
  getLog().debug("define property " + name + " = \"" + value + "\"");
}
project.getProperties().put(name, value);
}


On Tue, Oct 4, 2016 at 4:03 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 5:35 AM, M. Richey <mric...@gmx.de> wrote:
>> Thanks Benson to point that out, it's a good example.
>>
>> We have several use cases where we modify properties with our plugins. We 
>> have a large variety of our software which to build for up to three brands. 
>> For which brand a specific software is to build is defined outside the poms 
>> and provided by our plugin. As we all know you can't loop inside the poms. 
>> So we execute a plugin once for each brand to find out if this variant 
>> should be build for the brand specified. Therefore we defined a property in 
>> the pom.xml, pre-initialized with a default value, and if the software 
>> should be build for one brand, the brand is appended to the list, i.e. the 
>> value of the property, during the execution of our plugin. So the value of 
>> the property may be something like "default,brand1,brand3" after the 
>> executions of the plugin.
>>
>> So for us it is a blocker at the moment that one can't modify properties 
>> during the execution of a plugin anymore.
>>
>> Benson, you said you have some of these working with 3.3.9. Can you give an 
>> example of a plugin where this is working? I would like to see how they are 
>> doing it in their code.
>
> I'd better do a test to ensure that they are working as well as I
> think they are and then get back to you.
>>
>> Kind regards,
>>
>> Maik
>>
>>
>>
>>> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
>>> Von: "Benson Margulies" <bimargul...@gmail.com>
>>> An: "Maven Users List" <users@maven.apache.org>, i...@soebes.de
>>> Betreff: Re: [Regression] Declared properties could not be modified anymore 
>>> within a plugin
>>>
>>> On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
>>> wrote:
>>> > Hi,
>>> >
>>> > On 30/09/16 15:20, mric...@gmx.de wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> we discovered a problem with properties defined in a pom.xml.
>>> >>
>>> >> Properties could be defined in a pom.xml like:
>>> >>
>>> >> 
>>> >> default
>>> >> 
>>> >>
>>> >> In a maven plugin we fetch all the properties by calling:
>>> >>
>>> >> Properties projectProps = project.getProperties();
>>> >>
>>> >> Running all this with maven 2 we were able to modify the value of 
>>> >> "myProp"
>>> >> within the plugin by:
>>> >>
>>> >> projectProps.put("myProp", "newValue");
>>> >>
>>> >> So after the execution of the plugin, the property  has the value
>>> >> "newValue".
>>> >>
>>> >> Running all this with maven 3 that does not work anymore.
>>> >
>>> >
>>> >
>>> > First I would say this is by design wrong, cause if you define a property 
>>> > in
>>> > the pom file I would like to be sure that it will be kept the value I have
>>> > given and if a plugin (which could it be) will change that I will be 
>>> > really
>>> > astonished.
>>> >
>>> >
>>> > Apart from that my question: Why do you need to change existing properties
>>> > and why not changing the in the pom which is more clearer than 
>>> > mysteriously
>>> > chaning a property by a plugin?...
>>> >
>>> > Can you give more details about your use case ? Best would be having a 
>>> > real
>>> > workign example and what kind of problems you are trying to solve with 
>>> > this
>>> > approach?
>>> >
>>> >
>>> > Kind regards
>>> > Karl Heinz Marbaise
>>> >
>>> > --

Re: Re: [Regression] Declared properties could not be modified anymore within a plugin

[Benson Margulies]

On Tue, Oct 4, 2016 at 5:35 AM, M. Richey <mric...@gmx.de> wrote:
> Thanks Benson to point that out, it's a good example.
>
> We have several use cases where we modify properties with our plugins. We 
> have a large variety of our software which to build for up to three brands. 
> For which brand a specific software is to build is defined outside the poms 
> and provided by our plugin. As we all know you can't loop inside the poms. So 
> we execute a plugin once for each brand to find out if this variant should be 
> build for the brand specified. Therefore we defined a property in the 
> pom.xml, pre-initialized with a default value, and if the software should be 
> build for one brand, the brand is appended to the list, i.e. the value of the 
> property, during the execution of our plugin. So the value of the property 
> may be something like "default,brand1,brand3" after the executions of the 
> plugin.
>
> So for us it is a blocker at the moment that one can't modify properties 
> during the execution of a plugin anymore.
>
> Benson, you said you have some of these working with 3.3.9. Can you give an 
> example of a plugin where this is working? I would like to see how they are 
> doing it in their code.

I'd better do a test to ensure that they are working as well as I
think they are and then get back to you.
>
> Kind regards,
>
> Maik
>
>
>
>> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
>> Von: "Benson Margulies" <bimargul...@gmail.com>
>> An: "Maven Users List" <users@maven.apache.org>, i...@soebes.de
>> Betreff: Re: [Regression] Declared properties could not be modified anymore 
>> within a plugin
>>
>> On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
>> wrote:
>> > Hi,
>> >
>> > On 30/09/16 15:20, mric...@gmx.de wrote:
>> >>
>> >> Hi all,
>> >>
>> >> we discovered a problem with properties defined in a pom.xml.
>> >>
>> >> Properties could be defined in a pom.xml like:
>> >>
>> >> 
>> >> default
>> >> 
>> >>
>> >> In a maven plugin we fetch all the properties by calling:
>> >>
>> >> Properties projectProps = project.getProperties();
>> >>
>> >> Running all this with maven 2 we were able to modify the value of "myProp"
>> >> within the plugin by:
>> >>
>> >> projectProps.put("myProp", "newValue");
>> >>
>> >> So after the execution of the plugin, the property  has the value
>> >> "newValue".
>> >>
>> >> Running all this with maven 3 that does not work anymore.
>> >
>> >
>> >
>> > First I would say this is by design wrong, cause if you define a property 
>> > in
>> > the pom file I would like to be sure that it will be kept the value I have
>> > given and if a plugin (which could it be) will change that I will be really
>> > astonished.
>> >
>> >
>> > Apart from that my question: Why do you need to change existing properties
>> > and why not changing the in the pom which is more clearer than mysteriously
>> > chaning a property by a plugin?...
>> >
>> > Can you give more details about your use case ? Best would be having a real
>> > workign example and what kind of problems you are trying to solve with this
>> > approach?
>> >
>> >
>> > Kind regards
>> > Karl Heinz Marbaise
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>>
>> Here's why this is important.
>>
>> Consider a plugin with the job of setting a property, like many of the
>> build-helper goals, or the build-number plugin.
>>
>> Now, consider an IDE. The IDEs don't, in general, know about these
>> plugins. They get confused when they don't have a value at all. So,
>> SOP is is to put a harmless default into the POM, and count on the
>> plugin overwriting it. I have some of these working with 3.3.9, so
>> there must be something more subtle going on.
>>
>>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: [Regression] Declared properties could not be modified anymore within a plugin

[Benson Margulies]

On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> On 30/09/16 15:20, mric...@gmx.de wrote:
>>
>> Hi all,
>>
>> we discovered a problem with properties defined in a pom.xml.
>>
>> Properties could be defined in a pom.xml like:
>>
>> 
>> default
>> 
>>
>> In a maven plugin we fetch all the properties by calling:
>>
>> Properties projectProps = project.getProperties();
>>
>> Running all this with maven 2 we were able to modify the value of "myProp"
>> within the plugin by:
>>
>> projectProps.put("myProp", "newValue");
>>
>> So after the execution of the plugin, the property  has the value
>> "newValue".
>>
>> Running all this with maven 3 that does not work anymore.
>
>
>
> First I would say this is by design wrong, cause if you define a property in
> the pom file I would like to be sure that it will be kept the value I have
> given and if a plugin (which could it be) will change that I will be really
> astonished.
>
>
> Apart from that my question: Why do you need to change existing properties
> and why not changing the in the pom which is more clearer than mysteriously
> chaning a property by a plugin?...
>
> Can you give more details about your use case ? Best would be having a real
> workign example and what kind of problems you are trying to solve with this
> approach?
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Here's why this is important.

Consider a plugin with the job of setting a property, like many of the
build-helper goals, or the build-number plugin.

Now, consider an IDE. The IDEs don't, in general, know about these
plugins. They get confused when they don't have a value at all. So,
SOP is is to put a harmless default into the POM, and count on the
plugin overwriting it. I have some of these working with 3.3.9, so
there must be something more subtle going on.


>

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

Setting the default checksum policy

[Benson Margulies]

I want checksum:fail for all repos, all the time, without having to
configure it one-at-a-time in settings.xml. Can I have it?

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

Re: Excluding all transitive dependencies

[Benson Margulies]

On Tue, Sep 6, 2016 at 7:12 PM, Mark Derricutt <m...@talios.com> wrote:
> On 7 Sep 2016, at 4:16, Benson Margulies wrote:
>
>> In fact, I think I've seen it work. However, today, with Maven 3.3.9,
>> it seems to be having no effect with the declaration below. Can anyone
>> suggest a way to explain/fix/repair?
>
> That appears to work for me in 3.3.9/3.4.0-SNAPSHOT.
>
> No other dependencies pulling them in?

I think it must have been that. The confusing situation seems to have been:

Dependency (a) is top-level. It is also a transitive dependency of
(b). Under (a), I declare the exclusion */*. However, the path from
(b) causes all the transitive dependencies of (a) to reappear in
dependency:tree under the top-level description of (a),  not under
b/a.

>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt

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

Excluding all transitive dependencies

[Benson Margulies]

The doc describes:

  
 
*
*
  
  

is supposed to work to exclude all transitive dependencies.

In fact, I think I've seen it work. However, today, with Maven 3.3.9,
it seems to be having no effect with the declaration below. Can anyone
suggest a way to explain/fix/repair?



org.apache.servicemix.bundles
org.apache.servicemix.bundles.aws-java-sdk
1.10.52_1

  
*
*
  



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

Re: If an extension improves the version, it's not deployed

[Benson Margulies]

https://github.com/benson-basis/auto-version-example

On Mon, Sep 5, 2016 at 2:09 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi Benson,
>
> On 05/09/16 16:25, Benson Margulies wrote:
>>
>> I just discovered by experiment that that flatten-maven-plugin helps here.
>>
>
> would you so kind to show the setup you have used ?
>
> Might be helpful for others as well...
>
> Thanks for you testing etc.
>
>
> Kind regards
> Karl Heinz
>
>
>>
>> On Thu, Sep 1, 2016 at 1:35 PM, Dan Tran <dant...@gmail.com> wrote:
>>>
>>> I wonder if Karl's solution facing the same issue
>>> http://blog.soebes.de/blog/2016/08/08/maven-how-to-create-a-release/
>>>
>>> On Thu, Sep 1, 2016 at 9:20 AM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>>
>>>> Using Maven 3.3.9,
>>>> https://github.com/basis-technology-corp/auto-version-maven-extension
>>>> is not as useful as I had hoped. The extension sets a property for use
>>>> in a  element, but 'mvn deploy' deploys the POM as-is, not
>>>> after the version is calculated.
>>>>
>>>> Has anyone a suggestion for how to add to this extension to get the
>>>> desired behavior?
>>>>
>
> -
> 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: If an extension improves the version, it's not deployed

[Benson Margulies]

I just discovered by experiment that that flatten-maven-plugin helps here.


On Thu, Sep 1, 2016 at 1:35 PM, Dan Tran <dant...@gmail.com> wrote:
> I wonder if Karl's solution facing the same issue
> http://blog.soebes.de/blog/2016/08/08/maven-how-to-create-a-release/
>
> On Thu, Sep 1, 2016 at 9:20 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> Using Maven 3.3.9,
>> https://github.com/basis-technology-corp/auto-version-maven-extension
>> is not as useful as I had hoped. The extension sets a property for use
>> in a  element, but 'mvn deploy' deploys the POM as-is, not
>> after the version is calculated.
>>
>> Has anyone a suggestion for how to add to this extension to get the
>> desired behavior?
>>
>> -
>> 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

If an extension improves the version, it's not deployed

[Benson Margulies]

Using Maven 3.3.9,
https://github.com/basis-technology-corp/auto-version-maven-extension
is not as useful as I had hoped. The extension sets a property for use
in a  element, but 'mvn deploy' deploys the POM as-is, not
after the version is calculated.

Has anyone a suggestion for how to add to this extension to get the
desired behavior?

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

Re: Re: checkstyle plugin and checking files outside of maven dirs

[Benson Margulies]

I commend you to the source of the plugin in that case. The doc can be
confusing.


On Wed, Aug 17, 2016 at 10:06 AM, Veit Guna <veit.g...@gmx.de> wrote:
> I came from the checkstyle mailing list :). They say, they can basically 
> check anything thrown
> at them. And the pom is just an XML file that I would like to check for 
> specific line endings.
> So what I'm seeking for is a special option in the maven checkstyle plugin to 
> check files
> outside of the normal maven scope (sources, resources).
>
>
>> Gesendet: Mittwoch, 17. August 2016 um 15:21 Uhr
>> Von: "Benson Margulies" <bimargul...@gmail.com>
>> An: "Maven Users List" <users@maven.apache.org>
>> Betreff: Re: checkstyle plugin and checking files outside of maven dirs
>>
>> The checkstyle plugin runs http://checkstyle.sourceforge.net/. Which
>> has a particular feature set, which does not include checking Maven
>> poms. There are a number of checks in the enforcer plugin which, in
>> effect, check that the POM meets particular conditions. I don't know
>> of any way to scan arbitrary files for line endings, but someone else
>> might.
>>
>> On Tue, Aug 16, 2016 at 7:05 PM, Veit Guna <veit.g...@gmx.de> wrote:
>> > Hi.
>> >
>> > I'm using the checkstyle maven plugin to validate my source and resource
>> > files. That works so far.
>> > But now I encountered, that it won't check files outside of the standard
>> > maven dirs.
>> >
>> > E.g. it would be great if it could check the pom as well. Is this
>> > somehow possible?
>> > Also when it comes to windows/unix lineending checks, it would be great,
>> > if all
>> > files in a project could be checked.
>> >
>> > Any hints how to achieve that?
>> >
>> > Thanks
>> > Veit
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: checkstyle plugin and checking files outside of maven dirs

[Benson Margulies]

The checkstyle plugin runs http://checkstyle.sourceforge.net/. Which
has a particular feature set, which does not include checking Maven
poms. There are a number of checks in the enforcer plugin which, in
effect, check that the POM meets particular conditions. I don't know
of any way to scan arbitrary files for line endings, but someone else
might.

On Tue, Aug 16, 2016 at 7:05 PM, Veit Guna  wrote:
> Hi.
>
> I'm using the checkstyle maven plugin to validate my source and resource
> files. That works so far.
> But now I encountered, that it won't check files outside of the standard
> maven dirs.
>
> E.g. it would be great if it could check the pom as well. Is this
> somehow possible?
> Also when it comes to windows/unix lineending checks, it would be great,
> if all
> files in a project could be checked.
>
> Any hints how to achieve that?
>
> Thanks
> Veit
>
> -
> 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

If a repository has no metadata

[Benson Margulies]

We're considering a situation where we want to push artifacts to S3
following the repository pathname convention, but not bother to write
the metadata. In the current state of the universe, what will happen
when something goes to read?

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

Re: Surefire dead vm, how to debug?

[Benson Margulies]

I've proved that this is another one of the new bugs in 19/19.1 that
isn't in 18, and I've reported on those in detail before, so I've lost
interest.


On Mon, Jul 11, 2016 at 8:02 AM, Martin Gainty  wrote:
> can you attach surefire.log from mvn test e.g.
> mvn -X -e test | tee surefire.log
>
> ?
> Martin
> __
>
>
>
>> From: bimargul...@gmail.com
>> Date: Sun, 10 Jul 2016 07:46:34 -0400
>> Subject: Re: Surefire dead vm, how to debug?
>> To: users@maven.apache.org
>>
>> Same failure with 2.19.1. No parallelism configured.
>>
>>  
>> org.apache.maven.plugins
>> maven-surefire-plugin
>> 2.19.1
>> 
>> -Xmx8G -XX:+UseConcMarkSweepGC
>> -Djava.io.tmpdir=${project.build.directory}
>> 
>> 
>>
>>
>>
>> On Sun, Jul 10, 2016 at 7:41 AM, Martin Gainty  wrote:
>> >
>> >
>> >> From: bimargul...@gmail.com
>> >> Date: Sun, 10 Jul 2016 07:34:53 -0400
>> >> Subject: Surefire dead vm, how to debug?
>> >> To: users@maven.apache.org
>> >>
>> >> My build stops with this message just after printing the surefire
>> >> summary for the module in question, so none of my test cases called
>> >> 'exit'. There are no hotspot dumps.
>> >>
>> >> What's the diagnostic process?
>> > MG>possible parallel test execution config bug..can you share surefire 
>> > configuration?
>> > http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
>> >>
>> >> [ERROR] Failed to execute goal
>> >> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
>> >> (default-test) on project relax-ore-core: Execution default-test of
>> >> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
>> >> The forked VM terminated without properly saying goodbye. VM crash or
>> >> System.exit called?
>> >> [ERROR] Command was /bin/sh -c cd /Users/benson/x/relax-ore/core &&
>> >> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
>> >> -Xmx8G -XX:+UseConcMarkSweepGC
>> >> -Djava.io.tmpdir=/Users/benson/x/relax-ore/core/target -jar
>> >> /Users/benson/x/relax-ore/core/target/surefire/surefirebooter3368801762081916190.jar
>> >> /Users/benson/x/relax-ore/core/target/surefire/surefire3112822568238339351tmp
>> >> /Users/benson/x/relax-ore/core/target/surefire/surefire_67539786626460885470tmp
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>

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

Re: Surefire dead vm, how to debug?

[Benson Margulies]

Same failure with 2.19.1. No parallelism configured.

 
org.apache.maven.plugins
maven-surefire-plugin
2.19.1

-Xmx8G -XX:+UseConcMarkSweepGC
-Djava.io.tmpdir=${project.build.directory}





On Sun, Jul 10, 2016 at 7:41 AM, Martin Gainty  wrote:
>
>
>> From: bimargul...@gmail.com
>> Date: Sun, 10 Jul 2016 07:34:53 -0400
>> Subject: Surefire dead vm, how to debug?
>> To: users@maven.apache.org
>>
>> My build stops with this message just after printing the surefire
>> summary for the module in question, so none of my test cases called
>> 'exit'. There are no hotspot dumps.
>>
>> What's the diagnostic process?
> MG>possible parallel test execution config bug..can you share surefire 
> configuration?
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
>> (default-test) on project relax-ore-core: Execution default-test of
>> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
>> The forked VM terminated without properly saying goodbye. VM crash or
>> System.exit called?
>> [ERROR] Command was /bin/sh -c cd /Users/benson/x/relax-ore/core &&
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
>> -Xmx8G -XX:+UseConcMarkSweepGC
>> -Djava.io.tmpdir=/Users/benson/x/relax-ore/core/target -jar
>> /Users/benson/x/relax-ore/core/target/surefire/surefirebooter3368801762081916190.jar
>> /Users/benson/x/relax-ore/core/target/surefire/surefire3112822568238339351tmp
>> /Users/benson/x/relax-ore/core/target/surefire/surefire_67539786626460885470tmp
>>
>> -
>> 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

Surefire dead vm, how to debug?

[Benson Margulies]

My build stops with this message just after printing the surefire
summary for the module in question, so none of my test cases called
'exit'. There are no hotspot dumps.

What's the diagnostic process?

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19:test
(default-test) on project relax-ore-core: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was /bin/sh -c cd /Users/benson/x/relax-ore/core &&
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
-Xmx8G -XX:+UseConcMarkSweepGC
-Djava.io.tmpdir=/Users/benson/x/relax-ore/core/target -jar
/Users/benson/x/relax-ore/core/target/surefire/surefirebooter3368801762081916190.jar
/Users/benson/x/relax-ore/core/target/surefire/surefire3112822568238339351tmp
/Users/benson/x/relax-ore/core/target/surefire/surefire_67539786626460885470tmp

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

Re: own Maven Site plugin

[Benson Margulies]

It has to be set up as a 'reporting' plugin. I recommend looking at
examples of other such plugins, such as
https://maven.apache.org/plugins/maven-project-info-reports-plugin/

On Sat, Jun 25, 2016 at 4:44 PM, Philipp Kraus
 wrote:
> Hello,
>
> I try to build my first Maven site plugin.
> I have defined a class based on AbstractMojo and
> put the annotation @Mojo( name = "rrd-antlr4", defaultPhase = 
> LifecyclePhase.SITE )
> on top.
>
> I overload the execute-method and put my plugin content to the method. I 
> build the plugin and deploy
> it my local Maven repository. I’m testing my plugin in a testing project with 
> the pom content
> 
>
> 
>
> 
> de.flashpixx
> rrd-antlr4
> 0.1.0
> 
> …..
>
> If I run "mvn site“ I get "[INFO] configuring report plugin 
> de.flashpixx:rrd-antlr4:0.1.0“ but
> the execute method is not run / called.
>
> How I can debug the plugin or fix the execution of the plugin?
>
> Thanks
>
> Phil

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

Re: Single Git repo,multiple independent releasable folders using release plugin??

[Benson Margulies]

On Sat, Jun 25, 2016 at 6:06 PM, Dan Tran <dant...@gmail.com> wrote:
> Hi Benson,
>
> Could you please elaborate more details?
>
> Sounds like you have this working which is a good news.  I very prefer one
> single repo

Dan, it's all in the doc, and I'm not claiming that it's always a
great idea. But if you add

 subdir/pom.xml

to the m-r-p configuration, it works. I don't have a working example
in a useful place, but there are IT's for it in the m-r-p.




>
> Thanks
>
> -Dan
>
> On Sun, Jun 19, 2016 at 4:14 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> You don't put it in the URL.
>>
>> subdir/pom.xml
>>
>>
>>
>> On Fri, Jun 17, 2016 at 10:21 PM, Dan Tran <dant...@gmail.com> wrote:
>> > Hi
>> >
>> > I would like to host multiple multi-module maven projects, each project
>> has
>> > its own top level folder
>> > under same GIT repository
>> >
>> > is it possible to release each project using maven release plugin?, if
>> so,
>> > what would be SCM URL for each folder?
>> >
>> > Advice are greatly appreciated.
>> >
>> > -Dan
>>
>> -
>> 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: Single Git repo,multiple independent releasable folders using release plugin??

[Benson Margulies]

You don't put it in the URL.

subdir/pom.xml



On Fri, Jun 17, 2016 at 10:21 PM, Dan Tran  wrote:
> Hi
>
> I would like to host multiple multi-module maven projects, each project has
> its own top level folder
> under same GIT repository
>
> is it possible to release each project using maven release plugin?, if so,
> what would be SCM URL for each folder?
>
> Advice are greatly appreciated.
>
> -Dan

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

Re: How does maven internally manages package dependency?

[Benson Margulies]

What do you mean by 'manage package dependencies'? By 'package' do you
mean 'java package' (e.g. com.foo.bar), or do you mean an artifact in
the dependency graph?

Maven is open source. If you want to learn how it works, you need to
read the code.

If you want to learn how to use it, the sonatype online book is useful.



On Wed, Jun 15, 2016 at 2:14 PM, Debraj Manna  wrote:
> Can some let me know how does maven internally manages package dependency?
> Is there any architecture diagram available on the net for the same? I also
> asked this in Quora
>  but
> did not get any response their nor I am able to find any suitable resources
> in the web that explains the working of maven and even better if I can find
> some class diagram?

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

Re: Maven & Continuous Delivery

[Benson Margulies]

On Thu, Apr 21, 2016 at 10:20 PM, Dan Tran <dant...@gmail.com> wrote:
> does it upload the pom with its version fully translated?

All it does is arrange to trigger the 'version with a property'
functionality that was added quite some time ago. If that
functionality uploaded resolved poms, it uploads resolved poms. If
not, I guess, not.


>
> Thanks
>
> -D
>
> On Thu, Apr 21, 2016 at 6:40 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran <dant...@gmail.com> wrote:
>> > Hi Benson
>> >
>> > Sounds promissing
>> >
>> > does it support jenkins env BUILD_NUM?
>>
>> I doubt it. I dislike Jenkins and avoid having anything to do with it.
>> Feel free to make a PR.
>>
>> > does it push the actual version to maven repo at install/deploy time?
>>
>> if you run mvn deploy, your artifacts will be deployed.
>>
>>
>> >
>> > Thanks
>> >
>> > -Dan
>> >
>> > On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies <bimargul...@gmail.com
>> >
>> > wrote:
>> >
>> >> https://github.com/basis-technology-corp/auto-version-maven-extension
>> >>
>> >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>> >> <jeffjen...@upstairstechnology.com> wrote:
>> >> >>
>> >> >> Jason van Zyl also mentioned he was working on CD solution for Maven
>> >> last
>> >> >> year, not sure what the progress on this front.
>> >> >
>> >> >
>> >> > Yes, I've been curious about the progress too.  It's very needed and
>> so
>> >> > promising.
>> >> >
>> >> >
>> >> > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran <dant...@gmail.com> wrote:
>> >> >
>> >> >> Thanks Stephen.
>> >> >>
>> >> >> I was excited for a short moment but hitting the reality where I may
>> >> have
>> >> >> to deal with hundreds of dev and qa over the confusion of the hidden
>> >> >> version. Especially, when they have to rebuild a subset of the
>> product.
>> >> It
>> >> >> just not working
>> >> >>
>> >> >> Jason van Zyl also mentioned he was working on CD solution for Maven
>> >> last
>> >> >> year, not sure what the progress on this front.
>> >> >>
>> >> >> -Dan
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly <
>> >> >> stephen.alan.conno...@gmail.com> wrote:
>> >> >>
>> >> >> > I share your concern. We could fix the concern if we created the
>> >> >> > transformed pom on disk so that things like GPG signatures were
>> >> generated
>> >> >> > correctly, but AIUI the issue there was that the pom could not be
>> put
>> >> in
>> >> >> > target as that would break relative paths.
>> >> >> >
>> >> >> > I suspect this is also related to the issue of dependency reduced
>> poms
>> >> >> for
>> >> >> > shade... or any feature where the pom to be used downstream in the
>> >> >> reactor
>> >> >> > needs to differ from the pom on disk.
>> >> >> >
>> >> >> > For me, having been burned by not building the effective pom from a
>> >> clean
>> >> >> > checkout I actually favour the use of the release plugin, typically
>> >> for
>> >> >> CD
>> >> >> > I just have the next development version the same as the current
>> and
>> >> if
>> >> >> you
>> >> >> > tune your preparationGoals then you can just have one compile test
>> >> >> cycle...
>> >> >> >
>> >> >> > But the fight of that blog is a bit like the idiotic quest people
>> >> have to
>> >> >> > run the tests once only with code coverage as part of the single
>> test
>> >> >> > execution... until you have been burned by the code coverage
>> affecting
>> >> >> > effective bytecode and preventing the synchronization bug from
>> being
>> >> >> caught
>> >> &

Re: Maven & Continuous Delivery

[Benson Margulies]

On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran <dant...@gmail.com> wrote:
> Hi Benson
>
> Sounds promissing
>
> does it support jenkins env BUILD_NUM?

I doubt it. I dislike Jenkins and avoid having anything to do with it.
Feel free to make a PR.

> does it push the actual version to maven repo at install/deploy time?

if you run mvn deploy, your artifacts will be deployed.


>
> Thanks
>
> -Dan
>
> On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> https://github.com/basis-technology-corp/auto-version-maven-extension
>>
>> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>> <jeffjen...@upstairstechnology.com> wrote:
>> >>
>> >> Jason van Zyl also mentioned he was working on CD solution for Maven
>> last
>> >> year, not sure what the progress on this front.
>> >
>> >
>> > Yes, I've been curious about the progress too.  It's very needed and so
>> > promising.
>> >
>> >
>> > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran <dant...@gmail.com> wrote:
>> >
>> >> Thanks Stephen.
>> >>
>> >> I was excited for a short moment but hitting the reality where I may
>> have
>> >> to deal with hundreds of dev and qa over the confusion of the hidden
>> >> version. Especially, when they have to rebuild a subset of the product.
>> It
>> >> just not working
>> >>
>> >> Jason van Zyl also mentioned he was working on CD solution for Maven
>> last
>> >> year, not sure what the progress on this front.
>> >>
>> >> -Dan
>> >>
>> >>
>> >>
>> >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly <
>> >> stephen.alan.conno...@gmail.com> wrote:
>> >>
>> >> > I share your concern. We could fix the concern if we created the
>> >> > transformed pom on disk so that things like GPG signatures were
>> generated
>> >> > correctly, but AIUI the issue there was that the pom could not be put
>> in
>> >> > target as that would break relative paths.
>> >> >
>> >> > I suspect this is also related to the issue of dependency reduced poms
>> >> for
>> >> > shade... or any feature where the pom to be used downstream in the
>> >> reactor
>> >> > needs to differ from the pom on disk.
>> >> >
>> >> > For me, having been burned by not building the effective pom from a
>> clean
>> >> > checkout I actually favour the use of the release plugin, typically
>> for
>> >> CD
>> >> > I just have the next development version the same as the current and
>> if
>> >> you
>> >> > tune your preparationGoals then you can just have one compile test
>> >> cycle...
>> >> >
>> >> > But the fight of that blog is a bit like the idiotic quest people
>> have to
>> >> > run the tests once only with code coverage as part of the single test
>> >> > execution... until you have been burned by the code coverage affecting
>> >> > effective bytecode and preventing the synchronization bug from being
>> >> caught
>> >> > by your tests (plus other test invalidating behaviours I have seen)
>> you
>> >> > will run around trying to get rid of the second test execution...
>> >> >
>> >> > Those who do not understand why we do things will be condemned to
>> repeat
>> >> > our mistakes that made us do things that way.
>> >> >
>> >> > Having said that, it is a good pressure to have people pushing the
>> "why
>> >> do
>> >> > we need to do it this way" envelope... perhaps it is time that we
>> need to
>> >> > ensure that the release plugin has a page outlining our rational for
>> the
>> >> > current default behaviour, common ways to tweak it and stressing that
>> we
>> >> > have provided a framework for releasing and others are welcome to
>> reuse
>> >> the
>> >> > framework in their own release plugins
>> >> >
>> >> > On 16 April 2016 at 06:01, Dan Tran <dant...@gmail.com> wrote:
>> >> >
>> >> > > Hi,
>> >> > >
>> >> > > Anyone practicing CD according to this blog?
>> >> > > https://axelfontaine.com/blog/dead-burried.html
>> >> > >
>> >> > > I can build locally, but have a huge concern on the pom deployed at
>> >> maven
>> >> > > repo since it does NOT  have the exact version
>> >> > >
>> >> > > If you do, please share your experience. Any hick up when you
>> introduce
>> >> > > this new practice?
>> >> > >
>> >> > > For our case, we have about 200 modules project and about 100 dev +
>> qa
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > > -Dan
>> >> > >
>> >> >
>> >>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

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

Re: Maven & Continuous Delivery

[Benson Margulies]

https://github.com/basis-technology-corp/auto-version-maven-extension

On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
 wrote:
>>
>> Jason van Zyl also mentioned he was working on CD solution for Maven last
>> year, not sure what the progress on this front.
>
>
> Yes, I've been curious about the progress too.  It's very needed and so
> promising.
>
>
> On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran  wrote:
>
>> Thanks Stephen.
>>
>> I was excited for a short moment but hitting the reality where I may have
>> to deal with hundreds of dev and qa over the confusion of the hidden
>> version. Especially, when they have to rebuild a subset of the product. It
>> just not working
>>
>> Jason van Zyl also mentioned he was working on CD solution for Maven last
>> year, not sure what the progress on this front.
>>
>> -Dan
>>
>>
>>
>> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > I share your concern. We could fix the concern if we created the
>> > transformed pom on disk so that things like GPG signatures were generated
>> > correctly, but AIUI the issue there was that the pom could not be put in
>> > target as that would break relative paths.
>> >
>> > I suspect this is also related to the issue of dependency reduced poms
>> for
>> > shade... or any feature where the pom to be used downstream in the
>> reactor
>> > needs to differ from the pom on disk.
>> >
>> > For me, having been burned by not building the effective pom from a clean
>> > checkout I actually favour the use of the release plugin, typically for
>> CD
>> > I just have the next development version the same as the current and if
>> you
>> > tune your preparationGoals then you can just have one compile test
>> cycle...
>> >
>> > But the fight of that blog is a bit like the idiotic quest people have to
>> > run the tests once only with code coverage as part of the single test
>> > execution... until you have been burned by the code coverage affecting
>> > effective bytecode and preventing the synchronization bug from being
>> caught
>> > by your tests (plus other test invalidating behaviours I have seen) you
>> > will run around trying to get rid of the second test execution...
>> >
>> > Those who do not understand why we do things will be condemned to repeat
>> > our mistakes that made us do things that way.
>> >
>> > Having said that, it is a good pressure to have people pushing the "why
>> do
>> > we need to do it this way" envelope... perhaps it is time that we need to
>> > ensure that the release plugin has a page outlining our rational for the
>> > current default behaviour, common ways to tweak it and stressing that we
>> > have provided a framework for releasing and others are welcome to reuse
>> the
>> > framework in their own release plugins
>> >
>> > On 16 April 2016 at 06:01, Dan Tran  wrote:
>> >
>> > > Hi,
>> > >
>> > > Anyone practicing CD according to this blog?
>> > > https://axelfontaine.com/blog/dead-burried.html
>> > >
>> > > I can build locally, but have a huge concern on the pom deployed at
>> maven
>> > > repo since it does NOT  have the exact version
>> > >
>> > > If you do, please share your experience. Any hick up when you introduce
>> > > this new practice?
>> > >
>> > > For our case, we have about 200 modules project and about 100 dev + qa
>> > >
>> > > Thanks
>> > >
>> > > -Dan
>> > >
>> >
>>

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

Re: variable doesn't work for version

[Benson Margulies]

On Thu, Mar 10, 2016 at 3:04 AM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> Also I suspect this doesn't fully include logic to ensure that the

'this' = my code, or 'this' = the core implementation for properties
in the version?

> substitution resolved pom is installed/deployed, so may cause issues for
> out-of-reactor consumption as a dependency, or GPG signature validation if
> you try to "fix" with a hack
>
> On Thursday 10 March 2016, Stephen Connolly <stephen.alan.conno...@gmail.com>
> wrote:
>
>> It's ${revision} or ${changelist} or a third one I cannot recall, ${rev}
>> is on the "moan and wail" list
>>
>> On Wednesday 9 March 2016, Benson Margulies <bimargul...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','bimargul...@gmail.com');>> wrote:
>>
>>> Almost really working. The only gripe is that it is still warning me
>>> that I have an expression in , even when I use 'rev' as
>>> cited. Is that poor choice?
>>>
>>> [INFO] rev 0.0.1.20160309172035
>>> [INFO] Scanning for projects...
>>> [WARNING]
>>> [WARNING] Some problems were encountered while building the effective
>>> model for
>>> com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
>>> [WARNING] 'version' contains an expression but should be a constant. @
>>> com.basistech:auto-version-maven-extension-test:${rev},
>>> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
>>> line 7, column 14
>>> [WARNING]
>>> [WARNING] It is highly recommended to fix these problems because they
>>> threaten the stability of your build.
>>> [WARNING]
>>> [WARNING] For this reason, future Maven versions might no longer
>>> support building such malformed projects.
>>> [WARNING]
>>>
>>>
>>>
>>> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> > Of course, as soon as I hit Send I found out what I screwed up.
>>> >
>>> > On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> >> I tried this and it didn't work, even a little.
>>> >>
>>> >> See https://github.com/benson-basis/auto-version-maven-extension.
>>> >>
>>> >> My extension is never called, whether I put it into .mvn or the maven
>>> >> home lib/ext directory. (Proved by running mvnDebug, setting a
>>> >> breakpoint, and attaching a debugger).
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <
>>> bimargul...@gmail.com> wrote:
>>> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> >>> <stephen.alan.conno...@gmail.com> wrote:
>>> >>>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <
>>> ta...@cservenak.net
>>> >>>>> <javascript:;>> wrote:
>>> >>>>> > I assume it should be this (instead of spy):
>>> >>>>> >
>>> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>> >>>>> >
>>> >>>>> > And instead of starting beer machine, it can inject the value
>>> into the
>>> >>>>> > session that you got from whenever...
>>> >>>>>
>>> >>>>> I don't think this can work as a thing configured in the POM. Unless
>>> >>>>> these items can be dropped into the ext directory instead of
>>> >>>>> configured in the the pom as an extension. Is that the case in
>>> general
>>> >>>>> that the ext dir is the same thing as declaring in the POM as an
>>> >>>>> extension?
>>> >>>>
>>> >>>>
>>> >>>> That's where the .mvn folder as an extension loading mechanism kicks
>>> in
>>> >>>
>>> >>> What version did that show up in? Prior, it has to be in a dir in the
>>> >>> maven home, right?
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> >
>>> >&

Re: variable doesn't work for version

[Benson Margulies]

Almost really working. The only gripe is that it is still warning me
that I have an expression in , even when I use 'rev' as
cited. Is that poor choice?

[INFO] rev 0.0.1.20160309172035
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for 
com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
[WARNING] 'version' contains an expression but should be a constant. @
com.basistech:auto-version-maven-extension-test:${rev},
/Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
line 7, column 14
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[WARNING]



On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Of course, as soon as I hit Send I found out what I screwed up.
>
> On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <bimargul...@gmail.com> 
> wrote:
>> I tried this and it didn't work, even a little.
>>
>> See https://github.com/benson-basis/auto-version-maven-extension.
>>
>> My extension is never called, whether I put it into .mvn or the maven
>> home lib/ext directory. (Proved by running mvnDebug, setting a
>> breakpoint, and attaching a debugger).
>>
>>
>>
>> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <bimargul...@gmail.com> 
>> wrote:
>>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>>> <stephen.alan.conno...@gmail.com> wrote:
>>>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com> wrote:
>>>>
>>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <ta...@cservenak.net
>>>>> <javascript:;>> wrote:
>>>>> > I assume it should be this (instead of spy):
>>>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>>>> >
>>>>> > And instead of starting beer machine, it can inject the value into the
>>>>> > session that you got from whenever...
>>>>>
>>>>> I don't think this can work as a thing configured in the POM. Unless
>>>>> these items can be dropped into the ext directory instead of
>>>>> configured in the the pom as an extension. Is that the case in general
>>>>> that the ext dir is the same thing as declaring in the POM as an
>>>>> extension?
>>>>
>>>>
>>>> That's where the .mvn folder as an extension loading mechanism kicks in
>>>
>>> What version did that show up in? Prior, it has to be in a dir in the
>>> maven home, right?
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > maven related changes merely laxed the validation to allow those three
>>>>> > expressions in version, but does not provide anything as "source" for
>>>>> those.
>>>>> >
>>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>>>> > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>>>> >
>>>>> >> I have no clue... that is a different question we should ask of the
>>>>> person
>>>>> >> who implemented this functionality
>>>>> >>
>>>>> >> On 9 March 2016 at 13:40, Benson Margulies <bimargul...@gmail.com
>>>>> <javascript:;>> wrote:
>>>>> >>
>>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>>>> >> > <stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>>>> >> property
>>>>> >> > > based on whatever you seem safe
>>>>> >> >
>>>>> >> > Stephen, can you please offer some details? Just what sort of
>>>>> >> > extension? An event spy that sees session start? Something else? Does
>>>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>>>> >> >
>>>>> >> > >
>>>>> >> > > Then just have the project version include the ${rev} at the
>>>>> >> appropriate
>>>>> >> > > place
>>>>> >> > >
>>>>> >> >

Re: variable doesn't work for version

[Benson Margulies]

Of course, as soon as I hit Send I found out what I screwed up.

On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> I tried this and it didn't work, even a little.
>
> See https://github.com/benson-basis/auto-version-maven-extension.
>
> My extension is never called, whether I put it into .mvn or the maven
> home lib/ext directory. (Proved by running mvnDebug, setting a
> breakpoint, and attaching a debugger).
>
>
>
> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <bimargul...@gmail.com> 
> wrote:
>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
>> <stephen.alan.conno...@gmail.com> wrote:
>>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com> wrote:
>>>
>>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <ta...@cservenak.net
>>>> <javascript:;>> wrote:
>>>> > I assume it should be this (instead of spy):
>>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>>> >
>>>> > And instead of starting beer machine, it can inject the value into the
>>>> > session that you got from whenever...
>>>>
>>>> I don't think this can work as a thing configured in the POM. Unless
>>>> these items can be dropped into the ext directory instead of
>>>> configured in the the pom as an extension. Is that the case in general
>>>> that the ext dir is the same thing as declaring in the POM as an
>>>> extension?
>>>
>>>
>>> That's where the .mvn folder as an extension loading mechanism kicks in
>>
>> What version did that show up in? Prior, it has to be in a dir in the
>> maven home, right?
>>
>>>
>>>
>>>>
>>>>
>>>> >
>>>> > maven related changes merely laxed the validation to allow those three
>>>> > expressions in version, but does not provide anything as "source" for
>>>> those.
>>>> >
>>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>>> > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>>> >
>>>> >> I have no clue... that is a different question we should ask of the
>>>> person
>>>> >> who implemented this functionality
>>>> >>
>>>> >> On 9 March 2016 at 13:40, Benson Margulies <bimargul...@gmail.com
>>>> <javascript:;>> wrote:
>>>> >>
>>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>>> >> > <stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>>> >> property
>>>> >> > > based on whatever you seem safe
>>>> >> >
>>>> >> > Stephen, can you please offer some details? Just what sort of
>>>> >> > extension? An event spy that sees session start? Something else? Does
>>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>>> >> >
>>>> >> > >
>>>> >> > > Then just have the project version include the ${rev} at the
>>>> >> appropriate
>>>> >> > > place
>>>> >> > >
>>>> >> > > On Tuesday 8 March 2016, Gary Gregory <garydgreg...@gmail.com
>>>> <javascript:;>> wrote:
>>>> >> > >
>>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com
>>>> <javascript:;>
>>>> >> > <javascript:;>>
>>>> >> > >> wrote:
>>>> >> > >>
>>>> >> > >> > The first question I have to ask is what you are trying to
>>>> >> accomplish
>>>> >> > >> with
>>>> >> > >> > your continuous-delivery?
>>>> >> > >>
>>>> >> > >>
>>>> >> > >> We have a Maven multi-module build which has thousands of unit
>>>> tests.
>>>> >> We
>>>> >> > >> use Bamboo for CI and if we get a green build that means that all
>>>> the
>>>> >> > tests
>>>> >> > >> pass of course and that we successfully deplo

Re: variable doesn't work for version

[Benson Margulies]

I tried this and it didn't work, even a little.

See https://github.com/benson-basis/auto-version-maven-extension.

My extension is never called, whether I put it into .mvn or the maven
home lib/ext directory. (Proved by running mvnDebug, setting a
breakpoint, and attaching a debugger).



On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
>> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <ta...@cservenak.net
>>> <javascript:;>> wrote:
>>> > I assume it should be this (instead of spy):
>>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>>> >
>>> > And instead of starting beer machine, it can inject the value into the
>>> > session that you got from whenever...
>>>
>>> I don't think this can work as a thing configured in the POM. Unless
>>> these items can be dropped into the ext directory instead of
>>> configured in the the pom as an extension. Is that the case in general
>>> that the ext dir is the same thing as declaring in the POM as an
>>> extension?
>>
>>
>> That's where the .mvn folder as an extension loading mechanism kicks in
>
> What version did that show up in? Prior, it has to be in a dir in the
> maven home, right?
>
>>
>>
>>>
>>>
>>> >
>>> > maven related changes merely laxed the validation to allow those three
>>> > expressions in version, but does not provide anything as "source" for
>>> those.
>>> >
>>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>>> > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>> >
>>> >> I have no clue... that is a different question we should ask of the
>>> person
>>> >> who implemented this functionality
>>> >>
>>> >> On 9 March 2016 at 13:40, Benson Margulies <bimargul...@gmail.com
>>> <javascript:;>> wrote:
>>> >>
>>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>>> >> > <stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>>> >> property
>>> >> > > based on whatever you seem safe
>>> >> >
>>> >> > Stephen, can you please offer some details? Just what sort of
>>> >> > extension? An event spy that sees session start? Something else? Does
>>> >> > this require 3.3.x  or does it work with 3.2.5?
>>> >> >
>>> >> > >
>>> >> > > Then just have the project version include the ${rev} at the
>>> >> appropriate
>>> >> > > place
>>> >> > >
>>> >> > > On Tuesday 8 March 2016, Gary Gregory <garydgreg...@gmail.com
>>> <javascript:;>> wrote:
>>> >> > >
>>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com
>>> <javascript:;>
>>> >> > <javascript:;>>
>>> >> > >> wrote:
>>> >> > >>
>>> >> > >> > The first question I have to ask is what you are trying to
>>> >> accomplish
>>> >> > >> with
>>> >> > >> > your continuous-delivery?
>>> >> > >>
>>> >> > >>
>>> >> > >> We have a Maven multi-module build which has thousands of unit
>>> tests.
>>> >> We
>>> >> > >> use Bamboo for CI and if we get a green build that means that all
>>> the
>>> >> > tests
>>> >> > >> pass of course and that we successfully deployed the build to our
>>> repo
>>> >> > (we
>>> >> > >> use Artifactory). We use the Maven's deploy to deploy, not the
>>> release
>>> >> > >> plugin.
>>> >> > >>
>>> >> > >> At this point anyone can use the built product out of Bamboo's
>>> saved
>>> >> > >> artifacts or Artifactory: our internal/external consultants, sales
>>> >> > >> engineers, formal QA, other downstream, p

Re: variable doesn't work for version

[Benson Margulies]

On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
> On Wednesday, 9 March 2016, Benson Margulies <bimargul...@gmail.com> wrote:
>
>> On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <ta...@cservenak.net
>> <javascript:;>> wrote:
>> > I assume it should be this (instead of spy):
>> > http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>> >
>> > And instead of starting beer machine, it can inject the value into the
>> > session that you got from whenever...
>>
>> I don't think this can work as a thing configured in the POM. Unless
>> these items can be dropped into the ext directory instead of
>> configured in the the pom as an extension. Is that the case in general
>> that the ext dir is the same thing as declaring in the POM as an
>> extension?
>
>
> That's where the .mvn folder as an extension loading mechanism kicks in

What version did that show up in? Prior, it has to be in a dir in the
maven home, right?

>
>
>>
>>
>> >
>> > maven related changes merely laxed the validation to allow those three
>> > expressions in version, but does not provide anything as "source" for
>> those.
>> >
>> > On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
>> > stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>> >
>> >> I have no clue... that is a different question we should ask of the
>> person
>> >> who implemented this functionality
>> >>
>> >> On 9 March 2016 at 13:40, Benson Margulies <bimargul...@gmail.com
>> <javascript:;>> wrote:
>> >>
>> >> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> >> > <stephen.alan.conno...@gmail.com <javascript:;>> wrote:
>> >> > > In the .mvn folder put an extension that contributes the ${rev}
>> >> property
>> >> > > based on whatever you seem safe
>> >> >
>> >> > Stephen, can you please offer some details? Just what sort of
>> >> > extension? An event spy that sees session start? Something else? Does
>> >> > this require 3.3.x  or does it work with 3.2.5?
>> >> >
>> >> > >
>> >> > > Then just have the project version include the ${rev} at the
>> >> appropriate
>> >> > > place
>> >> > >
>> >> > > On Tuesday 8 March 2016, Gary Gregory <garydgreg...@gmail.com
>> <javascript:;>> wrote:
>> >> > >
>> >> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com
>> <javascript:;>
>> >> > <javascript:;>>
>> >> > >> wrote:
>> >> > >>
>> >> > >> > The first question I have to ask is what you are trying to
>> >> accomplish
>> >> > >> with
>> >> > >> > your continuous-delivery?
>> >> > >>
>> >> > >>
>> >> > >> We have a Maven multi-module build which has thousands of unit
>> tests.
>> >> We
>> >> > >> use Bamboo for CI and if we get a green build that means that all
>> the
>> >> > tests
>> >> > >> pass of course and that we successfully deployed the build to our
>> repo
>> >> > (we
>> >> > >> use Artifactory). We use the Maven's deploy to deploy, not the
>> release
>> >> > >> plugin.
>> >> > >>
>> >> > >> At this point anyone can use the built product out of Bamboo's
>> saved
>> >> > >> artifacts or Artifactory: our internal/external consultants, sales
>> >> > >> engineers, formal QA, other downstream, products, and so on. It's
>> up
>> >> to
>> >> > the
>> >> > >> PO to decide when to slap a new major or minor version label and
>> >> he/she
>> >> > can
>> >> > >> do at anytime.
>> >> > >>
>> >> > >> From development's POV, a green build is a released product, with a
>> >> > version
>> >> > >> for example 3.1.201601070101 (3.1.MMDDHHMM). We used to have
>> the
>> >> SVN
>> >> > >> version number as the maintenance version part but we are
>> switching to
>> >> > Git
>&g

Re: variable doesn't work for version

[Benson Margulies]

On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> I assume it should be this (instead of spy):
> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
>
> And instead of starting beer machine, it can inject the value into the
> session that you got from whenever...

I don't think this can work as a thing configured in the POM. Unless
these items can be dropped into the ext directory instead of
configured in the the pom as an extension. Is that the case in general
that the ext dir is the same thing as declaring in the POM as an
extension?


>
> maven related changes merely laxed the validation to allow those three
> expressions in version, but does not provide anything as "source" for those.
>
> On Wed, Mar 9, 2016 at 2:44 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> I have no clue... that is a different question we should ask of the person
>> who implemented this functionality
>>
>> On 9 March 2016 at 13:40, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> > On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
>> > <stephen.alan.conno...@gmail.com> wrote:
>> > > In the .mvn folder put an extension that contributes the ${rev}
>> property
>> > > based on whatever you seem safe
>> >
>> > Stephen, can you please offer some details? Just what sort of
>> > extension? An event spy that sees session start? Something else? Does
>> > this require 3.3.x  or does it work with 3.2.5?
>> >
>> > >
>> > > Then just have the project version include the ${rev} at the
>> appropriate
>> > > place
>> > >
>> > > On Tuesday 8 March 2016, Gary Gregory <garydgreg...@gmail.com> wrote:
>> > >
>> > >> On Mon, Mar 7, 2016 at 6:53 PM, Eric B <ebenza...@gmail.com
>> > <javascript:;>>
>> > >> wrote:
>> > >>
>> > >> > The first question I have to ask is what you are trying to
>> accomplish
>> > >> with
>> > >> > your continuous-delivery?
>> > >>
>> > >>
>> > >> We have a Maven multi-module build which has thousands of unit tests.
>> We
>> > >> use Bamboo for CI and if we get a green build that means that all the
>> > tests
>> > >> pass of course and that we successfully deployed the build to our repo
>> > (we
>> > >> use Artifactory). We use the Maven's deploy to deploy, not the release
>> > >> plugin.
>> > >>
>> > >> At this point anyone can use the built product out of Bamboo's saved
>> > >> artifacts or Artifactory: our internal/external consultants, sales
>> > >> engineers, formal QA, other downstream, products, and so on. It's up
>> to
>> > the
>> > >> PO to decide when to slap a new major or minor version label and
>> he/she
>> > can
>> > >> do at anytime.
>> > >>
>> > >> From development's POV, a green build is a released product, with a
>> > version
>> > >> for example 3.1.201601070101 (3.1.MMDDHHMM). We used to have the
>> SVN
>> > >> version number as the maintenance version part but we are switching to
>> > Git
>> > >> soon, hence the move to timestamps.
>> > >>
>> > >> Our parent POM contains what is considered a Maven "hack":
>> > >>
>> > >>   
>> > >>
>> > >>
>> > MMddHHmm
>> > >> 3
>> > >> 1
>> > >> ${version.major}.${version.minor}
>> > >> ${maven.build.timestamp}
>> > >> ${version.main}.${revision}
>> > >>
>> > >> Each module then has:
>> > >>
>> > >> ${dv.version}
>> > >>
>> > >> What is the Maven way to achieve this goal?
>> > >>
>> > >> Gary
>> > >>
>> > >>
>> > >>
>> > >> > Are you trying to put snapshot versions into a
>> > >> > production/release state?
>> > >> >
>> > >> > The biggest issue I have noticed with teams is the misunderstanding
>> of
>> > >> how
>> > >> > SNAPSHOTs work, or their purpose in the development process.  Either
>> > >> teams
>> > >> > want to release applicati

Re: variable doesn't work for version

[Benson Margulies]

On Tue, Mar 8, 2016 at 2:28 PM, Stephen Connolly
 wrote:
> In the .mvn folder put an extension that contributes the ${rev} property
> based on whatever you seem safe

Stephen, can you please offer some details? Just what sort of
extension? An event spy that sees session start? Something else? Does
this require 3.3.x  or does it work with 3.2.5?

>
> Then just have the project version include the ${rev} at the appropriate
> place
>
> On Tuesday 8 March 2016, Gary Gregory  wrote:
>
>> On Mon, Mar 7, 2016 at 6:53 PM, Eric B >
>> wrote:
>>
>> > The first question I have to ask is what you are trying to accomplish
>> with
>> > your continuous-delivery?
>>
>>
>> We have a Maven multi-module build which has thousands of unit tests. We
>> use Bamboo for CI and if we get a green build that means that all the tests
>> pass of course and that we successfully deployed the build to our repo (we
>> use Artifactory). We use the Maven's deploy to deploy, not the release
>> plugin.
>>
>> At this point anyone can use the built product out of Bamboo's saved
>> artifacts or Artifactory: our internal/external consultants, sales
>> engineers, formal QA, other downstream, products, and so on. It's up to the
>> PO to decide when to slap a new major or minor version label and he/she can
>> do at anytime.
>>
>> From development's POV, a green build is a released product, with a version
>> for example 3.1.201601070101 (3.1.MMDDHHMM). We used to have the SVN
>> version number as the maintenance version part but we are switching to Git
>> soon, hence the move to timestamps.
>>
>> Our parent POM contains what is considered a Maven "hack":
>>
>>   
>>
>> MMddHHmm
>> 3
>> 1
>> ${version.major}.${version.minor}
>> ${maven.build.timestamp}
>> ${version.main}.${revision}
>>
>> Each module then has:
>>
>> ${dv.version}
>>
>> What is the Maven way to achieve this goal?
>>
>> Gary
>>
>>
>>
>> > Are you trying to put snapshot versions into a
>> > production/release state?
>> >
>> > The biggest issue I have noticed with teams is the misunderstanding of
>> how
>> > SNAPSHOTs work, or their purpose in the development process.  Either
>> teams
>> > want to release applications in SNAPSHOT mode, or release code that is
>> > essentially in SNAPSHOT (ie: development) mode, but with fixed version
>> > numbers.  But instead of changing version numbers, they use something
>> like
>> > a timestamp to increment version numbers automatically.  But at the end
>> of
>> > it all, it kind of contravenes maven's versioning concept.
>> >
>> > Normally, if your artifact is a work in progress, you should just be
>> using
>> > a SNAPSHOT.  If you are looking to make a real release, then you should
>> be
>> > promoting your code from a SNAPSHOT to a fixed version.  Generally, the
>> > concept of continuous-delivery should only apply when in a SNAPSHOT mode,
>> > since anything else isn't changing (ie: a fixed release doesn't need to
>> be
>> > re-delivered).
>> >
>> > So then that begs the question why you need to constantly change your
>> > version numbers during your development phase?
>> >
>> > And if the goal is truly to have fixed versions for some other team to
>> have
>> > access to a "stable" version of your artifact (ie: they can be guaranteed
>> > that it isn't going to change as you continue to develop), you could
>> always
>> > use something like the maven-release-plugin to promote from SNAPSHOT to a
>> > fixed version, and then re-open the next version as a SNAPSHOT.
>> (Although
>> > I know there are many dissenters against the release-plugin).
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> >
>> >
>> > On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory > >
>> > wrote:
>> >
>> > > Is there a Maven-way to do continuous delivery then? As opposed
>> > > to continuous integration.
>> > >
>> > > Our current hack is to use the date as the maintenance version as a
>> > > variable for example 3.1.20160102
>> > >
>> > > G
>> > >
>> > > On Mon, Mar 7, 2016 at 11:18 AM, Eric B > > wrote:
>> > >
>> > > > I personally have a pet-peeve of using system variables to define
>> > version
>> > > > numbers; I find it is counter productive to the building of maven
>> > > > artifacts.  There is no traceability to determine  the actual version
>> > of
>> > > an
>> > > > artifact once it has been built.  At least having a fixed version
>> > number
>> > > in
>> > > > the  element shows up in the META-INF/maven/../pom.* files.
>> > > >
>> > > > Is using a variable for the version even a good idea?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Eric
>> > > >
>> > > >
>> > > > On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
>> > > > stephen.alan.conno...@gmail.com > wrote:
>> > > >
>> > > > > only specific properties are permitted for expansion in XPath paths
>> > > that
>> > > > > match 

Re: CD versioning

[Benson Margulies]

Jason, ping?


On Mon, Jan 25, 2016 at 7:36 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> I'm in. How non-public do you need it to be? On github quietly, or
> passed along through some other channel? Either way is fine with me.
>
>
> On Thu, Jan 21, 2016 at 9:17 PM, Jason van Zyl <ja...@takari.io> wrote:
>> I have something that I wouldn’t make public but you’re free to hack it up 
>> and do what you like with it.
>>
>>> On Jan 21, 2016, at 11:47 AM, Benson Margulies <bimargul...@gmail.com> 
>>> wrote:
>>>
>>> On Thu, Jan 21, 2016 at 2:42 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
>>> wrote:
>>>> Hi Benson,
>>>>
>>>> you know that you can define the following properties since Maven 3.2.1[1]
>>>>
>>>> ${revision}, ${changelist} and ${sha1} which can be set outside from Maven
>>>> via:
>>>>
>>>> mvn -Drevision=1.2.3-SNAPSHOT ...
>>>>
>>>> and you can use it:
>>>>
>>>> 
>>>>  ...
>>>>  ...
>>>>  ${revision}
>>>> ..
>>>> 
>>>>
>>>> in case of a multi module build you can also use it in the parent 
>>>> definition
>>>> of the children...
>>>>
>>>>
>>>> but there does not exist some kind of jar which generates the version...as
>>>> far as i know...
>>>
>>> that's the disconnect; i thought that JvZ or someone described a
>>> drop-in Jar that could cause a property to come into existence (which
>>> could then be referenced). Of course, I can wrap a script around mvn
>>> if there is no such beast.
>>>
>>>
>>>>
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>>
>>>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>>>>
>>>> On 1/20/16 1:11 PM, Benson Margulies wrote:
>>>>>
>>>>> Some time ago, I recall some email about dynamic versioning; the idea
>>>>> being that all the  elements in all the POMs of the project
>>>>> would look like ${version}, and a jar dropped into
>>>>> the maven extensions directory would provide a component that would
>>>>> generate the version, perhaps from a git hash or something like that.
>>>>> Is there any doc around on how to set this up? Is it functional in
>>>>> 3.2.5?
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>>
>>
>> -
>> 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: CD versioning

[Benson Margulies]

I'm in. How non-public do you need it to be? On github quietly, or
passed along through some other channel? Either way is fine with me.


On Thu, Jan 21, 2016 at 9:17 PM, Jason van Zyl <ja...@takari.io> wrote:
> I have something that I wouldn’t make public but you’re free to hack it up 
> and do what you like with it.
>
>> On Jan 21, 2016, at 11:47 AM, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> On Thu, Jan 21, 2016 at 2:42 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
>> wrote:
>>> Hi Benson,
>>>
>>> you know that you can define the following properties since Maven 3.2.1[1]
>>>
>>> ${revision}, ${changelist} and ${sha1} which can be set outside from Maven
>>> via:
>>>
>>> mvn -Drevision=1.2.3-SNAPSHOT ...
>>>
>>> and you can use it:
>>>
>>> 
>>>  ...
>>>  ...
>>>  ${revision}
>>> ..
>>> 
>>>
>>> in case of a multi module build you can also use it in the parent definition
>>> of the children...
>>>
>>>
>>> but there does not exist some kind of jar which generates the version...as
>>> far as i know...
>>
>> that's the disconnect; i thought that JvZ or someone described a
>> drop-in Jar that could cause a property to come into existence (which
>> could then be referenced). Of course, I can wrap a script around mvn
>> if there is no such beast.
>>
>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>>>
>>> On 1/20/16 1:11 PM, Benson Margulies wrote:
>>>>
>>>> Some time ago, I recall some email about dynamic versioning; the idea
>>>> being that all the  elements in all the POMs of the project
>>>> would look like ${version}, and a jar dropped into
>>>> the maven extensions directory would provide a component that would
>>>> generate the version, perhaps from a git hash or something like that.
>>>> Is there any doc around on how to set this up? Is it functional in
>>>> 3.2.5?
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
>
>
> -
> 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: CD versioning

[Benson Margulies]

On Thu, Jan 21, 2016 at 2:42 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi Benson,
>
> you know that you can define the following properties since Maven 3.2.1[1]
>
> ${revision}, ${changelist} and ${sha1} which can be set outside from Maven
> via:
>
> mvn -Drevision=1.2.3-SNAPSHOT ...
>
> and you can use it:
>
> 
>   ...
>   ...
>   ${revision}
> ..
> 
>
> in case of a multi module build you can also use it in the parent definition
> of the children...
>
>
> but there does not exist some kind of jar which generates the version...as
> far as i know...

that's the disconnect; i thought that JvZ or someone described a
drop-in Jar that could cause a property to come into existence (which
could then be referenced). Of course, I can wrap a script around mvn
if there is no such beast.


>
> Kind regards
> Karl Heinz Marbaise
>
> [1]: http://maven.apache.org/docs/3.2.1/release-notes.html
>
> On 1/20/16 1:11 PM, Benson Margulies wrote:
>>
>> Some time ago, I recall some email about dynamic versioning; the idea
>> being that all the  elements in all the POMs of the project
>> would look like ${version}, and a jar dropped into
>> the maven extensions directory would provide a component that would
>> generate the version, perhaps from a git hash or something like that.
>> Is there any doc around on how to set this up? Is it functional in
>> 3.2.5?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

CD versioning

[Benson Margulies]

Some time ago, I recall some email about dynamic versioning; the idea
being that all the  elements in all the POMs of the project
would look like ${version}, and a jar dropped into
the maven extensions directory would provide a component that would
generate the version, perhaps from a git hash or something like that.
Is there any doc around on how to set this up? Is it functional in
3.2.5?

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

Re: dependency:tree and wildcard exclusions

[Benson Margulies]

What evidence do you have that wildcard exclusions work at all? I'd
appreciate a pointer.

On Fri, Jan 15, 2016 at 9:47 PM, Jamie Johnson  wrote:
> I was trying to look at my applications dependency tree and noticed that it
> appears that wildcard expressions in exclusions do not get reflected in the
> tree, is that the case or is there a special usage to have the
> dependency:tree reflect these?

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

Surefire 2.19.1 is still failing to operate forks properly

[Benson Margulies]

I have a rather complex project using pax-exam that works fine with
2.18 and not with 2.19 or 2.19.1, contrary to some confused email I
sent the other day. Setting forkCount to 0 makes the immediate problem
go away, but messes up other things for me because of the different
working directory when running with no fork.

What, if anything, can I do to help the surefire devs diagnose this? I
don't have a small test case.

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

Re: surefire 'forked vm failed'

[Benson Margulies]

I was wrong, as I noted elsewhere. 2.18 good, 2.19.x bad.


On Thu, Jan 14, 2016 at 7:57 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> 2.19.1 is just as broken in these cases.
>
> On Tue, Jan 12, 2016 at 3:57 PM, Andreas Gudian
> <andreas.gud...@gmail.com> wrote:
>> You might wanna try 2.19.1, where Tibor fixed a couple of issues regarding
>> the fork-communication that crept in to 2.19.
>>
>> 2016-01-12 15:13 GMT+01:00 Benson Margulies <bimargul...@gmail.com>:
>>
>>> It might be related to:
>>>
>>> [SUREFIRE] std/in stream corrupted
>>> java.io.IOException: Command NOOP unexpectedly read Void data with length
>>> 4.
>>> at
>>> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:139)
>>> at
>>> org.apache.maven.surefire.booter.MasterProcessReader.read(MasterProcessReader.java:421)
>>> at
>>> org.apache.maven.surefire.booter.MasterProcessReader.access$800(MasterProcessReader.java:59)
>>> at
>>> org.apache.maven.surefire.booter.MasterProcessReader$CommandRunnable.run(MasterProcessReader.java:463)
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>> On Tue, Jan 12, 2016 at 9:09 AM, Benson Margulies <bimargul...@gmail.com>
>>> wrote:
>>> > I'm suddenly suffering from the following, is there any diagnostic
>>> > procedure recommended?
>>> >
>>> > [ERROR] Failed to execute goal
>>> > org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
>>> > (integration-tests) on project rosapi-itests-tests: Execution
>>> > integration-tests of goal
>>> > org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
>>> > failed: The forked VM terminated without properly saying goodbye. VM
>>> > crash or System.exit called?
>>> > [ERROR] Command was /bin/sh -c cd
>>> > /Users/benson/x/rosapi1.5/itests/tests &&
>>> >
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
>>> > -jar
>>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefirebooter205636317211670207.jar
>>> >
>>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire4524699189561772110tmp
>>> >
>>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire_05188544004656785245tmp
>>>
>>> -
>>> 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: surefire 'forked vm failed'

[Benson Margulies]

2.19.1 is just as broken in these cases.

On Tue, Jan 12, 2016 at 3:57 PM, Andreas Gudian
<andreas.gud...@gmail.com> wrote:
> You might wanna try 2.19.1, where Tibor fixed a couple of issues regarding
> the fork-communication that crept in to 2.19.
>
> 2016-01-12 15:13 GMT+01:00 Benson Margulies <bimargul...@gmail.com>:
>
>> It might be related to:
>>
>> [SUREFIRE] std/in stream corrupted
>> java.io.IOException: Command NOOP unexpectedly read Void data with length
>> 4.
>> at
>> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:139)
>> at
>> org.apache.maven.surefire.booter.MasterProcessReader.read(MasterProcessReader.java:421)
>> at
>> org.apache.maven.surefire.booter.MasterProcessReader.access$800(MasterProcessReader.java:59)
>> at
>> org.apache.maven.surefire.booter.MasterProcessReader$CommandRunnable.run(MasterProcessReader.java:463)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> On Tue, Jan 12, 2016 at 9:09 AM, Benson Margulies <bimargul...@gmail.com>
>> wrote:
>> > I'm suddenly suffering from the following, is there any diagnostic
>> > procedure recommended?
>> >
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
>> > (integration-tests) on project rosapi-itests-tests: Execution
>> > integration-tests of goal
>> > org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
>> > failed: The forked VM terminated without properly saying goodbye. VM
>> > crash or System.exit called?
>> > [ERROR] Command was /bin/sh -c cd
>> > /Users/benson/x/rosapi1.5/itests/tests &&
>> >
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
>> > -jar
>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefirebooter205636317211670207.jar
>> >
>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire4524699189561772110tmp
>> >
>> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire_05188544004656785245tmp
>>
>> -
>> 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: surefire 'forked vm failed'

[Benson Margulies]

It might be related to:

[SUREFIRE] std/in stream corrupted
java.io.IOException: Command NOOP unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:139)
at 
org.apache.maven.surefire.booter.MasterProcessReader.read(MasterProcessReader.java:421)
at 
org.apache.maven.surefire.booter.MasterProcessReader.access$800(MasterProcessReader.java:59)
at 
org.apache.maven.surefire.booter.MasterProcessReader$CommandRunnable.run(MasterProcessReader.java:463)
at java.lang.Thread.run(Thread.java:745)


On Tue, Jan 12, 2016 at 9:09 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> I'm suddenly suffering from the following, is there any diagnostic
> procedure recommended?
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
> (integration-tests) on project rosapi-itests-tests: Execution
> integration-tests of goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
> failed: The forked VM terminated without properly saying goodbye. VM
> crash or System.exit called?
> [ERROR] Command was /bin/sh -c cd
> /Users/benson/x/rosapi1.5/itests/tests &&
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
> -jar 
> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefirebooter205636317211670207.jar
> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire4524699189561772110tmp
> /Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire_05188544004656785245tmp

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

surefire 'forked vm failed'

[Benson Margulies]

I'm suddenly suffering from the following, is there any diagnostic
procedure recommended?

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
(integration-tests) on project rosapi-itests-tests: Execution
integration-tests of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.19:integration-test
failed: The forked VM terminated without properly saying goodbye. VM
crash or System.exit called?
[ERROR] Command was /bin/sh -c cd
/Users/benson/x/rosapi1.5/itests/tests &&
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/bin/java
-jar 
/Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefirebooter205636317211670207.jar
/Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire4524699189561772110tmp
/Users/benson/x/rosapi1.5/itests/tests/target/surefire/surefire_05188544004656785245tmp

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

Tracking down a

[Benson Margulies]

I can't build Apache CXF when my normal Nexus mirror is in place; it
fails to find:

org.springframework:org.springframework.context:2.5.6.SEC01

I can if I turn off my mirrors. So, I'm trying to determine what repo
I need to add to my Nexus or exclude from my mirrors.

Mirrorless, I see

➜ 2.5.6.SEC01 cat _remote.repositories
#NOTE: This is an Aether internal implementation file, its format can
be changed without prior notice.
#Fri Dec 11 08:13:18 EST 2015
org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=

How do I get from here to a URL /  declaration?

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

Re: Tracking down a

[Benson Margulies]

And indeed that's the ID to add to the mirror ! list!

On Fri, Dec 11, 2015 at 9:47 AM, Anders Hammar <and...@hammar.net> wrote:
> And by "that id" I mean 'com.springsource.repository.bundles.release'
>
> /Anders (mobile)
> On Dec 11, 2015 15:45, "Anders Hammar" <and...@hammar.net> wrote:
>
>> Most likely it is in one of the spring poms. Can't you search for that id
>> in all poms in your local Maven repo?
>>
>> /Anders (mobile)
>> On Dec 11, 2015 15:38, "Benson Margulies" <bimargul...@gmail.com> wrote:
>>
>>> I can't build Apache CXF when my normal Nexus mirror is in place; it
>>> fails to find:
>>>
>>> org.springframework:org.springframework.context:2.5.6.SEC01
>>>
>>> I can if I turn off my mirrors. So, I'm trying to determine what repo
>>> I need to add to my Nexus or exclude from my mirrors.
>>>
>>> Mirrorless, I see
>>>
>>> ➜ 2.5.6.SEC01 cat _remote.repositories
>>> #NOTE: This is an Aether internal implementation file, its format can
>>> be changed without prior notice.
>>> #Fri Dec 11 08:13:18 EST 2015
>>>
>>> org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
>>>
>>> org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=
>>>
>>> How do I get from here to a URL /  declaration?
>>>
>>> -
>>> 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

Reactor versus classifiers ...

[Benson Margulies]

I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.

One module builds a Karaf feature with the karaf maven plugin; this produces:


${project.groupId}
rosapi-features
${project.version}
features
xml
runtime


The packaging of this project is 'feature' to use the karaf-maven-plugin.


The second module consumes it, via the dependency above. It also uses
the karaf-maven-plugin with a different packaging to make the karaf
assembly.

When I try to run release:prepare, I fail, because the features.xml
file is not, apparently, resolved correctly from the reactor. Does
anyone here on the Maven side have any suggestions before I try to
dive into the Karaf side? Of course, it works fine when I am _not_
running the release plugin.

[INFO] [WARNING] Error resolving
artifactcom.basistech.ws:rosapi-features:xml:features:0.7.100:Could
not find artifact
com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
Technology Corp. Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public)
[INFO] shaded.org.eclipse.aether.resolution.ArtifactResolutionException:
Could not find artifact
com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
Technology Corp. Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public)

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

Re: Reactor versus classifiers ...

[Benson Margulies]

None of this is relevant to the simple build process of incorporating
a feature in a karaf assembly.

Adding 'install' to the preparationGoals of the release plugin is the
workaround.


On Wed, Oct 21, 2015 at 8:41 PM, Martin Gainty  wrote:
>
>
>> Date: Wed, 21 Oct 2015 13:56:39 -0400
>> Subject: Reactor versus classifiers ...
>> From: bimargul...@gmail.com
>> To: users@maven.apache.org
>>
>> I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.
>>
>> One module builds a Karaf feature with the karaf maven plugin; this produces:
>>
>> 
>> ${project.groupId}
>> rosapi-features
>> ${project.version}
>> features
>> xml
>> runtime
>> 
>>
>> The packaging of this project is 'feature' to use the karaf-maven-plugin.
>>
>>
>> The second module consumes it, via the dependency above. It also uses
>> the karaf-maven-plugin with a different packaging to make the karaf
>> assembly.
>>
>> When I try to run release:prepare, I fail, because the features.xml
>> file is not, apparently, resolved correctly from the reactor. Does
>> anyone here on the Maven side have any suggestions before I try to
>> dive into the Karaf side? Of course, it works fine when I am _not_
>> running the release plugin.
>>
>> [INFO] [WARNING] Error resolving
>> artifactcom.basistech.ws:rosapi-features:xml:features:0.7.100:Could
>> not find artifact
>> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
>> Technology Corp. Nexus
>> (http://nexus.basistech.net:8081/nexus/content/groups/public)
>> [INFO] shaded.org.eclipse.aether.resolution.ArtifactResolutionException:
>> Could not find artifact
>> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
>> Technology Corp. Nexus
>> (http://nexus.basistech.net:8081/nexus/content/groups/public)
>
> MG>you can add a jaraf feature to feature repository via 
> MG>feature:addMG>https://karaf.apache.org/manual/latest/users-guide/provisioning.htmlMG>verify
>  the feature registration has taken placeMG>feature:repo-list
> MG>at some point you may want to assemble 
> MG>https://karaf.apache.org/manual/latest/developers-guide/custom-distribution.htmlMG>where
>  maven-assembly specifies descriptor 
> src/main/descriptors/bin.xml in configurationMG>the 
> assembly bin.xml contains filenames you wish to include in 
>
> MG>karaf plugin produces kar assemblies from OSGI buildMG>once kar assembly  
> is created you can cp to deploy folderMG>then use the 
> 'feature-deployer'https://karaf.apache.org/manual/latest/users-guide/deployers.htmlhttps://karaf.apache.org/manual/latest/users-guide/provisioning.html
> Have fun> 
> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>

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

Re: Maven profiles vs Archetypes

[Benson Margulies]

Once you've run an archetype, you have a new project. And you're stuck
with it, in the sense that you have to keep it maintained.

An important question is this: what artifacts do you want to make as
part of a release? If you want a portfolio of artifacts, each for one
of your scenarios, then profiles aren't very useful, but the invoker
plugin might be.

On the other hand, if you never make releases, and you just want to
run various build with various results, then profiles can be
convenient.

The invoker is generally used for testing, and I've never tried it as
a solution to DRY-ing up a build that has to produce multiple small
variations.

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

Re: Maven profiles vs Archetypes

[Benson Margulies]

If each project picks a style and sticks to it, then archetypes are appropriate.

On Mon, Oct 19, 2015 at 11:26 AM, Patrick Sansoucy
<patrick.sanso...@gmail.com> wrote:
> Re,
>
> Basically, the end result would be to support multiple teams with multiple
> web application servers and setup (shared libs vs non shared libs). Thus
> each internal team does not go back and forth between setups/server. For a
> vast majority of cases, the decision is done once, at the start of the
> project, and you live with it.
>
> As for the question, like I said previously, the release drives a single
> artifact 'type', not a portfolio. The profile idea is basically used only
> to support the initial branching for the teams.
>
> Never thought about the Invoker plugin that way. I had suggested of using
> it to test the templating of the archetypes themselves, but not more. Since
> using profiles means that you have to execute the build itself to validate,
> while using the archetype, you test the structure and content of the
> created project, which I find easier.
>
>
>
> Patrick Sansoucy
> In theory, there is no difference between theory and practice, but in
> practice, there is ...
>
> On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> Once you've run an archetype, you have a new project. And you're stuck
>> with it, in the sense that you have to keep it maintained.
>>
>> An important question is this: what artifacts do you want to make as
>> part of a release? If you want a portfolio of artifacts, each for one
>> of your scenarios, then profiles aren't very useful, but the invoker
>> plugin might be.
>>
>> On the other hand, if you never make releases, and you just want to
>> run various build with various results, then profiles can be
>> convenient.
>>
>> The invoker is generally used for testing, and I've never tried it as
>> a solution to DRY-ing up a build that has to produce multiple small
>> variations.
>>
>> -
>> 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

[ANN] Apache Maven Plugins (parent POM) version 28 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Apache
Maven Plugins parent POM, version 28.

This POM is the common parent of all of the plugins maintained by the
Apache Maven PMC, and, as such, is of limited use to developers
outside of the Maven project. See the svn history of
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-plugins/pom.xml
for information on the content of this release.

The primary change here is to move to version 27 of the overall Maven
parent POM.\

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

Re: [ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

Laird,

I really can't help you with this, I was 99% just the release manager of
this thing. I recommend, however, reading the source of the
maven-dependency-plugin, which uses the new API.



On Mon, Oct 12, 2015 at 3:01 PM, Laird Nelson <ljnel...@gmail.com> wrote:

> On Sat, Oct 10, 2015 at 12:04 PM, Benson Margulies <bimargul...@apache.org
> > wrote:
>
>> The Maven team is pleased to announce the release of the Apache Maven
>> Dependency Tree, version 3.0
>>
>
> Hello, Benson; I was wondering what the proper upgrade path for usage of
> DependencyGraphBuilder#buildDependencyGraph() should be.
>
> In version 2.2, the first parameter was a MavenProject, which I'm passing
> in just fine.
>
> In version 3.0, the first parameter is now a ProjectBuildingRequest.
> Will it suffice to create one of these, call its setProject() method (and
> no other methods), and then pass in the resulting request for equivalent
> behavior?  Or is additional configuration now needed?
>
> Thanks,
> Best,
> Laird
>
> --
>
> [image: --]
>
> Laird Nelson
> [image: http://]about.me/lairdnelson
> <http://about.me/lairdnelson?promo=email_sig>
>
>

[ANN] Apache Maven Assembly Plugin 2.6 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Apache
Maven Assembly Plugin, version 2.6

This plugin builds directories and archives of files, usually for releases.

http://maven.apache.org/plugins/maven-assembly-plugin/

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


org.apache.maven.plugins
maven-assembly-plugin



You can download the appropriate sources etc. from the download page:

http://maven.apache.org/plugins/maven-2.6-plugin/download.cgi

Release Notes - Maven Assembly Plugin - Version 2.6

Improvements:
MASSEMBLY-780   Snappy supported  06/Oct/15

NOTE: This version requires Java 1.6.


Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven maven-dependency-tree 3.0

[Benson Margulies]

The Maven team is pleased to announce the release of the Apache Maven
Dependency Tree, version 3.0

A tree-based API for resolution of Maven project dependencies

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

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


  org.apache.maven.shared
  maven-dependency-tree
  3.0



Release Notes - Apache Maven Dependency Tree - Version 3.0

Bug
* [MSHARED-422] Change DependencyGraphBuilder method signatures

Improvement
* [MSHARED-421] Change JDK + Maven requirements
* [MSHARED-371] Increase chance of java8 compliance by updating to
plexus-component-* 1.6


Enjoy,

-The Maven team

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

Re: Is there a cache of version range resolutions?

[Benson Margulies]

I use 3.2.5. I've since confirmed that version ranges don't work the
same way as the release plugin, so in some sense this problem is moot.
But, still, the problem is the mysterious caching of a
previously-selected version.

On Sun, Oct 4, 2015 at 5:07 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> Hi,
>
> On 10/2/15 11:06 PM, Benson Margulies wrote:
>>
>> I've just tried version ranges for the first time, and I hit a pothole.
>>
>> Step 1: set version in dependency to: 7.14.0.c52.2. Run a build.
>>
>> Step 2: change version in pom to  [7.13.500.c52.2,7.13.600.c52.2).
>>
>> Now, mvn dependency:whatever shows the correct resolution, but an
>> actual build stubbornly uses the 7.14.0.c52.2 version in the
>> karaf-maven-plugin.
>
>
> Which Maven version do you use?
>
> Kind regards
> Karl Heinz Marbaise
>
>>
>> Completely wiping ~/.m2/repository fixed this.
>>
>> Can anyone give me higher-precision coordinates for what data I need
>> to nuke when this happens?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Is there a cache of version range resolutions?

[Benson Margulies]

I've just tried version ranges for the first time, and I hit a pothole.

Step 1: set version in dependency to: 7.14.0.c52.2. Run a build.

Step 2: change version in pom to  [7.13.500.c52.2,7.13.600.c52.2).

Now, mvn dependency:whatever shows the correct resolution, but an
actual build stubbornly uses the 7.14.0.c52.2 version in the
karaf-maven-plugin.

Completely wiping ~/.m2/repository fixed this.

Can anyone give me higher-precision coordinates for what data I need
to nuke when this happens?

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

Merging in xdoc from another module in site plugin

[Benson Margulies]

I've got a utility module with modello in it. I want to pull the xdoc
from that into the site doc of a plugin that uses it. Do I need to
'attach' it and then use the dependency plugin to grab it? I don't see
a way in the site plugin to add additional site content directories,
only to change the location of the main one.

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

Maven repeating itself (3.2.5)

[Benson Margulies]

One of our builds has developed a stutter.

These log messages (and the details and work that go with them) are
repeating several times. I can't find any evidence of a forked
lifecycle, but maybe I've forgotten how to look.

[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (root)
[DEBUG] Style: Regular
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?

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

Re: Maven repeating itself (3.2.5)

[Benson Margulies]

This is a bug in the maven-bundle-plugin, as it turns out.

On Tue, Aug 25, 2015 at 1:46 PM, Benson Margulies bimargul...@gmail.com wrote:
 One of our builds has developed a stutter.

 These log messages (and the details and work that go with them) are
 repeating several times. I can't find any evidence of a forked
 lifecycle, but maybe I've forgotten how to look.

 [DEBUG] 
 ---
 [DEBUG] Goal:
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (root)
 [DEBUG] Style: Regular
 [DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?

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

Re: Use 2 pom.xml files with different names

[Benson Margulies]

On Mon, Aug 10, 2015 at 11:04 AM, Alex Ditu ditu.alexan...@gmail.com wrote:
 I know how to solve my problem (by changing the project configuration).

 My question is: why mvn -f otherPomName.xml deploy doesen't work? And I
 said above how it fails.

It does not _fail_. It does precisely what it is designed to do.

mvn -f says, 'read the model of this project from an alternative
location, and then do what you do.'

Once Maven has read the XML, it has no idea where the file came from,
and it's not supposed to have any idea where the file came from.
Maven's job is to do the build as specified by the POM abstract data
model. That makes no provisions for your scheme.



 On Aug 10, 2015 5:59 PM, Barrie Treloar baerr...@gmail.com wrote:

 On 10 August 2015 at 23:22, Alex Ditu ditu.alexan...@gmail.com wrote:

  Ok, look what I am trying to achieve: I have a project with 2
  profileDeployments (it produces 2 types of artifacts: a jar and a war)
  but from the same sources. So, I did the following thing: I have
  written 2 pom.xml files with 2 different names (for example: pom.xml
  and pom2.xml). When I want to build the .jar artifact I would use the
  command 'mvn deploy' when I want the .war artifact I would use: 'mvn
  -f pom2.xml' --- after this, I encounter the problem I mentioned
  earlier.
 
  Note that the artifactIds are different.


 You solution is simple: do not have one project, split it into multiple
 projects.

 A war file should not have any java code in it. So there is no need for you
 do be having two poms. You war project depends on the jar project and you
 are done.

 There are plenty of examples on how to do this in the freely available
 maven books at http://maven.apache.org/articles.html


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

Re: Use 2 pom.xml files with different names

[Benson Margulies]

Formally, a project has can only produce one POM artifact. So, you can
do whatever you want with -f, but when it comes to install or deploy,
you are pushing the one-and-only pom (selected from the file system
with -f), and it gets the immutable, conventional, name of the pom
artifact in the repository. Perhaps if you explained what you want to
accomplish we could be more helpful.


On Mon, Aug 10, 2015 at 7:12 AM, Alex Ditu ditu.alexan...@gmail.com wrote:
 Hello,

 I want to use pom.xml files for my project with 2 different names:
 pom.xml and pom2.xml.
 In order to select wich one to execute/use I use -f pom-name like this:

 mvn -f pom2.xml deploy

 Using this aproach I've encountered some problems in 2 scenarios:

 1. If both pom.xml and pom2.xml exist when running the install phase,
 altough I've specified -f pom2.xml, maven is still using 'pom.xml'
 when installing my jar in .m2: output looks like this:

 installing .../project/pom.xml 
 /.m2/.../project/artifact-1.0.0-SNAPSHOT.pom

 it should be:
 installing .../project/pom2.xml 
 /.m2/.../project/artifact-1.0.0-SNAPSHOT.pom

 but because it finds pom.xml it passes this phase, and when it reaches
 deploy phase it gives this error:

 deploy failed: Cannot add two different pieces of metadata for:
 project dvh.web.sockets.push.server:webSocketsPushServerCommon


 2. If I have just one pom file but with a different name (for eg.
 pom2.xml) it doesn't pass the install phase, because it searches for
 pom.xml not for pom2.xml (so it appears that 'mvn -f otherPomName.xml'
 doesn't work for install phase).

 Am I missing something here? Or is just a bug?

 P.S. Don't ask me why I want to use 2 pom files, if anyone encountered
 this situation and knows how to deal with it, help will be much
 appreciated :)

 -
 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: Running jdeb plugin by itself .. not attached to the package lifecycle.

[Benson Margulies]

attachfalse/attach

On Sun, Aug 2, 2015 at 4:40 PM, Kevin Burton bur...@spinn3r.com wrote:
 The Maven jdeb plugin (for building debian packages) recommends you set it
 up like:

 executions
   execution
 phasepackage/phase
 goals
   goaljdeb/goal
 /goals

 … 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
 https://plus.google.com/102718274791889610666/posts

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

Re: Automating the build of a JNI based application

[Benson Margulies]

Look for the modern nar plugin on github.

On Fri, Jul 31, 2015 at 12:59 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 Hi,

 On 7/31/15 6:51 PM, Dušan Rychnovský wrote:

 Hi,

 I'm creating a JNI wrapper on top of a C++ library. I'd like to have a
 one-click Maven build for the whole application. When building it
 manually, I need to do the following:

 javac ... (compile the Java source files)
 javah ... (generate JNI header files from Java class files)
 g++   ... (compile the JNI source files + link them with the static
 library)

 I'm looking for a way to have these commands executed by Maven.

 I looked at the native-maven-plugin (
 http://maven.apache.org/archives/maven-1.x/plugins/native/index.html) and
 I'm afraid it will not work for me.


 Nor should it cause Maven 1 is simply dead..



 * The documentation is extremely insufficient (there is literally no
 official documentation on the plugin site and nor is there any information
 elsewhere on the Internet).


 which is not really astonishing...



 * I cannot even look at the source-code as it isn't there in the SVN
 repository linked from the plugin site.

 * I tried to make it work based on the two SO posts I discovered but I
 couldn't.

 I'm thinking about the following project layout:

 /src
 /src/main
 /src/main/java... the Java interfaces with native methods
 /src/main/native ... the C++ implementation of the generated header files

 The static library itself is a product of a different project and will be
 installed on my system in a standard location (i.e. outside of this
 project).

 What I need is essentially to call the javah and g++ commands after the
 Java .class files have been generated. The g++ command is non-trivial,
 there are quite a few compiler and linker options that need to be applied.
 The generated library file should not be a part of the generated JAR file,
 it should be a separate artifact.

 I was thinking maybe I'll need to use the exec-maven-plugin (
 http://www.mojohaus.org/exec-maven-plugin/index.html) and run the commands
 manually? Or is there a better way to do this?

 Also, once the library is generated, I'd like to have Maven run some test
 cases using the generated JNI wrapper to make sure it works correctly.

 Thanks very much for your help.

 Kind regards,
 Dusan


 I woudl suggest to take a look into the nar-maven-plugin:

 http://maven-nar.github.io/

 which might be better fit your needs..

 Kind Regards
 Karl Heinz Marbaise

 -
 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: A checkstyle plugin mystery

[Benson Margulies]

Yes, it's to do with the forked execution. I've made a test case and
created https://issues.apache.org/jira/browse/MRELEASE-915.

I haven't tried the mavenExecutorId yet, I will in a moment and
annotate the JIRA.


On Sun, Jul 12, 2015 at 1:08 PM, Benson Margulies bimargul...@gmail.com wrote:
 On Sat, Jul 11, 2015 at 5:04 AM, Robert Scholte rfscho...@apache.org wrote:
 You know that release:perform doesn't do any magic. It would be the same as:
 cd target/checkout
 mvn deploy (or mvn deploy site-deploy)

 If this works as expected (without failures), then it looks like something
 is leaking.
 Could you try to switch to the ForkedMavenExecutor?
 mavenExecutorIdforked-path/mavenExecutorId

 Where do I put that? release plugin config?


 thanks,
 Robert

 Op Fri, 10 Jul 2015 03:04:55 +0200 schreef Benson Margulies
 bimargul...@gmail.com:

 Ever since we bumped to 2.15 of the plugin, we've been hitting a
 problem. I don't have a concise repro, so I'm not opening a JIRA yet,
 but I thought I'd inquire for other people's experience.

 We use some source generators, and none of them generate source that
 is acceptable to our checkstyle rules. To prevent checkstyle from
 processing that stuff, we bind the 'check' goal to the validate phase.
 Since this is before generate-sources, it comes and goes before the
 generator plugin(s) have a chance to register any additional source
 roots.

 The recent change afflicts only release builds. All is well until we
 run release:perform, and then the build fails because of checkstyle
 complaints on generated source.

 How is it that the release plugin causes the generated source roots to
 be visible to the plugin?

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


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


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

Re: A checkstyle plugin mystery

[Benson Margulies]

On Sat, Jul 11, 2015 at 5:04 AM, Robert Scholte rfscho...@apache.org wrote:
 You know that release:perform doesn't do any magic. It would be the same as:
 cd target/checkout
 mvn deploy (or mvn deploy site-deploy)

 If this works as expected (without failures), then it looks like something
 is leaking.
 Could you try to switch to the ForkedMavenExecutor?
 mavenExecutorIdforked-path/mavenExecutorId

Where do I put that? release plugin config?


 thanks,
 Robert

 Op Fri, 10 Jul 2015 03:04:55 +0200 schreef Benson Margulies
 bimargul...@gmail.com:

 Ever since we bumped to 2.15 of the plugin, we've been hitting a
 problem. I don't have a concise repro, so I'm not opening a JIRA yet,
 but I thought I'd inquire for other people's experience.

 We use some source generators, and none of them generate source that
 is acceptable to our checkstyle rules. To prevent checkstyle from
 processing that stuff, we bind the 'check' goal to the validate phase.
 Since this is before generate-sources, it comes and goes before the
 generator plugin(s) have a chance to register any additional source
 roots.

 The recent change afflicts only release builds. All is well until we
 run release:perform, and then the build fails because of checkstyle
 complaints on generated source.

 How is it that the release plugin causes the generated source roots to
 be visible to the plugin?

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


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


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

Re: Surefire port in use error

[Benson Margulies]

I'm pretty sure this was the result of forkCount  1. Multiple forks
all tried to grab the port, and all but one failed. is this really
desirable? Should debugForkedTest force the fork count to 1?


On Thu, Jul 9, 2015 at 12:10 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 Reboot  retry.

 K
 9. jul. 2015 3.16 a.m. skrev Benson Margulies bimargul...@gmail.com:

 Port 5005 is NOT in use, but I get the following. What's up?

 SUREFIRE-859: FATAL ERROR in native method: JDWP No transports
 initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
 ERROR: transport error 202: bind failed: Address already in use
 SUREFIRE-859: ERROR: JDWP Transport dt_socket failed to initialize,
 TRANSPORT_INIT(510)
 JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
 initialized [../../../src/share/back/debugInit.c:750]
 SUREFIRE-859: /bin/sh: line 1: 15757 Abort trap: 6

 /Library/Java/JavaVirtualMachines/jdk1.7.0_72.jdk/Contents/Home/jre/bin/java
 -Dfile.encoding=utf-8 -Xmx2g -Xdebug -Xnoagent -Djava.compiler=NONE
 -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar

 /Users/benson/x/ws-bus/cat-processor/target/surefire/surefirebooter7582106457705119502.jar

 /Users/benson/x/ws-bus/cat-processor/target/surefire/surefire6601527055224800422tmp

 /Users/benson/x/ws-bus/cat-processor/target/surefire/surefire_06588360548170775574tmp

 -
 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

A checkstyle plugin mystery

[Benson Margulies]

Ever since we bumped to 2.15 of the plugin, we've been hitting a
problem. I don't have a concise repro, so I'm not opening a JIRA yet,
but I thought I'd inquire for other people's experience.

We use some source generators, and none of them generate source that
is acceptable to our checkstyle rules. To prevent checkstyle from
processing that stuff, we bind the 'check' goal to the validate phase.
Since this is before generate-sources, it comes and goes before the
generator plugin(s) have a chance to register any additional source
roots.

The recent change afflicts only release builds. All is well until we
run release:perform, and then the build fails because of checkstyle
complaints on generated source.

How is it that the release plugin causes the generated source roots to
be visible to the plugin?

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

Surefire port in use error

[Benson Margulies]

Port 5005 is NOT in use, but I get the following. What's up?

SUREFIRE-859: FATAL ERROR in native method: JDWP No transports
initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
SUREFIRE-859: ERROR: JDWP Transport dt_socket failed to initialize,
TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
initialized [../../../src/share/back/debugInit.c:750]
SUREFIRE-859: /bin/sh: line 1: 15757 Abort trap: 6
/Library/Java/JavaVirtualMachines/jdk1.7.0_72.jdk/Contents/Home/jre/bin/java
-Dfile.encoding=utf-8 -Xmx2g -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar
/Users/benson/x/ws-bus/cat-processor/target/surefire/surefirebooter7582106457705119502.jar
/Users/benson/x/ws-bus/cat-processor/target/surefire/surefire6601527055224800422tmp
/Users/benson/x/ws-bus/cat-processor/target/surefire/surefire_06588360548170775574tmp

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

Re: A little puzzle with the build helper

[Benson Margulies]

Once formatted, this is very interesting.

It doesn't quite solve the problem I started with, which that the
plain POM version of this project is not OSGi friendly, even before we
get to -SNAPSHOT.

But it's way cooler than just sticking .SNAPSHOT on the end, so I'm
going to combine it with my other solution.

Thanks!

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

A little puzzle with the build helper

[Benson Margulies]

We don't seem to have a mojo user mailing list post-codehaus, do we?

I'm trying to use the regexPropertySettings goal to map from Maven
version to OSGi version, since I need the OSGi version in more places
than just the manifest.

I can't figure out how to account for -SNAPSHOT well. It does not work
very well to specify two 'setting' blocks for the same value; it just
uses the second -- and I can't figure out how to write a
regex/replacement pair that maps -SNAPSHOT to _SNAPSHOT if present,
and to nothing if absent, while also doing other things.

execution
idosgi-version/id
goals
goalregex-properties/goal
/goals
phasegenerate-resources/phase
configuration
regexPropertySettings
regexPropertySetting
nameosgi-version/name
value${project.version}/value
regex${osgi-version-regex}/regex
replacement${osgi-version-replacement}/replacement
failIfNoMatchfalse/failIfNoMatch
/regexPropertySetting
/regexPropertySettings
/configuration
/execution

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

Re: Help needed with a strange fixed filename

[Benson Margulies]

Put a proxy in front of Nexus.

On Tue, Jun 9, 2015 at 1:51 AM, Thomas Klöber
thomas.kloe...@securintegration.com wrote:
 Hi Ron,

 might have not explained it right: jarfile3.jar gets turned into 
 jarfile3-x.x.x.jar due to the version number i have to supply when creating 
 the artefact in nexus.

 I agree it would be easier to either get rid of the version number at build 
 time or at least change the naming to jarfile-3.jar.
 But unfortunately the vendor refuses to change that.

 Hi Curtis,

 I fully agree that this is a terrible way of programming. But I asked the 
 vendor why they check the file name and thay say that some other apps would 
 fail if they didn't have a fixed jarfile name'. Escapes me why, but again 
 they refuse to cahnge that...

 Bytecode patching is a no go here :)

 Thanks for all your suggestions...


 -Ursprüngliche Nachricht-
 Von: Ron Wheeler [mailto:rwhee...@artifact-software.com]
 Gesendet: Montag, 8. Juni 2015 19:03
 An: users@maven.apache.org
 Betreff: Re: Help needed with a strange fixed filename

 Can you explain how  jarfile3.jar gets turned into jarfile-3.x.x?

 Lots of jar file names have numbers as the last character without that
 character getting turned into a version in Nexus.

 I can see how it would get loaded into Nexus as jarfile3-1.0.0 but not
 jarfile-3.1.0.0

 Getting rid of the version number at the end of the file name at build
 time is an easier task that changing the name.

 Ron



 On 08/06/2015 12:44 PM, Curtis Rueden wrote:
 Hi Thomas,

 it's name cannot be changed because during runtime it is checked and
 if changed a runtime exception is thrown
 IMHO, the fact that your third party JAR does that is incredibly terrible.

 Yes, we could change the code with the filename check. But I'm loath
 to do it since it is a 3rd party jar file and we had to do this every
 time a new version is released...
 One big hammer way to work around this, and other horrible third party
 behaviors, is bytecode manipulation using a library such as Javassist or
 ASM. Also called runtime patching, you can make a surgical change to the
 stupid exception thrown by the 3rd party library, which will be resistant
 to future upgrades of that library. It does require careful use of
 ClassLoaders, though. It would be much more ideal to work with the upstream
 vendor/developers to fix the problem there.

 Regards,
 Curtis

 On Mon, Jun 8, 2015 at 8:10 AM, Thomas Klöber 
 thomas.kloe...@securintegration.com wrote:

 Hi Karl Heinz,

 thanks for your answer.

 Yes, we could change the code with the filename check. But I'm loath to do
 it since it is a 3rd party jar file and we had to do this every time a new
 version is released...

 I'm just surprised that there is no other way or means to tell Maven that
 a different naming scheme should be used...

 Deployment at customer site is no problem, the nexus and naming issue only
 affects us during development.


 -Ursprüngliche Nachricht-
 Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
 Gesendet: Freitag, 5. Juni 2015 14:34
 An: Maven Users List
 Betreff: Re: Help needed with a strange fixed filename

 Hi Thomas,


 That the file is names in Nexus is the default naming schema within a
 maven repository so there is no chance to change it.

 So first question: Why not changing the code which checks the filename
 and follow the naming convention..?

 What you can do is to get the appropriate artifact via plugin (like
 maven-dependency-plugin) and rename it during the packaging of your
 distribution archive (which i assume you have?) Or are we talking about
 an EAR file?




 On 6/5/15 1:58 PM, Thomas Klöber wrote:
 Hi folks'es,

 I am having some problems, getting an external jar-file into my Maven
 project.
 Here is the issue:

 · the jar file has a fixed name, lets say jarfile3.jar (digit 3
 is important!)
 · it's name cannot be changed because during runtime it is
 checked and if changed a runtime exception is thrown
 ·  if I create an artefact for it in my nexus, the file name is
 changed to jarfile-3.x.x
 · adding this to my pom.xml as a dependency everything builds
 just fine
 · however, if I run my application now, it falls over with the
 above runtime exception
 What would be the best way of incoorporating an external jar into my
 project without having hard-coded pathnames?
 We are using Eclipse Kepler as IDE and Maven 3

 Thanks,
 _
 SecurIntegration
 Thomas Klöber
 Software Engineer
 Rösrather Str. 702
 51107 Köln
 Fon: +49 (221) 71 99 00-0
 Fax: +49 (221) 71 99 00-23

 www.SecurIntegration.comhttp://www.SecurIntegration.com

 Amtsgericht Köln HRB 35063
 Geschäftsführer: Guido Schneider

 Determine your actual SAP license needs
 http://www.securintegration.com/slc

 Kind regards
 Karl Heinz Marbaise

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

Re: Skill set to maintain a enterprise build system using Maven

[Benson Margulies]

First, treating build as a separate discipline from code is, in my
experience, a recipe for trouble. The poms or build.xml or whatever
files are just as much part of the source code as the java. Someone
may own Jenkins or whatever, but the devs should own the building of
the code they write.

Second, the environmental impact of Maven depends critically on the
nature of the code. If your entire build is composed of compiling Java
code and delivering jar files, the poms are trivial and the Maven cost
is near-zero. If, on the other extreme, you insist on fighting with
Maven and having policies for dependencies, or releases, or whatever,
that require extensive 'negotiation', it's a very different picture.
In between, if you have significant custom build activity (e.g. code
generators), you might need some of your own plugins.

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

Re: Apache Maven ANT - VPAT

[Benson Margulies]

I cannot imagine how anyone could expect a command-line tool for software
developers to be relevant to 508. We've never considered the question for
Maven and I don't think that we ever will. You might look into how people
treat, for example, 'make' as an model.



On Thu, Apr 23, 2015 at 9:34 AM, amber.l.ak...@accenture.com wrote:

  Hi Apache Team – Apache Maven  ANT are 2 products being used by
 Accenture for a client project. We need your assistance in verifying the
 VPAT status for these 2 products.



 I found the below statement in the community discussion area. Can you
 confirm this is correct and VPAT does not actually apply to Apache? Below I
 have also included a brief description of the U.S Federal VPAT purpose.



 Apache doesn't have anything to do with the accessibility. It just
 provides the web pages which can be accessible or not accessible at all.508
 compliance applies to a site (or a page), not to a server.”



 *The purpose of the Voluntary Product Accessibility Template, or VPAT, is
 to assist Federal contracting officials and other buyers in making
 preliminary assessments regarding the availability of commercial
 “Electronic and Information Technology” products and services with features
 that support accessibility. *



 *The Voluntary Product Accessibility Template (VPAT) is a document which
 evaluates how accessible a particular product is according to the Section
 508 Standards. It is a self-disclosing document produced by the vendor
 which details each aspect of the Section 508 requirements and how the
 product supports each criteria.*







 *Amber Akins*

 *Client  Sales Support*

 *Accenture - Alliance Services*

 *e-mail:  amber.l.ak...@accenture.com amber.l.ak...@accenture.com*

 *Phone: 678-657-2250 678-657-2250*

 *Fax: **678-657-0043 678-657-0043*



 --

 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise confidential information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the e-mail by you is prohibited. Where allowed
 by local law, electronic communications with Accenture and its affiliates,
 including e-mail and instant messaging (including content), may be scanned
 by our systems for the purposes of information security and assessment of
 internal compliance with Accenture policy.

 __

 www.accenture.com

[ANN] Apache Maven Archetype 2.3 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of Apache
Maven Archetype 2.3.

Archetype is a tool for setting up new Maven projects.

This is the last release intended to provide support for Maven 2.2.x.

Release notes: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095version=18127

Enjoy,

-The Apache Maven team

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

Re: Do I need to write a plugin for this?

[Benson Margulies]

I don't understand your question at all. In Maven, you can just use the
build-helper-maven-plugin to attach any file to the project, causing it to
upload. So, you can certainly use antrun to run the ant build, and the
helper to attach the result as an artifact.

On Sun, Mar 1, 2015 at 4:18 PM, Bruce Albrecht br...@maven.zuhause.org
wrote:

 I am working on a project that creates OSGI bundles with an extension of
 .cba and today uses ant to invoke a workbench to build the .cba file.  I
 want to upload the .cba file to my Nexus repository. My initial take on
 this is that if IBM didn't use its own extension for this, I would be
 able to just use the antrun plugin.

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

Can't push a snapshot for Apache Nifi to repository.apache.org

[Benson Margulies]

I'm a bit puzzled.

I can deploy a staged release for org.apache.nifi, but I can't push a
snapshot, I get permission denied.

Error:

 
https://repository.apache.org/content/repositories/snapshots/org/apache/nar-maven-plugin/0.0.2-test-incubating-SNAPSHOT/nar-maven-plugin-0.0.2-test-incubating-20150116.131426-1.jar,
ReasonPhrase: Forbidden.

I happen to be using the nexus-staging-plugin for this, and I have
credentials set up in settings.xml.

   plugin
 groupIdorg.sonatype.plugins/groupId
 artifactIdnexus-staging-maven-plugin/artifactId
 version1.6.5/version
 extensionstrue/extensions
 configuration
   serverIdrepository.apache.org/serverId
   nexusUrlhttps://repository.apache.org//nexusUrl
 /configuration
   /plugin


Any clues?

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

Re: Can't push a snapshot for Apache Nifi to repository.apache.org

[Benson Margulies]

Please ignore this, I see what I screwed up.

On Fri, Jan 16, 2015 at 8:16 AM, Benson Margulies bimargul...@gmail.com wrote:
 I'm a bit puzzled.

 I can deploy a staged release for org.apache.nifi, but I can't push a
 snapshot, I get permission denied.

 Error:

  
 https://repository.apache.org/content/repositories/snapshots/org/apache/nar-maven-plugin/0.0.2-test-incubating-SNAPSHOT/nar-maven-plugin-0.0.2-test-incubating-20150116.131426-1.jar,
 ReasonPhrase: Forbidden.

 I happen to be using the nexus-staging-plugin for this, and I have
 credentials set up in settings.xml.

plugin
  groupIdorg.sonatype.plugins/groupId
  artifactIdnexus-staging-maven-plugin/artifactId
  version1.6.5/version
  extensionstrue/extensions
  configuration
serverIdrepository.apache.org/serverId
nexusUrlhttps://repository.apache.org//nexusUrl
  /configuration
/plugin


 Any clues?

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

Re: Looking for Failsafe/Integration Test Example

[Benson Margulies]

Failsafe isn't what I'd use for that, but rather the invoker.


On Tue, Jan 6, 2015 at 4:49 PM, SDOCA SDOCA sd...@shaw.ca wrote:
 Hi,

 Can somebody provide a link to an sample project that uses the Failsafe 
 plugin to do integration tests that include deploying as per the lifecycle 
 phase integration-test (process and deploy the package if necessary into an 
 environment where integration tests can be run.)?

 I can only seem to find very basic examples that do not include a deploy.

 Also, is there a way

 -
 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: Separating Integration and Unit Tests

[Benson Margulies]

I think that what you actually want is two executions of surefire (or
one of surefire and one of failsafe) with different test name
patterns.

On Thu, Jan 1, 2015 at 2:40 PM, Ole Ersoy ole.er...@gmail.com wrote:
 Hi,

 I'm attempting to separate my integration and unit tests using profiles and
 the maven build helper plugin.  I have unit tests in the standard directory
 and integration tests in `src/integration-test/java`.  When I run the
 default profile, I expect integration tests to be skipped and unit tests to
 be executed.  When I run the `integration-test` profile with `mvn clean test
 -Pintegration-test` I expect the integration tests to be run and the unit
 tests to be skipped.  Right now Maven is just ignoring the profile test
 settings:
 `skip.integration.tests`
 `skip.unit.tests`
 and it just runs all the tests regardless of which profile is active.

 My POM looks like this:

 project xmlns=http://maven.apache.org/POM/4.0.0;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 modelVersion4.0.0/modelVersion

 groupIdcom.example.maven/groupId
 artifactIdseparating-integration-and-unit-test-execution/artifactId
 version1.0.0/version

 profiles
 profile
 idunit-test/id
 activation
 activeByDefaulttrue/activeByDefault
 /activation
 properties
 skip.integration.teststrue/skip.integration.tests
 skip.unit.testsfalse/skip.unit.tests
 /properties
 /profile
 profile
 idintegration-test/id
 properties
 skip.integration.testsfalse/skip.integration.tests
 skip.unit.teststrue/skip.unit.tests
 /properties
 /profile
 /profiles
 build
 plugins
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdbuild-helper-maven-plugin/artifactId
 version1.9.1/version
 executions
 !-- Add the integration-test source directory --
 execution
 idadd-integration-test-sources/id
 phasegenerate-test-sources/phase
 goals
 goaladd-test-source/goal
 /goals
 configuration
 sources
 sourcesrc/integration-test/java/source
 /sources
 /configuration
 /execution
 /executions
 /plugin
 /build
 /project

 Thoughts?

 TIA,
 - Ole


 -
 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: Separating Integration and Unit Tests

[Benson Margulies]

On Thu, Jan 1, 2015 at 5:29 PM, Ole Ersoy ole.er...@gmail.com wrote:
 Had one more question.  In the documentation I have read the integration
 test directory is usually added in the generate-test-sources phase.  So all
 tests are visible during the `test` phase, although they would be excluded
 by default if they end in `IT`.

Where is this documentation?


 It seems more Logical to add the integration test directory during the
 `pre-integration-test` phase, but I don't think that's what the Maven
 documentation does.  Are there any drawbacks to doing this?

 Thanks,

 - Ole



 -
 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