[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 > org.apache.maven.plugins > maven-changelog-plugin > 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: > > 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: (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 ).
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 ).
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 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] Updated: (MNG-1987) Set a minimal standard for plug-in documentation
[ http://jira.codehaus.org/browse/MNG-1987?page=all ] Marvin King updated MNG-1987: - Due Date: 26/Jun/06 > Set a minimal standard for plug-in documentation > > > Key: MNG-1987 > URL: http://jira.codehaus.org/browse/MNG-1987 > Project: Maven 2 > Type: Wish > Components: Documentation: General > Reporter: Bengt-Erik Fröberg > Assignee: Marvin King > Fix For: 2.0.5 > > > There are many repositories and providers of Maven2 plugins. > However, layout and,above all, content vary in lenghth and information value. > A few providers had made efforts to document, and others tend to completely > skip this step > as if one could guess how to configure or use the plugin in the best way. > I had a very positive and inspiring experience with the > http://cargo.codehaus.org/Maven2+plugin plugin documentation, and from a > pedagogical and user-oriented point of view this makes the difference between > "yes" and "no way". > Compare this to the sparse deploy:deploy plugin docs. > I will try to pinpoint the reasons my immediate love with this documentation > style: > 1) From very basic to advanced (minimal, small-intermediate and full-fledged > configuration) - pedagogical > 2) Listing of different use-cases with appropriate descriptions. Note the > progressive approach - no guessing games needed and very pedagogical. > 3) Examples, examples and examples - show us how it's done, and we get > happy!!! > It does not matter that there are some "TODO"s in the page, you just love > the guys that wrote it. > I really would like a minimal set of criteria being fulfilled in terms of > documentation: At least three levels of config, > some common and some special use cases and a lot of example code. > In some other plugin docs there are examples, that's true, but I don't think > they interact very well with the written text. > One example is http://maven.apache.org/plugins/maven-antrun-plugin/usage.html > (at least this plugin has a "usage" section. > Slightly uninformative text aside the examples, and some references to things > you obviously should know... > I hope this could lead to a discussion about docs in general, but plugin ones > especially. > Regards, > /B-E Fröberg -- 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 > > webapp1 > coreAPI > appEAR > > 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 section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> 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. (system) > 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:
>
>
>
> dev
>
>
> src/main/filters/dev-default.values
>
>
>
> auto-test
>
>
> src/main/filters/auto-test-default.values
>
>
>
> man-test
>
>
> src/main/filters/man-test-default.values
>
>
>
> prod
>
>
> src/main/filters/prod-default.values
>
>
>
>
>
> child pom..
>
>
>
>
> ${user.default.values}
>
>
>
> ${profile-default.values}
> ${user.default.values}
> ${client-ct-package.values}
>
>
>
> src/main/resources
> true
>
>
>
>
>
>
> prod
>
>
> deploy-ct
>
>
--
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|cvs|local|s:/home/cvsroot| [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 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: > ../parent > and > ../child > 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 cut&paste -- 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:
>
> gallup.maven
> services-provider-maven-plugin
> 1.0.1
>
>
> com/g/util/ServiceProvider.java
>
>
>
> process-classes
>
> generate
>
>
>
>
>
> 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 provided 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-2300) broken links on http://maven.apache.org/plugins/
[ http://jira.codehaus.org/browse/MNG-2300?page=all ] John Casey updated MNG-2300: Fix Version: 2.0.5 > broken links on http://maven.apache.org/plugins/ > - > > Key: MNG-2300 > URL: http://jira.codehaus.org/browse/MNG-2300 > Project: Maven 2 > Type: Task > Components: Documentation: General > Reporter: Rainer Wasserfuhr > Fix For: 2.0.5 > > > e.g. to changes -- 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:
>
>
>
> dev
>
>
> src/main/filters/dev-default.values
>
>
>
> auto-test
>
>
> src/main/filters/auto-test-default.values
>
>
>
> man-test
>
>
> src/main/filters/man-test-default.values
>
>
>
> prod
>
>
> src/main/filters/prod-default.values
>
>
>
>
>
> child pom..
>
>
>
>
> ${user.default.values}
>
>
>
> ${profile-default.values}
> ${user.default.values}
> ${client-ct-package.values}
>
>
>
> src/main/resources
> true
>
>
>
>
>
>
> prod
>
>
> deploy-ct
>
>
--
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
> section of the POM.
> Directories created by the other standard lifecycle sections like the
> 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):
> 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";>
> 4.0.0
> at.struct.mvntest
> mvntest
> jar
> 1.0-SNAPSHOT
> MSX Maven Test App
>
> msxtarget
> msxtarget/classes
>
>
> msxreports
>
>
> 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 ... is missing
wagon-webdav does not ask for auth password when ... 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 ... 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 ... 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 ... 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 > ... 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: > > mperham > http://wiki:9090/display/~mperham > > 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: > > > > > middlegen > > middlegen-hibernate-plugin > 2.1 > > > > 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-1408) filesetId does not contain all dependencies when artifact was not yet locally installed
[ http://jira.codehaus.org/browse/MNG-1408?page=all ] John Casey updated MNG-1408: Fix Version: 2.0.5 > filesetId does not contain all dependencies when artifact was not yet locally > installed > --- > > Key: MNG-1408 > URL: http://jira.codehaus.org/browse/MNG-1408 > Project: Maven 2 > Type: Bug > Components: Ant tasks > Versions: 2.0 > Environment: java version "1.4.2_04", Linux 2.6.11.12, Apache Ant version > 1.6.5 > Reporter: Ingo Weichsel > Fix For: 2.0.5 > Attachments: patch.txt > > > In the artifact:dependencies task the filesetId is only correctly set, when > the artifact was installed locally before running ant. > After deletion of the local repository the dependant artifacts will be > downloaded to the local repository, but only one of two dependant files will > be included in the ant fileset. The classpath is set correctly. > After running "mvn install" locally for the "as-base-launcher" maven project, > ant computes the correct filesetId. > The ant-project depends on the artifact "as-base-launcher" which itselfs > depends only on classworlds. Snippets from ant buildfiles, poms and ant > output follows: > From the ant buildfile: > > > > pathId="as-launcher.classpath" verbose="true"> > > > > > > > > > > > > > > > > > The referenced POM defining the ant dependencies: > > 4.0.0 > actis > ant-as-base > 1.0-SNAPSHOT > > > actis > as-base-launcher > 1.0-SNAPSHOT > > > > > actisRepository > actisRepository > http://company.com:/repository/ > > > > Output of the ant run: > launcherJAR: > actis:ant-as-base:jar:1.0-SNAPSHOT (selected) > actis:as-base-launcher:jar:1.0-SNAPSHOT (selected) > classworlds:classworlds:jar:1.1-alpha-1 (selected) > [echo] CLASSPATH: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar:/home/iwe/.m2/repository/actis/as-base-launcher/1.0-20051103.102305-8/as-base-launcher-1.0-20051103.102305-8.jar > [echo] FILESET: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2391) improve validation of POM elements
[ http://jira.codehaus.org/browse/MNG-2391?page=all ] John Casey updated MNG-2391: Fix Version: 2.0.5 > improve validation of POM elements > -- > > Key: MNG-2391 > URL: http://jira.codehaus.org/browse/MNG-2391 > Project: Maven 2 > 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] 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.
>
> 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] 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: > > > env-test > > > Adding an empty profiles section does not help: > > > > > env-test > > > Well, adding a dummy profile makes it work: > > > > dummy > > > > env-test > > > 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
[ http://jira.codehaus.org/browse/MNG-2392?page=all ] John Casey updated MNG-2392: Fix Version: 2.0.5 > document > > > 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-2387) on in settings is misleading
[ http://jira.codehaus.org/browse/MNG-2387?page=all ] John Casey updated MNG-2387: Fix Version: 2.0.5 > on in settings is misleading > - > > Key: MNG-2387 > URL: http://jira.codehaus.org/browse/MNG-2387 > Project: Maven 2 > Type: Task > Components: Settings > 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-2178) incorrect M2_HOME guess in mvn.bat
[ http://jira.codehaus.org/browse/MNG-2178?page=all ] John Casey updated MNG-2178: Fix Version: 2.0.5 > incorrect M2_HOME guess in mvn.bat > -- > > Key: MNG-2178 > URL: http://jira.codehaus.org/browse/MNG-2178 > Project: Maven 2 > Type: Bug > Components: Bootstrap & Build > Versions: 2.0.2 > Environment: WXP > Reporter: Jörg Henne > Fix For: 2.0.5 > > > mvn.bat contains the following lines: > :chkMHome > if not "%M2_HOME%"=="" goto valMHome > if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\.. > if not "%M2_HOME%"=="" goto valMHome > Guessing M2_HOME=%~dps0\.. leads to complaints later on, since the script > expects m2.bat in bin/...: > if exist "%M2_HOME%\bin\m2.bat" goto init > Hence, the line should read: > if "%OS%"=="Windows_NT" SET M2_HOME=%~dps0\..\.. -- 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-2256) Misleading documentation regarding configuration of java.utils.Properties
[ http://jira.codehaus.org/browse/MNG-2256?page=all ]
John Casey updated MNG-2256:
Fix Version: 2.0.5
> Misleading documentation regarding configuration of java.utils.Properties
> -
>
> Key: MNG-2256
> URL: http://jira.codehaus.org/browse/MNG-2256
> Project: Maven 2
> Type: Bug
> Components: Documentation: General
> Reporter: James Talmage
> Fix For: 2.0.5
>
>
> Location:
> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> Snippet:
> {quote}
> Properties
> This category covers any map which implements java.util.Properties. These
> parameters are configured by including XML tags in the form value
> in the parameter configuration.
> {quote}
> This lead me to believe I could set properties like this:
> {quote}
>
>
>
> propertyValue
>
>
> .
> {quote}
> Instead I've found I need to do it like this:
> {quote}
>
>
>
>
>propertyName
>propertyValue
>
>
>
> .
> {quote}
--
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: (MNG-2339) ${project.*} are interpreted in the wrong place
[ http://jira.codehaus.org/browse/MNG-2339?page=comments#action_67975 ]
Carlos Sanchez commented on MNG-2339:
-
In surefire-providers
${project.groupId}
surefire-api
2.1-SNAPSHOT
If you put back ${project.version}, deploy and clean your
repo org/apache/maven/surefire dir, you'll get the problem
> ${project.*} are interpreted in the wrong place
> ---
>
> Key: MNG-2339
> URL: http://jira.codehaus.org/browse/MNG-2339
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.0.4
> Reporter: Emmanuel Venisse
> Priority: Critical
> Fix For: 2.0.5
>
>
> If a plugin use ${project.version}, this parameter is interpreted with the
> version of the current project and not the plugin version. I think we have
> the same pb with dependencies and other ${project.*}
> For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT,
> ${project.version} used in the plugin will be interpreted as 1.0-SNAPSHOT
> instead of 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] 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:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
scm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
{code}
turns to
{code:xml}
scm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
scm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
{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 section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> 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 > 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) > ... 2
[jira] Moved: (MJAR-46) maven-jar-plugin doesn't accept 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 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-2009) Add new element in the POM model
[ http://jira.codehaus.org/browse/MNG-2009?page=all ] John Casey updated MNG-2009: Fix Version: 2.1 > Add new element in the POM model > - > > Key: MNG-2009 > URL: http://jira.codehaus.org/browse/MNG-2009 > Project: Maven 2 > Type: Task > Components: POM > Reporter: Vincent Massol > Fix For: 2.1 > > > This is to support the new surefire:integration-test mojo (MSUREFIRE-50). -- 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-2193) Add ability to exclude a report mojo from executing
[ http://jira.codehaus.org/browse/MNG-2193?page=all ] John Casey updated MNG-2193: Fix Version: 2.1 > Add ability to exclude a report mojo from executing > --- > > Key: MNG-2193 > URL: http://jira.codehaus.org/browse/MNG-2193 > Project: Maven 2 > Type: Improvement > Components: Sites & Reporting > Versions: 2.0.3 > Reporter: Vincent Massol > Fix For: 2.1 > > > Here's a use case (see also MCLOVER-19): > * I'm working on the clover plugin > * I have one report mojo that forks a custom lifecycle (this one instruments > the source code, runs the tests and generate a report) > * I'd like to have another report which simply takes an existing clover > database and generate a report out of it > Right now it's not possible to implement such a use case as by default all > report mojos are executed. I'd need to exclude the first report mojo (the one > that forks a lifecycle) from executing when the second report mojo is > executing. > Thanks -- 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: > > bookstore-web > > > xdoclet > maven-xdoclet-plugin > 1.2 > > > generate-deployment-decriptor > generate-sources > > > > > >web.xml >src/main/webapp/WEB-INF > > > > webdoclet > > > > > > 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 properties, but that's not as > clean as allowing the user to explicitly specify a element on the > element in settings.xml or as a "publickey" attribute on the > 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 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 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}
>
>
>
> ...
>
>
>
> {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}
>
>
>
> foo
> bar
>
>
> global
>
> baz
>
>
>...
>
>
>
>
>
>
> {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
