[jira] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://jira.codehaus.org/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341751#comment-341751
]
Henrik Brautaset Aronsen commented on MNG-5522:
---
I'm seeing this issue as well.
> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://jira.codehaus.org/browse/MNG-5522
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there:
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
> 1.5.300-SNAPSHOT
> imus
> ...
>
> 2.5.6
> 3.2.2.RELEASE
> 2.1.1
> 1.7.0
> windows-1251
> none
> 1.7
> 1.7
> ${basedir}
> QWERTY
>
> {code}
> First child module:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.1
>
>
> validate
>
> run
>
>
>
>
> [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
>
> [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
>
> [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
>
> [project.parent.spring3.version]:
> ${project.parent.spring3.version}
>
> [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
>
> [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
>
> [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
>
> [project.parent.name]: ${project.parent.name}
>
> [project.parent.properties]: ${project.parent.properties}
>
>
>
>
>
>
>
> {code}
> *In out I see what project.parent.name resolved and even
> project.parent.properties, but not any property in collection (f.e.
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath)
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
> [echo] [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
> [echo] [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
> [echo] [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
> [echo] [project.parent.spring3.version]:
> ${project.parent.spring3.version}
> [echo] [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
> [echo] [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
> [echo] [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
> [echo] [project.parent.name]: imus
> [echo] [project.parent.properties]: {rootProjectPath1=QWERTY,
> spring3.version=3.2.2.RELEASE, mule.version=2.1.1, aspectj.version=1.7.0,
> maven.compiler.target=1.7, source.encoding=windows-1251,
> maven.test.include=none, maven.compiler.source=1.7, spring.version=2.5.6,
> rootProjectPath=/home
[jira] (MNG-5522) properties project.parent.xxx not supported under Linux
[
https://jira.codehaus.org/browse/MNG-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341751#comment-341751
]
Henrik Brautaset Aronsen edited comment on MNG-5522 at 2/20/14 7:26 AM:
I'm seeing this issue as well. Annoying.
was (Author: henrik242):
I'm seeing this issue as well.
> properties project.parent.xxx not supported under Linux
> ---
>
> Key: MNG-5522
> URL: https://jira.codehaus.org/browse/MNG-5522
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build, POM
>Affects Versions: 3.0.5
> Environment: Few Linuxes tested, work under Windows
>Reporter: Pavel
> Attachments: maven-MNG-5522.zip
>
>
> Initially it was there:
> https://jira.codehaus.org/browse/MRM-1772#comment-333654 . But It is maven
> problem itself.
> It is reproducible on two our Linux machines (Fedora and Gentoo), so it may
> be Linux relative. On all our colleagues on windows it does not reproduced.
> Some details.
> Parent pom among others have:
> {code}
> 1.5.300-SNAPSHOT
> imus
> ...
>
> 2.5.6
> 3.2.2.RELEASE
> 2.1.1
> 1.7.0
> windows-1251
> none
> 1.7
> 1.7
> ${basedir}
> QWERTY
>
> {code}
> First child module:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.1
>
>
> validate
>
> run
>
>
>
>
> [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
>
> [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
>
> [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
>
> [project.parent.spring3.version]:
> ${project.parent.spring3.version}
>
> [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
>
> [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
>
> [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
>
> [project.parent.name]: ${project.parent.name}
>
> [project.parent.properties]: ${project.parent.properties}
>
>
>
>
>
>
>
> {code}
> *In out I see what project.parent.name resolved and even
> project.parent.properties, but not any property in collection (f.e.
> project.parent.rootProjectPath or project.parent.properties.rootProjectPath)
> as it should [by documentation|http://maven.apache.org/pom.html#Properties]*:
> {code}
> [INFO] --- maven-antrun-plugin:1.1:run (default) @ antinform-lib-parent ---
> [INFO] Executing tasks
> [echo] [project.parent.rootProjectPath]:
> ${project.parent.rootProjectPath}
> [echo] [project.parent.getRootProjectPath()]:
> ${project.parent.getRootProjectPath()}
> [echo] [project.parent.rootProjectPath1]:
> ${project.parent.rootProjectPath1}
> [echo] [project.parent.spring3.version]:
> ${project.parent.spring3.version}
> [echo] [project.parent.properties.spring3.version]:
> ${project.parent.properties.spring3.version}
> [echo] [project.parent.properties.rootProjectPath]:
> ${project.parent.properties.rootProjectPath}
> [echo] [project.parent.properties.rootProjectPath1]:
> ${project.parent.properties.rootProjectPath1}
> [echo] [project.parent.name]: imus
> [echo] [project.parent.properties]: {rootProjectPath1=QWERTY,
> spring3.version=3.2.2.RELEASE, mule.version=2.1.1, aspectj.version=1.7.0,
> maven.compiler.target=1.7, source.encodi
[jira] Created: (MNG-4032) Test jar dependency not available for for main classes in multi module builds
Test jar dependency not available for for main classes in multi module builds
-
Key: MNG-4032
URL: http://jira.codehaus.org/browse/MNG-4032
Project: Maven 2
Issue Type: Bug
Components: Bootstrap & Build, Class Loading, Dependencies,
Inheritance and Interpolation
Affects Versions: 2.1.0-M1, 2.0.9
Environment: MacOSX, Linux
Reporter: Henrik Brautaset Aronsen
Attachments: tests-dependency.zip
I have a module layout like this:
{noformat}
root -+- first
+- second
{noformat}
I have the test-jar plugin enabled, thus a *-tests.jar is built for each
module. In the second module, I have defined a dependency to first's tests jar:
{noformat}
me
first
tests
1.0-SNAPSHOT
compile
{noformat}
And here's the problem: A class in the second main folder imports a class from
the first test folder. If I build the second module separately it builds like
it should. But if I build both modules from the root module I get a
compilation failure:
{noformat}
/.../root/second/src/main/java/me/SecondMain.java:[3,10] cannot find symbol
symbol : class FirstTest
location: package me
{noformat}
A class in second's test folder also includes me.FirstTest, and it always
compiles. The scope somehow seems to be overridden when doing multi module
builds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-362) Not able to include ejb-client artifact in jar-with-dependencies
[
http://jira.codehaus.org/browse/MASSEMBLY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165221#action_165221
]
Henrik Brautaset Aronsen commented on MASSEMBLY-362:
Maybe using
[maven-shade-plugin|http://maven.apache.org/plugins/maven-shade-plugin/]
instead of the assembly plugin will solve it? I haven't had time to test it
yet.
> Not able to include ejb-client artifact in jar-with-dependencies
>
>
> Key: MASSEMBLY-362
> URL: http://jira.codehaus.org/browse/MASSEMBLY-362
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Henrik Brautaset Aronsen
>
> The assembly:assembly target with jar-with-dependencies does not include my
> ejb-client dependency. The jar dependencies are included. I've tried
> specifiying my own assembly.xml, but the artifact isn't included nonetheless:
> assembly.xml:
> {code}
>mygroup:myartifact-ejb
>
> {code}
> pom.xml:
> {code}
>mygroup
>myartifact-ejb
>ejb-client
>
> {code}
> I've also tried {{mygroup:myartifact-ejb:*}},
> {{mygroup:myartifact-ejb:ejb-client}} and a couple of other combinations.
> Maven still complains:
> {code}[WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'mygroup:myartifact-ejb'
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4032) Test jar dependency not available for for main classes in multi module builds
[
http://jira.codehaus.org/browse/MNG-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165339#action_165339
]
Henrik Brautaset Aronsen commented on MNG-4032:
---
Thanks for the updates. As mentioned in the linked issues, this issue is
fixable by replacing tests with test-jar.
Just in case anyone else who has this problem sees this issue...
> Test jar dependency not available for for main classes in multi module builds
> -
>
> Key: MNG-4032
> URL: http://jira.codehaus.org/browse/MNG-4032
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build, Class Loading, Dependencies,
> Inheritance and Interpolation
>Affects Versions: 2.0.9, 2.1.0-M1
> Environment: MacOSX, Linux
>Reporter: Henrik Brautaset Aronsen
>Assignee: John Casey
> Fix For: 2.1.0
>
> Attachments: tests-dependency.zip
>
>
> I have a module layout like this:
> {noformat}
> root -+- first
> +- second
> {noformat}
> I have the test-jar plugin enabled, thus a *-tests.jar is built for each
> module. In the second module, I have defined a dependency to first's tests
> jar:
> {noformat}
>
> me
> first
> tests
> 1.0-SNAPSHOT
> compile
>
> {noformat}
> And here's the problem: A class in the second main folder imports a class
> from the first test folder. If I build the second module separately it
> builds like it should. But if I build both modules from the root module I
> get a compilation failure:
> {noformat}
> /.../root/second/src/main/java/me/SecondMain.java:[3,10] cannot find symbol
> symbol : class FirstTest
> location: package me
> {noformat}
> A class in second's test folder also includes me.FirstTest, and it always
> compiles. The scope somehow seems to be overridden when doing multi module
> builds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: maven-dependency-problem.zip
This issue is still not fixed in 2.1.0.
Steps to reproduce:
- download and unzip [^maven-dependency-problem.zip]
- cd first
- mvn clean install
- cd fourth
- mvn clean install (which fails)
The project layout is this:
{noformat}
first--+--secondthird
|
+--fourth
{noformat}
"third" has "second" as parent version, and "second"/"fourth" has "first" as
parent version. They all use a common applicationVersion property, which is
set in "first". "fourth" has a dependency on "third", which resolves OK, but
it fails to resolve the transitive dependency to "second":
{code}
[INFO] Failed to resolve artifact.
GroupId: me
ArtifactId: second
Version: ${applicationVersion}
Reason: Unable to download the artifact from any repository
me:second:pom:${applicationVersion}
{code}
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
>Assignee: John Casey
> Fix For: 2.1.0
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch,
> InstallMojo.quoteReplacement.patch, maven-dependency-problem.zip,
> maven-install-parent.patch
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-2446:
--
Attachment: maven-version-problem.zip
I have the same problem, and I have attached a test case (see
maven-version-problem.zip):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
INFO] Using default encoding to copy filtered resources.
Downloading:
http://repo1.maven.org/maven2/me/second/${applicationVersion}/second-${applicationVersion}.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace ${applicationVersion} to 1.0 in this file, the {{fourth}} module
builds fine on itself.
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139953#action_139953
]
henrik242 edited comment on MNG-2446 at 6/30/08 5:28 AM:
I have the same problem, and I have attached a test case (see
[^maven-version-problem.zip]):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
INFO] Using default encoding to copy filtered resources.
Downloading:
http://repo1.maven.org/maven2/me/second/${applicationVersion}/second-${applicationVersion}.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace {{${applicationVersion}}} with {{1.0}} in this file, the
{{fourth}} module builds fine on itself.
was (Author: henrik242):
I have the same problem, and I have attached a test case (see
maven-version-problem.zip):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
INFO] Using default encoding to copy filtered resources.
Downloading:
http://repo1.maven.org/maven2/me/second/${applicationVersion}/second-${applicationVersion}.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace ${applicationVersion} to 1.0 in this file, the {{fourth}} module
builds fine on itself.
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139953#action_139953
]
henrik242 edited comment on MNG-2446 at 6/30/08 5:30 AM:
I have the same problem, and I have attached a test case (see
[^maven-version-problem.zip]):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: me
ArtifactId: second
Version: ${applicationVersion}
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace {{${applicationVersion}}} with {{1.0}} in this file, the
{{fourth}} module builds fine on itself.
was (Author: henrik242):
I have the same problem, and I have attached a test case (see
[^maven-version-problem.zip]):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
INFO] Using default encoding to copy filtered resources.
Downloading:
http://repo1.maven.org/maven2/me/second/${applicationVersion}/second-${applicationVersion}.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace {{${applicationVersion}}} with {{1.0}} in this file, the
{{fourth}} module builds fine on itself.
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139953#action_139953
]
henrik242 edited comment on MNG-2446 at 6/30/08 5:32 AM:
This issue should definately have a _major_ priority. I have the same problem,
and I have attached a test case (see [^maven-version-problem.zip]):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: me
ArtifactId: second
Version: ${applicationVersion}
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace {{${applicationVersion}}} with {{1.0}} in this file, the
{{fourth}} module builds fine on itself.
was (Author: henrik242):
I have the same problem, and I have attached a test case (see
[^maven-version-problem.zip]):
{code}
first-+-second---third
|
+-fourth
{code}
Fourth depends on third. Doing a {{mvn clean install}} from root works fine.
Doing the same within the {{fourth}} module fails to resolve the {{second}}
artifact:
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: me
ArtifactId: second
Version: ${applicationVersion}
{code}
The problem is in the install plugin. It creates pom files in the repository
with an unparsed :
{code}
$ cat ~/.m2/repository/me/second/1.0/second-1.0.pom
4.0.0
me
second
Second
pom
third
me
first
${applicationVersion}
../pom.xml
{code}
If I replace {{${applicationVersion}}} with {{1.0}} in this file, the
{{fourth}} module builds fine on itself.
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2412) global variable filtering of pom.xml for parent and sub module pom.xml files is not working when deploying to a repository.
[
http://jira.codehaus.org/browse/MNG-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139955#action_139955
]
Henrik Brautaset Aronsen commented on MNG-2412:
---
The problem is the install plugin. It doesn't replace $applicationVersion with
the real version in the pom files it installs to your maven2 repository. See
MNG-3057.
> global variable filtering of pom.xml for parent and sub module pom.xml files
> is not working when deploying to a repository.
> ---
>
> Key: MNG-2412
> URL: http://jira.codehaus.org/browse/MNG-2412
> Project: Maven 2
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: Windows XP., JDK 1.5
>Reporter: Bill Brown
> Fix For: 2.1
>
>
> Greetings:
> I have a maven2 project with two sub modules. I run into an issue when I
> build and deploy a SNAPSHOT of this project and try to reference one of the
> modules as a dependency when I build another project.
> here is the project structure.
> project
> module1
> pom.xml
> module2
> pom.xml
> pom.xml
> The parent pom declares a global property in the properties section:
>
> 1.1.2-SNAPSHOT
>
> The parent pom declares the project version in the following way:
> ${applicationVersion}
> The module poms refrence the parent pom with the parent tags:
>
> com.gocsc
> sam
> ${applicationVersion}
>
> The module poms both declare the project version in the same way:
> ${applicationVersion}
> The project deploys the artifacts to the corporate repository without error
> but the generated poms for each sub module and also the parent module do not
> resolve the ${applicationVersion} in all of the locations:
> The parent pom project version remains the same in the deployed pom.
> ${applicationVersion}
> The parent tags in the sub module poms remain the same:
>
> com.gocsc
> sam
> ${applicationVersion}
>
> The only section that gets resolved / filtered is the project version tags of
> the sub modules.
> 1.1.2-20060628.195852-10
> This seems to be what is causing the problem when I use one of the sub
> modules as dependency in another project and try to build it. Here is the
> output:
> *
> [INFO] snapshot com.gocsc:sam-common:1.1.2-SNAPSHOT: checking for updates
> from com.gocsc
> Downloading:
> file:///\\gatling\maven2\repository/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
> [WARNING] Unable to get resource from repository com.gocsc
> (file:///\\gatling\maven2\repository)
> Downloading:
> http://repo1.maven.org/maven2/com/gocsc/sam/${applicationVersion}/sam-${applicationVersion}.pom
> [WARNING] Unable to get resource from repository central
> (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: com.gocsc
> ArtifactId: sam
> Version: ${applicationVersion}
> Reason: Unable to download the artifact from any repository
> com.gocsc:sam:pom:${applicationVersion}
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> com.gocsc (file:///\\gatling\maven2\repository)
> ***
> Even if I manually modify the repository pom files to use the timstamp
> version of:
> 1.1.2-20060628.195852-10
> I still get the same error above.
> Is this the expected behavior of the system? Is this a bug?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139956#action_139956
]
Henrik Brautaset Aronsen commented on MNG-3057:
---
I added another test case for this problem in MNG-2446.
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: InstallMojo.java.patch
[^InstallMojo.java.patch] is a patch against revision 672740 of
maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java.
It's not very pretty, but it fixes this problem.
How to apply and build:
{code}
$ svn checkout
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin
maven-install-plugin
$ cd maven-install-plugin/src/main/java/org/apache/maven/plugin/install
$ patch < InstallMojo.java.patch
$ cd ../../../../../../../..
$ mvn clean install
{code}
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140058#action_140058
]
Henrik Brautaset Aronsen commented on MNG-2446:
---
I've added a patch against maven-install-plugin in MNG-3057 that fixes this
issue. It's sort of a hack, though, I don't reckon the patch will be added to
the main stream code.
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144263#action_144263 ] Henrik Brautaset Aronsen commented on MNG-624: -- MNG-3057 also has a small patch on maven-install-plugin that fixes the property substitution in . > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.1 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144263#action_144263 ] henrik242 edited comment on MNG-624 at 8/6/08 6:08 AM: -- MNG-3057 also has a small patch on maven-install-plugin that fixes the property substitution in . There's a test case for it in [MNG-2446|http://jira.codehaus.org/browse/MNG-2446?focusedCommentId=139953#action_139953]. was (Author: henrik242): MNG-3057 also has a small patch on maven-install-plugin that fixes the property substitution in . > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.1 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[
http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145306#action_145306
]
henrik242 edited comment on MNG-3314 at 8/18/08 4:06 AM:
The problem seems to be related to the ctime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
was (Author: henrik242):
The problem seems to be related to the filectime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
> offline build not running, when having SNAPSHOT dependencies
>
>
> Key: MNG-3314
> URL: http://jira.codehaus.org/browse/MNG-3314
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
>Reporter: Matthias Weßendorf
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.11
>
> Attachments: maven-offline-snapshot-failure.log,
> maven-offline-snapshot-problem.tar
>
>
> am having troubles with
> mvn ... -o
> (with maven 2.0.7)
> says not able to download (but, really, the file is in my local repo)
> The dependency is a -SNAPSHOT (for what's worth)
> Luckily, when traveling by train, I had maven 2.0.4 on my box as well.
> A change to use 2.0.4 works fine.
> So, is this an already know bug in 2.0.7 ?
> To my understanding it is a bug, since offline just shouldn't try to get a
> newer
> SNAPSHOT, perhaps I am wrong.
> I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect
> just not checking for new stuff.
> and... for some reasons, sometimes,
> it just downloads a new SNAPSHOT.
> That is a pain, when you are "maintaining" the same snapshot on your
> box, but the build just goes ahead and actually downloads a version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[
http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145306#action_145306
]
Henrik Brautaset Aronsen commented on MNG-3314:
---
The problem seems to be related to the filectime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
> offline build not running, when having SNAPSHOT dependencies
>
>
> Key: MNG-3314
> URL: http://jira.codehaus.org/browse/MNG-3314
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
>Reporter: Matthias Weßendorf
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.11
>
> Attachments: maven-offline-snapshot-failure.log,
> maven-offline-snapshot-problem.tar
>
>
> am having troubles with
> mvn ... -o
> (with maven 2.0.7)
> says not able to download (but, really, the file is in my local repo)
> The dependency is a -SNAPSHOT (for what's worth)
> Luckily, when traveling by train, I had maven 2.0.4 on my box as well.
> A change to use 2.0.4 works fine.
> So, is this an already know bug in 2.0.7 ?
> To my understanding it is a bug, since offline just shouldn't try to get a
> newer
> SNAPSHOT, perhaps I am wrong.
> I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect
> just not checking for new stuff.
> and... for some reasons, sometimes,
> it just downloads a new SNAPSHOT.
> That is a pain, when you are "maintaining" the same snapshot on your
> box, but the build just goes ahead and actually downloads a version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
http://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145413#action_145413
]
Henrik Brautaset Aronsen commented on MINSTALL-50:
--
MNG-3057 also has a patch for this issue. And it's being worked on in MNG-624.
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: http://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch, MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> ${myprop}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "filteringEnabled". Since this defaults
> to "false", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in FilteredProjectArtifactMetadata.java, the
> property resolution code has been inspired by ResourcesMojo.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
> is not included in the patch. This file is the same as
> src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145526#action_145526 ] Henrik Brautaset Aronsen commented on MNG-624: -- Harsha: There is a simple patch in MNG-3057 which solves this issue. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MARTIFACT-32) Maven does not expand expressions while installing artifacts locally
[
http://jira.codehaus.org/browse/MARTIFACT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145527#action_145527
]
Henrik Brautaset Aronsen commented on MARTIFACT-32:
---
There is a simple patch in MNG-3057 which solves this issue.
> Maven does not expand expressions while installing artifacts locally
> -
>
> Key: MARTIFACT-32
> URL: http://jira.codehaus.org/browse/MARTIFACT-32
> Project: Maven Artifact
> Issue Type: Bug
>Reporter: Harsha Rai
>
> When a pom uses expressions like: grizzly.version in the following pom.xml
> >
> >
>...
> > grizzly-module
> > jar
> > ${grizzly.version}
> Everything works well when the project.version above is defined as a
> property as 'grizzly.version'
> The local repository layout also seems to be correct, for a given property
> value for, grizzly.version.
> What's going wrong is, maven just copies the same pom.xml to the local repo
> directory and from there to the remote repo while deploying the
> artifacts of the same project, whose version is parameterized.
> In the strict sense, while parsing the pom and resolving the artifacts,
> maven got the right version for the project.version for the project; the
> same should have been used inside the pom file while installing locally. By
> doing this, the expanded pom files will have right artifact information.
> Users should be given a choice if they want maven to expand expressions in
> the pom.xml or leave them as it is.
> I don't know the right category of the project and component. Please reassign
> / redirect as appropriate.
> This belongs somewhere pom parsing, artifact resolver and mvn install.
> thanks..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: InstallMojo.java.patch
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148493#action_148493
]
Henrik Brautaset Aronsen commented on MNG-3057:
---
I've updated the patch. System properties are taken into account as well now.
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148493#action_148493
]
henrik242 edited comment on MNG-3057 at 9/19/08 5:49 AM:
I've updated [the patch|^InstallMojo.java.patch]. System properties are taken
into account as well now.
was (Author: henrik242):
I've updated the patch. System properties are taken into account as well
now.
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-362) Not able to include ejb-client artifact in jar-with-dependencies
Not able to include ejb-client artifact in jar-with-dependencies
Key: MASSEMBLY-362
URL: http://jira.codehaus.org/browse/MASSEMBLY-362
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Henrik Brautaset Aronsen
The assembly:assembly target with jar-with-dependencies does not include my
ejb-client dependency. The jar dependencies are included. I've tried
specifiying my own assembly.xml, but the artifact isn't included nonetheless:
assembly.xml:
{code}
mygroup:myartifact-ejb
{code}
pom.xml:
{code}
mygroup
myartifact-ejb
ejb-client
{code}
I've also tried {{mygroup:myartifact-ejb:*}},
{{mygroup:myartifact-ejb:ejb-client}} and a couple of other combinations.
Maven still complains:
{code}[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o 'mygroup:myartifact-ejb'
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: maven-install-parent.patch
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch, maven-install-parent.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152123#action_152123
]
Henrik Brautaset Aronsen commented on MNG-3057:
---
Hi Maxim.
I'm attaching [^maven-install-parent.patch], which is the one I've been using
locally for awhile. It fixes dots in property names and the properties
replacements you mentioned, as well as the failing unit tests.
I am not using nested properties and mvn deploy myself, and haven't given that
much thought -- sorry about that.
I don't think the maven team have any plans of including *this* patch, but
there's ongoing work in MNG-624 to do something simliar which [might be
included in Maven
2.1.0-M6|http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan] .
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch, maven-install-parent.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152287#action_152287
]
henrik242 edited comment on MNG-2446 at 10/29/08 9:32 AM:
-
Sorry, I uploaded [^InstallMojo.quoteReplacement.patch] by a mistake. It
should have been attached to MNG-3057.
was (Author: henrik242):
Here's a quick fix for the Illegal group reference bug (nested properties):
[^InstallMojo.quoteReplacement.patch]
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: InstallMojo.quoteReplacement.patch,
> maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: InstallMojo.quoteReplacement.patch
Maxim: Here's a quick fix for the Illegal group reference bug (nested
properties): [^InstallMojo.quoteReplacement.patch]
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch,
> InstallMojo.quoteReplacement.patch, maven-install-parent.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-2446:
--
Attachment: InstallMojo.quoteReplacement.patch
Here's a quick fix for the Illegal group reference bug (nested properties):
[^InstallMojo.quoteReplacement.patch]
> parent Pom properties not resolved for module dependencies
> ---
>
> Key: MNG-2446
> URL: http://jira.codehaus.org/browse/MNG-2446
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.4
> Environment: WindowsXP/Linux - JDK 1.4 last version
>Reporter: Jeremie Poutrin
>Priority: Minor
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: InstallMojo.quoteReplacement.patch,
> maven-version-problem.zip
>
>
> root-project --> root-pom.xml with ${my.version}
> |--->proj1 ${my.version}
> |--->proj2 ${my.version}
> | |
> | |->proj1 dependency
> |--->proj3 ${my.version}
> if I compile from the root-project directory, all compile fine.
> if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
> resolve proj1-${my.version}
> but tries to resolve the parent version root-project-${my.version} but this
> is not resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152998#action_152998 ] Henrik Brautaset Aronsen commented on MNG-624: -- Thank you for your valuable contribution to this bug report, Jean-Charles. I have no doubt that your comment is vital in solving this issue. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
