[jira] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=comments#action_67907 ] Olivier Lamy commented on MWAR-33: -- Why not using Set artifacts = project.getArtifacts(); And get dependencies of the artifacts with type war. But I think in case of war type transitive dependencies are not resolved. I don't know exactly but I think there is an issue in MNG. With all jars in WEB-INF will come from poms dependencies declaration. IMHO, it's the best and cleaner solution ? With this I'm sure to have the same classpath when I try a junit and when I build my war. -- Olivier jars with differents versions can be in WEB-INF/lib with war as dependencies Key: MWAR-33 URL: http://jira.codehaus.org/browse/MWAR-33 Project: Maven 2.x War Plugin Type: Bug Environment: all Reporter: Olivier Lamy Fix For: 2.1 Original Estimate: 15 minutes Time Spent: 30 minutes Remaining: 0 minutes My pom has the following dependencies : - log4j:log4j:1.2.13 - a war with log4j:log4j:1.2.11 included Result the two jars are in WEB-INF/lib. -- 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-1975) EAR project depends on WAR that doesn't exist, but it builds succesfully
[ http://jira.codehaus.org/browse/MNG-1975?page=comments#action_67910 ] Stephane Nicoll commented on MNG-1975: -- John, I don't think so. See the previous comment. EAR project depends on WAR that doesn't exist, but it builds succesfully Key: MNG-1975 URL: http://jira.codehaus.org/browse/MNG-1975 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Environment: Debian GNU/Linux Etch (Testing), Eclipse WTP 1.0 Reporter: Duncan Doyle Fix For: 2.0.5 While I was testing the features of Maven 2.0.1 and 2.0.2 I noticed the following. When specifying the correct version of my WAR project as a dependency in my EAR pom.xml, the EAR file is generated correctly during a mvn install on my SuperPom. However, when I specify a wrong WAR version number (a non-existing one) in the dependency of my EAR Pom, the build still succeeds and an EAR file is generated. I'm doing this just as a test. I would expect the build to fail when the EAR project can't find the WAR file it depends on, but instead it gives a message that it can't find the WAR file in the local repository and remote repository and uses the generated WAR file (that is created before the EAR file is created), which has the wrong version number, to create the EAR package. This my super pom.xml: project modelVersion4.0.0/modelVersion nameTour de France Service/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId version0.0.1/version artifactIdTourDeFranceService/artifactId packagingpom/packaging modules module../TourDeFranceServiceEAR/module module../TourDeFranceServiceWeb/module /modules /project This my WAR pom.xml: project modelVersion4.0.0/modelVersion nameTour de France Service Web/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceWeb/artifactId packagingwar/packaging version0.0.2/version dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration webXml../TourDeFranceServiceWeb/WebContent/WEB-INF/web.xml/webXml /configuration /plugin /plugins finalNameTourDeFranceServiceWeb/finalName /build /project And this my EAR pom.xml with the wrong version number of the WAR project: project modelVersion4.0.0/modelVersion nameTour de France Service EAR/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceEAR/artifactId packagingear/packaging version0.0.1/version dependencies dependency groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceWeb/artifactId typewar/type version1.0.2/version /dependency /dependencies build finalNameTourDeFranceServiceEAR/finalName /build /project This is part of the message that mvn install gives me: Downloading: http://repo1.maven.org/maven2/nl/doyle/mccloud/TourDeFranceService/TourDeFranceServiceWeb/1.0.2/TourDeFranceServiceWeb-1.0.2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ear:generate-application-xml] [INFO] Generating application.xml [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [ear:ear] [INFO] Copying artifact[war:nl.doyle.mccloud.TourDeFranceService:TourDeFranceServiceWeb:1.0.2] to[TourDeFranceServiceWeb.war] How can it copy an artifact that doesn't exist??? The 1.0.2 version of my WAR file doesn't exist in my local repository and the WAR file in my Enterprise project has a different version number!!! -- 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: (MCHANGELOG-38) NPE when developer section does not include an id
[ http://jira.codehaus.org/browse/MCHANGELOG-38?page=comments#action_67913 ] Jerome Lacoste commented on MCHANGELOG-38: -- The id is required for the changelog plugin to work, otherwise it cannot match your SCM id to your name. So I don't think this is critical. The code could be more resistant and throw a user friendly exception instead of a NPE though. NPE when developer section does not include an id - Key: MCHANGELOG-38 URL: http://jira.codehaus.org/browse/MCHANGELOG-38 Project: Maven 2.x Changelog Plugin Type: Bug Reporter: Baerrach bonDierne Priority: Critical [DEBUG] Trace java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:398) at org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530) at org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541) at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370) at org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263) at org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218) at org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198) at org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) This is easy to replicate, find a working mvn site and then remove an id from a developer. This is for plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId I'd like to provide version details but this plugin isn't in my repository! So I am not sure how it is actually working. The website does't point to a repository, and I accidentally found it at http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-changelog-plugins but this code doesn't match up with the error message. I couldn't find the code base from the the old codehaus repository either. -- 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-1975) EAR project depends on WAR that doesn't exist, but it builds succesfully
[ http://jira.codehaus.org/browse/MNG-1975?page=comments#action_67914 ] Joerg Schaible commented on MNG-1975: - I can approve this case. I've build from the parent POM an EAR that referenced a RAR with wrong version number. The generation of the EAR succeeded, but mvn eclise:eclipse bailed out because of a missing dependency! EAR project depends on WAR that doesn't exist, but it builds succesfully Key: MNG-1975 URL: http://jira.codehaus.org/browse/MNG-1975 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Environment: Debian GNU/Linux Etch (Testing), Eclipse WTP 1.0 Reporter: Duncan Doyle Fix For: 2.0.5 While I was testing the features of Maven 2.0.1 and 2.0.2 I noticed the following. When specifying the correct version of my WAR project as a dependency in my EAR pom.xml, the EAR file is generated correctly during a mvn install on my SuperPom. However, when I specify a wrong WAR version number (a non-existing one) in the dependency of my EAR Pom, the build still succeeds and an EAR file is generated. I'm doing this just as a test. I would expect the build to fail when the EAR project can't find the WAR file it depends on, but instead it gives a message that it can't find the WAR file in the local repository and remote repository and uses the generated WAR file (that is created before the EAR file is created), which has the wrong version number, to create the EAR package. This my super pom.xml: project modelVersion4.0.0/modelVersion nameTour de France Service/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId version0.0.1/version artifactIdTourDeFranceService/artifactId packagingpom/packaging modules module../TourDeFranceServiceEAR/module module../TourDeFranceServiceWeb/module /modules /project This my WAR pom.xml: project modelVersion4.0.0/modelVersion nameTour de France Service Web/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceWeb/artifactId packagingwar/packaging version0.0.2/version dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration webXml../TourDeFranceServiceWeb/WebContent/WEB-INF/web.xml/webXml /configuration /plugin /plugins finalNameTourDeFranceServiceWeb/finalName /build /project And this my EAR pom.xml with the wrong version number of the WAR project: project modelVersion4.0.0/modelVersion nameTour de France Service EAR/name groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceEAR/artifactId packagingear/packaging version0.0.1/version dependencies dependency groupIdnl.doyle.mccloud.TourDeFranceService/groupId artifactIdTourDeFranceServiceWeb/artifactId typewar/type version1.0.2/version /dependency /dependencies build finalNameTourDeFranceServiceEAR/finalName /build /project This is part of the message that mvn install gives me: Downloading: http://repo1.maven.org/maven2/nl/doyle/mccloud/TourDeFranceService/TourDeFranceServiceWeb/1.0.2/TourDeFranceServiceWeb-1.0.2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ear:generate-application-xml] [INFO] Generating application.xml [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [ear:ear] [INFO] Copying artifact[war:nl.doyle.mccloud.TourDeFranceService:TourDeFranceServiceWeb:1.0.2] to[TourDeFranceServiceWeb.war] How can it copy an artifact that doesn't exist??? The 1.0.2 version of my WAR file doesn't exist in my local repository and the WAR file in my Enterprise project has a different version number!!! -- 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: (MRAR-7) Rar plugin des not allow to include vendor-specific deployment descriptors to META-INF
[ http://jira.codehaus.org/browse/MRAR-7?page=comments#action_67915 ] Joerg Schaible commented on MRAR-7: --- Works for me, put them into src/main/rar/META-INF. Rar plugin des not allow to include vendor-specific deployment descriptors to META-INF -- Key: MRAR-7 URL: http://jira.codehaus.org/browse/MRAR-7 Project: Maven 2.x Rar Plugin Type: Bug Reporter: Eugene Kuleshov Priority: Blocker RAR plugin des not allow to include vendor-specific deployment descriptors to META-INF. It is very common that RAR actually have no jars inside when it is packaged within EAR. However it does require to have vendor-specific deployment descriptor in META-INF in the RAR archive, but it doesn't seem possible with current plugin. See RAR example (commonj-rar module) built with Maven 1 at https://xcommonj-work.projects.dev2dev.bea.com/svn/xcommonj-work/trunk/xcommonj -- 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: (MRAR-11) Cannot define excludes resp. default exluded are not applied
Cannot define excludes resp. default exluded are not applied Key: MRAR-11 URL: http://jira.codehaus.org/browse/MRAR-11 Project: Maven 2.x Rar Plugin Type: Bug Versions: 2.1 Reporter: Joerg Schaible The current version of the plugin copies *anything* from src/main/rar into the rar file, including .svn folders and their content. Plugin configuration does not allow to define own includes or excludes. -- 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-151) Ability to change the site directory in the plugin configuration in the pom.xml file.
[ http://jira.codehaus.org/browse/MSITE-151?page=comments#action_67916 ]
Fred Jonkhart commented on MSITE-151:
-
Upgrading from maven 2.0.2 to 2.0.4 site generation relying on plugin parameters
to change both site location and resource location broke .
I did some tests. Conclusions below.
The only working situation is using the default configuration as shown below.
${basedir}/src/site - location of site.xml
${basedir}/src/site/resources - location of resources
${basedir}/src/site/xdoc- location of XDoc documents
I performed the following test cases.
a) Define a non-default resource location (parameter resourcesDirectory).
The site.xml is used. (${basedir}/src/site/site.xml)
The resources are NOT copied to the target. (${basedir}/doc/resources)
The Xdocs are converted to HTML. (${basedir}/src/site/xdoc).
b) Define a non-default site location (parameter siteDirectory).
The site.xml is NOT used. (${basedir}/doc/site/xdoc).
The resources are copied to the target.(${basedir}/doc/site/resources).
The Xdocs are converted to HTML. (${basedir}/doc/site/xdoc).
c) Define a non-default location for both site and resources.
The site.xml is NOT used. (${basedir}/doc/site/site.xml).
The resources are NOT copied to the target. (${basedir}/doc/resources).
The Xdocs are converted to HTML. (${basedir}/doc/site/xdoc).
d) Define a non-default site location, but actually place files in the default
location.
The site.xml is used. (${basedir}/src/site/xdoc).
The resources are NOT copied to the target. (${basedir}/src/site/resources).
The Xdocs are NOT converted to HTML. (${basedir}/src/site/xdoc).
The site location parameter influence both Xdoc and resources, but not the use
of the site.xml.
The resources location parameter does not work at all.
Ability to change the site directory in the plugin configuration in the
pom.xml file.
-
Key: MSITE-151
URL: http://jira.codehaus.org/browse/MSITE-151
Project: Maven 2.x Site Plugin
Type: Improvement
Versions: 2.0-beta-5
Environment: All
Reporter: Mark Soderquist
Fix For: 2.0-beta-5
Attachments: AbstractSiteMojo.diff
Added the ability to change the site directory via the plugin configuration
in the pom.xml file. This completes an existing TODO in the code. Attached is
the SVN diff file for the 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: (MASSEMBLY-104) fileMode doesn't work with Cygwin
[ http://jira.codehaus.org/browse/MASSEMBLY-104?page=comments#action_67928 ] Simon Goodall commented on MASSEMBLY-104: - The problem is a bug in the number parsing. The processFileList method in AbstractAssemblyMojo.java has the following line; archiver.addFile( source, outputDirectory + / + destName, Integer.parseInt( fileItem.getFileMode() ) ); which should read; archiver.addFile( source, outputDirectory + / + destName, Integer.parseInt( fileItem.getFileMode(), 8 ) ); fileMode doesn't work with Cygwin - Key: MASSEMBLY-104 URL: http://jira.codehaus.org/browse/MASSEMBLY-104 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Environment: Windows 2002 XP Pro running Cygwin Reporter: Mark Heinze The fileMode does not correctly set the permissions on the file. This happens in the filesfile/file/files tag in the asssembly XML file. Any files copied with this tag ends up with strange permissions (including those with the default fileMode). -- 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-950) Upload new FindBugs 1.0.0 artifacts to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-950?page=comments#action_67932 ] Jeff Jensen commented on MAVENUPLOAD-950: - Thanks Carlos. The jars hit /maven2/findbugs on June 21 around 10:00 am. Will they automatically update to /maven/findbugs too (and if yes, how long does that typically take?)? Upload new FindBugs 1.0.0 artifacts to ibiblio -- Key: MAVENUPLOAD-950 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-950 Project: maven-upload-requests Type: Improvement Reporter: Jeff Jensen Assignee: Carlos Sanchez Attachments: annotations-1.0.0-bundle.jar, coreplugin-1.0.0-bundle.jar, findbugs-1.0.0-bundle.jar, findbugs-ant-1.0.0-bundle.jar, findbugsGUI-1.0.0-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] Created: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
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
Type: Bug
Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
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] Created: (MANTRUN-54) Provide ability to register (test) resource roots [patch included!]
Provide ability to register (test) resource roots [patch included!]
---
Key: MANTRUN-54
URL: http://jira.codehaus.org/browse/MANTRUN-54
Project: Maven 2.x Antrun Plugin
Type: Improvement
Versions: 1.2
Reporter: Andreas Schildbach
Index:
C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
===
---
C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
(revision 416302)
+++
C:/dev/workspace/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
(working copy)
@@ -18,6 +18,7 @@
import java.io.File;
+import org.apache.maven.model.Resource;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.project.MavenProject;
import org.apache.tools.ant.Target;
@@ -75,6 +76,16 @@
private File testSourceRoot;
/**
+ * @parameter expression=${resourceRoot}
+ */
+private Resource resourceRoot;
+
+/**
+ * @parameter expression=${testResourceRoot}
+ */
+
+private Resource testResourceRoot;
+/**
*/
public void execute()
throws MojoExecutionException
@@ -93,5 +104,16 @@
project.addTestCompileSourceRoot( testSourceRoot.toString() );
}
+if (resourceRoot != null)
+{
+getLog().info(Registering resource root + resourceRoot);
+project.addResource(resourceRoot);
+}
+
+if (testResourceRoot != null)
+{
+getLog().info(Registering test resource root +
testResourceRoot);
+project.addResource(resourceRoot);
+}
}
}
--
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-708) Continuum can not correctly locate modules for multiple module maven 2 projects.
[ http://jira.codehaus.org/browse/CONTINUUM-708?page=comments#action_67942 ] Emmanuel Venisse commented on CONTINUUM-708: actually, it isn't possible to use a pom with modules from a repository, only single pom in repo is supported. If you want to add a multi-module pom in continuum, you should use an http interface of your scm like viewcvs or http svn browser. You can use too the file protocol and take your pom from your local drive. Continuum can not correctly locate modules for multiple module maven 2 projects. Key: CONTINUUM-708 URL: http://jira.codehaus.org/browse/CONTINUUM-708 Project: Continuum Type: Bug Components: Core system Versions: 1.0.3 Environment: Windows 2000, CVS running on windows Reporter: Paul Grove We have a Maven 2 project with mutiple modules we call this the reactor project with the reactor POM. We have the below directory structure for development brokerApp | |POM.xml (reactor pom) | |-webapp1 ||-POM.xml | |-coreAPI ||-POM.xml | |-appEAR ||-POM.xml groupId = com..conceptlabs.brokerApp In the reactor POM we have the following modules modules modulewebapp1/module modulecoreAPI/module moduleappEAR/module /modules When we build and deploy from the Maven 2 reactor POM, we get the following directory structure in our Maven 2 repository. http://conceptlabs1.intranet..co.uk:8080/m2-repo/snapshots/com//conceptlabs/brokerApp/ Under this root we have the following |-brokerApp ||-1.0-SNAPSHOT | |-brokerApp-1.0-20060523.162030-1.pom | |-webapp1 ||-1.0-SNAPSHOT | |-webapp1-1.0-20060523.162030-1.pom | |-coreAPI ||-1.0-SNAPSHOT ||-coreAPI-1.0-20060523.162030-1.pom | |-appEAR ||-1.0-SNAPSHOT ||-appEAR-1.0-20060523.162030-1.pom Continuum can not correctly locate modules for multiple module maven 2 projects. This is the proper location as produced by doing a Maven 2 mvn deploy http://conceptlabs1.intranet..co.uk:8080/m2-repo/snapshots/com//conceptlabs/brokerApp/webapp1/1.0-SNAPSHOT/webapp1-1.0-20060523.162030-1.pom but Continuum for some reason looks here? http://conceptlabs1.intranet..co.uk:8080/m2-repo/snapshots/com//conceptlabs/brokerApp/brokerApp/1.0-SNAPSHOT/brokerApp-1.0-20060523.1620/webapp1/pom.xml: -- 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-128) SCM properties being replaced during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-128?page=comments#action_67943 ]
Joerg Schaible commented on MRELEASE-128:
-
Same for SVN. The plugin should restore the original entries in the trunk (HEAD
revision) again.
SCM properties being replaced during release:perform
Key: MRELEASE-128
URL: http://jira.codehaus.org/browse/MRELEASE-128
Project: Maven 2.x Release Plugin
Type: Bug
Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Attachments: after-release-perform-pom.xml, after-release-prepre-pom.xml,
original-pom.xml
The scm section of a pom in CVS for a pom archetype project looks like this
prior to executing release:prepare :
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
/scm
Then after executing release:prepare, the pom in CVS looks like this (new
tag tag is only difference):
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
tagR-1_7/tag
/scm
Then after executing release:perform, the pom looks like this in CVS:
scm
connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
/scm
Notice that the properties that were there for the base URLs for CVS and
ViewCVS have been replaced with literal values.
No other properties in the POM are being 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] Updated: (MNG-2369) Generic 3rd Party DotNet Libraries not appropriately handled
[ http://jira.codehaus.org/browse/MNG-2369?page=all ] John Casey updated MNG-2369: Component: Multiple Language Support Generic 3rd Party DotNet Libraries not appropriately handled Key: MNG-2369 URL: http://jira.codehaus.org/browse/MNG-2369 Project: Maven 2 Type: Improvement Components: Multiple Language Support, Sandbox Environment: Windows XP Reporter: James Carpenter The csharp plugins work great when using .Net dependencies built with the csharp plugins, but don't work in the general case. Problem Statement: (Note: As a Java developer, I might mess this up a bit.) A .NET assembly contains a manifest which lists the assemblies it depends upon. In addition to checking digital signatures for public assemblies, the classloader (whatever MS calls it) expects the filenames of the dependencies to match that described in the manifest. The problem is the maven repository structure imposes a particular naming convention upon the artifacts placed within it. So you can't just take a third party dll change its name to fit into the maven repo artifact naming convention and create an associated POM. Artifacts built by maven using the csharp plugins match the maven repo artifact naming conventions and the assembly manifests contain dependencies whose names are consistent with the maven repo artifact naming conventions. Tatical Solution: The nasty tatical solution I am currently using, is to simple refer to any 3rd party dlls as system dependencies. (scopesystem/scope) Potential Strategic Solution: I believe the solution is to create another maven artifact type to support 3rd party dlls. The artifact actually stored in the maven repo should be an archieve of some sort (jar, zip, etc.). During the process-resources (some phase prior to compilation, might need custom lifecycle) phase these 3rd party dependencies would be downloaded by the ArtifactResolver and unarchieved in some directory structure which maintains the versioning through directory naming, but not by file name. The dll filename would be the same as the original name of the 3rd party dll (most likely implementation choice is simply to let the archieve maintain the original name). When maven builds the classpath, any artifact of this new type would be represented in the classpath as the path to the unarchieved dll. (The current csharp compiler plugin sees these as the path to the local repo.) I believe, it will actually be necessary to produce two new artifact types. One will be used for managed dependencies and another for native unmanaged dependencies. This distinction is important because the csc (C# compiler) only wants to know about managed dependencies. (See as /resource arguments to csc compiler. Refer to plexus csharp compiler code for details.) I'm not sure my proposed solution is 100% accurate, as I still don't know the maven internals that well, but I think its close. -- 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-2275) profiles should be merged when inherited
[ http://jira.codehaus.org/browse/MNG-2275?page=comments#action_67948 ]
John Casey commented on MNG-2275:
-
profiles aren't designed to be inherited at all, but only injected into the
immediate POM they reference...the behaviors from the profile are then passed
down via normal POM inheritance. Otherwise, managing a local project's build
can become very arcane, since it will have to deal with profiles that magically
appear and start mucking with it's behavior. Also, you get into situations of
multiple inheritance of the same data if you inject a parent POM, then inherit
the profile from parent to child, then inject again in the child. If you only
inject in the child, then you have an issue of parent-POM-profiles taking
precedence over locally-specified properties and such.
profiles should be merged when inherited
Key: MNG-2275
URL: http://jira.codehaus.org/browse/MNG-2275
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Brian Fox
I have some default profiles setup in a super parent pom that all projects
inherit from. In some projects I want to change the active profile, but not
from the CLI because other projects running in the same multi-project build
need to have the normal default. I attempted to work around this by setting
the profile to be active on a property in the child pom. See below for parent
and child. It appears that when I do this, the child profile replaces the
parent. It should be merged so that the properties are pulled from the parent
and uses the activation from the child.
parent:
!-- Setup default profiles. --
profiles
profile
iddev/id
properties
profile-default.valuessrc/main/filters/dev-default.values/profile-default.values
/properties
/profile
profile
idauto-test/id
properties
profile-default.valuessrc/main/filters/auto-test-default.values/profile-default.values
/properties
/profile
profile
idman-test/id
properties
profile-default.valuessrc/main/filters/man-test-default.values/profile-default.values
/properties
/profile
profile
idprod/id
properties
profile-default.valuessrc/main/filters/prod-default.values/profile-default.values
/properties
/profile
/profiles
child pom..
!-- This is the property to override for custom properties in this
project--
properties
client-ct-package.values${user.default.values}/client-ct-package.values
/properties
build
filters
filter${profile-default.values}/filter
filter${user.default.values}/filter
filter${client-ct-package.values}/filter
/filters
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
/build
!-- temporary to activate the CT production values until all projects can
have prod values --
profiles
profile
idprod/id
activation
property
namedeploy-ct/name
/property
/activation
--
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: (SCM-216) CVS Local mode prepends slash to module name during checkout - checkout fails
CVS Local mode prepends slash to module name during checkout - checkout fails -- Key: SCM-216 URL: http://jira.codehaus.org/browse/SCM-216 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Environment: WinXP, WinCVS, Cygwin, Maven 2.0.4 Reporter: Andy Smith Priority: Trivial The cvs scm plugin is appending a slash to the module name when using the release plugin ( also am unable to use continuum in multiproject mode due to a similar issue. If the cvs command printed below is executed the checkout fails. If the leading slash is removed the checkout succeeds ( WinCVS is the client). Fuller details of the problem are on the Continuum list - http://www.nabble.com/cvs-local-checkot-problem-t1826113.html Maven users list.. http://www.nabble.com/Problem-with-release-plugin-w--CVS-...-leading-slash-in-Repository-file--t1799709.html scm connection scm|cvs|local|s:/home/cvsroot| /connection /scm [EMAIL PROTECTED] ~/eclipse_workspace/gsagrid $ mvn release:perform [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'release'. [INFO] [INFO] Building Unnamed - gsa:gsagrid:jar:1.3-SNAPSHOT [INFO]task-segment: [release:perform] (aggregator-style) [INFO] [INFO] [release:perform] [INFO] Checking out the project to perform the release ... [INFO] Executing: cvs -z3 -f -d s:/home/cvsroot -q checkout -r mvngrid1_2 -d checkout /gsagrid -- 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: (MNG-2388) document what gets inherited during project inheritence
[ http://jira.codehaus.org/browse/MNG-2388?page=all ] John Casey updated MNG-2388: Fix Version: 2.0.5 document what gets inherited during project inheritence --- Key: MNG-2388 URL: http://jira.codehaus.org/browse/MNG-2388 Project: Maven 2 Type: Task Components: Documentation: General Reporter: Brett Porter Fix For: 2.0.5 probably also the order things are done between management, inheritence and interpolation -- 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: (MNG-2267) Introduction to Repositories contains incorrect information
[ http://jira.codehaus.org/browse/MNG-2267?page=all ] John Casey updated MNG-2267: Fix Version: 2.0.5 Introduction to Repositories contains incorrect information --- Key: MNG-2267 URL: http://jira.codehaus.org/browse/MNG-2267 Project: Maven 2 Type: Bug Components: Documentation: Introductions Reporter: David Jackman Fix For: 2.0.5 The Introduction to Repositories document contains some incorrect information. I can't be certain everything that's incorrect (if I knew everything already I wouldn't have been reading the page), but here's a list of some things I'm pretty sure are incorrect or incomplete: * Downloading from a Remote Repository talks about build.properties and project.properties, and I thought these were no longer used in Maven 2. * Building Offline section should be expanded a bit. It only makes sense if you already know what it's talking about. * The example in Using the Internal Repository doesn't have a url element, which the previous example does have. * These examples show the tags to use, but give no examples of values for these tags or explain what they mean or how to come up with values. A start-to-finish example of creating a repository and setting a project/environment up to use it would be most helpful. Would that sort of thing belong in this introduction document, or would it be better suited in one of the guide documents? -- 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: (MNG-2284) Cannot specify additional classpath entries in manifest when using addClasspath
[ http://jira.codehaus.org/browse/MNG-2284?page=all ] John Casey updated MNG-2284: Fix Version: 2.0.5 Cannot specify additional classpath entries in manifest when using addClasspath --- Key: MNG-2284 URL: http://jira.codehaus.org/browse/MNG-2284 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Environment: Maven 2.0.4, maven-jar-plugin 2.0 and 2.1-SNAPSHOT, JDK 1.5.0_06, Windows XP Reporter: Fredrik Vraalsen Fix For: 2.0.5 Attachments: MNG-archiver-classpath.patch When using addClasspath, e.g. in the maven-jar-plugin, it is not possible to add additional classpath entries using manifestEntries, as this generates an illegal manifest file (contains two Class-Path entries). Please see http://jira.codehaus.org/browse/MJAR-41 I have been looking through the code, and it seems this might need to be resolved in MavenArchiver? I've attached a simple fix that solves the problem for me, but a more thorough solution might be needed of course. ;-) -- 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-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=comments#action_67949 ] John Casey commented on MNG-2301: - IMO, this could be a vector for introducing false data which may eventually be depended upon (even unintentionally)...I'd tend to say that this file should *always* be generated. What reason do you have for doing this? Maven Archiver deleteing already existing pom.properties file. -- Key: MNG-2301 URL: http://jira.codehaus.org/browse/MNG-2301 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0.4 Reporter: Sharmarke Aden Attachments: maven-archiver_pomDelete.patch My project has it's own pom.properties file and it seems that maven archiver is deleting it right after packaging the application. Any particular reason why it's doing this? It seems to me the archiver shouldn't be deleting the file if it already exists. It should delete the file if it doesn't exists otherwise it should add the necessary information (version, groupId, etc) to the file and leave it be. I have attached a patch that fixes the issue. Also note that this patch adds the builtOn property to the pom.properties which is satisfy the following enhancement request: http://jira.codehaus.org/browse/MNG-1830 -- 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: (MNG-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=all ] John Casey updated MNG-2301: Fix Version: 2.0.5 Maven Archiver deleteing already existing pom.properties file. -- Key: MNG-2301 URL: http://jira.codehaus.org/browse/MNG-2301 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0.4 Reporter: Sharmarke Aden Fix For: 2.0.5 Attachments: maven-archiver_pomDelete.patch My project has it's own pom.properties file and it seems that maven archiver is deleting it right after packaging the application. Any particular reason why it's doing this? It seems to me the archiver shouldn't be deleting the file if it already exists. It should delete the file if it doesn't exists otherwise it should add the necessary information (version, groupId, etc) to the file and leave it be. I have attached a patch that fixes the issue. Also note that this patch adds the builtOn property to the pom.properties which is satisfy the following enhancement request: http://jira.codehaus.org/browse/MNG-1830 -- 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: (MNG-2341) Shell script mvn too old
[ http://jira.codehaus.org/browse/MNG-2341?page=all ] John Casey updated MNG-2341: Fix Version: 2.0.5 Shell script mvn too old Key: MNG-2341 URL: http://jira.codehaus.org/browse/MNG-2341 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0.4 Environment: For *nix OS (Linux, *BSD etc.) Reporter: Vitaly Berdinskikh Fix For: 2.0.5 Shell script not equivalent on content mvn.bat. In mvn use old environment variable MAVEN_HOME instead of M2_HOME: quote ... if [ -z $M2_HOME ] ; then # try to find MAVEN if [ -d /opt/m2 ] ; then MAVEN_HOME=/opt/m2 fi if [ -d $HOME/m2 ] ; then MAVEN_HOME=$HOME/m2 fi ## resolve links - $0 may be a link to maven's home PRG=$0 # need this for relative symlinks while [ -h $PRG ] ; do ls=`ls -ld $PRG` link=`expr $ls : '.*- \(.*\)$'` if expr $link : '/.*' /dev/null; then PRG=$link else PRG=`dirname $PRG`/$link fi done saveddir=`pwd` M2_HOME=`dirname $PRG`/.. # make it fully qualified M2_HOME=`cd $M2_HOME pwd` cd $saveddir # echo Using m2 at $M2_HOME fi ... quote Also in header present old string of copyright, absent description used environment varibles unlike mvn.bat. -- 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: (MNG-2294) If /project/parent/relativePath fails to resolve, no error is reported.
[ http://jira.codehaus.org/browse/MNG-2294?page=all ] John Casey updated MNG-2294: Fix Version: 2.0.5 This is currently done by design. The relativePath is meant only as a hint to the current build. If it fails to resolve, or resolve to the correct version of the parent, then the repository is checked. If the parent isn't resolved on the repository system, then the build fails. However, this is a documentation point that needs to be incorporated. If /project/parent/relativePath fails to resolve, no error is reported. --- Key: MNG-2294 URL: http://jira.codehaus.org/browse/MNG-2294 Project: Maven 2 Type: Bug Versions: 2.0.4 Reporter: David Smiley Fix For: 2.0.5 If I have a bad /project/parent/relativePath specified, maven does not tell me. Instead the build proceeds as if there is no parent. The build should fail if the parent can't be resolved. -- 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: (MNG-2302) SCM path calculations don't work when parent and grandparent are in sibling directories
[ http://jira.codehaus.org/browse/MNG-2302?page=all ] John Casey updated MNG-2302: Fix Version: 2.0.5 SCM path calculations don't work when parent and grandparent are in sibling directories --- Key: MNG-2302 URL: http://jira.codehaus.org/browse/MNG-2302 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.4 Reporter: John Casey Fix For: 2.0.5 I have the following directory structure: -top | +-grandparent | +-parent | +-child where modules are specified in grandparent and parent, respectively, as: module../parent/module and module../child/module When I put these into Continuum, and it tries to use the SCM info provided in the grandparent, it winds up thinking the child directory is a subdirectory of the parent directory. -- 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: (MNG-2290) Generated URLs in POMs of child modules
[ http://jira.codehaus.org/browse/MNG-2290?page=all ]
John Casey updated MNG-2290:
Fix Version: 2.0.5
Generated URLs in POMs of child modules
---
Key: MNG-2290
URL: http://jira.codehaus.org/browse/MNG-2290
Project: Maven 2
Type: Improvement
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Joerg Schaible
Fix For: 2.0.5
Maven has quite some elements where a URL or a path is modified automatically
for child POMs (the ones I am currently aware of):
- url
- scm/connection
- scm/developerConnection
- scm/url
- distributionManagement/site/url
While expanding this path with /${pom.artifactId} sounds reasonable, this
approach fails badly for complex projects with more hierarchy levels. Suppose
we have a directory structure like:
* project
** core
*** provider
commons
impl1
In this hierarchy all POMs for _project_, _core_ and _provider_ are of
package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
artifactId approach now simply assumes that all POMs in the hierarchy are
named like the current directory. This does simply not match. Suppose those
jar artifacts are used in an enterprise or web app. Then every artifact is
located in one single directory and therefore the names have to be unique.
But if you decide to take an artifact name different to the directory name,
you have to add the definition in every POM, because the scm elements are
simply wrong.
An even worse scenario are components that can be provided using different
technologies. We have a lot of such structures:
* component
** jar
** war
** ear
* *_jar_:* the core functionality
* *_war_:* the core functionality integrated and eccessible with a web
application
* *_ear_:* the complete component as enterprise app, if it makes sense to
deploy the functionality on a different app server
_component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
with the according package type. All of the three POMs use the same
artifactId though. In this case not only the scm elements break, but also the
URLs for the site, since they are all the same for all three artifacts.
All of this could have been avoided, if the expanded part is not the
artifactId, but the basename of the current directory. Especially for the scm
elements, this is IMHO the only valid assumption.
It would already help us, if this auto-expansion could be turned off to allow
the definition of a single property in each POM for a correct interpolation
of those values, but there seems no such option ^1^. So you *have to* add
those elements under all circumstances into every POM.
1) The _tagBase_ of the release plugin does no such auto-expansion, which
makes it quite easy to use a property for it, that can be set individually in
every POM without adding any plugin configuration.
--
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: (MNG-2236) DefaultMavenProjectBuilder.buildStandaloneSuperProject() should include a ProfileManager that includes active profiles from settings.xml
[ http://jira.codehaus.org/browse/MNG-2236?page=all ] John Casey updated MNG-2236: Fix Version: 2.0.5 DefaultMavenProjectBuilder.buildStandaloneSuperProject() should include a ProfileManager that includes active profiles from settings.xml Key: MNG-2236 URL: http://jira.codehaus.org/browse/MNG-2236 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.4 Reporter: Aaron Anderson Fix For: 2.0.5 Attachments: patch.txt I have a custom plugin that performs JMX operations using properties defined in a profile. I have defined an active profile in the settings.xml that specifies properties that the plugin uses and everything works fine when a POM is present. Now I would like the plugin to work from any directory and have added the plugin annotation requiresProject=false to it. If I run the plugin in a directory without a POM the profile properties from settings.xml are never loaded. After performing some debugging I have determined that the default super-pom's model that is used when no POM xml file is available does not contain the profile properties defined in settings.xml while if a POM.xml is available the settings.xml profiles are loaded into the POM. This all appears to boil down to the lack of a ProfileManager parameter to thebuildStandaloneSuperProject method defined in the MavenProjectBuilder interface. While DefaultMaven's invocation of the component has a globalProfileManager available (with the active settings profiles set) it cannot be passed into the MavenProjectBuilder component. Alternatively, If the DefaultMavenProjectBuilder had the Settings component injected into it could pass it into the constructor of the DefaultProfileManager instance it creates and then the DefaultProfileManager would load the active profiles into the POM. By enabling this fix it would make plugins useful for management tasks, for example starting or stoping an application server. -- 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: (MNG-2169) Want to contribute: Contributing Maven 2 refcard
[ http://jira.codehaus.org/browse/MNG-2169?page=all ] John Casey updated MNG-2169: Fix Version: 2.0.5 Want to contribute: Contributing Maven 2 refcard Key: MNG-2169 URL: http://jira.codehaus.org/browse/MNG-2169 Project: Maven 2 Type: New Feature Components: Documentation: General Environment: All Reporter: Hans Baier Fix For: 2.0.5 Attachments: MavenQuickReference.pdf, MavenQuickReference.pdf, MavenQuickReference.tex, MavenQuickReference.tex Hello, I want to contribute a refcard for maven, the one I desperately wanted when I started -- 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: (MNG-2311) site plugin i18n HU
[ http://jira.codehaus.org/browse/MNG-2311?page=all ] John Casey updated MNG-2311: Fix Version: 2.0.5 site plugin i18n HU --- Key: MNG-2311 URL: http://jira.codehaus.org/browse/MNG-2311 Project: Maven 2 Type: Improvement Components: Sites Reporting Reporter: Laszlo Hornyak Kocka Fix For: 2.0.5 Attachments: project-info-report_hu.properties, project-info-report_hu.properties, site-plugin_hu.properties hungarian translation of the resource files as described in http://maven.apache.org/plugins/maven-site-plugin/i18n.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: (MNG-2365) classes before test-classes in MavenProject.getTestClasspathElements() - should be the other way around?
[ http://jira.codehaus.org/browse/MNG-2365?page=all ] John Casey updated MNG-2365: Fix Version: 2.0.5 classes before test-classes in MavenProject.getTestClasspathElements() - should be the other way around? Key: MNG-2365 URL: http://jira.codehaus.org/browse/MNG-2365 Project: Maven 2 Type: Bug Versions: 2.0.4 Environment: doesnt matter Reporter: kai lilleby Fix For: 2.0.5 in getTestClasspathElements() we have: List list = new ArrayList( getArtifacts().size() + 1 ); list.add( getBuild().getOutputDirectory() ); list.add( getBuild().getTestOutputDirectory() ); - causing classes to be prior to test-classes in the classpath- something then prohibits test-resources/classes to shadow classes/ resources fom main. .I.e. it is not possible to redefine resources/classes for usage when running tests. Sugested solution: List list = new ArrayList( getArtifacts().size() + 1 ); list.add( getBuild().getTestOutputDirectory() ); list.add( getBuild().getOutputDirectory() ); add test-classes before classes -- 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: (MNG-2384) document how plugin classloaders work
[ http://jira.codehaus.org/browse/MNG-2384?page=all ] John Casey updated MNG-2384: Fix Version: 2.0.5 document how plugin classloaders work - Key: MNG-2384 URL: http://jira.codehaus.org/browse/MNG-2384 Project: Maven 2 Type: Task Components: Documentation: Guides Versions: documentation Reporter: Brett Porter Fix For: 2.0.5 probably in the plugin authoring section: http://mail-archives.apache.org/mod_mbox/maven-users/200509.mbox/[EMAIL PROTECTED] -- 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: (MNG-2383) build lifecycle and executions: documentation fodder
[ http://jira.codehaus.org/browse/MNG-2383?page=all ] John Casey updated MNG-2383: Fix Version: 2.0.5 build lifecycle and executions: documentation fodder Key: MNG-2383 URL: http://jira.codehaus.org/browse/MNG-2383 Project: Maven 2 Type: Improvement Components: Documentation: Guides Versions: documentation Reporter: Brett Porter Fix For: 2.0.5 http://mail-archives.apache.org/mod_mbox/maven-users/200603.mbox/[EMAIL PROTECTED] This looks helpful (and some earlier messages in the thread) in explaining execution binding. Perhaps this should be a section of the documentation to look at -- 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: (MNG-2390) FAQ about why there are no dependency properties, and document how to use an artifact filter instead
[ http://jira.codehaus.org/browse/MNG-2390?page=all ] John Casey updated MNG-2390: Fix Version: 2.0.5 FAQ about why there are no dependency properties, and document how to use an artifact filter instead Key: MNG-2390 URL: http://jira.codehaus.org/browse/MNG-2390 Project: Maven 2 Type: Task Components: Documentation: Guides, Documentation: Faqs Reporter: Brett Porter Fix For: 2.0.5 see: http://mail-archives.apache.org/mod_mbox/maven-users/200511.mbox/[EMAIL PROTECTED] (whole thread) -- 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: (MNG-2386) document how to write packaging plugins
[ http://jira.codehaus.org/browse/MNG-2386?page=all ] John Casey updated MNG-2386: Fix Version: 2.0.5 document how to write packaging plugins --- Key: MNG-2386 URL: http://jira.codehaus.org/browse/MNG-2386 Project: Maven 2 Type: Task Components: Documentation: Guides Reporter: Brett Porter Fix For: 2.0.5 we particularly need to highlight that this: project.getArtifact().setFile( fileYouGenerated ) must be called, as well as referencing the appropriate components definitions from the lifecycle introduction. (ideally, we could get rid of the requirement for the above, but it is a necessity in 2.0) -- 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: (MNG-2385) incorporate plugin configuration conventions into the standard directory layout
[ http://jira.codehaus.org/browse/MNG-2385?page=all ] John Casey updated MNG-2385: Fix Version: 2.0.5 incorporate plugin configuration conventions into the standard directory layout --- Key: MNG-2385 URL: http://jira.codehaus.org/browse/MNG-2385 Project: Maven 2 Type: Task Components: Documentation: General Reporter: Brett Porter Fix For: 2.0.5 see: http://mail-archives.apache.org/mod_mbox/maven-users/200601.mbox/[EMAIL PROTECTED] we need a standard way to locate config for modello, checkstyle, etc. we may also want to later adopt this as a way of setting a convenient default for location some configuration. Note also that this may involved being able to turn such configuration into an artifact (perhaps a group of them) so that it can be used from multiple projects without having to cutpaste -- 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: (MNG-1496) Ancient documentation is confusing users.
[ http://jira.codehaus.org/browse/MNG-1496?page=all ] John Casey updated MNG-1496: Fix Version: 2.0.5 Ancient documentation is confusing users. - Key: MNG-1496 URL: http://jira.codehaus.org/browse/MNG-1496 Project: Maven 2 Type: Improvement Environment: N/A Reporter: Joakim Erdfelt Priority: Minor Fix For: 2.0.5 Attachments: listing.txt.gz I work in an environment where maven has been in active use since pre-1.0 days. The users and developers here have links to documentation on the maven.apache.org website that points to bad or old documentation. Can they be removed, or better yet have an apache url rewrite to the appropriate page? Examples of ones I've found. http://maven.apache.org/reference/plugins/core-plugins.html From November 2003 - so old it mentions ApacheCon 2003 and maven 1.0-rc2-SNAPSHOT http://maven.apache.org/reference/plugins/optional/optional.html From March 2004 Both of those should redirect to http://maven.apache.org/reference/plugins/index.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: (MCLOVER-38) Allow check Mojo to be overriden by a ${clover.failOnViolation} parameter in the same way pmd and checkstyle can
[ http://jira.codehaus.org/browse/MCLOVER-38?page=comments#action_67958 ]
John Allen commented on MCLOVER-38:
---
Hi Vincent,
Same use case as the PMD:check, Checkstyle:check and Surefire:test Mojos -
namely that the flexibility to circumvent certain aspects of a 'governance'
build (which as you quite rightly say is setup by profile) is very useful. And
just as important is that we should be striving for consistency across plugins
with similiar lifecycle semantics (i.e. mojos that check that policy is adhered
to).
Also worthy of note is that i may wish to run the complete governance build
from beginning to end to determine which aspects of the build do not adhere to
the defined governance policy, ie. n PMD/Checkstyle violations, actual coverage
being less than policy specified minimum n% or a test failure. If each check
Mojo failed the build immediately, with no option to simply print a warning
message out stating that it has failed to pass the governance policy, one would
have to fix that failure before proceeding to the next aspect of the governance
build.
Note that IMO controlling each aspect of governance build with a seprate
profile is not applicable, a profile is for use by developers and as such
having to specify multiple profiles on the CLI is not very convient, not to
mention the fact that by not running the clover:check Mojo I will not know
whether it would fail the defined policy.
Allow check Mojo to be overriden by a ${clover.failOnViolation} parameter in
the same way pmd and checkstyle can
Key: MCLOVER-38
URL: http://jira.codehaus.org/browse/MCLOVER-38
Project: Maven 2.x Clover Plugin
Type: Improvement
Versions: 2.1
Environment: 2.0.4
Reporter: John Allen
Priority: Minor
Add a ${clover.failOnViolation} parameter to allow a check failure to be
overriden on the command line in line with the PMD and Checkstyle check Mojos
--
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: (MNG-2190) -Dkey=value parameters cannot include spaces in the value
[ http://jira.codehaus.org/browse/MNG-2190?page=all ] John Casey updated MNG-2190: Fix Version: 2.0.5 -Dkey=value parameters cannot include spaces in the value - Key: MNG-2190 URL: http://jira.codehaus.org/browse/MNG-2190 Project: Maven 2 Type: Bug Components: Command Line Versions: 2.0.2 Environment: Darwin Reporter: Gordon Henriksen Assignee: Brett Porter Fix For: 2.0.5 Attachments: MNG-2190.patch Even if I properly escape spaces in a path at the shell level, Maven seems to re-split the command parameters. For instance, on Unix, the following should all run the compile goal with a property foo=bar baz: $ mvn compile -Dfoo=bar baz $ mvn compile -Dfoo=bar baz $ mvn compile -Dfoo=bar\ baz But in fact, Maven fails, complaining that baz is an invalid task: [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'baz': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Mar 29 15:21:01 EST 2006 [INFO] Final Memory: 1M/2M [INFO] Is this intended behavior? Seems as if Maven is unnecessarily splitting the string, when the OS already does as much. I was merely trying to run: mvn deploy:deploy-file -Dfile=/Users/me/Desktop/Bellicose SDK/lib/Bellicose.jar ... In my case, it's practical to work around by renaming the Bellicose SDK folder, but it seems as if Windows users stuck with C:\Documents and Settings\... might have a harder time of it. -- 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: (MNG-1390) @requiresDependencyResolution in process-classes post compile
[ http://jira.codehaus.org/browse/MNG-1390?page=all ]
John Casey updated MNG-1390:
Fix Version: 2.0.5
@requiresDependencyResolution in process-classes post compile
-
Key: MNG-1390
URL: http://jira.codehaus.org/browse/MNG-1390
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0
Reporter: Jesse McConnell
Fix For: 2.0.5
Original Estimate: 3 hours
Remaining: 3 hours
I was looking back into some plugins I had written a while back and ran
across an oddity.
it appears that when using a plugin in the process-classes phase, after the
compiler plugin has done its thing, the @requiresDependencyResolution javadoc
flag will toggle the presense of dependencies that are scoped to provided in
the dependencies section when calling project.getCompileClasspathElements();
(a difference of 80 vs 24 when not using the flag and then using it)
---
this are two snippits of code from the plugin
/**
* A plugin for generating * java file containing all the classes in a src
tree.
*
* @goal generate
* @requiresDependencyResolution
* @description Functions Generator plugin
* @author jesse [EMAIL PROTECTED]
*/
List classpathFiles = project.getCompileClasspathElements();
URL[] urls = new URL[classpathFiles.size() + 1];
getLog().debug( + classpathFiles.size());
for (int i = 0; i classpathFiles.size(); ++i) {
getLog().debug((String)classpathFiles.get(i));
urls[i] = new File((String)classpathFiles.get(i)).toURL();
}
urls[classpathFiles.size()] = new File( buildDirectory + /classes
).toURL();
URLClassLoader ucl = new URLClassLoader(urls,
Thread.currentThread().getContextClassLoader());
being used with the following plugin declaration:
plugin
groupIdgallup.maven/groupId
artifactIdservices-provider-maven-plugin/artifactId
version1.0.1/version
configuration
fullyQualifiedFileNamecom/g/util/ServiceProvider.java/fullyQualifiedFileName
/configuration
executions
execution
phaseprocess-classes/phase
goals
goalgenerate/goal
/goals
/execution
/executions
/plugin
analyzing the debug output when I run the plugin without the
@requiresDependencyResolution I get 80 dependencies and it builds out the
classloader correctly..
but if I add the @requiresDependencyResolution statement I go down to 24
dependencies being put into the classloader...and the discrepency corresponds
to the presense of the scopeprovided/scope statement.
--
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: (MNG-1275) Properties and references created by the pom and dependencies tasks don't persist across ant/subant task invocations.
[ http://jira.codehaus.org/browse/MNG-1275?page=all ] John Casey updated MNG-1275: Fix Version: 2.1 Properties and references created by the pom and dependencies tasks don't persist across ant/subant task invocations. --- Key: MNG-1275 URL: http://jira.codehaus.org/browse/MNG-1275 Project: Maven 2 Type: Bug Components: Ant tasks Versions: 2.0 (RC) Environment: Fedora Core 4 Reporter: Xavier Toth Fix For: 2.1 Attachments: build.xml, taskDefs.xml, test-build.xml Properties and references created by the pom and dependencies tasks don't persist across ant/subant task invocations. I've included some ant scripts. If you create a test-build dir and put build.xml and taskDefs.xml in it and then run ant -f test-build.xml from the parent dir of test-build you will see the problem in the output. -- 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: (MNG-2140) Mojo in forked lifecycle invoked in reactor build cannot find reactor dependency
[ http://jira.codehaus.org/browse/MNG-2140?page=all ] John Casey updated MNG-2140: Fix Version: 2.1 Mojo in forked lifecycle invoked in reactor build cannot find reactor dependency Key: MNG-2140 URL: http://jira.codehaus.org/browse/MNG-2140 Project: Maven 2 Type: Bug Components: Reactor and workspace Versions: 2.0.2 Reporter: Grzegorz Slowikowski Fix For: 2.1 Attachments: test.zip In multiproject I have two modules. One of them (lets name it main) depends on the second one (util). If I bind forking lifecycle mojo in the main artifact pom, that mojo does not find util artifact and tries to find it in local and remote repositories. If the same mojo does not for lifecycle, reactor build finishes with success. I attach an example: - plugin with two mojos writing something to the log, one of them forks lifecycle, second - does not - test multiproject using test mojo There are some plugins forking lifecycles, so I think this can be serious problem. I would love to see its priority to Blocker for Maven 2.0.3 -- 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: (MNG-1497) remove old html files from the site
[ http://jira.codehaus.org/browse/MNG-1497?page=all ] John Casey updated MNG-1497: Fix Version: 2.0.5 remove old html files from the site --- Key: MNG-1497 URL: http://jira.codehaus.org/browse/MNG-1497 Project: Maven 2 Type: Improvement Reporter: Alex Wood Priority: Minor Fix For: 2.0.5 The Maven Directory Layout page (http://maven.apache.org/reference/dirlayout.html) notes for the src directory that The code may be placed into separate source code directories by language, as in src/java/ and src/php/ for source code in the Java and PHP languages respectively. The separation into directories according to function (src/share, src/core, src/web) is currently not supported by Maven. It is highly recommended that sub-directories be used under src/. The Maven Conventions Page (http://maven.apache.org/reference/conventions.html) advises that projects should follow another directory structure: src/main/$LANGUAGE, src/test/$LANGUAGE, src/site/xdocs, etc. To me this seems to contradict the statement that Maven doesn't support separation into directories according to function. The examples given of structures to avoid (src/core and src/web) match closely to what's encouraged elsewhere (src/main and src/site). The directory layout page is marked as being for v1.0.2, but the conventions page is not marked with a version. If the conventions are different for different versions, clearer labeling is needed. If the conventions are constant across versions, then the documentation should be changed so that it is not contradicting itself. -- 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: (MNG-2275) profiles should be merged when inherited
[ http://jira.codehaus.org/browse/MNG-2275?page=all ]
John Casey updated MNG-2275:
Fix Version: 2.1
profiles should be merged when inherited
Key: MNG-2275
URL: http://jira.codehaus.org/browse/MNG-2275
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Brian Fox
Fix For: 2.1
I have some default profiles setup in a super parent pom that all projects
inherit from. In some projects I want to change the active profile, but not
from the CLI because other projects running in the same multi-project build
need to have the normal default. I attempted to work around this by setting
the profile to be active on a property in the child pom. See below for parent
and child. It appears that when I do this, the child profile replaces the
parent. It should be merged so that the properties are pulled from the parent
and uses the activation from the child.
parent:
!-- Setup default profiles. --
profiles
profile
iddev/id
properties
profile-default.valuessrc/main/filters/dev-default.values/profile-default.values
/properties
/profile
profile
idauto-test/id
properties
profile-default.valuessrc/main/filters/auto-test-default.values/profile-default.values
/properties
/profile
profile
idman-test/id
properties
profile-default.valuessrc/main/filters/man-test-default.values/profile-default.values
/properties
/profile
profile
idprod/id
properties
profile-default.valuessrc/main/filters/prod-default.values/profile-default.values
/properties
/profile
/profiles
child pom..
!-- This is the property to override for custom properties in this
project--
properties
client-ct-package.values${user.default.values}/client-ct-package.values
/properties
build
filters
filter${profile-default.values}/filter
filter${user.default.values}/filter
filter${client-ct-package.values}/filter
/filters
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
/build
!-- temporary to activate the CT production values until all projects can
have prod values --
profiles
profile
idprod/id
activation
property
namedeploy-ct/name
/property
/activation
--
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: (MNG-2038) A mini guide covering the interplay between SCM and maven releases
[ http://jira.codehaus.org/browse/MNG-2038?page=all ] John Casey updated MNG-2038: Fix Version: 2.0.5 A mini guide covering the interplay between SCM and maven releases -- Key: MNG-2038 URL: http://jira.codehaus.org/browse/MNG-2038 Project: Maven 2 Type: Improvement Components: Documentation: Guides Reporter: Julian Wood Priority: Minor Fix For: 2.0.5 Attachments: project_process.apt Emmanuel Venisse asked if I would contribute this document, so here it is. It is a step by step guide which covers releasing a project using maven, but also demonstrates some best practices when it comes to making branches, tags, and of course versions, all while touching on how maven makes these practices so much less of a headache. -- 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: (MCLEAN-9) maven-clean-plugin doesn't remove the reporting output directory ${project.reporting.outputDirectory}
[ http://jira.codehaus.org/browse/MCLEAN-9?page=all ]
John Casey moved MNG-1881 to MCLEAN-9:
--
Version: (was: 2.0.1)
2.1
Component: (was: Plugins and Lifecycle)
Complexity: (was: Novice)
Key: MCLEAN-9 (was: MNG-1881)
Project: Maven 2.x Clean Plugin (was: Maven 2)
maven-clean-plugin doesn't remove the reporting output directory
${project.reporting.outputDirectory}
-
Key: MCLEAN-9
URL: http://jira.codehaus.org/browse/MCLEAN-9
Project: Maven 2.x Clean Plugin
Type: Improvement
Versions: 2.1
Environment: Linux FC4, sun jdk1.5
Reporter: mark struberg
Priority: Minor
Attachments: MNG-1881-maven-clean-plugin.diff
DESCRIPTION:
The maven-clean-plugin does only remove the directories given in the build
section of the POM.
Directories created by the other standard lifecycle sections like the
reporting section of the POM will not be removed by the clean mojo.
I see 2 ways to fix this issue:
1.) (which 1 prefere) Provide all clean actions for the other standard
lifecyles too inside the maven-clean-plugin
2.) Add new mojos with the @goal clean to the corresponding maven-plugins,
like ie the maven-site-plugin
TESTCASE (pom.xml):
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdat.struct.mvntest/groupId
artifactIdmvntest/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
nameMSX Maven Test App/name
build
directorymsxtarget/directory
outputDirectorymsxtarget/classes/outputDirectory
/build
reporting
outputDirectorymsxreports/outputDirectory
/reporting
/project
PATCH:
Added
removeDirectory( reportingOutputDirectory );
to CleanMojo.java
Maybe there are also other directories to be removed in the same way
--
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: (MNG-1204) don't show disabled repositories in artifact exceptions
[ http://jira.codehaus.org/browse/MNG-1204?page=all ] John Casey updated MNG-1204: Fix Version: 2.0.5 don't show disabled repositories in artifact exceptions --- Key: MNG-1204 URL: http://jira.codehaus.org/browse/MNG-1204 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Assignee: Edwin Punzalan Priority: Minor Fix For: 2.0.5 Attachments: MNG-1204-maven-artifact.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] Created: (WAGON-52) wagon-webdav does not ask for auth password when username.../username is missing
wagon-webdav does not ask for auth password when username.../username is missing Key: WAGON-52 URL: http://jira.codehaus.org/browse/WAGON-52 Project: wagon Type: Bug Components: wagon-webdav Versions: 1.0-beta-1 Environment: Linux and Windows Reporter: Bernhard Wellhöfer We use as internal repository a WebDav server with BASIC authentication. Only internal developers have access to this WebDav server and so e.g. internship students do not have access to company jars. Now when the server definition in settings.xml does not contain the username.../username element, then wagon-webdav should ask once for the missing password on the command line. Right now it just 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] Updated: (WAGON-52) wagon-webdav does not ask for auth password when username.../username is missing
[ http://jira.codehaus.org/browse/WAGON-52?page=all ] Carlos Sanchez updated WAGON-52: Component: (was: wagon-webdav) type: Improvement (was: Bug) None of the wagons do that. In any case requires a change in the way it works wagon-webdav does not ask for auth password when username.../username is missing Key: WAGON-52 URL: http://jira.codehaus.org/browse/WAGON-52 Project: wagon Type: Improvement Versions: 1.0-beta-1 Environment: Linux and Windows Reporter: Bernhard Wellhöfer We use as internal repository a WebDav server with BASIC authentication. Only internal developers have access to this WebDav server and so e.g. internship students do not have access to company jars. Now when the server definition in settings.xml does not contain the username.../username element, then wagon-webdav should ask once for the missing password on the command line. Right now it just 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] Commented: (MAVENUPLOAD-950) Upload new FindBugs 1.0.0 artifacts to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-950?page=comments#action_67967 ] Carlos Sanchez commented on MAVENUPLOAD-950: /maven is a redirect to /maven2 so they are available for m1 Upload new FindBugs 1.0.0 artifacts to ibiblio -- Key: MAVENUPLOAD-950 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-950 Project: maven-upload-requests Type: Improvement Reporter: Jeff Jensen Assignee: Carlos Sanchez Attachments: annotations-1.0.0-bundle.jar, coreplugin-1.0.0-bundle.jar, findbugs-1.0.0-bundle.jar, findbugs-ant-1.0.0-bundle.jar, findbugsGUI-1.0.0-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] Created: (MEV-417) Wrong dependency on itext in jfreereport poms
Wrong dependency on itext in jfreereport poms - Key: MEV-417 URL: http://jira.codehaus.org/browse/MEV-417 Project: Maven Evangelism Type: Improvement Components: Invalid POM, Dependencies Reporter: Grégory Joseph In http://www.ibiblio.org/maven2/jfree/jfreereport/0.8.5-5/jfreereport-0.8.5-5.pom, there is a dependency to itext:itext:1.2.3 However, as 1)itext:itext has been relocated to com.lowagie:itext 2) no 1.2.3 version exists in the repository, my application, which depends on com.lowagie:itext:1.3.1 can't be built, because maven complains about a missing itext:itext:1.2.3 artifact. (Same if i set my dependency on itext:itext:1.3.1.) I suppose there are two solutions to this: either create a relocation pom for itext:itext:1.2.3, but there's not com.lowagie:itext:1.2.3 to redirect to, or update the dependency in the jfreereport poms to com.lowagie:itext:1.2.3 . I've done the latter locally, and eventhough 1.2.3 does not exist, since my app depends on 1.3.1, it just works. Please let me know if I can help or provide more 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] Updated: (MNG-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated
[ http://jira.codehaus.org/browse/MNG-1943?page=all ]
John Casey updated MNG-1943:
Fix Version: (was: 2.0.5)
2.1
MavenProject::getParent() returns a MavenProject that is NOT interpolated
-
Key: MNG-1943
URL: http://jira.codehaus.org/browse/MNG-1943
Project: Maven 2
Type: Bug
Reporter: John Allen
Priority: Blocker
Fix For: 2.1
Plugin developers repeatedly use ${project}.getParent().someMethod() yet
getParent() returns a project that has not been interpolated. This obviously
needs to be fixed but may I also suggest that all plugin acceptance testing
is revisted to ensure that the tests use POMs that are littered with property
expressions and not literals.
--
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: (MNG-2145) Plugins' dependencies are not always checked
[ http://jira.codehaus.org/browse/MNG-2145?page=all ] John Casey updated MNG-2145: Fix Version: (was: 2.0.5) 2.1 this has to do with plugins not being reconfigured inside a multmodule project, I think. It's a lifecycle/plugin management issue. Plugins' dependencies are not always checked Key: MNG-2145 URL: http://jira.codehaus.org/browse/MNG-2145 Project: Maven 2 Type: Bug Components: Dependencies Versions: 2.0.2 Reporter: Daiyam Priority: Blocker Fix For: 2.1 Attachments: pom-echo.xml, pom-merge.xml, pom-profile.xml, pom.xml, test-suite.zip I want to run two ant task, one on the phase 'generate-sources' which contains a dependency and another on the phase 'package'. When I want to compile with the project like that, maven don't check the dependency. But when I comment the plugin on the phase 'package', maven check it. PS: In the pom.xml in attachement, maven must check the library junit:junit:jar:30.80.10 (which don't exsist) -- 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: (MNG-2219) artifactId appended to URL in scm reports. Problem apparently comes from the core.
[ http://jira.codehaus.org/browse/MNG-2219?page=all ] John Casey updated MNG-2219: Fix Version: 2.0.5 artifactId appended to URL in scm reports. Problem apparently comes from the core. -- Key: MNG-2219 URL: http://jira.codehaus.org/browse/MNG-2219 Project: Maven 2 Type: Bug Reporter: Jerome Lacoste Fix For: 2.0.5 See MPIR-42 for description of the issue. This issue is supposedly already reported but I wasn't able to find it. Feel free to duplicate it against the correct one. I have several users of the webstart plugin confused because the rendered scm information is incorrect. -- 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: (MNG-1731) I18n issues with report generation
[ http://jira.codehaus.org/browse/MNG-1731?page=all ] John Casey updated MNG-1731: Fix Version: 2.0.5 I18n issues with report generation -- Key: MNG-1731 URL: http://jira.codehaus.org/browse/MNG-1731 Project: Maven 2 Type: Wish Versions: 2.0 Reporter: Anuerin Diaz Fix For: 2.0.5 The issue wherein report generation of certain plugins (or mix) causes the site/build phase to fail has already been logged before (see http://jira.codehaus.org/browse/MNG-1572). It might be better for the report component to have a way of falling back to a default locale especially when the locale was not explicitly defined in the project descriptor. -- 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: (MNG-1759) URLs only link if they are FQDNs
[ http://jira.codehaus.org/browse/MNG-1759?page=all ] John Casey updated MNG-1759: Fix Version: 2.0.5 URLs only link if they are FQDNs Key: MNG-1759 URL: http://jira.codehaus.org/browse/MNG-1759 Project: Maven 2 Type: Bug Versions: 2.0 Reporter: Mike Perham Fix For: 2.0.5 We are trying to create internal site documentation for our projects with links to our Confluence user home pages: developer idmperham/id urlhttp://wiki:9090/display/~mperham/url /developer But the project info report does not link this URL. If I add .com or .org to the end of it, it does link so I suspect the validation is just a little over-zealous. It should just link whatever the user puts in there. -- 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: (MNG-2351) mvn -X doesn't enable debugging
[ http://jira.codehaus.org/browse/MNG-2351?page=all ] John Casey updated MNG-2351: Fix Version: 2.0.5 mvn -X doesn't enable debugging --- Key: MNG-2351 URL: http://jira.codehaus.org/browse/MNG-2351 Project: Maven 2 Type: Bug Components: Embedding Versions: 2.1 Reporter: Jerome Lacoste Fix For: 2.0.5 mvn -X doesn't enable debugging If I add the following code to DefaultMaven.execute(...) public void execute( MavenExecutionRequest request ) throws MavenExecutionException [...] loggerManager.setThreshold( request.getLoggingLevel() ); // ADDED loggerManager.getLoggerForComponent( Maven.ROLE ).info( XXX logging level + request.getLoggingLevel()); loggerManager.getLoggerForComponent( Maven.ROLE ).debug( XXX logging level + request.getLoggingLevel()); System.err.println(XXX logging level + request.getLoggingLevel()); System.err.println(XXX show errors + request.isShowErrors()); System.err.println(XXX logger threshold + loggerManager.getLoggerForComponent( Maven.ROLE ).getThreshold()); // end of ADDED I get: [INFO] XXX logging level 0 XXX logging level 0 XXX show errors true XXX logger threshold 1 Looks like something is wrong with regard to thresholds in the Maven.ROLE component. -- 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: (MNG-2355) Documentation of the @component javadoc tag
[ http://jira.codehaus.org/browse/MNG-2355?page=all ] John Casey updated MNG-2355: Fix Version: 2.0.5 Documentation of the @component javadoc tag --- Key: MNG-2355 URL: http://jira.codehaus.org/browse/MNG-2355 Project: Maven 2 Type: Improvement Components: Documentation: General Reporter: Scott Cytacki Fix For: 2.0.5 While trying to figure out how the AbstractCompilerMojo worked, I found the @component tag for the compilerManager field. There is a reference page for the mojo-api-spec, but this page doesn't talk about the component tag. That page seems like a logical place to put this documentation, or at least a reference to it if it is already somewhere else. -- 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: (MNG-2091) NPE when including middlegen-hibernate-plugin
[ http://jira.codehaus.org/browse/MNG-2091?page=all ] John Casey updated MNG-2091: Fix Version: 2.0.5 NPE when including middlegen-hibernate-plugin - Key: MNG-2091 URL: http://jira.codehaus.org/browse/MNG-2091 Project: Maven 2 Type: Bug Components: Plugin API Versions: 2.2 Environment: SUSE Linux 9.3 on i386; JVM: 1.5.0_04-b05; Kernel: 2.6.11.4.20a-11-default Reporter: Bernd Adamowicz Fix For: 2.0.5 As soon as the plugin middlegen-hibernat-plugin is integrated into the POM, a NPE is thrown when the plugin is added. This is the stacktrace: [EMAIL PROTECTED]:~/THEMEN/ECLIPSE_WORKBENCH/Buttenlauf mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building Buttenlauf Auswertung - GVC Criesbach [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:295) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:950) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:450) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Mon Feb 20 21:04:30 CET 2006 [INFO] Final Memory: 1M/4M [INFO] This is how the Middlegen-part of the POM looks like: build plugins plugin groupIdmiddlegen/groupId artifactIdmiddlegen-hibernate-plugin/artifactId version2.1/version /plugin plugin I know this issue has been around with Maven 1.x. The cause there was a corrupted plugin pom from middlegen. But I wasn't able to reproduce this. I couldn't find anything wrong with the pom. This problem can be reproduced with Maven 2.0 and on Windows systems, too. So I think the problem really is the plugin. I will open an issue on the Middlegen page, too and will (hopefully) post a solution here. But maybe someone has a workaround to fix this in the meantime. Thanks in advance for any help. Bernd -- 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: (MNG-2253) Improve documentation on multi-projects
[ http://jira.codehaus.org/browse/MNG-2253?page=all ] John Casey updated MNG-2253: Fix Version: 2.0.5 Improve documentation on multi-projects --- Key: MNG-2253 URL: http://jira.codehaus.org/browse/MNG-2253 Project: Maven 2 Type: Improvement Components: Documentation: General Versions: documentation Reporter: Torsten Curdt Fix For: 2.0.5 Simon gives a nice overview about how multi-projects work. Would be worth having all this information in the documentation somewhere http://www.mail-archive.com/users@maven.apache.org/msg41444.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: (MNG-2164) Generated plugin documentation lists wrong data type
[ http://jira.codehaus.org/browse/MNG-2164?page=all ] John Casey updated MNG-2164: Fix Version: 2.0.5 Generated plugin documentation lists wrong data type Key: MNG-2164 URL: http://jira.codehaus.org/browse/MNG-2164 Project: Maven 2 Type: Bug Components: Plugin Creation Tools Versions: 2.0.2 Reporter: Mike Perham Fix For: 2.0.5 Attachments: MPLUGIN-12-maven-plugin-tools-java.patch The PMD Report has a String[] rulesets parameter. The generated documentation says that rulesets is of type String. -- 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: (MNG-2306) mojo javadoc annotations support for IntelliJ Idea
[ http://jira.codehaus.org/browse/MNG-2306?page=all ] John Casey updated MNG-2306: Fix Version: 2.0.5 mojo javadoc annotations support for IntelliJ Idea -- Key: MNG-2306 URL: http://jira.codehaus.org/browse/MNG-2306 Project: Maven 2 Type: Improvement Components: Sites Reporting Reporter: Roald Bankras Fix For: 2.0.5 Attachments: MNG-2306.txt I've created Live templates config file for the mojo javadoc annotations. This file can be made available through the maven site (i.e. on the mojo-api-specification page). -- 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: (MNG-1929) Plugin Goal report should indicate which fields are read only. (Patch Attached)
[ http://jira.codehaus.org/browse/MNG-1929?page=all ] John Casey updated MNG-1929: Fix Version: 2.0.5 Plugin Goal report should indicate which fields are read only. (Patch Attached) --- Key: MNG-1929 URL: http://jira.codehaus.org/browse/MNG-1929 Project: Maven 2 Type: Improvement Components: Plugin API Reporter: Brian Fox Fix For: 2.0.5 Attachments: dontshowreadonly.patch, plugin-tools-api.patch The report shows which fields are discovered and optional, but not which are read only. This can lead to some newby confusion where they think every field needs to be defined. -- 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: (MNG-2378) incorporate Jesse's description of the directory structure
[ http://jira.codehaus.org/browse/MNG-2378?page=all ] John Casey updated MNG-2378: Fix Version: 2.0.5 incorporate Jesse's description of the directory structure -- Key: MNG-2378 URL: http://jira.codehaus.org/browse/MNG-2378 Project: Maven 2 Type: Improvement Components: Documentation: General Versions: documentation Reporter: Brett Porter Fix For: 2.0.5 http://mail-archives.apache.org/mod_mbox/maven-users/200508.mbox/[EMAIL PROTECTED] this struck me as being useful -- 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: (MNG-2379) review and link to free Maven courseware
[ http://jira.codehaus.org/browse/MNG-2379?page=all ] John Casey updated MNG-2379: Fix Version: 2.0.5 review and link to free Maven courseware Key: MNG-2379 URL: http://jira.codehaus.org/browse/MNG-2379 Project: Maven 2 Type: Improvement Components: Documentation: General Versions: documentation Reporter: Brett Porter Fix For: 2.0.5 http://cvs.peopleware.be/training/maven/maven2/ Could be in the articles/books section -- 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: (MNG-2223) Interpolation in resources section appears not to work correctly
[ http://jira.codehaus.org/browse/MNG-2223?page=all ]
John Casey updated MNG-2223:
Fix Version: 2.0.5
Interpolation in resources section appears not to work correctly
Key: MNG-2223
URL: http://jira.codehaus.org/browse/MNG-2223
Project: Maven 2
Type: Bug
Versions: 2.0.4
Reporter: Jason van Zyl
Fix For: 2.0.5
This is captured by it0091 and reported by David Kulp. This might be
duplicated because I'm sure I put this in JIRA.
This may specifically be a property which is a boolean value, or a general
interpolation problem in the resources section.
project
modelVersion4.0.0/modelVersion
groupIdorg.apache.maven.it/groupId
artifactIdmaven-core-it0090/artifactId
version1.0/version
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
typejar/type
scopetest/scope
/dependency
/dependencies
properties
filter.resourcestrue/filter.resources
namejason/name
/properties
build
resources
resource
directorysrc/main/resources/directory
filtering${filter.resources}/filtering
/resource
/resources
/build
/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: (MNG-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
[ http://jira.codehaus.org/browse/MNG-2234?page=all ] John Casey updated MNG-2234: Fix Version: 2.0.5 activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty Key: MNG-2234 URL: http://jira.codehaus.org/browse/MNG-2234 Project: Maven 2 Type: Bug Versions: 2.0.4 Reporter: Manfred Geiler Fix For: 2.0.5 When i have this settings.xml file in my user home dir, the activeProfile setting is simply ignored by Maven: settings activeProfiles activeProfileenv-test/activeProfile /activeProfiles /settings Adding an empty profiles section does not help: settings profiles /profiles activeProfiles activeProfileenv-test/activeProfile /activeProfiles /settings Well, adding a dummy profile makes it work: settings profiles profile iddummy/id /profile /profiles activeProfiles activeProfileenv-test/activeProfile /activeProfiles /settings Funny, isn't it? Regards, Manfred -- 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: (MNG-2392) document relativePath/
[ http://jira.codehaus.org/browse/MNG-2392?page=all ] John Casey updated MNG-2392: Fix Version: 2.0.5 document relativePath/ Key: MNG-2392 URL: http://jira.codehaus.org/browse/MNG-2392 Project: Maven 2 Type: Task Components: Documentation: General Reporter: Brett Porter Fix For: 2.0.5 see: http://mail-archives.apache.org/mod_mbox/maven-users/200511.mbox/[EMAIL PROTECTED] -- 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: (MNG-2393) documentation of -U on CLI usage help is incorrect
[ http://jira.codehaus.org/browse/MNG-2393?page=all ] John Casey updated MNG-2393: Fix Version: 2.0.5 documentation of -U on CLI usage help is incorrect -- Key: MNG-2393 URL: http://jira.codehaus.org/browse/MNG-2393 Project: Maven 2 Type: Task Components: Documentation: General Reporter: Brett Porter Fix For: 2.0.5 see: http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/[EMAIL PROTECTED] -- 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: (MNG-1325) Document ibiblio synchronization process
[ http://jira.codehaus.org/browse/MNG-1325?page=all ] John Casey updated MNG-1325: Fix Version: 2.0.5 Document ibiblio synchronization process Key: MNG-1325 URL: http://jira.codehaus.org/browse/MNG-1325 Project: Maven 2 Type: Task Reporter: Carlos Sanchez Assignee: Carlos Sanchez Fix For: 2.0.5 -- 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: (MNG-2188) Report mojos should check canGenerateReport() when called directly
[ http://jira.codehaus.org/browse/MNG-2188?page=all ]
John Casey updated MNG-2188:
Fix Version: 2.0.5
Report mojos should check canGenerateReport() when called directly
--
Key: MNG-2188
URL: http://jira.codehaus.org/browse/MNG-2188
Project: Maven 2
Type: Improvement
Components: Sites Reporting
Versions: 2.0.3
Reporter: Vincent Massol
Fix For: 2.0.5
Attachments: AbstractMavenReport-canGenerateReport-check.patch
There's a canGenerateReport() method in a ReportMojo. This method is called
by the site phase to decide if the mojo should be called or not. This is
cool. However the user can call directly the report mojo and in that case the
canGenerateReport() method is not called automatically. Thus the solution for
a plugin developer is to write:
{code}
public void executeReport()
{
if (canGenerateReport() )
{
[...]
}
}
{code}
Which means that the canGenerateReport method is going to be called twice
when mvn site is executed.
--
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: (MNG-2213) Current settings.xml example incorrect
[ http://jira.codehaus.org/browse/MNG-2213?page=all ] John Casey updated MNG-2213: Fix Version: 2.0.5 Current settings.xml example incorrect --- Key: MNG-2213 URL: http://jira.codehaus.org/browse/MNG-2213 Project: Maven 2 Type: Improvement Versions: 2.0.3 Reporter: Todd Nine Fix For: 2.0.5 The settings.xml in the example is incorrect. The child tags of repository and pluginRepository are releases and snapshots, not release and snapshot. Todd -- 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: (MNG-2380) review and link to POMstrap
[ http://jira.codehaus.org/browse/MNG-2380?page=all ] John Casey updated MNG-2380: Fix Version: 2.0.5 review and link to POMstrap --- Key: MNG-2380 URL: http://jira.codehaus.org/browse/MNG-2380 Project: Maven 2 Type: Improvement Components: Documentation: General Versions: documentation Reporter: Brett Porter Fix For: 2.0.5 http://pomstrap.tigris.org/ Heard about this a while back - it seems to have matured a bit. Let's you execute your project from 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: (MNG-2299) org.apache.maven.it.Verifier.loadProperties(..) does not close FileInputStream (relies upon finalizer being called)
[ http://jira.codehaus.org/browse/MNG-2299?page=all ] John Casey updated MNG-2299: Fix Version: 2.0.5 org.apache.maven.it.Verifier.loadProperties(..) does not close FileInputStream (relies upon finalizer being called) --- Key: MNG-2299 URL: http://jira.codehaus.org/browse/MNG-2299 Project: Maven 2 Type: Bug Components: Performance Reporter: John Sisson Fix For: 2.0.5 Attachments: verifier.patch The loadProperties(..) method in the Verifier class needs to close the FileInputStream. See attached 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: (MNG-2214) ITs fail when bootstrapping M2 SVN trunk with java.lang.StringIndexOutOfBoundsException: String index out of range: 1
[ http://jira.codehaus.org/browse/MNG-2214?page=all ] John Casey updated MNG-2214: Fix Version: 2.0.5 ITs fail when bootstrapping M2 SVN trunk with java.lang.StringIndexOutOfBoundsException: String index out of range: 1 - Key: MNG-2214 URL: http://jira.codehaus.org/browse/MNG-2214 Project: Maven 2 Type: Bug Components: Bootstrap Build Environment: Windows XP, M2 SVN trunk Reporter: Rahul Thakur Fix For: 2.0.5 Attachments: StringReplacementTest.java Here is an exception stacktrace for one of the failed tests... it0002... FAILED Error Stacktrace: org.apache.maven.it.VerificationException: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at org.apache.maven.it.Verifier.executeHook(Verifier.java:366) at org.apache.maven.it.Verifier.main(Verifier.java:862) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:566) at java.util.regex.Matcher.appendReplacement(Matcher.java:696) at java.util.regex.Matcher.replaceAll(Matcher.java:806) at java.lang.String.replaceAll(String.java:2028) at org.apache.maven.it.Verifier.resolveCommandLineArg(Verifier.java:698) at org.apache.maven.it.Verifier.executeHook(Verifier.java:355) ... 1 more Error Stacktrace -- 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: (MNG-2389) document more about how to get help on the mailing lists
[ http://jira.codehaus.org/browse/MNG-2389?page=all ] John Casey updated MNG-2389: Fix Version: 2.0.5 document more about how to get help on the mailing lists -- Key: MNG-2389 URL: http://jira.codehaus.org/browse/MNG-2389 Project: Maven 2 Type: Task Components: Documentation: General Reporter: Brett Porter Fix For: 2.0.5 see: http://mail-archives.apache.org/mod_mbox/maven-users/200601.mbox/[EMAIL PROTECTED] including later posts in the thread. We should have this in a place that we can point to more often. -- 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: (MNG-2022) What is the Difference between project.getDependencies() and project.getDependencyArtifacts?
[ http://jira.codehaus.org/browse/MNG-2022?page=all ] John Casey updated MNG-2022: Fix Version: 2.0.5 What is the Difference between project.getDependencies() and project.getDependencyArtifacts? Key: MNG-2022 URL: http://jira.codehaus.org/browse/MNG-2022 Project: Maven 2 Type: Improvement Components: Documentation: Faqs Reporter: Natalie Burdick Fix For: 2.0.5 The difference between project.getDependencies() and project.getDependencyArtifacts() is that project.getDependencies() also returns transitive dependencies, while project.getDependencyArtifacts returns only the direct dependencies, and also includes things in the test scope. -- 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-417) Wrong dependency on itext in jfreereport poms
[ http://jira.codehaus.org/browse/MEV-417?page=all ] Carlos Sanchez closed MEV-417: -- Assign To: Carlos Sanchez Resolution: Fixed Added itext 1.2.3 to the repo Wrong dependency on itext in jfreereport poms - Key: MEV-417 URL: http://jira.codehaus.org/browse/MEV-417 Project: Maven Evangelism Type: Improvement Components: Invalid POM, Dependencies Reporter: Grégory Joseph Assignee: Carlos Sanchez In http://www.ibiblio.org/maven2/jfree/jfreereport/0.8.5-5/jfreereport-0.8.5-5.pom, there is a dependency to itext:itext:1.2.3 However, as 1)itext:itext has been relocated to com.lowagie:itext 2) no 1.2.3 version exists in the repository, my application, which depends on com.lowagie:itext:1.3.1 can't be built, because maven complains about a missing itext:itext:1.2.3 artifact. (Same if i set my dependency on itext:itext:1.3.1.) I suppose there are two solutions to this: either create a relocation pom for itext:itext:1.2.3, but there's not com.lowagie:itext:1.2.3 to redirect to, or update the dependency in the jfreereport poms to com.lowagie:itext:1.2.3 . I've done the latter locally, and eventhough 1.2.3 does not exist, since my app depends on 1.3.1, it just works. Please let me know if I can help or provide more 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: (MRELEASE-128) SCM properties being replaced during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-128?page=comments#action_67977 ]
Martin Gilday commented on MRELEASE-128:
I posted a question regarding this on the maven users mailing list. At least
now I know it appears to be a bug and not my POM.
But I get the problem when using release:perform as well. Do I need to create
another issue for this (quite new to JIRA/reporting)?
Another slight difference is that my property is for the SCM username and
password - $\{cvs-user\} and $\{cvs-pass\}. After a release:perform both of
these properties are replaced with the ones from the settings.xml. I have
tried removing the properties from the POM and specifiying them with \
-Dusername and \-Dpassword. Doing this also reasults in the SCM path being
altered and the login details added. Both the exported POM and the original
POM are incorrectly altered.
{code:xml}
scm
connectionscm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName/connection
developerConnectionscm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName/developerConnection
/scm
{code}
turns to
{code:xml}
scm
connectionscm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName/connection
developerConnectionscm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName/developerConnection
/scm
{code}
after the release:perform is called.
SCM properties being replaced during release:perform
Key: MRELEASE-128
URL: http://jira.codehaus.org/browse/MRELEASE-128
Project: Maven 2.x Release Plugin
Type: Bug
Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Attachments: after-release-perform-pom.xml, after-release-prepre-pom.xml,
original-pom.xml
The scm section of a pom in CVS for a pom archetype project looks like this
prior to executing release:prepare :
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
/scm
Then after executing release:prepare, the pom in CVS looks like this (new
tag tag is only difference):
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
tagR-1_7/tag
/scm
Then after executing release:perform, the pom looks like this in CVS:
scm
connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
/scm
Notice that the properties that were there for the base URLs for CVS and
ViewCVS have been replaced with literal values.
No other properties in the POM are being 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] Updated: (MNG-2349) dependency management, report-plugins and deploy-site
[ http://jira.codehaus.org/browse/MNG-2349?page=all ] John Casey updated MNG-2349: Fix Version: 2.0.5 dependency management, report-plugins and deploy-site - Key: MNG-2349 URL: http://jira.codehaus.org/browse/MNG-2349 Project: Maven 2 Type: Bug Versions: 2.0.4 Environment: jdk 1.4.2_11, windows 2000 Reporter: Thiago Gozzi Prado Fix For: 2.0.5 Attachments: myproject.zip When I run mvn -e clean site site-deploy for the root pom, maven throws a NullPointerException. If I remove the javadoc report plugin declaration, the site is deployed. Or if I keep the javadoc report plugin declaration, but remove the dependency management declaration, the site is deployed. This happens for some report plugins, not all. Checkstyle, for instance, works fine. myproject.zip contains the project structure and the project definition. -- 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: (MNG-2203) Problem with duplicates
[ http://jira.codehaus.org/browse/MNG-2203?page=all ] John Casey updated MNG-2203: Fix Version: 2.0.5 Problem with duplicates --- Key: MNG-2203 URL: http://jira.codehaus.org/browse/MNG-2203 Project: Maven 2 Type: Bug Components: Dependencies Versions: 2.1, 2.0.3 Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1-SNAPSHOT Reporter: Francesco Tinti Fix For: 2.0.5 Attachments: pomerr.zip Declare in POM a duplicate group-artifact dependency but with different versions.: there's no log of duplicate entry. Maven will also take care only of the latest dependency, so if the version is ancient of the other, you can obtain (of course) compilation error. In attachment a simple demonstration with a specific commons-io 1.2 function. -- 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: (MECLIPSE-119) Allow custom project name for eclipse projects
[ http://jira.codehaus.org/browse/MECLIPSE-119?page=all ]
John Casey moved MNG-1920 to MECLIPSE-119:
--
Version: (was: 2.0.1)
2.2
Complexity: (was: Intermediate)
Key: MECLIPSE-119 (was: MNG-1920)
Project: Maven 2.x Eclipse Plugin (was: Maven 2)
Allow custom project name for eclipse projects
--
Key: MECLIPSE-119
URL: http://jira.codehaus.org/browse/MECLIPSE-119
Project: Maven 2.x Eclipse Plugin
Type: New Feature
Versions: 2.2
Reporter: David Rice
Attachments: MNG-1920-maven-eclipse-plugin.patch
If you download 2 versions of the same artifact, or 2 artifacts with the same
artifactId then when you create eclipse the projects you have to load them
into different workspaces because the eclipse project name is the same (ie.
based on artifactId). I added a parameter eclipse.projectName to allow you
to specify an alternate name to artifactId to get around this problem.
Example uses:
-Declipse.projectName='${project.artifactId}:${project.version}'
-Declipse.projectName='${project.groupId}:${project.artifactId}:${project.version}'
-Declipse.projectName=my-different-project-name
--
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: (MNG-2088) antcall failed
[ http://jira.codehaus.org/browse/MNG-2088?page=all ] John Casey updated MNG-2088: Fix Version: 2.0.5 antcall failed -- Key: MNG-2088 URL: http://jira.codehaus.org/browse/MNG-2088 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.2 Environment: Suse Linux 10.0 / JDK 1.5.0_04 / ANT 1.6.5 Reporter: Marco Meschieri Priority: Blocker Fix For: 2.0.5 I am trying to develop a maven plugin using the ant way beacuse of intensive file operations. I have many filesystem operations coded inside different targets(mainly for easy manageability) A template target invokes other targets in the same build file using the antcall task, but the invocation of this task couses the following exception: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to execute: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:37) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.codehaus.plexus.component.factory.ant.AntComponentExecutionException: Executing Ant script: /logicalserver.build.xml [deploy]: Failed to execute. at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(AntScriptInvoker.java:227) at org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:33) ... 18 more Caused by: /tmp/plexus-ant-component61868.build.xml:15: The following error occurred while executing this line: java.io.FileNotFoundException: /home/marco/projects/util/build.xml (No such file or directory) at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:336) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:107) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(AntScriptInvoker.java:222) ... 19 more Caused by: java.io.FileNotFoundException: /home/marco/projects/util/build.xml (No such file or directory) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:243) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:140) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:91) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:334) ... 27 more Caused by: java.io.FileNotFoundException: /home/marco/projects/util/build.xml
[jira] Moved: (MJAR-46) maven-jar-plugin doesn't accept manfiestFile element in configuration
[ http://jira.codehaus.org/browse/MJAR-46?page=all ] John Casey moved MNG-2156 to MJAR-46: - Version: (was: 2.0.2) 2.0 Component: (was: Plugins and Lifecycle) Complexity: (was: Intermediate) Key: MJAR-46 (was: MNG-2156) Project: Maven 2.x Jar Plugin (was: Maven 2) maven-jar-plugin doesn't accept manfiestFile element in configuration --- Key: MJAR-46 URL: http://jira.codehaus.org/browse/MJAR-46 Project: Maven 2.x Jar Plugin Type: Bug Versions: 2.0 Reporter: Sachin Patel Priority: Blocker The maven-jar-plugin does not accept the manfiestFile element in the configuration as advertised. The error reported is... [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-jar-plugin:2.1-SNAPSHOT Cause: Cannot find setter nor field in org.apache.maven.archiver.ManifestConfiguration for 'manifestFile' Need to mark this as a blocker as their is no way to merge an existing MANFIEST that is needed to build an eclipse-plugin. The MANIFEST entries cannot be respecified in the plugin configuration because this would break running the plugin in a eclipse runtime-workbench. Keeping the manifest entires in the POM and in the MANIFEST file synchronized is too much maintainance. Need to support merging an existing manifest 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: (MNG-1751) merging metadata doesn't fail when timestamp is in the future
[ http://jira.codehaus.org/browse/MNG-1751?page=all ] John Casey updated MNG-1751: Fix Version: 2.1 merging metadata doesn't fail when timestamp is in the future - Key: MNG-1751 URL: http://jira.codehaus.org/browse/MNG-1751 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Fix For: 2.1 on deploying, the timestamp got set to the future (set to GMT - Guelph Mean Time instead of the expected Grenwich :) subsequent attempts to deploy reported success, but did not update the metadata. The fact that we might suffer clock skew is probably a separate issue to consider, that might be reoslved through passing deployments via repoman. -- 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: (MNG-1983) Mojo parameters defined in abstract-mojo class not set, when concrete/abstract mojo class in different JARs
[ http://jira.codehaus.org/browse/MNG-1983?page=all ] John Casey updated MNG-1983: Fix Version: 2.1 Mojo parameters defined in abstract-mojo class not set, when concrete/abstract mojo class in different JARs --- Key: MNG-1983 URL: http://jira.codehaus.org/browse/MNG-1983 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.2 Environment: Maven-2.0.2 (also in Maven-2.0.1) Win-XP/Pro - Cygwin $ java -version java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) Reporter: Shash Chatterjee Fix For: 2.1 Attachments: abstractmojotest.zip Have an abstract mojo class, which extends AbstractMojo. This abstract class defines some mojo parameters with expressions to set default values. Have a concrete class, in the same project (JAR) and package, which simply extends the abstract mojo class. This works fine, in that the parameter values are initialized correctly. Have an identical concrete class, but this time in a different project which defines a Maven dependency on the previous JAR. This time the parameters defined in the abstract class are not initialized correctly. Whether this second concrete mojo is in the same Java package as the abstract class, or not, does not seem to make a difference. I have attached a ZIP file which demonstrates the problem. Included are three very simple Maven modules, all created with mvn archetype:create. The first project, testplugin-one contains an abstract and a concrete Mojo class. The second project, testplugin-two contains just a concrete Mojo class. The third project testplugin-driver contains a POM that invokes the two mojos: the first time the parameters have values, the second time they are null. -- 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: (MNG-2242) mvn command gives a Null Pointer Exception when a plugin is invalid
[ http://jira.codehaus.org/browse/MNG-2242?page=all ] John Casey updated MNG-2242: Fix Version: 2.1 mvn command gives a Null Pointer Exception when a plugin is invalid --- Key: MNG-2242 URL: http://jira.codehaus.org/browse/MNG-2242 Project: Maven 2 Type: Bug Environment: Windows XP, Mavne 2.0.2 Reporter: Kin Leung Fix For: 2.1 Attachments: pom.xml I tried to use xdoclet with Maven 2.0.2 by adding those lines in pom.xml: build finalNamebookstore-web/finalName plugins plugin groupIdxdoclet/groupId artifactIdmaven-xdoclet-plugin/artifactId version1.2/version executions execution idgenerate-deployment-decriptor/id phasegenerate-sources/phase configuration fileset dir=src/main/java include name=**/*.java/ /fileset webdoclet destinationFileweb.xml/destinationFile destDirsrc/main/webapp/WEB-INF/destDir /webdoclet /configuration goals goalwebdoclet/goal /goals /execution /executions /plugin /plugins After I saved the file and run mvn (mvn install and mvn clean), it gives me Null Pointer Exception: Downloading: http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave n-xdoclet-plugin-1.2.pom 159b downloaded Downloading: http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave n-xdoclet-plugin-1.2.jar 34K downloaded [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] null [INFO] - --- [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM anager.java:295) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De faultPluginManager.java:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug inManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa ultLifecycleExecutor.java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec ycle(DefaultLifecycleExecutor.java:1182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl eMappings(DefaultLifecycleExecutor.java:950) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:450) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] - --- Looks like something is screwed up when maven attempts to run the plugin for generating the web.xml of my servlet. I didn't do anything on the settings.xml, does that matter? Also the documentation is por and in worse case the poor documentation offsets the benefits of the tool. -- 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: (MNG-2271) It should be possible to specify the public key for a repository as well as the private key
[ http://jira.codehaus.org/browse/MNG-2271?page=all ] John Casey updated MNG-2271: Fix Version: 2.1 It should be possible to specify the public key for a repository as well as the private key --- Key: MNG-2271 URL: http://jira.codehaus.org/browse/MNG-2271 Project: Maven 2 Type: Improvement Components: General, Ant tasks Reporter: Dan Fabulich Fix For: 2.1 This bug is related to WAGONSSH-19. Right now settings.xml and the repository ant tasks allow you to specify a path to a private key, but not a path to a public key. WAGONSSH-19 suggests a way in which this could be configured using arbitrary configuration properties, but that's not as clean as allowing the user to explicitly specify a publickey element on the server element in settings.xml or as a publickey attribute on the authentication element in an Ant task. -- 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: (MNG-2036) The clean plugin requires dependent plugins defined in a project's pom.xml to be in the repository before it can perform a clean
[ http://jira.codehaus.org/browse/MNG-2036?page=all ] John Casey updated MNG-2036: Fix Version: 2.1 The clean plugin requires dependent plugins defined in a project's pom.xml to be in the repository before it can perform a clean Key: MNG-2036 URL: http://jira.codehaus.org/browse/MNG-2036 Project: Maven 2 Type: Improvement Environment: maven2 2.0.1 Reporter: Chad Brandon Fix For: 2.1 It appears that any plugins that are in my pom.xml need to be downloaded before clean can work, otherwise it fails with unsatisfied dependencies (for example, I can't clean our distribution until the rest of the plugins of our build are installed). -- 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: (MNG-2272) It should be possible to trust all public keys implicitly
[ http://jira.codehaus.org/browse/MNG-2272?page=all ] John Casey updated MNG-2272: Fix Version: 2.1 It should be possible to trust all public keys implicitly - Key: MNG-2272 URL: http://jira.codehaus.org/browse/MNG-2272 Project: Maven 2 Type: Improvement Components: General, Ant tasks Reporter: Dan Fabulich Fix For: 2.1 There should be a setting in server.xml and in the authentication element for the ant task that allows you to turn off host key checking, and to explicitly trust all hosts, without prompting you to accept the certificate. (Ant's scp task allows you to do this.) On my official build system, I don't have the authority to leave files in the home directory. (The official build machine needs to remain pristine; if everybody just dropped one little custom file for their build, there'd be no way to reproduce the build machine.) That means that I need to be able to convince Maven to accept a host with an arbitrary public key. -- 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: (MNG-2066) Specify multiple proxies
[ http://jira.codehaus.org/browse/MNG-2066?page=all ] John Casey updated MNG-2066: Fix Version: 2.1 Specify multiple proxies Key: MNG-2066 URL: http://jira.codehaus.org/browse/MNG-2066 Project: Maven 2 Type: Improvement Versions: 2.0.2 Reporter: Thomas Recloux Fix For: 2.1 Attachments: multiple-proxies-paches.zip After this discussion : http://www.mail-archive.com/dev@maven.apache.org/msg53099.html In the attached zip file, you'll find four patch files : - on the maven-artifact-manager projet : changes in the DefaultWagonManager class, using the http proxy when no https proxy is specified. - on the maven-core project : changes in the DefaultMaven, adding all teh active proxies from the settings to the wagon manager - on the maven-settings project : changes in the settings.mdo file Theses patches are built on the maven-2.0.x branch. -- 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: (MNG-2347) MavenExecutionRequest.getBaseDirectory() should be propagated to the ${basedir} expression
[ http://jira.codehaus.org/browse/MNG-2347?page=all ]
John Casey updated MNG-2347:
Fix Version: 2.1
MavenExecutionRequest.getBaseDirectory() should be propagated to the
${basedir} expression
--
Key: MNG-2347
URL: http://jira.codehaus.org/browse/MNG-2347
Project: Maven 2
Type: Bug
Components: General
Versions: 2.1
Environment: Maven 2.1-SNAPSHOT
Reporter: Ovidio Mallo
Fix For: 2.1
Attachments: MNG-2347-maven-core.patch
When executing a goal given by a MavenExecutionRequest (e.g. on the
MavenEmbedder) which has no POM file set (e.g. archetype:create), the
MavenExecutionRequest.getBaseDirectory() is not propagated to the expression
${basedir} for the plugins to be used.
Currently, the ${basedir} is set to the directory where the POM file resides,
if any is specified. Otherwise, it is simply set to the current working
directory. I guess that when no POM file is given, ${basedir} should be set
to the base directory set on the MavenExecutionRequest.
--
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: (MNG-2073) Support configuring plugins that always execute
[ http://jira.codehaus.org/browse/MNG-2073?page=all ]
John Casey updated MNG-2073:
Fix Version: 2.1
Support configuring plugins that always execute
---
Key: MNG-2073
URL: http://jira.codehaus.org/browse/MNG-2073
Project: Maven 2
Type: New Feature
Components: Plugins and Lifecycle
Reporter: John Didion
Fix For: 2.1
Currently, there is no way to set up a plugin to run every time I invoke
maven on my project, regardless of whether I'm executing a stand-alone goal
or a lifecycle phase. For example, I have a plugin that munges some project
information and sets project properties based on the results. I want to use
these properties elsewhere in my project file. It would be nice if I could
set up this plugin to always be the first thing that executes when I invoke
maven on my project. I'm thinking something like the following:
{noformat}
project
globalPlugins
plugin
...
/plugin
/globalPlugins
/project
{noformat}
These plugins obviously wouldn't support the phase and goal tags within
executions.
Another way to accomplish this would be to recognize a special phase called
global (or something similar) that would indicate a plugin that always runs
first (i.e. before starting the lifecycle or executing stand-alone goals).
For example:
{noformat}
project
plugins
plugin
groupIdfoo/groupId
artifactIdbar/artifactId
executions
execution
phaseglobal/phase
goals
goalbaz/goal
/goals
configuration
...
/configuration
/execution
/executions
/plugin
/plugins
/project
{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] Updated: (MNG-2368) Executing a goal that doesn't need a pom but that need some extensions is impossible.
[ http://jira.codehaus.org/browse/MNG-2368?page=all ] John Casey updated MNG-2368: Fix Version: 2.1 Executing a goal that doesn't need a pom but that need some extensions is impossible. - Key: MNG-2368 URL: http://jira.codehaus.org/browse/MNG-2368 Project: Maven 2 Type: Bug Components: Settings Versions: 2.0.4 Reporter: Alexandre Poitras Fix For: 2.1 There is no way to specify extensions in settings.xml. This is a problem when you want to execute a goal without a pom but that need an extension. One basic case is archetype:create when the archetype is located on a ftp repository. At the moment, you need to perform the command using a fake pom declaring the extension. In my opinion, this is a big gotcha for novice users. -- 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: (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=all ] John Casey updated MNG-1991: Fix Version: 2.1 Can't get transitive dependencies from a war pom when this war is added as a depdency of a project -- Key: MNG-1991 URL: http://jira.codehaus.org/browse/MNG-1991 Project: Maven 2 Type: Bug Versions: 2.0.2 Reporter: Emmanuel Venisse Fix For: 2.1 I have a project (continuum-core-it) that need to use all transitive dependencies of a war (continuum-webapp). If i add the war as a dependency of the project with packaging war, war dependencies aren't shown by project, maven doesn't try to resolve them and doesn't add them in classpath. If if replace packaging from war to pom, all dependencies are resolved and added to classpath. -- 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: (MNG-1549) metadata needs different policy to releases
[ http://jira.codehaus.org/browse/MNG-1549?page=all ] John Casey updated MNG-1549: Fix Version: 2.1 metadata needs different policy to releases - Key: MNG-1549 URL: http://jira.codehaus.org/browse/MNG-1549 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Reporter: Brett Porter Fix For: 2.1 currently, metadata is looked for updates on the same interval as releases. However, if that is never (which is valid if you want a purely snapshot repository), then finding out the available snapshot versions is impossible. The metadata update policy probably should not be individually configurable, as that would be confusing, but instead should be the more frequent of snapshots and releases, and the more permissive of thetwo checksum policies. -- 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: (MNG-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=all ] John Casey updated MNG-714: --- Fix Version: 2.1 When artifact not found on mirror the real site isn't checked - Key: MNG-714 URL: http://jira.codehaus.org/browse/MNG-714 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-beta-1 Reporter: Kenney Westerhof Assignee: Edwin Punzalan Fix For: 2.1 Attachments: MNG-714-maven-artifact-manager.patch Original Estimate: 3 hours Remaining: 3 hours I'm using the settings.xml mirror feature as a local cache. Periodically I upload my local repo to the webserver specified as mirror. When an artifact cannot be found on the mirror, the original site isn't checked (and possibly the rest of the sites). I'm not sure what the exact function of the mirror is (except caching?), but repo1 is checked often regardless of mirror presence, so I figure it's not meant to totally disable checking the central repo's. Simple reproduction: define a few mirrors in your settings.xml for central, central-plugins and snapshots, pointing to say file://tmp/empty/dir/. Stacktrace: [DEBUG] Error resolving artifact version from metadata. org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) at org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) at org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:123) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:209) at org.apache.maven.cli.MavenCli.main(MavenCli.java:267) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324)
[jira] Updated: (MNG-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=all ] John Casey updated MNG-2276: Fix Version: 2.1 profile activation by property doesn't work with properties defined in settings. Key: MNG-2276 URL: http://jira.codehaus.org/browse/MNG-2276 Project: Maven 2 Type: Bug Components: POM Versions: 2.0.4 Reporter: Brian Fox Fix For: 2.1 Activating a profile like below doesn't get activated unless the property is set on the CLI. I need to have the property defined in the settings.xml so it's always set. profiles profile idprod/id activation property namedeploy-ct/name /property /activation Further, I noticed that if I set it so that the activation is like: activation property namedeploy-ct/namevaluetrue/value /property /activation The profile is triggered just by setting the cli like mvn -Ddeploy-ct It is not active if I use -Ddeploy-ct=false but the settings descriptor says that the existence of the property is only used if value is not set. -- 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: (MNG-2028) Attached mojos with the @aggregator tag can yield bad results in a multi-module project
[ http://jira.codehaus.org/browse/MNG-2028?page=all ]
John Casey updated MNG-2028:
Fix Version: 2.1
Attached mojos with the @aggregator tag can yield bad results in a
multi-module project
---
Key: MNG-2028
URL: http://jira.codehaus.org/browse/MNG-2028
Project: Maven 2
Type: Bug
Components: Plugins and Lifecycle
Versions: 2.0.2
Reporter: John Didion
Fix For: 2.1
I am using an attached version of the directory assembly plugin. I also have
a multi-module project that is several levels deep. Here's an overview
myproject
tools
libraries
library1
library2
library3
If I configure the attached directory assembly plugin in library1's POM and
then run maven install from the myproject directory, I get errors about
dependency resolution because the presence of the @aggregator tag causes
maven to try and resolve dependencies for all modules in the entire project.
That means it's trying to resolve dependencies for library3, which is a
problem if library3 depends on library2, which hasn't been built yet.
It makes sense to me that dependency resolution should only happen on the
sub-modules of the POM that configures the aggregator plugin, not all modules
in the project.
If this makes sense then I think the fix would be in
DefaultPluginManager.executeMojo():
if ( mojoDescriptor.isDependencyResolutionRequired() != null )
{
Collection projects;
if ( mojoDescriptor.isAggregator() project.getModules() !=
null !project.getModules().isEmpty())
{
List modules = project.getModules();
projects = new ArrayList(modules.size());
for (Iterator itr = modules.iterator(); itr.hasNext();) {
String module = (String) itr.next();
MavenProject moduleProject = // load the project for the
module...don't know exactly how to do this
projects.add(moduleProject);
}
}
...
--
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: (MNG-2241) Versions are required when it shouldn't with multi-modules projects and war dependencies
[ http://jira.codehaus.org/browse/MNG-2241?page=all ]
John Casey updated MNG-2241:
Fix Version: 2.1
Versions are required when it shouldn't with multi-modules projects and war
dependencies
Key: MNG-2241
URL: http://jira.codehaus.org/browse/MNG-2241
Project: Maven 2
Type: Bug
Versions: 2.0.4
Environment: Maven 2.0.4, Java 5, Windows XP
Reporter: Celso Gomes Barreto Junior
Fix For: 2.1
In a multi-project with a parent pom which should enforces modules's versions
in dependencyManagement element, when I use a war dependnecy it starts to
require the version declaration in child pom's dependencies. When I use jar
dependencies, it works fine.
Project structure:
parent project
|_ web (war)
|_ commons (jar)
|_ webcommons (war)
--
parent project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
nameProcdev - Referência/name
groupIdglobo/groupId
artifactIdprocdevref/artifactId
packagingpom/packaging
version0.0.1/version
descriptionno/description
modules
moduleweb/module
modulecommons/module
modulewebcommons/module
/modules
dependencyManagement
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-web/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
version${project.version}/version
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
/project
--
web project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web/name
artifactIdprocdevref-web/artifactId
packagingwar/packaging
version0.0.1/version
descriptionno/description
dependencies
dependency
groupIdglobo/groupId
artifactIdprocdevref-webcommons/artifactId
typewar/type
/dependency
dependency
groupIdglobo/groupId
artifactIdprocdevref-commons/artifactId
/dependency
dependency
groupIdjstl/groupId
artifactIdjstl/artifactId
version[1.1.2,]/version
/dependency
dependency
groupIdtaglibs/groupId
artifactIdstandard/artifactId
version[1.1.2,]/version
/dependency
/dependencies
/project
--
webcommons project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Web Commons/name
artifactIdprocdevref-webcommons/artifactId
packagingwar/packaging
version0.0.1/version
descriptionno/description
/project
--
commons project pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdglobo/groupId
artifactIdprocdevref/artifactId
version0.0.1/version
/parent
nameProcdev Commons/name
artifactIdprocdevref-commons/artifactId
packagingjar/packaging
version0.0.1/version
descriptionno/description
/project
When i Run it with mvn -X clean install I get:
+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
Settin
gs\celso.cs\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'C:\java\maven-2.0.4\b
in\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: globo:procdevref-web
POM Location: C:\Projetos\ProcdevReferencia\web\pom.xml
Validation Messages:
[0] 'dependencies.dependency.version' is missing for
globo:procdevref-webco
mmons
Reason: Failed to validate 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] Updated: (MNG-2348) add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often
[ http://jira.codehaus.org/browse/MNG-2348?page=all ] John Casey updated MNG-2348: Fix Version: 2.1 add a simple command line alias for -Dmaven.test.skip=true as I find myself typing it very very often - Key: MNG-2348 URL: http://jira.codehaus.org/browse/MNG-2348 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.4 Reporter: james strachan Fix For: 2.1 Could we have some simple alias on the command line to disable unit tests just like we have maven -o for offline. Don't much mind what it is - how about... -nt --no-testsDisables the junit tests in this build so to do a build without unit tests mvn -nt install -- 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: (MNG-1982) wagons should be tolerant of incorrect configurations in server/ entries within settings.xml
[ http://jira.codehaus.org/browse/MNG-1982?page=all ] John Casey updated MNG-1982: Fix Version: 2.1 wagons should be tolerant of incorrect configurations in server/ entries within settings.xml -- Key: MNG-1982 URL: http://jira.codehaus.org/browse/MNG-1982 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: John Casey Fix For: 2.1 basically, we need to soften the reaction to invalid configuration of a wagon...make it a warning instead of an exception. -- 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
