RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes

2012-10-16 Thread Wang, Simon 
Yes, I did.

It should be caused by that signed jars are changed.
But my question is "whether there is a tool to identify which signed jars are 
changed?"

Regards
Simon

Here is stack trace:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:
2.1:analyze (default-cli) on project CoreAppFramework: Execution default-cli of
goal org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invali
d signature file digest for Manifest main attributes -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o
rg.apache.maven.plugins:maven-dependency-plugin:2.1:analyze (default-cli) on pro
ject CoreAppFramework: Execution default-cli of goal org.apache.maven.plugins:ma
ven-dependency-plugin:2.1:analyze failed: Invalid signature file digest for Mani
fest main attributes
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:225)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
ild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
eStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
cher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
a:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
uncher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-c
li of goal org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed:
Invalid signature file digest for Manifest main attributes
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:209)
... 19 more
Caused by: java.lang.SecurityException: Invalid signature file digest for Manife
st main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVeri
fier.java:241)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier
.java:196)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:266)
at java.util.jar.JarVerifier.update(JarVerifier.java:220)
at java.util.jar.JarInputStream.read(JarInputStream.java:193)
at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:111)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:89)
at java.util.jar.JarInputStream.getNextEntry(JarInputStream.java:129)
at java.util.jar.JarInputStream.getNextJarEntry(JarInputStream.java:160)

at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acc
eptJar(ClassFileVisitorUtils.java:99)
at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acc
ept(ClassFileVisitorUtils.java:60)
at org.apache.maven.shared.dependency.analyzer.DefaultClassAnalyzer.anal
yze(DefaultClassAnalyzer.java:46)
at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyA
nalyzer.buildArtifactClassMap(DefaultProjectDependencyAnalyzer.java:153)
at org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyA
nalyzer.analyze(DefaultProjectDependencyAnalyzer.java:72)
at org.apache.maven.plugin.dependency.AbstractAnalyzeMojo.checkDependenc
ies(AbstractAnalyzeMojo.java:168)
at org.apache.maven.plugin.dependency.AbstractAnalyzeMojo.execute(Abstra
ctAnalyzeMojo.java:152)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:101)
... 20 more

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: 2012年10月17日 12:00
To: Maven Users List
Subject: Re: mvn dependency:analyze fail

RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes

2012-10-16 Thread Wang, Simon 
Yes, you're right, but there are lots of dependency jars.

Do you know whether there is a tool(maven plugin) to identify those signed 
changed jars?

Regards
Simon
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com] 
Sent: 2012年10月17日 10:41
To: users@maven.apache.org
Subject: RE: mvn dependency:analyze failed:Invalid signature file digest for 
Manifest main attributes


the manifest.mf contains a MD5-Digest which looks like
Manifest-Version: 1.0

Name: bibparse-1.04/META-INF/MANIFEST.MF
Digest-Algorithms: SHA MD5 
SHA-Digest: +ZeuKiF1Qrq/ym6omfGMSD5tel0=
MD5-Digest: uK1nT2MOzIU5HgaZzmZgHg==where the digest contained in MD-5 does not 
conform to the actual generated MD5 *for the jar *

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité


Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.


> From: yunfeng.w...@ebay.com
> To: users@maven.apache.org
> Subject: mvn dependency:analyze failed:Invalid signature file digest for 
> Manifest main attributes
> Date: Wed, 17 Oct 2012 01:38:56 +
> 
> Hi,
>I'm trying to analyze my dependencies, but encountered "Invalid signature 
> file digest for Manifest main attributes" issue.
> I know it should be caused by signed jar is changed.
>But you know there are lot of dependency jars there. Is there a tool to 
> identify which signed jar is changed?
> 
> Error log is here:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:
> 2.1:analyze (default-cli) on project XXX: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid 
> signature file digest for Manifest main attributes -> [Help 1]
> 
> Regards
> Simon

Re: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes

2012-10-16 Thread Wayne Fay 
>But you know there are lot of dependency jars there. Is there a tool to
> identify which signed jar is changed?

Did you try adding -X for debug ouput?

Wayne

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

RE: mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes

2012-10-16 Thread Martin Gainty 

the manifest.mf contains a MD5-Digest which looks like
Manifest-Version: 1.0

Name: bibparse-1.04/META-INF/MANIFEST.MF
Digest-Algorithms: SHA MD5 
SHA-Digest: +ZeuKiF1Qrq/ym6omfGMSD5tel0=
MD5-Digest: uK1nT2MOzIU5HgaZzmZgHg==where the digest contained in MD-5 does not 
conform to the actual generated MD5 *for the jar *

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité


Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.


> From: yunfeng.w...@ebay.com
> To: users@maven.apache.org
> Subject: mvn dependency:analyze failed:Invalid signature file digest for 
> Manifest main attributes
> Date: Wed, 17 Oct 2012 01:38:56 +
> 
> Hi,
>I'm trying to analyze my dependencies, but encountered "Invalid signature 
> file digest for Manifest main attributes" issue.
> I know it should be caused by signed jar is changed.
>But you know there are lot of dependency jars there. Is there a tool to 
> identify which signed jar is changed?
> 
> Error log is here:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:
> 2.1:analyze (default-cli) on project XXX: Execution default-cli of goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid 
> signature file digest for Manifest main attributes -> [Help 1]
> 
> Regards
> Simon

mvn dependency:analyze failed:Invalid signature file digest for Manifest main attributes

2012-10-16 Thread Wang, Simon 
Hi,
   I'm trying to analyze my dependencies, but encountered "Invalid signature 
file digest for Manifest main attributes" issue.
I know it should be caused by signed jar is changed.
   But you know there are lot of dependency jars there. Is there a tool to 
identify which signed jar is changed?

Error log is here:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:
2.1:analyze (default-cli) on project XXX: Execution default-cli of goal 
org.apache.maven.plugins:maven-dependency-plugin:2.1:analyze failed: Invalid 
signature file digest for Manifest main attributes -> [Help 1]

Regards
Simon

Re: Broken link for avalon

2012-10-16 Thread Benson Margulies 
On Tue, Oct 16, 2012 at 11:54 AM, Volkan Istek wrote:

> Hi Guys,
>
> ** **
>
> I am trying use FOP (Formatting Objects Processor) with maven. It uses
> avalon-framework-api-4.3.1.jar and it can’t download it. Because of
> following links are not working.  Directories are there and other filres in
> the directories are there too.
>

Please contact the FOP project.



> 
>
> ** **
>
>
> http://repo.maven.apache.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
> 
>
>
> http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
> 
>
> ** **
>
> Do you have any idea for it or fo you know who I should  connect in order
> to fix it?
>
> ** **
>
> Thanks,
>
> Volkan Istek
>
> ** **
>
> Best Regard
>
> ** **
>
> Volkan Istek • Senior Software Developer• +90 216 576 80 66
>
> ** **
>
> [image: Description: Description: Description: Description: Description:
> Sqills Logo] 
>
> Enschede
>
> +31 (0)88 7745570
>
> Hengelosestraat 52, 7514 AJ
>
> NL
>
> Haarlem
>
> +31 (0)88 7745570
>
> Leidsevaart 594, 2014 HT
>
> NL
>
> Istanbul
>
> +90 216 576 80 66  
>
>   Kayışdağı Cad. Sevinç Sok. No:5 Kat:5 34758 Küçükbakkalköy, Ataşehir /
> İstanbul
>
> TR
>
> Tunis
>
> +216 97 861 927  
>
> 64, Rue d'Iran, 2nd Floor, La Fayette, 1002
>
> TN
>
> ** **
>
> ** **
>

Re: Broken link for avalon

2012-10-16 Thread Anders Hammar 
Works for me.

/Anders

On Tue, Oct 16, 2012 at 5:54 PM, Volkan Istek wrote:

> Hi Guys,
>
> ** **
>
> I am trying use FOP (Formatting Objects Processor) with maven. It uses
> avalon-framework-api-4.3.1.jar and it can’t download it. Because of
> following links are not working.  Directories are there and other filres in
> the directories are there too.
>
> ** **
>
>
> http://repo.maven.apache.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
> 
>
>
> http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
> 
>
> ** **
>
> Do you have any idea for it or fo you know who I should  connect in order
> to fix it?
>
> ** **
>
> Thanks,
>
> Volkan Istek
>
> ** **
>
> Best Regard
>
> ** **
>
> Volkan Istek • Senior Software Developer• +90 216 576 80 66
>
> ** **
>
> [image: Description: Description: Description: Description: Description:
> Sqills Logo] 
>
> Enschede
>
> +31 (0)88 7745570
>
> Hengelosestraat 52, 7514 AJ
>
> NL
>
> Haarlem
>
> +31 (0)88 7745570
>
> Leidsevaart 594, 2014 HT
>
> NL
>
> Istanbul
>
> +90 216 576 80 66  
>
>   Kayışdağı Cad. Sevinç Sok. No:5 Kat:5 34758 Küçükbakkalköy, Ataşehir /
> İstanbul
>
> TR
>
> Tunis
>
> +216 97 861 927  
>
> 64, Rue d'Iran, 2nd Floor, La Fayette, 1002
>
> TN
>
> ** **
>
> ** **
>

Broken link for avalon

2012-10-16 Thread Volkan Istek 
Hi Guys,

I am trying use FOP (Formatting Objects Processor) with maven. It uses 
avalon-framework-api-4.3.1.jar and it can't download it. Because of following 
links are not working.  Directories are there and other filres in the 
directories are there too.

http://repo.maven.apache.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar
http://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar

Do you have any idea for it or fo you know who I should  connect in order to 
fix it?

Thanks,
Volkan Istek

Best Regard

Volkan Istek * Senior Software Developer* +90 216 576 80 66


[cid:image001.gif@01CDABCF.A48E46A0]

Enschede

+31 (0)88 7745570

Hengelosestraat 52, 7514 AJ

NL

Haarlem

+31 (0)88 7745570

Leidsevaart 594, 2014 HT

NL

Istanbul

+90 216 576 80 66

  Kayışdağı Cad. Sevinç Sok. No:5 Kat:5 34758 Küçükbakkalköy, Ataşehir / 
İstanbul

TR

Tunis

+216 97 861 927

64, Rue d'Iran, 2nd Floor, La Fayette, 1002

TN

Re: HOWTO: git-flow + maven-release-plugin + multi-module maven project w/parent pom as sibling to other modules?

2012-10-16 Thread Lyons, Roy 
Correct.  On the pom where it defines all of the s.  in your case,
you would specify "production/app/pom.xml" if that¹s where this exists.



Thanks,

Roy Lyons
Senior Configuration Engineer



On 10/16/12 9:14 AM, "Matthew Adams"  wrote:

>Stephen,
>
>It sounds like what you're referring to is what I've been calling the
>"root" pom in my example, as opposed to what I've been calling the
>"parent" pom.
>
>The root pom is sitting at the top of the maven project
>(production/app relative to the git repo root directory), and
>basically only contains the  section.  The parent pom is
>sitting in production/app/parent-pom, and it's the pom that all of
>other modules are inheriting from (via their  sections).
>
>So you're saying to invoke "mvn release:prepare release:perform" on my
>root pom, not my parent pom, right?
>
>-matthew
>
>On Tue, Oct 16, 2012 at 2:38 AM, Stephen Connolly
> wrote:
>> On 15 October 2012 22:24, Matthew Adams  wrote:
>>
>>> One of the questions in my original post was actually "which pom
>>> should you execute 'mvn release:prepare release:perform' on?".  I'm
>>> guessing, based on nothing else but intuition, that it's the parent
>>> pom, not the root pom, so, in my case,
>>
>>
>> It should be the pom that aggregates everything you want to release. IOW
>> the aggregation root of all projects that are to be released. That need
>>not
>> be the parent pom if aggregation does not follow inheritance
>>
>>
>>> I suppose that'd be
>>> production/app/parent-pom/pom.xml.  However, that SO question was just
>>> for poms that aren't at the repo root; my question is a touch more
>>> specific than that, what with a parent-pom as a sibling to its
>>> children, which is a common use case, IME.
>>>
>>> Thoughts?
>>>
>>> On Mon, Oct 15, 2012 at 4:03 PM, Lyons, Roy 
>>> wrote:
>>> >
>>> > The way I am reading this, you need to add it to the pom which you
>>>are
>>> > invoking maven on.  So whichever pom file you are running maven
>>>against
>>> > for the call to the release plugin (not talking the submodules here,
>>>but
>>> > the pom closest to the invocation of maven), add this in -- basically
>>> > pointing to the relative path (relative to your git repository root)
>>>to
>>> > the pom you are running maven against.
>>> >
>>> >
>>> > Thanks,
>>> >
>>> > Roy Lyons
>>> > Senior Configuration Engineer
>>> >
>>> >
>>> > On 10/15/12 3:31 PM, "Matthew Adams"  wrote:
>>> >
>>> >>Thanks, Roy.  The answer you pointed me to says "add the following to
>>> >>your build/plugins section", but it doesn't tell me **which** pom to
>>> >>add to...leaving me confused.  Can you clarify for the answerer
>>>(since
>>> >>I don't have enough repu points to comment on the answer & ask for
>>> >>clarification).
>>> >>
>>> >>On Mon, Oct 15, 2012 at 2:49 PM, Lyons, Roy 
>>> >>wrote:
>>> >>> I had remembered looking this up and thought I would share my
>>>finding
>>> >>>with
>>> >>> you:
>>> >>>
>>> >>>
>>> 
>>>http://stackoverflow.com/questions/5558785/maven-release-plugin-git-and-
>>>t
>>> >>>he
>>> >>> -poms-not-at-the-top
>>> >>>
>>> >>> Basically theres a
>>> >>> 
>>> >>> subdir/pom.xml
>>> >>> 
>>> >>> That you need to define as part of your plugin definition.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Roy Lyons
>>> >>> Senior Configuration Engineer
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 10/15/12 1:17 PM, "Matthew Adams" 
>>>wrote:
>>> >>>
>>> Hi all,
>>> 
>>> I'm trying to visualize how to perform a release properly, given
>>>that
>>> 
>>> * I'm using git with git-flow on a
>>> * multi-module maven project with a
>>> * parent pom module that is located in a sibling directory to the
>>> other modules which are
>>> * located in a directory other than the git repository's root
>>> directory.
>>> 
>>> The docs for using the maven-release-plugin seem a little sparse
>>>when
>>> used with multi-module maven projects like mine.  For example, my
>>>git
>>> repo's root directory (the one containing the .git directory) has a
>>> subdirectory called "production/app".  The multi-module root pom
>>>is at
>>> production/app/pom.xml, and looks like this:
>>> 
>>> http://maven.apache.org/POM/4.0.0";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd";>
>>>    4.0.0
>>>    org.example
>>>    app-root
>>>    pom
>>>    0.2.0.BUILD-SNAPSHOT
>>>    Application Multimodule Root POM
>>> 
>>>    
>>>    parent-pom
>>>    test-support
>>>    support
>>>    domain
>>>    dto
>>>    service
>>>    rest
>>>    web
>>>    
>>> 
>>> 
>>> Note that it basically only contains  en

Re: Independent module release strategies

2012-10-16 Thread Ron Wheeler 

For what its worth:

1) We do not use the  Maven release plug-in and follow what Barrie 
described below - SCM tags, etc.

2) We do not use profiles.
3) By getting the libraries out of our code, we make the wars very small 
which might help more in this case where a lot of people are downloading 
bug fixes over slow lines. We generally do not change the provided 
libraries within a minor update so they are very stable and there is no 
need to download 20Mb to get 20Kb of code that changed. Things like CXF 
are huge and are used everywhere in our application so it makes a big 
difference in the builds if you have to include it in every war file.


Ron

On 16/10/2012 5:56 AM, Barrie Treloar wrote:

On Tue, Oct 16, 2012 at 7:36 PM, Stephen Connolly
 wrote:
[del]

See what happens when your thread reaches critical mass!
Kittens die.

p.s. Thanks for an in-depth email that will be very useful for the archives.

The "Maven Way" for a release process isn't really well documented
anywhere yet, and I fear a few more kittens will die over that debate
as well.
Most people bump into release:process and blindly follow that path and
there a limitations with that option.
SCM commit/tags and mvn deploy are just as good.
Its really important to understand what is being automated before automating it.

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





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: HOWTO: git-flow + maven-release-plugin + multi-module maven project w/parent pom as sibling to other modules?

2012-10-16 Thread Matthew Adams 
Stephen,

It sounds like what you're referring to is what I've been calling the
"root" pom in my example, as opposed to what I've been calling the
"parent" pom.

The root pom is sitting at the top of the maven project
(production/app relative to the git repo root directory), and
basically only contains the  section.  The parent pom is
sitting in production/app/parent-pom, and it's the pom that all of
other modules are inheriting from (via their  sections).

So you're saying to invoke "mvn release:prepare release:perform" on my
root pom, not my parent pom, right?

-matthew

On Tue, Oct 16, 2012 at 2:38 AM, Stephen Connolly
 wrote:
> On 15 October 2012 22:24, Matthew Adams  wrote:
>
>> One of the questions in my original post was actually "which pom
>> should you execute 'mvn release:prepare release:perform' on?".  I'm
>> guessing, based on nothing else but intuition, that it's the parent
>> pom, not the root pom, so, in my case,
>
>
> It should be the pom that aggregates everything you want to release. IOW
> the aggregation root of all projects that are to be released. That need not
> be the parent pom if aggregation does not follow inheritance
>
>
>> I suppose that'd be
>> production/app/parent-pom/pom.xml.  However, that SO question was just
>> for poms that aren't at the repo root; my question is a touch more
>> specific than that, what with a parent-pom as a sibling to its
>> children, which is a common use case, IME.
>>
>> Thoughts?
>>
>> On Mon, Oct 15, 2012 at 4:03 PM, Lyons, Roy 
>> wrote:
>> >
>> > The way I am reading this, you need to add it to the pom which you are
>> > invoking maven on.  So whichever pom file you are running maven against
>> > for the call to the release plugin (not talking the submodules here, but
>> > the pom closest to the invocation of maven), add this in -- basically
>> > pointing to the relative path (relative to your git repository root) to
>> > the pom you are running maven against.
>> >
>> >
>> > Thanks,
>> >
>> > Roy Lyons
>> > Senior Configuration Engineer
>> >
>> >
>> > On 10/15/12 3:31 PM, "Matthew Adams"  wrote:
>> >
>> >>Thanks, Roy.  The answer you pointed me to says "add the following to
>> >>your build/plugins section", but it doesn't tell me **which** pom to
>> >>add to...leaving me confused.  Can you clarify for the answerer (since
>> >>I don't have enough repu points to comment on the answer & ask for
>> >>clarification).
>> >>
>> >>On Mon, Oct 15, 2012 at 2:49 PM, Lyons, Roy 
>> >>wrote:
>> >>> I had remembered looking this up and thought I would share my finding
>> >>>with
>> >>> you:
>> >>>
>> >>>
>> http://stackoverflow.com/questions/5558785/maven-release-plugin-git-and-t
>> >>>he
>> >>> -poms-not-at-the-top
>> >>>
>> >>> Basically theres a
>> >>> 
>> >>> subdir/pom.xml
>> >>> 
>> >>> That you need to define as part of your plugin definition.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Roy Lyons
>> >>> Senior Configuration Engineer
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 10/15/12 1:17 PM, "Matthew Adams"  wrote:
>> >>>
>> Hi all,
>> 
>> I'm trying to visualize how to perform a release properly, given that
>> 
>> * I'm using git with git-flow on a
>> * multi-module maven project with a
>> * parent pom module that is located in a sibling directory to the
>> other modules which are
>> * located in a directory other than the git repository's root
>> directory.
>> 
>> The docs for using the maven-release-plugin seem a little sparse when
>> used with multi-module maven projects like mine.  For example, my git
>> repo's root directory (the one containing the .git directory) has a
>> subdirectory called "production/app".  The multi-module root pom is at
>> production/app/pom.xml, and looks like this:
>> 
>> http://maven.apache.org/POM/4.0.0";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd";>
>>    4.0.0
>>    org.example
>>    app-root
>>    pom
>>    0.2.0.BUILD-SNAPSHOT
>>    Application Multimodule Root POM
>> 
>>    
>>    parent-pom
>>    test-support
>>    support
>>    domain
>>    dto
>>    service
>>    rest
>>    web
>>    
>> 
>> 
>> Note that it basically only contains  entries, one of which is
>> the parent-pom module, which is in the directory
>> production/app/parent-pom (the parent pom is then
>> production/app/parent-pom/pom.xml) and all of the other modules in the
>> project, then, declare the relative path to the parent pom to be
>> "../parent-pom/pom.xml".  Now, I'm trying
>> to use the maven-release-plugin with this project along with git-flow.
>>

Re: how put resource files on update site?

2012-10-16 Thread Jeff MAURY 
As recommanded on the Tycho users list, you should post his question on the
P2 mailing list

Jeff

On Tue, Oct 16, 2012 at 8:49 AM, Anders Hammar  wrote:

> For tycho and update site questions I think the tycho users list is a
> better place to ask.
>
> /Anders
>
> On Tue, Oct 16, 2012 at 8:47 AM,   wrote:
> > Hello,
> > we are building our product with tycho, and during build we generate
> some txt files. Than we would like to put the binary jars on the update
> site. To provide our product to someone else. But we need to provide also
> the generated txt files.
> > Please what is the proper steps to achieve that? Thank you
> > D.
> >
> > -
> > 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
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

Maven Repository on my home Tomcat

2012-10-16 Thread AlexSerov 
I have created a simple test artifact and maven finds it locally. Now I want
to publish it on my home site. I tried to create a repository manually but
did not find sufficient guide on that in particular on .pom file. Please
advice a good document.



--
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-Repository-on-my-home-Tomcat-tp5726788.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: How to optimize maven dependencies to get better performance?

2012-10-16 Thread Brian Fox 
The problem below is because your configuration is inside an execution,
which when run from the command line like mvm enforcer:enforce won't be
activated. Either bind this plugin to a phase as part of your build, or
move the configuration element outside the executions block.

On Thu, Oct 11, 2012 at 4:27 AM, Wang, Simon  wrote:

> Hi, Barrie,
>Ask a stupid question about enforcer plugin.
> I added enforcer plugin into project pom like this:
> 
>
> org.apache.maven.plugins
>
> maven-enforcer-plugin
> 1.1.1
> 
>   
> enforce
> 
> 
>
> 
> 
> 
> 
>   enforce
> 
>   
> 
> 
>
> But it always complain missing parameter: rules.
> Below is debug log.
>
> Any mistakes in above code?
>
> ~~~
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:1.1.1:en
> force from plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforce
> r-plugin:1.1.1, parent: sun.misc.Launcher$AppClassLoader@233e233e]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:1.1.1:e
> nforce' with basic configurator -->
> [DEBUG]   (s) fail = true
> [DEBUG]   (s) failFast = false
> [DEBUG]   (f) ignoreCache = false
> [DEBUG]   (s) project = MavenProject:
> com.ebay.raptor.buyerexp.framework:CoreApp
> Framework:4.1.1-W41-SNAPSHOT @
> C:\gitrepo\search_raptor\CoreAppFramework\pom.xml
>
> [DEBUG]   (s) session = org.apache.maven.execution.MavenSession@3d153d15
> [DEBUG]   (s) skip = false
> [DEBUG] -- end configuration --
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 3.050s
> [INFO] Finished at: Thu Oct 11 15:49:28 CST 2012
> [INFO] Final Memory: 17M/45M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.
> 1.1:enforce (default-cli) on project CoreAppFramework: The parameters
> 'rules' fo
> r goal org.apache.maven.plugins:maven-enforcer-plugin:1.1.1:enforce are
> missing
> or invalid -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal o
> rg.apache.maven.plugins:maven-enforcer-plugin:1.1.1:enforce (default-cli)
> on pro
> ject CoreAppFramework: The parameters 'rules' for goal
> org.apache.maven.plugins:
> maven-enforcer-plugin:1.1.1:enforce are missing or invalid
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
> .java:221)
>
>
>
> Regards
> Simon
> -Original Message-
> From: Wang, Simon [mailto:yunfeng.w...@ebay.com]
> Sent: 2012年10月11日 13:41
> To: Maven Users List
> Subject: RE: How to optimize maven dependencies to get better performance?
>
> Hi, Barrie,
>That's really helpful!
>
>Even I have local cache, it also takes about 2 mins to resolve
> dependencies.
>Also it seems maven still will talk with remote maven server even I
> have local cache.
>Yes, maybe it's caused by unspecified version numbers for dependencies.
>
>I'll try maven-enforcer-plugin.
>
>We're using nexus now, haven't tried MRM, I'll host it and compare it
> to nexus.
>
>And I saw aether(major in dependency resolving) will take longer time
> to resolve conflict dependencies.
>Is it also a point that need to be improved?
>Do you know is there any maven plugin to identify conflict dependencies?
>
> Regards
> Simon
>
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: 2012年10月11日 11:48
> To: Maven Users List
> Subject: Re: How to optimize maven dependencies to get better performance?
>
> On Thu, Oct 11, 2012 at 1:46 PM, Wang, Simon 
> wrote:
> > Hi,
> >We're in trouble of terrible performance on resolve maven
> dependencies.
> > I did some search about it. Basically below ways should be helpful:
> >
> > 1. optimize nexus server to improve response time.
> > 2. optimize maven dependencies.
> >   1) avoid duplicated dependencies
> >   2) avoid dependency conflict cases
> >   3)
> >
> > Any others suggestions?
>
> What specifically is your problem?
>
> I can only guess at what you mean.
> I'm assuming that when you run "mvn install" that maven is reaching out to
> check for new dependencies which can be time consuming, especially with an
> empty ~/

Re: modules, dependencies, whatelse?

2012-10-16 Thread Barrie Treloar 
On Tue, Oct 16, 2012 at 3:19 AM, Wayne Fay  wrote:
>> The problem with this is that I also need to build standalone jars of myLib2
>> and myLib3, and they need myLib1 themselves. Their code refers to classes in
>> myLib1 and myLib3 code defers also to classes in myLib2. myLib2 and myLib3 do
>> not even compile if they don't have myLib1/myLib2 listed as dependency in
>> their pom file. But if I list them as dependecies, those are expected to be
>> found in a repository or manually installed. Otherwise if I list them as
>> modules, I'm forced to packaging="pom", so no standalone jars...
>
> Just set things up as you've been told and build your projects from
> the top/parent each time, not from the children. Then the reactor
> finds the files it needs when it builds each library. Use packaging of
> "jar" in each lib, and use packaging "pom" for the top parent.

You dont need Nexus yet for your 3 module setup.

I assume the number of classes you have are tiny* (by some definition of tiny).
If you whole build run from the top level, as Wayne suggests, take
longer than 5 minutes then we can help you to speed it up.

Since you are new its easier to start with the small steps.

When you are feeling braver you can run with options like "--also-make".
But in your case I doubt that this will save you any cpu cycles.

Most people work in an IDE rather than on the command line.
What this means is, that most of the time you just work in your IDE
that has maven support (Eclipse or IDE do) and you let the IDE rebuild
your projects for you.
When you are ready to commit back into your SCM or you would like to
run the complete set of test (unit or integration) you break out to a
shell and run "mvn clean install" and check nothing is broken.
The incremental build cycle of an IDE will save you a lot more time
than trying to improve the Maven build process.

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

Re: Independent module release strategies

2012-10-16 Thread Barrie Treloar 
On Tue, Oct 16, 2012 at 7:36 PM, Stephen Connolly
 wrote:
[del]

See what happens when your thread reaches critical mass!
Kittens die.

p.s. Thanks for an in-depth email that will be very useful for the archives.

The "Maven Way" for a release process isn't really well documented
anywhere yet, and I fear a few more kittens will die over that debate
as well.
Most people bump into release:process and blindly follow that path and
there a limitations with that option.
SCM commit/tags and mvn deploy are just as good.
Its really important to understand what is being automated before automating it.

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

Re: modules, dependencies, whatelse?

2012-10-16 Thread John Patrick 
Step By Step will get you though this, once you understand Maven more
it will become a lot clearer. Nexus is a good idea and i should
probably do that myself but it's probably step 2 after getting this
working.

1) Create pom for myLib1, packaging type jar
2) myPom/myLib1$ mvn clean install
3) Create pom for myLib2 and add dependency for myLib1, packaging type jar
4) myPom/myLib2$ mvn clean install
5) Create pom for myLib3 and add dependency for myLib1, packaging type jar
6) myPom/myLib3$ mvn clean install
7) Create pom for myPom in parent directory of myLib1, myLib2 and
myLib3, packaging type pom
8) Add 
myLib1myLib2myLib3
into the myPom pom
9) myPom$ mvn clean install
10) Based upon the groupId you have used, delete it manually from your
own maven repository e.g. ~/.m2/repository/x/y/z
11) Manually delete myLib1/target myLib2/target myLib3/target
12) myPom$ mvn clean install

Steps 10 and 11 remove your locally built version and followed by step
12 proves that all the dependencies work correctly and dependencies
your in control of all build in the right order and installed into
your local repository.

After that look into SNAPSHOTS and Nexus, once your project is building.

Hope this helps,
John

On 15 October 2012 20:04, Ron Wheeler  wrote:
> On 15/10/2012 12:36 PM, Lucio Crusca wrote:
>>
>> In data lunedì 15 ottobre 2012 16:16:44, Ron Wheeler ha scritto:
>>
>>> Set up a Maven repo like Nexus. This is worth the small effort for the
>>> improvement in your life with Maven.
>>
>> I feared this reply and badly hoped not receiving it...
>>
>>> Even if you are a 1 man shop, it is worthwhile.
>>
>> This is reassuring (I actually am a 1 man shop).
>>
>>> Set it up on your workstation if you have to or put it on a small server
>>> in the cloud.
>>
>> I'm often on the move and I often work with slow internet connections, I
>> suppose my notebook is the best choice. Have you got any pointers to
>> howtos
>> for this?
>
> If you are using Nexus, I would just follow the installation instructions.
>
> Read the Nexus instructions carefully.
> The setup is a bit out of the ordinary so be careful about making
> assumptions about how "normal" webapps work.
> If you run into trouble, the Nexus forum is very active and a lot of the
> really bright lights of Maven are also involved in Nexus support so you
> should get very consistent advice between the 2 forums.
> Please post questions in the right forum.
> Maven supports at least 3 different repositories and there is sensitivity on
> the part of some people about the Maven forum leaning towards one repository
> package or another.
>
> I am not involved in either project or any repo project so I tend to be a
> bit more outspoken in my praise of Nexus but I am not an expert in
> repositories and have no experience with the other repos. From the traffic
> here, I gather that the other solutions are also very good.
>
> The one thing that having a repo will do for you is to make you much more
> aware of proper release practices and to a certain extent force you into
> using SNAPSHOTs correctly.
> We ran for 2 years without a repo and I feel that we lost a lot of time
> because of that. It took us a lot longer to understand Maven's best
> practices and the "Maven way" without the repo.
>
> You should also take a quick look at the Maven project team
> http://maven.apache.org/plugins/maven-project-info-reports-plugin/team-list.html
> so that you recognize the people who are giving you advice.
>
> Key thing to keep in mind. "Unless you are building something really, really
> out of the ordinary, bordering on bizarre, thousands of people have already
> built something similar to your project and there is a simple Maven Best
> Practice already available."
>
> Ron
>
>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: Independent module release strategies

2012-10-16 Thread Stephen Connolly 
On 16 October 2012 07:45, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:

> As described in my other response. Simply keeping the versions in sync is
> not an option for us due to the donwtime this would mean for our clients
> and the load this would generate on the central servers.
>
> Well currently the approach to release a new version was to have all
> modules defined in the master pom modules-section as well as a
> dependencyManagement-section that defines the versions of all the modules.
>
> Now if a new build was to be made that updates only some of the modules,
> the other modules (the ones that should stay the same) were commented out
> of the master poms modules-section and then the releaseplugin was used to
> release the desired artifacts. After the release was finished the versions
> hat do be manually updated.
>
> This process really sucked and caused a lot of problems.
>
> Now my approach was not to use the release plugin at all and to define all
> of the versions used throughout the entire project in the master pom using
> properties. So all I had to do was to increase the versions in the release
> profile to the versions I want and commit that. Now in jenkins I was able
> to define some jobs to run "mvn deploy" for individual projects with turned
> on "release" profile.
>
>
well first off, in my experience, the use of profiles to modify the
dependencies is bad karma. many kittens will die if you follow that use of
profiles. no matter how "clean" you think it is, with the current versions
of Maven and their current behaviour, attempts to follow this path will
result in many dead kittens underfoot.


> To me this seems a lot cleaner than all other approaches, but as I don't
> want to kill too many kittens (As stephen on the dev-list called it). So
> I'm open for other suggestions or explanationy WHY this is bad.
>
> Stephen claimed that if I re-define my properties in child modules, I
> would have really big trouble, but we are developing the entire project and
> this is a thing we could fefinitely rule out because it should be really
> easy to enforce such a constraint ("Versions are defines solely in the
> master pom"). And as I mentioned, to me it looks more like a highly
> restricted feature than a bug in maven that I was able to use a variable in
> the version.
>
>
Not quite, I fear it is loosing something in translation for you.

In an ideal world, before deploying the pom into the local cache (i.e.
install:install) or remote repository (i.e. deploy:deploy) Maven would
compute a resolved effective pom. Such a pom would strip out a lot of the
stuff that is in a pom at present, e.g. it would probably only consist of

/project/groupId
/project/artifactId
/project/version
/project/packaging
/project/dependencies/*
and maybe
/project/build/extensions/*
(but it gets tricky deciding exactly how much to prune out)

Such a pom would be capturing the dependency tree of the built artifact
after inheritance from the parent, and any active profiles, etc had been
applied. [Let's ignore the problem of “magic” profiles that alter the
dependencies when building on JDK1.5 vs JDK1.6 vs JDK1.7 vs JDK1.8]

*IF* we did something like that *THEN* it could be valid to try what you
want to do (Note: I say ‘could be’ not ‘would be’)

This is because anyone depending on the artifact would have a consistent
classpath.

Now for pom projects we would have to deploy the raw
pom to the repository so that inheritance would continue to work
[thankfully you can only inherit from projects with packaging=pom]. Because
the poms with packaging <> pom would be deploying flattened poms (where
they no-longer inherit from their parent) the fact that the parents are
deployed as raw unflattened poms should/might not be an issue.

That is the ideal world... we are not there... and the picture I paint
above has some holes that need ironing out before we can get there (one
hole for example is GPG signing of poms)

Here is the real world.

I am going to show an issue that you may not have yourself, but which
illustrates the kind/type of problems your approach can result in.

[ Benson I shall now pick on you ;-) ]

Consider the following pom

org.apache.cxf
cxf-parent
2.7.0

More specifically I would like to draw your attention to the profiles
section



jdk17

1.7


${cxf.jaxb22.version}
${cxf.jaxb22.impl.version}
${cxf.jaxb22.impl.version}
1.6


What, you might ask is so wrong with that?

Well what is wrong is that profiles are evaluated at build time.

So at present, if I depend on CXF for building my web application, and I
happen to build *my web application* which only depends on CXF on JDK 1.6
then the JDK 1.7 profile will not be activated because *when maven
evaluates the pom in the repository* it is doing the evaluation with a JDK
1.6 so the profile do

Re: Is it a bug? (install plugin deploys poms with variables in artifact.version and parent.version)

2012-10-16 Thread Baptiste MATHUS 
Moving onto user-list.

Thanks

2012/10/15 christofer.d...@c-ware.de 

> Just did a little digging ... so assuming I have only two projects ... one
> master and one module.
> If I define two properties in my master pom: "my.cool.master.version" and
> "my.cool.alternate.master.version"  and set both to the same value of
> "1.2-SNAPSHOT".
>
> In szenario 1: I ´hard code the version of the master to "1.2-SNAPSHOT"
> but use the property to reference the parent from the moule ... when
> running a build, maven tries to download
> "de/mycompany/test/${my.cool.master.version}/mycoolmaster-${my.cool.master.version}.pom"
> --> Failure
>
> In szenario 2: I use the same variable for defining the masters version.
> This time the maven build runs fine and the parent version is correctly
> resolved.
>
> In szenario 3: I use the first property to define the version of the
> master and the second one for referncing the parent from the module ...
> when running a build, maven tries to download
> "de/mycompany/test/${my.cool.alternate.master.version}/mycoolmaster-${my.cool.alternate.master.version}.pom"
> --> Failure
>
> So to me it looks as if there was some sort of intention behind
> everything. To mee it looks like one teeniewienie loophole allowing
> properies in versions while closing the usage range so much that possible
> harm is reduced to it's absolute minimum, while allowing that one usecase I
> was intending to use it for. After all ... this is a problem users are
> begging for maven to provide a solution since maven 2.0 (When looking at
> the forums).
>
> Chris
>
>
>
>
> 
> Von: Stephen Connolly [stephen.alan.conno...@gmail.com]
> Gesendet: Montag, 15. Oktober 2012 17:35
> An: Maven Developers List
> Betreff: Re: Is it a bug? (install plugin deploys poms with variables in
> artifact.version and parent.version)
>
> Those are edge cases where things unintentionally work, probably falling
> out of the way the model is built in memory.
>
> e.g.
>
> /project/version has an effective default value of
> ${project.parent.version}
> /project/groupId has an effective default value of
> ${project.parent.groupId}
>
> I say "effective" as the actual handling is IIRC a straight copy.
>
> Also if you are using System properties, there may be some unintended
> expansion of those in /project/parent
>
> BUT I REPEAT... STOP!
>
> Don't do it.
>
> Many kittens will be killed if you persist in trying to square this circle
>
> On 15 October 2012 16:18, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
> > I know that property substitution in those places seems to be
> unavailable.
> >
> > But there seems to be one case where it's seems to be explicitly allowed:
> > If the parent artifacts version is defined by the same variable used to
> > reference the parent pom, maven doesn't complain about anything (So I
> guess
> > this case is explicitly allowed). The artifacts are built, named and
> > deployed at the absolutely correct place. If I define the version of the
> > parent without a property (or a property with a different name), maven
> > doesn't resolve the version and I get all sorts of errors, even if I set
> it
> > to the same value. So I guess there must be some sort of support for it?
> >
> > Just have a look at the tiny project I attached to the issue. It builds
> > just fine, except for the fact that the poms deployed in the local maven
> > repo.
> >
> > Chris
> >
> > 
> > Von: Stephen Connolly [stephen.alan.conno...@gmail.com]
> > Gesendet: Montag, 15. Oktober 2012 16:32
> > An: Maven Developers List
> > Betreff: Re: Is it a bug? (install plugin deploys poms with variables in
> > artifact.version and parent.version)
> >
> > On 15 October 2012 15:13, christofer.d...@c-ware.de <
> > christofer.d...@c-ware.de> wrote:
> >
> > > Hi,
> > >
> > > I just opened an issue regarding the install plugin (I think that's the
> > > module responsible).
> > > http://jira.codehaus.org/browse/MNG-5358
> > >
> > > The general problem is that I am using variables for defining the
> > versions
> > > of artifacts, dependencies and parent projects.
> >
> >
> > STOP!
> >
> > Property substitution is not supported at the following XPath locations
> >
> > /project/parent/groupId
> > /project/parent/artifactId
> > /project/parent/version
> > /project/groupId
> > /project/artifactId
> > /project/version
> > /project/packaging
> >
> > If your issue is that Maven is failing to report
> > groupIds/artifactIds/versions at these XPath locations containing ${...}
> > characters as being invalid, then you have a valid bug. Otherwise you are
> > doing something wrong.
> >
> > Note we are investigating at some point in the future allowing
> > /project/parent/version to be optional where the parent is available on
> > disk at the specified /project/parent/relativePath but that is not a
> > feature in Maven 3.0.x
> >
> > -Stephen
> >
> >
> >
> > > The install plugin i

Re: HOWTO: git-flow + maven-release-plugin + multi-module maven project w/parent pom as sibling to other modules?

2012-10-16 Thread Stephen Connolly 
On 15 October 2012 22:24, Matthew Adams  wrote:

> One of the questions in my original post was actually "which pom
> should you execute 'mvn release:prepare release:perform' on?".  I'm
> guessing, based on nothing else but intuition, that it's the parent
> pom, not the root pom, so, in my case,


It should be the pom that aggregates everything you want to release. IOW
the aggregation root of all projects that are to be released. That need not
be the parent pom if aggregation does not follow inheritance


> I suppose that'd be
> production/app/parent-pom/pom.xml.  However, that SO question was just
> for poms that aren't at the repo root; my question is a touch more
> specific than that, what with a parent-pom as a sibling to its
> children, which is a common use case, IME.
>
> Thoughts?
>
> On Mon, Oct 15, 2012 at 4:03 PM, Lyons, Roy 
> wrote:
> >
> > The way I am reading this, you need to add it to the pom which you are
> > invoking maven on.  So whichever pom file you are running maven against
> > for the call to the release plugin (not talking the submodules here, but
> > the pom closest to the invocation of maven), add this in -- basically
> > pointing to the relative path (relative to your git repository root) to
> > the pom you are running maven against.
> >
> >
> > Thanks,
> >
> > Roy Lyons
> > Senior Configuration Engineer
> >
> >
> > On 10/15/12 3:31 PM, "Matthew Adams"  wrote:
> >
> >>Thanks, Roy.  The answer you pointed me to says "add the following to
> >>your build/plugins section", but it doesn't tell me **which** pom to
> >>add to...leaving me confused.  Can you clarify for the answerer (since
> >>I don't have enough repu points to comment on the answer & ask for
> >>clarification).
> >>
> >>On Mon, Oct 15, 2012 at 2:49 PM, Lyons, Roy 
> >>wrote:
> >>> I had remembered looking this up and thought I would share my finding
> >>>with
> >>> you:
> >>>
> >>>
> http://stackoverflow.com/questions/5558785/maven-release-plugin-git-and-t
> >>>he
> >>> -poms-not-at-the-top
> >>>
> >>> Basically theres a
> >>> 
> >>> subdir/pom.xml
> >>> 
> >>> That you need to define as part of your plugin definition.
> >>>
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Roy Lyons
> >>> Senior Configuration Engineer
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 10/15/12 1:17 PM, "Matthew Adams"  wrote:
> >>>
> Hi all,
> 
> I'm trying to visualize how to perform a release properly, given that
> 
> * I'm using git with git-flow on a
> * multi-module maven project with a
> * parent pom module that is located in a sibling directory to the
> other modules which are
> * located in a directory other than the git repository's root
> directory.
> 
> The docs for using the maven-release-plugin seem a little sparse when
> used with multi-module maven projects like mine.  For example, my git
> repo's root directory (the one containing the .git directory) has a
> subdirectory called "production/app".  The multi-module root pom is at
> production/app/pom.xml, and looks like this:
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
>    4.0.0
>    org.example
>    app-root
>    pom
>    0.2.0.BUILD-SNAPSHOT
>    Application Multimodule Root POM
> 
>    
>    parent-pom
>    test-support
>    support
>    domain
>    dto
>    service
>    rest
>    web
>    
> 
> 
> Note that it basically only contains  entries, one of which is
> the parent-pom module, which is in the directory
> production/app/parent-pom (the parent pom is then
> production/app/parent-pom/pom.xml) and all of the other modules in the
> project, then, declare the relative path to the parent pom to be
> "../parent-pom/pom.xml".  Now, I'm trying
> to use the maven-release-plugin with this project along with git-flow.
>  I'm planning on using the following settings, which I've seen in
> several posts on using it with git-flow:
> 
>    
> 
> org.apache.maven.plugins
> 
> maven-release-plugin
>    2.3.2
>    
> 
> true
> 
> true
>    false
> 
> v@{project.version}
>    
>    
> 
> * Into which pom do I put this plugin configuration:  the root pom
> (production/app/pom.xml) or the parent pom
> (production/app/parent-pom/pom.xml)?
> * Into which root or parent's section should this  section be
> placed:   or ?
> 
> Here