[continuum build - FAILED - update] Sun Nov 6 08:00:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.080001.txt
[continuum build - FAILED - update] Sun Nov 6 09:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.09.txt
[continuum build - FAILED - update] Sun Nov 6 09:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.093000.txt
[continuum build - FAILED - update] Sun Nov 6 10:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.10.txt
[continuum build - FAILED - update] Sun Nov 6 11:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.113000.txt
[continuum build - FAILED - update] Sun Nov 6 12:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.12.txt
[continuum build - FAILED - update] Sun Nov 6 12:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.123000.txt
[continuum build - FAILED - update] Sun Nov 6 13:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.133000.txt
[continuum build - FAILED - update] Sun Nov 6 14:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.14.txt
[continuum build - FAILED - update] Sun Nov 6 15:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.15.txt
[continuum build - SUCCESS - update] Sun Nov 6 16:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051106.16.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051106.16.txt
[continuum build - SUCCESS - checkout] Mon Nov 7 01:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051107.013001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051107.013001.txt
[jira] Created: (MNG-1435) Test summary only prints out execution time for last test
Test summary only prints out execution time for last test - Key: MNG-1435 URL: http://jira.codehaus.org/browse/MNG-1435 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Reporter: Boris Boehlen The surefire plugin only prints out the execution time used for the last test. The execution time of the previous tests is ignored. E.g. the end of the TEST-foo.xml says: testcase time=0.061 name=testGraphEntityClassSerialization/ testcase time=0.023 name=testAttributeSerialization/ testcase time=0.056 name=testGraphEntitySerialization/ /testsuite And the surefire summary says: [surefire] Running i3.dragos.PsqlAllTests [surefire] Tests run: 157, Failures: 0, Errors: 0, Time elapsed: 0.056 sec Obviously, surefire should print out the total execution time of all tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-740) dependencies resolution not work using pom on local source tree - special case
[ http://jira.codehaus.org/browse/MNG-740?page=comments#action_50128 ] Jeff Jensen commented on MNG-740: - My dir structure is a little less complex, and has the same result. I too have the parent pom not in a dir directly above the other components, but in a dir at the same level as the other components. |--root |--pom.xml |--component1 |--pom.xml |--component2 |--pom.xml |--component3 |--pom.xml The relativePath setting in the parent tags in the components seem to have no effect. I do not receive an error message that the parent was not found either, only [INFO] Failed to resolve artifact. when I have not first executed a mvn install in the root dir. dependencies resolution not work using pom on local source tree - special case -- Key: MNG-740 URL: http://jira.codehaus.org/browse/MNG-740 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-beta-1 Environment: xp Reporter: Dan Tran Fix For: 2.1 Attachments: c.log, jira.zip Folks, I would like to make sure i am able to build my artitfact with it parent poms are not either in local or remote repo. Attached is the dummy m2 structure to repoduce the problem. Here are detail somedir root pom.xml subprojects pom.xml A pom.xml BC-parent B pom.xml--- depend on A C pom.xml --- depends on B Here are the step the reproduce 1. Install root's pom ( m2 install ) 2. Install A ( m2 install in subproejcts/A 3. install B ( m2 install in subprojects/BC-parent/B 4. install C ( m2 install in subprojects/BC-parent/C) C fails here. See attach logs however if I do a full install from subprojects or manually install subproejcts pom and BC-parent pom ( via m2 install -N) the problem goes away -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1436) Unable to load maven-model-2.0-all from a plugin
Unable to load maven-model-2.0-all from a plugin Key: MNG-1436 URL: http://jira.codehaus.org/browse/MNG-1436 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: fabrizio giustina Priority: Critical Fix For: 2.0.1 The org.apache.maven:maven-model artifact is available with the all classifier in the maven repo. The all version also contains project v3 classes and reader/writer. Adding a dependency with: dependency groupIdorg.apache.maven/groupId artifactIdmaven-model/artifactId version2.0/version typejar/type classifierall/classifier /dependency let you use project 3 classes in a plugin and install successfully. However, when running the plugin, the maven-model-2.0-all artifact seems to be ignored and replaced by the version in m2/lib _also if the classifier is different_. This is the debug log from an execution of a plugin that uses this dependency: [INFO] Searching repository for plugin with prefix: 'maven1'. [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] org.apache.maven.plugins:maven-maven1-plugin:maven-plugin:2.0-SNAPSHOT (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0 [DEBUG] org.apache.maven:maven-model:jar:all:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] dom4j:dom4j:jar:1.4 (selected for runtime) [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-maven1-plugin:2.0-SNAPSHOT:convert' -- [DEBUG] (f) basedir = \testconvert [DEBUG] -- end configuration -- [INFO] [1:convert] [WARNING] pom.xml in \testconvert already exists, overwriting [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader [INFO] [DEBUG] Trace java.lang.NoClassDefFoundError: org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader At the moment this makes impossible to use pom v.3 in mvn. Apart from the classifier issue that could be solved in a future m2 release, I would like to find out a workaroud in order to use v3 poms for a mvn plugin that could automatically convert maven 1 project.xml to mvn pom.xml for making migration from maven 1 easier. The current options I can think at are: - embedding the org.apache.maven.model.v3_0_0.* classes in the plugin - releasing maven-model-2.0-all with a different artifactId (maven-model-all-2.0 or maven-model-v3-2.0) thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1 and Maven 2 repositories on codehaus for Cargo
Hi there (and especially Carlos!), I'm planning to add a m2 repository on codehaus for the Cargo project. However I'm wondering how the sync to ibiblio will be done as there's already a m1 repository. More precisely I have the following questions: * Can we activate the sync for the cargo m2 repo so that it is synced with ibiblio? I guess I need to talk to Carlos for this. Carlos? * The m1 repo on codehaus is synced every few hours and thus the artifacts that are put there will find their way to the ibiblio m1 repo and *also* to the ibiblio m2 repo as there's a sync on ibiblio between the m1 and m2 repo. Thus the project.xml will be converted to a pom.xml. Now as the Cargo project will also be publishing to its m2 repo I'm wondering what will happen, especially WRT the pom.xml (the one from the codehaus m2 repo should be over the converted one). How do you deal with this? Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1430) add j2ee project nature/builders to generated .project file
[ http://jira.codehaus.org/browse/MNG-1430?page=all ] Dan Allen updated MNG-1430: --- Attachment: MNG-1430.txt This patch adds the project natures and builders for the WTP 0.71 out of the box (instead of forcing every user to have to add these to the plugin configuration). After all, maven is supposed to be smart about your project and require little to no configuration. Maven adds these natures and builders to the .project file when the packaging is specified to be war. I have also configured the .deployables directory correctly so that eclipse will be able to import the project and deploy it without a single glitch (this includes creating this directory). Finally, I have added a few additional dependency artifactId names that will help to determine the servlet version used in the .wtpmodules file. add j2ee project nature/builders to generated .project file --- Key: MNG-1430 URL: http://jira.codehaus.org/browse/MNG-1430 Project: Maven 2 Type: Improvement Components: maven-eclipse-plugin Versions: 2.0 Environment: maven 2.0 on linux Reporter: Dan Allen Attachments: MNG-1430.txt When the eclipse:eclipse target generates the .project file for a war project in maven, the .project file contains only the natures and builders for a regular java project. The additional information is as follows for WTP 0.71 buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilder/name arguments /arguments /buildCommand buildCommand buildCommand nameorg.eclipse.wst.validation.validationbuilder/name arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.ComponentStructuralBuilderDependen arguments /arguments /buildCommand buildCommand nameorg.eclipse.wst.common.modulecore.DependencyGraphBuilder/name arguments /arguments /buildCommand natureorg.eclipse.jem.workbench.JavaEMFNature/nature natureorg.eclipse.wst.common.modulecore.ModuleCoreNature/nature -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-569) maven taglib plugin 2.0 for m2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-569?page=comments#action_50132 ] fabrizio giustina commented on MAVENUPLOAD-569: --- groupId has been fixed (same bundle url) metadata xml is available here: http://maven-taglib.sourceforge.net/m2repo/net/sourceforge/maven-taglib/ maven taglib plugin 2.0 for m2 -- Key: MAVENUPLOAD-569 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-569 Project: maven-upload-requests Type: Wish Reporter: fabrizio giustina This is the first m2 release of the maven taglib plugin ( http://maven-taglib.sourceforge.net/m2 ) does the upload bundle method work also for m2 plugins? This should end up in the m2 repository only and it will also require the metadata xml... The plugin matrix at http://docs.codehaus.org/display/MAVEN/Maven%20Plugin%20Matrix should also be updated -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_50133 ] Jeff Jensen commented on MNG-624: - On a different use case, with my current understanding, this seems to easily make sense when specifying relativePath. In fact, in that case, it seems one could leave off all three: groupId, artifactId, version, since it simply uses the specified one. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Components: maven-project Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Original Estimate: 4 hours Remaining: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1437) How to make additions to the POM and have it be backward/forward compatible
How to make additions to the POM and have it be backward/forward compatible --- Key: MNG-1437 URL: http://jira.codehaus.org/browse/MNG-1437 Project: Maven 2 Type: Task Components: design Reporter: Jason van Zyl I would like to add categories and site staging information to the POM but don't want to break everything. Brett and I have discussed this topic briefly but we need the XML parsing mechanism to be a bit more flexible or we may just have to embrace namespaces to make this work ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1438) Plugin of plugins (or CompositePlugin)
Plugin of plugins (or CompositePlugin) -- Key: MNG-1438 URL: http://jira.codehaus.org/browse/MNG-1438 Project: Maven 2 Type: New Feature Components: plugin-ideas Reporter: Jason van Zyl Chris, do you think you could pop in your original email? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1439) Organization Object Model (OOM)
Organization Object Model (OOM) Key: MNG-1439 URL: http://jira.codehaus.org/browse/MNG-1439 Project: Maven 2 Type: New Feature Components: design Reporter: Jason van Zyl Would be cool to start capturing organizational information and just use a reference from projects to the OOM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1440) Developer Object Model (DOM)
Developer Object Model (DOM) Key: MNG-1440 URL: http://jira.codehaus.org/browse/MNG-1440 Project: Maven 2 Type: New Feature Components: design Reporter: Jason van Zyl Would be cool to be able to reference a developer by id from any POM and get their full range of information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1441) Starting thinking about a proper distributed repository mechanism a la CPAN
Starting thinking about a proper distributed repository mechanism a la CPAN --- Key: MNG-1441 URL: http://jira.codehaus.org/browse/MNG-1441 Project: Maven 2 Type: New Feature Components: design Reporter: Jason van Zyl We might want to actually contact the folks at CPAN to see if we could learn from them or piggy back upon their setup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1442) Check site for dead links
Check site for dead links - Key: MNG-1442 URL: http://jira.codehaus.org/browse/MNG-1442 Project: Maven 2 Type: New Feature Components: maven-site-plugin Reporter: Jason van Zyl We could use the m1 link checking plugin or we can steal a bit of code from xstream which has some link checking code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1 and Maven 2 repositories on codehaus for Cargo
Jason has a copy of the initial design we've developed for the repository management. He'll be placing it somewhere shortly. You might also like to review any discussions with the Jetty team on the users list. Basically, I'd say: - pick one. Don't deploy to both the m1 and m2 repositories - let the repository manager take care of it (this probably means m2). - we haven't decided if each project should have its own repo or whether there will be a big m2 repository like the original one at codehaus. The latter is probably feasible as long as it can hvae proper permissions and no other deployments unrelated to Maven in there this time. Note that nothing is implemented yet, so we may need to determine an interim solution, but I think it's best to determine the correct solution and work towards this. BTW, Carlos won't be the only one working on this, and I'd really like to see other volunteers to help him out - he's done a lot of work on maintaining the repository on his own, I think he deserves a break :) Cheers, Brett Vincent Massol wrote: Hi there (and especially Carlos!), I'm planning to add a m2 repository on codehaus for the Cargo project. However I'm wondering how the sync to ibiblio will be done as there's already a m1 repository. More precisely I have the following questions: * Can we activate the sync for the cargo m2 repo so that it is synced with ibiblio? I guess I need to talk to Carlos for this. Carlos? * The m1 repo on codehaus is synced every few hours and thus the artifacts that are put there will find their way to the ibiblio m1 repo and *also* to the ibiblio m2 repo as there's a sync on ibiblio between the m1 and m2 repo. Thus the project.xml will be converted to a pom.xml. Now as the Cargo project will also be publishing to its m2 repo I'm wondering what will happen, especially WRT the pom.xml (the one from the codehaus m2 repo should be over the converted one). How do you deal with this? Thanks -Vincent ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] Re: bringing surefire and doxia to Maven
Brett, Carlos, John, Jason, Arnaud, Emmanuel, Vincent S, Fabrizio: +1 Kenney, Vincent M, Trygve: +0 Dave Sag, Eric Pugh both spoke positively but didn't cast a numberical vote. Jason is discussing this with Infrastructure, and I have reviewed the IP clearance template to check everything is ok. Cheers, Brett Brett Porter wrote: Hi, Doxia and Surefire were small projects started at Codehaus to experiment with new technology that has since been used from Maven 2.0. With one recent exception the committer set are entirely Maven committers. Doxia is the underpinnings of the site plugin, and is used to generate documents via a sink using various input formats. Surefire is a test runner, used to run junit tests in Maven. Since the code is our own work, it is easy to bring here, and the development can be more easily worked with alongside the primary uses and discussion can happen in one place. What do others think? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accepting two code bases into the Maven project
Hi, The Maven community has voted to consolidate by bringing two related codebases into the main Maven project. Below are the IP clearance forms for each project. My understanding is that neither need to be incubated on this basis. Please let me know if this is not the case. Project: Surefire Description: Library for running test suites. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/surefire in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file, bar one * Andy Glick was very recently added to work on a branch. He has gone quiet there, we will either get a CLA from him or prune his branch from the import. This will be taken care of before the code arrives at Apache. - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Project: Doxia Description: Simple library for document transformation and site generation. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/doxia in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accepting two code bases into the Maven project
+1 from me. On 11/6/05, Brett Porter [EMAIL PROTECTED] wrote: Hi, The Maven community has voted to consolidate by bringing two related codebases into the main Maven project. Below are the IP clearance forms for each project. My understanding is that neither need to be incubated on this basis. Please let me know if this is not the case. Project: Surefire Description: Library for running test suites. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/surefire in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file, bar one * Andy Glick was very recently added to work on a branch. He has gone quiet there, we will either get a CLA from him or prune his branch from the import. This will be taken care of before the code arrives at Apache. - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Project: Doxia Description: Simple library for document transformation and site generation. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/doxia in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
change jira components to be more user friendly
Hi, I was wondering what folks though of changing maven-artifact, maven-core, etc in JIRA to be user friendly components like: * error reporting * artifact deployment * artifact resolution etc. These often cover more than one physical component anyway and they are more likely to be initially filled in correctly. No need to change plugins as I think the consensus is to eventually move them out into individual jira projects. Thoughts? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accepting two code bases into the Maven project
So I'm confused .. I was under the impression that *all* new code coming into the ASF had to come thru the incubator and go thru incubation? Maybe there's an exception if the code was written by ASF committers under AL v2 but simply done elsewhere? Would appreciate clarification. Sanjiva. On Sun, 2005-11-06 at 18:03 -0500, Davanum Srinivas wrote: +1 from me. On 11/6/05, Brett Porter [EMAIL PROTECTED] wrote: Hi, The Maven community has voted to consolidate by bringing two related codebases into the main Maven project. Below are the IP clearance forms for each project. My understanding is that neither need to be incubated on this basis. Please let me know if this is not the case. Project: Surefire Description: Library for running test suites. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/surefire in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file, bar one * Andy Glick was very recently added to work on a branch. He has gone quiet there, we will either get a CLA from him or prune his branch from the import. This will be taken care of before the code arrives at Apache. - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Project: Doxia Description: Simple library for document transformation and site generation. Project Info: - Maven PMC will be responsible for the codebase - It will be stored under /maven/doxia in SVN - Files have not yet been updated with ASF copyright, that will be done immediately after import - All active committers have a CLA on file - All code is either MIT/X, BSD or ASL - There are no external dependencies on unsuitably licensed code Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Mon Nov 7 00:00:01 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051107.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051107.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1443) should not fail in offline mode if pom doesn't exist
should not fail in offline mode if pom doesn't exist Key: MNG-1443 URL: http://jira.codehaus.org/browse/MNG-1443 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Fix For: 2.0.1 should instead use the default one, like it would if it didn't exist remotely. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - checkout] Mon Nov 7 00:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051107.001500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051107.001500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1354) NPE when plugins throw certain exceptions
[ http://jira.codehaus.org/browse/MNG-1354?page=comments#action_50137 ] Brett Porter commented on MNG-1354: --- ok, it seems I made a mistake on this particular one, not updating the version to 2.0-1. I'll remark it as fixed in 2.0.1. NPE when plugins throw certain exceptions - Key: MNG-1354 URL: http://jira.codehaus.org/browse/MNG-1354 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: Mark Hobson Assignee: Brett Porter Regularly see this, although it's entirely obvious why looking at the source: java.lang.NullPointerException at org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique(DiagnosisUtils.java:89) at org.apache.maven.usability.diagnostics.ErrorDiagnostics$PuntErrorDiagnoser.diagnose(ErrorDiagnostics.java:132) at org.apache.maven.usability.diagnostics.ErrorDiagnostics.diagnose(ErrorDiagnostics.java:104) at org.apache.maven.DefaultMaven.logDiagnostics(DefaultMaven.java:693) at org.apache.maven.DefaultMaven.logFatal(DefaultMaven.java:627) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:143) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Can spend time creating a testcase if it's not immediately obvious. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MNG-1220) NPE in DiagnosisUtils
[ http://jira.codehaus.org/browse/MNG-1220?page=all ] Brett Porter reopened MNG-1220: --- NPE in DiagnosisUtils - Key: MNG-1220 URL: http://jira.codehaus.org/browse/MNG-1220 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0.1 Reporter: fabrizio giustina Assignee: Brett Porter Fix For: 2.0 Attachments: diagnosisUtilsNPE.diff org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique() throws an NPE if the exception message is null [line 89: if ( rootMsg != null error.getMessage().indexOf( rootMsg ) 0 )] The attached patch simply adds the error.getMessage() != null check -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1220) NPE in DiagnosisUtils
[ http://jira.codehaus.org/browse/MNG-1220?page=all ] Brett Porter closed MNG-1220: - Resolution: Fixed Fix Version: (was: 2.0) 2.0.1 NPE in DiagnosisUtils - Key: MNG-1220 URL: http://jira.codehaus.org/browse/MNG-1220 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0.1 Reporter: fabrizio giustina Assignee: Brett Porter Fix For: 2.0.1 Attachments: diagnosisUtilsNPE.diff org.apache.maven.usability.diagnostics.DiagnosisUtils.appendRootCauseIfPresentAndUnique() throws an NPE if the exception message is null [line 89: if ( rootMsg != null error.getMessage().indexOf( rootMsg ) 0 )] The attached patch simply adds the error.getMessage() != null check -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1427) Dependency Scope not documented in the new site
[ http://jira.codehaus.org/browse/MNG-1427?page=comments#action_50138 ] Brett Porter commented on MNG-1427: --- grr. If we are doing a link checker, it would be good to identify orphaned docs also. Dependency Scope not documented in the new site - Key: MNG-1427 URL: http://jira.codehaus.org/browse/MNG-1427 Project: Maven 2 Type: Improvement Components: documentation - guides Reporter: Fabrice BELLINGARD Dependency Scope used to be documented on this page (http://maven.apache.org/maven2/dependency-mechanism.html) but does not exist in the new site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-804) maven.jar.override usage in m2
[ http://jira.codehaus.org/browse/MNG-804?page=comments#action_50140 ] Brett Porter commented on MNG-804: -- there is already a guide on dependency management, but what we really need is a doc that points m1 users at changes. maven.jar.override usage in m2 -- Key: MNG-804 URL: http://jira.codehaus.org/browse/MNG-804 Project: Maven 2 Type: Sub-task Components: documentation - general Reporter: Natalie Burdick Priority: Minor Fix For: 2.0.1 refer to: http://mail-archives.apache.org/mod_mbox/maven-users/200508.mbox/[EMAIL PROTECTED] to document that unlike m1, m2 no longer allow jar overrides via the maven.jar.override property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1303) surefire should include bootclasspath when running tests
[ http://jira.codehaus.org/browse/MNG-1303?page=comments#action_50141 ] Brett Porter commented on MNG-1303: --- this should be done by delegating to the system classloader, rather than including specific jars into the isolated classloader surefire should include bootclasspath when running tests Key: MNG-1303 URL: http://jira.codehaus.org/browse/MNG-1303 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Environment: commons-digester 1.7; JDK 1.5.0_05 Reporter: Boris Boehlen Attachments: my-app.zip I use the common-digester to parse a configuration file. When I do this in a test case I get the following error. javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.SAXParserFactory cannot be found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at org.apache.commons.digester.Digester.getFactory(Digester.java:490) at org.apache.commons.digester.Digester.getParser(Digester.java:693) at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1704) at i3.grasgxl.core.ConfigurationLoader.load(ConfigurationLoader.java:107) Worked properly with Maven 1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1313) maven-surefire-plugin cannot test custom charset providers specified in META-INF/services/java.nio.charset.spi.CharsetProvider
[ http://jira.codehaus.org/browse/MNG-1313?page=all ]
Brett Porter closed MNG-1313:
-
Resolution: Duplicate
I added a note to MNG-1303 to clarify, I still believe these are the same thing.
maven-surefire-plugin cannot test custom charset providers specified in
META-INF/services/java.nio.charset.spi.CharsetProvider
--
Key: MNG-1313
URL: http://jira.codehaus.org/browse/MNG-1313
Project: Maven 2
Type: Bug
Components: maven-surefire-plugin
Versions: 2.0
Environment: All
Reporter: Christian Schulte
Assignee: Brett Porter
Priority: Blocker
maven-surefire-plugin cannot run a jUnit test for a custom charset provider
specified in the jar file's
META-INF/services/java.nio.charset.spi.CharsetProvider file. Class
java.nio.charset.Charset performs a lookup using
ClassLoader.getSystemClassLoader(); which does not have the jar file in its
classpath and thus fails with e.g. junit.framework.AssertionFailedError:
java.io.UnsupportedEncodingException: DIN_66003 although the jar file itself
is correct. I think this is due to the plugin using its own classloader and
the JDK using the system classloader but I may be totally wrong and
everything is fine with the plugin.
The method from java.nio.charset.Charset performing the lookup beings with
private static Iterator providers() {
return new Iterator() {
Class c = java.nio.charset.spi.CharsetProvider.class;
ClassLoader cl = ClassLoader.getSystemClassLoader();
Iterator i = Service.providers(c, cl);
Object next = null;
As it seems org.codehaus.surefire.SurefireBooter does not promote the jar
files to the classpath of the system classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-579) jsch 0.1.23
[ http://jira.codehaus.org/browse/MAVENUPLOAD-579?page=all ] Brett Porter closed MAVENUPLOAD-579: Assign To: Brett Porter Resolution: Fixed note it was already in the m2 repository. Copied to the m1 repository. The group ID is not com.jcraft, not jsch. jsch 0.1.23 --- Key: MAVENUPLOAD-579 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-579 Project: maven-upload-requests Type: Wish Reporter: Mario Ivankovits Assignee: Brett Porter Please upload this new version used by commons-vfs. Thanks! Mario -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to configure multiple parameters in the pom.xml for a Maven 2 plugin
I am trying to modify my plugin to accept multiple parameters as a String array or an ArrayList. In my mojo I have configured the following: /** * An array of names of servers to deploy the target onto. the deployment. * * @parameter */ private String[] serverName; with getters and setters to support the type. In my pom.xml I have the following configured for the parameters in the plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-sample-plugin/artifactId configuration serverNamemyserver/serverName /configuration /plugin When I run the plugin I get the following error message: (found static expression: 'myserver' which may act as a default value). Cause: Cannot assign configuration entry 'serverName' to 'class [Ljava.lang.String;' from 'myserver, which is of type class java.lang.String I read the documentation on handling multiple parameters but did not seem to understand the hints that were given. Can anyone suggest what I am doing wrong. I am sure it is somewhere in my definition of the parameter in the pom.xml. Also any hints as to how to handle a List as well would be appreciated. Thanks Scott D. Ryan Chief Technology Officer Soaring Eagle LLC. 9742 S. Whitecliff Place Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1440) Developer Object Model (DOM)
[ http://jira.codehaus.org/browse/MNG-1440?page=comments#action_50144 ] Brett Porter commented on MNG-1440: --- ok, but we really can't use that acronym. Developer Object Model (DOM) Key: MNG-1440 URL: http://jira.codehaus.org/browse/MNG-1440 Project: Maven 2 Type: New Feature Components: design Reporter: Jason van Zyl Would be cool to be able to reference a developer by id from any POM and get their full range of information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1438) Plugin of plugins (or CompositePlugin)
[ http://jira.codehaus.org/browse/MNG-1438?page=comments#action_50145 ] Brett Porter commented on MNG-1438: --- isn't there already a jira for this? Not sure why this isn't in the design component and wonder if it should be scheduled for 2.1. Plugin of plugins (or CompositePlugin) -- Key: MNG-1438 URL: http://jira.codehaus.org/browse/MNG-1438 Project: Maven 2 Type: New Feature Components: plugin-ideas Reporter: Jason van Zyl Chris, do you think you could pop in your original email? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1437) How to make additions to the POM and have it be backward/forward compatible
[ http://jira.codehaus.org/browse/MNG-1437?page=comments#action_50146 ] Brett Porter commented on MNG-1437: --- there's an open issue about selecting the reader based on the model version. I think that's what's needed (which means making multiple versions available and be able to convert between them). Alternatively, we need to enable one reader to read multiple versions into a known-compatible model. How to make additions to the POM and have it be backward/forward compatible --- Key: MNG-1437 URL: http://jira.codehaus.org/browse/MNG-1437 Project: Maven 2 Type: Task Components: design Reporter: Jason van Zyl I would like to add categories and site staging information to the POM but don't want to break everything. Brett and I have discussed this topic briefly but we need the XML parsing mechanism to be a bit more flexible or we may just have to embrace namespaces to make this work ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_50147 ] Brett Porter commented on MNG-624: -- tha'ts not the meaning of realtivePath - it still relies on the correct data being used so that the project can be built in isolation. Relative path is a hint for the universal source directory. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Components: maven-project Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Original Estimate: 4 hours Remaining: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1436) Unable to load maven-model-2.0-all from a plugin
[ http://jira.codehaus.org/browse/MNG-1436?page=comments#action_50148 ] Brett Porter commented on MNG-1436: --- we won't be allowing maven-model-2.0-all into the plugin, its v4 classes will conflict with the root classloader. What is needed is a way to get maven-model-3.0.1 into the plugin, really. That may be best done by changing the artifact ID of that release. Unable to load maven-model-2.0-all from a plugin Key: MNG-1436 URL: http://jira.codehaus.org/browse/MNG-1436 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: fabrizio giustina Priority: Critical Fix For: 2.0.1 The org.apache.maven:maven-model artifact is available with the all classifier in the maven repo. The all version also contains project v3 classes and reader/writer. Adding a dependency with: dependency groupIdorg.apache.maven/groupId artifactIdmaven-model/artifactId version2.0/version typejar/type classifierall/classifier /dependency let you use project 3 classes in a plugin and install successfully. However, when running the plugin, the maven-model-2.0-all artifact seems to be ignored and replaced by the version in m2/lib _also if the classifier is different_. This is the debug log from an execution of a plugin that uses this dependency: [INFO] Searching repository for plugin with prefix: 'maven1'. [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] maven-maven1-plugin: using locally installed snapshot [DEBUG] org.apache.maven.plugins:maven-maven1-plugin:maven-plugin:2.0-SNAPSHOT (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] Retrieving parent-POM from the repository for project: org.apache.maven:maven-model:jar:2.0 [DEBUG] org.apache.maven:maven-model:jar:all:2.0 (selected for runtime) [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) [DEBUG] dom4j:dom4j:jar:1.4 (selected for runtime) [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-maven1-plugin:2.0-SNAPSHOT:convert' -- [DEBUG] (f) basedir = \testconvert [DEBUG] -- end configuration -- [INFO] [1:convert] [WARNING] pom.xml in \testconvert already exists, overwriting [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader [INFO] [DEBUG] Trace java.lang.NoClassDefFoundError: org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader At the moment this makes impossible to use pom v.3 in mvn. Apart from the classifier issue that could be solved in a future m2 release, I would like to find out a workaroud in order to use v3 poms for a mvn plugin that could automatically convert maven 1 project.xml to mvn pom.xml for making migration from maven 1 easier. The current options I can think at are: - embedding the org.apache.maven.model.v3_0_0.* classes in the plugin - releasing maven-model-2.0-all with a different artifactId (maven-model-all-2.0 or maven-model-v3-2.0) thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to configure multiple parameters in the pom.xml for a Maven 2 plugin
Your configuration should be: serverNames serverNamemyserver/serverName /serverNames If you'd like to file a bug for the error reporting, please do. - Brett Scott Ryan wrote: I am trying to modify my plugin to accept multiple parameters as a String array or an ArrayList. In my mojo I have configured the following: /** * An array of names of servers to deploy the target onto. the deployment. * * @parameter */ private String[] serverName; with getters and setters to support the type. In my pom.xml I have the following configured for the parameters in the plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-sample-plugin/artifactId configuration serverNamemyserver/serverName /configuration /plugin When I run the plugin I get the following error message: (found static expression: 'myserver' which may act as a default value). Cause: Cannot assign configuration entry 'serverName' to 'class [Ljava.lang.String;' from 'myserver, which is of type class java.lang.String I read the documentation on handling multiple parameters but did not seem to understand the hints that were given. Can anyone suggest what I am doing wrong. I am sure it is somewhere in my definition of the parameter in the pom.xml. Also any hints as to how to handle a List as well would be appreciated. Thanks Scott D. Ryan Chief Technology Officer Soaring Eagle LLC. 9742 S. Whitecliff Place Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1443) should not fail in offline mode if pom doesn't exist
[ http://jira.codehaus.org/browse/MNG-1443?page=all ] Edwin Punzalan updated MNG-1443: Attachment: MNG-1443-maven-artifact-manager.patch should not fail in offline mode if pom doesn't exist Key: MNG-1443 URL: http://jira.codehaus.org/browse/MNG-1443 Project: Maven 2 Type: Bug Components: maven-artifact Reporter: Brett Porter Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1443-maven-artifact-manager.patch should instead use the default one, like it would if it didn't exist remotely. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-169) Relocated dependency for tagsoup in xom
[ http://jira.codehaus.org/browse/MEV-169?page=comments#action_50149 ] Edwin Punzalan commented on MEV-169: The dependency issue says its fixed, but i can't see org.ccil.cowan.tagsoup in the repo... should i also relocate the jar? Relocated dependency for tagsoup in xom --- Key: MEV-169 URL: http://jira.codehaus.org/browse/MEV-169 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Yann Le Du Assignee: Edwin Punzalan Important : must be done only after MAVENUPLOAD-573 is achieved Please change tagsoup dependency to : groupIdorg.ccil.cowan.tagsoup/groupId artifactIdtagsoup/artifactId Thx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-132) iBATIS POMs need some work - sqlmaps doesn't depend on common
[ http://jira.codehaus.org/browse/MEV-132?page=all ] Edwin Punzalan closed MEV-132: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to be cascaded to central repo. iBATIS POMs need some work - sqlmaps doesn't depend on common - Key: MEV-132 URL: http://jira.codehaus.org/browse/MEV-132 Project: Maven Evangelism Type: Bug Reporter: Matt Raible Assignee: Edwin Punzalan ibatis2-sqlmap should depend on ibatis2-common both don't have to be specified. Also, why are avalon-framework and logkit required (they shouldn't be IMO). Another wierd thing is when I replace Hibernate with iBATIS, I have to include commons-logging (even though it's required by Spring). dependency artifactIdibatis2-sqlmap/artifactId groupIdcom.ibatis/groupId version2.1.5.582/version exclusions exclusion artifactIdavalon-framework/artifactId groupIdavalon-framework/groupId /exclusion exclusion artifactIdlogkit/artifactId groupIdlogkit/groupId /exclusion /exclusions /dependency dependency artifactIdibatis2-common/artifactId groupIdcom.ibatis/groupId version2.1.5.582/version exclusions exclusion artifactIdavalon-framework/artifactId groupIdavalon-framework/groupId /exclusion exclusion artifactIdlogkit/artifactId groupIdlogkit/groupId /exclusion /exclusions /dependency !-- For some reason, removing Hibernate requires commons-logging -- dependency artifactIdcommons-logging/artifactId groupIdcommons-logging/groupId version1.0.4/version /dependency -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-168) swarmcache-1.0RC2.pom reference a wrong commons logging version
[ http://jira.codehaus.org/browse/MEV-168?page=all ] Edwin Punzalan closed MEV-168: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to reach to central repo. swarmcache-1.0RC2.pom reference a wrong commons logging version --- Key: MEV-168 URL: http://jira.codehaus.org/browse/MEV-168 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Rico Schäpe Assignee: Edwin Punzalan The swarmcache-1.0RC2.pom reference a wrong commons logging version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-174) Wrong apacheds-main dependency groupId in acegi-security POM
[ http://jira.codehaus.org/browse/MEV-174?page=all ] Edwin Punzalan closed MEV-174: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to reach central repo. Wrong apacheds-main dependency groupId in acegi-security POM Key: MEV-174 URL: http://jira.codehaus.org/browse/MEV-174 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Yann Le Du Assignee: Edwin Punzalan In dependency groupIdapache-directory/groupId artifactIdapacheds-main/artifactId version0.9-SNAPSHOT/version /dependency please change groupId to groupIddirectory/groupId Thx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-129) eXo POM's have incorrect groupId
[ http://jira.codehaus.org/browse/MEV-129?page=all ] Edwin Punzalan closed MEV-129: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours before the fix reaches central repo. eXo POM's have incorrect groupId Key: MEV-129 URL: http://jira.codehaus.org/browse/MEV-129 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Stephen Duncan Jr Assignee: Edwin Punzalan Example: http://www.ibiblio.org/maven2/exo/exoplatform.portal.api/1.0/exoplatform.portal.api-1.0.pom I assume this happened during automatic conversion from Maven1. The dependency groupId has been correctly changed to exo to match the location in the repository, but the groupId specified in each POM incorrectly uses . characters, and will not work with Maven 2. They should all be changed to exo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-153) commons-lang-2.1 is missing scope test on junit dependency
[ http://jira.codehaus.org/browse/MEV-153?page=all ] Edwin Punzalan closed MEV-153: -- Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to reach central repo. commons-lang-2.1 is missing scope test on junit dependency -- Key: MEV-153 URL: http://jira.codehaus.org/browse/MEV-153 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Ørjan Austvold Assignee: Edwin Punzalan The JUnit dependency of commons-lang is missing scopetest/scope on the junit:junit-3.8.1 dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-177) older jstl jars in old location need relocation tag added
[ http://jira.codehaus.org/browse/MEV-177?page=all ] Edwin Punzalan closed MEV-177: -- Resolution: Fixed Patch applied. Thanks. ^_^ older jstl jars in old location need relocation tag added - Key: MEV-177 URL: http://jira.codehaus.org/browse/MEV-177 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Tomislav Stojcevich Assignee: Edwin Punzalan Attachments: MEV-177-jstl.jstl.patch, jstl-1.0.1.pom, jstl-1.0.2.pom, jstl-1.0.3.pom, jstl-1.0.4.pom, jstl-1.0.5.pom, jstl-1.0.pom, jstl-1.1.0.pom, jstl-1.1.1.pom The 2 newest versions (1.0.6 and 1.1.2) have the relocation tag to give a warning. All older versions need to have the tag added as well. The tag needs to be added because in one of my projects I am using the new groupId (javax.servlet), but some of the transient dependencies are declared with the older groupId (jstl.jstl). In my project I use javax.servlet.jstl-1.0.6.jar, I have a transient dependency that uses jstl.jstl-1.0.2.jar. The result is that both jars get put in my classpath (and in my WEB-INF/lib) with the older one first (since it sorts that way alphabetically) which is not desirable. If they had the same groupId maven would use the new one only. Attached are the updated poms for all older versions with the relocation tag to give the warning. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-178) struts 1-1 servletapi warning
[ http://jira.codehaus.org/browse/MEV-178?page=all ] Edwin Punzalan closed MEV-178: -- Assign To: Edwin Punzalan Resolution: Fixed Applied. Thanks. struts 1-1 servletapi warning - Key: MEV-178 URL: http://jira.codehaus.org/browse/MEV-178 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Brian Fox Assignee: Edwin Punzalan Attachments: struts-1.1-pom-fix serlvetapi has been relocated to javax.servlet.servlet-api. This produces warnings. Patch is attached, thanks for the help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1387) surefire plugin crashes
[ http://jira.codehaus.org/browse/MNG-1387?page=all ] Johnny R. Ruiz III updated MNG-1387: Attachment: MNG-1387-surefire.patch Here's a patch to surefire project itself. This is committed in surefire project. I attached here for reference. surefire plugin crashes --- Key: MNG-1387 URL: http://jira.codehaus.org/browse/MNG-1387 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0.1, 2.0 Environment: win XP-SP2, jvm 1.4.2_08 Reporter: Erick Dovale Assignee: Johnny R. Ruiz III Attachments: MNG-1387-surefire.patch, test-surefire.zip The surefire plugin crashes with the following exception: Reporter method testStarting completed abruptly with an exception. java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1444) at org.codehaus.surefire.report.XMLReporter.testStarting(XMLReporter.jav a:101) at org.codehaus.surefire.report.ReporterManager.testStarting(ReporterMan ager.java:304) at org.codehaus.surefire.battery.TestListenerInvocationHandler.handleSta rtTest(TestListenerInvocationHandler.java:143) at org.codehaus.surefire.battery.TestListenerInvocationHandler.invoke(Te stListenerInvocationHandler.java:120) at $Proxy0.startTest(Unknown Source) at junit.framework.TestResult.startTest(TestResult.java:151) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery. java:246) at org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java: 220) at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:204) at org.codehaus.surefire.Surefire.run(Surefire.java:153) at org.codehaus.surefire.Surefire.run(Surefire.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:309) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To
[jira] Closed: (MNG-1387) surefire plugin crashes
[ http://jira.codehaus.org/browse/MNG-1387?page=all ] Johnny R. Ruiz III closed MNG-1387: --- Resolution: Fixed I committed a patch for surefire. But I don't suggest overriding the toString() method of the testCase since the testCase name will be overriden. Fixed. surefire plugin crashes --- Key: MNG-1387 URL: http://jira.codehaus.org/browse/MNG-1387 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0.1, 2.0 Environment: win XP-SP2, jvm 1.4.2_08 Reporter: Erick Dovale Assignee: Johnny R. Ruiz III Attachments: MNG-1387-surefire.patch, test-surefire.zip The surefire plugin crashes with the following exception: Reporter method testStarting completed abruptly with an exception. java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1444) at org.codehaus.surefire.report.XMLReporter.testStarting(XMLReporter.jav a:101) at org.codehaus.surefire.report.ReporterManager.testStarting(ReporterMan ager.java:304) at org.codehaus.surefire.battery.TestListenerInvocationHandler.handleSta rtTest(TestListenerInvocationHandler.java:143) at org.codehaus.surefire.battery.TestListenerInvocationHandler.invoke(Te stListenerInvocationHandler.java:120) at $Proxy0.startTest(Unknown Source) at junit.framework.TestResult.startTest(TestResult.java:151) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery. java:246) at org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java: 220) at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:204) at org.codehaus.surefire.Surefire.run(Surefire.java:153) at org.codehaus.surefire.Surefire.run(Surefire.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:309) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1384) optional dependencies not resolved while compiling from a master project
[ http://jira.codehaus.org/browse/MNG-1384?page=all ] Edwin Punzalan updated MNG-1384: Attachment: MNG-1384-maven-artifact.patch optional dependencies not resolved while compiling from a master project Key: MNG-1384 URL: http://jira.codehaus.org/browse/MNG-1384 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0 Reporter: fabrizio giustina Assignee: Edwin Punzalan Priority: Critical Fix For: 2.0.1 Attachments: MNG-1384-maven-artifact.patch project-A has a dependency defined as optional but required to compile. Running mvn install directly on project-A works. If project-A is referenced as a module in master-project, running mvn install from master-project will result in a build failure, since direct optional dependencies will not be included in project-A compile classpath. A related issue (currently fixed by manually resolving artifacts) is that optional direct dependencies were not included in the classpath file generated by the m2 eclipse plugin (direct optional dependencies are missing from project.getTestArtifacts() with @requiresDependencyResolution test) Shouldn't optional dependencies only be excluded from referenced projects or am I missing something? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1063) release-pom is changed too much
[ http://jira.codehaus.org/browse/MNG-1063?page=comments#action_50165 ]
Brett Porter commented on MNG-1063:
---
actually, no need to fill in the super pom - the modelVersion will control that.
currently, it warns about the deployed version having fixed versions when using
the release pom. This is an issue - we do not want that to be the case. Some
more thought is needed here. Perhaps release:perform, using deploy, defaults to
not using the release-pom, while generally building from a checkout defaults to
using it (ie, commit the release pom containing resolved versions, but
release:perform would use -f pom.xml).
Another thought is to revisit why we had release pom. If it is in fact just the
versions, then we could go back to populating an extra version tag (eg
suggestedVersion) that would be used as the suggested version in conjunction
with the given range.
The release pom was meant to capture any other environmental influences at the
time, however we don't really have a way to tell which of those actually modify
the build and which should be retained (eg profiles that attach artifacts,
${basedir}, etc).
release-pom is changed too much
---
Key: MNG-1063
URL: http://jira.codehaus.org/browse/MNG-1063
Project: Maven 2
Type: Bug
Components: maven-release-plugin
Reporter: Brett Porter
this needs a full review.
Expressions are populated that shouldn't be (only external settings should be
filled in, but not those like basedir or are otherwise path dependant like
project.file...)
basically need to use the pre-interpolation, post inheritence pom... or can
we live with the original one without inheritence and just fill in resolved
versions?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
