[jira] Created: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.
Inherit dependencies from a WAR type dependency when it is overlayed. - Key: MWAR-253 URL: http://jira.codehaus.org/browse/MWAR-253 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Maarten Billemont When WAR artifact B depends on WAR artifact A, and also defines an overlay of A, B should inherit all A's dependencies. This issue is related to MNG-1991, but can be resolved without much discussion as it's unrelated to skinny WARs and such. Classes in B are guaranteed to have runtime access to all A's declared dependencies when A is an overlay of B. -- 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-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269370#action_269370 ] Maarten Billemont commented on MNG-1991: I've created a separate issue for the overlay case, since the resolution for that will probably be different from resolving the skinny WAR use case, and shouldn't need any additional configuration. See MWAR-253 > Can't get transitive dependencies from a war pom when this war is added as a > depdency of a project > -- > > Key: MNG-1991 > URL: http://jira.codehaus.org/browse/MNG-1991 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2 >Reporter: Emmanuel Venisse > Fix For: Issues to be reviewed for 3.x > > > I have a project (continuum-core-it) that need to use all transitive > dependencies of a war (continuum-webapp). If i add the war as a dependency of > the project with packaging war, war dependencies aren't shown by project, > maven doesn't try to resolve them and doesn't add them in classpath. > If if replace packaging from war to pom, all dependencies are resolved and > added to classpath. -- 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: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.
[ http://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269435#action_269435 ] Maarten Billemont commented on MWAR-253: Currently all classes in B have all A's classes and dependencies available at runtime, guaranteed, by virtue of being in the same WAR, but they are not available at compile time. That is a bug to do with the compile-time classpath. > Inherit dependencies from a WAR type dependency when it is overlayed. > - > > Key: MWAR-253 > URL: http://jira.codehaus.org/browse/MWAR-253 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Maarten Billemont > > When WAR artifact B depends on WAR artifact A, and also defines an overlay of > A, B should inherit all A's dependencies. > This issue is related to MNG-1991, but can be resolved without much > discussion as it's unrelated to skinny WARs and such. > Classes in B are guaranteed to have runtime access to all A's declared > dependencies when A is an overlay of B. -- 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: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.
[ http://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269532#action_269532 ] Maarten Billemont commented on MWAR-253: The plugin provides the ability to overlay one WAR with another. Such an overlay implies that the latter WAR's classes function, at runtime, in the same classpath. The WAR plugin however fails to reflect this at compile-time. It does not set the compile-time classpath for the artifact according to what is needed to properly compile its classes, which would otherwise work fine at runtime thanks to the overlaying. In that sense, this is a bug with regards to the overlay functionality in the WAR plugin neglecting to reflect its effects at compile-time, as it does at run-time. > Inherit dependencies from a WAR type dependency when it is overlayed. > - > > Key: MWAR-253 > URL: http://jira.codehaus.org/browse/MWAR-253 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Maarten Billemont > > When WAR artifact B depends on WAR artifact A, and also defines an overlay of > A, B should inherit all A's dependencies. > This issue is related to MNG-1991, but can be resolved without much > discussion as it's unrelated to skinny WARs and such. > Classes in B are guaranteed to have runtime access to all A's declared > dependencies when A is an overlay of B. -- 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] (MJARSIGNER-14) Keystore password should be entered in an interactive way
[
https://jira.codehaus.org/browse/MJARSIGNER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351931#comment-351931
]
Maarten Billemont commented on MJARSIGNER-14:
-
Two years later, do we really still care about 1.5? Let's just merge this.
> Keystore password should be entered in an interactive way
> -
>
> Key: MJARSIGNER-14
> URL: https://jira.codehaus.org/browse/MJARSIGNER-14
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Eric TOURNIER
>Priority: Minor
> Attachments: MJARSIGNER-14-maven-jarsigner-plugin.patch,
> MJARSIGNER-14-maven-jarsigner-plugin.patch
>
>
> For security reasons, it could be useful not to configure keystore password
> in the {{pom.xml}} file. Then, when these informations are missing, the
> plugin should ask the user to enter this password in an interactive way.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259090#action_259090 ] Maarten Billemont commented on MDEP-208: So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- 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: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259090#action_259090 ] Maarten Billemont edited comment on MDEP-208 at 3/7/11 4:09 AM: So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is and regardless of whether the artifacts are in the reactor or not. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. was (Author: lhunath): So, with this fix (as tested in 2.2), my artifacts are named [artifactId]-[version].[packaging] either way, regardless of what the finalName is. That kind of throws finalName out the window completely. Is this the intended effect? This causes severe issues with us, since we actually RELY on our artifact's finalName to name them a certain way. That's because JBoss deploys .ear files in sort-order. We need our core application to be deployed before any applications that use its beans. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- 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] Reopened: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Billemont reopened MDEP-208: Given the above comment, this issue needs to be re-evaluated. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > Fix For: 2.2 > > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- 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: (MNG-5038) Properly inherit parent dependency management in child dependency management.
Properly inherit parent dependency management in child dependency management.
-
Key: MNG-5038
URL: http://jira.codehaus.org/browse/MNG-5038
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Reporter: Maarten Billemont
say I have a pom artifact a, with a dependencyManagement section that says
something like:
{{
my.company
some-lib
${some-lib.version}
jar
commons-logging
commons-logging
}}
This artifact marks the top-level pom of a multi-module project. There's a
child pom artifact a:b, with a depedencyManagement section that says something
like:
{{
my.company
some-lib
provided
}}
Only, that doesn't fly. a:b's dependency element doesn't inherit from a's. In
fact, even if I explicitly added in the version to make maven find the right
dependency node, it would still forget about my parent's exclusion.
Which means that a:b's dependencyManagement doesn't override a's, it *replaces*
it. And that's a real and serious pain, because now I need to COPY a's
dependencyManagement code into a:b wherever I want to amend it, leaving me to
configure all my excludes in two places. You can imagine the complete and
utter lack of consistency between a:b and a's dependencyManagement excludes
after 2 years of trying to maintain this sort of set-up, with all the
unexpected bugs that result from it.
"Hey, why is commons-logging in our build, it's excluded!", no it's not,
somebody decided to amend some lib that depends on it in a:b and now suddenly
it's back in.
--
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: (MRELEASE-668) Properties are not inherited
Properties are not inherited
Key: MRELEASE-668
URL: http://jira.codehaus.org/browse/MRELEASE-668
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.1
Reporter: Maarten Billemont
When a parent defines a property, eg. myproject.version, and a child uses it in
reference of a dependency on a module in the project, the property cannot be
found, and prepare fails with:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on
project myproject: The version could not be updated: ${myproject.version} ->
[Help 1]
Setup:
mycompany:myproject:1.0-SNAPSHOT ( has
1.0-SNAPSHOT )
- mycompany.myproject:child1:1.0-SNAPSHOT ( has no , has a
on mycompany.myproject:child2:${myproject.version} )
- mycompany.myproject:child2:1.0-SNAPSHOT
This setup results in the error message above after showing:
[INFO] Transforming 'child1'...
[INFO] Updating child2 to 1.0
If I copy the from myproject into child1 then child1's dependency
on child2 updates just fine.
I would expect child1 to *inherit* all properties from myproject, but for some
reason, it doesn't.
--
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: (MNG-4513) Add "additions"/"depedencies" to "dependency" element in "dependencyManagement".
Add "additions"/"depedencies" to "dependency" element in "dependencyManagement".
Key: MNG-4513
URL: http://jira.codehaus.org/browse/MNG-4513
Project: Maven 2 & 3
Issue Type: New Feature
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Maarten Billemont
Quite often we need ugly hacks in our poms because of broken dependencies in
artifacts we depend on.
For example, org.apache.ws.security:wss4j depends on xalan:xalan, but that
dependency is outdated or badly maintained (not sure now, but irrelevant); so
we need to exclude it and replace it with org.apache.xalan:xalan. Only; we
can't do this from our dependencyManagement section for all our project
modules, no, we can exclude xalan:xalan, but for EACH module that uses wss4j,
we need to MANUALLY specify the dependency on org.apache.xalan:xalan; even
though this SHOULD be a transitional dependency from wss4j. This is dirty and
causes unacceptable bugs and maintenance when artifact dependencies change or
artifacts are distributed to third parties.
To fix this, we need to either host our own fixed version of wss4j, or Maven
would have to introduce a method of doing BOTH the exclusion of xalan:xalan AND
the addition of org.apache.xalan:xalan to the wss4j artifact from the
dependencyManagement section. Personally; I'm not sure it makes much sense
supporting only one of the two.
In this example, I'd like to see the following in my project's parent pom:
org.apache.ws.security
wss4j
${wss4j.version}
xalan
xalan
xerces
xercesImpl
xml-security
xmlsec
xml-apis
xml-apis
org.apache.xalan
xalan
${xalan.version}
org.apache.xerces
xercesImpl
${xercesImpl.version}
org.apache.santuario
xmlsec
${xmlsec.version}
org.apache.santuario
xmlsec
${xmlsec.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] Created: (MRELEASE-538) Release-with-pom fails for git provider
Release-with-pom fails for git provider
---
Key: MRELEASE-538
URL: http://jira.codehaus.org/browse/MRELEASE-538
Project: Maven 2.x Release Plugin
Issue Type: Bug
Reporter: Maarten Billemont
When running the release-with-pom goal; toward the end, the release-poms are
deleted and this change is committed. Unfortunately, with the GIT provider,
this is done by first git rm'ing the files and then git add'ing them
(presumably, to add the rm change to the index). The latter fails because the
files are no longer present.
{code}
[INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git rm
release-pom.xml d/release-pom.xml c/release-pom.xml e/release-pom.xml
[INFO] Working directory: /Users/lhunath/work/git
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git add -- pom.xml
release-pom.xml d/pom.xml d/release-pom.xml c/pom.xml c/release-pom.xml
e/pom.xml e/release-pom.xml
[INFO] Working directory: /Users/lhunath/work/git
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-add command failed.
Command output:
fatal: pathspec 'release-pom.xml' did not match any files
{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] Created: (MRELEASE-539) prepare-with-pom fails for git provider
prepare-with-pom fails for git provider
---
Key: MRELEASE-539
URL: http://jira.codehaus.org/browse/MRELEASE-539
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Reporter: Maarten Billemont
When running the release-with-pom goal; toward the end, the release-poms are
deleted and this change is committed. Unfortunately, with the GIT provider,
this is done by first git rm'ing the files and then git add'ing them
(presumably, to add the rm change to the index). The latter fails because the
files are no longer present.
{code}
[INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git rm
release-pom.xml d/release-pom.xml c/release-pom.xml e/release-pom.xml
[INFO] Working directory: /Users/lhunath/work/git
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git add -- pom.xml
release-pom.xml d/pom.xml d/release-pom.xml c/pom.xml c/release-pom.xml
e/pom.xml e/release-pom.xml
[INFO] Working directory: /Users/lhunath/work/git
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-add command failed.
Command output:
fatal: pathspec 'release-pom.xml' did not match any files
{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] Created: (MRELEASE-540) branch fails with git provider when not on a branch
branch fails with git provider when not on a branch --- Key: MRELEASE-540 URL: http://jira.codehaus.org/browse/MRELEASE-540 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0 Reporter: Maarten Billemont When running release:branch while not on a branch tip, maven fails because the git provider tries to look up the symbolic-ref of the current commit and push this. This should not be fatal; when no symbolic-ref is found for the current commit, the plugin should not fail. This is keeping me from adding release:branch to such that a maintenance branch is automatically created when the release is performed. -- 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: (MRELEASE-538) Release-with-pom fails for git provider
[
http://jira.codehaus.org/browse/MRELEASE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217162#action_217162
]
Maarten Billemont commented on MRELEASE-538:
Invalid, see MRELEASE-539 instead.
> Release-with-pom fails for git provider
> ---
>
> Key: MRELEASE-538
> URL: http://jira.codehaus.org/browse/MRELEASE-538
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Reporter: Maarten Billemont
>
> When running the release-with-pom goal; toward the end, the release-poms are
> deleted and this change is committed. Unfortunately, with the GIT provider,
> this is done by first git rm'ing the files and then git add'ing them
> (presumably, to add the rm change to the index). The latter fails because
> the files are no longer present.
> {code}
> [INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git rm
> release-pom.xml d/release-pom.xml c/release-pom.xml e/release-pom.xml
> [INFO] Working directory: /Users/lhunath/work/git
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /Users/lhunath/work/git && git add -- pom.xml
> release-pom.xml d/pom.xml d/release-pom.xml c/pom.xml c/release-pom.xml
> e/pom.xml e/release-pom.xml
> [INFO] Working directory: /Users/lhunath/work/git
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The git-add command failed.
> Command output:
> fatal: pathspec 'release-pom.xml' did not match any files
> {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] Created: (MRELEASE-541) tries to make empty commits when version doesn't change.
tries to make empty commits when version doesn't change. Key: MRELEASE-541 URL: http://jira.codehaus.org/browse/MRELEASE-541 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0 Reporter: Maarten Billemont We use "SNAPSHOT" as the development version, so not "X.Y-SNAPSHOT". When we use goals such as release:branch to create a release branch, the release plugin tries to create a new commit for that branch even though nothing was changed in code (the main branch uses SNAPSHOT as version and the maintenance branch uses SNAPSHOT too). The release plugin should check whether there are changes before attempting to perform a commit after updating versions. -- 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: (MRELEASE-541) tries to make empty commits when version doesn't change.
[ http://jira.codehaus.org/browse/MRELEASE-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217177#action_217177 ] Maarten Billemont commented on MRELEASE-541: I'll add what may seem obvious but might be GIT (our SCM)-specific: You don't need a new commit to make a new branch; you can just start a branch from any commit. > tries to make empty commits when version doesn't change. > > > Key: MRELEASE-541 > URL: http://jira.codehaus.org/browse/MRELEASE-541 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0 >Reporter: Maarten Billemont > > We use "SNAPSHOT" as the development version, so not "X.Y-SNAPSHOT". When we > use goals such as release:branch to create a release branch, the release > plugin tries to create a new commit for that branch even though nothing was > changed in code (the main branch uses SNAPSHOT as version and the maintenance > branch uses SNAPSHOT too). > The release plugin should check whether there are changes before attempting > to perform a commit after updating versions. -- 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: (MRELEASE-542) release:perform prevents deploy:deploy from deploying release poms
release:perform prevents deploy:deploy from deploying release poms -- Key: MRELEASE-542 URL: http://jira.codehaus.org/browse/MRELEASE-542 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0 Reporter: Maarten Billemont When I begin my release with release:prepare-with-pom to generate release poms and then run release:perform, the deploy:deploy plugin deploys my normal pom instead of the generated release pom I had prepare-with-pom create for me. This is because the deploy:deploy goal is invoked using -f pom.xml as argument. -f pom.xml should probably be removed from the arguments. I'm not sure whether it serves a higher purpose, though. I don't think it's possible to build using one pom and have deploy:deploy deploy another. -- 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: (MRELEASE-542) release:perform prevents deploy:deploy from deploying release poms
[ http://jira.codehaus.org/browse/MRELEASE-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217293#action_217293 ] Maarten Billemont commented on MRELEASE-542: I just encountered another related issue: My parent POM specifies a lot of dependencyManagement; when using release-poms, this section does not come through and my whole build changes. This is unacceptable. The flaw is in the fact that the build is performed using release-pom.xml, while this is not at all the purpose of this release pom. The purpose is to hide internal configuration (which is obviously necessary for a correct build) from the users of the artifact (they don't need to build it). Therefore, it is imperative that the REAL pom.xml is used for the entire process; but the release-pom.xml is used as the pom to deploy; and ONLY that. > release:perform prevents deploy:deploy from deploying release poms > -- > > Key: MRELEASE-542 > URL: http://jira.codehaus.org/browse/MRELEASE-542 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0 >Reporter: Maarten Billemont > > When I begin my release with release:prepare-with-pom to generate release > poms and then run release:perform, the deploy:deploy plugin deploys my normal > pom instead of the generated release pom I had prepare-with-pom create for > me. This is because the deploy:deploy goal is invoked using -f pom.xml as > argument. > -f pom.xml should probably be removed from the arguments. I'm not sure > whether it serves a higher purpose, though. I don't think it's possible to > build using one pom and have deploy:deploy deploy another. -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[ http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219487#action_219487 ] Maarten Billemont commented on MCHANGELOG-104: -- Seems OK with 2.2-SNAPSHOT. > NPE when using the plugin with the git provider > --- > > Key: MCHANGELOG-104 > URL: http://jira.codehaus.org/browse/MCHANGELOG-104 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont >Assignee: Mark Struberg > > I've manually added a dependency on the gitexe provider to make the plugin > able to use it. However, using the plugin with GIT then causes the following > NullPointerEception: > Caused by: java.lang.NullPointerException > at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) > at > org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) > at > org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) > ... 19 more -- 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: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
finalName of artifacts not in the reactor is not taken into account. Key: MDEP-208 URL: http://jira.codehaus.org/browse/MDEP-208 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies, unpack-dependencies Affects Versions: 2.0 Reporter: Maarten Billemont Assignee: Brian Fox Setting: A project where module B has a dependency on module A. Module B uses copy-dependencies to copy that dependency into a certain directory. What works: When both module A and B are in the maven reactor, module A's finalName is taken into account and the artifact that ends up copied into our directory uses the filename as given by finalName. What doesn't work: When only module B is in the maven reactor, module A is copied from the local repository where it has a different filename. Maven-dependency-plugin does not correct the filename during copy and as a result we have an artifact in our destination directory with a different name. This behavior is inconsistent and a solution should be established. I propose maven-dependency-plugin reads the dependency (A)'s POM and checks whether it has a finalName set. If so, it should modify the destination filename of the dependency copy operation accordingly. -- 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: (MDEP-208) finalName of artifacts not in the reactor is not taken into account.
[ http://jira.codehaus.org/browse/MDEP-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172628#action_172628 ] Maarten Billemont commented on MDEP-208: Our scenario is as follows: We have a maven artifact which yields a ZIP that contains a pre-configured JBoss installation. This contains each of our application's EAR files in the JBoss deploy directory. These EAR files are dependencies of the distribution artifact, and copy-dependencies is used to copy all EAR dependencies of the distribution artifact into the JBoss deploy directory. Since JBoss uses the EAR filename to determine the JNDI binding of all EJBs, it is absolutely vital that the naming of these EAR files remains consistent, no matter how the artifact is built - provided, of course, the build is successful. > finalName of artifacts not in the reactor is not taken into account. > > > Key: MDEP-208 > URL: http://jira.codehaus.org/browse/MDEP-208 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies, unpack-dependencies >Affects Versions: 2.0 >Reporter: Maarten Billemont >Assignee: Brian Fox > > Setting: > A project where module B has a dependency on module A. > Module B uses copy-dependencies to copy that dependency into a certain > directory. > What works: > When both module A and B are in the maven reactor, module A's finalName is > taken into account and the artifact that ends up copied into our directory > uses the filename as given by finalName. > What doesn't work: > When only module B is in the maven reactor, module A is copied from the local > repository where it has a different filename. Maven-dependency-plugin does > not correct the filename during copy and as a result we have an artifact in > our destination directory with a different name. > This behavior is inconsistent and a solution should be established. I > propose maven-dependency-plugin reads the dependency (A)'s POM and checks > whether it has a finalName set. If so, it should modify the destination > filename of the dependency copy operation accordingly. -- 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: (MECLIPSE-460) Configure eclipse to use same source/target version as configured in maven-compiler-plugin.
Configure eclipse to use same source/target version as configured in maven-compiler-plugin. --- Key: MECLIPSE-460 URL: http://jira.codehaus.org/browse/MECLIPSE-460 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Workspace settings Reporter: Maarten Billemont With a configuration like this: org.apache.maven.plugins maven-compiler-plugin 1.3 1.3 The following should be written to ".settings/org.eclipse.jdt.core.prefs": org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.3 org.eclipse.jdt.core.compiler.source=1.3 org.eclipse.jdt.core.compiler.compliance=1.3 We are working with a multi-module project where certain modules have a non-default source/target version because they are applets and need to be compatible with JSE 1.3. Without the above; these projects cause a mass of warnings in our eclipse workspace which shouldn't be there. -- 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-2205) "provided" scope dependencies must be transitive
[ http://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144387#action_144387 ] Maarten Billemont commented on MNG-2205: What I'd like to do is create a POM-type artifact which is basically just a grouping of dependencies used by other artifacts. commons-codec commons-codec 1.3 provided Then I would add this artifact as a provided dependency to all artifacts. The desired result would be an inclusion of all dependencies from this container artifact in my other artifacts, marked as provided. You may wonder why I'm not just marking them as compile-scoped in the container artifact; here's why: I have an artifact that creates a ZIP file containing the JBoss AS. This artifact basically just downloads JBoss, extracts it, messes around with its configuration, and packages it as a ZIP file. Additionally, all artifacts from the container artifact above that are *not* marked as *provided* (because they are not already provided by JBoss) are *added* to the jboss/server/default/lib/ directory just before zipping it up. That means I can specify two types of provided dependencies in the container POM above: - Dependencies provided by the JBoss AS default configuration (provided in the container POM). - Dependencies that I add to my JBoss' server/default/lib directory (compile in the container POM). Every artifact that depends on the container POM and sets that dependency to a provided should have all dependencies in the container pom, be they provided or compile, added to the artifact as provided. This is exactly as described by the documentation here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope With one single exception: I cannot yet mark provided dependencies in the container POM as transitive. The table on the link above says "provided" in the intersection of "provided" on the left side and "provided" on the top. Reading the text above the table you will see this implies that: If a dependency is set to [provided], transitive dependencies of that dependency with the scope [provided] will result in a dependency in the main project with the scope [provided]. If no scope is listed, it means the dependency will be omitted. I would've thought that the author would've just put a "-" at the intersection of provided with provided seeing as there currently is no such thing as transitive provided dependencies. Or is there? > "provided" scope dependencies must be transitive > > > Key: MNG-2205 > URL: http://jira.codehaus.org/browse/MNG-2205 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: David Boden >Priority: Critical > Fix For: 2.1 > > > A provided scope dependency can also be thought of as "compile-only". > Project A requires Sybase JConnect on the runtime classpath. Project A > declares a "provided" dependency on Sybase JConnect. > Project B depends upon Project A. Project B declares a "compile" dependency > on Project A. > Project C depends upon Project B. Project C declares a "compile" dependency > on Project B. > C > | - compile dependency > B > | - compile dependency > A > | - provided dependency > Sybase JConnect > So, does Project C transitively depend on Sybase JConnect. Yes, of course! > The "provided" dependency needs to be transitive. > Ultimately, when Project C gets deployed, Sybase JConnect needs to be > somewhere on the runtime classpath in order for the application to function. > It's valid for Project C to assume that Sybase JConnect is available and use > JDBC all over the Project C code. Project C is safe to do this because it can > happily deduce that Sybase JConnect will be there in the runtime environment > because Project A NEEDS IT. > I've got Use Cases all over my aggregated build which make it absolutely > critical and common sense that provided scope dependencies are transitive. > For the (very rare) odd case where you don't want to inherit provided > dependencies, you can them. -- 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: (MNG-3739) Perform multiple web requests simultaneously.
Perform multiple web requests simultaneously. - Key: MNG-3739 URL: http://jira.codehaus.org/browse/MNG-3739 Project: Maven 2 Issue Type: Improvement Components: Performance Affects Versions: 2.0.9 Reporter: Maarten Billemont Maven's dependency downloading is horribly slow. It appears to only make one request at a time; often to slow mirrors which take seconds to respond. This is not so much of an issue when you use a local repository to keep and manage your dependencies; though it becomes one again once you leave the network of that repository and try to access it over the internet. Maven should make multiple (5 or so; configurable perhaps) requests simultaneously so that while several are establishing connection, others are at least already using the available bandwidth. And should mirrors be capped; other artifacts can already be downloaded from other mirrors to make optimal use of the bandwidth. Currently only a fraction of the bandwidth capacity is used; causing an initial build of a large project without a local repository available to take *for* *ever*. The project I'm working on; I need to make sure to reserve a day at least should I want to build the code with a client. -- 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: (MWAR-18) Need to declare dependencies as resources outside of WEB-INF in WARs
[ http://jira.codehaus.org/browse/MWAR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147129#action_147129 ] Maarten Billemont commented on MWAR-18: --- The "targetPath" feature you talk about is not in maven-war-plugin; it is a patch that has not been applied (your sentence is somewhat misleading/confusing: he doesn't talk about zip dependencies; and overlay definately isn't a "feature" you can currently apply on zip overlays). Either apply the patch and close this bug as fixed; or don't apply the patch and close the bug as won't fix. Currently; the only way I see this happening is with a zip overlay; which is a horribly messy workaround. > Need to declare dependencies as resources outside of WEB-INF in WARs > > > Key: MWAR-18 > URL: http://jira.codehaus.org/browse/MWAR-18 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mark Hobson >Assignee: Stephane Nicoll > Fix For: 2.1-alpha-1 > > Attachments: maven-war-plugin-target-filename-path.patch > > > Need to be able to declare maven dependencies as resources within WARs. > Currently all dependencies are placed within WEB-INF/lib. > Typical use-case is for a war project to pull in an applet from the repo to > be included in the package. Would need to specify the whereabouts of the > applet in the WAR. -- 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: (MWAR-18) Need to declare dependencies as resources outside of WEB-INF in WARs
[ http://jira.codehaus.org/browse/MWAR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147130#action_147130 ] Maarten Billemont commented on MWAR-18: --- (I'd re-open the bug; but I can't find a button to do so; do I hit sub-task?) > Need to declare dependencies as resources outside of WEB-INF in WARs > > > Key: MWAR-18 > URL: http://jira.codehaus.org/browse/MWAR-18 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mark Hobson >Assignee: Stephane Nicoll > Fix For: 2.1-alpha-1 > > Attachments: maven-war-plugin-target-filename-path.patch > > > Need to be able to declare maven dependencies as resources within WARs. > Currently all dependencies are placed within WEB-INF/lib. > Typical use-case is for a war project to pull in an applet from the repo to > be included in the package. Would need to specify the whereabouts of the > applet in the WAR. -- 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: (MWAR-169) NPE during packaging.
NPE during packaging. - Key: MWAR-169 URL: http://jira.codehaus.org/browse/MWAR-169 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Reporter: Maarten Billemont The following NPE happens when I run maven from the parent in a multi-module project; though it does not occur when I run mvn clean install from within the module itself. [INFO] [war:war] [INFO] Packaging webapp [INFO] Assembling webapp[safe-online-startup-runtime] in [/Users/mbillemo/Documents/workspace/safe-online/safe-online-startup-runtime/target/safe-online-startup- runtime-1.1-SNAPSHOT] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) at org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) at org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147131#action_147131 ] Maarten Billemont commented on MWAR-169: Commenting out these options in the maven-war-plugin's configuration section avoids this problem: WEB-INF/lib/* true > NPE during packaging. > - > > Key: MWAR-169 > URL: http://jira.codehaus.org/browse/MWAR-169 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 >Reporter: Maarten Billemont > > The following NPE happens when I run maven from the parent in a multi-module > project; though it does not occur when I run mvn clean install from within > the module itself. > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[safe-online-startup-runtime] in > [/Users/mbillemo/Documents/workspace/safe-online/safe-online-startup-runtime/target/safe-online-startup- > runtime-1.1-SNAPSHOT] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)at > org.apache.maven.cli.MavenCli.main(MavenCli.java:287)at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147131#action_147131 ] lhunath edited comment on MWAR-169 at 9/5/08 8:56 AM: After running mvn clean install in the module in question and then running another mvn install in the parent; the problem no longer occurs. was (Author: lhunath): Commenting out these options in the maven-war-plugin's configuration section avoids this problem: WEB-INF/lib/* true > NPE during packaging. > - > > Key: MWAR-169 > URL: http://jira.codehaus.org/browse/MWAR-169 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 >Reporter: Maarten Billemont > > The following NPE happens when I run maven from the parent in a multi-module > project; though it does not occur when I run mvn clean install from within > the module itself. > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[safe-online-startup-runtime] in > [/Users/mbillemo/Documents/workspace/safe-online/safe-online-startup-runtime/target/safe-online-startup- > runtime-1.1-SNAPSHOT] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)at > org.apache.maven.cli.MavenCli.main(MavenCli.java:287)at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147136#action_147136 ] Maarten Billemont commented on MWAR-169: This has happened to me on artifacts that have no overlays defined and on artifacts that do have overlays defined. > NPE during packaging. > - > > Key: MWAR-169 > URL: http://jira.codehaus.org/browse/MWAR-169 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 >Reporter: Maarten Billemont > > The following NPE happens when I run maven from the parent in a multi-module > project; though it does not occur when I run mvn clean install from within > the module itself. > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[safe-online-startup-runtime] in > [/Users/mbillemo/Documents/workspace/safe-online/safe-online-startup-runtime/target/safe-online-startup- > runtime-1.1-SNAPSHOT] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)at > org.apache.maven.cli.MavenCli.main(MavenCli.java:287)at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MWAR-169) NPE during packaging.
[ http://jira.codehaus.org/browse/MWAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147139#action_147139 ] Maarten Billemont commented on MWAR-169: This might be interesting; done after the process of building from the parent failed on artifact "safe-online-owner-webapp": cd "safe-online-owner-webapp" cp -a target target~ mvn clean install # successful diff -ur target~ target The result shows only one file is different: "war/work/webapp-cache.xml" The old version of this file (from target~; the target dir that caused the build to fail) contained an entry for "net.lin-k.safe-online:safe-online-startup-runtime" which is NOT the artifact that should be overlayed on this artifact. The new version of this file (from target; the target dir that caused the build to succeed) contained an entry for "net.lin-k.safe-online:safe-online-webapp-base" which IS the artifact that should be overlayed on this artifact. So that's good. Basically; I conclude something has gone wrong in the caching backend of maven-war-plugin. > NPE during packaging. > - > > Key: MWAR-169 > URL: http://jira.codehaus.org/browse/MWAR-169 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 >Reporter: Maarten Billemont > > The following NPE happens when I run maven from the parent in a multi-module > project; though it does not occur when I run mvn clean install from within > the module itself. > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[safe-online-startup-runtime] in > [/Users/mbillemo/Documents/workspace/safe-online/safe-online-startup-runtime/target/safe-online-startup- > runtime-1.1-SNAPSHOT] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)at > org.apache.maven.cli.MavenCli.main(MavenCli.java:287)at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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: (MECLIPSE-79) exclude dependencies from the Classpath Container
[ http://jira.codehaus.org/browse/MECLIPSE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=148510#action_148510 ] Maarten Billemont commented on MECLIPSE-79: --- This does not appear to prevent the dependencies from being downloaded. > exclude dependencies from the Classpath Container > - > > Key: MECLIPSE-79 > URL: http://jira.codehaus.org/browse/MECLIPSE-79 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path > Environment: Windows, Eclipse 3.1.2 >Reporter: Martin Goldhahn >Assignee: nicolas de loof > Fix For: 2.5 > > Attachments: MECLIPSE-79.patch > > > There are some dependencies that need to be in the POM in order to compile > the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an > error because the servlet classes from the POM are included in the classpath > via the classpath container. -- 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: (MECLIPSE-492) Maven Eclipse Plugin does not take dependencyManagement excludes into account when building eclipse CP configuration.
Maven Eclipse Plugin does not take dependencyManagement excludes into account
when building eclipse CP configuration.
-
Key: MECLIPSE-492
URL: http://jira.codehaus.org/browse/MECLIPSE-492
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
Affects Versions: 2.5.1
Reporter: Maarten Billemont
I have a parent pom that excludes xml-apis:xml-apis from dom4j:dom4j in the
dependencyManagement section. To make certain that as the project development
progresses no artifacts depend on xml-apis:xml-apis (it is superseded by
org.apache.xerces:xml-apis) I've forced the version of xml-apis:xml-apis in the
same dependencyManagement section to be -1. No artifact should depend on it
since I'm excluding all dependencies on it manually and adding
org.apache.xerces:xml-apis as a manual dependency. In Maven this works fine.
When I run maven-eclipse-plugin in a child module of this pom artifact which
depends on dom4j:dom4j however, it tries to download xml-apis:xml-apis:jar:-1
and after failing it adds it to the project's classpath configuration (which
obviously causes eclipse to throw errors not being able to find
xml-apis:xml-apis:jar:-1 in my local repository.
dom4j
dom4j
${dom4j.version}
xml-apis
xml-apis
xml-apis
xml-apis
-1
--
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: (MEAR-87) Allow exclusion of artifacts when building the ear file.
[ http://jira.codehaus.org/browse/MEAR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=151830#action_151830 ] Maarten Billemont commented on MEAR-87: --- The current method of excluding dependencies is OK for excluding two or three. It is UNMANAGABLE for excluding large groups of dependencies. Moreover, excluding transitive dependencies this way is utterly rediculous, especially when you have lots of them. You end up with a POM file that repeats x% of all the dependencies in your project, creating massive dublicate code which is hell to maintain. For example, we want to exclude all non-in-house artifacts from the EAR generated; so that the EAR file we distribute contains only our own artifacts. The other dependencies, we put in the default/lib directory of our JBoss AS; they do not belong in the EAR file - where they only serve to bloat; especially when we're trying to build or deploy 4 EAR files, each with all of those dependencies in them. > Allow exclusion of artifacts when building the ear file. > > > Key: MEAR-87 > URL: http://jira.codehaus.org/browse/MEAR-87 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.3.1 >Reporter: Dieter Houthooft >Priority: Minor > Fix For: 2.4 > > Attachments: maven-ear-plugin-excludes-fixed.patch, > maven-ear-plugin-excludes.patch > > > What is included in the .ear file is determined by the module list and the > dependency list and its transitive dependencies. We are often confronted with > changing demands about what to include in our ear files. It is quite hard to > change our dependency management (scopes) every time without side-effects on > other distributable artifacts. So I created an exclude configuration option > which allows to exclude artifacts from the ear file based on regular > expressions (java.util.regex) matching artifactIds and groupIds. > Use it like this: > > > > be.nondistributable.* > > > -- 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: (MCHANGELOG-103) Does not depend on gitexe provider
Does not depend on gitexe provider -- Key: MCHANGELOG-103 URL: http://jira.codehaus.org/browse/MCHANGELOG-103 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Maarten Billemont The plugin specifies a whole bunch of providers manually. This sounds like pretty bad practice; aside from that, it does not specify the gitexe provider, effectively making the plugin useless for repositories using the GIT SCM. Perhaps it should depend on org/apache/maven/scm/maven-scm-providers-standard or org/apache/maven/scm/maven-scm instead? -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
NPE when using the plugin with the git provider --- Key: MCHANGELOG-104 URL: http://jira.codehaus.org/browse/MCHANGELOG-104 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Maarten Billemont I've manually added a dependency on the gitexe provider to make the plugin able to use it. However, using the plugin with GIT then causes the following NullPointerEception: Caused by: java.lang.NullPointerException at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) at org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) at org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) at org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) at org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) ... 19 more -- 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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[ http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=189656#action_189656 ] Maarten Billemont commented on MCHANGELOG-104: -- Nope, maven-changelog-plugin-2.1. > NPE when using the plugin with the git provider > --- > > Key: MCHANGELOG-104 > URL: http://jira.codehaus.org/browse/MCHANGELOG-104 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont > > I've manually added a dependency on the gitexe provider to make the plugin > able to use it. However, using the plugin with GIT then causes the following > NullPointerEception: > Caused by: java.lang.NullPointerException > at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) > at > org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) > at > org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) > ... 19 more -- 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: (MEAR-66) finalName taken into account for full build but not for ear build
[ http://jira.codehaus.org/browse/MEAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191310#action_191310 ] Maarten Billemont commented on MEAR-66: --- This *IS* a bug. If only because of its inconsistent behavior. Building an EAR artifact with dependencies that are in the reactor and have a finalName specified results in a *different* resulting EAR artifact than building the EAR artifact without the dependencies in the reactor. This is not only a problem with the manifest, but, for instance, JBoss uses the archive name to build the JNDI mapping of EJBs. If the name of the archive is unpredictable (because you don't know how it will be built; either with or without the dependencies in the reactor), the JNDI mapping that JBoss will use when deploying the archive is unpredictable and your EJBs are inaccessible half the time. When copying the dependencies, their finalName should be considered and their destination name should conform to it. > finalName taken into account for full build but not for ear build > - > > Key: MEAR-66 > URL: http://jira.codehaus.org/browse/MEAR-66 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP; JDK1.5 >Reporter: Mark Jeffery >Assignee: Stephane Nicoll > Attachments: build.zip, j2ee-1.0.jar > > > If I force a build of all projects via a parent pom (which build 2 EARS), > then the finalName attribute of the jar plugin is taken into account for the > dependencies when they are built. > If I quickly build one EAR only, via its pom, it retrieves the dependencies > from the repository, the finalName in the dependency pom is not taken into > account and the version number is added to the jar name. > This breaks the manifest entries for the jars that were built with the forced > build as they still reference the specified name but the jars included in the > EAR have the version on the name. -- 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: (MECLIPSE-619) Bundle artifact .classpath generation skipped when jboss-sar-type artifacts in reactor
Bundle artifact .classpath generation skipped when jboss-sar-type artifacts in
reactor
--
Key: MECLIPSE-619
URL: http://jira.codehaus.org/browse/MECLIPSE-619
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path (.classpath)
Affects Versions: 2.5.1
Reporter: Maarten Billemont
Whenever I combine an artifact to the reactor of type bundle and jboss-sar, the
bundle artifact does not have its .classpath file generated. I expect the
jboss-packaging-maven-plugin breaks something that maven-eclipse-plugin relies
on.
The two artifacts have no dependency on each other. I can reproduce this with:
{{{
rm -rf my-bundle-artifact/.{classpath,project,settings}; mvn -pl
my-sar-artifact,my-bundle-artifact eclipse:eclipse; ls
my-bundle-artifact/.classpath
}}}
--
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: (MECLIPSE-619) Bundle artifact .classpath generation skipped when jboss-sar-type artifacts in reactor
[
http://jira.codehaus.org/browse/MECLIPSE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198701#action_198701
]
Maarten Billemont commented on MECLIPSE-619:
FWIW, I just verified this issue also exists in 2.7
> Bundle artifact .classpath generation skipped when jboss-sar-type artifacts
> in reactor
> --
>
> Key: MECLIPSE-619
> URL: http://jira.codehaus.org/browse/MECLIPSE-619
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5.1
>Reporter: Maarten Billemont
>
> Whenever I combine an artifact to the reactor of type bundle and jboss-sar,
> the bundle artifact does not have its .classpath file generated. I expect
> the jboss-packaging-maven-plugin breaks something that maven-eclipse-plugin
> relies on.
> The two artifacts have no dependency on each other. I can reproduce this
> with:
> {{{
> rm -rf my-bundle-artifact/.{classpath,project,settings}; mvn -pl
> my-sar-artifact,my-bundle-artifact eclipse:eclipse; ls
> my-bundle-artifact/.classpath
> }}}
--
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: (MECLIPSE-620) Resource rules on test source paths cause implicit **/*.java exclusion
Resource rules on test source paths cause implicit **/*.java exclusion
---
Key: MECLIPSE-620
URL: http://jira.codehaus.org/browse/MECLIPSE-620
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path (.classpath)
Affects Versions: 2.5.1
Reporter: Maarten Billemont
As soon as I add the following to my pom.xml:
{code:xml}
src/test/java
{code}
A rule gets added to {{.classpath}}:
{code:xml}
{code}
The {{excluding="**/*.java"}} seems to appear out of nowhere causing all java
files in eclipse to become unmanaged.
Without this rule resource files in this directory are not added to the eclipse
JUnit classpath (we need this since we have wicket HTML files alongside java
files). I expect to be able to use this:
{code:xml}
false
src/test/java
**
**/*.java
{code}
The same way I use this (and this one DOES work!):
{code:xml}
false
src/main/java
**
**/*.java
{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
