[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[ https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351118#comment-351118 ] Martin Ellis commented on MRELEASE-875: --- Torben: If you run maven with the -X option, it'll show the output of the git status command in the log. That way you'll be able to verify whether the comment prefix is being added. The regular expressions the git output is being matched against are the static fields in this class: http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.7/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java > release:prepare does not commit pom.xml if not in the git root > -- > > Key: MRELEASE-875 > URL: https://jira.codehaus.org/browse/MRELEASE-875 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare, scm >Affects Versions: 2.5 > Environment: git 1.9.0 >Reporter: john ten Den >Assignee: Dominik Bartholdi > > When the project pom.xml is not in the Git project root (f.e. in the "src" > directory) the pom.xml not committed and pushed (before tagging) > Commit of the pom.xml during release:prepare works fine if it is in the / > (root) of the git repository > Using the pom.xml in a subdirectory worked well with version 2.4.2 using git > 1.7. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[
https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348740#comment-348740
]
Martin Ellis commented on MRELEASE-875:
---
In case it helps anyone, I am currently working around this as follows:
* Use maven-release-plugin version 2.4.2
* Ensure git output is English
* Set git's {{status.displayCommentPrefix}} configuration property to {{true}}
(see below)
I've set the displayCommentPrefix option in the .gitconfig of the user running
release:prepare as follows:
{noformat}
[status]
displayCommentPrefix = true
{noformat}
I haven't looked into whether there's a similar workaround for 2.5(.x) yet.
Also, I haven't seen the "ref HEAD is not a symbolic ref" error reported by
Alejandro E.
> release:prepare does not commit pom.xml if not in the git root
> --
>
> Key: MRELEASE-875
> URL: https://jira.codehaus.org/browse/MRELEASE-875
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5
> Environment: git 1.9.0
>Reporter: john ten Den
>
> When the project pom.xml is not in the Git project root (f.e. in the "src"
> directory) the pom.xml not committed and pushed (before tagging)
> Commit of the pom.xml during release:prepare works fine if it is in the /
> (root) of the git repository
> Using the pom.xml in a subdirectory worked well with version 2.4.2 using git
> 1.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345007#comment-345007 ] Martin Ellis commented on MRELEASE-812: --- Looks like we're seeing MRELEASE-875. I've added my vote there. > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343344#comment-343344 ] Martin Ellis commented on MRELEASE-812: --- Just experienced this bug with maven-release-plugin 2.5 using git. Reverting to 2.4.2 fixes the behaviour for me (i.e. commits the pom with a release version). > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.3.2, 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-223) HelpMojo is not extracted when using java-annotations extractor
Martin Ellis created MPLUGIN-223:
Summary: HelpMojo is not extracted when using java-annotations
extractor
Key: MPLUGIN-223
URL: https://jira.codehaus.org/browse/MPLUGIN-223
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Martin Ellis
The generated HelpMojo uses javadoc tags rather than Java annotations.
If the plugin is only configured to use only the java-annotations extractor,
then it does not recognise the HelpMojo as a valid mojo:
{noformat}
java-annotations
{noformat}
In this case, the plugin will silently fail to include the 'help' goal in the
plugin descriptor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303497#comment-303497
]
Martin Ellis edited comment on MASSEMBLY-556 at 7/12/12 4:33 PM:
-
The patches I attached to MASSEMBLY-295 fix this issue.
was (Author: mart):
The patch I attached to MASSEMBLY-295 fixes this issue.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=303497#comment-303497
]
Martin Ellis commented on MASSEMBLY-556:
The patch I attached to MASSEMBLY-295 fixes this issue.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-295) Repository assembly contains local metadata
[ https://jira.codehaus.org/browse/MASSEMBLY-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ellis updated MASSEMBLY-295: --- Attachment: massembly-295-assembly-plugin.diff massembly-295-repo-builder.diff Patches for maven-repository-builder and maven-assembly-plugin attached. I've tested by building the assembly plugin with -Prun-its. Does anything else use maven-repository-builder? Any reason not to just remove the local metadata generation? > Repository assembly contains local metadata > --- > > Key: MASSEMBLY-295 > URL: https://jira.codehaus.org/browse/MASSEMBLY-295 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > Attachments: massembly-295-assembly-plugin.diff, > massembly-295-repo-builder.diff > > > When using the assembly plugin to construct a remote repository as described > on > http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html, > the repository contains "local" metadata files such as > maven-metadata-central.xml. > The remote repository format should only contain maven-metadata.xml files. > Need to re-test with 2.2-beta-2 to confirm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-295) Repository assembly contains local metadata
[ https://jira.codehaus.org/browse/MASSEMBLY-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302618#comment-302618 ] Martin Ellis commented on MASSEMBLY-295: Not adding local metadata would have the benefit of fixing the NPE in MASSEMBLY-556. :) > Repository assembly contains local metadata > --- > > Key: MASSEMBLY-295 > URL: https://jira.codehaus.org/browse/MASSEMBLY-295 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > > When using the assembly plugin to construct a remote repository as described > on > http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html, > the repository contains "local" metadata files such as > maven-metadata-central.xml. > The remote repository format should only contain maven-metadata.xml files. > Need to re-test with 2.2-beta-2 to confirm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-208) HelpMojo class generated by helpmojo goal uses deprecated annotations
Martin Ellis created MPLUGIN-208:
Summary: HelpMojo class generated by helpmojo goal uses deprecated
annotations
Key: MPLUGIN-208
URL: https://jira.codehaus.org/browse/MPLUGIN-208
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Martin Ellis
Attachments: annots-test.tar.gz
The helpmojo goal generates a HelpMojo class that uses 'expression' annotations
on parameter fields rather than 'property' annotations. This results in a lots
of output at warning level when building a plugin that uses the helpmojo goal
for documentation.
This issue refers to javadoc/qdox style annotations generated by the
maven-plugin-plugin 3.0 helpmojo. This version of the 'plugin' plugin does
output Java 5 style annotations too but they are commented out.
Sample project attached. Running {{mvn package}} on the project will show the
warnings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284500#comment-284500
]
Martin Ellis commented on MASSEMBLY-556:
What's up with this ticket?
Looks like Benson Margulies just set the "Fix Version" to 2.3, but the "Fix
Version" is still 'None' in the Details section. Also, the ticket doesn't
appear at:
https://jira.codehaus.org/browse/MASSEMBLY/fixforversion/13669
Is JIRA confused (or just me)?
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ellis updated MASSEMBLY-556:
---
Attachment: massembly-556-2.tar.gz
Attaching massembly-556-2.tar.gz because I managed to compress the first
archive twice.
Also: this issue doesn't seem to be specific to artifacts installed with
install:install-file. (The project I've attached uses junit).
The issue title should probably be updated accordingly.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276677#comment-276677
]
Martin Ellis commented on MASSEMBLY-556:
My user settings are based on the settings described here:
http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
As a workaround, I've managed to build our project with the following settings
file (note that 'nexus' resolves to our local Nexus instance):
{code:xml}
no-mirrors
true
nexus
default
http://nexus/content/groups/public
true
nexus
http://nexus/content/groups/public
default
true
{code}
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556.tar.gz, pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Ellis updated MASSEMBLY-556:
---
Attachment: massembly-556.tar.gz
I've been able to reproduce this bug. It seems to be caused by having a mirror
defined in the settings.
See the attached project for an example.
Running with no mirror defined works correctly:
mvn package -s empty-settings.xml
... however, running with a mirror defined will fail:
mvn package -s mirror-settings.xml
My example settings use repo1.maven.org as the mirror, but I get the same
behaviour with uk.maven.org, and with the url of our repository manager.
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Fix For: 2.3
>
> Attachments: build.log, massembly-556.tar.gz, pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2386) Dozer 5.0 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175405#action_175405 ] Martin Ellis commented on MAVENUPLOAD-2386: --- I agree that uploading under net.sf.dozer would be better for those of us who want to use 5.0 now. Could a new bundle be prepared? BTW, the Dozer FAQ is misleading where it suggests that 5.0 is in the repo under org.dozer: http://dozer.sourceforge.net/documentation/faq.html#maven-repo > Dozer 5.0 Upload > > > Key: MAVENUPLOAD-2386 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2386 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Matt Tierney > Attachments: dozer-5.0-bundle.jar > > > Dozer is a powerful, yet simple Java Bean to Java Bean mapper that > recursively copies data from one object to another. Typically, these Java > Beans will be of different complex types. > Dozer supports simple property mapping, complex type mapping, bi-directional > mapping, implicit-explicit mapping, as well as recursive mapping. This > includes mapping collection attributes that also need mapping at the element > level. > Dozer not only supports mapping between attribute names, but also converting > between types. Many conversion scenarios are supported out of the box, but > Dozer also allows you to specify custom conversions via XML. > The mapper is used any time you need to take one type of Java Bean and map it > to another type of Java Bean. Most field mapping can be done automatically by > Dozer using reflection, but any custom mapping can be predescribed in XML > format. Mapping is bi-directional so only one relationship between classes > needs defining. If any property names on both objects are the same you do not > even need to do any explicit property mapping for these fields. > Thanks in advance! -- 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: (MCHANGES-135) JIRA links on changes report are broken
JIRA links on changes report are broken --- Key: MCHANGES-135 URL: http://jira.codehaus.org/browse/MCHANGES-135 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.0 Reporter: Martin Ellis See the sample changes report for an example of what I mean: http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html The link to MPJIRA-11 on this page is broken - it points to the following page, which is an error message: http://jira.codehaus.org/browse/ViewIssue.jspa?key=MPJIRA-11 This appears to be because the issueLinkTemplate has an inappropriate default value: %URL%/ViewIssue.jspa?key=%ISSUE% according to http://maven.apache.org/plugins/maven-changes-plugin/changes-report-mojo.html A default value of of %URL%/%ISSUE% would result in the following link, which does work: http://jira.codehaus.org/browse/MPJIRA-11 -- 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: (MAVENUPLOAD-1498) Upload JUEL
Upload JUEL --- Key: MAVENUPLOAD-1498 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1498 Project: maven-upload-requests Issue Type: Task Reporter: Martin Ellis JUEL is an implementation of the javax.el.* API - the basis of the Unified Expression Language used in JSP/JSF. It's Apache 2.0 licenced, with copy of CDDL'd javax.el API from Glassfish. The main site for the project is http://juel.sf.net/ It's written by Christoph Beck, of Odysseus Software, http://odysseus.de/ The de.odysseus.juel groupId is his choice (in preference to net.sf.juel - the packages for the implementation classes are under de.odysseus. The odysseus.de domain is registered to Christoph: http://www.who.is/whois-de/ip-address/odysseus.de/ who has uploaded the bundle to that domain: http://odysseus.de/juel/juel-2.1.0-bundle.jar The pom in the referenced bundle includes my name and his (this is the best I can do for a contributor URL). The main jar includes everything you need to embed the EL interpreter. The impl jar is similar, but lacks the javax.el.* API - hence is useful for replacing the implementation used by a container that already has a copy of those classes. 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
