[jira] Commented: (MNGSITE-83) Behavior of Maven when mirror is down should be documented
[ http://jira.codehaus.org/browse/MNGSITE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242061#action_242061 ] John Bäckstrand commented on MNGSITE-83: Unless I am mistaken, using a mirror is the way to do it if you want to use an archetype of anything not in central. Thats the reason I started using my companies internal repository as a mirror of central, which works perfectly, except of course when I am not connected to the VPN meaning the mirror is effectively offline. The nothing works. (Our projects are also set up so that they replace central with our repo) I am surprised this is not fixed yet. Behavior of Maven when mirror is down should be documented -- Key: MNGSITE-83 URL: http://jira.codehaus.org/browse/MNGSITE-83 Project: Maven Project Web Site Issue Type: Improvement Reporter: Trevor Harmon Priority: Minor I recently ran into a Maven problem in which standard artifacts that were hosted on Central could not be downloaded. I eventually traced the problem to the use of a mirror. Our team had been using a local installation of Nexus to mirror Central, as described here: http://maven.apache.org/guides/mini/guide-mirror-settings.html The problem was that the mirror was down. Now, I knew the mirror was down, but I assumed (wrongly) that Maven would try to route around the problem by skipping the downed mirror and obtaining the artifact directly from Central. (It is, after all, only a mirror, not the actual repository.) Instead, if a mirror is down, Maven simply aborts, saying it cannot download the file. This led me to the mistaken conclusion that Central itself was down. It would be nice if this problem could be fixed so that a downed mirror doesn't cause Maven to fail, but that might take a lot of work, so in the meantime I'd be happy if the problem were simply documented. Unfortunately, the Guide to Mirror Settings in the link above talks a lot about how to declare a mirror, but it doesn't say what Maven does if it can't connect to a mirror. It should be amended to include this information. -- 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-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242062#action_242062 ] John Bäckstrand commented on MNG-714: - Is there any more long-winded explanation this is not fixed? How exactly would this break repository managers? -some folks from my company have to change the settings file every time they go home because at home they don't have proxy. Quite annoying... is my exact situation, too. When artifact not found on mirror the real site isn't checked - Key: MNG-714 URL: http://jira.codehaus.org/browse/MNG-714 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0-beta-1 Reporter: Kenney Westerhof Assignee: Jason van Zyl Attachments: MNG-714-maven-artifact-manager.patch Original Estimate: 3 hours Remaining Estimate: 3 hours I'm using the settings.xml mirror feature as a local cache. Periodically I upload my local repo to the webserver specified as mirror. When an artifact cannot be found on the mirror, the original site isn't checked (and possibly the rest of the sites). I'm not sure what the exact function of the mirror is (except caching?), but repo1 is checked often regardless of mirror presence, so I figure it's not meant to totally disable checking the central repo's. Simple reproduction: define a few mirrors in your settings.xml for central, central-plugins and snapshots, pointing to say file://tmp/empty/dir/. Stacktrace: [DEBUG] Error resolving artifact version from metadata. org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) at org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) at org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) at
[jira] Commented: (MNG-4843) maven-glassfish-plugin does not work with maven 3.0-RC3 (works with 2.2.1)
[ http://jira.codehaus.org/browse/MNG-4843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242072#action_242072 ] Vetle Roeim commented on MNG-4843: -- FYI, I have reported it here: https://glassfish.dev.java.net/issues/show_bug.cgi?id=14411 maven-glassfish-plugin does not work with maven 3.0-RC3 (works with 2.2.1) -- Key: MNG-4843 URL: http://jira.codehaus.org/browse/MNG-4843 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0-beta-3 Environment: maven 3.0-RC3 Ubuntu Linux Reporter: Ulli Hafner Assignee: Benjamin Bentmann Deployments to glassfish don't work with maven 3 (the same steps work with maven 2.2.1). Seems that there is a dependency missing. I'm using the following plugin: build plugins plugin groupIdorg.glassfish.maven.plugin/groupId artifactIdmaven-glassfish-plugin/artifactId version2.1/version ... (URL: http://download.java.net/maven/2/org/glassfish/maven/plugin/maven-glassfish-plugin/2.1/) mvn org.glassfish.maven.plugin:maven-glassfish-plugin:deploy [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building FIPS 4 FSPM Product Data Service EAR 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-glassfish-plugin:2.1:deploy (default-cli) @ com.f10.ips4fspm.connect.prdservices.ear --- [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC4-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC5-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC6-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC7-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC8-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.9-RC9-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.10-RC3-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.10-RC4-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.10-RC5-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.10-RC6-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.10-RC7-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.12-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.1.0-M2-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.1-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.maven.artifact:maven-artifact:jar:3.0-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.apache.xbean:xbean-reflect:jar:3.4-20080418.173627-4 is missing, no dependency information available [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:3.0-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.codehaus.plexus:plexus-component-annotations:jar:1.2.1-SNAPSHOT is missing, no dependency information available [WARNING] The POM for org.codehaus.plexus:plexus-container-default:jar:1.2.1-SNAPSHOT is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 4.227s [INFO] Finished at: Thu Sep 30 10:23:21 CEST 2010 [INFO] Final Memory: 9M/171M [INFO] [ERROR] Failed to execute goal org.glassfish.maven.plugin:maven-glassfish-plugin:2.1:deploy (default-cli) on project com.f10.ips4fspm.connect.prdservices.ear: Execution default-cli of goal org.glassfish.maven.plugin:maven-glassfish-plugin:2.1:deploy failed: Plugin org.glassfish.maven.plugin:maven-glassfish-plugin:2.1 or one of its
[jira] Commented: (MEV-609) The following POMs do not even parse
[
http://jira.codehaus.org/browse/MEV-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242078#action_242078
]
Torsten Curdt commented on MEV-609:
---
It wasn't clear a patch was expected for this. It would probably be much easier
to fix in place if one has file level access. Even easier than verifying and
applying all those patches.
Kind of sad you just close this and leave the repo broken.
The following POMs do not even parse
Key: MEV-609
URL: http://jira.codehaus.org/browse/MEV-609
Project: Maven Evangelism
Issue Type: Bug
Components: Invalid POM
Reporter: Torsten Curdt
Assignee: Juven Xu
{code}
repository/acegisecurity/acegi-security/0.7.0/acegi-security-0.7.0.pom failed
Invalid byte 2 of 3-byte UTF-8 sequence.
repository/activemq/activemq-itest-ejb/1.1-G1M3/activemq-itest-ejb-1.1-G1M3.pom
failed locator.ent (No such file or directory)
repository/activemq/activemq-itest-ejb/1.2/activemq-itest-ejb-1.2.pom failed
locator.ent (No such file or directory)
repository/ant/ant/1.6.5/ant-1.6.5.pom failed The prefix xsi for attribute
xsi:schemaLocation associated with an element type project is not bound.
repository/com/javaexchangeconnector/jec/1.52_01/jec-1.52_01.pom failed The
element type artifactId must be terminated by the matching end-tag
/artifactId.
repository/com/novell/ldap/jldap/2006-09-28/jldap-2006-09-28.pom failed The
reference to entity cvsroot must end with the ';' delimiter.
repository/com/pragmaticautomation/pragautox10/1.0/pragautox10-1.0.pom failed
Invalid byte 1 of 1-byte UTF-8 sequence.
repository/easyconf/easyconf/0.9.0/easyconf-0.9.0.pom failed Invalid byte 2
of 2-byte UTF-8 sequence.
repository/generama/generama/1.2.3/generama-1.2.3.pom failed Invalid byte 1
of 1-byte UTF-8 sequence.
repository/jhunlang/jmorph/0.2/jmorph-0.2.pom failed Invalid byte 2 of 2-byte
UTF-8 sequence.
repository/net/sourceforge/jsdp/jsdp/1.0/jsdp-1.0.pom failed The prefix xsi
for attribute xsi:schemaLocation associated with an element type project
is not bound.
repository/net/sourceforge/stripes/stripes/1.3.1/stripes-1.3.1.pom failed The
string -- is not permitted within comments.
repository/org/apache/maven/continuum/continuum-parent/1.0/continuum-parent-1.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven/2.0/maven-2.0-javadoc.pom failed Content is
not allowed in prolog.
repository/org/apache/maven/maven-plugin-tools/2.0/maven-plugin-tools-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven-script/2.0/maven-script-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/reporting/maven-reporting/2.0/maven-reporting-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm/1.0-alpha-4/maven-scm-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-managers/1.0-alpha-4/maven-scm-managers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-providers/1.0-alpha-4/maven-scm-providers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/codehaus/gant/gant/1.0.0/gant-1.0.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.1/gant-1.0.1.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.2/gant-1.0.2.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.0/gant-1.1.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.1/gant-1.1.1.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.2/gant-1.1.2.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.2.0/gant-1.2.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.3.0/gant-1.3.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/jackson/jackson-lgpl/0.9.3/jackson-lgpl-0.9.3.pom
failed The element type description must be terminated by the matching
end-tag /description.
repository/org/codehaus/modello/modello/1.0-alpha-17/modello-1.0-alpha-17.pom
failed Invalid byte 1 of 1-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1/clirr-maven-plugin-2.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1.1/clirr-maven-plugin-2.1.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
[jira] Commented: (MLINKCHECK-10) Upgrade to Doxia 1.1
[
http://jira.codehaus.org/browse/MLINKCHECK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242086#action_242086
]
Vincent Siveton commented on MLINKCHECK-10:
---
agree
Upgrade to Doxia 1.1
Key: MLINKCHECK-10
URL: http://jira.codehaus.org/browse/MLINKCHECK-10
Project: Maven 2.x Linkcheck Plugin
Issue Type: Task
Affects Versions: 1.0
Reporter: Lukas Theussl
Attachments: MLINKCHECK-10.patch
There are a couple of Doxia 1.0 specific quirks in the report-generation
code, in particular several calls to {{sink.rawText()}}, which makes the
plugin unusable with different sinks (cf the pdf plugin).
--
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: (MEV-609) The following POMs do not even parse
[
http://jira.codehaus.org/browse/MEV-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242088#action_242088
]
Juven Xu commented on MEV-609:
--
this project home declares that 'please provide a solution'
this project is going to be shut down, you can create a ticket at
https://issues.sonatype.org/browse/MVNCENTRAL with solution then we will fix
thank you
The following POMs do not even parse
Key: MEV-609
URL: http://jira.codehaus.org/browse/MEV-609
Project: Maven Evangelism
Issue Type: Bug
Components: Invalid POM
Reporter: Torsten Curdt
Assignee: Juven Xu
{code}
repository/acegisecurity/acegi-security/0.7.0/acegi-security-0.7.0.pom failed
Invalid byte 2 of 3-byte UTF-8 sequence.
repository/activemq/activemq-itest-ejb/1.1-G1M3/activemq-itest-ejb-1.1-G1M3.pom
failed locator.ent (No such file or directory)
repository/activemq/activemq-itest-ejb/1.2/activemq-itest-ejb-1.2.pom failed
locator.ent (No such file or directory)
repository/ant/ant/1.6.5/ant-1.6.5.pom failed The prefix xsi for attribute
xsi:schemaLocation associated with an element type project is not bound.
repository/com/javaexchangeconnector/jec/1.52_01/jec-1.52_01.pom failed The
element type artifactId must be terminated by the matching end-tag
/artifactId.
repository/com/novell/ldap/jldap/2006-09-28/jldap-2006-09-28.pom failed The
reference to entity cvsroot must end with the ';' delimiter.
repository/com/pragmaticautomation/pragautox10/1.0/pragautox10-1.0.pom failed
Invalid byte 1 of 1-byte UTF-8 sequence.
repository/easyconf/easyconf/0.9.0/easyconf-0.9.0.pom failed Invalid byte 2
of 2-byte UTF-8 sequence.
repository/generama/generama/1.2.3/generama-1.2.3.pom failed Invalid byte 1
of 1-byte UTF-8 sequence.
repository/jhunlang/jmorph/0.2/jmorph-0.2.pom failed Invalid byte 2 of 2-byte
UTF-8 sequence.
repository/net/sourceforge/jsdp/jsdp/1.0/jsdp-1.0.pom failed The prefix xsi
for attribute xsi:schemaLocation associated with an element type project
is not bound.
repository/net/sourceforge/stripes/stripes/1.3.1/stripes-1.3.1.pom failed The
string -- is not permitted within comments.
repository/org/apache/maven/continuum/continuum-parent/1.0/continuum-parent-1.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven/2.0/maven-2.0-javadoc.pom failed Content is
not allowed in prolog.
repository/org/apache/maven/maven-plugin-tools/2.0/maven-plugin-tools-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven-script/2.0/maven-script-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/reporting/maven-reporting/2.0/maven-reporting-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm/1.0-alpha-4/maven-scm-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-managers/1.0-alpha-4/maven-scm-managers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-providers/1.0-alpha-4/maven-scm-providers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/codehaus/gant/gant/1.0.0/gant-1.0.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.1/gant-1.0.1.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.2/gant-1.0.2.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.0/gant-1.1.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.1/gant-1.1.1.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.2/gant-1.1.2.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.2.0/gant-1.2.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/gant/gant/1.3.0/gant-1.3.0.pom failed The entity
copy was referenced, but not declared.
repository/org/codehaus/jackson/jackson-lgpl/0.9.3/jackson-lgpl-0.9.3.pom
failed The element type description must be terminated by the matching
end-tag /description.
repository/org/codehaus/modello/modello/1.0-alpha-17/modello-1.0-alpha-17.pom
failed Invalid byte 1 of 1-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1/clirr-maven-plugin-2.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1.1/clirr-maven-plugin-2.1.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
repository/org/codehaus/mojo/osxappbundle-maven-plugin/1.0-alpha-1/osxappbundle-maven-plugin-1.0-alpha-1.pom
failed Invalid
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242106#action_242106
]
CTT commented on MRELEASE-140:
--
I'm experiencing the same NoClassDefFoundError/ClassNotFoundException error due
to classpath problems with test-jar dependencies.
Versions of software in use:
Ubuntu Linux 9.10
Java version: 1.6.0_12
Apache Maven 2.2.1 (rdebian-1)
maven-release-plugin 2.0
The release plugin triggers three separate executions of my JUnit tests and the
test failures only occur on the third test execution. The first test run is
part of release:prepare. The next two runs are part of release:perform. The
second run builds the release artifacts, and the third test run is part of the
site goal.
I'm currently working around this issue by removing the site goal.
The test failures are caused by the inability to locate classes in a project
that is providing both a type test-jar and a type jar artifact. Only the
tests that depend on classes in the test-jar fail, all the other tests pass.
Here is the surefire classpath on the second test run:
{noformat}
[INFO] [DEBUG] Test Classpath :
[INFO] [DEBUG]
/home/ctt/workspace_head/RenderableCreationServiceTemp/target/checkout/target/test-classes
[INFO] [DEBUG]
/home/ctt/workspace_head/RenderableCreationServiceTemp/target/checkout/target/classes
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_Core/2.1.0/ImagePath_Core-2.1.0-tests.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/jibx/jibx-run/1.1.6a/jibx-run-1.1.6a.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_SceneApplication/2.1.0/ImagePath_SceneApplication-2.1.0-tests.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_Core/2.1.0/ImagePath_Core-2.1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_SceneApplication/2.1.0/ImagePath_SceneApplication-2.1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/vega/VEGA-RCS-RoomBoards/1.0.0/VEGA-RCS-RoomBoards-1.0.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/springframework/spring-context/2.5.6.SEC01/spring-context-2.5.6.SEC01.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/springframework/spring-beans/2.5.6.SEC01/spring-beans-2.5.6.SEC01.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/springframework/spring-core/2.5.6.SEC01/spring-core-2.5.6.SEC01.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/springframework/spring-test/2.5.6.SEC01/spring-test-2.5.6.SEC01.jar
[INFO] [DEBUG] /home/ctt/.m2/repository/junit/junit/4.4/junit-4.4.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/jibx/jibx-extras/1.1.6a/jibx-extras-1.1.6a.jar
[INFO] [DEBUG] /home/ctt/.m2/repository/xpp3/xpp3/1.1.3.4.O/xpp3-1.1.3.4.O.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/mockito/mockito-core/1.8.3/mockito-core-1.8.3.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/objenesis/objenesis/1.0/objenesis-1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/noelios/restlet/com.noelios.restlet/1.1.8/com.noelios.restlet-1.1.8.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/restlet/org.restlet/1.1.8/org.restlet-1.1.8.jar
{noformat}
Here is the surefire classpath on the third (failing) test run:
{noformat}
[INFO] [DEBUG] Test Classpath :
[INFO] [DEBUG]
/home/ctt/workspace_head/RenderableCreationServiceTemp/target/checkout/target/test-classes
[INFO] [DEBUG]
/home/ctt/workspace_head/RenderableCreationServiceTemp/target/checkout/target/classes
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_Core/2.1.0/ImagePath_Core-2.1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/org/jibx/jibx-run/1.1.6a/jibx-run-1.1.6a.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_SceneApplication/2.1.0/ImagePath_SceneApplication-2.1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_Core/2.1.0/ImagePath_Core-2.1.0.jar
[INFO] [DEBUG]
/home/ctt/.m2/repository/com/lifetouch/lti/ImagePath_SceneApplication/2.1.0/ImagePath_SceneApplication-2.1.0.jar
[INFO] [DEBUG]
[jira] Commented: (MLINKCHECK-10) Upgrade to Doxia 1.1
[
http://jira.codehaus.org/browse/MLINKCHECK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242124#action_242124
]
Dennis Lundberg commented on MLINKCHECK-10:
---
Do we want to apply this patch before or after we release version 1.1?
Upgrade to Doxia 1.1
Key: MLINKCHECK-10
URL: http://jira.codehaus.org/browse/MLINKCHECK-10
Project: Maven 2.x Linkcheck Plugin
Issue Type: Task
Affects Versions: 1.0
Reporter: Lukas Theussl
Attachments: MLINKCHECK-10.patch
There are a couple of Doxia 1.0 specific quirks in the report-generation
code, in particular several calls to {{sink.rawText()}}, which makes the
plugin unusable with different sinks (cf the pdf plugin).
--
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-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242123#action_242123 ] Dennis Lundberg commented on MNG-4162: -- Christopher, the Site Plugin for Maven 3 has a built-in converter, that is able to read the reporting section of a POM and convert it into the new model used in Maven 3. So it is possible to use reporting with Maven 3. Read more on the Site Plugin 3.x site: http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html Removal of all reporting logic from the core of Maven - Key: MNG-4162 URL: http://jira.codehaus.org/browse/MNG-4162 Project: Maven 2 3 Issue Type: Improvement Reporter: Jason van Zyl Assignee: Benjamin Bentmann Fix For: 3.0-beta-1 Attachments: MNG-4162.patch Any reporting implementation will be implemented as a plugin. Maven will provide any information, APIs, and extension points to make this possible. But the conflation of building with reporting in the core makes it almost impossible for anyone two understand the distinction, makes it impossible to have alternate implementations and couple many tools like Doxia directly to the core which is unacceptable for Maven 3.x. -- 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: (MLINKCHECK-10) Upgrade to Doxia 1.1
[
http://jira.codehaus.org/browse/MLINKCHECK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242126#action_242126
]
Lukas Theussl commented on MLINKCHECK-10:
-
Not necessary for this release IMO, unless you take the time (which I haven't)
to test and confirm that it works with the pdf plugin and different maven
versions. I'd say we apply the patch right after the release and have the
snapshot tested for a while.
Upgrade to Doxia 1.1
Key: MLINKCHECK-10
URL: http://jira.codehaus.org/browse/MLINKCHECK-10
Project: Maven 2.x Linkcheck Plugin
Issue Type: Task
Affects Versions: 1.0
Reporter: Lukas Theussl
Attachments: MLINKCHECK-10.patch
There are a couple of Doxia 1.0 specific quirks in the report-generation
code, in particular several calls to {{sink.rawText()}}, which makes the
plugin unusable with different sinks (cf the pdf plugin).
--
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-292) When selecting groupId fuzziness, exclude all artifacts based on groupId.
When selecting groupId fuzziness, exclude all artifacts based on groupId. - Key: MDEP-292 URL: http://jira.codehaus.org/browse/MDEP-292 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Affects Versions: 2.1 Reporter: Greg Vanore Assignee: Brian Fox Attachments: use-groupId-sensitivity-when-building-exclusions.diff This patch includes a simple change to the PurgeLocalRepositoryMojo class so that when the resolutionFuzziness is set to 'groupId,' the exclusions are treated by groupId. This is because if I have two dependencies, such as 'org.slf4j:slf4j-api' and 'org.slf4j:slf4j-log4j' and I only list one of them in my exclusions and set the fuzziness to groupId, the entire group will still be deleted. It seemed more natural to me that if the fuzziness is at the groupId level, that the exclusions should be based on which groupIds have been excluded. -- 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-292) When selecting groupId fuzziness, exclude all artifacts based on groupId.
[ http://jira.codehaus.org/browse/MDEP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242127#action_242127 ] Greg Vanore commented on MDEP-292: -- I didn't mean to submit with Major priority - sorry about that. When selecting groupId fuzziness, exclude all artifacts based on groupId. - Key: MDEP-292 URL: http://jira.codehaus.org/browse/MDEP-292 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Affects Versions: 2.1 Reporter: Greg Vanore Assignee: Brian Fox Attachments: use-groupId-sensitivity-when-building-exclusions.diff This patch includes a simple change to the PurgeLocalRepositoryMojo class so that when the resolutionFuzziness is set to 'groupId,' the exclusions are treated by groupId. This is because if I have two dependencies, such as 'org.slf4j:slf4j-api' and 'org.slf4j:slf4j-log4j' and I only list one of them in my exclusions and set the fuzziness to groupId, the entire group will still be deleted. It seemed more natural to me that if the fuzziness is at the groupId level, that the exclusions should be based on which groupIds have been excluded. -- 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-2805) Provide mechanism for suppressing inherited/injected/mapped mojo binding
[
http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242128#action_242128
]
Ian Brandt commented on MNG-2805:
-
Just to add a real world use case I found my way here looking for a way to
disable the execution of the maven-antlr3-plugin when an IDE profile is
active, signifying the ANTLRv3 IDE Eclipse plugin is in use. The issue is the
M2Eclipse/maven-antlr3-plugin and ANTLRv3 IDE Eclipse plugins tend to trip over
each other, as they both try to create the same generated source files. It
would be easy to disable the ANTLRv3 IDE builder in Eclipse, but it offers the
added benefit of programmatically marking the generated resources as derived.
This doesn't happen if M2Eclipse/maven-antlr3-plugin beats it to the punch
after a {{clean}}.
M2Eclipse lets you set an active profile in project level preferences, which
can be shared by checking in {{.settings/org.maven.ide.eclipse.prefs}}:
{noformat}
#Thu Nov 04 11:24:30 PDT 2010
activeProfiles=ide
eclipse.preferences.version=1
fullBuildGoals=process-test-resources
includeModules=false
resolveWorkspaceProjects=true
resourceFilterGoals=process-resources resources\:testResources
skipCompilerPlugin=true
version=1
{noformat}
Then a workaround similar to that referenced by Aleksander above works okay,
where the maven-antlr3-plugin is only declared in a profile that is active
whenever the ide profile is not:
{noformat}
profiles
profile
idide/id
activation
activeByDefaultfalse/activeByDefault
/activation
properties
idetrue/ide
/properties
/profile
profile
idantlr/id
activation
property
name!ide/name
/property
/activation
build
plugins
plugin
groupIdorg.antlr/groupId
artifactIdantlr3-maven-plugin/artifactId
version3.2/version
executions
execution
goals
goalantlr/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/profile
/profiles
{noformat}
The {{disableExecution}} or {{disablePlugin}} additions proposed would
certainly seem to offer a more straightforward and succinct solution.
Provide mechanism for suppressing inherited/injected/mapped mojo binding
Key: MNG-2805
URL: http://jira.codehaus.org/browse/MNG-2805
Project: Maven 2 3
Issue Type: New Feature
Components: POM
Affects Versions: 2.0.4
Reporter: John Casey
Fix For: Issues to be reviewed for 3.x
In some cases, a mojo should be suppressed from the build process. If this
mojo binding comes from a parent POM or a lifecycle mapping, it's not
possible to simply comment out that mojo binding. Currently this sort of
functionality is left to the individual plugins to implement as parameters
that cause each mojo to bow out. This use case is common enough in large
development environments (for addressing the 80% with no customization, but
allowing the remaining 20% the control to use the same parent POM with
subtractions) to warrant a built-in suppression/disabling functionality.
Suppression should be available by plugin or by plugin-execution. To suppress
bindings from the packaging-mapping, the default executionId 'default' can be
used.
--
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] Closed: (MDEP-149) Field accesses and method invocations cause bogus dependencies
[
http://jira.codehaus.org/browse/MDEP-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-149.
--
Resolution: Fixed
Fix Version/s: 2.2
Field accesses and method invocations cause bogus dependencies
--
Key: MDEP-149
URL: http://jira.codehaus.org/browse/MDEP-149
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Affects Versions: 2.0
Reporter: Benjamin Bentmann
Assignee: Brian Fox
Priority: Trivial
Fix For: 2.2
Attachments: bogus-dependencies.patch, MDEP-149.zip
When hunting down some Used undeclared dependencies warnings, I found the
plugin lying. For example, the line
{code:java}
java.lang.Object var = bean.field;
{code}
does not impose a direct dependency on the field's type, whatever it may be.
Likewise, the line
{code:java}
bean.method(null);
{code}
does not directly depend on the method's return type nor parameter types.
Unless I explicitly code a reference to a type by means of variable
declarations, type checks/casts etc., there is no need to declare
dependencies that are already brought in via transitivity, that's what Maven
was invented for, isn't is ;-)
--
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: (MLINKCHECK-10) Upgrade to Doxia 1.1
[
http://jira.codehaus.org/browse/MLINKCHECK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242135#action_242135
]
Dennis Lundberg commented on MLINKCHECK-10:
---
That is my preference as well.
I'll go ahead and start the release of 1.1 without this issue.
Upgrade to Doxia 1.1
Key: MLINKCHECK-10
URL: http://jira.codehaus.org/browse/MLINKCHECK-10
Project: Maven 2.x Linkcheck Plugin
Issue Type: Task
Affects Versions: 1.0
Reporter: Lukas Theussl
Attachments: MLINKCHECK-10.patch
There are a couple of Doxia 1.0 specific quirks in the report-generation
code, in particular several calls to {{sink.rawText()}}, which makes the
plugin unusable with different sinks (cf the pdf plugin).
--
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] Closed: (MDEP-215) copy-dependencies -- useSubDirectoryPerScope [patch]
[ http://jira.codehaus.org/browse/MDEP-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-215. -- Resolution: Fixed Fix Version/s: 2.2 copy-dependencies -- useSubDirectoryPerScope [patch] Key: MDEP-215 URL: http://jira.codehaus.org/browse/MDEP-215 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: copy-dependencies Affects Versions: 2.1 Reporter: Jo Odland Assignee: Brian Fox Fix For: 2.2 Attachments: useSubDirectoryPerScope-rev771391.diff I have added a useSubDirectoryPerScope configuration setting. This will copy all artefacts into folders based on scope (like /outputDirectory/test/junit-3.8.1-jar) -- 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] Closed: (MDEP-292) When selecting groupId fuzziness, exclude all artifacts based on groupId.
[ http://jira.codehaus.org/browse/MDEP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-292. -- Resolution: Fixed Fix Version/s: 2.2 When selecting groupId fuzziness, exclude all artifacts based on groupId. - Key: MDEP-292 URL: http://jira.codehaus.org/browse/MDEP-292 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: purge-local-repository Affects Versions: 2.1 Reporter: Greg Vanore Assignee: Brian Fox Fix For: 2.2 Attachments: use-groupId-sensitivity-when-building-exclusions.diff This patch includes a simple change to the PurgeLocalRepositoryMojo class so that when the resolutionFuzziness is set to 'groupId,' the exclusions are treated by groupId. This is because if I have two dependencies, such as 'org.slf4j:slf4j-api' and 'org.slf4j:slf4j-log4j' and I only list one of them in my exclusions and set the fuzziness to groupId, the entire group will still be deleted. It seemed more natural to me that if the fuzziness is at the groupId level, that the exclusions should be based on which groupIds have been excluded. -- 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-253) Purge does not purge released artifacts
[ http://jira.codehaus.org/browse/MDEP-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242145#action_242145 ] Brian Fox commented on MDEP-253: Is there any configuration in your pom that could alter the behavior? I just tried it here and it did what I expected. Purge does not purge released artifacts --- Key: MDEP-253 URL: http://jira.codehaus.org/browse/MDEP-253 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: purge-local-repository Affects Versions: 2.0 Environment: Linux, JDK 1.5, Maven 2.0.10 Reporter: James Lorenzen Assignee: Brian Fox I am running into a problem when running mvn dependency:purge-local-repository in that it does not remove any local artifacts for a large multi-module project. I run it from the parent directory and it reports the following for all my sub modules [INFO] Nothing to do for project: ... I expect the goal to examine all my dependencies, including transitive dependencies, and remove them from the local 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-262) Add support for custom ProjectDependencyAnalyzer implementations
[ http://jira.codehaus.org/browse/MDEP-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MDEP-262: -- Attachment: maven-dependency-plugin_2.2.patch maven-dependency-analyzer_1.2.patch updated patch files for the Unix impaired Add support for custom ProjectDependencyAnalyzer implementations Key: MDEP-262 URL: http://jira.codehaus.org/browse/MDEP-262 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Components: analyze Reporter: Tobias Gierke Assignee: Brian Fox Attachments: maven-dependency-analyzer_1.2.patch, maven-dependency-analyzer_1.2.patch, maven-dependency-plugin_2.2.patch, maven-dependency-plugin_2.2.patch I've written a customized ProjectDependencyAnalyzer (includes dependencies from Spring XMLs) that I'd like to be able to use with the maven-dependency-plugin. The current plugin implementation only supports a single ProjectDependencyAnalyzer component on the classpath (otherwise plexus will fail) and has no way of specifying which analyzer to use at runtime. The appended patches add support for custom ProjectDependencyAnalyzer components to the plugin. The basic idea is to assign ProjectDependencyAnalyzer components a unique role-hint and let the plugin dynamically look-up the implementation to use by specifying the role-hint as configuration parameter. 1. maven-dependency-analyzer_1.2.patch Patch against maven-dependency-analyzer 1.2-SNAPSHOT (trunk / r942613) To apply patch: patch -p1 maven-dependency-analyzer_1.2.patch CHANGES: - DefaultProjectDependencyAnalyzer component now has an additonal role-hint 'default' so plexus won't complain when multiple ProjectDependencyAnalyzer components are one the classpath - changes the visibility of buildDependencyClasses() and findArtifactForClassName() from private to protected to allow subclassing - buildDependencyClasses() now takes the artifact map as additional parameter so subclasses can call findArtifactForClassName() with it 2. maven-dependency-plugin_2.2.patch Patch against maven-dependency-plugin 2.2-SNAPSHOT (trunk / r942613) To apply patch: patch -p1 maven-dependency-plugin_2.2.patch CHANGES: - AbstractDependencyMojo now has a new 'analyzer' parameter that is the role hint to use when looking up the ProjectDependencyAnalyzer from the container ( the default value is set to 'default' and thus references DefaultProjectDependencyAnalyzer) - AbstractDependencyMojo now implements Contextualizable and dynamically looks up the ProjectDependencyAnalyzer component to use from the plexus container - Integration test added that first buids and installs a custom dummy ProjectDependencyAnalyzer component and then runs dependency:analyze with this analyzer -- 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] Closed: (MDEP-281) An option to append outputs at the end of output file
[ http://jira.codehaus.org/browse/MDEP-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-281. -- Resolution: Fixed Fix Version/s: 2.2 An option to append outputs at the end of output file - Key: MDEP-281 URL: http://jira.codehaus.org/browse/MDEP-281 Project: Maven 2.x Dependency Plugin Issue Type: Wish Components: resolve, tree Affects Versions: 2.1 Reporter: Selim Ok Assignee: Brian Fox Fix For: 2.2 Attachments: appendOutput.patch It would be nice to have a command line switch to decide, whether the output file will be overwritten or not. Currently the output file is completely overwritten each time. This behavior has a drawback, espceially if i try to get all dependencies of a multi module project. The output file is overwritten for each module and so I get at the end the dependency tree of the last module. For this whish i have prepared a little patch. I'll be very happy, if you accept my commitment. P.S.: Sorry for my bad english. :/ P.S.2: I'm not very sure, if this issue is a feature or wish , please forgive me if i'm wrong. -- 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-281) An option to append outputs at the end of output file
[ http://jira.codehaus.org/browse/MDEP-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242160#action_242160 ] Selim Ok commented on MDEP-281: --- Thank you :) An option to append outputs at the end of output file - Key: MDEP-281 URL: http://jira.codehaus.org/browse/MDEP-281 Project: Maven 2.x Dependency Plugin Issue Type: Wish Components: resolve, tree Affects Versions: 2.1 Reporter: Selim Ok Assignee: Brian Fox Fix For: 2.2 Attachments: appendOutput.patch It would be nice to have a command line switch to decide, whether the output file will be overwritten or not. Currently the output file is completely overwritten each time. This behavior has a drawback, espceially if i try to get all dependencies of a multi module project. The output file is overwritten for each module and so I get at the end the dependency tree of the last module. For this whish i have prepared a little patch. I'll be very happy, if you accept my commitment. P.S.: Sorry for my bad english. :/ P.S.2: I'm not very sure, if this issue is a feature or wish , please forgive me if i'm wrong. -- 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] Closed: (MDEP-192) generated classpath should match what maven produces
[
http://jira.codehaus.org/browse/MDEP-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-192.
--
Resolution: Fixed
Fix Version/s: 2.2
generated classpath should match what maven produces
Key: MDEP-192
URL: http://jira.codehaus.org/browse/MDEP-192
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: build-classpath
Affects Versions: 2.0, 2.1
Environment: all
Reporter: deckrider
Assignee: Brian Fox
Fix For: 2.2
Attachments: build-classpath.patch
The generated classpath should be what maven produces, but appears to be in
some other order when the following configuration is used for both version
2.0 and today's (Dec 12, 2008) latest trunk:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idclasspathUnix/id
phasegenerate-sources/phase
goals
goalbuild-classpath/goal
/goals
configuration
pathSeparator:/pathSeparator
prefix${project.artifactId}/prefix
outputFile${project.build.directory}/${project.artifactId}-unix.classpath/outputFile
/configuration
/execution
/executions
/plugin
--
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-284) Get Mojo ignores the transitive attribute because of a typo in the parameter declaration
[
http://jira.codehaus.org/browse/MDEP-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-284:
---
Attachment: mdep-284.patch
Updated patch, but the tests keep failing for me. Moving to the next patch for
now.
Get Mojo ignores the transitive attribute because of a typo in the parameter
declaration
Key: MDEP-284
URL: http://jira.codehaus.org/browse/MDEP-284
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Baptiste MATHUS
Assignee: Brian Fox
Attachments: maven-dependency-get-transitive.patch, mdep-284.patch
[Note : get is missing as a component for MDEP jira.]
Due to a typo in the GetMojo code, transitive resolution doesn't work.
@parameter was set to {$transitive} instead of ${transitive}.
Thanks a lot.
PS : I tried providing the corresponding ITs, but didn't really manage to
cope with configuring the (stub) environment. I'm providing the unfinished
code anyway, since I think it might be missing not much. Feel free to wipe
all ITs I tried to initiate if it's simpler. I think I'll have a look at how
you do it, if you find time for that.
--
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: (WAGON-295) Provide more debug information in wagon (http request/response/headers)
[ http://jira.codehaus.org/browse/WAGON-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated WAGON-295: -- Fix Version/s: (was: 1.0-beta-7) 1.0-beta-8 Provide more debug information in wagon (http request/response/headers) --- Key: WAGON-295 URL: http://jira.codehaus.org/browse/WAGON-295 Project: Maven Wagon Issue Type: Improvement Reporter: Olivier Lamy Fix For: 1.0-beta-8 Is there any way to have more debug information concerning wagon with the option -e -X ? Like commons-httpclient does : - http requests - http response - http headers Thanks, - Olivier -- 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: (WAGON-312) Cannot download folders with spaces via SCP
[ http://jira.codehaus.org/browse/WAGON-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated WAGON-312: -- Fix Version/s: (was: 1.0-beta-7) 1.0-beta-8 Cannot download folders with spaces via SCP --- Key: WAGON-312 URL: http://jira.codehaus.org/browse/WAGON-312 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh Affects Versions: 1.0-beta-6 Reporter: Lóránt Pintér Assignee: Olivier Lamy Fix For: 1.0-beta-8 Attachments: wagon-scp-spaces-2.patch, wagon-scp-spaces.patch Downloading files via SCP fails when some folder names contain spaces. The problem is caused by paths not being properly escaped when executing commands. See attached patch for a primitive fix -- this fixes the problem in most cases, but proper escaping would be more welcome. -- 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: (WAGON-314) Permament move (error 301) not handled properly by Lightweight HTTP Wagon
[ http://jira.codehaus.org/browse/WAGON-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=242173#action_242173 ] Dennis Lundberg commented on WAGON-314: --- I tried to apply Stephen's patch to wagon trunk, but it fails to apply. Is there any chance that you could update the patch so that it applies cleanly to trunk? Permament move (error 301) not handled properly by Lightweight HTTP Wagon - Key: WAGON-314 URL: http://jira.codehaus.org/browse/WAGON-314 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-6 Reporter: Grzegorz Slowikowski Priority: Minor Fix For: 1.0-beta-8 Attachments: mng-4428.patch Artifact cannot be downloaded by http-lightweight-wagon used (as default) in all Maven versions except 2.2.0, which uses http-wagon by default. Instead of pom and jar files html files appear in the local repo with content like: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title301 Moved Permanently/title /headbody h1Moved Permanently/h1 pThe document has moved a href=http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom;here/a./p hr addressApache Server at maven2-repository.dev.java.net Port 443/address /body/html Only Maven 2.2.0 handles 301 properly. By the way, I haven't expected such Apache configuration (permament move) in central Maven repo. As you can see this is not handled properly by almost all versions of Maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-525) Ant Tokens can now be multi-line when filtering - regression from 2.2-beta-5
Ant Tokens can now be multi-line when filtering - regression from 2.2-beta-5
Key: MASSEMBLY-525
URL: http://jira.codehaus.org/browse/MASSEMBLY-525
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Ryan Lea
Attachments: assembly-filter-test.zip
I've looked through existing issues and cannot find anything similar.
In 2.2-beta-5 I was able to specify in scripts
{code}
@echo off
java ${project.build.finalName}.jar
{code}
with filtering turned on for the final name. However, 2.2 appears to have
allowed for ant tokens '@' to be carried over multiple lines. I don't think
this is expected behaviour.
I've attached a small test project with two files to demonstrate the case.
--
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
