[jira] Created: (WAGON-228) role hint: 'scpexe' has a hint, but there are other implementations that don't
role hint: 'scpexe' has a hint, but there are other implementations that don't -- Key: WAGON-228 URL: http://jira.codehaus.org/browse/WAGON-228 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh-external Affects Versions: 1.0-beta-3 Environment: Windows XP, Maven 2.0.9, JDK 1.6.0_04 Reporter: Dennis Kieselhorst Priority: Critical scpexe doesn't work after updating to 1.0-beta-3: [ERROR] BUILD ERROR [INFO] [INFO] Unable to initialise extensions Component descriptor role: 'org.apache.maven.wagon.CommandExecutor', implementation: 'org.apache.maven.wagon.providers.ssh.external.ScpExternalCommandExecutor', role hint: 'scpexe' has a hint, but there are other implementations that don't -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-228) role hint: 'scpexe' has a hint, but there are other implementations that don't
[ http://jira.codehaus.org/browse/WAGON-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-228. -- Assignee: Brett Porter Resolution: Won't Fix regrettably, as you'll see in the release notes, the new wagon won't work with 2.0.9. However, 2.0.10 that bundles the new version is being prepared for release now, and going forward there should be no problems in using newer wagons with an Maven version. role hint: 'scpexe' has a hint, but there are other implementations that don't -- Key: WAGON-228 URL: http://jira.codehaus.org/browse/WAGON-228 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh-external Affects Versions: 1.0-beta-3 Environment: Windows XP, Maven 2.0.9, JDK 1.6.0_04 Reporter: Dennis Kieselhorst Assignee: Brett Porter Priority: Critical scpexe doesn't work after updating to 1.0-beta-3: [ERROR] BUILD ERROR [INFO] [INFO] Unable to initialise extensions Component descriptor role: 'org.apache.maven.wagon.CommandExecutor', implementation: 'org.apache.maven.wagon.providers.ssh.external.ScpExternalCommandExecutor', role hint: 'scpexe' has a hint, but there are other implementations that don't -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-198) AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap
AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap -- Key: MJAVADOC-198 URL: http://jira.codehaus.org/browse/MJAVADOC-198 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Detelin Yordanov Attachments: AbstractJavadocMojo.patch Hi, We had a problem using Eclipse artifacts that contain version qualifiers, e.g. artifact foo version 3.3.0-SomeQualifier is not resolved when the dependency version definition uses a version range e.g.: dependency artifactIdfooartifactId version[3.3.0,4.0.0)/version groupIdsome Group.../groupId dependency We found a workaround for this described here: http://jira.codehaus.org/browse/MECLIPSE-405. The workaround is to use maven 2.0.9+ and define concrete versions for the eclipse artifacts in a dependencyManagement section of our project, thus overriding the range version definitions in some of the eclipse poms. e.g.: dependencyManagement dependencies dependency groupIdorg.eclipse.equinox/groupId artifactIdcommon/artifactId version3.3.0-v20070426/version /dependency /dependencies dependencyManagement This helped us to build our project without getting version range issues, however when we ran javadoc:javadoc we found out that the javadoc dependency resolution does not take into account the dependencyManagement section and we still get the error: An error has occurred in JavaDocs report generation: Couldn't find a version in [3.2.0-v20060603, 3.3.0-v20070426] to match range [3.3.0,4.0.0) org.eclipse.equinox:common:jar:null When we examined the getClasspath(..) method of AbstractJavadocMojo we found out that it uses the ArtifactResolver#resolveTransitively(..) method that lacks the managedVersions Map parameter. We made an according patch to use the method that specifies it, and our problem was solved. So the question is whether the usage of the #resolveTransitively(..) that lacks managedVersions parameter is intentional or not. If there is no problem with it, we would be very happy if you could change this, so that we can successfully use the javadoc plugin in our project. Kind Regards, Detelin -- 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: (SUREFIRE-504) own classes and test-classes at the end of test classpath
own classes and test-classes at the end of test classpath
-
Key: SUREFIRE-504
URL: http://jira.codehaus.org/browse/SUREFIRE-504
Project: Maven Surefire
Issue Type: Bug
Components: plugin
Affects Versions: 2.4
Environment: Maven 2.0.9, Windows XP
Reporter: Torsten Reinhard
Own classes and test-classes may be added to the end of the classpath:
[DEBUG] Adding to surefire test classpath:
s:\mavenrepo\org\apache\maven\surefire\surefire-api\2.4\surefire-api-2.4.jar
[DEBUG] Test Classpath :
[DEBUG] s:\mavenrepo\log4j\log4j\1.2.13\log4j-1.2.13.jar
...
[DEBUG] s:\mavenrepo\org\apache\xmlsec\1.4.1\xmlsec-1.4.1.jar
[DEBUG] S:\pdv_cms\GDCAMS\src\pip\gdcams-pip-itest\target\classes
[DEBUG] S:\pdv_cms\GDCAMS\src\pip\gdcams-pip-itest\target\test-classes
This may happen, when you add the following terms to a parent pom.xml:
properties
target.dirtarget/target.dir
/properties
build
!-- special (output)Directory for Eclipse --
!-- see
http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-HowtoconfigureMavenprojecttouseseparateoutputfoldersinEclipse--
outputDirectory${project.basedir}/${target.dir}/classes/outputDirectory
testOutputDirectory${project.basedir}/${target.dir}/test-classes/testOutputDirectory
/build
profiles
profile
ideclipse-folders/id
properties
target.dirtarget-eclipse/target.dir
/properties
/profile
/profiles
The reason for that is:
SurefirePlugin#constructSurefireBooter changes the classpath by doing:
...
getLog().debug( Test Classpath : );
// Check if we need to add configured classes/test classes directories
here.
// If they are configured, we should remove the default to avoid
conflicts.
if ( !project.getBuild().getOutputDirectory().equals(
classesDirectory.getAbsolutePath() ) )
{
classpathElements.remove( project.getBuild().getOutputDirectory() );
classpathElements.add( classesDirectory.getAbsolutePath() );
}
if ( !project.getBuild().getTestOutputDirectory().equals(
testClassesDirectory.getAbsolutePath() ) )
{
classpathElements.remove(
project.getBuild().getTestOutputDirectory() );
classpathElements.add( testClassesDirectory.getAbsolutePath() );
}
...
project.getBuild().getOutputDirectory() is like ${basedir}/target/classes
classesDirectory.getAbsolutePath() is: ${basedir}\target\classes
So i think here a 2 bugs:
(1) files/directories shouldn´t be compared just as String.equals() - using
File.compareTo may be a better solution
(2) an Element of classpathElements shouldn´t be removed and added to the end
of the ArrayList, it should be replaced at the same position.
--
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: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142165#action_142165
]
Marcello Teodori commented on MRESOURCES-20:
hit by this bug when using a ${anytexthere.name} property, the side effect of
this bug are so big it should be patched as soon as possible
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MRESOURCES-20
URL: http://jira.codehaus.org/browse/MRESOURCES-20
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
Attachments: MRESOURCES-20.patch
If an unresolved variable is encountered, the plugin simply does not replace
the variable in the target file.
If this unresolved variable however ends in .file} it will evaluate to a
file object that targets the current pom. This results in the replacement
being the complete path to that pom (in the 2.1 version of the plugin this
results in a ClassCastException).
The workaround is, of course, not to filter the affected files.
Though this will not work if other variables in the affected files do need to
be replaced.
--
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-3122) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml
[ http://jira.codehaus.org/browse/MNG-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142166#action_142166 ] Lorenzo Bigagli commented on MNG-3122: -- This is the console output I get: pan:prova bigagli$ mvn help:active-profiles [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building Unnamed - it.cnr.imaa.essi:lablib-prova:jar:1.0 [INFO]task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'it.cnr.imaa.essi:lablib-prova:jar:1.0': The following profiles are active: - property-injection (source: settings.xml) - property-injection (source: settings.xml) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml Key: MNG-3122 URL: http://jira.codehaus.org/browse/MNG-3122 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.7 Reporter: Ian Berry Fix For: 2.0.x Attachments: duplicateActiveProfiles.JPG, duplicateActiveProfiles.zip, settings.xml MavenProject:getActiveProfiles() is returning duplicate activeByDefault profiles defined in LOCAL_HOME/.m2/settings.xml. Attached settings.xml resides in LOCAL_HOME/.m2. Below is part of the output of a buildInformation plugin i am writing, which shows profile WLS8 twice. activeProfiles activeProfile profileIddefault-repositories/profileId profileSourcesettings.xml/profileSource /activeProfile activeProfile profileIdWLS8/profileId profileSourcesettings.xml/profileSource /activeProfile activeProfile profileIdWLS8/profileId profileSourcesettings.xml/profileSource /activeProfile /activeProfiles -- 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: (MJAVADOC-198) AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap
[ http://jira.codehaus.org/browse/MJAVADOC-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-198. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.5 Patch applied in r677561, snapshot deployed AbstractJavadocMojo#getClasspath(..) should use subProject's managedVersionMap -- Key: MJAVADOC-198 URL: http://jira.codehaus.org/browse/MJAVADOC-198 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Detelin Yordanov Assignee: Vincent Siveton Fix For: 2.5 Attachments: AbstractJavadocMojo.patch Hi, We had a problem using Eclipse artifacts that contain version qualifiers, e.g. artifact foo version 3.3.0-SomeQualifier is not resolved when the dependency version definition uses a version range e.g.: dependency artifactIdfooartifactId version[3.3.0,4.0.0)/version groupIdsome Group.../groupId dependency We found a workaround for this described here: http://jira.codehaus.org/browse/MECLIPSE-405. The workaround is to use maven 2.0.9+ and define concrete versions for the eclipse artifacts in a dependencyManagement section of our project, thus overriding the range version definitions in some of the eclipse poms. e.g.: dependencyManagement dependencies dependency groupIdorg.eclipse.equinox/groupId artifactIdcommon/artifactId version3.3.0-v20070426/version /dependency /dependencies dependencyManagement This helped us to build our project without getting version range issues, however when we ran javadoc:javadoc we found out that the javadoc dependency resolution does not take into account the dependencyManagement section and we still get the error: An error has occurred in JavaDocs report generation: Couldn't find a version in [3.2.0-v20060603, 3.3.0-v20070426] to match range [3.3.0,4.0.0) org.eclipse.equinox:common:jar:null When we examined the getClasspath(..) method of AbstractJavadocMojo we found out that it uses the ArtifactResolver#resolveTransitively(..) method that lacks the managedVersions Map parameter. We made an according patch to use the method that specifies it, and our problem was solved. So the question is whether the usage of the #resolveTransitively(..) that lacks managedVersions parameter is intentional or not. If there is no problem with it, we would be very happy if you could change this, so that we can successfully use the javadoc plugin in our project. Kind Regards, Detelin -- 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: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142192#action_142192 ] M. Rohrmoser commented on MSITE-159: Sadly, the workaround above will not work with Firefox 3.0 - see https://bugzilla.mozilla.org/show_bug.cgi?id=43659 Absolute URI rendered as relative URI if absolute URI related to domain of POM URI -- Key: MSITE-159 URL: http://jira.codehaus.org/browse/MSITE-159 Project: Maven 2.x Site Plugin Issue Type: Bug Components: relative links Reporter: Ted Husted Under site-beta5 if the POM references a URI like urlhttp://struts.apache.org/url absolute URLs used in the site.xml file are converted to relative references. For example a reference to to http://struts.apache.org/1.x; becomes 1.x, and a reference to just http://struts.apache.org; becomes an empty string. If the documentation is being used offline, there are many cases when we want to refer people back to the website, to be sure the current information is used. The best use case is a download page that determines the mirror via CGI. Another use case is referring to a sister site in the domain, that might refer to another version. If used locally, the other site might not be in the relative location. Switching back to beta4 cures the behavior, and absolute URIs remain absolute, as expected. -- 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: (ARCHETYPE-193) Description of requiredProperty
Description of requiredProperty --- Key: ARCHETYPE-193 URL: http://jira.codehaus.org/browse/ARCHETYPE-193 Project: Maven Archetype Issue Type: New Feature Components: Generator Affects Versions: 2.0-alpha-3 Environment: windows xp sp2; java sun 1.6.0_07; maven 2.0.9 Reporter: Marcelo Romulo Fernandes Could we show a description of the requiredProperty to the user instead of their name at generator prompt? I think it could be more user friendly! I have to provide an extra readme.txt to explain how to use the requiredProperties. -- 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: (ARCHETYPE-194) conditional requiredProperty
conditional requiredProperty Key: ARCHETYPE-194 URL: http://jira.codehaus.org/browse/ARCHETYPE-194 Project: Maven Archetype Issue Type: New Feature Components: Generator Affects Versions: 2.0-alpha-3 Environment: windows xp sp2; java sun 1.6.0_07; maven2.0.9 Reporter: Marcelo Romulo Fernandes Can we ask the user for some requiredProperties depending of the values of others requiredProperties? Do we have conditional requiredProperty? -- 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: (ARCHETYPE-195) Enumeration of allowed values of requiredProperty
Enumeration of allowed values of requiredProperty
-
Key: ARCHETYPE-195
URL: http://jira.codehaus.org/browse/ARCHETYPE-195
Project: Maven Archetype
Issue Type: New Feature
Environment: windows xp sp2; java sun 1.6.0_07; maven2.0.9
Reporter: Marcelo Romulo Fernandes
Can we define an enumeration of allowed values of requiredProperty?
Example:
requiredProperty: databaseType
enumeration: {postgresql, mysql, oracle}
--
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: (ARCHETYPE-196) Default value like property 'version' at 2.0-alpha-3
Default value like property 'version' at 2.0-alpha-3 Key: ARCHETYPE-196 URL: http://jira.codehaus.org/browse/ARCHETYPE-196 Project: Maven Archetype Issue Type: New Feature Environment: windows xp sp2; java sun 1.6.0_07; maven 2.0.9 Reporter: Marcelo Romulo Fernandes If I define a requiredProperty at archetype-metadata.xml without a defaultValue (example: requiredProperty key=copyright/), the value of the property is prompted when I run mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-3:generate. If I input nothing (just hit an enter), the process fails. If I define a requiredProperty at archetype-metadata.xml with a defaultValue (example: requiredProperty key=copyright defaultValue=Basegen 2008/), when I run mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-3:generate the value of the property is not prompted anymore and process assumes the defaultValue. I wish a way to the command mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-3:generate prompt a value to the requiredProperty and a default value is assumed if nothing is typed (just hit an enter). At version 2.0-alpha-3, this happens with property 'version': if i just press enter, the process assumes the value '1.0-SNAPSHOT'. -- 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: (MSITE-302) mvn install site-deploy does not follow the reactor build sequence
[ http://jira.codehaus.org/browse/MSITE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor L. Torrez updated MSITE-302: --- Attachment: msite302-maven-logs.zip I added pluginartifactIdmaven-site-plugin/artifactIdversion2.0-beta-7/version/plugin to the pluginManagement section; separate invocations work, single invocation still fails. Attached are the results (mvn -X ...) mvn install site-deploy does not follow the reactor build sequence -- Key: MSITE-302 URL: http://jira.codehaus.org/browse/MSITE-302 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Ramon Havermans Attachments: msite302-maven-logs.zip, msite302.zip, OvereenkomstService_site-OvereenkomstService_site.1006-build.log We have a multi pom project. We have one parent, one EJB and one Impl project. The EJB project uses the Impl. The reactor sequence is Parent, EJB, Impl. When first doing mvn install and then mvn site-deploy the build is succesful. When doing mvn install site-deploy (on clean repository) the build fails because it first builds the Ejb instead of the Impl. It won't build because it is missing the installed Impl 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] Created: (MASSEMBLY-341) Fat JAR assemblies may result in JARs with duplicate files
Fat JAR assemblies may result in JARs with duplicate files -- Key: MASSEMBLY-341 URL: http://jira.codehaus.org/browse/MASSEMBLY-341 Project: Maven 2.x Assembly Plugin Issue Type: Bug Environment: Maven 2.0.8 Reporter: Daniel Gredler When building a fat JAR assembly (format=jar, dependencySet.unpack=true), if some of the dependencies contain files with the same path and name as files in any other dependencies and/or the current project, the generated JAR file contains duplicate files. The root issue is that ZIP files allow duplicate files, and JAR files are just special ZIP files. However, when a JAR file contains duplicate files, the results are unpredictable -- there's no way to know which file wins. Internally, (as far as I can tell) Maven's DefaultAssemblyArchiver [2] uses an ArchiverManager to get an Archiver based on the format name (jar). This Archiver is probably a MavenArchiver [3], which delegates to a JarArchiver [4], which is a subclass of ZipArchiver [5] and AbstractZipArchiver [6]. AbstractZipArchiver has a protected instance variable of type String named duplicate, the values of which can be one of preserve, fail and add. The default is add. I'm not sure if this needs to be fixed at the JarArchiver level (initialize the duplicate instance var to preserve), or at the DefaultAssemblyArchiver level (as was done with WAR assemblies for MNG-1274 -- see the createWarArchiver() method), or somewhere else. As an example of how other projects handle this, Ant's Jar task documentation page [1] includes a bolded warning which describes the issue and provides the duplicate attribute, which can be set to add, preserve or fail. [1] http://ant.apache.org/manual/CoreTasks/jar.html [2] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugin/assembly/archive/DefaultAssemblyArchiver.java [3] http://maven.apache.org/shared/maven-archiver/xref/index.html [4] http://fisheye.codehaus.org/browse/~raw,r=4612/plexus/plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/jar/JarArchiver.java [5] http://fisheye.codehaus.org/browse/~raw,r=4573/plexus/plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/zip/ZipArchiver.java [6] http://fisheye.codehaus.org/browse/~raw,r=4573/plexus/plexus-components/trunk/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MANTRUN-78) Use of AntRun causes clean to fail for multiproject
[
http://jira.codehaus.org/browse/MANTRUN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Jackson reopened MANTRUN-78:
--
I disagree that it's a duplicate. The error and the way it exhibits itself is
very different from MANTRUN-51.
Please run the test case I attached. The error you'll see is below. The only
task in the antrun config is a simple echo command.
C:\testmvn clean -Pbuild-failure
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] test
[INFO] test-b
[INFO] test-a
[INFO]
[INFO] Building test
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] test
[INFO] Executed tasks
[INFO]
[INFO] Building test-b
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] test
[INFO] Executed tasks
[INFO]
[INFO] Building test-a
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] snapshot com.example.test:test-b:1.0-SNAPSHOT: checking for updates from
espn.releases
[INFO] snapshot com.example.test:test-b:1.0-SNAPSHOT: checking for updates from
espn.snapshots
Downloading: http://maven2.corp.espn3.com/archiva/repository/releases//com/examp
le/test/test-b/1.0-SNAPSHOT/test-b-1.0-SNAPSHOT.jar
Downloading: http://maven2.corp.espn3.com/archiva/repository/snapshots//com/exam
ple/test/test-b/1.0-SNAPSHOT/test-b-1.0-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) com.example.test:test-b:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.example.test -DartifactId=test-b -D
version=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.example.test -DartifactId=test-b -Dve
rsion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -Drepository
Id=[id]
Path to dependency:
1) com.example.test:test-a:jar:1.0-SNAPSHOT
2) com.example.test:test-b:jar:1.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
com.example.test:test-a:jar:1.0-SNAPSHOT
from the specified remote repositories:
espn.releases (http://maven2.corp.espn3.com/archiva/repository/releases/),
espn.snapshots (http://maven2.corp.espn3.com/archiva/repository/snapshots/),
central (http://repo1.maven.org/maven2)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 6 seconds
[INFO] Finished at: Thu Jul 17 15:02:43 EDT 2008
[INFO] Final Memory: 3M/6M
[INFO]
C:\test
Use of AntRun causes clean to fail for multiproject
---
Key: MANTRUN-78
URL: http://jira.codehaus.org/browse/MANTRUN-78
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Environment: Maven version: 2.0.8
Java version: 1.5.0_12
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Brian Jackson
Assignee: Carlos Sanchez
Attachments: test.zip
Attaching the antrun plugin to the clean phase causes it to interfere with
local dependency resolution for sibling projects.
An example is attached.
The project consists of project 'test' with modules 'test-a' and test-b'.
'test-a' depends on 'test-b'.
If you run mvn clean on the root POM, the clean succeeds.
If you run mvn clean -Pbuild-failure it fails.
--
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: (MSHADE-39) Allow processing of Ma
Allow processing of Ma -- Key: MSHADE-39 URL: http://jira.codehaus.org/browse/MSHADE-39 Project: Maven 2.x Shade Plugin Issue Type: New Feature Reporter: Jason van Zyl -- 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: (MSHADE-39) Allow processing of MANIFEST.MF files
[ http://jira.codehaus.org/browse/MSHADE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MSHADE-39: Description: Allow for the arbitrary addition of manifest attributes. Also take care of the special case where you just want to specify a main-class attribute. Fix Version/s: 1.2 Summary: Allow processing of MANIFEST.MF files (was: Allow processing of Ma) Allow processing of MANIFEST.MF files - Key: MSHADE-39 URL: http://jira.codehaus.org/browse/MSHADE-39 Project: Maven 2.x Shade Plugin Issue Type: New Feature Reporter: Jason van Zyl Fix For: 1.2 Allow for the arbitrary addition of manifest attributes. Also take care of the special case where you just want to specify a main-class attribute. -- 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: (MPLUGIN-126) Report mojo outputs XDoc into wrong directory if outputDirectory parameter is overriden with a relative path
Report mojo outputs XDoc into wrong directory if outputDirectory parameter is
overriden with a relative path
Key: MPLUGIN-126
URL: http://jira.codehaus.org/browse/MPLUGIN-126
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 2.4.2
Reporter: Benjamin Bentmann
Priority: Minor
This configuration for {{plugin:report}}
{code:xml}
configuration
outputDirectorytarget/generated-site/xdoc/outputDirectory
/configuration
{code}
together with an invocation like
{noformat}
mvn -f subdir/pom.xml site
{noformat}
will exhibit [Common Bug #1|http://www.nabble.com/Common-Bugs-p14783703.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: (MPLUGIN-126) Report mojo outputs XDoc into wrong directory if outputDirectory parameter is overriden with a relative path
[
http://jira.codehaus.org/browse/MPLUGIN-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPLUGIN-126.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4.3
Fixed in [r677730|http://svn.apache.org/viewvc?view=revrevision=677730].
Report mojo outputs XDoc into wrong directory if outputDirectory parameter is
overriden with a relative path
Key: MPLUGIN-126
URL: http://jira.codehaus.org/browse/MPLUGIN-126
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 2.4.2
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Priority: Minor
Fix For: 2.4.3
This configuration for {{plugin:report}}
{code:xml}
configuration
outputDirectorytarget/generated-site/xdoc/outputDirectory
/configuration
{code}
together with an invocation like
{noformat}
mvn -f subdir/pom.xml site
{noformat}
will exhibit [Common Bug #1|http://www.nabble.com/Common-Bugs-p14783703.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] Updated: (MANTRUN-78) Use of AntRun during clean phase fails multiproject with intermodule dependencies
[ http://jira.codehaus.org/browse/MANTRUN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MANTRUN-78: -- Assignee: (was: Carlos Sanchez) Affects Version/s: 1.2 Summary: Use of AntRun during clean phase fails multiproject with intermodule dependencies (was: Use of AntRun causes clean to fail for multiproject) Confirmed with Maven 2.0.9 and antrun 1.1 and 1.2 Use of AntRun during clean phase fails multiproject with intermodule dependencies - Key: MANTRUN-78 URL: http://jira.codehaus.org/browse/MANTRUN-78 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1, 1.2 Environment: Maven version: 2.0.8 Java version: 1.5.0_12 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Brian Jackson Attachments: test.zip Attaching the antrun plugin to the clean phase causes it to interfere with local dependency resolution for sibling projects. An example is attached. The project consists of project 'test' with modules 'test-a' and test-b'. 'test-a' depends on 'test-b'. If you run mvn clean on the root POM, the clean succeeds. If you run mvn clean -Pbuild-failure it fails. -- 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: (MPCLOVER-60) clover:merge - a small change to allow the use of more than one pattern in the property 'maven.clover.merge.databases'
clover:merge - a small change to allow the use of more than one pattern in the
property 'maven.clover.merge.databases'
--
Key: MPCLOVER-60
URL: http://jira.codehaus.org/browse/MPCLOVER-60
Project: Maven 1.x Clover Plugin
Issue Type: Improvement
Reporter: Geoff Bennett
If more than just a single pattern is required to specify the databases to
merge it cannot be done with the current implementation of the plugin.
It would be better to change the following code in the clover:merge goal from:
ant:cloverDbSet dir=${_multiproject_basedir}
ant:include name=${maven.clover.merge.databases}/
/ant:cloverDbSet
to:
ant:cloverDbSet dir=${_multiproject_basedir}
includes=${maven.clover.merge.databases}/
The 'includes' attribute on cloverDbSet provides everything that the 'include'
tag provides, with the added benefit of being able to use multiple patterns and
files.
--
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: (MPCLOVER-60) clover:merge - a small change to allow the use of more than one pattern in the property 'maven.clover.merge.databases'
[
http://jira.codehaus.org/browse/MPCLOVER-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Bennett closed MPCLOVER-60.
-
Resolution: Won't Fix
Realised that the plugin is now hosted by Atlassian
clover:merge - a small change to allow the use of more than one pattern in
the property 'maven.clover.merge.databases'
--
Key: MPCLOVER-60
URL: http://jira.codehaus.org/browse/MPCLOVER-60
Project: Maven 1.x Clover Plugin
Issue Type: Improvement
Reporter: Geoff Bennett
If more than just a single pattern is required to specify the databases to
merge it cannot be done with the current implementation of the plugin.
It would be better to change the following code in the clover:merge goal from:
ant:cloverDbSet dir=${_multiproject_basedir}
ant:include name=${maven.clover.merge.databases}/
/ant:cloverDbSet
to:
ant:cloverDbSet dir=${_multiproject_basedir}
includes=${maven.clover.merge.databases}/
The 'includes' attribute on cloverDbSet provides everything that the
'include' tag provides, with the added benefit of being able to use multiple
patterns and files.
--
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-3669) getting compile time error class PropertyTable is public, should be declared in a file named PropertyTable.java
getting compile time error class PropertyTable is public, should be declared in a file named PropertyTable.java - Key: MNG-3669 URL: http://jira.codehaus.org/browse/MNG-3669 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.5 Environment: OS= windows2000 professioanl, platform = java, Reporter: John David Hi Folks , when im compiling my java source with maven im getting the following compile time error class PropertyTable is public, should be declared in a file named PropertyTable.java. when i dig into the code the above class is present with same package structure but in different jar files.. but this is working fine with ANT script.. could you please help me out in this... regards david -- 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
