Re: short term branch for project/group keys
On 27/12/2006, at 7:10 PM, Rahul Thakur wrote: Updates to any children hanging off key entities should cascade. This makes sense if and only if the children are dependent. So, for build definitions - that's right. Profiles and such are all 'links' and so will be managed by the normal foreign key construct. 2) Another thing that Jesse mentioned in his email about breaking up Continuum interface into two or three - I am thinking perhaps it might be an idea to break up the ContinuumStore into as many as well and have one-to- one mapping between store and corresponding continuum interfaces. So, possibly Fine by me. - Brett
Re: short term branch for project/group keys
On 27/12/2006, at 8:28 AM, Jesse McConnell wrote: Rahul is going to mail on how this can be cleaned up in the store api, but I question why we want these methods on the Continuum interface at all? I think it's there as the application interface - for use from the webapp and the xmlrpc interface (which is generated pretty much off the Continuum interface). I'm not a big fan of this when it doesn't have any logic of its own, but it can make sense for the external interface. As long as it isn't used within the app itself, it's a good idea - though I'd even limit it's use in the webapp in favour of the actual components which should not require any additional scaffolding if they are designed right. My thought at the moment is to take methods like 'getBuildDefinitionForGroup' and move those to an interface for group related actions that can't be directly on the ProjectGroup model class. It might make sense to decompose Continuum into a number of different controllers that the main one delegates to just so it isn't so mammoth. The above sounds like a good idea as long as the getBuildDefinitionForGroup method isn't doing any logic, store interactions, or caching (ie, it's just looking up in the group object). Otherwise, I wouldn't do this. The we would have a ContinuumGroup and ContinuumProject interface and impl that could act as facade's over the model classes and some of the other logic oriented methods that are currently in the Continuum interface. That might make sense. Probably worth drawing it up. We definitely need to be making the architecture simpler, not more complicated. - Brett
Re: Releasing the Eclipse plugin
On 12/28/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Fabrizio, Slight delay but I'll have to release the Eclipse plugin from Window. The forked test that you're using won't pass on any system properties so I can't skip the tests. They all fail on OS/X and on Linux. I think that's a clear sign we have some problems with the testing. I will do this tomorrow, but not good at all I don't think that I have to resort to releasing on Windows. The tests are highly fragile if they only survive on Window. This isn't the only plugin that has platform brittleness. I'm hoping that once continuum is setup against the maven svn plugins that you have multiple build machines building to catch these errors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doxia Velocity Render Module
How about committing this to the Maven sandbox? It's open to all apache committers. You might like to discuss this at (and subscribe to) doxia- dev@maven.apache.org - it's low traffic compared to this list and more on topic. Cheers, Brett On 28/12/2006, at 8:41 AM, Henning P. Schmiedehausen wrote: This is the fruit of some toying with Doxia, Plexus, the various different ways to write annotations, Plugins and some general maven hacking. And a lot of frustration about the state of general and specific Maven 2 documentation. It allows you to do things like http://svn.apache.org/viewvc/db/site/templates/whoweare.xml? revision=227393&view=markup with Xdoc and Apt in Maven 2. Docs are at http://people.apache.org/~henning/velocity-doxia-renderer/ Get the source from http://svn.apache.org/repos/asf/velocity/site/ doxia-velocity-renderer/ Comments very much appreciated. Please send me a Cc, I do not really read the maven lists. Best regards Henning P.S.: I would still be interested in a way to access the Mojo API from an extension without going through a plugin and a singleton. P.P.S.: And I am interested why the maven-plexus-plugin does not know about fields in superclasses. The Mojo packager obviously does. -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy "Save the cheerleader. Save the world." - 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]
Releasing the Eclipse plugin
Fabrizio, Slight delay but I'll have to release the Eclipse plugin from Window. The forked test that you're using won't pass on any system properties so I can't skip the tests. They all fail on OS/X and on Linux. I think that's a clear sign we have some problems with the testing. I will do this tomorrow, but not good at all I don't think that I have to resort to releasing on Windows. The tests are highly fragile if they only survive on Window. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (22 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1288Request to upload RCFaces jars : html http://jira.codehaus.org/browse/MAVENUPLOAD-1288 MAVENUPLOAD-1287Request to upload RCFaces jars http://jira.codehaus.org/browse/MAVENUPLOAD-1287 MAVENUPLOAD-1286WizCrypt 2.1 Upload Request To Maven Public Repository http://jira.codehaus.org/browse/MAVENUPLOAD-1286 MAVENUPLOAD-1282PMD 3.9 bundle http://jira.codehaus.org/browse/MAVENUPLOAD-1282 MAVENUPLOAD-1284upload new artifact to The Central Repository http://jira.codehaus.org/browse/MAVENUPLOAD-1284 MAVENUPLOAD-1283jsap-2.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1283 MAVENUPLOAD-1280jMimeMagic 0.1.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1280 MAVENUPLOAD-1281JFacets profile-based framework bundle http://jira.codehaus.org/browse/MAVENUPLOAD-1281 MAVENUPLOAD-1264UrlRewriteFilter 2.6 http://jira.codehaus.org/browse/MAVENUPLOAD-1264 MAVENUPLOAD-1267Upload of novell jldap http://jira.codehaus.org/browse/MAVENUPLOAD-1267 MAVENUPLOAD-1243JCommon 1.0.6 http://jira.codehaus.org/browse/MAVENUPLOAD-1243 MAVENUPLOAD-1149Upload jboss-seam-ui-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1149 MAVENUPLOAD-1148Upload jboss-seam-debug-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1148 MAVENUPLOAD-1147Upload jboss-seam-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1147 MAVENUPLOAD-1130Rhino js-1.5R4.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1130 MAVENUPLOAD-1128Rhino js-1.5R3 http://jira.codehaus.org/browse/MAVENUPLOAD-1128 MAVENUPLOAD-1129Rhino js-1.5R4-RC3 http://jira.codehaus.org/browse/MAVENUPLOAD-1129 MAVENUPLOAD-1084Upload drools:drools-core:3.0.4 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1084 MAVENUPLOAD-1088Upload drools:drools-decisiontables:3.0.4 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1088 MAVENUPLOAD-1085Upload drools:drools-compiler:3.0.4 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1085 MAVENUPLOAD-1087Upload drools:drools-jsr94:3.0.4 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1087 MAVENUPLOAD-976Please upload SUN Java 1.2 rutime http://jira.codehaus.org/browse/MAVENUPLOAD-976 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (40 issues) Subscriber: mavendevlist Key Summary MEV-479 Invalid POI POM http://jira.codehaus.org/browse/MEV-479 MEV-478 jakarta-poi requires commons-lang as dependency http://jira.codehaus.org/browse/MEV-478 MEV-477 stax:stax:1.2.0 pom is missing http://jira.codehaus.org/browse/MEV-477 MEV-457 Geronimo jar fails to download http://jira.codehaus.org/browse/MEV-457 MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib http://jira.codehaus.org/browse/MEV-352 MEV-472 relocate artifacts in the woodstox groupid to org.codehaus.woodstox http://jira.codehaus.org/browse/MEV-472 MEV-427 relocate ehcache:ehcache to net.sf.ehcache http://jira.codehaus.org/browse/MEV-427 MEV-471 javax.xml:jsr173:1.0 should be relocated to javax.xml.bind:jsr173_api:1.0 http://jira.codehaus.org/browse/MEV-471 MEV-469 jaxb-api available with two different groupIds http://jira.codehaus.org/browse/MEV-469 MEV-375 Relocate xpp to xpp3 http://jira.codehaus.org/browse/MEV-375 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-459 Velocity should not depend on Velocity-dep http://jira.codehaus.org/browse/MEV-459 MEV-443 Several projects have maven-metadata.xml files that are missing released versions http://jira.codehaus.org/browse/MEV-443 MEV-461 Missing pom for commons-logging-api-1.1 http://jira.codehaus.org/browse/MEV-461 MEV-455 bad checksums on repo1.maven.org http://jira.codehaus.org/browse/MEV-455 MEV-454 testng-spring has a invalid dependency on testng. http://jira.codehaus.org/browse/MEV-454 MEV-450 plexus-velocity 1.1.2 includes invalid external snapshot repositories http://jira.codehaus.org/browse/MEV-450 MEV-449 lucene 1.9.1 JAR is hosed. http://jira.codehaus.org/browse/MEV-449 MEV-448 xmlrpc POM should include commons-codec http://jira.codehaus.org/browse/MEV-448 MEV-441 Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature http://jira.codehaus.org/browse/MEV-441 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 MEV-436 JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it needs connector-1.5. http://jira.codehaus.org/browse/MEV-436 MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables http://jira.codehaus.org/browse/MEV-296 MEV-405 pom for cactus:cactus:13-1.7.2 http://jira.codehaus.org/browse/MEV-405 MEV-404 pom for cactus:cactus-ant:13-1.7.2 http://jira.codehaus.org/browse/MEV-404 MEV-401 Incoherences / duplication between javax.xml and com.sun.xml http://jira.codehaus.org/browse/MEV-401 MEV-334 Stax POM points to an invalid XMLBeans dependency http://jira.codehaus.org/browse/MEV-334 MEV-384 velocity 1.4 dependencies are wrong http://jira.codehaus.org/browse/MEV-384 MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit) http://jira.codehaus.org/browse/MEV-364 MEV-356 Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2 http://jira.codehaus.org/browse/MEV-356 MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and xmlc-apis.jar is required. http://jira.codehaus.org/browse/MEV-351 MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required for plain ol' JSPs http://jira.codehaus.org/browse/MEV-330 MEV-325 Description of jaxb-api 1.0.1 is wrong http://jira.codehaus.org/browse/MEV-325 MEV-320 Hibernate 3.1.x POMs pull in Sun jars http://jira.codehaus.org/browse/MEV-320 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: selenium tests
On 12/27/06, Brett Porter <[EMAIL PROTECTED]> wrote: 6) we should use dbunit or something similar to set the database up into a consistent state for the respective tests, and tear it down again. Running through the web interface in tearDown is time consuming, and error prone (if you add a new test that doesn't tear itself down, then a different test fails). On 27/12/2006, at 3:57 PM, Brett Porter wrote: > see below > > On 27/12/2006, at 3:09 PM, Brett Porter wrote: > >> >> On 27/12/2006, at 2:08 PM, Brett Porter wrote: >> >>> Hi, >>> >>> A few observations on these. Does anyone else have outstanding >>> "todos" in this area? Would like to gatehr them up and get them >>> resolved to make them useful. >>> >>> 1) these need to be run regularly to be really useful. They >>> aren't part of the main build ( a good idea, since it requires a >>> UI and takes forever). Is there a way to run them in rhino so we >>> can run them as part of the main build and then turn on the other >>> profiles when we have mutliple platforms to test on? >>> >>> 2) they currently all fail - Franz says it's due to UI changes we >>> haven't caught up to. See #1 :) Are the UI changes abstracted >>> sufficiently that this will be a quick fix, or is it going to a >>> be a big search and replace job? They fail due to "user >>> authenticated" assertions failing. >> >> Fixed the fundamental problem, now it's just UI changes. >> >> Down to 14 :) > > Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look later. > >> >>> >>> 3) Is there a way to get it to stop after a certain number of >>> failures? 39 open firefox browser instances caused my mac to >>> kernel panic. >>> >>> 4) I underestand that the plexus-security related tests are >>> shared across both webapps. Should we put some helper code into >>> plexus-security that can be used by these tests so that changes >>> there can be addressed there (preferably using the example webapp)? >>> >>> I think this is the list of things to get done - I can put them >>> in JIRA if there isn't anything extra or anything I've missed in >>> the list. >>> >>> - brett > > 5) the continuum tearDown should not swallow exceptions (retthrow > them, but that means changing the abstract selenium test case to > throw it too) > 7.) Switch to Tomcat 5.5.17 to support the email validations ( a bug in 5.5.20 prohibits that ).
Re: maven 1.x & plexus
Jason, I will commit the necessary code before the end of the week. I'll explain you how you can reproduce it. Thanks a lot arnaud On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Arnaud, Let me know how the alpha-15-SNAPSHOT went and then once we are sync'd up andy and I will track down the problem for you. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: selenium tests
6) we should use dbunit or something similar to set the database up into a consistent state for the respective tests, and tear it down again. Running through the web interface in tearDown is time consuming, and error prone (if you add a new test that doesn't tear itself down, then a different test fails). On 27/12/2006, at 3:57 PM, Brett Porter wrote: see below On 27/12/2006, at 3:09 PM, Brett Porter wrote: On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding "todos" in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to "user authenticated" assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look later. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus-security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett 5) the continuum tearDown should not swallow exceptions (retthrow them, but that means changing the abstract selenium test case to throw it too)
Re: re[2]: Feedback Needed on Release Reporting Tool
Hi Natalie, The logo is somewhat separate - it is part of the overall site configuration, not a part of the report. This sample from John is just using the current default. I agree it is a good idea for our little built by logo to default to one that matches the main logo on the site, it's just a separate discussion. Cheers, Brett On 28/12/2006, at 3:51 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: John What about updating the "Built with Maven" logo? I will send to you in separate email. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Doxia Velocity Render Module
This is the fruit of some toying with Doxia, Plexus, the various different ways to write annotations, Plugins and some general maven hacking. And a lot of frustration about the state of general and specific Maven 2 documentation. It allows you to do things like http://svn.apache.org/viewvc/db/site/templates/whoweare.xml?revision=227393&view=markup with Xdoc and Apt in Maven 2. Docs are at http://people.apache.org/~henning/velocity-doxia-renderer/ Get the source from http://svn.apache.org/repos/asf/velocity/site/doxia-velocity-renderer/ Comments very much appreciated. Please send me a Cc, I do not really read the maven lists. Best regards Henning P.S.: I would still be interested in a way to access the Mojo API from an extension without going through a plugin and a singleton. P.P.S.: And I am interested why the maven-plexus-plugin does not know about fields in superclasses. The Mojo packager obviously does. -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy "Save the cheerleader. Save the world." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-deploy-plugin version 2.3
+1 Stephane Nicoll wrote: +1 Stéphane On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Ok, headers updated. This release contains the changes required for deploying to staging repositories. So I would like to release this so that I can remove the SNAPSHOT from the profile that will be used for release staging. Revision: 490414 Roadmap: http://jira.codehaus.org/browse/MDEPLOY? report=com.atlassian.jira.plugin.system.project:roadmap-panel Thanks, Jason. - 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] - 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: maven-changes-plugin questions
changes.xml is also very useful where module:JIRA project is not 1:1. We have jira projects for each subsystem, not module. On 12/27/06, Jeff Jensen <[EMAIL PROTECTED]> wrote: I like the changes page as a "simplified, user-friendly" list of notable changes made for each release. The defect/RFE tracking system has the details for the initiated users when desired. Quoting Stephane Nicoll <[EMAIL PROTECTED]>: > On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > I never really understood the changes.xml myself, as I don't want to > > keep things in an issue tracking system and changes.xml or is this > > for folks who don't employ an issue tracking system? > > Yes and no. I've always seen it as a "technical" changelog of the > project. When end-users create issues, the summary is not always > understandable so we end up with a list of "things" beings solved. > > The changes.xml allows to describe in more details what happened. It's > a good thing actually and it's certainly a good alternative for people > not using an Issue tracker that maven handles. > > Stéphane > > > > > > > - Keeping it in a maven-changes-plugin brings M1 and M2 more in > > > sync than they were before, which eases migration pains. - 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: maven-changes-plugin questions
I like the changes page as a "simplified, user-friendly" list of notable changes made for each release. The defect/RFE tracking system has the details for the initiated users when desired. Quoting Stephane Nicoll <[EMAIL PROTECTED]>: > On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > I never really understood the changes.xml myself, as I don't want to > > keep things in an issue tracking system and changes.xml or is this > > for folks who don't employ an issue tracking system? > > Yes and no. I've always seen it as a "technical" changelog of the > project. When end-users create issues, the summary is not always > understandable so we end up with a list of "things" beings solved. > > The changes.xml allows to describe in more details what happened. It's > a good thing actually and it's certainly a good alternative for people > not using an Issue tracker that maven handles. > > Stéphane > > > > > > > - Keeping it in a maven-changes-plugin brings M1 and M2 more in > > > sync than they were before, which eases migration pains. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re[2]: Feedback Needed on Release Reporting Tool
John What about updating the "Built with Maven" logo? I will send to you in separate email. Thanks! Natalie --- Original Message --- From: "John Tolentino" <[EMAIL PROTECTED]> To: "Maven Developers List" Date: Sat, 23 Dec 2006 07:13:20 +0800 Subject: Re: Feedback Needed on Release Reporting Tool Here's version 2: http://people.apache.org/~jtolentino/release-reports/MockReport2.html You can also find the corresponding xdoc here: http://people.apache.org/~jtolentino/release-reports/MockReport2.xml I didn't change the left navigation yet as we're still deciding on which reports gets linked to and which will be included within the page. On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: > I see what you mean. I'll post the second version of the mock report > and let's group it from there. :-) > > On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > On 23/12/2006, at 9:13 AM, John Tolentino wrote: > > > > > > > > The vote is an indicator that we're prioritizing what the community > > > needs/wants to get fixed. I think this would be of interest for those > > > making a vote for the release, if the issues they want fixed will go > > > in. > > > > > > > I think these really should be two separate, but related reports. The > > stable would be: > > > > - build status report (for developers, from Continuum, things that > > need immediate attention like broken build, failing tests, failing > > ITs, failing checks) > > - development priorities report (for developers, information on what > > needs attention at any time) > > - release readiness report (for developers, information on what needs > > attention before a release can be cut) > > - changes/release report (for users, information on what was in the > > last release. Could also include announcement text, download links, > > etc). > > > > I think the key differences between 2 and 3 are different handling of > > JIRA. An issue with 1024 votes needs to be scheduled, but it still > > shouldn't block a release (eg, it's a feature, and the release in > > question is only a point release). However, a scheduled issue for the > > point release will block that release and so needs to be considered. > > > > WDYT? > > > > - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse and EAR plugins
On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: If you're sure they work I can do the release. Looks like the EAR plugin is ready now too. It is. I have tested on both windows/linux. I don't have macOSx (yet ;-)) ) We need to seriously all the testing stuff. This is where having 5 different frameworks and utilities is very bad. Indeed. It would really help if everybody knew what tools are available and how to use them. Stéphane Jason. > > fabrizio > > On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> Guys, >> >> I just did a clean install of CentOS (redhat linux), a fresh download >> of 2.0.4, no existing local repository, with java 1.5 and I get >> failures in both the EAR and Eclipse plugins. Do you both happen to >> use Windows? As the failures occur on my OS/X box and my Linux VM >> (running Parallels). So I think you have some problems to track down >> before the release can happen. >> >> http://people.apache.org/~jvanzyl/eclipse-plugin-surefire-reports- >> redhat.tgz >> >> http://people.apache.org/~jvanzyl/ear-plugin-surefire-reports- >> redhat.zip >> >> Thanks, >> >> Jason. >> >> >> >> - >> 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] > > - 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: maven-changes-plugin questions
On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: I never really understood the changes.xml myself, as I don't want to keep things in an issue tracking system and changes.xml or is this for folks who don't employ an issue tracking system? Yes and no. I've always seen it as a "technical" changelog of the project. When end-users create issues, the summary is not always understandable so we end up with a list of "things" beings solved. The changes.xml allows to describe in more details what happened. It's a good thing actually and it's certainly a good alternative for people not using an Issue tracker that maven handles. Stéphane > - Keeping it in a maven-changes-plugin brings M1 and M2 more in > sync than they were before, which eases migration pains. > > I would like to sink my teeth into the patch [1] from Denis > Cabasson which introduces a Modello model for the changes.xml files. > > Let me know what I can help with... > > > [1] http://jira.codehaus.org/browse/MCHANGES-47 > > Jason van Zyl wrote: >> Hi, >> Is anyone actually using this because I'd like to sync this up >> with the reporting we're doing for voting. The JIRA stuff in the >> changes plugin is now obsoleted by the Swizzle (it just kicks >> ass), and I would like to remove the mail sending stuff and put it >> in an announcement component and put in with the /maven/release >> stuff. I would also like to move the changes plugin over to /maven/ >> release stuff as it is in the release vein of things. >> Thanks, >> Jason. >> - >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r490479 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 27 Dec 06, at 6:15 AM 27 Dec 06, Stephane Nicoll wrote:
> I have applied a little hack, let's make sure we fix this in the
> verifier directly.
>
Can you stick something in JIRA or a TODO in the verifier code so
that I don't forget. I still will attempt to merge the various
verifiers and invokers.
Sure, MNG-2718. By the way it seems that MNG-658 is related to this problem.
Stéphane
Jason.
> Cheers,
> Stpéhane
>
> On 12/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Author: snicoll
>> Date: Wed Dec 27 03:12:04 2006
>> New Revision: 490479
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=490479
>> Log:
>> Fixed test failure on linux and macOSx when the build is expected
>> to fail.
>>
>> Modified:
>> maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
>> maven/plugin/ear/AbstractEarPluginTestCase.java
>>
>> Modified: maven/plugins/trunk/maven-ear-plugin/src/test/java/org/
>> apache/maven/plugin/ear/AbstractEarPluginTestCase.java
>> URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-
>> plugin/src/test/java/org/apache/maven/plugin/ear/
>> AbstractEarPluginTestCase.java?
>> view=diff&rev=490479&r1=490478&r2=490479
>> =
>> =
>> --- maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
>> maven/plugin/ear/AbstractEarPluginTestCase.java (original)
>> +++ maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
>> maven/plugin/ear/AbstractEarPluginTestCase.java Wed Dec 27
>> 03:12:04 2006
>> @@ -21,6 +21,7 @@
>>
>> import junit.framework.TestCase;
>> import org.apache.maven.it.Verifier;
>> +import org.apache.maven.it.VerificationException;
>> import org.apache.maven.it.util.ResourceExtractor;
>> import org.custommonkey.xmlunit.XMLAssert;
>>
>> @@ -76,7 +77,20 @@
>> // Let's add alternate settings.xml setting so that the
>> latest dependencies are used
>> verifier.getCliOptions().add( "-s " +
>> settingsFile.getAbsolutePath() );
>> verifier.localRepo = localRepositoryDir.getAbsolutePath();
>> -verifier.executeGoal( "package" );
>> +
>> +// On linux and macOSX, an exception is thrown if a build
>> failure occurs underneath
>> +try
>> +{
>> +verifier.executeGoal( "package" );
>> +}
>> +catch ( VerificationException e )
>> +{
>> +//@TODO needs to be handled nicely in the verifier
>> +if (expectNoError || e.getMessage().indexOf( "Exit
>> code was non-zero") == -1) {
>> +throw e;
>> +}
>> +}
>> +
>> // If no error is expected make sure that error logs are
>> free
>> if ( expectNoError )
>> {
>>
>>
>>
>
> -
> 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-changes-plugin questions
Jason van Zyl wrote: On 27 Dec 06, at 7:17 AM 27 Dec 06, Dennis Lundberg wrote: Hi I've been trying to get the changes plugin into a releasable state. But it has been going on for too long, I did however manage to get a 2.0-beta-2 out there. The main hurdle that I have seen is that the plugin does too much at the same time. This has also been seen on the user list where users migrating from Maven have had difficulties. So I'm in favor of splitting it up: - Rip out the JIRA code and replace it with Swizzle - Move announcing to its own plugin, or perhaps to /maven/release since you only announce when you release right? However I would not like to move the changes.xml parts to /maven/release for a couple of reasons: - It you use a changes.xml file you use it constantly during development, not just when you're doing a release Sure, but when would you actually show it to anyone? You might for example publish the site of a project periodically, to show your users that progress is being made. You might also encourage the users to try out the latest version by highlighting issues that have been fixed since the last stable release. I never really understood the changes.xml myself, as I don't want to keep things in an issue tracking system and changes.xml or is this for folks who don't employ an issue tracking system? I see it as a "poor man's" issue tracking system, for people who don't have access to a full fledged system like JIRA. It's very easy to use for a small project with few changes. - Keeping it in a maven-changes-plugin brings M1 and M2 more in sync than they were before, which eases migration pains. I would like to sink my teeth into the patch [1] from Denis Cabasson which introduces a Modello model for the changes.xml files. Let me know what I can help with... [1] http://jira.codehaus.org/browse/MCHANGES-47 Jason van Zyl wrote: Hi, Is anyone actually using this because I'd like to sync this up with the reporting we're doing for voting. The JIRA stuff in the changes plugin is now obsoleted by the Swizzle (it just kicks ass), and I would like to remove the mail sending stuff and put it in an announcement component and put in with the /maven/release stuff. I would also like to move the changes plugin over to /maven/release stuff as it is in the release vein of things. Thanks, Jason. - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse and EAR plugins
On 27 Dec 06, at 4:22 AM 27 Dec 06, Fabrizio Giustina wrote: Hi Jason, from what I can see in the log the only error for the eclipse plugin is the same we saw before: "Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-eclipse- plugin:test:eclipse." Another thing I see in the log is that an old version of the eclipse plugin is downloaded for some of the tests. I guess this is the reason why you get that failure: the only test which is failing is the one where the plugin gets downloaded and you find in the log "Reloading plugin container for: org.apache.maven.plugins:maven-eclipse-plugin. The plugin artifact has changed", other tests work properly. This doesn't work from a completely clean checkout and you get unreliable results. That's bad. Everything works fine for me on windows, and anyway this is surely a problem with the test framework and not the plugin itself. Given that we already know that tests needs to be refactored and cleaned up, I would prefer to go on with this release as is before starting such refactoring (could be a long task, I don't want to delay the release again). Fair enough, if it blows up I'll just send everyone your way :-) So, WDYT about ignoring/disabling failing tests and push this one out before reworking the test framework? Since this appears to be a difficult release on your environment I could take care of releasing it directly, as said tests work fine here... If you're sure they work I can do the release. Looks like the EAR plugin is ready now too. We need to seriously all the testing stuff. This is where having 5 different frameworks and utilities is very bad. Jason. fabrizio On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Guys, I just did a clean install of CentOS (redhat linux), a fresh download of 2.0.4, no existing local repository, with java 1.5 and I get failures in both the EAR and Eclipse plugins. Do you both happen to use Windows? As the failures occur on my OS/X box and my Linux VM (running Parallels). So I think you have some problems to track down before the release can happen. http://people.apache.org/~jvanzyl/eclipse-plugin-surefire-reports- redhat.tgz http://people.apache.org/~jvanzyl/ear-plugin-surefire-reports- redhat.zip Thanks, Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r490479 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
On 27 Dec 06, at 6:15 AM 27 Dec 06, Stephane Nicoll wrote:
Jason,
The ear ITs are now fixed on linux. It's what I thought (the process
exit code being different on linux and Windows).
I have applied a little hack, let's make sure we fix this in the
verifier directly.
Can you stick something in JIRA or a TODO in the verifier code so
that I don't forget. I still will attempt to merge the various
verifiers and invokers.
Jason.
Cheers,
Stpéhane
On 12/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: snicoll
Date: Wed Dec 27 03:12:04 2006
New Revision: 490479
URL: http://svn.apache.org/viewvc?view=rev&rev=490479
Log:
Fixed test failure on linux and macOSx when the build is expected
to fail.
Modified:
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
maven/plugin/ear/AbstractEarPluginTestCase.java
Modified: maven/plugins/trunk/maven-ear-plugin/src/test/java/org/
apache/maven/plugin/ear/AbstractEarPluginTestCase.java
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-
plugin/src/test/java/org/apache/maven/plugin/ear/
AbstractEarPluginTestCase.java?
view=diff&rev=490479&r1=490478&r2=490479
=
=
--- maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
maven/plugin/ear/AbstractEarPluginTestCase.java (original)
+++ maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/
maven/plugin/ear/AbstractEarPluginTestCase.java Wed Dec 27
03:12:04 2006
@@ -21,6 +21,7 @@
import junit.framework.TestCase;
import org.apache.maven.it.Verifier;
+import org.apache.maven.it.VerificationException;
import org.apache.maven.it.util.ResourceExtractor;
import org.custommonkey.xmlunit.XMLAssert;
@@ -76,7 +77,20 @@
// Let's add alternate settings.xml setting so that the
latest dependencies are used
verifier.getCliOptions().add( "-s " +
settingsFile.getAbsolutePath() );
verifier.localRepo = localRepositoryDir.getAbsolutePath();
-verifier.executeGoal( "package" );
+
+// On linux and macOSX, an exception is thrown if a build
failure occurs underneath
+try
+{
+verifier.executeGoal( "package" );
+}
+catch ( VerificationException e )
+{
+//@TODO needs to be handled nicely in the verifier
+if (expectNoError || e.getMessage().indexOf( "Exit
code was non-zero") == -1) {
+throw e;
+}
+}
+
// If no error is expected make sure that error logs are
free
if ( expectNoError )
{
-
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: maven-changes-plugin questions
On 27 Dec 06, at 7:17 AM 27 Dec 06, Dennis Lundberg wrote: Hi I've been trying to get the changes plugin into a releasable state. But it has been going on for too long, I did however manage to get a 2.0-beta-2 out there. The main hurdle that I have seen is that the plugin does too much at the same time. This has also been seen on the user list where users migrating from Maven have had difficulties. So I'm in favor of splitting it up: - Rip out the JIRA code and replace it with Swizzle - Move announcing to its own plugin, or perhaps to /maven/release since you only announce when you release right? However I would not like to move the changes.xml parts to /maven/ release for a couple of reasons: - It you use a changes.xml file you use it constantly during development, not just when you're doing a release Sure, but when would you actually show it to anyone? I never really understood the changes.xml myself, as I don't want to keep things in an issue tracking system and changes.xml or is this for folks who don't employ an issue tracking system? - Keeping it in a maven-changes-plugin brings M1 and M2 more in sync than they were before, which eases migration pains. I would like to sink my teeth into the patch [1] from Denis Cabasson which introduces a Modello model for the changes.xml files. Let me know what I can help with... [1] http://jira.codehaus.org/browse/MCHANGES-47 Jason van Zyl wrote: Hi, Is anyone actually using this because I'd like to sync this up with the reporting we're doing for voting. The JIRA stuff in the changes plugin is now obsoleted by the Swizzle (it just kicks ass), and I would like to remove the mail sending stuff and put it in an announcement component and put in with the /maven/release stuff. I would also like to move the changes plugin over to /maven/ release stuff as it is in the release vein of things. Thanks, Jason. - 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: New User Registration problems
On 12/26/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: hehe, please file jira issue Done. This one is http://jira.codehaus.org/browse/CONTINUUM-1085, and most of 1082-1093 are related. -- Wendy
Re: maven-changes-plugin questions
Dennis Lundberg wrote: Hi I've been trying to get the changes plugin into a releasable state. But it has been going on for too long, I did however manage to get a 2.0-beta-2 out there. I just checked to see if there were any differences between 2.0-beta-2 and the current SVN trunk. The changes are limited to pom.xml and src/site/site.xml. The main hurdle that I have seen is that the plugin does too much at the same time. This has also been seen on the user list where users migrating from Maven have had difficulties. So I'm in favor of splitting it up: - Rip out the JIRA code and replace it with Swizzle - Move announcing to its own plugin, or perhaps to /maven/release since you only announce when you release right? However I would not like to move the changes.xml parts to /maven/release for a couple of reasons: - It you use a changes.xml file you use it constantly during development, not just when you're doing a release - Keeping it in a maven-changes-plugin brings M1 and M2 more in sync than they were before, which eases migration pains. I would like to sink my teeth into the patch [1] from Denis Cabasson which introduces a Modello model for the changes.xml files. Let me know what I can help with... [1] http://jira.codehaus.org/browse/MCHANGES-47 Jason van Zyl wrote: Hi, Is anyone actually using this because I'd like to sync this up with the reporting we're doing for voting. The JIRA stuff in the changes plugin is now obsoleted by the Swizzle (it just kicks ass), and I would like to remove the mail sending stuff and put it in an announcement component and put in with the /maven/release stuff. I would also like to move the changes plugin over to /maven/release stuff as it is in the release vein of things. Thanks, Jason. - 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: maven-changes-plugin questions
Hi I've been trying to get the changes plugin into a releasable state. But it has been going on for too long, I did however manage to get a 2.0-beta-2 out there. The main hurdle that I have seen is that the plugin does too much at the same time. This has also been seen on the user list where users migrating from Maven have had difficulties. So I'm in favor of splitting it up: - Rip out the JIRA code and replace it with Swizzle - Move announcing to its own plugin, or perhaps to /maven/release since you only announce when you release right? However I would not like to move the changes.xml parts to /maven/release for a couple of reasons: - It you use a changes.xml file you use it constantly during development, not just when you're doing a release - Keeping it in a maven-changes-plugin brings M1 and M2 more in sync than they were before, which eases migration pains. I would like to sink my teeth into the patch [1] from Denis Cabasson which introduces a Modello model for the changes.xml files. Let me know what I can help with... [1] http://jira.codehaus.org/browse/MCHANGES-47 Jason van Zyl wrote: Hi, Is anyone actually using this because I'd like to sync this up with the reporting we're doing for voting. The JIRA stuff in the changes plugin is now obsoleted by the Swizzle (it just kicks ass), and I would like to remove the mail sending stuff and put it in an announcement component and put in with the /maven/release stuff. I would also like to move the changes plugin over to /maven/release stuff as it is in the release vein of things. Thanks, Jason. - 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: svn commit: r490479 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
Jason,
The ear ITs are now fixed on linux. It's what I thought (the process
exit code being different on linux and Windows).
I have applied a little hack, let's make sure we fix this in the
verifier directly.
Cheers,
Stpéhane
On 12/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: snicoll
Date: Wed Dec 27 03:12:04 2006
New Revision: 490479
URL: http://svn.apache.org/viewvc?view=rev&rev=490479
Log:
Fixed test failure on linux and macOSx when the build is expected to fail.
Modified:
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
Modified:
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java?view=diff&rev=490479&r1=490478&r2=490479
==
---
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
(original)
+++
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/AbstractEarPluginTestCase.java
Wed Dec 27 03:12:04 2006
@@ -21,6 +21,7 @@
import junit.framework.TestCase;
import org.apache.maven.it.Verifier;
+import org.apache.maven.it.VerificationException;
import org.apache.maven.it.util.ResourceExtractor;
import org.custommonkey.xmlunit.XMLAssert;
@@ -76,7 +77,20 @@
// Let's add alternate settings.xml setting so that the latest
dependencies are used
verifier.getCliOptions().add( "-s " + settingsFile.getAbsolutePath() );
verifier.localRepo = localRepositoryDir.getAbsolutePath();
-verifier.executeGoal( "package" );
+
+// On linux and macOSX, an exception is thrown if a build failure
occurs underneath
+try
+{
+verifier.executeGoal( "package" );
+}
+catch ( VerificationException e )
+{
+//@TODO needs to be handled nicely in the verifier
+if (expectNoError || e.getMessage().indexOf( "Exit code was
non-zero") == -1) {
+throw e;
+}
+}
+
// If no error is expected make sure that error logs are free
if ( expectNoError )
{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
weird error
Hey, I was about to start working on an issue on my linux box and the idea:module goal was unavailable. Then I executed maven with the -U flag and it suddently downloaded a released version of the plugin. How come it was not downloaded by default? See below [EMAIL PROTECTED] maven-ear-plugin]$ mvn idea:module [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'idea'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Required goal not found: idea:module [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Dec 27 11:53:48 CET 2006 [INFO] Final Memory: 1M/3M [INFO] [EMAIL PROTECTED] maven-ear-plugin]$ mvn -U idea:module [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'idea'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-idea-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.jar 37K downloaded [INFO] [INFO] Building Maven Ear plugin [INFO]task-segment: [idea:module] [INFO] [INFO] Preparing idea:module [INFO] No goals needed for project - skipping Downloading: http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.pom 365b downloaded Downloading: http://repo1.maven.org/maven2/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar 106K downloaded Downloading: http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar 306K downloaded [INFO] [idea:module] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Wed Dec 27 11:54:04 CET 2006 [INFO] Final Memory: 4M/7M [INFO] [EMAIL PROTECTED] maven-ear-plugin]$ Thanks, Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse and EAR plugins
I have reproduced the EAR test issue on fedora. I am working on it. Cheers, Stéphane On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Guys, I just did a clean install of CentOS (redhat linux), a fresh download of 2.0.4, no existing local repository, with java 1.5 and I get failures in both the EAR and Eclipse plugins. Do you both happen to use Windows? As the failures occur on my OS/X box and my Linux VM (running Parallels). So I think you have some problems to track down before the release can happen. http://people.apache.org/~jvanzyl/eclipse-plugin-surefire-reports- redhat.tgz http://people.apache.org/~jvanzyl/ear-plugin-surefire-reports-redhat.zip Thanks, Jason. - 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: maven-changes-plugin questions
Definitely +1 Stéphane On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, Is anyone actually using this because I'd like to sync this up with the reporting we're doing for voting. The JIRA stuff in the changes plugin is now obsoleted by the Swizzle (it just kicks ass), and I would like to remove the mail sending stuff and put it in an announcement component and put in with the /maven/release stuff. I would also like to move the changes plugin over to /maven/release stuff as it is in the release vein of things. Thanks, Jason. - 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: [vote] Release maven-deploy-plugin version 2.3
+1 Stéphane On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Ok, headers updated. This release contains the changes required for deploying to staging repositories. So I would like to release this so that I can remove the SNAPSHOT from the profile that will be used for release staging. Revision: 490414 Roadmap: http://jira.codehaus.org/browse/MDEPLOY? report=com.atlassian.jira.plugin.system.project:roadmap-panel Thanks, Jason. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse and EAR plugins
I will reboot on Fedora and see what's going on. Cheers, Stéphane On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Guys, I just did a clean install of CentOS (redhat linux), a fresh download of 2.0.4, no existing local repository, with java 1.5 and I get failures in both the EAR and Eclipse plugins. Do you both happen to use Windows? As the failures occur on my OS/X box and my Linux VM (running Parallels). So I think you have some problems to track down before the release can happen. http://people.apache.org/~jvanzyl/eclipse-plugin-surefire-reports- redhat.tgz http://people.apache.org/~jvanzyl/ear-plugin-surefire-reports-redhat.zip Thanks, Jason. - 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: Eclipse and EAR plugins
Hi Jason, from what I can see in the log the only error for the eclipse plugin is the same we saw before: "Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-eclipse-plugin:test:eclipse." Another thing I see in the log is that an old version of the eclipse plugin is downloaded for some of the tests. I guess this is the reason why you get that failure: the only test which is failing is the one where the plugin gets downloaded and you find in the log "Reloading plugin container for: org.apache.maven.plugins:maven-eclipse-plugin. The plugin artifact has changed", other tests work properly. Everything works fine for me on windows, and anyway this is surely a problem with the test framework and not the plugin itself. Given that we already know that tests needs to be refactored and cleaned up, I would prefer to go on with this release as is before starting such refactoring (could be a long task, I don't want to delay the release again). So, WDYT about ignoring/disabling failing tests and push this one out before reworking the test framework? Since this appears to be a difficult release on your environment I could take care of releasing it directly, as said tests work fine here... fabrizio On 12/27/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: Guys, I just did a clean install of CentOS (redhat linux), a fresh download of 2.0.4, no existing local repository, with java 1.5 and I get failures in both the EAR and Eclipse plugins. Do you both happen to use Windows? As the failures occur on my OS/X box and my Linux VM (running Parallels). So I think you have some problems to track down before the release can happen. http://people.apache.org/~jvanzyl/eclipse-plugin-surefire-reports- redhat.tgz http://people.apache.org/~jvanzyl/ear-plugin-surefire-reports-redhat.zip Thanks, Jason. - 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: short term branch for project/group keys
Store updates: I am taking a stab at refactoring the current ContinuumStore into RefactoredContinuumStore as a p-o-c for a couple of things. 1) Idea basically is that the Store interface should provide (lookup, save and delete) operations on key 'application' entities. I gather these are o Project o ProjectGroup o Schedule o Profile o Installation o SystemConfiguration Updates to any children hanging off key entities should cascade. So, something like: addBuildDefinitionToProject addBuildDefintionToGroup could be done like: project.addBuildDefintion(updatedBuildDefintion); store.saveProject(project); and, group.addBuildDefinition(updatedBuildDefinition); store.saveProjectGroup(group); 2) Another thing that Jesse mentioned in his email about breaking up Continuum interface into two or three - I am thinking perhaps it might be an idea to break up the ContinuumStore into as many as well and have one-to-one mapping between store and corresponding continuum interfaces. So, possibly oProjectStore (all project related operations) oGroupStore (all group related operations) oSystemStore (all top level operations - fetch all projects, groups. Operations on Schedules, profiles etc) The names above are just indicative, we can change them later :-) Thoughts? Cheers, Rahul - Original Message - From: "Jesse McConnell" <[EMAIL PROTECTED]> To: Sent: Wednesday, December 27, 2006 10:28 AM Subject: Re: short term branch for project/group keys rahul and I have been talking on skype some working out some of the details of this key refactor and we see an opportunity to do a few things that might make life better for continuum. He is going to mail soon on some things that we are wanting to do in the store and this mail is one something to do with the DefaultContinuum object itself. I am thinking of breaking up the Continuum interface into two objects (perhaps three) interfaces that have more targeted purposes. Looking through the Continuum interface right now it has largely three purposes. 1) top lvl actions (getting all projects, building all projects, firing off adding of groups based on metadata, etc) 2) group actions (adding notifiers to groups, build definitions, etc) 3) project actions (adding notifiers to projects, build definitions, etc) In many methods for 2 and 3 the continuum instance is just acting as a facade over the store api doing lots of pass through function calls. Some places in continuum project shun the use of the Continuum interface for these things and just use the store api directly having plexus inject the ContinuumStore instance into the components. If you look at the Continuum interface as it stands right now there are a number methods like addBuildDefinition <- deprecated addBuildDefinitionToProject addBuildDefintionToGroup Rahul is going to mail on how this can be cleaned up in the store api, but I question why we want these methods on the Continuum interface at all? My thought at the moment is to take methods like 'getBuildDefinitionForGroup' and move those to an interface for group related actions that can't be directly on the ProjectGroup model class. Then perhaps do the same for the 'getBuildDefinitionForProject' type methods. This would solidify the focus of the Continuum interface to be a lookup for particular project group's and project's as well as top lvl continuum functionalities like building all projects using the ProjectSorter, etc. The we would have a ContinuumGroup and ContinuumProject interface and impl that could act as facade's over the model classes and some of the other logic oriented methods that are currently in the Continuum interface. thoughts? rahul and I are pretty happy with the way it sounds atm jesse -- jesse mcconnell [EMAIL PROTECTED]
