[jira] Updated: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] nicolas de loof updated MRM-153: Attachment: MRM-155.patch Repackaged patch to include testcase. adds "testLegacyRequestConvertedToMaven2PathInManagedRepo" to ProxyRequestHandlerTest. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (MPA-49) consider IRC logging again
[ http://jira.codehaus.org/browse/MPA-49?page=comments#action_73764 ] Emmanuel Venisse commented on MPA-49: - http://dev.rectang.com/logs/codehaus/%23maven/ > consider IRC logging again > -- > > Key: MPA-49 > URL: http://jira.codehaus.org/browse/MPA-49 > Project: Maven Project Administration > Issue Type: Task >Reporter: Brett Porter > Assigned To: Jason van Zyl > Fix For: 2006-q3 > > > I wonder if it is a good idea to reconsider running logging on the #maven IRC > channel as an extra source of finding answers to questions? > Installing something like this: http://humdi.net/ircstats/ would also be > interesting. -- 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: (MRM-154) DigestUtils fails to verify checksum from ibiblio
[ http://jira.codehaus.org/browse/MRM-154?page=all ]
nicolas de loof updated MRM-154:
Attachment: MRM-154.patch
Rapackaged patch (from archiva-utils root), including testcase
> DigestUtils fails to verify checksum from ibiblio
> -
>
> Key: MRM-154
> URL: http://jira.codehaus.org/browse/MRM-154
> Project: Archiva
> Issue Type: Bug
>Reporter: nicolas de loof
> Attachments: DigestUtils.java.patch, MRM-154.patch
>
>
> Downloading servletapi-24.pom fails.
> DigestUtils.cleanChecksum check for filename in remote checksum file to be
> same as local, but tets is inverted :
> String filename = m.group( 2 );
> if ( !path.endsWith( filename ) )
> {
> throw new DigesterException( "Supplied checksum does not
> match checksum pattern" );
> }
> filename =
> "/home/projects/maven/repository-staging/to-ibiblio/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom"
> path = "servletapi-2.4.pom".
> Patch provided to test if ( !path.endsWith( filename ) )
--
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: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=comments#action_73766 ] nicolas de loof commented on MRM-153: - Please don't mind my patch name is "MRM-155" as it is a typo. This patch file IS related to MRM-153 > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=all ] nicolas de loof updated MRM-155: Attachment: MRM-155.patch Repackaged patch to include testcase. adds "testLegacyRequestConvertedToMaven2PathInManagedRepo" to ProxyRequestHandlerTest. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch, > MRM-155.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (SCM-219) broken link online documentation
[ http://jira.codehaus.org/browse/SCM-219?page=comments#action_73768 ] Bernhard Wellhöfer commented on SCM-219: I herbey kindly ask to fix this bug. The whole maven documentation is not in a good shape and this is one example. I really have problems to convince my colleagues that we should switch to maven when such an easy fix just does not happen. > broken link online documentation > > > Key: SCM-219 > URL: http://jira.codehaus.org/browse/SCM-219 > Project: Maven SCM > Issue Type: Bug > Components: documentation >Reporter: Valerio Schiavoni > > There's a broken link to the scm plugin documentation, reachable from: > http://maven.apache.org/plugins/index.html > scm > Subversion (from left menu > the broken link is: http://maven.apache.org/scm/plugins/subversion.html > it should be: http://maven.apache.org/scm/subversion.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] Commented: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=comments#action_73769 ] nicolas de loof commented on MRM-153: - I realy have troubles with numbers. Please don't care this patch that IS for MRM-155 and has been also attached to MRM-155 issue. I'll provide a patch for MRM-153 (this one) latter. Sory for noise... > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (MNGECLIPSE-169) Offline is ignored
[ http://jira.codehaus.org/browse/MNGECLIPSE-169?page=comments#action_73771 ] Robert Herschke commented on MNGECLIPSE-169: The offline mode has no effect in: - building - update source folder - resolve dependencies > Offline is ignored > -- > > Key: MNGECLIPSE-169 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-169 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 >Reporter: Robert Herschke > > If the checkbox "Offline" in Maven2 Settings under Eclipse Preferences is > set, it has no effect. -- 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: (MDEPLOY-38) deploy:deploy-file fails silently on Windows URL containing invalid host name or share
[ http://jira.codehaus.org/browse/MDEPLOY-38?page=comments#action_73772 ] Pierre-Arnaud commented on MDEPLOY-38: -- if your windows share is \\host\share, a working URL would be file:///\\host/share (i.e. the windows share is resolved from your localhost) > deploy:deploy-file fails silently on Windows URL containing invalid host name > or share > -- > > Key: MDEPLOY-38 > URL: http://jira.codehaus.org/browse/MDEPLOY-38 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Windows >Reporter: Maarten Brugman >Priority: Minor > > When using goal deploy:deploy-file, and a Windows URL is used of the form > "file://host/share/" containing an invalid host name or share, maven > reports XXX K uploaded and BUILD SUCCESSFUL. > NOTE: if a URL of the form "file://\\nonexistenthost\share\..." is used, the > command fails as expected. However, as soon as one backslash after "share" is > replaced by a frontslash, the goal fails silently (i.e. reports success). > Example of silent failure: > mvn deploy:deploy-file -Detc > -Durl=file://nonexistenthost/share/Maven-repository > --> output: > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file://nonexistenthost/share/Maven-repository/javax/faces/jsf-impl/1.1/jsf-impl-1.1.jar > 673K uploaded > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading repository metadata for: 'artifact javax.faces:jsf-impl' > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading project information for jsf-impl 1.1 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Jul 25 16:47:00 CEST 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- 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: (MPSCM-86) scm:prepare-release does not commit modified changes.xml
[ http://jira.codehaus.org/browse/MPSCM-86?page=comments#action_73773 ] Arnaud Heritier commented on MPSCM-86: -- No but I didn't notice it when I released maven and its plugins > scm:prepare-release does not commit modified changes.xml > > > Key: MPSCM-86 > URL: http://jira.codehaus.org/browse/MPSCM-86 > Project: maven-scm-plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Windows 2000 >Reporter: Chuck Daniels >Priority: Minor > > The scm:prepare-release goal does not commit the change it makes to > changes.xml. However, it does properly put the modified changes.xml file into > the new tag and it does commit the changes to project.xml. > This requires a manual commit to changes.xml after running > scm:prepare-release. Is this the intention? -- 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: (MAVEN-1786) Performance Optimization of the Reactor
Performance Optimization of the Reactor --- Key: MAVEN-1786 URL: http://jira.codehaus.org/browse/MAVEN-1786 Project: Maven Issue Type: Improvement Affects Versions: 1.1-beta-2 Environment: OS windows xp, JVM sun 1.4.2 Reporter: Emmanuel Renaud Attachments: Goal.java, reactor-jprofiler.GIF The Goal.checkForCycle method is a hotspot as the reactor starts. Most of the time is spent in creating HashSets and filling them (see attached screen shot). Instead of creating a new HasSet each time, reusing the same improves the performance of dependency analysis (see attached file Goal.java). Due to security policy in my company I can't checkout the sources and run non-regression tests, at least it works fine on our project. -- 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: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] nicolas de loof updated MRM-153: Attachment: MRM-153.patch This patch moves the relocation handling in DefaultProxyRequestHandler (archiva-proxy). No more change on archiva-core is required. Testcase is included for artecfact + checksum relocation on maven1 request. This patch requires some logic change on the DefaultProxyRequestHandler.get() : Artifact layout is discovered BEFORE proxies are used to get the file. This require to handle checksums, metadata and unknown file before requesting proxied repositories. I moved metadata and unknown files handling in a dedicated method to clarify code. Please note this patch includes correction for issue MRM-155 as managed repository path is build during artifact discovery, so my patch for MRM-155 gets obsolete if this patch is applied. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-153.patch, > MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (CONTINUUM-831) Continuum Release white site pages
[ http://jira.codehaus.org/browse/CONTINUUM-831?page=comments#action_73775 ] Brett Porter commented on CONTINUUM-831: is the final of this committed to yur branch now? > Continuum Release white site pages > -- > > Key: CONTINUUM-831 > URL: http://jira.codehaus.org/browse/CONTINUUM-831 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Attachments: CONTINUUM-831-continuum-uml.patch > > -- 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: (MNGECLIPSE-192) Exit code 1 - 'ssh' is not recognized as an internal or external command,
[ http://jira.codehaus.org/browse/MNGECLIPSE-192?page=all ] Klingon Coder updated MNGECLIPSE-192: - Attachment: settings.xml this is the settings.xml. please view the settings for the servers > Exit code 1 - 'ssh' is not recognized as an internal or external command, > - > > Key: MNGECLIPSE-192 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-192 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher >Affects Versions: 0.0.9 > Environment: WIN XP SP2. Eclipse 3.2 Maven eclipse extension 0.0.9 >Reporter: Klingon Coder > Attachments: settings.xml > > > [INFO] > > [INFO] Building Dimensions Auto Build Application > [INFO]task-segment: [deploy] > [INFO] > > [INFO] plugin:descriptor > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 2 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > [INFO] Nothing to compile - all classes are up to date > [INFO] resources:testResources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:testCompile > [INFO] No sources to compile > [INFO] surefire:test > [INFO] No tests to run. > [INFO] jar:jar > [INFO] Building jar: > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > [INFO] plugin:addPluginArtifactMetadata > [INFO] install:install > [INFO] Installing > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > to C:\Documents and > Settings\user\.m2\repository\com\AutoBuild\dimensions-maven-plugin\1.0\dimensions-maven-plugin-1.0.jar > [INFO] plugin:updateRegistry > [INFO] deploy:deploy > [ERROR] mojo-execute : deploy:deploy > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : > com.AutoBuild:dimensions-maven-plugin:maven-plugin:1.0 ( task-segment: > [deploy] ) > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:145) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 8 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error executing command for transfer > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:133) > ... 10 more > Caused by: org.apache.maven.wagon.TransferFailedException: Error executing > command for transfer > at > org.apache.maven.wagon.providers.sshext.ScpExternalWagon.put(ScpExternalWagon.java:342) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(
[jira] Updated: (MNGECLIPSE-192) Exit code 1 - 'ssh' is not recognized as an internal or external command,
[ http://jira.codehaus.org/browse/MNGECLIPSE-192?page=all ] Klingon Coder updated MNGECLIPSE-192: - Attachment: pom.xml > Exit code 1 - 'ssh' is not recognized as an internal or external command, > - > > Key: MNGECLIPSE-192 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-192 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher >Affects Versions: 0.0.9 > Environment: WIN XP SP2. Eclipse 3.2 Maven eclipse extension 0.0.9 >Reporter: Klingon Coder > Attachments: pom.xml, settings.xml > > > [INFO] > > [INFO] Building Dimensions Auto Build Application > [INFO]task-segment: [deploy] > [INFO] > > [INFO] plugin:descriptor > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 2 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > [INFO] Nothing to compile - all classes are up to date > [INFO] resources:testResources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:testCompile > [INFO] No sources to compile > [INFO] surefire:test > [INFO] No tests to run. > [INFO] jar:jar > [INFO] Building jar: > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > [INFO] plugin:addPluginArtifactMetadata > [INFO] install:install > [INFO] Installing > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > to C:\Documents and > Settings\user\.m2\repository\com\AutoBuild\dimensions-maven-plugin\1.0\dimensions-maven-plugin-1.0.jar > [INFO] plugin:updateRegistry > [INFO] deploy:deploy > [ERROR] mojo-execute : deploy:deploy > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : > com.AutoBuild:dimensions-maven-plugin:maven-plugin:1.0 ( task-segment: > [deploy] ) > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:145) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 8 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error executing command for transfer > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:133) > ... 10 more > Caused by: org.apache.maven.wagon.TransferFailedException: Error executing > command for transfer > at > org.apache.maven.wagon.providers.sshext.ScpExternalWagon.put(ScpExternalWagon.java:342) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:77) > ... 11 more > Caused by
[jira] Updated: (MNGECLIPSE-192) Exit code 1 - 'ssh' is not recognized as an internal or external command,
[ http://jira.codehaus.org/browse/MNGECLIPSE-192?page=all ] Klingon Coder updated MNGECLIPSE-192: - Attachment: SampleMojo.java this is a sample mojo > Exit code 1 - 'ssh' is not recognized as an internal or external command, > - > > Key: MNGECLIPSE-192 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-192 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher >Affects Versions: 0.0.9 > Environment: WIN XP SP2. Eclipse 3.2 Maven eclipse extension 0.0.9 >Reporter: Klingon Coder > Attachments: pom.xml, SampleMojo.java, settings.xml > > > [INFO] > > [INFO] Building Dimensions Auto Build Application > [INFO]task-segment: [deploy] > [INFO] > > [INFO] plugin:descriptor > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 2 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > [INFO] Nothing to compile - all classes are up to date > [INFO] resources:testResources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:testCompile > [INFO] No sources to compile > [INFO] surefire:test > [INFO] No tests to run. > [INFO] jar:jar > [INFO] Building jar: > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > [INFO] plugin:addPluginArtifactMetadata > [INFO] install:install > [INFO] Installing > C:\workspace\dimensions-maven-plugin\target\dimensions-maven-plugin-1.0.jar > to C:\Documents and > Settings\user\.m2\repository\com\AutoBuild\dimensions-maven-plugin\1.0\dimensions-maven-plugin-1.0.jar > [INFO] plugin:updateRegistry > [INFO] deploy:deploy > [ERROR] mojo-execute : deploy:deploy > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : > com.AutoBuild:dimensions-maven-plugin:maven-plugin:1.0 ( task-segment: > [deploy] ) > Diagnosis: Error deploying artifact: Error executing command for transfer > FATAL ERROR: Error executing Maven for a project > org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying > artifact: Error executing command for transfer > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:145) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 8 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error deploying artifact: Error executing command for transfer > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:91) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:133) > ... 10 more > Caused by: org.apache.maven.wagon.TransferFailedException: Error executing > command for transfer > at > org.apache.maven.wagon.providers.sshext.ScpExternalWagon.put(ScpExternalWagon.java:342) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:180) > at > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:109) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactD
[jira] Commented: (MDEPLOY-38) deploy:deploy-file fails silently on Windows URL containing invalid host name or share
[ http://jira.codehaus.org/browse/MDEPLOY-38?page=comments#action_73778 ] Maarten Brugman commented on MDEPLOY-38: Yes, I know, and I got it working. My point is that anything between the first // and / is assumed to be 'localhost' and thus ignored, even if it contains backslashes. See the example in my previous comment above. That results in behavior I did not expect. Also, if there is no / after the //, but only backslashes (e.g. file://\\host\share\repo), it works. I see several changes that could make the behavior clearer: - if there is anything between // and /, fail - if there is anything between // and /, show a warning that this will be ignored - explain the behavior in the documentation My 2 cents, I hope you agree and then find the time to do something with it. I appreciate the work you have done so far on this module. > deploy:deploy-file fails silently on Windows URL containing invalid host name > or share > -- > > Key: MDEPLOY-38 > URL: http://jira.codehaus.org/browse/MDEPLOY-38 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Windows >Reporter: Maarten Brugman >Priority: Minor > > When using goal deploy:deploy-file, and a Windows URL is used of the form > "file://host/share/" containing an invalid host name or share, maven > reports XXX K uploaded and BUILD SUCCESSFUL. > NOTE: if a URL of the form "file://\\nonexistenthost\share\..." is used, the > command fails as expected. However, as soon as one backslash after "share" is > replaced by a frontslash, the goal fails silently (i.e. reports success). > Example of silent failure: > mvn deploy:deploy-file -Detc > -Durl=file://nonexistenthost/share/Maven-repository > --> output: > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file://nonexistenthost/share/Maven-repository/javax/faces/jsf-impl/1.1/jsf-impl-1.1.jar > 673K uploaded > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading repository metadata for: 'artifact javax.faces:jsf-impl' > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading project information for jsf-impl 1.1 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Jul 25 16:47:00 CEST 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- 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: (CONTINUUM-831) Continuum Release white site pages
[ http://jira.codehaus.org/browse/CONTINUUM-831?page=comments#action_73782 ] Edwin Punzalan commented on CONTINUUM-831: -- I've just committed it in the release-integration branch. NOTE: Attached patch in this jira is not updated. > Continuum Release white site pages > -- > > Key: CONTINUUM-831 > URL: http://jira.codehaus.org/browse/CONTINUUM-831 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Attachments: CONTINUUM-831-continuum-uml.patch > > -- 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: (MSUREFIREREP-27) number of skipped test no shown in html report
[ http://jira.codehaus.org/browse/MSUREFIREREP-27?page=comments#action_73784 ] Wim Deblauwe commented on MSUREFIREREP-27: -- TestNG has this feature too, so it would be nice to have that also. > number of skipped test no shown in html report > -- > > Key: MSUREFIREREP-27 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-27 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug >Reporter: Bernd > > JUnit4 support skipping of tests (@Ignore). Even if they are in the xml > report, e.g. " failures="1"" they do not show up in the html report -- 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-1106) Upload freemarker-2.3.8
Upload freemarker-2.3.8 --- Key: MAVENUPLOAD-1106 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1106 Project: maven-upload-requests Issue Type: Wish Reporter: Andreas Schödl Please upload freemarker-2.3.8.jar License, URL and Dependencies are in the uploaded POM. -- 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: (MEV-439) pom for stax:stax-api:1.0.1
pom for stax:stax-api:1.0.1 --- Key: MEV-439 URL: http://jira.codehaus.org/browse/MEV-439 Project: Maven Evangelism Issue Type: Bug Components: Missing POM Reporter: Tim O'Brien This artifact is missing a POM -- 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: (MEV-439) pom for stax:stax-api:1.0.1
[ http://jira.codehaus.org/browse/MEV-439?page=all ] Tim O'Brien updated MEV-439: Attachment: stax-api-1.0.1.pom Here is a working pom for stax:stax-api:1.0.1 > pom for stax:stax-api:1.0.1 > --- > > Key: MEV-439 > URL: http://jira.codehaus.org/browse/MEV-439 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Tim O'Brien > Attachments: stax-api-1.0.1.pom > > > This artifact is missing a POM -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2542) Remove carriage returns and tabs from field values in the manifest file
Remove carriage returns and tabs from field values in the manifest file --- Key: MNG-2542 URL: http://jira.codehaus.org/browse/MNG-2542 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Reporter: Tim O'Brien When creating a JAR Manfiest, maven needs to remove CR and Tabs from the description taken from the POM. This is a critical issue with JAR files created from Maven. The issue is that Maven can create a MANIFEST file for a JAR, but it creates an invalid manifest if you jsut happen to have a description in your POM like thi: this is an library for idiots The issue is that your description element has new line characters and thejar plugin just take those new line characters and blindly copies them into the Manfiest, creating an invalid Manifest. This doesn't show up until you try to use the JAR in another application. Then you get a very cryptic error message about having an invalid jar. This used to be 1247 but it was closed and marked as Won't Fix with no explanation as to why it isn't worth fixing. -- 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-2542) Remove carriage returns and tabs from field values in the manifest file
[ http://jira.codehaus.org/browse/MNG-2542?page=comments#action_73790 ] Brett Porter commented on MNG-2542: --- I think it was won't fixed because the bug was opened in plexus-archiver, but unfortunately wasn't linked. I'm certain this is either fixed or filed somewhere else, but I'll leave this open for verification. > Remove carriage returns and tabs from field values in the manifest file > --- > > Key: MNG-2542 > URL: http://jira.codehaus.org/browse/MNG-2542 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Tim O'Brien > > When creating a JAR Manfiest, maven needs to remove CR and Tabs from the > description taken from the POM. > This is a critical issue with JAR files created from Maven. The issue is > that Maven can create a MANIFEST file for a JAR, but it creates an invalid > manifest if you jsut happen to have a description in your POM like thi: > > this is an library for idiots > > The issue is that your description element has new line characters and thejar > plugin just take those new line characters and blindly copies them into the > Manfiest, creating an invalid Manifest. This doesn't show up until you try > to use the JAR in another application. Then you get a very cryptic error > message about having an invalid jar. > This used to be 1247 but it was closed and marked as Won't Fix with no > explanation as to why it isn't worth fixing. -- 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: (MSUREFIRE-134) Surefire finds test classes but ignores test methods and configuration methods with TestNG and includes tag
[ http://jira.codehaus.org/browse/MSUREFIRE-134?page=all ] fabrizio giustina closed MSUREFIRE-134. --- Resolution: Fixed patches committed to surefire and maven-surefire-plugin, thanks! > Surefire finds test classes but ignores test methods and configuration > methods with TestNG and includes tag > --- > > Key: MSUREFIRE-134 > URL: http://jira.codehaus.org/browse/MSUREFIRE-134 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Maven 2.0.4 > Surefire Plugin 2.2 > TestNG 4.7 jdk15 (using annotations) > Sun JDK 1.5_06 > Windows XP SP 2 >Reporter: Mark Reynolds > Assigned To: fabrizio giustina > Fix For: 2.3 > > Attachments: maven-surefire-plugin-patch.txt, maven2-testng.zip, > surefire-patch.txt > > > Attachment contains 2 projects which are identical except for how the test > cases are referenced. In one project they are referenced via a suite xml > file. In the second they are referenced using the includes tag. I believe > they should produce identical results. > Both projects find all 6 test classes, but only the one using a suite xml > file actually executes the configuration methods and test methods. The > project using an includes tag completely ignores the configuratiion methods > and test methods. -- 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-153) Multiproject CVS uncommitted changes not checked
Multiproject CVS uncommitted changes not checked Key: MRELEASE-153 URL: http://jira.codehaus.org/browse/MRELEASE-153 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Parolini Antonio When using the "release plugin" on a flat multi-project struture, the plugin dosen't check uncommitted changes with CVS, and perfome the release. The module section of the master pom.xml: ../ejb ../web http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-153) Multiproject CVS uncommitted changes not checked
[ http://jira.codehaus.org/browse/MRELEASE-153?page=comments#action_73793 ] Parolini Antonio commented on MRELEASE-153: --- I meant: dosen't check uncommitted changes for sub-modules. > Multiproject CVS uncommitted changes not checked > > > Key: MRELEASE-153 > URL: http://jira.codehaus.org/browse/MRELEASE-153 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Parolini Antonio > > When using the "release plugin" on a flat multi-project struture, the plugin > dosen't check uncommitted changes with CVS, and perfome the release. > The module section of the master pom.xml: > > ../ejb > ../web > Maybe this is related to MRELEASE-6. -- 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: (SUREFIRE-49) Surefire leaves null/$TestNGGroupName directories after mvn test
[ http://jira.codehaus.org/browse/SUREFIRE-49?page=all ] fabrizio giustina closed SUREFIRE-49. - Assignee: fabrizio giustina Resolution: Fixed looks like a TestNG bug, see http://jira.opensymphony.com/browse/TESTNG-107 At the moment fixed with a workaround (output redirected to java.io.tmpdir) > Surefire leaves null/$TestNGGroupName directories after mvn test > > > Key: SUREFIRE-49 > URL: http://jira.codehaus.org/browse/SUREFIRE-49 > Project: surefire > Issue Type: Bug >Affects Versions: 2.0 > Environment: Wonderland$ java -version > java version "1.5.0_06" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) > Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) > Wonderland$ uname -a > Darwin Wonderland.local 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 > 15:20:53 PDT 2006; > root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh powerpc > Wonderland$ mvn -v > Maven version: 2.0.4 > From Surefire POM: > org.apache.maven.surefire > surefire > pom > SureFire > 2.0 >Reporter: codehauser > Assigned To: fabrizio giustina > Fix For: 2.1 > > > Running mvn test with the following config: > > org.apache.maven.plugins > maven-surefire-plugin > > > src/test/conf/testng.xml > > > > Leaves behind a structure: > Wonderland$ ls > LICENSE.txt null pom.xml src target > Wonderland$ ls -R null > kernel > null/kernel: > Where kernel was the test suite name defined in the testng.xml file. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] fabrizio giustina updated SUREFIRE-31: -- Component/s: Junit 4.x support > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2543) dependencies ant task does not handle scoped transitive dependencies correctly
dependencies ant task does not handle scoped transitive dependencies correctly -- Key: MNG-2543 URL: http://jira.codehaus.org/browse/MNG-2543 Project: Maven 2 Issue Type: Bug Components: Ant tasks Affects Versions: 2.0.4 Environment: Windows XP, Java 1.5.0_08-b03, Ant 1.6.5, Maven 2.0.4 Reporter: Rick Riemer The ant task resolves transitive dependencies incorrectly if they're included in different scopes. Here's an example: [dependencies section of pom.xml for project A] ... log4j log4j 1.2.13 ... [dependencies section of pom.xml for project B] ... my-company project-A 1.0-SNAPSHOT test log4j log4j 1.2.13 commons-lang commons-lang 2.1 ... [dependencies section of pom.xml for project C] ... my-company project-B 1.0-SNAPSHOT ... When I use the task to build a "compile"-scope classpath for project B everything is OK: -- gives -- \.m2\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar \.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar But when I use the same task to build a "compile"-scope classpath for project C, log4j goes missing: -- gives -- \.m2\repository\nl\forcare\common\1.0-SNAPSHOT\common-1.0-SNAPSHOT.jar \.m2\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar I think that that log4j is filtered, because project A is only included in test scope, regardless of log4j also being present in project B. If I use the mvn executable itself to run a compile instead of the ant tasks, then there is no problem and log4j appears on the compile classpath. It seems that the ant tasks have a different mechanism of resolving dependencies than the mvn executable. -- 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: (MEJB-19) clientExclude(s) does not work
[ http://jira.codehaus.org/browse/MEJB-19?page=comments#action_73805 ] Mike R. Haller commented on MEJB-19: Seems to be fixed in 2.1-SNAPSHOT. > clientExclude(s) does not work > -- > > Key: MEJB-19 > URL: http://jira.codehaus.org/browse/MEJB-19 > Project: Maven 2.x Ejb Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven 2.0.4 >Reporter: Stefan Seidel > > I've tried each and every configuration of and > to control what is being put into the ejb-client JAR, but > nothing really works. I expect the configuration > > ** > > to produce an empty JAR - but it doesn't. > What I really need to do is to exclude ejb-jar.xml and jboss.xml from the > client jar because JBoss 4 will still (try to) deploy the JAR file because > these XMLs are in it, even if it is given as java module in the > application.xml. Leaving these files there leads the whole idea of a client > JAR ad adsurdum. -- 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: (MSUREFIREREP-28) Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA
Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA -- Key: MSUREFIREREP-28 URL: http://jira.codehaus.org/browse/MSUREFIREREP-28 Project: Maven 2.x Surefire report Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Christophe DENEUX I have a maven project with a POM packaging in which I run test with the maven-surefire-plugin. All works fine, but I am not able to generate the surefire report. After investigations in the source code of the maven-surefire-report-plugin, it seems to me that the implementation of the method SurefireReportMojo.canGenerateReport is not correct. The condition is too restrictive. It seems to me that the condition should be something like "Does a surefire execution report exist?". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2544) dependencies ant task incorrectly handles transitive snapshot dependencies
dependencies ant task incorrectly handles transitive snapshot dependencies -- Key: MNG-2544 URL: http://jira.codehaus.org/browse/MNG-2544 Project: Maven 2 Issue Type: Bug Components: Ant tasks Affects Versions: 2.0.4 Environment: Windows XP, Java 1.5.0_08-b03, Ant 1.6.5, Maven 2.0.4 Reporter: Rick Riemer This issue may be related to MNG-2543. The ant task resolves transitive SNAPSHOT dependencies incorrectly. Here's an example: [dependencies section of pom.xml for project A] ... hapi hapi 0.5beta-SNAPSHOT ... [dependencies section of pom.xml for project B] ... my-company project-A 1.0-SNAPSHOT ... When I use the task to build a classpath for project A everything is OK: - gives - \.m2\repository\hapi\hapi\0.5beta-SNAPSHOT\hapi-0.5beta-SNAPSHOT.jar But when I use the same task to build a classpath for project B, the version numbering goes bad: - gives - \.m2\repository\hapi\hapi\0.5beta-20060814.11-1\hapi-0.5beta-20060814.11-1.jar The files in my repository are: \.m2\repository\hapi\hapi\0.5beta-SNAPSHOT\hapi-0.5beta-20060814.11-1.jar \.m2\repository\hapi\hapi\0.5beta-SNAPSHOT\hapi-0.5beta-SNAPSHOT.jar For some reason, the task uses the expanded artifact name for the folder as well, but the folder name should use SNAPSHOT. If I use the mvn executable itself to run a compile instead of the ant tasks, then there is no problem and the jar is correctly resolved. It seems that the ant tasks have a different mechanism of resolving transitive dependencies than the mvn executable. -- 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: (MSUREFIREREP-28) Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA
[ http://jira.codehaus.org/browse/MSUREFIREREP-28?page=all ] Christophe DENEUX updated MSUREFIREREP-28: -- Attachment: MSUREFIREREP-28.patch A patch that change the condition as explain in the bug description. > Unable to generate the surefire report if the project is not a java project, > but tests are written in JAVA > -- > > Key: MSUREFIREREP-28 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-28 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Christophe DENEUX > Attachments: MSUREFIREREP-28.patch > > > I have a maven project with a POM packaging in which I run test with the > maven-surefire-plugin. All works fine, but I am not able to generate the > surefire report. > After investigations in the source code of the maven-surefire-report-plugin, > it seems to me that the implementation of the method > SurefireReportMojo.canGenerateReport is not correct. The condition is too > restrictive. It seems to me that the condition should be something like "Does > a surefire execution report exist?". -- 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-2118) Listing central repo in pluginRepositories confuses Maven
[ http://jira.codehaus.org/browse/MNG-2118?page=comments#action_73807 ]
Gareth Moorst commented on MNG-2118:
I have the same problem - in a project which has the central repository
redefined to point to an internal maven-proxy server, a clean install of maven
does not download all the artifacts required to make the clean goal work.
In another project which does not redefine the central repository, mvn clean
worked fine.
This is holding back our adoption of Maven - we need to be able to redefine the
central server, as most of our developers have no direct access to the internet.
> Listing central repo in pluginRepositories confuses Maven
> -
>
> Key: MNG-2118
> URL: http://jira.codehaus.org/browse/MNG-2118
> Project: Maven 2
> Issue Type: Bug
> Components: POM, Plugins and Lifecycle
>Affects Versions: 2.0.2
>Reporter: Jason Dillon
>Priority: Critical
> Fix For: 2.1
>
>
> It appears that if you list the central repository in the pluginRepositories,
> that it may cause Maven to incorrectly check the central repository for
> plugin data.
> Specifically, I found this when using the maven-clean-plugin 2.1. I did not
> have this plugin in my local repository, and when running {{mvn clean}} it
> causes the build to fail:
> {noformat}
> + Error stacktraces are turned on.
> [DEBUG] Building Maven user-level plugin registry from:
> '/Users/jason/.m2/plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from:
> '/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/conf/plugin-registry.xml'
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Paycore
> [INFO] Paycore :: Merchant
> [INFO] Paycore :: Merchant :: Core
> [INFO] Paycore :: Merchant :: Services
> [INFO]
>
> [INFO] Building Paycore
> [INFO]task-segment: [clean]
> [INFO]
>
> [DEBUG] maven-clean-plugin: resolved to version 2.1 from repository
> maven-snapshots
> [DEBUG] Trying repository maven-snapshots
> Downloading:
> http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.pom
> [DEBUG] Artifact not found - using stub model: Unable to locate resource in
> repository
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> maven-snapshots (http://snapshots.maven.codehaus.org/maven2),
> paybytouch-legacy (http://repository.paybytouch.com/m1/repository)
> [DEBUG] Using defaults for missing POM
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-SNAPSHOT from
> repository maven-snapshots
> [DEBUG] maven-surefire-plugin: resolved to version 2.1.3-20060228.012944-10
> from repository maven-snapshots
> [DEBUG] Retrieving parent-POM from the repository for project:
> null:maven-surefire-plugin:maven-plugin:2.1.3-20060228.012944-10
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] maven-one-plugin: resolved to version 1.0-20060213.011019-4 from
> repository maven-snapshots
> [DEBUG] org.apache.maven.plugins:maven-clean-plugin:maven-plugin:2.1
> (selected for runtime)
> -
> this realm = app0.child-container[org.apache.maven.plugins:maven-clean-plugin]
> urls[0] =
> file:/Users/jason/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.1/maven-clean-plugin-2.1.jar
> Number of imports: 0
> this realm = plexus.core.maven
> urls[0] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/commons-cli-1.0.jar
> urls[1] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/doxia-sink-api-1.0-alpha-7.jar
> urls[2] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/jsch-0.1.24.jar
> urls[3] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-2.0.2.jar
> urls[4] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-artifact-manager-2.0.2.jar
> urls[5] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2-javadoc.jar
> urls[6] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-core-2.0.2.jar
> urls[7] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-error-diagnostics-2.0.2.jar
> urls[8] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-model-2.0.2.jar
> urls[9] =
> file:/Users/jason/ws/paybytouch/dev/paycore/main/tools/maven/lib/maven-monitor-2.0.2.jar
> urls[10] =
> file:/Users/jason/ws/paybytou
[jira] Commented: (MEV-439) pom for stax:stax-api:1.0.1
[ http://jira.codehaus.org/browse/MEV-439?page=comments#action_73808 ] Carlos Sanchez commented on MEV-439: There's missing info: license, url, description,... > pom for stax:stax-api:1.0.1 > --- > > Key: MEV-439 > URL: http://jira.codehaus.org/browse/MEV-439 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Tim O'Brien > Attachments: stax-api-1.0.1.pom > > > This artifact is missing a POM -- 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-1545) some execution output not routed through default routes.
[ http://jira.codehaus.org/browse/MNG-1545?page=comments#action_73811 ] Milos Kleint commented on MNG-1545: --- After some more work I think I got it working for netbeans correctly. The StreamPumper not printing was a Netbeans/Mevenide classpath issue. Now I have a multiplexing stdout/stderr implementation that is capable of sending the System.out and System.err to the correct output window pane. not sure if we can consider the issue fix as the texts are not routed thought the loggers but System.out. > some execution output not routed through default routes. > > > Key: MNG-1545 > URL: http://jira.codehaus.org/browse/MNG-1545 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Milos Kleint >Priority: Critical > Fix For: 2.0.5 > > > when running embedded maven I create an instance of EventMonitor, > TransferListener and MavenEmbedderLogger. > however there's still some output that is not received through these means, > but rather printoed to standard output (I suppose) > that's wrong because it prohibits custom handling of output. > one example that I found is the surefire plugin's output.. everything > prepended with [surefire] is printed out wrongly.. -- 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: (WAGONSSH-52) scpexe won't honour .ssh/config information
scpexe won't honour .ssh/config information --- Key: WAGONSSH-52 URL: http://jira.codehaus.org/browse/WAGONSSH-52 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-6 Reporter: Michael Semb Wever scp test.xml sch-login01.osl.basefarm.net:/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2/schibstedsok/commons-log4j/1.3-SNAPSHOT/test.xml from the command line works just fine. My local username is mick, and my login on the sch-login01 machine is mickw. Correspondingly my .ssh/config file contains: Host sch-login01.osl.basefarm.net User mickw My pom.xml specifies: scpexe://sch-login01.osl.basefarm.net/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2 But when running "mvn deploy" I get: Uploading: scpexe://sch-login01.osl.basefarm.net/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2/schibstedsok/commons-log4j/1.3-SNAPSHOT/commons-log4j-1.3-20060831.163911-1.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Error executing command for transfer Exit code 255 - Permission denied (publickey,password,keyboard-interactive). -- 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-439) pom for stax:stax-api:1.0.1
[ http://jira.codehaus.org/browse/MEV-439?page=comments#action_73809 ] Tim O'Brien commented on MEV-439: - True, there's lot's of missing stuff, this was copied from the stax-api 1.0 POM. attaching a second version.. > pom for stax:stax-api:1.0.1 > --- > > Key: MEV-439 > URL: http://jira.codehaus.org/browse/MEV-439 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Tim O'Brien > Attachments: stax-api-1.0.1.pom, stax-api-1.0.1.pom > > > This artifact is missing a POM -- 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: (MEV-439) pom for stax:stax-api:1.0.1
[ http://jira.codehaus.org/browse/MEV-439?page=all ] Tim O'Brien updated MEV-439: Attachment: stax-api-1.0.1.pom > pom for stax:stax-api:1.0.1 > --- > > Key: MEV-439 > URL: http://jira.codehaus.org/browse/MEV-439 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Tim O'Brien > Attachments: stax-api-1.0.1.pom, stax-api-1.0.1.pom > > > This artifact is missing a POM -- 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-1107) upload jguard v1.00-beta-1 jars
upload jguard v1.00-beta-1 jars --- Key: MAVENUPLOAD-1107 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1107 Project: maven-upload-requests Issue Type: Task Reporter: charles gay http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-core-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-ext-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-jee-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-struts-example-1.00-beta-1-bundle.jar http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-swing-example-1.00-beta-1-bundle.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] Commented: (WAGONSSH-52) scpexe won't honour .ssh/config information
[ http://jira.codehaus.org/browse/WAGONSSH-52?page=comments#action_73813 ] Michael Semb Wever commented on WAGONSSH-52: When I run mvn deploy -Duser.name=mickw it works. So it appears AuthenticationInfo.getUser() is not giving correct heed to .ssh/config settings. If AuthenticationInfo doesn't yet implement this at all, then why have a default user (from user.name system property) at all. Instead if no user was specified then do not prefix the hostname with "user@" at all. Then the ssh executable will correctly pick up the settings from .ssh/config > scpexe won't honour .ssh/config information > --- > > Key: WAGONSSH-52 > URL: http://jira.codehaus.org/browse/WAGONSSH-52 > Project: wagon-ssh > Issue Type: Bug >Affects Versions: 1.0-alpha-6 >Reporter: Michael Semb Wever > > scp test.xml > sch-login01.osl.basefarm.net:/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2/schibstedsok/commons-log4j/1.3-SNAPSHOT/test.xml > > from the command line works just fine. > My local username is mick, and my login on the sch-login01 machine is mickw. > Correspondingly my .ssh/config file contains: > Host sch-login01.osl.basefarm.net >User mickw > My pom.xml specifies: > > > > scpexe://sch-login01.osl.basefarm.net/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2 > But when running "mvn deploy" I get: > Uploading: > scpexe://sch-login01.osl.basefarm.net/www/schibstedsok/data/httpd/dev.schibstedsok.no_443/htdocs/maven2/schibstedsok/commons-log4j/1.3-SNAPSHOT/commons-log4j-1.3-20060831.163911-1.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Error executing command for transfer > Exit code 255 - Permission denied (publickey,password,keyboard-interactive). -- 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: (MCLEAN-17) Change default=value to default-value in CleanMojo
[ http://jira.codehaus.org/browse/MCLEAN-17?page=all ] Joakim Erdfelt closed MCLEAN-17. Resolution: Fixed Work for this was done by epunzalan on 7/5/2006, revision 419179. > Change default=value to default-value in CleanMojo > -- > > Key: MCLEAN-17 > URL: http://jira.codehaus.org/browse/MCLEAN-17 > Project: Maven 2.x Clean Plugin > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Denis Cabasson >Priority: Trivial > Fix For: 2.1.1 > > Attachments: maven-clean-plugin-dcabasson-MCLEAN17.txt > > Original Estimate: 2 minutes > Remaining Estimate: 2 minutes > > Looks like there is a typo in CleanMojo, default=value should be default-value -- 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: (MCLEAN-5) Replace removeDirectory() and delete by FileUtils.deleteDirectory()
[ http://jira.codehaus.org/browse/MCLEAN-5?page=all ] Joakim Erdfelt closed MCLEAN-5. --- Resolution: Fixed The change from PlexusUtils to maven/shared/file-management/ has fixed this issue. > Replace removeDirectory() and delete by FileUtils.deleteDirectory() > --- > > Key: MCLEAN-5 > URL: http://jira.codehaus.org/browse/MCLEAN-5 > Project: Maven 2.x Clean Plugin > Issue Type: Task >Reporter: Emmanuel Venisse >Priority: Critical > Fix For: 2.1.1 > > > this will depend on a new release of plexus-utils, to add followSymLinks > behavior to FileUtils. Since plexus-utils is filtered out of plugin > dependencies and provided by Maven's core, this issue will also depend on a > new release of Maven that incorporates the changes in plexus-utils. -- 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: (MCLEAN-10) Option to "mvn clean" task not to follow soft links
[ http://jira.codehaus.org/browse/MCLEAN-10?page=comments#action_73817 ] Joakim Erdfelt commented on MCLEAN-10: -- file-management 1.1-SNAPSHOT definately has this implemented and wired up. > Option to "mvn clean" task not to follow soft links > --- > > Key: MCLEAN-10 > URL: http://jira.codehaus.org/browse/MCLEAN-10 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature > Environment: UNIX >Reporter: Roar Lauritzsen >Priority: Minor > > Our project builds an executable into our "install" subproject under > "install/target". To do a test-run of this executable, I usually symlink a > directory containing about 1 million test-data files into the directory tree > below "target". I much prefer symlinking this test-data directory instead of > copying it, because of the time it takes to copy. > However, if I inadvertently do "mvn clean" without removing this link, maven > will follow the symlink and recursively remove my whole input document > directory. > An option to "mvn clean", like "dontFollowSymlinks", could do the trick -- 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: (MCLEAN-10) Option to "mvn clean" task not to follow soft links
[ http://jira.codehaus.org/browse/MCLEAN-10?page=all ]
Joakim Erdfelt closed MCLEAN-10.
Resolution: Fixed
Work has already been done.
file-management 1.0 has followSymlinks implemented.
http://svn.apache.org/viewvc/maven/shared/tags/file-management-1.0/src/main/java/org/apache/maven/shared/model/fileset/util/FileSetManager.java?view=markup
I tested the false functionality on my local
linux machine by linking in some content from ~/tmp/ into a sample projects
${basedir}/target/foo works as advertised.
> Option to "mvn clean" task not to follow soft links
> ---
>
> Key: MCLEAN-10
> URL: http://jira.codehaus.org/browse/MCLEAN-10
> Project: Maven 2.x Clean Plugin
> Issue Type: New Feature
> Environment: UNIX
>Reporter: Roar Lauritzsen
>Priority: Minor
>
> Our project builds an executable into our "install" subproject under
> "install/target". To do a test-run of this executable, I usually symlink a
> directory containing about 1 million test-data files into the directory tree
> below "target". I much prefer symlinking this test-data directory instead of
> copying it, because of the time it takes to copy.
> However, if I inadvertently do "mvn clean" without removing this link, maven
> will follow the symlink and recursively remove my whole input document
> directory.
> An option to "mvn clean", like "dontFollowSymlinks", could do the trick
--
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: (MPRELEASE-20) mvn release:perform does not inherit command line variable
mvn release:perform does not inherit command line variable -- Key: MPRELEASE-20 URL: http://jira.codehaus.org/browse/MPRELEASE-20 Project: maven-release-plugin Issue Type: Bug Affects Versions: 1.5 Reporter: Michael Semb Wever Priority: Critical When I deploy i must add -Duser.name=mickw to ensure scpexe logins in with the correct username. eg mvn deploy -Duser.name=mick But when I run "mvn release:perform" scpexe fails when it forks the sub process: mvn deploy site-deploy --no-plugin-updates -P null,null -DperformRelease=true and it's missing the -Duser.name=mickw variable. I need some way of setting the user.name property to make it possible to run release:perform -- 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: (MCLEAN-16) unable to resolve org.apache.maven.plugins:maven-clean-plugin:pom:2.1.1-SNAPSHOT
[ http://jira.codehaus.org/browse/MCLEAN-16?page=all ]
Joakim Erdfelt closed MCLEAN-16.
Resolution: Fixed
The 2.1.1-SNAPSHOT plugin can be found with the 2 following additions into your
pom. Tested with maven-user-webapp.
{code:xml}
...
org.apache.maven.plugins
maven-clean-plugin
2.1.1-20060724.192148-1
${basedir}/src/main/webapp
META-INF
WEB-INF/classes
WEB-INF/tld
WEB-INF/lib
user/*
WEB-INF/*.tld
WEB-INF/*.xml
...
{code}
and a new repository entry to find it.
{code:xml}
snapshots.apache.org
http://people.apache.org/maven-snapshot-repository
false
true
{code}
> unable to resolve
> org.apache.maven.plugins:maven-clean-plugin:pom:2.1.1-SNAPSHOT
>
>
> Key: MCLEAN-16
> URL: http://jira.codehaus.org/browse/MCLEAN-16
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
> Environment: maven 2.0.4 on ubuntu linux jre 1.6
>Reporter: Jesse Kuhnert
>
> When trying to build tapestry today I was immediately presented with an error
> of not being able to resolve the 2.1.1 clean plugin. Could be because I have
> the snapshots repo in my pom and should expect things like this, but thought
> I'd post an issue just in case.
> Someone else reported similar issues with the JETTY plugin that were only
> resolved by citing a specific version. Ie: version
> 2.1.1-20060724.192148-1.
> My pom looks like this (it may change on this url as I hope to fix it in
> whatever way possible tonight):
> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/pom.xml?view=markup
--
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: (MCHECKSTYLE-43) Add "skip" capability....
[ http://jira.codehaus.org/browse/MCHECKSTYLE-43?page=comments#action_73822 ] Joakim Erdfelt commented on MCHECKSTYLE-43: --- A consistent analysis skip property should be created. ala "-Dmaven.analysis.skip=true" ??Dreaming of a better future?? I'd like to see a new AbstractAnalysisMojo that implements this skip functionality, as well as provide some DataPoint gathering for dashboard, code health, and analysis history reporting. Then all analysis tools could use this new abstract mojo to make for consistent source/binary analysis reports. > Add "skip" capability > - > > Key: MCHECKSTYLE-43 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-43 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Reporter: Daniel Kulp > > Since checkstyle can be a time consuming task like running tests, it would be > nice to have a flag similar to the "-Dmaven.test.skip=true" flag to allow > skipping the checkstyle checks. -- 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: (MEV-438) pom for tomcat:jasper-runtime:5.5.15 is missing
[ http://jira.codehaus.org/browse/MEV-438?page=all ]
Carlos Sanchez closed MEV-438.
--
Assignee: Carlos Sanchez
Resolution: Fixed
I created and uploaded poms for all tomcat jars 5.5.15 with dependencies
> pom for tomcat:jasper-runtime:5.5.15 is missing
> ---
>
> Key: MEV-438
> URL: http://jira.codehaus.org/browse/MEV-438
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Missing POM
>Reporter: Emmanuel Venisse
> Assigned To: Carlos Sanchez
>
> based on old jasper-runtime pom, the new one would be :
> {noformat}
>
> 4.0.0
> tomcat
> jasper-runtime
> 5.5.15
>
> {noformat}
--
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: (MEV-439) pom for stax:stax-api:1.0.1
[ http://jira.codehaus.org/browse/MEV-439?page=all ] Carlos Sanchez closed MEV-439. -- Assignee: Carlos Sanchez Resolution: Fixed > pom for stax:stax-api:1.0.1 > --- > > Key: MEV-439 > URL: http://jira.codehaus.org/browse/MEV-439 > Project: Maven Evangelism > Issue Type: Bug > Components: Missing POM >Reporter: Tim O'Brien > Assigned To: Carlos Sanchez > Attachments: stax-api-1.0.1.pom, stax-api-1.0.1.pom > > > This artifact is missing a POM -- 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: (MAVENUPLOAD-1107) upload jguard v1.00-beta-1 jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1107?page=comments#action_73824 ] Carlos Sanchez commented on MAVENUPLOAD-1107: - missing parent pom I suggest you to create a repo at sf and we'll sync from there, see end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > upload jguard v1.00-beta-1 jars > --- > > Key: MAVENUPLOAD-1107 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1107 > Project: maven-upload-requests > Issue Type: Task >Reporter: charles gay > > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-core-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-ext-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-jee-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-struts-example-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-swing-example-1.00-beta-1-bundle.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: (MAVENUPLOAD-1105) Upload asterisk-java-0.3-m1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1105?page=all ] Carlos Sanchez closed MAVENUPLOAD-1105. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload asterisk-java-0.3-m1 > --- > > Key: MAVENUPLOAD-1105 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1105 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stefan Reuter > Assigned To: Carlos Sanchez > > http://asterisk-java.org/asterisk-java-0.3-m1-bundle.jar > http://asterisk-java.org/0.3-m1/ > http://asterisk-java.org/0.3-m1/team-list.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] Closed: (MAVENUPLOAD-1106) Upload freemarker-2.3.8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1106?page=all ] Carlos Sanchez closed MAVENUPLOAD-1106. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload freemarker-2.3.8 > --- > > Key: MAVENUPLOAD-1106 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1106 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Andreas Schödl > Assigned To: Carlos Sanchez > > Please upload freemarker-2.3.8.jar > License, URL and Dependencies are in the uploaded POM. -- 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: (MAVENUPLOAD-1099) Upload jMock 1.1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1099?page=all ] Carlos Sanchez closed MAVENUPLOAD-1099. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload jMock 1.1.0 > -- > > Key: MAVENUPLOAD-1099 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1099 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joerg Schaible > Assigned To: Carlos Sanchez > > http://people.apache.org/~joehni/jmock-cglib-1.1.0-bundle.jar > jMock is a well known library for mock objects. New version released on > weekend. -- 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: (MAVENUPLOAD-1053) Upload hibernate-tools 3.2.0-beta6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1053?page=comments#action_73826 ] Carlos Sanchez commented on MAVENUPLOAD-1053: - classifier is not needed as they are in another groupId > Upload hibernate-tools 3.2.0-beta6 > -- > > Key: MAVENUPLOAD-1053 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1053 > Project: maven-upload-requests > Issue Type: Task >Reporter: Johann Reyes > > Just found out that hibernate-tools is not dependant in official releases of > hibernate and hibernate-annotations artifacts, it needs the ones that came > bundle with, so here they are. -- 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: (MAVENUPLOAD-1104) Elmo 3.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1104?page=comments#action_73825 ] Carlos Sanchez commented on MAVENUPLOAD-1104: - run "mvn compile" with that pom, it has a log of errors both syntax and wrong dependencies > Elmo 3.0 > > > Key: MAVENUPLOAD-1104 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1104 > Project: maven-upload-requests > Issue Type: Task >Reporter: Peter Mika > > Elmo is an API for the Sesame RDF storage and query facility. (Sesame is > already available from this maven 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] Commented: (MRELEASE-131) release:prepare failed in 'cvs ... commit' phase for multi-module build
[ http://jira.codehaus.org/browse/MRELEASE-131?page=comments#action_73839 ]
Chris Byrd commented on MRELEASE-131:
-
I have the same problem, and a similar setup. I am using a cvs repository, and
have the following module layout.
-parent module
|
-> child module 1
|
-> child module 2
During the the release:prepare goal it modifies the poms fo the parent and
children, to update version numbers. Then it attempts to check in all poms
with updated values, before it tags the code. It seems to commit the poms,
then fails on the tag stating that the "pom.xml has been modified".
Looking logs, it sticks all 3 changed poms in the same commit, in the order
(parent, child 1, child 2). I have no idea which pom.xml file is actually
causing the problem, or if it is all 3.
I have a separate project that only has one module, and the release:prepare
goal works fine in this scenario. The pom is basically the same for the
multiple module project, except for the module dependencies.
The goal release:prepare -DdryRun=true works without a hitch. Its just the
actual tag into the cvs scm that fails. I'm really at a loss for how to fix
this. I hope someone has an idea. Below is the actual error.
[INFO] Checking in modified POMs...
[INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:D:/cvsrepo
-q commit -R -F D:\DOCUME~1\xfxc104\LOCALS~1\Temp\scm-commit-message5345.txt
pom.xml pw-linesheets-core/pom.xml pw-linesheets-webapp/pom.xml
[INFO] Working directory: D:\Documents and Settings\xfxc104\My
Documents\Dev\workspace\pw-linesheets
[INFO] Tagging release with the label pw_linesheets_0_1...
[INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:D:/cvsrepo -q tag -F
-c pw_linesheets_0_1
[INFO] Working directory: D:\Documents and Settings\xfxc104\My
Documents\Dev\workspace\pw-linesheets
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The cvs tag command failed.
Command output:
cvs server: pom.xml is locally modified
cvs [server aborted]: correct the above errors first!
> release:prepare failed in 'cvs ... commit' phase for multi-module build
> ---
>
> Key: MRELEASE-131
> URL: http://jira.codehaus.org/browse/MRELEASE-131
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: redhat linux, cvs 1.11.17, maven 2.0.4
>Reporter: Hung Le
>
> I have a multi-module setup
> parent-module
>child-module-1
>child-module-2
>...
> In CVS, they are peer, to establish the parent-child layout, manually first
> check out
> . parent-module (which has only the pom.xml)
> then 'cd to parent-module' and manually check out each of the child
> module (using 'cvs co -d outputDir module_name)
> when I use 'release:prepare', Maven2 failed at the 'commit phase'. After
> playing with the 'cvs commit ...' it appears that changing the order the
> 'list of modified POM's' gives different results. One that allow an OK
> 'commit' involves ordering the list of the modified POM's so that the parent
> POM is first in the list.
> It does look as if this is a cvs-specific issue but if we can do something to
> help as work-around, that will be great. I did quick experiment by modifying
> ScmCommitPhase.java. In method createPomFiles(reactorProjects), sort the list
> before returning and it did let me complete the release:prepare step:
> // [EMAIL PROTECTED]
> System.out.println("preSorted, pomFiles=" + pomFiles);
> boolean sortPomFiles = true;
> if (sortPomFiles) {
> Comparator comp = new Comparator() {
> public int compare(Object o1, Object o2) {
> File f1 = (File) o1;
> File f2 = (File) o2;
> String str1 = f1.getAbsolutePath();
> String str2 = f2.getAbsolutePath();
> int rv = (str1.length() - str2.length());
> if (rv == 0) {
> rv = f1.compareTo(f2);
> }
> return rv;
> }
> };
> Collections.sort(pomFiles, comp);
> }
> System.out.println("postSorted, pomFiles=" + pomFiles);
--
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] Moved: (MRELEASE-154) mvn release:perform does not inherit command line variable
[ http://jira.codehaus.org/browse/MRELEASE-154?page=all ] Dennis Lundberg moved MPRELEASE-20 to MRELEASE-154: --- Affects Version/s: (was: 1.5) Workflow: Maven New (was: jira) Key: MRELEASE-154 (was: MPRELEASE-20) Project: Maven 2.x Release Plugin (was: maven-release-plugin) > mvn release:perform does not inherit command line variable > -- > > Key: MRELEASE-154 > URL: http://jira.codehaus.org/browse/MRELEASE-154 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Michael Semb Wever >Priority: Critical > > When I deploy i must add -Duser.name=mickw to ensure scpexe logins in with > the correct username. > eg mvn deploy -Duser.name=mick > But when I run "mvn release:perform" scpexe fails when it forks the sub > process: > mvn deploy site-deploy --no-plugin-updates -P null,null -DperformRelease=true > and it's missing the -Duser.name=mickw variable. > I need some way of setting the user.name property to make it possible to run > release:perform -- 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: (MEV-440) jasper poms under Tomcat are missing groupIds
jasper poms under Tomcat are missing groupIds - Key: MEV-440 URL: http://jira.codehaus.org/browse/MEV-440 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Jeff Genender It seems all the jasper poms are missing groupIds and they fail when building with those dependencies. You may wish to check the other 5.5.15 poms as well. -- 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-440) jasper poms under Tomcat are missing groupIds
[ http://jira.codehaus.org/browse/MEV-440?page=comments#action_73834 ] Jeff Genender commented on MEV-440: --- After speaking with carlos looks like the error is in tomcat/tomcat-parent/5.5.15 pom...missing tag. > jasper poms under Tomcat are missing groupIds > - > > Key: MEV-440 > URL: http://jira.codehaus.org/browse/MEV-440 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Jeff Genender > > It seems all the jasper poms are missing groupIds and they fail when building > with those dependencies. You may wish to check the other 5.5.15 poms as well. -- 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: (MEV-440) jasper poms under Tomcat are missing groupIds
[ http://jira.codehaus.org/browse/MEV-440?page=all ] Carlos Sanchez closed MEV-440. -- Assignee: Carlos Sanchez Resolution: Fixed parent had an xml error > jasper poms under Tomcat are missing groupIds > - > > Key: MEV-440 > URL: http://jira.codehaus.org/browse/MEV-440 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Jeff Genender > Assigned To: Carlos Sanchez > > It seems all the jasper poms are missing groupIds and they fail when building > with those dependencies. You may wish to check the other 5.5.15 poms as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-47) Regression : Files not copied when overlaying wars
[ http://jira.codehaus.org/browse/MWAR-47?page=comments#action_73836 ]
Douglas Ferguson commented on MWAR-47:
--
I actually would prefer that files in the "real,final" projects would take
priority over anything in a dependency.
I was suprised when this changed. Could this be configurable?
D-
> Regression : Files not copied when overlaying wars
> --
>
> Key: MWAR-47
> URL: http://jira.codehaus.org/browse/MWAR-47
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Eric Bottard
> Assigned To: Brett Porter
> Fix For: 2.0.1
>
> Original Estimate: 30 minutes
> Time Spent: 45 minutes
> Remaining Estimate: 0 minutes
>
> The handy "overlay wars" functionnality seems to have changed with release
> 2.0 : files that are already in place (no matter last modification date) are
> never overwritten from overlaid wars.
> This is problematic since after a first packaging of the war file, any file
> coming from a dependent war will already sit there and will never be updated.
> The faulty line is here (AbstractWarMojo.java):
> for ( int j = 0; j < files.length; j++ )
> {
> File targetFile = new File( targetDir, files[j] );
> // Do not overwrite existing files.
> if ( !targetFile.exists() ) // <== WILL
> ALWAYS FAIL
> {
> try
> {
> targetFile.getParentFile().mkdirs();
> copyFileIfModified( new File( srcDir, files[j] ),
> targetFile );
> }
> catch ( IOException e )
> {
> throw new MojoExecutionException( "Error copying file '"
> + files[j] + "' to '" + targetFile + "'",
> e );
> }
> }
> }
> My use case is, I guess, pretty common : I have a "framework" project
> (packaging = war) that must benefit may "real, final" projects that produce
> the final artifact (packaging = war as well). The "framework" part is a
> 'dependent war' of the real project and is 'overlaid' by the war plugin. The
> trouble is, if I update any file of the framework part, changes are not taken
> into account since files already exist in the target directory.
> Please consider removing the " if ( !targetFile.exists() )" part (last
> modification date alone is fine).
> regards,
> eb.
--
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-74) Can this be configurable? See my comment on the above issue
Can this be configurable? See my comment on the above issue --- Key: MWAR-74 URL: http://jira.codehaus.org/browse/MWAR-74 Project: Maven 2.x War Plugin Issue Type: Sub-task Reporter: Douglas Ferguson -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-47) Regression : Files not copied when overlaying wars
[ http://jira.codehaus.org/browse/MWAR-47?page=comments#action_73838 ]
Cservenak, Tamas commented on MWAR-47:
--
The same as above seems logical to me also.
If the web.xml is taken from "final" project, why not overwrite another file
that exists in both, the dependency WAR and "final" project with "final" file?
~t~
> Regression : Files not copied when overlaying wars
> --
>
> Key: MWAR-47
> URL: http://jira.codehaus.org/browse/MWAR-47
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Eric Bottard
> Assigned To: Brett Porter
> Fix For: 2.0.1
>
> Original Estimate: 30 minutes
> Time Spent: 45 minutes
> Remaining Estimate: 0 minutes
>
> The handy "overlay wars" functionnality seems to have changed with release
> 2.0 : files that are already in place (no matter last modification date) are
> never overwritten from overlaid wars.
> This is problematic since after a first packaging of the war file, any file
> coming from a dependent war will already sit there and will never be updated.
> The faulty line is here (AbstractWarMojo.java):
> for ( int j = 0; j < files.length; j++ )
> {
> File targetFile = new File( targetDir, files[j] );
> // Do not overwrite existing files.
> if ( !targetFile.exists() ) // <== WILL
> ALWAYS FAIL
> {
> try
> {
> targetFile.getParentFile().mkdirs();
> copyFileIfModified( new File( srcDir, files[j] ),
> targetFile );
> }
> catch ( IOException e )
> {
> throw new MojoExecutionException( "Error copying file '"
> + files[j] + "' to '" + targetFile + "'",
> e );
> }
> }
> }
> My use case is, I guess, pretty common : I have a "framework" project
> (packaging = war) that must benefit may "real, final" projects that produce
> the final artifact (packaging = war as well). The "framework" part is a
> 'dependent war' of the real project and is 'overlaid' by the war plugin. The
> trouble is, if I update any file of the framework part, changes are not taken
> into account since files already exist in the target directory.
> Please consider removing the " if ( !targetFile.exists() )" part (last
> modification date alone is fine).
> regards,
> eb.
--
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-131) release:prepare failed in 'cvs ... commit' phase for multi-module build
[ http://jira.codehaus.org/browse/MRELEASE-131?page=comments#action_73840 ]
Chris Byrd commented on MRELEASE-131:
-
In additional testing, I have found that the the release:prepare goal is
actually failing on the commit somehow. What is occurring is that of the 3
poms I have in my project, the release:prepare goal is committing the 2 child
poms, but not the parent pom. Then when it goes to tag the code, the parent
pom has not been committed, and it errors out.
Therefore, the issue is to determine why the parent pom is not getting
committed, and what I need to do to make this happen.
> release:prepare failed in 'cvs ... commit' phase for multi-module build
> ---
>
> Key: MRELEASE-131
> URL: http://jira.codehaus.org/browse/MRELEASE-131
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: redhat linux, cvs 1.11.17, maven 2.0.4
>Reporter: Hung Le
>
> I have a multi-module setup
> parent-module
>child-module-1
>child-module-2
>...
> In CVS, they are peer, to establish the parent-child layout, manually first
> check out
> . parent-module (which has only the pom.xml)
> then 'cd to parent-module' and manually check out each of the child
> module (using 'cvs co -d outputDir module_name)
> when I use 'release:prepare', Maven2 failed at the 'commit phase'. After
> playing with the 'cvs commit ...' it appears that changing the order the
> 'list of modified POM's' gives different results. One that allow an OK
> 'commit' involves ordering the list of the modified POM's so that the parent
> POM is first in the list.
> It does look as if this is a cvs-specific issue but if we can do something to
> help as work-around, that will be great. I did quick experiment by modifying
> ScmCommitPhase.java. In method createPomFiles(reactorProjects), sort the list
> before returning and it did let me complete the release:prepare step:
> // [EMAIL PROTECTED]
> System.out.println("preSorted, pomFiles=" + pomFiles);
> boolean sortPomFiles = true;
> if (sortPomFiles) {
> Comparator comp = new Comparator() {
> public int compare(Object o1, Object o2) {
> File f1 = (File) o1;
> File f2 = (File) o2;
> String str1 = f1.getAbsolutePath();
> String str2 = f2.getAbsolutePath();
> int rv = (str1.length() - str2.length());
> if (rv == 0) {
> rv = f1.compareTo(f2);
> }
> return rv;
> }
> };
> Collections.sort(pomFiles, comp);
> }
> System.out.println("postSorted, pomFiles=" + pomFiles);
--
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-87) doc-files ignored if they reside in the resources directory
[ http://jira.codehaus.org/browse/MJAVADOC-87?page=comments#action_73842 ] Matthew Beermann commented on MJAVADOC-87: -- It might be worth expanding on the Standard Directory Layout (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) to include a generic folder for documentation. The "resources" folder(s) don't really seem appropriate - we don't want javadoc artifacts included in the endstate. Nor does the "site" folder, because they don't become part of the Maven site. > doc-files ignored if they reside in the resources directory > --- > > Key: MJAVADOC-87 > URL: http://jira.codehaus.org/browse/MJAVADOC-87 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Matthew Beermann > > It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad > summary. The bug is this: if you have a "doc-files" folder in the > "src/main/resources" branch of your project, its contents will be omitted > from the Javadoc output. However, if you move the same folder over to > "src/main/java", it will be included in the output. This bug is present in > the released (2.0) version of the plugin. > The file "package.html", by comparison, will be included in the Javadoc > output no matter where it is. This is the expected behavior, AFAICT. More > information about the "doc-files" directory can be found here: > http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed -- 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-131) release:prepare failed in 'cvs ... commit' phase for multi-module build
[ http://jira.codehaus.org/browse/MRELEASE-131?page=comments#action_73843 ]
Chris Byrd commented on MRELEASE-131:
-
Here is the logs with the debug stacktrace. The interesting thing is that the
code is not even attempting to commit the top level parent pom. All mvn tasks
are executed from the top level directory. It is committing both the children
poms, and skipping over the parent pom. All other plugins and goals have
worked correctly. I can only guess this is somehow a bug with the release
plugin.
[INFO] Checking in modified POMs...
[INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:D:/cvsrepo -q commit
-R -F D:\DOCUME~1\xfxc104\LOCALS~1\Temp\scm-commit-message6743.txt pom.xml
pw-linesheets-core/pom.xml pw-linesheets-webapp/pom.xml
[INFO] Working directory: D:\Documents and Settings\xfxc104\My
Documents\Dev\workspace\pw-linesheets
[DEBUG] Checking in pw-linesheets-core/pom.xml;
[DEBUG] D:/cvsrepo/pw_linesheets/pw-linesheets-core/pom.xml,v <-- pom.xml
[DEBUG] new revision: 1.10; previous revision: 1.9
[DEBUG] done
[DEBUG] Checking in pw-linesheets-webapp/pom.xml;
[DEBUG] D:/cvsrepo/pw_linesheets/pw-linesheets-webapp/pom.xml,v <-- pom.xml
[DEBUG] new revision: 1.9; previous revision: 1.8
[DEBUG] done
[INFO] Tagging release with the label pw_linesheets_1_0...
[INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:D:/cvsrepo -q tag -F
-c pw_linesheets_1_0
[INFO] Working directory: D:\Documents and Settings\xfxc104\My
Documents\Dev\workspace\pw-linesheets
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to tag SCM
Provider message:
The cvs tag command failed.
Command output:
cvs server: pom.xml is locally modified
cvs [server aborted]: correct the above errors first!
> release:prepare failed in 'cvs ... commit' phase for multi-module build
> ---
>
> Key: MRELEASE-131
> URL: http://jira.codehaus.org/browse/MRELEASE-131
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: redhat linux, cvs 1.11.17, maven 2.0.4
>Reporter: Hung Le
>
> I have a multi-module setup
> parent-module
>child-module-1
>child-module-2
>...
> In CVS, they are peer, to establish the parent-child layout, manually first
> check out
> . parent-module (which has only the pom.xml)
> then 'cd to parent-module' and manually check out each of the child
> module (using 'cvs co -d outputDir module_name)
> when I use 'release:prepare', Maven2 failed at the 'commit phase'. After
> playing with the 'cvs commit ...' it appears that changing the order the
> 'list of modified POM's' gives different results. One that allow an OK
> 'commit' involves ordering the list of the modified POM's so that the parent
> POM is first in the list.
> It does look as if this is a cvs-specific issue but if we can do something to
> help as work-around, that will be great. I did quick experiment by modifying
> ScmCommitPhase.java. In method createPomFiles(reactorProjects), sort the list
> before returning and it did let me complete the release:prepare step:
> // [EMAIL PROTECTED]
> System.out.println("preSorted, pomFiles=" + pomFiles);
> boolean sortPomFiles = true;
> if (sortPomFiles) {
> Comparator comp = new Comparator() {
> public int compare(Object o1, Object o2) {
> File f1 = (File) o1;
> File f2 = (File) o2;
> String str1 = f1.getAbsolutePath();
> String str2 = f2.getAbsolutePath();
> int rv = (str1.length() - str2.length());
> if (rv == 0) {
> rv = f1.compareTo(f2);
> }
> return rv;
> }
> };
> Collections.sort(pomFiles, comp);
> }
> System.out.println("postSorted, pomFiles=" + pomFiles);
--
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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73854 ] Brett Porter commented on MRM-155: -- unfortunately this broke existing tests. Please make sure to run them all again before submitting. I'm going to rework it to get that fixed though this time. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch, > MRM-155.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73855 ]
Brett Porter commented on MRM-155:
--
I removed:
if ( target.exists() )
{
break;
}
Because it caused additional snapshot repositories to be checked as they should
be (as shown by the metadata merging test failure)
> When proxy is used by maven1artifact are stored in managed repo using legacy
> layout.
>
>
> Key: MRM-155
> URL: http://jira.codehaus.org/browse/MRM-155
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Reporter: nicolas de loof
> Attachments: DefaultProxyRequestHandler.java.patch,
> DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch,
> MRM-155.patch
>
>
> When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the
> artifact is stored using legacy layout (maven1 path). When a maven2 client
> asks for it, the artifact is downloaded a second time and stored using maven2
> layout.
> This may produce lot's of duplicates in the managed repo.
> request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar"
> -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1
> -> servletapi\jars\servletapi-2.3.jar
> request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar "
> -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73856 ]
Brett Porter commented on MRM-155:
--
this:
if ( path.endsWith( ".md5" ) || path.endsWith( ".sha1" ) )
{
// always read from the managed repository, no need to make remote
request
}
was removed without explanation. The checksums should always be present so need
to proxy them. I added it back.
> When proxy is used by maven1artifact are stored in managed repo using legacy
> layout.
>
>
> Key: MRM-155
> URL: http://jira.codehaus.org/browse/MRM-155
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
>Reporter: nicolas de loof
> Attachments: DefaultProxyRequestHandler.java.patch,
> DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch,
> MRM-155.patch
>
>
> When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the
> artifact is stored using legacy layout (maven1 path). When a maven2 client
> asks for it, the artifact is downloaded a second time and stored using maven2
> layout.
> This may produce lot's of duplicates in the managed repo.
> request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar"
> -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1
> -> servletapi\jars\servletapi-2.3.jar
> request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar "
> -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73858 ] Brett Porter commented on MRM-155: -- ok, found and fixed the problem. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch, > MRM-155.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73859 ] Brett Porter commented on MRM-155: -- I've added an additional test for the reverse case (legacy managed, default remote) and noticed this fix wasn't sufficient. I've corrected that. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch, > MRM-155.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=all ] Brett Porter closed MRM-155. Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0-beta-1 > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch, > MRM-155.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.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] Commented: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=comments#action_73861 ] Brett Porter commented on MRM-153: -- there are a number of issues with this that I am reworking: - the same ones highlighted in MRM-155 - incorrect assumptions about the location of the POM - didn't test m2 relocations at all - exception handling in the relocation was not ideal - applyRelocation didn't need to return artifact, it modifies the passed in instance > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-153.patch, > MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] Brett Porter closed MRM-153. Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0-beta-1 > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof > Assigned To: Brett Porter >Priority: Minor > Fix For: 1.0-beta-1 > > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-153.patch, > MRM-155.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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: (MRM-154) DigestUtils fails to verify checksum from ibiblio
[ http://jira.codehaus.org/browse/MRM-154?page=all ]
Brett Porter closed MRM-154.
Assignee: Brett Porter
Resolution: Fixed
Fix Version/s: 1.0-beta-1
applied, thanks.
I also fixed the same problem for the openssl format
> DigestUtils fails to verify checksum from ibiblio
> -
>
> Key: MRM-154
> URL: http://jira.codehaus.org/browse/MRM-154
> Project: Archiva
> Issue Type: Bug
>Reporter: nicolas de loof
> Assigned To: Brett Porter
> Fix For: 1.0-beta-1
>
> Attachments: DigestUtils.java.patch, MRM-154.patch
>
>
> Downloading servletapi-24.pom fails.
> DigestUtils.cleanChecksum check for filename in remote checksum file to be
> same as local, but tets is inverted :
> String filename = m.group( 2 );
> if ( !path.endsWith( filename ) )
> {
> throw new DigesterException( "Supplied checksum does not
> match checksum pattern" );
> }
> filename =
> "/home/projects/maven/repository-staging/to-ibiblio/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom"
> path = "servletapi-2.4.pom".
> Patch provided to test if ( !path.endsWith( filename ) )
--
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: (MRM-141) update design documentation
[ http://jira.codehaus.org/browse/MRM-141?page=all ] Brett Porter updated MRM-141: - Assignee: Brett Porter Fix Version/s: (was: 1.0-beta-1) 1.0 > update design documentation > --- > > Key: MRM-141 > URL: http://jira.codehaus.org/browse/MRM-141 > Project: Archiva > Issue Type: Task > Components: design >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0 > > > - the indexing design docs don't indicate how to use the indexer from an API > perspective > - there needs to be a more general "this is the architecture" design document -- 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
