[jira] Created: (ARCHETYPE-286) Use System.getProperty("line.separator") for line ending terminators of generated source files
Use System.getProperty("line.separator") for line ending terminators of
generated source files
--
Key: ARCHETYPE-286
URL: http://jira.codehaus.org/browse/ARCHETYPE-286
Project: Maven Archetype
Issue Type: Bug
Components: Generator
Affects Versions: 2.0-alpha-4
Environment: WindowsXP Prof 2002 SP2, JDK 1.6.0_17, Maven 2.2.1
Reporter: Harold Shinsato
Priority: Minor
It would be nice if it weren't necessary to translate the line endings when
we're not on a unix/linux system.
--
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: (MJAVADOC-275) Creation of Javadoc attachments fails in multi-module project where modules have never been installed/deployed
[
http://jira.codehaus.org/browse/MJAVADOC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214339#action_214339
]
Harold Shinsato commented on MJAVADOC-275:
--
This is happening for us only during release:perform - is there any workaround?
It's confusing why the javadoc for one project gets invoked from another
project.
> Creation of Javadoc attachments fails in multi-module project where modules
> have never been installed/deployed
> --
>
> Key: MJAVADOC-275
> URL: http://jira.codehaus.org/browse/MJAVADOC-275
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Benjamin Bentmann
>Priority: Critical
> Attachments: MJAVADOC-275.zip
>
>
> Running the commands
> {noformat}
> mvn clean
> mvn verify
> {noformat}
> will fail on the attached demo project with
> {noformat}
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'org.apache.maven.its.javadoc:mod-b:jar:0.1'.
> Trying to invoke it...
> [ERROR] MavenInvocationException: Error when invoking Maven, consult the
> invoker log file:
> M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] MavenReportException: Error while creating archive:
> Error when invoking Maven, consult the invoker log file:
> M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
> {noformat}
> The command {{mvn clean verify}} as usually used during releases will also
> fail, but starts working after repeated invocations.
--
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-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
[
http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218967#action_218967
]
Harold Shinsato commented on MNG-2877:
--
We've run in this as well with the Maven Dependency Plugin 2.0.6 running with
Maven 2.2.1. I'm confused as to why this bug is marked fixed with the Maven
Dependency Plugin 2.0.6 - as the problem still seems to be present.
> unable to resolve attached artifacts from reactor that are not in repo.
> (patch applied in svn and IT tests added)
> -
>
> Key: MNG-2877
> URL: http://jira.codehaus.org/browse/MNG-2877
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
>Reporter: Brian Fox
>Assignee: Jason van Zyl
> Fix For: 2.0.6
>
> Attachments: test-bug-maven-release.zip
>
>
> The patch has been applied here:
> https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
> and the IT tests are already added to core-it but commented out from the
> suite. To enable it, uncomment this line: //suite.addTestSuite(
> MavenIT0118AttachedArtifactsInReactor.class );
> ---
> This is from MDEP-64:
> We have a project with a few sub-projects. Only one of those subprojects uses
> the maven-dependency-plugin, copying the jar file artifact from one of the
> sibling sub-projects. The dependency plugin has worked fine in another
> multi-project m2 buld and release when the dependency copy was only
> referencing projects outside the multi-project's project tree.
> But in the present multi-project release, copying that sibling jar file with
> the dependency plugin causes the mvn release:prepare step to fail, because it
> can't find the released version in the release repository. It doesn't care
> about referencing sibling project dependencies from the regular pom
> dependencies, it only chokes for the dependency:copy.
> Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
> scm, distributionManagement, and other content from the poms that were not
> necessary to communicate the basic issue. I've worked around this by using
> the antrun plugin, which is unpleasant and untidy. This seems like it might
> be related to MDEP-44.
> superproject/
> A/ -> no dependencies
> B/ -> dependency:copy A
> //superproject/pom.xml (abbrieviated)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO] task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId:
> ArtifactId: A
> Version: 1.0.0.1
> Reason: Unable to download the artifact from any repository
--
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: (MSUREFIRE-160) Documentation link on website does not point to surefire parameter docs
Documentation link on website does not point to surefire parameter docs --- Key: MSUREFIRE-160 URL: http://jira.codehaus.org/browse/MSUREFIRE-160 Project: Maven 2.x Surefire Plugin Issue Type: Bug Environment: irrelevant Reporter: Harold Shinsato Priority: Minor On page http://maven.apache.org/plugins/maven-surefire-plugin/howto.html, and the very end, there is a promise that "There are other parameters that you can configure like testFailureIgnore, reportsDirectory, and so on. For full documentation, click here." Clicking "here" only leads back to the empty index page. Where are the docs for the parameters? -- 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: (MANT-13) Generated build.xml for pom packaged super projects doesn't invoke subprojects
Generated build.xml for pom packaged super projects doesn't invoke subprojects -- Key: MANT-13 URL: http://jira.codehaus.org/browse/MANT-13 Project: Maven 2.x Ant Plugin Issue Type: Bug Environment: windows xp Reporter: Harold Shinsato Attachments: test_pom_package_w_ant_ant.zip Running mvn ant:ant on a pom packaged superproject generates a build.xml in the top level and recursively for all the lower level builds. But the top level pom packaging includes compile tasks that are not invoked in the top level - and then ant complains because there is no src/main/java directory. And it does not map the prime function of a pom package project, which is to invoke all the subprojects. -- 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-167) More friendly failure message when scm.getConnection() returns null during a release
More friendly failure message when scm.getConnection() returns null during a release Key: MRELEASE-167 URL: http://jira.codehaus.org/browse/MRELEASE-167 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: Windows XP Reporter: Harold Shinsato Doing a release:prepare, this failure occurred. Not sure why, but the source code shows (PropertiesReleaseConfigurationStore.write - line 225) that scm.getConnection() returned a null. The scm worked earlier in the phase, so not sure why it would be null, but a more friendly message here might have shown what the problem was. It does seem it would be wiser to have a check for scm.getConnection() != null before trying to put the connection into the properties list. Here's the crash stack. java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:396) at java.util.Properties.setProperty(Properties.java:128) at org.apache.maven.plugins.release.config.PropertiesReleaseConfigurationStore.write(PropertiesReleaseConfigurationStore.java:225) at org.apache.maven.plugins.release.config.PropertiesReleaseConfigurationStore.write(PropertiesReleaseConfigurationStore.java:149) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:145) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:106) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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: (SCM-258) The perforce provider should be able to accept complex filespecs using a clientspec rather than the path in the SCM url
[ http://jira.codehaus.org/browse/SCM-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135325#action_135325 ] Harold Shinsato commented on SCM-258: - Is there any way to make the perforce plugin work with the release plugin if you don't have a one directory clientspec? I'm quite confused. The release:prepare task seems to be blocked but it's unclear if this is the issue - but it looks like it might be because of the message that "+//myspec" doesn't match "//myspec", the release:prepare task reports. [INFO] The SCM location in your pom.xml (//myspec) is not equal to the depot location (+//myspec). This happens frequently with branches. Ignoring the SCM location. > The perforce provider should be able to accept complex filespecs using a > clientspec rather than the path in the SCM url > --- > > Key: SCM-258 > URL: http://jira.codehaus.org/browse/SCM-258 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-perforce > Environment: All OS, Maven 2.x using the SCM plugin to talk to > perforce >Reporter: Dana Lacoste > Fix For: future > > > One of the strengths of perforce is the ability to do fairly complex actions > with the clientspec. > For example: > 1 - Checkout two file structures into one location: > //depot1/tree1/... //client/project/tree1 > //depot2/tree2/... //client/project/tree2 > 2 - Rename file structures at checkout time : > //depot/tree/sample-configuration.xml //client/tree/configuration.xml > The SCM URL format doesn't allow this (and implementing it would be difficult) > Currently, the perforce provider doesn't seem to allow a way to use an > existing clientspec (all codepaths seem to create a new clientspec based on > the URL) > If the provider could allow an existing clientspec to define the file > structure, this functionality could be enabled. > Testing: > I don't have any JUnit experience, but I think this could be tested by: > 1 - Create a clientspec that defines some complex content, for example: > //depot/project/src/... //clientspec/project/src/... > //ThirdParty/... //clientspec/project/ThirdParty/... > 2 - run "mvn scm:checkout" and all files should be checked out. > Implementation Ideas: > I can see multiple ways of doing this, depending on the > restrictions/conventions required > A - Use the existing "bootstrap/target/checkout" dynamic directory structure > - Using "p4 client -o" with the given/predefined/assumed clientspec, > alter the p4_root (the line containing "Root:") and do a "p4 sync -f" >(Definition of the clientspec ideas defined separately below) > B - Assume the clientspec has a defined "Root:" and use that for the purposes > of "locating" files (needed for tag/editing/checkin purposes) > - As I'm only checking out, I really don't know how this would affect a > checkin :) > C - Separate from above, how to define which clientspec to use: > - In the SCM URL, perhaps with scm:perforce:[EMAIL > PROTECTED]:port:@clientspec_name > (the second @ being a placeholder for a delimiter) > - As an environment variable (perhaps the existing > maven.scm.perforce.clientspec.name, > enabling this functionality (re-use vs. re-create) with a different > property > - Defined in the settings.xml or in the pom.xml in the SCM configuration > properties > I'm sure more details will be required, this is only what I've identified > within my particular situation. -- 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-273) Regression: NullPointerException at end of standalone "release:perform"
[
http://jira.codehaus.org/browse/MRELEASE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135331#action_135331
]
Harold Shinsato commented on MRELEASE-273:
--
I'm seeing this as well. I also executed it in a directory without a pom.
> Regression: NullPointerException at end of standalone "release:perform"
> ---
>
> Key: MRELEASE-273
> URL: http://jira.codehaus.org/browse/MRELEASE-273
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
>Reporter: Max Bowsher
>Priority: Blocker
> Attachments: release.bug
>
>
> I executed "mvn release:perform -DconnectionUrl=scm:svn:..". The actual
> performing succeeded, but then the plugin failed with a NullPointerException
> - it seems that the plugin attempts to unconditionally run code analogous to
> "mvn release:clean", but this is inappropriate because release:perform is not
> supposed to require a project to be able to run.
> Output:
> {noformat}
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
> [INFO] Final Memory: 13M/23M
> [INFO]
>
> [INFO] Cleaning up after release...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [DEBUG] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
> at
> org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
> at
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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)
> [INFO]
>
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Thu Au
[jira] Created: (MASSEMBLY-150) Clarify or fix relative scoping in assembly descriptor to be module centric or location of mvn execution
Clarify or fix relative scoping in assembly descriptor to be module centric or location of mvn execution --- Key: MASSEMBLY-150 URL: http://jira.codehaus.org/browse/MASSEMBLY-150 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: windows xp Reporter: Harold Shinsato According to http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the assembly descriptor's source is supposed to be absolute or relative from the module's directory. This works when I execute mvn in the module directory. But when I run it from a top level super project, it seems to run from that higher level project. This isn't how the works, which we were using before, but we needed to set filtering to true, which caused this to break. So this is how we have to write this to make this work from the top level, but it breaks when running the assembly from this directory. fileutil/src/main/scripts/FileUploadUtility.bat file-utility true This is how it used to be specified, where it worked both from the top level and from the subdirectory: ../fileutil file-utility FileUploadUtility.bat Hopefully this won't make a difference, but we've plugged our assembly into the execution of the package phase. This is copied from the pom.xml of the module. maven-assembly-plugin src/main/assembly/dist.xml attached package -- 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-197) Release plugin documentation on maven.apache.org has broken link to release:rollback
Release plugin documentation on maven.apache.org has broken link to release:rollback Key: MRELEASE-197 URL: http://jira.codehaus.org/browse/MRELEASE-197 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Harold Shinsato The website lists a release:rollback goal with a broken link. http://maven.apache.org/plugins/maven-release-plugin/ Notice the link with the text "release:rollback", it links to http://maven.apache.org/plugins/maven-release-plugin/rollback-mojo.html which is a non-existant page. This goal is not listed in other pages of the documentation for this plugin, so I'm assuming it no longer exists or was deleted. Notice that this info page doesn't reference the release:rollback. http://maven.apache.org/plugins/maven-release-plugin/plugin-info.html -- 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-64) Subprojects using m2 dependency plugin causes release:prepare to fail
Subprojects using m2 dependency plugin causes release:prepare to fail
-
Key: MDEP-64
URL: http://jira.codehaus.org/browse/MDEP-64
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Environment: winxp
Reporter: Harold Shinsato
Assigned To: Brian Fox
We have a project with a few sub-projects. Only one of those subprojects uses
the maven-dependency-plugin, copying the jar file artifact from one of the
sibling sub-projects. The dependency plugin has worked fine in another
multi-project m2 buld and release when the dependency copy was only referencing
projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with
the dependency plugin causes the mvn release:prepare step to fail, because it
can't find the released version in the release repository. It doesn't care
about referencing sibling project dependencies from the regular pom
dependencies, it only chokes for the dependency:copy.
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
scm, distributionManagement, and other content from the poms that were not
necessary to communicate the basic issue. I've worked around this by using the
antrun plugin, which is unpleasant and untidy. This seems like it might be
related to MDEP-44.
superproject/
A/ -> no dependencies
B/ -> dependency:copy A
//superproject/pom.xml (abbrieviated)
superproject
pom
1.0.0.1-SNAPSHOT
A
B
// superproject/A/pom.xml (abbrievated)
superproject
1.0.0.1-SNAPSHOT
A
1.0.0.1-SNAPSHOT
// superproject/B/pom.xml (abbreviated)
superproject
1.0.0.1-SNAPSHOT
B
war
1.0.0.1-SNAPSHOT
FooWar
org.apache.maven.plugins
maven-dependency-plugin
copy
copy
package
A
${pom.version}
jar
${project.build.directory}/${pom.build.finalName}/jars
A
${pom.version}
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO]task-segment: [clean, integration-test]
[INFO]
[INFO] [clean:clean]
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: :A:null:1.0.0.1:jar
Downloading: /1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle ()
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId:
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to download the artifact from any repository
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-64) Subprojects using m2 dependency plugin causes release:prepare to fail
[
http://jira.codehaus.org/browse/MDEP-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harold Shinsato updated MDEP-64:
Attachment: summary.txt
The summary seems to avoid the removal of the indenting that happened in the
description field.
> Subprojects using m2 dependency plugin causes release:prepare to fail
> -
>
> Key: MDEP-64
> URL: http://jira.codehaus.org/browse/MDEP-64
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Environment: winxp
>Reporter: Harold Shinsato
> Assigned To: Brian Fox
> Attachments: summary.txt
>
>
> We have a project with a few sub-projects. Only one of those subprojects
> uses the maven-dependency-plugin, copying the jar file artifact from one of
> the sibling sub-projects. The dependency plugin has worked fine in another
> multi-project m2 buld and release when the dependency copy was only
> referencing projects outside the multi-project's project tree.
> But in the present multi-project release, copying that sibling jar file with
> the dependency plugin causes the mvn release:prepare step to fail, because it
> can't find the released version in the release repository. It doesn't care
> about referencing sibling project dependencies from the regular pom
> dependencies, it only chokes for the dependency:copy.
> Here's a diagram for the issue with three pseudo-poms. I omitted groupId's,
> scm, distributionManagement, and other content from the poms that were not
> necessary to communicate the basic issue. I've worked around this by using
> the antrun plugin, which is unpleasant and untidy. This seems like it might
> be related to MDEP-44.
> superproject/
> A/ -> no dependencies
> B/ -> dependency:copy A
> //superproject/pom.xml (abbrieviated)
>
> superproject
> pom
> 1.0.0.1-SNAPSHOT
>
> A
> B
>
>
> // superproject/A/pom.xml (abbrievated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> A
> 1.0.0.1-SNAPSHOT
>
> // superproject/B/pom.xml (abbreviated)
>
>
> superproject
> 1.0.0.1-SNAPSHOT
>
> B
> war
> 1.0.0.1-SNAPSHOT
>
> FooWar
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy
>
> copy
>
> package
>
>
>
> A
> ${pom.version}
> jar
>
>
>
> ${project.build.directory}/${pom.build.finalName}/jars
>
>
>
>
>
>
>
>
> A
> ${pom.version}
>
>
>
> The error message during mvn release:prepare is basically:
> [INFO] Building B
> [INFO]task-segment: [clean, integration-test]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] [dependency:copy {execution: copy}]
> [INFO] Configured Artifact: :A:null:1.0.0.1:jar
> Downloading: /1.0.0.1/A-1.0.0.1.jar
> [WARNING] Unable to get resource from repository sizzle ( details>)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId:
> ArtifactId: A
> Version: 1.0.0.1
> Reason: Unable to download the artifact from any repository
--
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-92) Bad xml in sample documentation on website
Bad xml in sample documentation on website -- Key: MWAR-92 URL: http://jira.codehaus.org/browse/MWAR-92 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: Harold Shinsato Priority: Minor The online documentation at http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html contains a snippet of xml, the first example box has the following. value The final tag should have been to properly close it and make it well formed xml, otherwise this snippet won't work. -- 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-82) go-offline / resolve-plugins does not resolve all plugin dependencies
[ http://jira.codehaus.org/browse/MDEP-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197430#action_197430 ] Harold Shinsato commented on MDEP-82: - Being able to go offline so all needed dependencies (including plugin dependencies) will work is something we have a requirement to do for our builds or it will be hard for us to get to use maven. Is there a workaround for this issue that would not require writing custom code? > go-offline / resolve-plugins does not resolve all plugin dependencies > - > > Key: MDEP-82 > URL: http://jira.codehaus.org/browse/MDEP-82 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: go-offline, resolve-plugins >Affects Versions: 2.0-alpha-4 > Environment: Maven 2.0.6 >Reporter: Arne Degenring >Assignee: Brian Fox > Attachments: pom.xml > > > The attached pom.xml is a very simple JAR project, without any direct > dependencies or plugin dependencies. > Start with an empty local repository, and run mvn dependency:go-offline on > it. Some files get downloaded, but not everything that is needed for the > build. If you run "mvn -o package" afterwards, you end up with the following > error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not > exist or no valid version could be found > Afterwards, even "mvn package" without the "-o" parameter does not work any > longer. -- 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
