Processing Patches
Hi, I've tried to streamline the processing of patches for MNG by adjusting the default issue creation screen: http://jira.codehaus.org/secure/CreateIssue.jspa And specifically the checkbox at the bottom which allow someone to specify whether they are submitting a patch or not: http://people.apache.org/~jvanzyl/patches.png So hopefully folks can check this off which will make it easier for us to process the patches. I created a simple filter that's shared called "Maven Patches": http://people.apache.org/~jvanzyl/PatchesFilter.png If you use this filter inside Eclipse using Mylar then actually reviewing the patches is a lot easier as it's easy to apply them and check the differences. I might write something up on that once I get it down myself. I've just started trying to use Mylar to process the patches. To get the initial list I used the existing filter we had searching for "patch" and "diff" and flipped the bit on the patch submitted. I went through them and tried to remove the false positives so what's left is what should be issues with patches. If you've got any more could you please bulk change them and flip the patch submitted bit. I will update the patch submission doco with these screen shots but hopefully change the issue creation form with the checkbox will help us identify them. I'm going to try and review the rest of the patches this week while trying to flesh out the 2.1 arch goal and taxonomy. It just all needs to be cleaned up before we can proceed in any meaningful way. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MNG-2121) mvn launch script should use jpackage.org config if available
On 1 Jun 07, at 12:50 AM 1 Jun 07, Brett Porter wrote: Jason, There was hardly consensus on this issue. There were definitely more users who were in the "who cares" camp. And I will always be -1 for adding anything that is location specific based on platform/distribution. We have enough problems with behaviors of different platform/distributions a la the shell script hacks. If we give an inch every distribution will insist on having it's platform/distribution specifics baked into everything we have. Let the distributions support it. I will never lend support to something I think will fracture usage patterns. More generally, maybe it'd be better to leave it open and unscheduled and let user votes drive it? I've sifted through almost all the issues and there is no drive for it. - Brett On 01/06/2007, at 2:23 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-2121? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2121. -- Resolution: Won't Fix Not supporting jpackage. Redhat specific and we're not interested in fracturing our installs. mvn launch script should use jpackage.org config if available - Key: MNG-2121 URL: http://jira.codehaus.org/browse/MNG-2121 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.2 Environment: GNU/Linux Reporter: Chris Hubick Priority: Minor Fix For: 2.2.x Attachments: maven_jpp.patch I am attempting to install and use Maven for the first time... so excuse me if I'm off base here :) It is my understanding that a single global classpath (and JVM) is generally deprecated, so I trivially modified my version of the command line 'mvn' script to automatically utilize my existing jpackage.org configuration (patch attached). Also, the installation instructions at http://maven.apache.org/ download.html say to unpack it to /usr/local/maven-2.0.2/, yet the mvn script looks for the existance of /opt/m2/ when attempting to automatically set $M2_HOME. I symlinked /usr/local/ maven to /usr/local/maven-2.0.2, and also trivially patched my mvn script to look for /usr/local/maven/ when setting $M2_HOME. Instead of adding $M2_HOME/bin to my global path, I just symlinked /usr/local/bin/mvn -> /usr/local/maven/bin/mvn. In this way, I have a working Maven (I hope) without having to modify any global configuration on my machine - meaning the install should be side effect free. I can also upgrade to a new release without having to modify any configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Subscription: Outstanding Repository Maintenance: Evangelism
Hen, Yep, you already have access. - Brett On 01/06/2007, at 2:52 PM, Carlos Sanchez wrote: brett or jason are the despots in the machine you can start with the apache side too On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I've closed the top list. Not sure I have an account yet for the latter. Any idea? Hen On 5/31/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > go for it, but keep the poms for the corrupt jars (just delete the wrong stuff) > > On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Suggest we close the following: > > > > MEV-325 - Too minor to bother with. WONTFIX. > > MEV-201 - No org/relaxngdatatype. INVALID. > > MEV-401 - Dead issue? > > MEV-483 - ActiveMQ's problem. INVALID. > > MEV-511 - Struts2 snapshot dep. WONTFIX > > MEV-499 - Apart from the magic release, this issue is FIXED. Close > > issue and bring up with Vincent separately. > > MEV-436 - No point keeping these open. WONTFIX. > > > > Suggest we act on: > > > > MEV-449 - Delete Lucene 1.9.1 directory (and on people.apache.org) and > > mail lucene pmc. > > MEV-520 - Delete retroweaver 1.2.4. > > > > > > On 5/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Issue Subscription > > > Filter: Outstanding Repository Maintenance: Evangelism (40 issues) > > > Subscriber: mavendevlist > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
Re: [jira] Subscription: Outstanding Repository Maintenance: Evangelism
brett or jason are the despots in the machine you can start with the apache side too On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I've closed the top list. Not sure I have an account yet for the latter. Any idea? Hen On 5/31/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > go for it, but keep the poms for the corrupt jars (just delete the wrong stuff) > > On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Suggest we close the following: > > > > MEV-325 - Too minor to bother with. WONTFIX. > > MEV-201 - No org/relaxngdatatype. INVALID. > > MEV-401 - Dead issue? > > MEV-483 - ActiveMQ's problem. INVALID. > > MEV-511 - Struts2 snapshot dep. WONTFIX > > MEV-499 - Apart from the magic release, this issue is FIXED. Close > > issue and bring up with Vincent separately. > > MEV-436 - No point keeping these open. WONTFIX. > > > > Suggest we act on: > > > > MEV-449 - Delete Lucene 1.9.1 directory (and on people.apache.org) and > > mail lucene pmc. > > MEV-520 - Delete retroweaver 1.2.4. > > > > > > On 5/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Issue Subscription > > > Filter: Outstanding Repository Maintenance: Evangelism (40 issues) > > > Subscriber: mavendevlist > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride > > - > 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MNG-2121) mvn launch script should use jpackage.org config if available
Jason, There was hardly consensus on this issue. More generally, maybe it'd be better to leave it open and unscheduled and let user votes drive it? - Brett On 01/06/2007, at 2:23 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-2121? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2121. -- Resolution: Won't Fix Not supporting jpackage. Redhat specific and we're not interested in fracturing our installs. mvn launch script should use jpackage.org config if available - Key: MNG-2121 URL: http://jira.codehaus.org/browse/MNG-2121 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.2 Environment: GNU/Linux Reporter: Chris Hubick Priority: Minor Fix For: 2.2.x Attachments: maven_jpp.patch I am attempting to install and use Maven for the first time... so excuse me if I'm off base here :) It is my understanding that a single global classpath (and JVM) is generally deprecated, so I trivially modified my version of the command line 'mvn' script to automatically utilize my existing jpackage.org configuration (patch attached). Also, the installation instructions at http://maven.apache.org/ download.html say to unpack it to /usr/local/maven-2.0.2/, yet the mvn script looks for the existance of /opt/m2/ when attempting to automatically set $M2_HOME. I symlinked /usr/local/maven to /usr/ local/maven-2.0.2, and also trivially patched my mvn script to look for /usr/local/maven/ when setting $M2_HOME. Instead of adding $M2_HOME/bin to my global path, I just symlinked /usr/local/ bin/mvn -> /usr/local/maven/bin/mvn. In this way, I have a working Maven (I hope) without having to modify any global configuration on my machine - meaning the install should be side effect free. I can also upgrade to a new release without having to modify any configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MNG-2203) Problem with duplicates
Is this still an issue though? Maybe it should be left open for a simpler fix. - Brett On 01/06/2007, at 2:19 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-2203? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2203. -- Assignee: (was: Maria Odea Ching) Resolution: Won't Fix That patch is way to complicated for finding duplicates. We really should fail on duplicate entries. Problem with duplicates --- Key: MNG-2203 URL: http://jira.codehaus.org/browse/MNG-2203 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0-alpha-1, 2.0.3 Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1- SNAPSHOT Reporter: Francesco Tinti Fix For: 2.0.x Attachments: MNG-2203-maven.patch, pomerr.zip Time Spent: 1 day, 6 hours, 30 minutes Remaining Estimate: 0 minutes Declare in POM a duplicate group-artifact dependency but with different versions.: there's no log of duplicate entry. Maven will also take care only of the latest dependency, so if the version is ancient of the other, you can obtain (of course) compilation error. In attachment a simple demonstration with a specific commons-io 1.2 function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Subscription: Outstanding Repository Maintenance: Evangelism
I've closed the top list. Not sure I have an account yet for the latter. Any idea? Hen On 5/31/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: go for it, but keep the poms for the corrupt jars (just delete the wrong stuff) On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > Suggest we close the following: > > MEV-325 - Too minor to bother with. WONTFIX. > MEV-201 - No org/relaxngdatatype. INVALID. > MEV-401 - Dead issue? > MEV-483 - ActiveMQ's problem. INVALID. > MEV-511 - Struts2 snapshot dep. WONTFIX > MEV-499 - Apart from the magic release, this issue is FIXED. Close > issue and bring up with Vincent separately. > MEV-436 - No point keeping these open. WONTFIX. > > Suggest we act on: > > MEV-449 - Delete Lucene 1.9.1 directory (and on people.apache.org) and > mail lucene pmc. > MEV-520 - Delete retroweaver 1.2.4. > > > On 5/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Issue Subscription > > Filter: Outstanding Repository Maintenance: Evangelism (40 issues) > > Subscriber: mavendevlist > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
Re: [jira] Subscription: Outstanding Repository Maintenance: Evangelism
go for it, but keep the poms for the corrupt jars (just delete the wrong stuff) On 5/31/07, Henri Yandell <[EMAIL PROTECTED]> wrote: Suggest we close the following: MEV-325 - Too minor to bother with. WONTFIX. MEV-201 - No org/relaxngdatatype. INVALID. MEV-401 - Dead issue? MEV-483 - ActiveMQ's problem. INVALID. MEV-511 - Struts2 snapshot dep. WONTFIX MEV-499 - Apart from the magic release, this issue is FIXED. Close issue and bring up with Vincent separately. MEV-436 - No point keeping these open. WONTFIX. Suggest we act on: MEV-449 - Delete Lucene 1.9.1 directory (and on people.apache.org) and mail lucene pmc. MEV-520 - Delete retroweaver 1.2.4. On 5/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Issue Subscription > Filter: Outstanding Repository Maintenance: Evangelism (40 issues) > Subscriber: mavendevlist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Subscription: Outstanding Repository Maintenance: Evangelism
Suggest we close the following: MEV-325 - Too minor to bother with. WONTFIX. MEV-201 - No org/relaxngdatatype. INVALID. MEV-401 - Dead issue? MEV-483 - ActiveMQ's problem. INVALID. MEV-511 - Struts2 snapshot dep. WONTFIX MEV-499 - Apart from the magic release, this issue is FIXED. Close issue and bring up with Vincent separately. MEV-436 - No point keeping these open. WONTFIX. Suggest we act on: MEV-449 - Delete Lucene 1.9.1 directory (and on people.apache.org) and mail lucene pmc. MEV-520 - Delete retroweaver 1.2.4. On 5/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (40 issues) Subscriber: mavendevlist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MNG-1910) Allow jdk 1.4+ as profile requirement
It's not the same thing. The issue refers to profile activation, not to criteria for failing the build. -j On Jun 1, 2007, at 12:07 AM, Brett Porter wrote: Is this the same thing? turning profiles on/off vs stopping the build if it's not seems different. - Brett On 01/06/2007, at 1:53 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-1910? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1910. -- Resolution: Won't Fix You can use the enforcer plugin now in a profile. Allow jdk 1.4+ as profile requirement - Key: MNG-1910 URL: http://jira.codehaus.org/browse/MNG-1910 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.1 Reporter: Jochen Wiedmann Fix For: 2.0.x Attachments: jdk_plus.patch, jdk_plus.patch The "jdk" element in the POM allows for strings like "1.5", or "! 1.4" only. It would be desirable to use "1.4+", or something similar. The attached patch serves that purpose. A patch for the docs is missing. I am ready to create such a patch as well, if I know that my idea would be accepted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: [jira] Closed: (MNG-1910) Allow jdk 1.4+ as profile requirement
Is this the same thing? turning profiles on/off vs stopping the build if it's not seems different. - Brett On 01/06/2007, at 1:53 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-1910? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1910. -- Resolution: Won't Fix You can use the enforcer plugin now in a profile. Allow jdk 1.4+ as profile requirement - Key: MNG-1910 URL: http://jira.codehaus.org/browse/MNG-1910 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.1 Reporter: Jochen Wiedmann Fix For: 2.0.x Attachments: jdk_plus.patch, jdk_plus.patch The "jdk" element in the POM allows for strings like "1.5", or "! 1.4" only. It would be desirable to use "1.4+", or something similar. The attached patch serves that purpose. A patch for the docs is missing. I am ready to create such a patch as well, if I know that my idea would be accepted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: [jira] Closed: (MNG-2521) Using JDK 1.5+ annotations for mojos metadata
Jason, I'm interested in playing with these, but I haven't been able to find them (though I do recall seeing commits). Can you point me in the right direction? - Brett On 01/06/2007, at 1:32 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-2521? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2521. -- Resolution: Fixed Kenney and Eric have already created tools for this. Using JDK 1.5+ annotations for mojos metadata - Key: MNG-2521 URL: http://jira.codehaus.org/browse/MNG-2521 Project: Maven 2 Issue Type: New Feature Components: Multiple Language Support Affects Versions: 2.0-alpha-1, 2.0.4, 2.0.5 Reporter: Yoav Landman Attachments: maven-plugin-tools-anno.patch The attached patch contains a plugin-tool that allows writing annotatd mojos using JDK 1.5 annotations instead of doclet comments. It is was created from (my) sf.net project https://sourceforge.net/ projects/mvn-anno-mojo/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
Hi Mark, Sure, jump on in your morning (or grab me on google talk, yahoo, skype :). I'll still be here. Emmanuel should be around then too, and he's done the most work on the release plugin recently. We can post back with what we figure out... - Brett On 01/06/2007, at 1:36 AM, Mark Hobson wrote: On 30/05/07, Mark Hobson <[EMAIL PROTECTED]> wrote: On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote: > So the sequence might need to be: > - resolve the project dependencies, filtering out the reactor projects > - add the reactor projects to the list of resolved artifacts > - iterate through the reactor projects and resolve each's > dependencies (again filtering the reactor projects) and add to the > list of resolved artifacts. > > Does that make sense? Possibly, I'll consider it properly tomorrow and let you of the next problem ;) I don't think this will work since the ArtifactCollector would be bypassed when merging the two sets of dependencies together. This is becoming quite some workaround - why not add @rDR back in and have 'mvn install' as a workaround to MNG-3023? Brett, are you available on IRC sometime to chat this through? I'm GMT+1, so could be tricky :) Cheers, Mark - 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]
Re: [jira] Closed: (MNG-50) Coding standard descriptor
Cool. But we will tie them back into JIRA eventually, right? That particular issue seemed like a pretty self-contained goal. - Brett On 01/06/2007, at 1:43 PM, Jason van Zyl wrote: On 31 May 07, at 11:16 PM 31 May 07, Brett Porter wrote: Jason, Bit confused about this one - is it done, not being done, or on the roadmap (and if so, why closed?) I put it in here: http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven +2.1 I'm going to cleanse JIRA and turn that document back into a coherent set of issues. - Brett On 01/06/2007, at 12:36 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-50? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-50. Resolution: Won't Fix Added to the design documents for 2.1. Coding standard descriptor -- Key: MNG-50 URL: http://jira.codehaus.org/browse/MNG-50 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl Priority: Minor Fix For: 2.1.x Add a field to the POM that describes the coding standard used by a project. This value could then be used to create a link to a standard set of documents describing the chose coding standard: sun, turbine, gnu or what have you. This could possibly be combined with some other properties that might generally control source formatting and verification type plugins like checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot 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]
Re: [jira] Closed: (MNG-50) Coding standard descriptor
On 31 May 07, at 11:16 PM 31 May 07, Brett Porter wrote: Jason, Bit confused about this one - is it done, not being done, or on the roadmap (and if so, why closed?) I put it in here: http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1 I'm going to cleanse JIRA and turn that document back into a coherent set of issues. - Brett On 01/06/2007, at 12:36 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-50? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-50. Resolution: Won't Fix Added to the design documents for 2.1. Coding standard descriptor -- Key: MNG-50 URL: http://jira.codehaus.org/browse/MNG-50 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl Priority: Minor Fix For: 2.1.x Add a field to the POM that describes the coding standard used by a project. This value could then be used to create a link to a standard set of documents describing the chose coding standard: sun, turbine, gnu or what have you. This could possibly be combined with some other properties that might generally control source formatting and verification type plugins like checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (MNG-50) Coding standard descriptor
Jason, Bit confused about this one - is it done, not being done, or on the roadmap (and if so, why closed?) - Brett On 01/06/2007, at 12:36 PM, Jason van Zyl (JIRA) wrote: [ http://jira.codehaus.org/browse/MNG-50? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-50. Resolution: Won't Fix Added to the design documents for 2.1. Coding standard descriptor -- Key: MNG-50 URL: http://jira.codehaus.org/browse/MNG-50 Project: Maven 2 Issue Type: New Feature Reporter: Jason van Zyl Priority: Minor Fix For: 2.1.x Add a field to the POM that describes the coding standard used by a project. This value could then be used to create a link to a standard set of documents describing the chose coding standard: sun, turbine, gnu or what have you. This could possibly be combined with some other properties that might generally control source formatting and verification type plugins like checkstyle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (35 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site Generation Struggles
This is a user group question - but look below. On 5/31/07, Brent Kersanske <[EMAIL PROTECTED]> wrote: I've been struggling with some of maven's custom site generation tools for a few days now. It seems there is very little helpful information out there, and the few bits of good information that do exist are difficult to find. I've gotten to the point where I have a working velocity template for my site, and I've added dynamic javascript menus in place of the normal menus. I wanted to format the actual content (reports, project documentation, etc) that is generated by reporting plugins and assorted project information in the pom. I understand that maven uses doxia to render all content similarly from accepted formats. If possible, I'd like to render content within collapsible ajax panels to allow the user to eliminate a lot of the extra noise that some report plugins deliver. What's the point of Ajax? A collapsible menu - sure - but Ajax? An old-fashioned javascript collapsible menu is one of the examples here: http://sonatype.com/book/site-generation.html Eric Would this be possible? If not, what capabilities does a developer have as far as customization of report and project information content go? If anyone has any suggestions or links to helpful documentation, I would be greatly appreciative. Thanks, Brent Kersanske Akorri -- Eric Redmond http://www.sonatype.com
Re: [VOTE] Release maven-one-plugin 1.1
+1 On 31 May 07, at 4:49 PM 31 May 07, Dennis Lundberg wrote: Hi, I'd like to release maven-one-plugin 1.1. Half of the issues filed against 1.0 have been closed in this release. The main reason for the release is the addition of the M1 to M2 pom converter. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11241&styleName=Html&version=12529 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-one- plugin-1.1/ Staged at: http://people.apache.org/~dennisl/staging-repository-one-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-one-plugin 1.1
+1 Arnaud On 31/05/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi, I'd like to release maven-one-plugin 1.1. Half of the issues filed against 1.0 have been closed in this release. The main reason for the release is the addition of the M1 to M2 pom converter. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11241&styleName=Html&version=12529 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-one-plugin-1.1/ Staged at: http://people.apache.org/~dennisl/staging-repository-one-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .. ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ...
[VOTE] Release maven-one-plugin 1.1
Hi, I'd like to release maven-one-plugin 1.1. Half of the issues filed against 1.0 have been closed in this release. The main reason for the release is the addition of the M1 to M2 pom converter. Release Notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11241&styleName=Html&version=12529 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-one-plugin-1.1/ Staged at: http://people.apache.org/~dennisl/staging-repository-one-plugin/ The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to prepare a release because tests fail, but the tests run fine on their own
Ah fun, it crashes with the embedder. g :( On 5/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Stephane Nicoll wrote: > buy a mac? :) :) > Runs fine here. You want me to stage it? Yes please. It would be nice to find out what is going wrong, but that can be done later. > Stéphane > > On 5/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> Hi >> >> I'm preparing to release maven-idea-plugin, but I ran into trouble >> running the tests. I've tried both Maven 2.0.5 and 2.0.6 on Windows, >> against the svn trunk of maven-idea-plugin. >> >> If I run "mvn test" all tests pass. >> >> But if I run "mvn release:prepare -DdryRun=true" the tests fail with the >> following message: >> >> java.lang.NoClassDefFoundError: >> org/codehaus/classworlds/NoSuchRealmException >> at >> org.codehaus.plexus.PlexusTestCase.createContainerInstance(PlexusTestCase.java:126) >> >> at >> org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:91) >> at >> org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:62) >> >> at junit.framework.TestCase.runBare(TestCase.java:125) >> at junit.framework.TestResult$1.protect(TestResult.java:106) >> at junit.framework.TestResult.runProtected(TestResult.java:124) >> at junit.framework.TestResult.run(TestResult.java:109) >> 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(DelegatingMethodAccessorImpl.java:25) >> >> at java.lang.reflect.Method.invoke(Method.java:324) >> at >> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) >> >> at >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) >> >> at >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) >> >> at org.apache.maven.surefire.Surefire.run(Surefire.java:132) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> >> at java.lang.reflect.Method.invoke(Method.java:324) >> at >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) >> >> at >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) >> >> at >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) >> >> >> >> Does anyone have a clue to what might be wrong? >> >> -- >> Dennis Lundberg >> >> - >> 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] > > -- Dennis Lundberg - 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]
Re: Unable to prepare a release because tests fail, but the tests run fine on their own
Stephane Nicoll wrote: buy a mac? :) :) Runs fine here. You want me to stage it? Yes please. It would be nice to find out what is going wrong, but that can be done later. Stéphane On 5/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi I'm preparing to release maven-idea-plugin, but I ran into trouble running the tests. I've tried both Maven 2.0.5 and 2.0.6 on Windows, against the svn trunk of maven-idea-plugin. If I run "mvn test" all tests pass. But if I run "mvn release:prepare -DdryRun=true" the tests fail with the following message: java.lang.NoClassDefFoundError: org/codehaus/classworlds/NoSuchRealmException at org.codehaus.plexus.PlexusTestCase.createContainerInstance(PlexusTestCase.java:126) at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:91) at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:62) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) 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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Does anyone have a clue to what might be wrong? -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to prepare a release because tests fail, but the tests run fine on their own
buy a mac? :) Runs fine here. You want me to stage it? Stéphane On 5/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi I'm preparing to release maven-idea-plugin, but I ran into trouble running the tests. I've tried both Maven 2.0.5 and 2.0.6 on Windows, against the svn trunk of maven-idea-plugin. If I run "mvn test" all tests pass. But if I run "mvn release:prepare -DdryRun=true" the tests fail with the following message: java.lang.NoClassDefFoundError: org/codehaus/classworlds/NoSuchRealmException at org.codehaus.plexus.PlexusTestCase.createContainerInstance(PlexusTestCase.java:126) at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:91) at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:62) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) 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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Does anyone have a clue to what might be wrong? -- Dennis Lundberg - 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]
Re: Unable to prepare a release because tests fail, but the tests run fine on their own
Had that one a couple of weeks ago. Lemme check. Stéphane On 5/31/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi I'm preparing to release maven-idea-plugin, but I ran into trouble running the tests. I've tried both Maven 2.0.5 and 2.0.6 on Windows, against the svn trunk of maven-idea-plugin. If I run "mvn test" all tests pass. But if I run "mvn release:prepare -DdryRun=true" the tests fail with the following message: java.lang.NoClassDefFoundError: org/codehaus/classworlds/NoSuchRealmException at org.codehaus.plexus.PlexusTestCase.createContainerInstance(PlexusTestCase.java:126) at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:91) at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:62) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) 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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Does anyone have a clue to what might be wrong? -- Dennis Lundberg - 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]
Unable to prepare a release because tests fail, but the tests run fine on their own
Hi I'm preparing to release maven-idea-plugin, but I ran into trouble running the tests. I've tried both Maven 2.0.5 and 2.0.6 on Windows, against the svn trunk of maven-idea-plugin. If I run "mvn test" all tests pass. But if I run "mvn release:prepare -DdryRun=true" the tests fail with the following message: java.lang.NoClassDefFoundError: org/codehaus/classworlds/NoSuchRealmException at org.codehaus.plexus.PlexusTestCase.createContainerInstance(PlexusTestCase.java:126) at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:91) at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:62) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) 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(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) Does anyone have a clue to what might be wrong? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New maven-runtime shared component
Hi Jason, On 31/05/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Couple comments: 1. Classloaders are dictated by how ClassWorlds works and simply looking at URLClassloaders isn't going to give you the whole picture and might be misleading as ClassWorlds supports imports and can change the direction of classloading (child first, parent first) depending on the strategy used. Anything not providing ClassRealm information will not be accurate. Generally I think the stuff being used here would need to be presented to clients in an uniform way and I'm trying to do that via the embedder. So I would like to try and integrate these sort of diagnostic features as part of the embedder so that it becomes the standard way for information to be retrieved from Maven. Maybe you could take a look at the embedder and see how you might integrate this component. I'm not sure if I was clear enough about how this component would be used: it is intended to be used outside of Maven, but within a system built by Maven. It simply parses the Maven META-INF metadata embedded in JARs to allow systems to introspect their environment at runtime. Possible use cases would be to display all components' versions in a help dialog, or obtain project metadata to automatically send error reports to the correct issue management system. Is this the area you'd envisage the embedder covering? My understanding of the embedder was that it is used to embed the build process, rather than working with the produced artifacts. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site Generation Struggles
I've been struggling with some of maven's custom site generation tools for a few days now. It seems there is very little helpful information out there, and the few bits of good information that do exist are difficult to find. I've gotten to the point where I have a working velocity template for my site, and I've added dynamic javascript menus in place of the normal menus. I wanted to format the actual content (reports, project documentation, etc) that is generated by reporting plugins and assorted project information in the pom. I understand that maven uses doxia to render all content similarly from accepted formats. If possible, I'd like to render content within collapsible ajax panels to allow the user to eliminate a lot of the extra noise that some report plugins deliver. Would this be possible? If not, what capabilities does a developer have as far as customization of report and project information content go? If anyone has any suggestions or links to helpful documentation, I would be greatly appreciative. Thanks, Brent Kersanske Akorri
Re: New maven-runtime shared component
On 31 May 07, at 11:25 AM 31 May 07, Mark Hobson wrote: Hi there, I've submitted a new shared component, maven-runtime, which can be used to introspect a runtime Maven environment: http://jira.codehaus.org/browse/MNG-3026 I remember a long while back there was some talk on this list about reading pom.properties from a given ClassLoader. Hopefully this component will centralise the code to achieve this, along with reading the full pom.xml models and project ordering. Any feedback welcome. Couple comments: 1. Classloaders are dictated by how ClassWorlds works and simply looking at URLClassloaders isn't going to give you the whole picture and might be misleading as ClassWorlds supports imports and can change the direction of classloading (child first, parent first) depending on the strategy used. Anything not providing ClassRealm information will not be accurate. Generally I think the stuff being used here would need to be presented to clients in an uniform way and I'm trying to do that via the embedder. So I would like to try and integrate these sort of diagnostic features as part of the embedder so that it becomes the standard way for information to be retrieved from Maven. Maybe you could take a look at the embedder and see how you might integrate this component. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
On 30/05/07, Mark Hobson <[EMAIL PROTECTED]> wrote: On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote: > So the sequence might need to be: > - resolve the project dependencies, filtering out the reactor projects > - add the reactor projects to the list of resolved artifacts > - iterate through the reactor projects and resolve each's > dependencies (again filtering the reactor projects) and add to the > list of resolved artifacts. > > Does that make sense? Possibly, I'll consider it properly tomorrow and let you of the next problem ;) I don't think this will work since the ArtifactCollector would be bypassed when merging the two sets of dependencies together. This is becoming quite some workaround - why not add @rDR back in and have 'mvn install' as a workaround to MNG-3023? Brett, are you available on IRC sometime to chat this through? I'm GMT+1, so could be tricky :) Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New maven-runtime shared component
Hi there, I've submitted a new shared component, maven-runtime, which can be used to introspect a runtime Maven environment: http://jira.codehaus.org/browse/MNG-3026 I remember a long while back there was some talk on this list about reading pom.properties from a given ClassLoader. Hopefully this component will centralise the code to achieve this, along with reading the full pom.xml models and project ordering. Any feedback welcome. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
