[jira] Created: (MCHANGES-45) A mailto: link is always created for a due-to in the changes report, even though no due-to-email has been supplied
A mailto: link is always created for a due-to in the changes report, even though no due-to-email has been supplied -- Key: MCHANGES-45 URL: http://jira.codehaus.org/browse/MCHANGES-45 Project: Maven 2.x Changes Plugin Issue Type: Bug Reporter: Dennis Lundberg Assigned To: Dennis Lundberg Priority: Minor Fix For: 2.0-beta-2 -- 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: (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
There is no link to the RSS feed of changes in the changes report - Key: MCHANGES-46 URL: http://jira.codehaus.org/browse/MCHANGES-46 Project: Maven 2.x Changes Plugin Issue Type: Bug Reporter: Dennis Lundberg -- 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: (MCHANGES-45) A mailto: link is always created for a due-to in the changes report, even though no due-to-email has been supplied
[ http://jira.codehaus.org/browse/MCHANGES-45?page=all ] Dennis Lundberg closed MCHANGES-45. --- Resolution: Fixed > A mailto: link is always created for a due-to in the changes report, even > though no due-to-email has been supplied > -- > > Key: MCHANGES-45 > URL: http://jira.codehaus.org/browse/MCHANGES-45 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Reporter: Dennis Lundberg > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.0-beta-2 > > -- 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: (MCHANGES-47) Add support for multiple and tags in changes.xml
Add support for multiple and tags in changes.xml - Key: MCHANGES-47 URL: http://jira.codehaus.org/browse/MCHANGES-47 Project: Maven 2.x Changes Plugin Issue Type: New Feature Reporter: Dennis Lundberg This is to improve the compatibility with changes.xml files used by the Maven 1 version of the plugin. See MPCHANGES-15 and MPCHANGES-16 for 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: (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
[ http://jira.codehaus.org/browse/MCHANGES-46?page=comments#action_69900 ] Dennis Lundberg commented on MCHANGES-46: - I have added code to create the link to the RSS feed, but I have commented it out. The reason being that there is no RSS feed file. So the changes.rss file needs to be created as well. In the Maven 1 version of the plugin this is done in Jelly, but using XSL should work. Perhaps an Ant mojo using the xslt task can do the job. > There is no link to the RSS feed of changes in the changes report > - > > Key: MCHANGES-46 > URL: http://jira.codehaus.org/browse/MCHANGES-46 > Project: Maven 2.x Changes Plugin > Issue Type: Bug >Reporter: Dennis Lundberg > -- 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: (MJAR-51) handle signing jars which are not project artifacts and not "in place" signing
handle signing jars which are not project artifacts and not "in place" signing
--
Key: MJAR-51
URL: http://jira.codehaus.org/browse/MJAR-51
Project: Maven 2.x Jar Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Scott Cytacki
It seems the SignJarMojo is intended to be used both as a way to sign a jar
artifact, and as a utitlity to sign jars for other plugins in maven.
The jnlp plugin uses it in the latter mode. However currently it can only sign
jars "inplace" when the jar being signed isn't a artifact of a project.
More specifically if the signedJar field is not null, and the project of the
SingJarMojo is null, then SignJarMojo fails. Changing:
else
{
project.getArtifact().setFile( signedjar );
}
to
else if ( project != null)
{
project.getArtifact().setFile( signedjar );
}
Would fix this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-48) regression: report generation doesn't work while dealing with the header file
[ http://jira.codehaus.org/browse/MCHECKSTYLE-48?page=comments#action_69904 ] Dennis Lundberg commented on MCHECKSTYLE-48: I also stumbled on this today. After some serious digging I found a workaround for it. If you add config/maven-header.txt to your configuration it works. Now, on to the real problem. It seems to be the "magical" Locator, that: "Checks a location string to for a resource, URL, or File that matches. If a resource or URL is found, then a local file is created with that locations contents." The problem here is the "location" which in this case is set to "LICENSE.txt" (i.e. the default value for headerLocation). Now, if your project does not contain such a file, the Locator tries to find this in some other magical way and downloads it if it finds it. In my case I ended up with the license file for "JSch 0.0.*" in target/checkstyle-header.txt! So check the contents of that file. And this is what debug tells us: [DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt) [DEBUG] Location is not a URL. [DEBUG] Location is not a File. [DEBUG] Potential Resource: jar:file:/C:/Program/maven-2.0.5-SNAPSHOT/lib/jsch-0.1.24.jar!/LICENSE.txt A solution for the maven_checks problem would be to change the default value of headerFile to "config/maven-header.txt" if the user has configured the plugin to use "config/maven_checks.xml" > regression: report generation doesn't work while dealing with the header file > - > > Key: MCHECKSTYLE-48 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-48 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug > Environment: Checkstyle 2.2-SNAPSHOT rev 419829. >Reporter: Jerome Lacoste >Priority: Blocker > Attachments: mvn.log > > > Configured as is: > > org.apache.maven.plugins > maven-checkstyle-plugin > > config/maven_checks.xml > > > Checkstyle stopped working. I made a fresh svn update and mvn > checkstyle:checkstyle fails with: > [...] > Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot > initialize module TreeWalker - Cannot set property 'headerFile' in module > RegexpHeader to > '/home/jerome/Dev/OSS/perso/jar-info/target/checkstyle-header.txt': line 24 > in header specification is not a regular expression > at > com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:165) > at > com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:209) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeCheckstyle(CheckstyleReport.java:729) > at > org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:490) > [...] > Caused by: org.apache.commons.beanutils.ConversionException: line 24 in > header specification is not a regular expression > at > com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.initHeaderRegexps(RegexpHeaderCheck.java:116) > at > com.puppycrawl.tools.checkstyle.checks.header.RegexpHeaderCheck.setHeaderFile(RegexpHeaderCheck.java:85) > ... 34 more > Full log attached. -- 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: (MCHECKSTYLE-50) Sort the files and details in the report
Sort the files and details in the report Key: MCHECKSTYLE-50 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-50 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Dennis Lundberg Priority: Minor Fix For: 2.2 Attachments: SortFilesInReport.patch The current Checkstyle report lists the files, and thier details, in the order they are delivered from Checkstyle. This simple patch sorts them before writing them to the report. That makes for a much more readable report. I can apply the patch if someone reviews 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] Created: (SCM-220) Submission of a patch for the VSS apt documentation (includes example SCM URL and notes)
Submission of a patch for the VSS apt documentation (includes example SCM URL and notes) Key: SCM-220 URL: http://jira.codehaus.org/browse/SCM-220 Project: Maven SCM Issue Type: Improvement Components: documentation, maven-scm-site Affects Versions: 1.0-beta-3 Environment: Documentation Reporter: Jeremy J. Smith Priority: Minor Attachments: vss.apt.patch There is no documentation on the SCM URL. The attached patch provides this documentation (or at least one mechanism that works and a working example) Many thanks to Jesse on IRC #maven for his help! -- 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: (MSITE-162) maven -N site does not generate index.html
[ http://jira.codehaus.org/browse/MSITE-162?page=all ] Lukas Theussl moved MPSITE-53 to MSITE-162: --- Component/s: (was: plugin) Workflow: Maven New (was: jira) Key: MSITE-162 (was: MPSITE-53) Project: Maven 2.x Site Plugin (was: maven-site-plugin) > maven -N site does not generate index.html > -- > > Key: MSITE-162 > URL: http://jira.codehaus.org/browse/MSITE-162 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: solaris 8 >Reporter: Andrew Williams > > when using maven -N (through continuum) I run the site goal (and site:deploy) > but it fails to generate 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] Created: (CONTINUUM-781) move AbstractContinuumAction to plexus-xwork-integration
move AbstractContinuumAction to plexus-xwork-integration Key: CONTINUUM-781 URL: http://jira.codehaus.org/browse/CONTINUUM-781 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.1 Reporter: Jesse McConnell Assigned To: Emmanuel Venisse Fix For: 1.1 trygve mentioned in the commit notes that the abstraction action ought to live in the xwork integration so I switched to over to that package and deployed an updated snapshot with that new abstract action in 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: (CONTINUUM-781) move AbstractContinuumAction to plexus-xwork-integration
[ http://jira.codehaus.org/browse/CONTINUUM-781?page=all ] Jesse McConnell updated CONTINUUM-781: -- Attachment: continuum-759-with-plexus-xwork-baseclass.patch /Users/jesse/src/continuum-trunk/continuum-webapp/continuum-759-with-plexus-xwork-baseclass.patch this converts all of the actions (including one that appears to have been missed in the last patch over to the new base class logging test remains the same since its good to test the logging here too > move AbstractContinuumAction to plexus-xwork-integration > > > Key: CONTINUUM-781 > URL: http://jira.codehaus.org/browse/CONTINUUM-781 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1 >Reporter: Jesse McConnell > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: continuum-759-with-plexus-xwork-baseclass.patch > > > trygve mentioned in the commit notes that the abstraction action ought to > live in the xwork integration so I switched to over to that package and > deployed an updated snapshot with that new abstract action in 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] Closed: (MPECLIPSE-118) Attaching sourcepath in .classpath when file doesn't exist causes errors in Eclipse
[ http://jira.codehaus.org/browse/MPECLIPSE-118?page=all ] Arnaud Heritier closed MPECLIPSE-118. - Resolution: Fixed Applied. Thanks. > Attaching sourcepath in .classpath when file doesn't exist causes errors in > Eclipse > --- > > Key: MPECLIPSE-118 > URL: http://jira.codehaus.org/browse/MPECLIPSE-118 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.11 > Environment: Windows XP/Eclipse 3.2rc7 > (eclipse.buildId=I20060602-1317) /maven 1.0.2 >Reporter: Jon Christiansen > Assigned To: Arnaud Heritier > Fix For: 1.11.1 > > Attachments: eclipseplugin.diff > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Plugin will put sourcepath attribute on classpathentry elements, regardless > if file exists or not. > Patch attached will only supply sourcepath attribute if the source archive > exists. > This will cause errors in eclipse when you dont have the source files > available. For instance, if you have run a program and have a stack trace in > your console and you click on a link to a file/line number in the stack trace > of one of your source files, you will get something similar to this: > An exception occurred while following link. Reason: Error logged from JDT > Debug UI: > Error logged from JDT Debug UI: > Source lookup error > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\junit\java-sources\junit-3.8.1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-logging\java-sources\commons-logging-1.0.3-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-lang\java-sources\commons-lang-2.0-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-net\java-sources\commons-net-1.3.0-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\sshtools\java-sources\sshtools-maverick-all-1.2.7-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\jboss\java-sources\jboss-jmx-4.0.3SP1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-httpclient\java-sources\commons-httpclient-2.0.2-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-collections\java-sources\commons-collections-3.1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\jboss\java-sources\jboss-system-4.0.3SP1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\jboss\java-sources\jboss-common-4.0.3SP1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\servletapi\java-sources\servletapi-2.4-20040521-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-validator\java-sources\commons-validator-1.1.4-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-beanutils\java-sources\commons-beanutils-1.6-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\jboss\java-sources\jmx-adaptor-plugin-4.0.3SP1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\dom4j\java-sources\dom4j-1.6.1-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\jaxen\java-sources\jaxen-1.1-beta-4-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\commons-digester\java-sources\commons-digester-1.6-sources.jar > Unable to access archive C:\Documents and > Settings\jchristi\.maven\repository\oro\java-sources\oro-2.0.7-sources.jar > Stack trace in Eclipse's error log shows: > org.eclipse.core.runtime.CoreException: Source lookup error > at > org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(CompositeSourceContainer.java:104) > at > org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(CompositeSourceContainer.java:45) > at > org.eclipse.debug.core.sourcelookup.AbstractSourceLookupParticipant.findSourceElements(AbstractSourceLookupParticipant.java:67) > at > org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector$SourceLookupQuery.run(AbstractSourceLookupDirector.java:136) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.findSourceElements(AbstractSourceLookupDirector.java:721) > at > org.eclipse.jdt.internal.debug.cor
[jira] Created: (MECLIPSE-127) Ability to add other workspace configuration similar to add-maven-repo goal
Ability to add other workspace configuration similar to add-maven-repo goal --- Key: MECLIPSE-127 URL: http://jira.codehaus.org/browse/MECLIPSE-127 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.2 Environment: xp Reporter: Dan Tran Fix For: 2.3 add ability to configure code slyle, jvm, warning,etc We can create a new goal like eclipse:configure-workspace and merge add-maven-repo into it. We will need to a complex class for injection. This complex class will have the following property String workspaceDirectory; // if given, will trigger add-maven-repo String styleFile; // if given, will trigger the settup of source format style file etc, This will allow us to preconfigure eclispe configuration in the parent pom, and there for developers in a team will have the same eclipse setup, rather manually configure it. WDYT? -- 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: (MAVEN-1764) planetmirror repository listed in the documentation prevents any project from building
[ http://jira.codehaus.org/browse/MAVEN-1764?page=comments#action_69914 ] Arnaud Heritier commented on MAVEN-1764: The site is re-published. It should be online in some hours. http://maven.apache.org/using/repositories.html was the page in the old site before the refactoring. I removed this directory > planetmirror repository listed in the documentation prevents any project from > building > -- > > Key: MAVEN-1764 > URL: http://jira.codehaus.org/browse/MAVEN-1764 > Project: Maven > Issue Type: Bug > Components: documentation >Reporter: Henning Schmiedehausen > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 1.1-beta-3 > > Attachments: oro-2.0.7.jar > > > On http://maven.apache.org/using/repositories.html, some maven repository > URLs are listed as examples. One of these is > http://public.planetmirror.com/pub/maven/. However, this is not a "real" > maven repository, planetmirror.com insists on showing you advertisments > before a jar can be downloaded. It does behave differently whether you > access an URL with a browser, wget or maven. > This leads to hard to find build errors, because maven (1.0.2, the last > released version of 1.x, you know), even with the artifact updates installed, > chokes on these redirects and saves the HTML page as jar file. Which in turn > leads to hard to find build errors. > Please either remove planetmirror.com from the documentation pages or work > with the people there to fix this behaviour. -- 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: (MPTEST-65) Upgrade to Junit 4.0
Upgrade to Junit 4.0 Key: MPTEST-65 URL: http://jira.codehaus.org/browse/MPTEST-65 Project: maven-test-plugin Issue Type: Task Reporter: Arnaud Heritier Priority: Minor Upgrade to Junit 4.0 JUnit 4.1 isn't (yet) available on ibiblio. -- 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: (MPTEST-65) Upgrade to Junit 4.0
[ http://jira.codehaus.org/browse/MPTEST-65?page=all ] Arnaud Heritier updated MPTEST-65: -- Affects Version/s: 1.6.2 1.7 1.8 Fix Version/s: 1.9 > Upgrade to Junit 4.0 > > > Key: MPTEST-65 > URL: http://jira.codehaus.org/browse/MPTEST-65 > Project: maven-test-plugin > Issue Type: Task >Affects Versions: 1.6.2, 1.7, 1.8 >Reporter: Arnaud Heritier >Priority: Minor > Fix For: 1.9 > > > Upgrade to Junit 4.0 > JUnit 4.1 isn't (yet) available on ibiblio. -- 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: (MPTEST-65) Upgrade to Junit 4.0
[ http://jira.codehaus.org/browse/MPTEST-65?page=all ] Arnaud Heritier closed MPTEST-65. - Resolution: Fixed Done > Upgrade to Junit 4.0 > > > Key: MPTEST-65 > URL: http://jira.codehaus.org/browse/MPTEST-65 > Project: maven-test-plugin > Issue Type: Task >Affects Versions: 1.6.2, 1.7, 1.8 >Reporter: Arnaud Heritier > Assigned To: Arnaud Heritier >Priority: Minor > Fix For: 1.9 > > > Upgrade to Junit 4.0 > JUnit 4.1 isn't (yet) available on ibiblio. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_69923 ] andrew commented on MNGECLIPSE-59: -- Scott Cytacki Can you repost your patch? all attachment seems lost from this server. thanks Andrew > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Assigned To: Eugene Kuleshov > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-161) allow declaring google analytics code in maven generated website
[ http://jira.codehaus.org/browse/MSITE-161?page=comments#action_69925 ] Brett Porter commented on MSITE-161: you can in xdoc - there isn't any way to add markup to APT. Perhaps site.xml could have some custom elements that would be pulled in as is to the standard template. Note that you can always replace the template to do this yourself. > allow declaring google analytics code in maven generated website > > > Key: MSITE-161 > URL: http://jira.codehaus.org/browse/MSITE-161 > Project: Maven 2.x Site Plugin > Issue Type: New Feature >Reporter: Milos Kleint > > as per discussion with trygve, i'm adding this issue. > I have a non maven-site-plugin solution at mojo.codehaus.org that does > postprocessing of the generated site. > http://fisheye.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/ganalytics-maven-mojo -- 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: (MSUREFIRE-148) SurefireBooter can initialize classloader with badly formed URLs
[ http://jira.codehaus.org/browse/MSUREFIRE-148?page=comments#action_69927 ] Brett Porter commented on MSUREFIRE-148: we support back to JDK 1.3, so we would need the explicit encoding - thanks for volunteering! > SurefireBooter can initialize classloader with badly formed URLs > > > Key: MSUREFIRE-148 > URL: http://jira.codehaus.org/browse/MSUREFIRE-148 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Reporter: Jeremy Boynes > > In SurefireBooter.createClassLoader() the path is converted to a URL using > File f = new File( url ); > urls.add( f.toURL() ); > File.toURL does not perform URL encoding so the resulting URL may contain > invalid characters. This is an issue on Windows machines where the default > maven repository is in "C:\Documents and Settings\user\.m2\..." (the filename > contains spaces). If a test accesses a resource that is loaded from a > dependency jar then the URL returned to that test is malformed. > With JDK 1.4 this can be fixed using > urls.add( f.toURI().toURL() ); > as toURI() does encode the path. If surefire still needs to run under pre-1.4 > JVMs this would need to be explicitly encoded. I'm willing to supply a patch > for that if wanted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-151) Ability to change the site directory in the plugin configuration in the pom.xml file.
[ http://jira.codehaus.org/browse/MSITE-151?page=all ] Brett Porter updated MSITE-151: --- Fix Version/s: (was: 2.0-beta-5) 2.0 > 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 > Issue Type: Improvement >Affects Versions: 2.0-beta-5 > Environment: All >Reporter: Mark Soderquist > Fix For: 2.0 > > 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] Closed: (MSITE-162) maven -N site does not generate index.html
[ http://jira.codehaus.org/browse/MSITE-162?page=all ] Brett Porter closed MSITE-162. -- Assignee: Brett Porter Resolution: Duplicate > maven -N site does not generate index.html > -- > > Key: MSITE-162 > URL: http://jira.codehaus.org/browse/MSITE-162 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: solaris 8 >Reporter: Andrew Williams > Assigned To: Brett Porter > > when using maven -N (through continuum) I run the site goal (and site:deploy) > but it fails to generate 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: (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=comments#action_69929 ] Brett Porter commented on MNG-2214: --- I'm not seeing this. > 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 > Issue 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] Commented: (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=comments#action_69930 ] Brett Porter commented on MNG-2214: --- I don't experience this issue > 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 > Issue 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-1493) Support in multiproject environment modules with different named POMs
[ http://jira.codehaus.org/browse/MNG-1493?page=all ] Brett Porter updated MNG-1493: -- Fix Version/s: (was: 2.0.5) 2.1 this will require a change to the POM (reusing the existing modules entry would be too confusing, IMO). Putting back to 2.1. > Support in multiproject environment modules with different named POMs > - > > Key: MNG-1493 > URL: http://jira.codehaus.org/browse/MNG-1493 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0 >Reporter: Joerg Schaible >Priority: Minor > Fix For: 2.1 > > > Command line version of Maven 2 supports POMs with a different name using the > -f option. Unfortunately such POMs cannot be used as modules, since the value > of the module tag is defined as a directory to another pom.xml instead of a > pathname to another POM. Only if the value is not already an existing file > the value should be treated as directory with a present pom.xml file. Similar > situation applies to the relativePath element of the parent tag. > This makes the generation of different artifacts from the same sources (with > some modifications) much more easy. Currently you will have to put the POMs > in separate directories and modify the sourec location into another module. -- 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-2294) If /project/parent/relativePath fails to resolve, no error is reported.
[ http://jira.codehaus.org/browse/MNG-2294?page=comments#action_69932 ] Brett Porter commented on MNG-2294: --- this is by design. If the relativePath doesn't exist, it is assumed to have been checked out in isolation and the parent is resolved from the repository. relativePath is just a development convience, not a strict part of the build. Perhaps we can improve the reporting of it, though. > 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 > Issue Type: Bug >Affects 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] Commented: (MNG-1545) some execution output not routed through default routes.
[ http://jira.codehaus.org/browse/MNG-1545?page=comments#action_69933 ] Brett Porter commented on MNG-1545: --- I think surefire should be fixed in the later plugins - can you confirm? > some execution output not routed through default routes. > > > Key: MNG-1545 > URL: http://jira.codehaus.org/browse/MNG-1545 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Milos Kleint >Priority: Critical > Fix For: 2.0.5 > > > when running embedded maven I create an instance of EventMonitor, > TransferListener and MavenEmbedderLogger. > however there's still some output that is not received through these means, > but rather printoed to standard output (I suppose) > that's wrong because it prohibits custom handling of output. > one example that I found is the surefire plugin's output.. everything > prepended with [surefire] is printed out wrongly.. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1465) Maven not able to find setter for MavenProjectHelper property
[ http://jira.codehaus.org/browse/MNG-1465?page=all ]
Brett Porter updated MNG-1465:
--
Fix Version/s: (was: 2.0.5)
2.1
pretty sure this will require plexus changes which I think we are holding until
Maven 2.1.
The reason this occurs is that @component fields (which is what
expression="${component.*}" represents, but is legacy notation), are Plexus
requirements, not configuration, so are handled differently.
> Maven not able to find setter for MavenProjectHelper property
> -
>
> Key: MNG-1465
> URL: http://jira.codehaus.org/browse/MNG-1465
> Project: Maven 2
> Issue Type: Bug
>Reporter: David Jackman
> Fix For: 2.1
>
>
> This might really be a plexus issue (I don't know enough about the code to
> know for sure).
> I have a Mojo class with a field of type MavenProjectHelper. For all other
> field, I've followed the pattern of using a private member field with a
> prefix of "m_", then using the property parameter to indicate a setter method
> for that field that Maven should use. This seems to work find for most of my
> properties, but the one that takes a MavenProjectHelper won't work that way.
> For some reason, it looks for a field of that name and not a setter method
> for that property.
> Here's the field definition and the setter method:
> /**
> * @parameter
> expression="${component.org.apache.maven.project.MavenProjectHelper}"
> property="projectHelper"
> */
> private MavenProjectHelper m_projectHelper;
> /**
> * Sets the project helper.
> *
> * @param projectHelper the project helper to use.
> */
> public void setProjectHelper(MavenProjectHelper projectHelper)
> {
> this.m_projectHelper = projectHelper;
> }
> And the error I get back when attempting to use the Mojo looks like this:
> [INFO] Internal error in the plugin manager executing goal
> 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
> the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> Component Composition failed. No field of name: 'projectHelper' exists in
> component: role: 'null', implementation:
> 'no.fast.buildprocess.ConfigdocJarMojo'
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar': Unable to find
> the mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
> 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:324)
> 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.PluginManagerException: Unable to find the
> mojo 'no.fast.buildprocess:docextractor:1.0-SNAPSHOT:configdocjar' in the
> plugin 'no.fast.buildprocess:docextractor'
> at
> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
> ... 16 more
> Cau
[jira] Updated: (MNG-1678) missing element does not trigger any warning
[ http://jira.codehaus.org/browse/MNG-1678?page=all ] Brett Porter updated MNG-1678: -- Affects Version/s: 2.0.4 I see it in 2.0.4 also. It should be strict parsing this, so there must be a bug in Modello. > missing element does not trigger any warning > > > Key: MNG-1678 > URL: http://jira.codehaus.org/browse/MNG-1678 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0, 2.0.4 >Reporter: Jorg Heymans > Fix For: 2.0.5 > > > spot the subtle error in below pom : > > > 4.0.0 > org.my.project > myProject > 0.1 > The Project > jar > > > apache-maven2-snapshot > Apache Maven2 Snapshot Repository > http://cvs.apache.org/maven-snapshot-repository > > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > > The dependency element is missing inside . Maven did not give > any warning or error though. > Note that in my actual project, the dependency was not needed for compilation -- 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: (MNG-2109) Stack trace with Internal error in the plugin manager executing goal
[ http://jira.codehaus.org/browse/MNG-2109?page=all ] Brett Porter closed MNG-2109. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 2.0.5) this was an error in the metadata that crept into the Maven repository for a short period of time. Please clean out your local repository (specifically maven-assembly-plugin). > Stack trace with Internal error in the plugin manager executing goal > > > Key: MNG-2109 > URL: http://jira.codehaus.org/browse/MNG-2109 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.2 > Environment: windows/cygwin and solaris >Reporter: Olivier Lamy > Assigned To: Brett Porter >Priority: Critical > Attachments: fulllog.txt > > > Hi, > I have a root pom with some modules : > - api (packaging jar) > - webapp (packaging accorwar internal plugin use with extension) > - tools > - site > The plugin accorwar is actually in a snapshot version. > When i run the cli accowar:clean in the root folder and if a new snapshot has > been detected/downloaded in the remote repository. > I have the following stack trace : > [INFO] Preparing accorwar:clean > Downloading: > http://57.200.214.247/snapshots/com/accor/maven/plugins/maven-accor > war-plugin/1.0-SNAPSHOT/maven-accorwar-plugin-1.0-20060216.171651-24.jar > 20K downloaded > [INFO] Reloading plugin container for: > com.accor.maven.plugins:maven-accorwar-pl > ugin. The plugin artifact has changed. > [INFO] [clean:clean] > [INFO] Deleting directory c:\projets\CommonTrunk\commontrunk-api\target > [INFO] Deleting directory > c:\projets\CommonTrunk\commontrunk-api\target\classes > [INFO] Deleting directory > c:\projets\CommonTrunk\commontrunk-api\target\test-cla > sses > - > this realm = > app0.child-container[com.accor.maven.plugins:maven-accorwar-plugin] > urls[0] = > file:/c:/local/maven/local-repository/repository/com/accor/maven/plugi > ns/maven-accorwar-plugin/1.0-SNAPSHOT/maven-accorwar-plugin-1.0-SNAPSHOT.jar > Number of imports: 0 > this realm = plexus.core.maven > urls[0] = file:/c:/maven-2.0.2/lib/commons-cli-1.0.jar > urls[1] = file:/c:/maven-2.0.2/lib/doxia-sink-api-1.0-alpha-7.jar > urls[2] = file:/c:/maven-2.0.2/lib/jsch-0.1.24.jar > urls[3] = file:/c:/maven-2.0.2/lib/maven-artifact-2.0.2.jar > urls[4] = file:/c:/maven-2.0.2/lib/maven-artifact-manager-2.0.2.jar > urls[5] = file:/c:/maven-2.0.2/lib/maven-core-2.0.2-javadoc.jar > urls[6] = file:/c:/maven-2.0.2/lib/maven-core-2.0.2.jar > urls[7] = file:/c:/maven-2.0.2/lib/maven-error-diagnostics-2.0.2.jar > urls[8] = file:/c:/maven-2.0.2/lib/maven-model-2.0.2.jar > urls[9] = file:/c:/maven-2.0.2/lib/maven-monitor-2.0.2.jar > urls[10] = file:/c:/maven-2.0.2/lib/maven-plugin-api-2.0.2.jar > urls[11] = file:/c:/maven-2.0.2/lib/maven-plugin-descriptor-2.0.2.jar > urls[12] = > file:/c:/maven-2.0.2/lib/maven-plugin-parameter-documenter-2.0.2.jar > urls[13] = file:/c:/maven-2.0.2/lib/maven-plugin-registry-2.0.2.jar > urls[14] = file:/c:/maven-2.0.2/lib/maven-profile-2.0.2.jar > urls[15] = file:/c:/maven-2.0.2/lib/maven-project-2.0.2.jar > urls[16] = file:/c:/maven-2.0.2/lib/maven-reporting-api-2.0.2.jar > urls[17] = file:/c:/maven-2.0.2/lib/maven-repository-metadata-2.0.2.jar > urls[18] = file:/c:/maven-2.0.2/lib/maven-settings-2.0.2.jar > urls[19] = file:/c:/maven-2.0.2/lib/plexus-interactivity-api-1.0-alpha-4.jar > urls[20] = file:/c:/maven-2.0.2/lib/wagon-file-1.0-alpha-7-SNAPSHOT.jar > urls[21] = file:/c:/maven-2.0.2/lib/wagon-http-lightweight-1.0-alpha-6.jar > urls[22] = file:/c:/maven-2.0.2/lib/wagon-provider-api-1.0-alpha-6.jar > urls[23] = file:/c:/maven-2.0.2/lib/wagon-ssh-1.0-alpha-6.jar > urls[24] = file:/c:/maven-2.0.2/lib/wagon-ssh-external-1.0-alpha-6.jar > Number of imports: 0 > this realm = plexus.core > urls[0] = file:/c:/maven-2.0.2/core/plexus-container-default-1.0-alpha-9.jar > urls[1] = file:/c:/maven-2.0.2/core/plexus-utils-1.1.jar > Number of imports: 0 > - > [INFO] > - > --- > [ERROR] BUILD ERROR > [INFO] > - > --- > [INFO] Internal error in the plugin manager executing goal > 'com.accor.maven.plug > ins:maven-accorwar-plugin:1.0-SNAPSHOT:clean': Unable to find the mojo > 'com.acco > r.maven.plugins:maven-accorwar-plugin:1.0-SNAPSHOT:clean' in the plugin > 'com.acc > or.maven.plugins:maven-accorwar-plugin' > org/codehaus/plexus/archiver/ArchiverException > [INFO] > - > --- > [INFO] For more information, run Maven with the -e switch > [INFO] > --
[jira] Closed: (MNG-1975) EAR project depends on WAR that doesn't exist, but it builds succesfully
[ http://jira.codehaus.org/browse/MNG-1975?page=all ] Brett Porter closed MNG-1975. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.0.5) > 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 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2 > Environment: Debian GNU/Linux Etch (Testing), Eclipse WTP 1.0 >Reporter: Duncan Doyle > Assigned To: Brett Porter > > 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: > > 4.0.0 > Tour de France Service > nl.doyle.mccloud.TourDeFranceService > 0.0.1 > TourDeFranceService > pom > > ../TourDeFranceServiceEAR >../TourDeFranceServiceWeb > > > This my WAR pom.xml: > > 4.0.0 > Tour de France Service Web > nl.doyle.mccloud.TourDeFranceService > TourDeFranceServiceWeb > war > 0.0.2 > > > junit > junit > 3.8.1 > test > > > > > >org.apache.maven.plugins >maven-war-plugin > > ../TourDeFranceServiceWeb/WebContent/WEB-INF/web.xml > > > >TourDeFranceServiceWeb > > > And this my EAR pom.xml with the wrong version number of the WAR project: > > 4.0.0 > Tour de France Service EAR > nl.doyle.mccloud.TourDeFranceService > TourDeFranceServiceEAR > ear > 0.0.1 > > > nl.doyle.mccloud.TourDeFranceService > TourDeFranceServiceWeb > war > 1.0.2 > > > > TourDeFranceServiceEAR > > > 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: (MNG-1905) Delete remote files before uploading them to avoid permission problems
[ http://jira.codehaus.org/browse/MNG-1905?page=comments#action_69940 ] Brett Porter commented on MNG-1905: --- there's a risk that this will cause metadata to be erased and then uploading the new one will fail (which can't be rolled back). Currently, since this is done last a failure means the old version continues to be used which is not as serious. How could we accommodate that possibility? > Delete remote files before uploading them to avoid permission problems > -- > > Key: MNG-1905 > URL: http://jira.codehaus.org/browse/MNG-1905 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.2 >Reporter: Carlos Sanchez > Fix For: 2.0.5 > > > If metadata files in server are owned by other person and not group writeable > wagon doesn't try to delete them first, causing a permission denied error > org.apache.maven.lifecycle.LifecycleExecutionException: Error installing > artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: > unable to open > /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: > permission denied > 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: Error installing > artifact's metadata: Error while deploying metadata: Exit code: 1 - pscp: > unable to open > /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: > permission denied > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:414) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more > Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: > Error installing artifact's metadata: Error while deploying metadata: Exit > code: 1 - pscp: unable to open > /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: > permission denied > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:99) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) > ... 18 more > Caused by: > org.apache.maven.artifact.repository.metadata.RepositoryMetadataDeploymentException: > Error while deploying metadata: Exit code: 1 - pscp: unable to open > /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven-metadata.xml: > permission denied > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java:433) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:83) > ... 19 more > Caused by: org.apache.maven.wagon.TransferFailedException: Exit code: 1 - > pscp: unable to open > /home/projects/maven/repository-staging/snapshots/maven2/org/apache/maven/plugins/maven-checkstyle-plugin/maven
[jira] Commented: (MNG-2365) classes before test-classes in MavenProject.getTestClasspathElements() - should be the other way around?
[ http://jira.codehaus.org/browse/MNG-2365?page=comments#action_69941 ] Brett Porter commented on MNG-2365: --- while this makes sense to me, ISTR having to change this in the past. Please investigate SVN history before doing this. > 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 > Issue Type: Bug >Affects 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] Commented: (MNG-2391) improve validation of POM elements
[ http://jira.codehaus.org/browse/MNG-2391?page=comments#action_69942 ] Brett Porter commented on MNG-2391: --- I believe this should be done via the modello model. It would be worth reusing something for this (particularly in light of JSR 303). commons-validator may be a good alternative for now (not sure using the stuff from xwork is appropriate). > improve validation of POM elements > -- > > Key: MNG-2391 > URL: http://jira.codehaus.org/browse/MNG-2391 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: Brett Porter > Fix For: 2.0.5 > > > this needs to go beyond basic construction. > In particular, the group and artifact ID should always be constrained to > valid characters. > Perhaps this could be done via the modello model. -- 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: (MNG-1956) profile build without pluginManagement fails if pom build has pluginManagement
[ http://jira.codehaus.org/browse/MNG-1956?page=all ] Brett Porter closed MNG-1956. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.0.5) > profile build without pluginManagement fails if pom build has pluginManagement > -- > > Key: MNG-1956 > URL: http://jira.codehaus.org/browse/MNG-1956 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.1 >Reporter: Shinobu Kawai > Assigned To: Brett Porter > Attachments: pom.xml > > > If the build sections has a pluginManagement, profiles without > pluginManagement fails with the following: > [INFO] Scanning for projects... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.project.injection.DefaultProfileInjector.injectPlugins(DefaultProfileInjector.java:147) > at > org.apache.maven.project.injection.DefaultProfileInjector.injectBuild(DefaultProfileInjector.java:134) > at > org.apache.maven.project.injection.DefaultProfileInjector.inject(DefaultProfileInjector.java:80) > at > org.apache.maven.project.DefaultMavenProjectBuilder.injectActiveProfiles(DefaultMavenProjectBuilder.java:1037) > at > org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:838) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:594) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:304) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) > 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: < 1 second > [INFO] Finished at: Wed Jan 11 16:29:00 PST 2006 > [INFO] Final Memory: 1M/2M > [INFO] > > Attached is a sample pom.xml to reproduce. > Workaround is to put an empty in the profile build. -- 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: (MNG-2152) pom.xml and pom.properties in JAR file causes JBOSS SARDeployer to fail.
[ http://jira.codehaus.org/browse/MNG-2152?page=all ] Brett Porter closed MNG-2152. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: 2.0.5) it depends on what you are using to produce the SAR. Many Maven plugins already support configuration to disable it (see the guides page, regarding configuring archive plugins). If it is a plugin, then it needs to be filed against the plugin, not Maven. Thanks. > pom.xml and pom.properties in JAR file causes JBOSS SARDeployer to fail. > > > Key: MNG-2152 > URL: http://jira.codehaus.org/browse/MNG-2152 > Project: Maven 2 > Issue Type: Bug > Components: POM, Plugin API >Affects Versions: 2.0.1 > Environment: Windows, JBOSS-4.0.1sp1 >Reporter: Walt Barrow > Assigned To: Brett Porter > Attachments: ESS-PD-1.1-DEV.sar > > > I am creating a JAR file which is then packaged into JBOSS MBean Service > Archives (SARs). When the JAR file is created it contains the following > files: > META-INF\maven\SJL\WorkflowManagerMBean\pom.xml > META-INF\maven\SJL\WorkflowManagerMBean\pom.properties > The JAR file is then embedded into a SAR file which is nothing more than a > JAR file with a ".sar" extension plus a special jboss-service.xml file. > When I try to deploy the SAR to JBOSS, it fails because it cannot resolve the > classloader for the classes in the JAR file. When I remove the pom.xml file > from the embedded JAR file, then the SAR file deploys properly. > Is this a known issue? Is there any way to surpress the inclusion of the > pom.xml file in the target JAR file? > Perhaps there should be a mechanism to surpress such information should the > need arise. > Thank you! -- 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: (MNG-2223) Interpolation in resources section appears not to work correctly
[ http://jira.codehaus.org/browse/MNG-2223?page=all ]
Brett Porter closed MNG-2223.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: 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
> Issue Type: Bug
>Affects Versions: 2.0.4
>Reporter: Jason van Zyl
> Assigned To: Brett Porter
>
> 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.
>
> 4.0.0
> org.apache.maven.it
> maven-core-it0090
> 1.0
>
>
> junit
> junit
> 3.8.1
> jar
> test
>
>
>
> true
> jason
>
>
>
>
> src/main/resources
> ${filter.resources}
>
>
>
>
--
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-2174) do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a
[ http://jira.codehaus.org/browse/MNG-2174?page=comments#action_69944 ] Brett Porter commented on MNG-2174: --- this needs to be checked from an inheritence perspective, but there's also a chance that it's just a victim of the bug where only plugin dependencies from the first POM activating the plugin are taken (which is a more complicated fix as it pertains to how the plugin classloader is constructed). In both cases, the workaround is to put the plugins with dependencies in the root POM. > do not propogate to child > POM plugins (potentially scoped to only affecting child POM plugins that live > within a ) > - > > Key: MNG-2174 > URL: http://jira.codehaus.org/browse/MNG-2174 > Project: Maven 2 > Issue Type: Bug >Reporter: John Allen > Fix For: 2.0.5 > > > do not propogate to child > POM plugins. > Kenny believe this works OKAY if the childs are using the parent > preconfigured plugins in their main section > however it does NOT work if the childs are trying to use those preconfigured > plugins via their own . Configuration propogates through okay but > dependencies are missing and have to be respecified in the child POMs. -- 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-2174) do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a )
[ http://jira.codehaus.org/browse/MNG-2174?page=all ] Brett Porter updated MNG-2174: -- Fix Version/s: (was: 2.0.5) 2.1 moving out to 2.1. Even if the management inheritence is incorrect, fixing it won't help a great deal until the classloader construction is fixed > do not propogate to child > POM plugins (potentially scoped to only affecting child POM plugins that live > within a ) > - > > Key: MNG-2174 > URL: http://jira.codehaus.org/browse/MNG-2174 > Project: Maven 2 > Issue Type: Bug >Reporter: John Allen > Fix For: 2.1 > > > do not propogate to child > POM plugins. > Kenny believe this works OKAY if the childs are using the parent > preconfigured plugins in their main section > however it does NOT work if the childs are trying to use those preconfigured > plugins via their own . Configuration propogates through okay but > dependencies are missing and have to be respecified in the child POMs. -- 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: (MNG-2219) artifactId appended to URL in scm reports. Problem apparently comes from the core.
[ http://jira.codehaus.org/browse/MNG-2219?page=all ] Brett Porter closed MNG-2219. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 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 > Issue Type: Bug >Reporter: Jerome Lacoste > Assigned To: Brett Porter > > 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
