[jira] Commented: (MRELEASE-113) prepare dryRun should also run site:site
[ http://jira.codehaus.org/browse/MRELEASE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112434 ] Joerg Schaible commented on MRELEASE-113: - You can configure the executed goals for prepare and perform yourself. > prepare dryRun should also run site:site > > > Key: MRELEASE-113 > URL: http://jira.codehaus.org/browse/MRELEASE-113 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Mike Perham > > Currently just runs 'clean integration-test'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1542) Surefire Report in continuum contains excess/superfluous test methods.
[ http://jira.codehaus.org/browse/CONTINUUM-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1542: Assignee: Olivier Lamy Fix Version/s: 1.1 > Surefire Report in continuum contains excess/superfluous test methods. > -- > > Key: CONTINUUM-1542 > URL: http://jira.codehaus.org/browse/CONTINUUM-1542 > Project: Continuum > Issue Type: Bug > Components: Testing >Reporter: Joakim Erdfelt >Assignee: Olivier Lamy > Fix For: 1.1 > > > When looking at the surefire test results within a continuum build that > reported a failure, the list of test methods for the tested class contains > extra methods from other tested classes. > Continuum on maven.zones.apache.org [surefire report example with > problem|http://maven.zones.apache.org/continuum/surefireReport.action;jsessionid=10vfs6g7jbl9f?buildId=32827&projectId=296#org.apache.maven.archiva.web.repository.RepositoryServletProxiedReleasePolicyTest] > If you look at the list of test methods for > RepositoryServletProxiedReleasePolicyTest you can see that the report shows > the correct # of tests at the top with 15, but when you goto the details for > that test, you see well over 15 tests. > In fact, when you look at the section that starts with "Test Cases" you can > see that the list of tests for each Test class is actually the list of tests > from the previous Test class + the tests for the current Test class. > Example: > +RepositoryServletNoProxyMetadataTest+ > > (/) testGetVersionMetadataDefaultLayout > (/) testGetProjectMetadataDefaultLayout > (/) testGetSnapshotVersionMetadataDefaultLayout > +ArchivaMimeTypeLoaderTest+ > > (/) -testGetVersionMetadataDefaultLayout- > (/) -testGetProjectMetadataDefaultLayout- > (/) -testGetSnapshotVersionMetadataDefaultLayout- > (/) testArchivaTypes > +RepositoryServletProxiedPluginSnapshotPolicyTest+ > > (/) -testGetVersionMetadataDefaultLayout- > (/) -testGetProjectMetadataDefaultLayout- > (/) -testGetSnapshotVersionMetadataDefaultLayout- > (/) -testArchivaTypes- > (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedNewer > (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedOlder > (/) testGetProxiedSnapshotsArtifactPolicyAlwaysNoManagedContent > (/) testGetProxiedSnapshotsArtifactPolicyDailyFail > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112431 ] Stephane Nicoll commented on MWAR-33: - Having the ability to deploy the server-side code is actually a good idea and I used it in most projects with the build-helper plugin. I'd like to make this a feature of the war plugin. Since we have many watchers over here, I'm open to suggestions with regard to the classifier's name + parameter name (war-client does not sound intuitive to me but I guess you used that for illustration purposes) > jars with differents versions can be in WEB-INF/lib with war as dependencies > > > Key: MWAR-33 > URL: http://jira.codehaus.org/browse/MWAR-33 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy >Assignee: Stephane Nicoll > Fix For: 2.1-alpha-2 > > Original Estimate: 15 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > My pom has the following dependencies : > - log4j:log4j:1.2.13 > - a war with log4j:log4j:1.2.11 included > Result the two jars are in WEB-INF/lib. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112430
]
Stephane Nicoll commented on MWAR-116:
--
Still trying to figure out how to avoid the filtering
> The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
>
>
> Key: MWAR-116
> URL: http://jira.codehaus.org/browse/MWAR-116
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Chris Moesel
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: mwar_93_webapp.zip
>
>
> I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
> the following to my POM:
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-alpha-1-SNAPSHOT
>
> ${artifactId}.${extension}
>
>
> This results in really oddly named files in my web-inf/lib now. A typical
> example:
> org.springframework-mywebapp.null
> So, the resulting files are really mapped more like: ${groupId of the
> dependency}-${artifactId of my war module}.null
> I've attached an example Maven 2 project that demonstrates this. Just run
> "mvn package" and look at the result in target.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MNG-3269) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MNG-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll moved MWAR-114 to MNG-3269: --- Affects Version/s: (was: 2.1-alpha-1) 2.0.7 Fix Version/s: (was: 2.1-alpha-2) Key: MNG-3269 (was: MWAR-114) Project: Maven 2 (was: Maven 2.x War Plugin) > Different builds for ejb-client optional with parent > > > Key: MNG-3269 > URL: http://jira.codehaus.org/browse/MNG-3269 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Tim Reilly > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.1-alpha-1.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2864) Optional is not transitive
[ http://jira.codehaus.org/browse/MNG-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112425 ] Stephane Nicoll commented on MNG-2864: -- I agree this is clearly a hack that should be addressed. Not sure that we need yet another scope for that. It could be an explicit configuration of the war plugin. > Optional is not transitive > -- > > Key: MNG-2864 > URL: http://jira.codehaus.org/browse/MNG-2864 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: Bernhard Mähr >Priority: Minor > Fix For: Reviewed Pending Version Assignment > > > Hello! > I have this situation: > WAR > |- compile/optional> POM compile ---> JAR1 > |- compile/optional> JAR2 > If I build WAR I get a war-file with the Manifest entries JAR1 and JAR2 and > the file JAR1 in WEB-INF\lib. > I would expect a war-file with the Manifest entries JAR1 and JAR2 and no > WEB-INF\lib. > It seams to me that JAR1 is included because the second dependency is > without optional and the optional from the frist dependency is not transitive > to the second dependency. > Generally I think it is a hack to use the combination compile/optional to > decide a lib should be included in Manifest but not in the lib dir. I think > the should be an additional scope betwen compile and provided for this > purpose. > Bernhard Mähr -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-114) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MWAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112423 ] Stephane Nicoll commented on MWAR-114: -- I guess you need this for the manifest? Otherwise can't you put it provided? > Different builds for ejb-client optional with parent > > > Key: MWAR-114 > URL: http://jira.codehaus.org/browse/MWAR-114 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Tim Reilly > Fix For: 2.1-alpha-2 > > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.1-alpha-1.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-114) Different builds for ejb-client optional with parent
[ http://jira.codehaus.org/browse/MWAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112422 ] Stephane Nicoll commented on MWAR-114: -- Note sure it's a WAR issue. The optional flag is not passed to the war plugin, period. You will have the same kind of issue with the EAR if you put the ejb-client optional This is a Maven core issue. > Different builds for ejb-client optional with parent > > > Key: MWAR-114 > URL: http://jira.codehaus.org/browse/MWAR-114 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Tim Reilly > Fix For: 2.1-alpha-2 > > Attachments: MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.0.2.patch, > MWAR114-maven-war-plugin-2.1-alpha-1.patch, mytime.zip > > > When trying to package a j2ee project's ejb-client artifact in the ear /lib > directory the war plugin's optional attribute is ignored if building from the > parent app project. If you build from the parent project you get the > ejb-client packaged in the web-inf/lib directory. If you build the ejb, war, > and ear independently you get the ejb-client packaged in the ear /lib > directory. It seems when run from the parent project the dependency/artifact > doesn't have the optional attribute set. > Perhaps this is b/c the artifact is a project artifact that was attached from > the ejb plugin it is not resolved as optional when the dependency is resolved > from the war project. > Attaching Geronimo's mytime sample with modifications to reproduce the > behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1790) jline 0.9.92
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112420 ] Marc Prud'hommeaux commented on MAVENUPLOAD-1790: - I remove it and re-uploaded it. Sorry about that. > jline 0.9.92 > > > Key: MAVENUPLOAD-1790 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1790 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Prud'hommeaux > > JLine is a popular Java library for handling console input. It is similar in > functionality to BSD editline and GNU readline. People familiar with the > readline/editline capabilities for modern shells (such as bash and tcsh) will > find most of the command editing features of JLine to be familiar. > See also: http://jira.codehaus.org/browse/MAVENUPLOAD-1003 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1792) 4.1 Release of Dozer
4.1 Release of Dozer Key: MAVENUPLOAD-1792 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1792 Project: maven-upload-requests Issue Type: Task Reporter: Franz Garsombke Attachments: dozer-4.1-bundle.jar I have attached the bundle to this Jira Request. The source can be found at: http://sourceforge.net/project/showfiles.php?group_id=133517 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-9) Avoid to bundle rar dependencies (w/o scope=provided) inside the rar archive
[
http://jira.codehaus.org/browse/MRAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112418
]
Dave Meibusch commented on MRAR-9:
--
Perhaps a solution mirroring the ear plugin functionality:
http://maven.apache.org/plugins/maven-ear-plugin/examples/excluding-a-module.html
> Avoid to bundle rar dependencies (w/o scope=provided) inside the rar archive
>
>
> Key: MRAR-9
> URL: http://jira.codehaus.org/browse/MRAR-9
> Project: Maven 2.x Rar Plugin
> Issue Type: New Feature
>Affects Versions: 2.1
> Environment: Maven 2.0.4
>Reporter: Carsten Karkola
>Assignee: Stephane Nicoll
> Fix For: 2.3
>
>
> If I use "provided" the dependencies will never be included, my problem is
> 1. projects:
> my-jar
> rar1: dependency to my-jar
> rar2: dependency to my-jar
> ejb1: dependency to my-jar
> ear: dependency to rar1, rar2. ejb1
> 2. inside the ear:
> ejb1.jar
> rar1.rar
> rar2.rar
> lib/my-jar.jar
> 3. This works fine for packaging=ejb - the my-jar.jar gets copied to the lib
> dir during build of
> the ear. But the same jar gets also packaged in the rar1 and in the rar2
> archive. So I have it
> three times instead only having the entries in MANFIFEST.MF/Class-Path and
> the jar only
> once in the lib subdir.
> The Manifest entries are not the problem, to get the jar not packaged in the
> rars is my
> problem.
> 4. my proposal:
> add plugin configuration parameter
> false
> in RarMojo.java additional parameter and check:
> /**
> * Specify if the specified dependencies of this project should be
> * included in the rar file ; default is true.
> *
> * @parameter
> */
> private Boolean includeDependencies = Boolean.TRUE;
>
> // Copy dependencies
> try
> {
> if (includeDependencies.booleanValue()) { // additional check
> carsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-333: - Affects Version/s: (was: 2.5) 2.4 Fix Version/s: 2.5 > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.4 >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-173) Project should be considered a Java project if it has at least one source folder even if the language of its artifact handler is not java
[
http://jira.codehaus.org/browse/MECLIPSE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-173:
-
Fix Version/s: (was: 2.5)
> Project should be considered a Java project if it has at least one source
> folder even if the language of its artifact handler is not java
> -
>
> Key: MECLIPSE-173
> URL: http://jira.codehaus.org/browse/MECLIPSE-173
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: PDE support
>Affects Versions: 2.2
>Reporter: Cédric Vidal
> Attachments: MECLIPSE-173.patch
>
>
> Use case:
> - I have non java source files in src/main/foo (for example a UML model)
> - the "foo" artifact handler builds a zip containing the "foo" source files
> and its language is not "java" (for example the UML model zipped)
> - I have a "bar" plugin which generates "bar" java source files from the
> "foo" source files in target/generated-sources/bar. (for example an MDA
> plugin)
> - The "bar" plugin also builds a jar containing the
> target/generated-sources/bar java source files and attachs it with a "bar"
> classifier.
> So even if the language of my project's artifact handler is not set to
> "java", since my project contains java source code (generated), my project
> should be considered a java project so that it can be referenced in
> multiproject mode by other projects in their build path.
> The effect is obtained by replacing :
> isJavaProject = "java".equals( artifactHandler.getLanguage() ) &&
> !"ear".equals( packaging );
> by
> isJavaProject = ("java".equals(artifactHandler.getLanguage()) ||
> sourceDirs.length > 0)
> && !"ear".equals(packaging);
> and moving the code which builds the sourceDirs from the
> EclipsePlugin#writeConfiguration( IdeDependency[] deps ) to the
> EclipsePlugin#setup() method.
> Regards,
> Cédric
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-139) Eclipse plugin cannot handle Java source files in resource directories
[ http://jira.codehaus.org/browse/MECLIPSE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-139: - Fix Version/s: (was: 2.5) > Eclipse plugin cannot handle Java source files in resource directories > -- > > Key: MECLIPSE-139 > URL: http://jira.codehaus.org/browse/MECLIPSE-139 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Jochen Kuhnle >Assignee: Kenney Westerhof > Attachments: MECLIPSE-139-java-resources.patch, > MECLIPSE-139-java-resources.patch, MECLIPSE-139-java-resources.patch > > > The eclipse plugin cannot handle Java source files in resource directories: > The resulting Eclipse configuration compiles the Java files, so the target > directory contains the class files, but not the java sources. > This is often troublesome in unit tests or when you need to use code > templates, because you often get compile errors in the Workbench. The > attached plugin allows to handle this situation in the following ways: > 1. Default behavior: Work just as the plugin did before > 2. Exclude Java files from resource dirs > 3. Use an Ant builder to copy Java sources > As a sideeffect, the patch also extends the handling of custom builders: > Instead of just specifying a name, you can also specify the triggers and > arguments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-179) Revise dependency configuration for WTP 1.5 EAR projects
[ http://jira.codehaus.org/browse/MECLIPSE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-179: - Fix Version/s: (was: 2.5) > Revise dependency configuration for WTP 1.5 EAR projects > - > > Key: MECLIPSE-179 > URL: http://jira.codehaus.org/browse/MECLIPSE-179 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Reporter: Aleksandr Tarutin >Priority: Critical > > Dependencies for the WTP 1.5 EAR projects are correctly configured into 'J2EE > Module Dependencies'. That includes all of the artifacts from each project > (EJB, WAR, Utility) that the EAR consists of. But that's only part of the > configuration. Next instead of adding the dependencies listed in individual > POMs to each project's classpath these dependencies should be selected on the > same 'J2EE Module Dependencies' configuration for the specific project. Then > they will appear under the 'EAR Libraries' entry in the project explorer. > That way the EAR file built by WTP 1.5 will be much more consistent with the > one built by maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-270) Add support for classpathentry attributes
[ http://jira.codehaus.org/browse/MECLIPSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-270: - Fix Version/s: (was: 2.5) > Add support for classpathentry attributes > - > > Key: MECLIPSE-270 > URL: http://jira.codehaus.org/browse/MECLIPSE-270 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Mike Youngstrom > > With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute > nested inside of the .classpath file's element Like so: > path="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5.jar" > > sourcepath="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5-sources.jar"> > > > > > It would be nice if it were possible to add attributes to classpathentry's > with some kind of configuration syntax where maybe the dependency artifact > and group are specified and then the attributes for that dependency. > Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-228) CLONE -eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-228: - Fix Version/s: (was: 2.5) > CLONE -eclipse:eclipse goal should handle includes and excludes of the > maven-compiler-plugin > > > Key: MECLIPSE-228 > URL: http://jira.codehaus.org/browse/MECLIPSE-228 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Diego Ballve >Assignee: fabrizio giustina > Attachments: includeExclude.patch > > > The maven-compiler-plugin allows a configuration such as: > > maven-compiler-plugin > > > **/idl/*Factory.java > > > > the generated .classpath file currently does not mention the excluded part: > > > which should be: >path="src/main/java"/> >path="target/generated-sources/idl"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-238) Follow rule groupId+artifactId=bundle-name
[ http://jira.codehaus.org/browse/MECLIPSE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-238: - Fix Version/s: (was: 2.5) > Follow rule groupId+artifactId=bundle-name > -- > > Key: MECLIPSE-238 > URL: http://jira.codehaus.org/browse/MECLIPSE-238 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: OSGi >Affects Versions: 2.3 >Reporter: Carlos Sanchez > > make-artifacts and other related goals should follow this rule > eclipse artifacts should be installed with a simpler artifactId, removing the > groupId reference > eg. org.eclipse.swt.core would be > groupId = org.eclipse.swt > artifactId = core > then when used in a flat directory structure like the eclipse plugins dir > they would be downloaded and renamed to groupId+artifactId -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-334) Add a rule that determined artifacts will be always recognized as reactor projects
[ http://jira.codehaus.org/browse/MECLIPSE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-334: - Fix Version/s: (was: 2.5) > Add a rule that determined artifacts will be always recognized as reactor > projects > -- > > Key: MECLIPSE-334 > URL: http://jira.codehaus.org/browse/MECLIPSE-334 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.4 >Reporter: Martin Zeltner > Attachments: patch_maven-eclipse-plugin-r587020.patch > > Original Estimate: 10 minutes > Remaining Estimate: 10 minutes > > I've implemented a feature that determined artifacts will be always > recognized as reactor projects, doesn't matter where the "mvn > eclipse:eclipse" is executed. The idea is to set a list of groupId prefixes. > Example: > [code] > > org.apache.maven.plugins > maven-eclipse-plugin > > > ch.elca., > org.sp, > net.sf > > > > [/code] > All artifacts where the groupId starts with "ch.elca.", "org.sp" or "net.sf" > will be handled as reactor projects. > Cheers, > Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-178) symbolic links need to able to be specified in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-178: - Fix Version/s: (was: 2.5) > symbolic links need to able to be specified in the pom > -- > > Key: MECLIPSE-178 > URL: http://jira.codehaus.org/browse/MECLIPSE-178 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Jim Sellers > > In eclipse, you can make a symbolic link to a file. > create new file -> advanced -> "link to file in the system". > This will create a part in the .project file like this: > > > src/test/resources/oracle-ds.xml > 1 > > C://jboss/server/default/deploy/oracle-ds.xml > > > When you run "mvn eclipse:eclipse" this gets wipped out. It would be great > if this soft link didn't have to be re-created someone runs the command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-171) compile dependencies not used in tests
[ http://jira.codehaus.org/browse/MECLIPSE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-171: - Fix Version/s: (was: 2.5) > compile dependencies not used in tests > -- > > Key: MECLIPSE-171 > URL: http://jira.codehaus.org/browse/MECLIPSE-171 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Win XP, Eclipse 3.2.1 >Reporter: Andre Ranvik > > I had dependencies to other components setup in "compile" scope in the pom > file. I created a test (under src/test/java), which used some of these > dependencies. All well so far. > Now I added a method to a class, which was part of one of the modules I had a > compile dependency on. I then called this method from my test. No problems > within Eclipse finding the new method, since I was using project references. > This means that Eclipse did not complain about the new method at compile > time. BUT - when I ran the test, it gives me a "NoSuchMethodException" on the > newly added method. > When I run the test from command line (mvn test), then it runs fine, without > any problems. > I was able to resolve the problem by changing all dependencies to "test" > scope (instead of "compile"). Everything worked fine then. I tried to change > it back to compile, and now that worked too...! > I then tried adding another method in the same class that caused the problem > - in order to see if there was a pattern here, but that worked too, meaning I > did not have to change the dependencies to "test" to get Eclipse to find the > new method call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-193) The new 'additionalConfig' configuration doesn't create sub-directories
[ http://jira.codehaus.org/browse/MECLIPSE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-193: - Fix Version/s: (was: 2.5) > The new 'additionalConfig' configuration doesn't create sub-directories > --- > > Key: MECLIPSE-193 > URL: http://jira.codehaus.org/browse/MECLIPSE-193 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Maurice Zeijen > > The new configuration option 'additionalConfig' throws an exception when I > set a non existing sub-directory in the 'file' node. It would be better if > the subdirectory would be created if it doesn't exists. > Example: > A lot of eclipse configuration files are written in the '.settings' directory. > > > > .settings/org.eclipse.jdt.core.prefs > > > > > > > The plugin should create the subdirectory '.settings' if it doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-302) resolveVersionRanges crashes on system.bundle
[
http://jira.codehaus.org/browse/MECLIPSE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-302:
-
Fix Version/s: (was: 2.5)
> resolveVersionRanges crashes on system.bundle
> -
>
> Key: MECLIPSE-302
> URL: http://jira.codehaus.org/browse/MECLIPSE-302
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Matthew Beermann
> Attachments: MECLIPSE-302-maven-eclipse-plugin.patch,
> MECLIPSE-302-maven-eclipse-plugin.patch
>
>
> When running eclipse:make-artifacts with -DresolveVersionRanges=true, it dies
> with the following error:
> [INFO] Unable to resolve version range for dependency Dependency
> {groupId=system.bundle, artifactId=system.bundle, version=[0,), type=jar} in
> project org.apache.xml.org.apache.xml.resolver
> It turns out that "system.bundle" is a keyword in OSGi that (broadly
> speaking) refers to the JRE itself, and thus need not/should not be included
> in the POM as a dependency. I've got a patch for this coming up in a moment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-219) Allow file contents to be obtained from url
[ http://jira.codehaus.org/browse/MECLIPSE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-219: - Fix Version/s: (was: 2.5) > Allow file contents to be obtained from url > --- > > Key: MECLIPSE-219 > URL: http://jira.codehaus.org/browse/MECLIPSE-219 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Mike Youngstrom > Attachments: eclipse-219-b.patch, eclipse-219.patch > > > Something like: > > .springBeans http://someurl"/> > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-316) RadCleanMojo does not clean .war files
[ http://jira.codehaus.org/browse/MECLIPSE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-316: - Fix Version/s: (was: 2.5) > RadCleanMojo does not clean .war files > -- > > Key: MECLIPSE-316 > URL: http://jira.codehaus.org/browse/MECLIPSE-316 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support >Affects Versions: 2.4 >Reporter: Siarhei Dudzin > > RadCleanMojo only cleans jars in deleteJarArtifactsInDirectory() while > RadLibCopier also copies .war files in RadLibCopier.copyArtifact( > IdeDependency[] deps, File destDir ). RadCleanMojo also needs to clean .war > files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-235) Eclipse Maven plugin has its own Classpath Container that conflicts with generated class paths when enabled.
[ http://jira.codehaus.org/browse/MECLIPSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-235: - Fix Version/s: (was: 2.5) > Eclipse Maven plugin has its own Classpath Container that conflicts with > generated class paths when enabled. > > > Key: MECLIPSE-235 > URL: http://jira.codehaus.org/browse/MECLIPSE-235 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Environment: Should be OK for ALL >Reporter: Hasan Ceylan > Attachments: eclipseM2Plugin.diff, q4t_patch.txt > > > When we create eclipse projects using the maven-eclipse-plugin, all the class > path entries for the dependent libraries are added to the .classpath. > For those like me who has eclipse maven plugin, enabling maven2 for the > generated project creates duplicate libraries as maven also introduces its > own container based on the information in the pom.xml. > I took the liberty to modify the head, and introduced the > "eclipse.withM2Plugin" parameter. If this parameter is true in the runtime, > 1) In EclipsePlugin.setup() > a) If "org.maven.ide.eclipse.maven2Nature" nature is not added in the > configuration, it is added automatically. > b) If "org.maven.ide.eclipse.maven2Builder" builder is not added in the > configuration, it is added automatically. > c) If "org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER" container is added > automatically. > 2) In config > introduced the method hasMaven2Nature() which indicates if Maven2 nature is > available > 3) M2_REPO's skipped in EclipseClasspathWriter if config returns true for > hasMaven2Nature() > Hope you like the patch... > Regards, > Hasan Ceylan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-152) Write .classpath with ordered dependencies [incl. Patch]
[ http://jira.codehaus.org/browse/MECLIPSE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-152: - Fix Version/s: (was: 2.5) > Write .classpath with ordered dependencies [incl. Patch] > > > Key: MECLIPSE-152 > URL: http://jira.codehaus.org/browse/MECLIPSE-152 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.2 > Environment: Windowz XP, eclipse 3.2 >Reporter: Holger Hoffstätte >Assignee: Kenney Westerhof > Attachments: orderDependencies.patch, orderDependencies.patch > > > Related to my comment in MNG-1412 - I decided to take a quick stab at the > eclipse plugin and voilá! Ordered dependencies in the written .classpath. > This is only a prototype (my first attempt at maven development) and could > serve as basis for other orderings like groupId, transitive nearness etc. > Initially I wanted to make IdeDependency comparable (similar to MECLIPSE-150 > which added proper equals) but having multiple Comparators seemed better for > extensibility. > It worked right away, does exactly what I want (ordering by artifactId) and > has minimal impact. I am not familiar with the maven codebase so I hope this > is the right place to do the actual ordering before writing; obviously it > should observe a property like -DorderDependencies=artifactId or something > similar. The patch is against svn r425750 (2006-08-30). Currently no testcase > but if someone tells me how to add/read an orderDependencies property I might > add one. > Comments welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-249) Generated .classpath file misses exported=true for dependency libraries
[ http://jira.codehaus.org/browse/MECLIPSE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-249: - Fix Version/s: (was: 2.5) > Generated .classpath file misses exported=true for dependency libraries > --- > > Key: MECLIPSE-249 > URL: http://jira.codehaus.org/browse/MECLIPSE-249 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 > Environment: Eclipse 3.2.1 > Win 2000 >Reporter: Jens Baitinger > > When I generate an Eclipse project with maven, the generated .classpath files > looks like this: > >including="plugin.xml|plugin.properties" excluding="**/*.java"/> > > > > > > > But the classes in the libraries are not exported correctly. Only when I > remove those libs from the classpath and readd them via the Plug-in Manifest > Editor, the classes are correctly exported. After that, the classpathentries > lools like this: > > So I think this maven plugin should generate exported="true" into each > library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-214) Non-flat multiproject support (like idea plugin) + docs
[ http://jira.codehaus.org/browse/MECLIPSE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-214: - Fix Version/s: (was: 2.5) > Non-flat multiproject support (like idea plugin) + docs > --- > > Key: MECLIPSE-214 > URL: http://jira.codehaus.org/browse/MECLIPSE-214 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > A parent pom of a non-flat multiproject should be editable in Eclipse. > It's possible, but it involves some tricks: > Eclipse 3.2.1 > With svn at least Subversive 1.1.x (RC4 currently) - Subclipse didn't work, > older versions of Subversive either. > Preferences/Team/SVN: For Subversive select SVNKit as provider. > Here's what maven can do (because it works manually): > - Create a simple project (!= not a java project) of the multiproject > directory. > - Mark all folders which are modules under that simple project as Derrived > (right click/Info). > - Create the module projects as they are created now. > Note: If the simple project exists, its impractical to import the module > projects in Eclipse: either you select each module folder as root during > "import existing project" or you move the simple project for a moment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-218) Mike "File" more inheritable
[ http://jira.codehaus.org/browse/MECLIPSE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-218: - Fix Version/s: (was: 2.5) > Mike "File" more inheritable > > > Key: MECLIPSE-218 > URL: http://jira.codehaus.org/browse/MECLIPSE-218 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Mike Youngstrom > > Make it so that can be inherited. So in a parent pom a file named > .pmd may be defined and the child may define .springBeans > make it so that both the .pmd and .springBeans files are created when > eclipse:eclipse is run on the child's 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: (MECLIPSE-230) Classpath entries to be marked exported
[ http://jira.codehaus.org/browse/MECLIPSE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-230: - Fix Version/s: (was: 2.5) > Classpath entries to be marked exported > --- > > Key: MECLIPSE-230 > URL: http://jira.codehaus.org/browse/MECLIPSE-230 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.1 >Reporter: Vlad Skarzhevskyy >Assignee: fabrizio giustina > > Generated .classpath entries of kind "var" need to be marked exported by > default so that referenced projects have visibility to them. Or provide an > option to specifiy that that entries should be exported. > Example: path="M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar"/> > should me made... > path="M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.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: (MECLIPSE-146) Make the report of missing sources optional
[ http://jira.codehaus.org/browse/MECLIPSE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-146: - Fix Version/s: (was: 2.5) > Make the report of missing sources optional > --- > > Key: MECLIPSE-146 > URL: http://jira.codehaus.org/browse/MECLIPSE-146 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: dependency resolution >Affects Versions: 2.0, 2.1, 2.2 > Environment: maven2 on windows, mac or linux >Reporter: Steve Dodge >Priority: Minor > > Add a settable parameter to ensure the reportMissingSources() method can be > included optionally. The long printout of missing source files can be > distracting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-256) [PATCH]Flat Maven2 Multiproject Structures and Classpath Resolution as Projects (not binaries)
[
http://jira.codehaus.org/browse/MECLIPSE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-256:
-
Fix Version/s: (was: 2.5)
> [PATCH]Flat Maven2 Multiproject Structures and Classpath Resolution as
> Projects (not binaries)
> ---
>
> Key: MECLIPSE-256
> URL: http://jira.codehaus.org/browse/MECLIPSE-256
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: dependency resolution, multiproject
>Affects Versions: 2.3
>Reporter: Kevin Ross
>
> In a project structure where 'root' projects are flat/siblings with child
> projects or modules, we need to resolve actual projects on the local system
> as eclipse project dependencies for ease of debugging, hot deployment etc.
> The following code is a hack, perhaps should be an option to be turned
> on/off, but PLEASE include it. It is certainly doubtful to hurt...
> In AbstractIdeSupportMojo.doDependencyResolution() towards the end of the
> method and before the instantiation of the IdeDependency object please:
> <<<>>>
> if (new File( project.getBasedir(), "../" +
> artifact.getArtifactId() ).exists()) {
> getLog().info( "Adding project dependency: "
> + artifact.getArtifactId() );
> isReferencedProject = true;
> }
> <<<>>>
> // for reference:
> IdeDependency dep = new IdeDependency(
> artifact.getGroupId(), artifact.getArtifactId(), artifact.getVersion(),
> isReferencedProject, Artifact.SCOPE_TEST.equals( artifact.getScope() ),
> Artifact.SCOPE_SYSTEM.equals( artifact.getScope() ),
> Artifact.SCOPE_PROVIDED.equals( artifact.getScope() ),
> artifact.getArtifactHandler().isAddedToClasspath(), artifact
> .getFile(), artifact.getType(),
> isOsgiBundle, osgiSymbolicName, dependencyDepth );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-185) mvn eclipse:eclipse report 'Build Successful' even when generation fails
[ http://jira.codehaus.org/browse/MECLIPSE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-185: - Fix Version/s: (was: 2.5) > mvn eclipse:eclipse report 'Build Successful' even when generation fails > > > Key: MECLIPSE-185 > URL: http://jira.codehaus.org/browse/MECLIPSE-185 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Hans Dockter >Assignee: Brian Fox > > When I start mvn eclipse:eclipse and for example some dependencies can't be > downloaded. Then the plugin still reports at the end Build successful, > although no new .classpath file was generated. Now ypu have to always verify > the content of the output, to see if it was really successful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-300) Regression!!!! project references of wtp project are not automatically set as J2EE Module Dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-300: - Fix Version/s: (was: 2.5) > Regression project references of wtp project are not automatically set as > J2EE Module Dependencies > -- > > Key: MECLIPSE-300 > URL: http://jira.codehaus.org/browse/MECLIPSE-300 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.4 >Reporter: Mike Youngstrom > > It used to be that if I had a multi module project my web project would > automatically have the dependencies automatically checked in the J2EE Module > Dependencies dialog in the project properties. With the upgrade to 2.4 these > module dependencies are no longer automatically checked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-336) Adding runtime facets and additional classpath containers depending on the artifact packaging
[
http://jira.codehaus.org/browse/MECLIPSE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-336:
-
Fix Version/s: (was: 2.5)
> Adding runtime facets and additional classpath containers depending on the
> artifact packaging
> -
>
> Key: MECLIPSE-336
> URL: http://jira.codehaus.org/browse/MECLIPSE-336
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: WTP support
>Affects Versions: 2.4
>Reporter: Martin Zeltner
> Attachments: patch_maven-eclipse-plugin-r587020-2.patch
>
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> If extended the plugin so it is possible to add runtime facets and classpath
> containers depending on the artifact packaging. So it is possible to
> configure the eclipse plugin in "root pom" but with different behaviour for
> jar, war, ejb and ear artifacts. Else it is necessary to i.e. set the same
> classpath containers for each war project. Example:
> [code]
>
> org.apache.maven.plugins
> maven-eclipse-plugin
>
>
> ${jee-web.context}
>
>
> ${tomcat5x.eclipse.runtime.facet.name}
>
>
>
> org.eclipse.jst.server.core.container/org.eclipse.jst.server.tomcat.runtimeTarget/${tomcat5x.eclipse.runtime.facet.name}
>
> org.eclipse.jst.j2ee.internal.web.container
>
> org.eclipse.jst.j2ee.internal.module.container
>
>
>
> [/code]
> Cheers,
> Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112416 ] Arnaud Heritier commented on MECLIPSE-333: -- Richard, I cannot apply patchs 2 & 3 because it doesn't seems that they are unified diff. With which command line can I apply them ? > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112415 ] Arnaud Heritier commented on MECLIPSE-333: -- Richard, a remark : It seems that you reformatted some files which create a noise in patchs for nothing. Our code style conventions are explained here : http://maven.apache.org/guides/development/guide-m2-development.html#Maven_Code_Style > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MECLIPSE-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MECLIPSE-333 started by Arnaud Heritier. > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Arnaud Heritier > Attachments: maven-eclipse-plugin_only_new.tar.gz, > maven-eclipse-plugin_only_new_2.tar.tgz, > wtp-2.0-and-more-2.5-SNAPSHOT-2.patch, wtp-2.0-and-more-2.5-SNAPSHOT-3.patch, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112412 ] Henri Tremblay commented on MNG-3268: - No. I know I can do -Pmain,test. What I need is two -P. One is directly in the batch file and one is passed by the user calling the batch file. The ones in the batch are the default for the script and the one added by the user are specific to a given batch call. For example, I want to deploy on an application server. The deploy.bat contains a -Pdeploy to tell mvn it should deploy during the build. Then the user pass a -Pdev to tell that he wants to deploy on the dev platform. That is not currently possible. And I don't want him to have to modify his settings.xml all the time. > Command line doesn't handle multiple -P correctly > - > > Key: MNG-3268 > URL: http://jira.codehaus.org/browse/MNG-3268 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Henri Tremblay > > It is currently not possible to have more than one -P on the same command > line. Only the first specified profile is considered. > So if you do > mvn -Pmain -Ptest > only the main profile will be taken into account. > This may sound enough but it's not when your maven call is wrapped into a > batch file. Let's say you have a batch doing the compilation of a given > module: > a.bat > - > mvn install -Pmymodule %* > - > and you want to pass a special integration tests profile you would do: > a.bat -Pintegration-tests > But that won't work since you are not allowed to have two -P. > To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1542) Surefire Report in continuum contains excess/superfluous test methods.
Surefire Report in continuum contains excess/superfluous test methods. -- Key: CONTINUUM-1542 URL: http://jira.codehaus.org/browse/CONTINUUM-1542 Project: Continuum Issue Type: Bug Components: Testing Reporter: Joakim Erdfelt When looking at the surefire test results within a continuum build that reported a failure, the list of test methods for the tested class contains extra methods from other tested classes. Continuum on maven.zones.apache.org [surefire report example with problem|http://maven.zones.apache.org/continuum/surefireReport.action;jsessionid=10vfs6g7jbl9f?buildId=32827&projectId=296#org.apache.maven.archiva.web.repository.RepositoryServletProxiedReleasePolicyTest] If you look at the list of test methods for RepositoryServletProxiedReleasePolicyTest you can see that the report shows the correct # of tests at the top with 15, but when you goto the details for that test, you see well over 15 tests. In fact, when you look at the section that starts with "Test Cases" you can see that the list of tests for each Test class is actually the list of tests from the previous Test class + the tests for the current Test class. Example: +RepositoryServletNoProxyMetadataTest+ (/) testGetVersionMetadataDefaultLayout (/) testGetProjectMetadataDefaultLayout (/) testGetSnapshotVersionMetadataDefaultLayout +ArchivaMimeTypeLoaderTest+ (/) -testGetVersionMetadataDefaultLayout- (/) -testGetProjectMetadataDefaultLayout- (/) -testGetSnapshotVersionMetadataDefaultLayout- (/) testArchivaTypes +RepositoryServletProxiedPluginSnapshotPolicyTest+ (/) -testGetVersionMetadataDefaultLayout- (/) -testGetProjectMetadataDefaultLayout- (/) -testGetSnapshotVersionMetadataDefaultLayout- (/) -testArchivaTypes- (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedNewer (/) testGetProxiedSnapshotsArtifactPolicyAlwaysManagedOlder (/) testGetProxiedSnapshotsArtifactPolicyAlwaysNoManagedContent (/) testGetProxiedSnapshotsArtifactPolicyDailyFail ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112401 ] Olivier Lamy commented on MNG-3268: --- Do you want to activate more than one profile ? If yes, look at mvn -h and you can close the issue : ... -P,--activate-profilesComma-delimited list of profiles to activate ... > Command line doesn't handle multiple -P correctly > - > > Key: MNG-3268 > URL: http://jira.codehaus.org/browse/MNG-3268 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Henri Tremblay > > It is currently not possible to have more than one -P on the same command > line. Only the first specified profile is considered. > So if you do > mvn -Pmain -Ptest > only the main profile will be taken into account. > This may sound enough but it's not when your maven call is wrapped into a > batch file. Let's say you have a batch doing the compilation of a given > module: > a.bat > - > mvn install -Pmymodule %* > - > and you want to pass a special integration tests profile you would do: > a.bat -Pintegration-tests > But that won't work since you are not allowed to have two -P. > To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVENUPLOAD-1791) Adding the Validator.nu HTML Parser to Maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Hubick updated MAVENUPLOAD-1791: -- Attachment: icu4j-3.8.pom As per the comment in the pom.xml, icu 3.8 isn't yet in the Maven repo, only the older 3.4.4. I generated the attached updated pom for it via: wget http://ibiblio.org/pub/packages/maven2/com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.pom cat icu4j-3.4.4.pom | sed 's/3.4.4/3.8/g' > icu4j-3.8.pom You can grab the newer jar file at: http://download.icu-project.org/files/icu4j/3.8/icu4j-3_8.jar If someone could also update this, that would be swell! Thanks! :) > Adding the Validator.nu HTML Parser to Maven repo > - > > Key: MAVENUPLOAD-1791 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1791 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Henri Sivonen > Attachments: icu4j-3.8.pom > > > The Validator.nu HTML Parser is an implementation of the HTML5 parsing > algorithm (draft). > Note: > Following the instructions did not cause Maven to put the Javadoc jar inside > the bundle. The Javadoc jar is at: > http://about.validator.nu/htmlparser/htmlparser-1.0.5-javadoc.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112394 ] Paul King commented on MEV-549: --- It would be nice to copy: http://dist.codehaus.org/groovy/poms/groovy-1.0.pom to: http://repo1.maven.org/maven2/groovy/groovy/1.0/groovy-1.0.pom This would make the groovy pom not rely on 'snapshot' artifacts. It just does the excludes around the '-pre' version of castor and includes a non-pre version. But since MEV-553 has been fixed, this is no longer critical. Also, back to the thing which triggered this whole rollercoaster ride, the groovy-all-1.0.pom is still missing. I guess we either get the repo 1 sync thing happening, or manually copy: http://dist.codehaus.org/groovy/poms/groovy-all-1.0.pom to: http://repo1.maven.org/maven2/groovy/groovy-all/1.0/ should also fix the problem. > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King >Assignee: Carlos Sanchez > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-554) POM for joda-time-hibernate 1.0 is invalid
[ http://jira.codehaus.org/browse/MEV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112393 ] Sergey Koshcheyev commented on MEV-554: --- Exactly the same things that were wrong with the 0.8 pom (why didn't the changes made in MEV-302 make it to 1.0?). It declares Hibernate's dependencies as its own, and the jta:jta dependency doesn't have a version specified causing Maven to complain. > POM for joda-time-hibernate 1.0 is invalid > -- > > Key: MEV-554 > URL: http://jira.codehaus.org/browse/MEV-554 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies, Invalid POM >Reporter: Sergey Koshcheyev > > The POM for joda-time-hibernate 1.0 release uploaded in MAVENUPLOAD-1753 is > invalid. Can it be fixed in the same way as the one for 0.8 (MEV-302)? 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] Closed: (MAVENUPLOAD-1789) Upload script for "com.cedarsoft"
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1789. --- Assignee: Carlos Sanchez Resolution: Fixed Added, and the slash at the end is there for a reason > Upload script for "com.cedarsoft" > - > > Key: MAVENUPLOAD-1789 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1789 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Johannes Schneider >Assignee: Carlos Sanchez > > #!/bin/sh > CONTACT="[EMAIL PROTECTED]" > MODE=rsync_ssh > [EMAIL PROTECTED]:/home/maven/public/release > GROUP_DIR=com/cedarsoft > This is the same server as for "eu.cedarsoft" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1788) Maven archetype for flex 2.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1788. --- Assignee: Carlos Sanchez Resolution: Fixed > Maven archetype for flex 2.0 > > > Key: MAVENUPLOAD-1788 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1788 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Jacob von Eyben >Assignee: Carlos Sanchez > > A maven archetype for flex 2.0 development. (the Adobe UI platform) > A quickstarter for flex development using the javaplatform. > - > Proving groupId ownership: The bundle can be downloaded from the domain. > I am owner of domain jacobve.dk > Currently I am the only developer, but haven't created a project site yet - > see my name as projectowner as prove. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1731) ACEGI-JSF Component Library
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1731. --- Resolution: Fixed > ACEGI-JSF Component Library > --- > > Key: MAVENUPLOAD-1731 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1731 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Cagatay Civici >Assignee: Carlos Sanchez > > ACEGI-JSF Integration library contains the reimplementation of ACEGI's JSP > tags as JSF components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1790) jline 0.9.92
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112390 ] Carlos Sanchez commented on MAVENUPLOAD-1790: - you need to remove the pluginRepositories section > jline 0.9.92 > > > Key: MAVENUPLOAD-1790 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1790 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Prud'hommeaux > > JLine is a popular Java library for handling console input. It is similar in > functionality to BSD editline and GNU readline. People familiar with the > readline/editline capabilities for modern shells (such as bash and tcsh) will > find most of the command editing features of JLine to be familiar. > See also: http://jira.codehaus.org/browse/MAVENUPLOAD-1003 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-87) Poms are written with wrong encodings
[ http://jira.codehaus.org/browse/MRELEASE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112389 ] Herve Boutemy commented on MRELEASE-87: --- everything should be fixed in r591123 but I didn't find your test (testWritePom in PrepareReleaseMojoTest) to check it I think I'll write 2 sets of POM files: - src/test/resources/rewrite-for-development/basic-pom-with-encoding - src/test/resources/rewrite-for-release/basic-pom-with-encoding like basic-pom ones, but with poms in UTF-16: I guarantee it will fail if encoding isn't properly handled somewhere :) but I need some time to understand the coding part of the tests any idea on other useful tests? > Poms are written with wrong encodings > - > > Key: MRELEASE-87 > URL: http://jira.codehaus.org/browse/MRELEASE-87 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Carlos Sanchez >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.0-beta-8 > > Attachments: MRELEASE-87-bis.diff, MRELEASE-87.diff > > > I have committed a test that works in my Sun and IBM JDKs under windows but > breaks in the Continuum at codehaus. > Tomorrow i'll try with IBM JDK under linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1791) Adding the Validator.nu HTML Parser to Maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112388 ] Carlos Sanchez commented on MAVENUPLOAD-1791: - you will need to put the javadoc by hand in the bundle jar all the dependencies must be in the repo already > Adding the Validator.nu HTML Parser to Maven repo > - > > Key: MAVENUPLOAD-1791 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1791 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Henri Sivonen > > The Validator.nu HTML Parser is an implementation of the HTML5 parsing > algorithm (draft). > Note: > Following the instructions did not cause Maven to put the Javadoc jar inside > the bundle. The Javadoc jar is at: > http://about.validator.nu/htmlparser/htmlparser-1.0.5-javadoc.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112387 ] Brian Fox commented on MNG-3259: Its not as scary as you think. It seems to be related to the fact that you are excluding the same artifacts in some places, but want them in test scope in others. I think this is a rare occurance. You should be able to just add the ones you want as test scope. I'll try to look some more, but if it's not an easy fix then we have to bump it. The chances of it breaking other behavior is probably greater. Also, this isn't a windows only issue, i have reproduced it on solaris. For me it only happens on jdk 1.5 or less. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-554) POM for joda-time-hibernate 1.0 is invalid
[ http://jira.codehaus.org/browse/MEV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112386 ] Carlos Sanchez commented on MEV-554: what's wrong with it? we don't change poms anymore unless they are clearly unusable > POM for joda-time-hibernate 1.0 is invalid > -- > > Key: MEV-554 > URL: http://jira.codehaus.org/browse/MEV-554 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies, Invalid POM >Reporter: Sergey Koshcheyev > > The POM for joda-time-hibernate 1.0 release uploaded in MAVENUPLOAD-1753 is > invalid. Can it be fixed in the same way as the one for 0.8 (MEV-302)? 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] Commented: (MEV-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112385 ] Carlos Sanchez commented on MEV-549: fixed http://repo1.maven.org/maven2/groovy/groovy/1.1-beta-2/groovy-1.1-beta-2.pom and http://repo1.maven.org/maven2/groovy/groovy-all-minimal/1.1-beta-2/groovy-all-minimal-1.1-beta-2.pom anything else? > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King >Assignee: Carlos Sanchez > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MECLIPSE-335) Nested compile source roots in effective POM cause bad Eclipse build path
[
http://jira.codehaus.org/browse/MECLIPSE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MECLIPSE-335:
---
Attachment: nested-source-roots.patch
After a look at the source code of MavenProject, I discovered that it actually
contains some logic to avoid multiple additions of the same source root. This
encouraged me to extend its logic to ignore nested source roots as well, see
the attached patch.
Assume a POM with a single compile source root of "src/main/java". The patch
intents to realize the following behavior, each time considering the original
POM named before:
- adding "src/main/java" should be ignored (like is now)
- adding "src/main/java/org/apache/maven" should be ignored
- adding "src/main" should discard "src/main/java" as a source root but use
"src/main" instead
I could not think of a practical use-case that would trigger the third case but
I wanted to guarantee the invariant that no nested source roots exists,
regardless of their order of addition.
The unit test MavenProjectTest is also extended to capture the new behavior.
> Nested compile source roots in effective POM cause bad Eclipse build path
> -
>
> Key: MECLIPSE-335
> URL: http://jira.codehaus.org/browse/MECLIPSE-335
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Attachments: nested-source-roots.patch, nested-sources.zip
>
>
> Source generating plugins like for JavaCC or JFlex usually add their output
> folder to the POM as a compile source root. If these source directories
> happen to be nested, i.e. "src/main/java" and additional something like
> "src/main/java/org/apache", mvn eclipse:eclipse produces the following bad
> .classpath contents with overlapping build paths:{code:xml}
>
>
>
> ...
>
> {code}
> While this issues relates to MECLIPSE-114, I really think my problem is
> caused by Maven.
> Though the maven-eclipse-plugin causes the problem to manifest itself, it
> might not be the proper place to solve it as it appears to be a more general
> issue (i.e. the Maven Eclipse Integration might also be affected, though I
> did not test this). Surely, each and every plugin developer could be told to
> check for source directory nesting but I consider this an error-prone
> approach. I would rather appreciate either that
> MavenProject.addCompileSourceRoot() automatically ignores nested source
> directories (if such a general change is acceptable) or that new methods in
> MavenProject are introduced that allow for conditional addition of source
> roots only if they do not nest with existing roots such that plugin
> developers can easily fix the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112380 ] Asgeir S. Nilsen commented on MNG-3259: --- If it appears only on Windows -- could it be related to Windows' weird case-insensitive, but case-preserving file naming? I would guess that the strings c:\Windows and C:\WINDOWS have different hashcodes (and thus ordering could change), but are considered equal by the file system. Furthermore, the backslash \ vs forward slash / in file system paths could also cause equivalent paths to be treated different in a HashMap. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-248) version was null for junit:junit
[
http://jira.codehaus.org/browse/MASSEMBLY-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112379
]
Danilo Eiji Seki commented on MASSEMBLY-248:
Another piece of information:
This is the correction (project POM):
{code:xml}
junit
junit
4.4
{code}
Also, the same situation ocurrs with a log4j runtime dependency, but in this
case there is no error.
> version was null for junit:junit
>
>
> Key: MASSEMBLY-248
> URL: http://jira.codehaus.org/browse/MASSEMBLY-248
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Danilo Eiji Seki
>
> Another report for MASSEMBLY-214, but I will try to be more specific.
> The stack trace is the same (included below just for easy reference), but
> this is the project configuration:
> - Grand parent project with a dependency *management* to junit:junit:4.4 with
> scope test.
> {panel}
> [INFO] [assembly:attached {execution: make-assembly}]
> [INFO] Processing DependencySet (output=null)
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] version was null for junit:junit
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException: version was null for junit:junit
> at
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364)
> at
> org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
> at
> org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
> at
> org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:82)
> at
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:155)
> at
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:100)
> at
> org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90)
> at
> org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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:597)
> 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)
> {panel}
> - Grand parent project with plugin *management* configuring the assembly
> plugin:
> {code:xml}
>
> maven-assembly-plugin
>
> src/assembly
>
>
>
> make-assembly
> package
>
> attached
>
>
>
>
> {code}
> - Project POM references the junit dependency and assembly plug
[jira] Created: (MASSEMBLY-248) version was null for junit:junit
version was null for junit:junit
Key: MASSEMBLY-248
URL: http://jira.codehaus.org/browse/MASSEMBLY-248
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Danilo Eiji Seki
Another report for MASSEMBLY-214, but I will try to be more specific.
The stack trace is the same (included below just for easy reference), but this
is the project configuration:
- Grand parent project with a dependency *management* to junit:junit:4.4 with
scope test.
{panel}
[INFO] [assembly:attached {execution: make-assembly}]
[INFO] Processing DependencySet (output=null)
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] version was null for junit:junit
[INFO]
[INFO] Trace
java.lang.NullPointerException: version was null for junit:junit
at
org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364)
at
org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
at
org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142)
at
org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:82)
at
org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:155)
at
org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:100)
at
org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90)
at
org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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:597)
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)
{panel}
- Grand parent project with plugin *management* configuring the assembly plugin:
{code:xml}
maven-assembly-plugin
src/assembly
make-assembly
package
attached
{code}
- Project POM references the junit dependency and assembly plugin:
{code:xml}
junit
junit
4.4
maven-assembly-plugin
{code}
By grand parent project I mean that the modules has a parent and the parent
project also has a parent, but just the direct parent lists the project as
module.
I "resolved" this by specifing the junit dependecy version for 4.4, but that is
not quite right.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/soft
[jira] Commented: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112378 ] Joerg Schaible commented on MNG-3259: - Oh, please don't. I already reported the problem as regression for 2.0.7, but was not able to find a test case to reproduce the effect: http://mail-archives.apache.org/mod_mbox/maven-dev/200706.mbox/. I follow all the issues about dependency problems quite close and I really thought that the causing issue has been fixed - unless I tried the new RC. And, no, we're stuck to 2.0.5, because we don't have a workaround. As said, if we add the missing artifact directly with scope test, the test fails with another missing class. IMHO it is quite scary, that Maven drops dependencies under some circumstances. And staying with M205 starts to be a real pain, since quite some new versions of plugins require now newer versions. I can also confirm Asgeir's comment, the build does not fail for me on Linux, so it seems to be bound to a Windows installation - for whatever weird reason, but see also: MNG-2962 MNG-3061 At least the natural order should not make any difference, then we would have a chance of sorting the deps accordingly. Can you simply replace the usage of the involved ordinary HashMaps with LinkedHashMaps? > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3268) Command line doesn't handle multiple -P correctly
Command line doesn't handle multiple -P correctly - Key: MNG-3268 URL: http://jira.codehaus.org/browse/MNG-3268 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.7 Reporter: Henri Tremblay It is currently not possible to have more than one -P on the same command line. Only the first specified profile is considered. So if you do mvn -Pmain -Ptest only the main profile will be taken into account. This may sound enough but it's not when your maven call is wrapped into a batch file. Let's say you have a batch doing the compilation of a given module: a.bat - mvn install -Pmymodule %* - and you want to pass a special integration tests profile you would do: a.bat -Pintegration-tests But that won't work since you are not allowed to have two -P. To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGELOG-78) Descending date order
[ http://jira.codehaus.org/browse/MCHANGELOG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Jones updated MCHANGELOG-78: Attachment: changelog.html I've attached the html for a change log report, the first entry is: Changes between 2006-07-18 and 2007-09-20 and the second: Changes between 2007-09-20 and 2007-10-31 And the definition in the pom is: org.apache.maven.plugins maven-changelog-plugin date 2006-07-18 2007-09-20 2007-10-31 -MM-dd The dates correspond to the project release dates. > Descending date order > - > > Key: MCHANGELOG-78 > URL: http://jira.codehaus.org/browse/MCHANGELOG-78 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Reporter: Cameron Jones >Priority: Minor > Attachments: changelog.html > > > The reports generated are ordered in ascending order whereas the entries in > each report are descending. It's a bit confusing, i'd like to see it all > descending so you always have the most recent changes at the top. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1791) Adding the Validator.nu HTML Parser to Maven repo
Adding the Validator.nu HTML Parser to Maven repo - Key: MAVENUPLOAD-1791 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1791 Project: maven-upload-requests Issue Type: Improvement Reporter: Henri Sivonen The Validator.nu HTML Parser is an implementation of the HTML5 parsing algorithm (draft). Note: Following the instructions did not cause Maven to put the Javadoc jar inside the bundle. The Javadoc jar is at: http://about.validator.nu/htmlparser/htmlparser-1.0.5-javadoc.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-20) add bootclasspath support to forked java compiler
[ http://jira.codehaus.org/browse/MCOMPILER-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112355 ] Benjamin Bentmann commented on MCOMPILER-20: bq. Therefore I would suggest to configure the bootclasspath not only for the compiler, but on a higher level so plugins on other life cycle phases can take this configuration as a reference. The maven-javadoc-plugin is a further example of a plugin that would need to use the boot class path (using javadoc's -bootclasspath option), so Frank's suggestion is really reasonable. To give some inspiration for an implementation, I could imagine to introduce a further artifact scope like "bootstrap" and a method MavenProject.getBootstrapClasspathElements() that would allow plugins to get those artifact paths. The tricky task would be to properly define the semantics for this new scope in regard to the other scopes and transitive dependency resolution. I guess the existing scope "provided" is the most similar to "bootstrap": - only use bootstrap entries for compilation, not for runtime or test (e.g. compile against JSE 1.3 but test using JSE 1.5) - never include boostrap entries during transitive dependency resolution - never package bootstrap entries into WARs or similar assemblies The whole difference between "provided" and "bootstrap" would be that plugins can access those dependency sets independently such that they can be fed into SDK tools using separate command line options (i.e. -bootclasspath vs. -classpath). > add bootclasspath support to forked java compiler > - > > Key: MCOMPILER-20 > URL: http://jira.codehaus.org/browse/MCOMPILER-20 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter > > this can be required to override the DOM library used, f.e. > M1 supports arbitrary paths, and an extdirs for the same thing. Perhaps we > have add extdirs for the paths, and select dependencies for the > bootclasspath, ie: > > > xerces:xerces > > > ... > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112353 ] Brian Fox commented on MNG-3259: There is definately an issue. I think though that there are plenty of workarounds and this is a far edge case. I think the best thing is to bump this to 2.0.9 because any fix we make is likely to break something and we should have plenty of time to flush it out. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-66) add XML encoding support for POM reading/writing
[ http://jira.codehaus.org/browse/MDEPLOY-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MDEPLOY-66. Resolution: Fixed fixed in r591045 like for install plugin, encoding problems appear only on deploy:deploy-file task (with pomFile parameter), not deploy:deploy which is AFAIK the most used then "normal" Maven2 users who would use encoding in their pom.xml when swithcing to Maven 2.0.8 won't have any problem even with 2.3 plugin version > add XML encoding support for POM reading/writing > > > Key: MDEPLOY-66 > URL: http://jira.codehaus.org/browse/MDEPLOY-66 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.4 > > > With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is > necessary in this plugin to avoid data corruption when reading and writing > POM files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-574) archiva should not delete the newest snapshot, regardless of age
[ http://jira.codehaus.org/browse/MRM-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-574. Resolution: Duplicate duplicate MRM-556 > archiva should not delete the newest snapshot, regardless of age > > > Key: MRM-574 > URL: http://jira.codehaus.org/browse/MRM-574 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-4 > > > if the newest snapshot for a library is older than the configured number of > days, then even that only viable snapshot getes deleted. I think the days > option should only be used in conjunction with the retention count parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112337
]
srikanth madarapu commented on MDEP-117:
I tried
2.0-alpha-5
and get this error
{panel}
[INFO] Scanning for projects...
[INFO]
[INFO] Building CAPS Main Application for Comp and Perf
[INFO]task-segment: [install]
[INFO]
Downloading:
http://stingray:/repository//org/apache/maven/plugins/maven-dependency-plugin/2.0-alpha-5/maven-dependency-plugin-2.0-alpha-5.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0-alpha-5/maven-dependency-plugin-2.0-alpha-5.pom
Downloading:
http://stingray:/repository//org/apache/maven/plugins/maven-dependency-plugin/2.0-alpha-5/maven-dependency-plugin-2.0-alpha-5.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0-alpha-5/maven-dependency-plugin-2.0-alpha-5.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.maven.plugins:maven-dependency-plugin
Reason: POM 'org.apache.maven.plugins:maven-dependency-plugin' not found in
repository: Unable to download the artifact from any repository
org.apache.maven.plugins:maven-dependency-plugin:pom:2.0-alpha-5
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
internal (http://stingray:/repository/),
Codehaus Snapshots (http://snapshots.repository.codehaus.org/)
for project org.apache.maven.plugins:maven-dependency-plugin
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Nov 01 10:15:24 EDT 2007
[INFO] Final Memory: 3M/6M
[INFO]
{panel}
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1541) NPE with "Provide Release Parameters"
[ http://jira.codehaus.org/browse/CONTINUUM-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1541: Fix Version/s: 1.1 > NPE with "Provide Release Parameters" > - > > Key: CONTINUUM-1541 > URL: http://jira.codehaus.org/browse/CONTINUUM-1541 > Project: Continuum > Issue Type: Bug > Components: Release >Affects Versions: 1.1-beta-4 > Environment: Continuum 1.1.-beta-4 > Ubuntu 7 Server >Reporter: Wendy Smoak > Fix For: 1.1 > > > To reproduce: > 1. Complete 'Prepare for Release' as usual > 2. Choose "Perform project release" > 3. Select "Provide Release Parameters" (rather than selecting the version > number you just prepared) > 4. Fill in the scm credentials and an existing tag, such as 'hello-1.0.3' > 5. Click 'Done' > It should work, but instead you get a NPE: > Error Occurred > java.lang.NullPointerException > Show/hide Stack Trace > java.lang.NullPointerException > at java.util.Hashtable.get(Hashtable.java:336) > at > org.apache.maven.continuum.web.action.ReleaseInProgressAction.execute(ReleaseInProgressAction.java:63) > 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 > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192) > at > org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundIntercep
[jira] Updated: (CONTINUUM-1472) No navigation on Project Release Summary page
[ http://jira.codehaus.org/browse/CONTINUUM-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1472: Fix Version/s: 1.1 > No navigation on Project Release Summary page > - > > Key: CONTINUUM-1472 > URL: http://jira.codehaus.org/browse/CONTINUUM-1472 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Maria Catherine Tan >Priority: Minor > Fix For: 1.1 > > > If you click 'View Output' after Prepare for Release finishes, the only way > to get back from the Project Release Summary page is to use the browser back > button. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-117) includeClassifiers does not work
[
http://jira.codehaus.org/browse/MDEP-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112335
]
srikanth madarapu commented on MDEP-117:
How do i mention the version, i tried the following two versions and resulted
in "Unable to download the artifact from any repository" error.
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
*2.0-alpha-5-SNAPSHOT* also tried
*alpha-5-SNAPSHOT*
unpack-lang-translations
unpack-dependencies
WEB-INF
com.workscape
caps-translations
zip
app
true
{code}
> includeClassifiers does not work
>
>
> Key: MDEP-117
> URL: http://jira.codehaus.org/browse/MDEP-117
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
> Environment: windows xp
>Reporter: srikanth madarapu
>Assignee: Brian Fox
>
> This is same as the issue described in MDEP-43. I have 2.0-alpha-1 and
> 2.0-alpha-04, not sure which one i am using.
> This is how my execution looks like...
>
> unpack-lang-translations
>
> unpack-dependencies
>
>
>
> ${webapp.deploy.dir}/WEB-INF
> com.workscape
>
> caps-translations
> zip
> app
> true
>
>
> I have another zip in that folder with classifier 'flex' but that is getting
> unzipped too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112331 ] Asgeir S. Nilsen commented on MNG-3259: --- I am unable to reproduce the error. Steps: - Used MNG-3259-2.zip - Installed parent pom - Installed multiproject Maven versions: 2.0.7 and 2.0.8-SNAPSHOT OS name: "sunos" version: "5.10" arch: "x86" Family: "unix" Java versions: Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Expected result: - Multiproject build should fail Actual result: - Multiproject build passes. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-44) add XML encoding support for POM reading/writing
[ http://jira.codehaus.org/browse/MINSTALL-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112328 ] Herve Boutemy commented on MINSTALL-44: --- to be precise, encoding problems appear only on install:file task, not install:install which is AFAIK the most used then "normal" Maven2 users who would use encoding in their pom.xml when swithcing to Maven 2.0.8 won't have any problem even with 2.2 plugin version > add XML encoding support for POM reading/writing > > > Key: MINSTALL-44 > URL: http://jira.codehaus.org/browse/MINSTALL-44 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.3 > > > With MNG-2254 being fixed in Maven 2.0.8, same XML encoding support is > necessary in this plugin to avoid data corruption when reading and writing > POM files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPLUGIN-58) File Parameter Evaluation
[
http://jira.codehaus.org/browse/MPLUGIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MPLUGIN-58:
-
Attachment: align-to-base-birectory.patch
This patch should fix this:
- pass through absolute paths without any modifications
- have two-arg File() constructor do the path concatenation
> File Parameter Evaluation
> -
>
> Key: MPLUGIN-58
> URL: http://jira.codehaus.org/browse/MPLUGIN-58
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
>Reporter: Vincent Thoulé
> Attachments: align-to-base-birectory.patch
>
>
> I am developping a plugin have as configuration a File.
> In the Test phasis, I encounter some trouble with File Resolution.
> My dependency are :
> - org.apache.maven.shared:maven-plugin-testing-harness:1.1
> In the
> org.codehaus.plexus.component.configurator.converters.basic.FileConverter
> provided by Plexus-container-default-1.0-alpha-9-stable-1.jar,
> The method fromConfiguration() calls
> expressionEvaluator.alignToBaseDirectory( f );
> In case of Test , the expressionEvaluator is
> org.apache.maven.plugin.testing.ResolverExpressionEvaluatorStub.
> The code is as follow :
> public File alignToBaseDirectory( File file )
> {
> if ( file.getAbsolutePath().startsWith( PlexusTestCase.getBasedir() )
> )
> {
> return file;
> }
> else
> {
> return new File( PlexusTestCase.getBasedir() + File.pathSeparator
> + file.getPath() );
> }
> }
> Two Bugs :
> - All path which do not start with TestCase Basedir are assumed as relative
> path based on basedir. Why not, but it not allow to test Absolute path.
> - The concatenation with the Basedir is done with File.pathSeparator ( :
> under UNIX and ; under Windows) instead of File.separator ( / under Unix and
> \ under Windows ).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-60) MavenProjectStub uses immutable collections for modifiable data
MavenProjectStub uses immutable collections for modifiable data
---
Key: MPLUGIN-60
URL: http://jira.codehaus.org/browse/MPLUGIN-60
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP,
maven-testing-harness:1.1
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: immutable-lists.patch
For example, calling MavenProjectStub.addCompileSourceRoot() twice causes the
following stack trace
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:151)
at java.util.AbstractList.add(AbstractList.java:89)
at
org.apache.maven.plugin.testing.stubs.MavenProjectStub.addCompileSourceRoot(MavenProjectStub.java:328)
{code}
This is caused by the usage of Collections.singletonList() in various methods
to initialize modifiable collection members. However, singletonList() returns
an immutable collection as stated in its javadoc.
The attached patch should fix this. Besides, the patch uses eager
initialization for the collections such that getters like
getCompileSourceRoots() return non-null data right from the beginning. This
makes the stub more consistent with the behavior of MavenProject.
Apropos MavenProject: I wonder why many (if not all) methods inherited from
MavenProject are overriden by MavenProjectStub. For instance,
MavenProject.addCompileSourceRoot() already provides (non-trivial) management
of the source root collection. The stub in turn badly overwrites this, making
the tests behave differently than during a real build while apparently not
providing any more features to the unit tests. Likewise I cannot quite
understand why methods like getDependencies() are overwritten with noops while
the MavenProject's implementation nicely delegates to the 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] Created: (MEV-554) POM for joda-time-hibernate 1.0 is invalid
POM for joda-time-hibernate 1.0 is invalid -- Key: MEV-554 URL: http://jira.codehaus.org/browse/MEV-554 Project: Maven Evangelism Issue Type: Bug Components: Dependencies, Invalid POM Reporter: Sergey Koshcheyev The POM for joda-time-hibernate 1.0 release uploaded in MAVENUPLOAD-1753 is invalid. Can it be fixed in the same way as the one for 0.8 (MEV-302)? 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] Commented: (MCHANGELOG-78) Descending date order
[ http://jira.codehaus.org/browse/MCHANGELOG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112322 ] Dennis Lundberg commented on MCHANGELOG-78: --- Not sure that I follow you here... How does your output differ from the report here: http://maven.apache.org/plugins/maven-changelog-plugin/changelog.html Please provide an sample report, either as a screenshot or as an html file. > Descending date order > - > > Key: MCHANGELOG-78 > URL: http://jira.codehaus.org/browse/MCHANGELOG-78 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Reporter: Cameron Jones >Priority: Minor > > The reports generated are ordered in ascending order whereas the entries in > each report are descending. It's a bit confusing, i'd like to see it all > descending so you always have the most recent changes at the top. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112321 ] Paul King commented on MEV-549: --- OK, for the 1.1 milestone releases, the simplest path to correct the errant poms is to ignore the missing ones (beta-1/BETA-1) and just fix the ones which are incorrect. For the groovy artifacts, this is: http://repo1.maven.org/maven2/groovy/groovy/1.1-beta-2/groovy-1.1-beta-2.pom For the groovy-all-minimal artifacts, this is: http://repo1.maven.org/maven2/groovy/groovy-all-minimal/1.1-beta-2/groovy-all-minimal-1.1-beta-2.pom For both these files we need to change the groupId from org.codehaus.groovy to groovy. Thanks. > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King >Assignee: Carlos Sanchez > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
