RE: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies
I think it's also necessary to allow control over the ordering of the overlay. Otherwise it's kinda random based on the way the dependencies are resolved isn't it? -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 1:56 PM To: [EMAIL PROTECTED] Cc: dev@maven.apache.org Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies Just some thoughts on enhancements: It'd be nice if we could 1) get this into the war plugin and 2) add 3 different modes: 1. Default - the way things are now, where dependencies aren't inherited. This would allow backwards compatibility and not suprise anyone. 2. Include Dependencies - excludes everything from WEB-INF/lib and includes all dependencies - making them available to all plugins as well (i.e. esp. IDEA, Eclipse and NetBeans). 3. Merge - has a way of allowing web.xml and other configuration files to be merged. Of course, it'd need certain include and exclude patterns. With #3, it may be possible to produce some sort of wars-as-plugins features where you could develop a small set of functionality and merge it into a larger application. This seems like a pretty simple way to do plugins. Of course, you'd probably have to create a pretty fancy XML parser/merger/munger. Thoughts? What are the chances of getting this plugin included in the war plugin? Matt On 11/11/06, Michael Horwitz [EMAIL PROTECTED] wrote: Hi, I have been helping out with the development of the AppFuse project over the last month where we make heavy use of the war overlay feature in the Maven war plugin. It is a really nifty feature! To get max power with war overlays I have developed the Warpath plugin that allows projects to use war artifacts as fully fledged dependencies. In brief: 1) The contents of the /WEB-INF/classes directory in the war dependency artifacts can be included in the project's classpath for normal compile, etc tasks. 2) Transitive dependencies from the war dependency artifacts become available for use by other plugins, e.g. compile and ear - so no more having to include all the dependencies when creating skinny wars! The plugin has now been actively used in the AppFuse project for the last few months, and I feel it is at a point where it is both usable and stable. Would the war plugin team be interested in including the warpath functionality inside the war plugin? It would seem to be the most natural place to host it. As a side issue one sticking point for us with war overlays has been the overlay by timestamp for files included in the web project being built. In a multi-web module project like AppFuse this has led to some unpredictable behaviour when a file from a dependent war overwrites a file in the war project being built. Although it is possible to influence the behaviour of the overlay using dependentWarExcludes, it is a maintenance heavy approach when many files are involved and requires continual updates to the project's pom file. Would it be possible to include functionality, perhaps as a configurable feature, in the Maven war plugin to automatically prefer all files from the war project being built over those from dependent war files regardless of file timestamp? I would be more than happy to do the necessary work and submit a patch. Thanks Mike Horwitz -- http://raibledesigns.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: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies
It would be nice! In AppFuse only one war is ever overlayed. I am guessing here, but would imagine that projects that overlay more than one war will be pretty rare. For AppFuse it would be sufficient to prioritise the local files over those coming in from the overlay, which is a good deal simpler than overlay ordering? Does anyone have a specific need to overlay more than one war dependency? On 11/15/06, Brian E. Fox [EMAIL PROTECTED] wrote: I think it's also necessary to allow control over the ordering of the overlay. Otherwise it's kinda random based on the way the dependencies are resolved isn't it? -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 1:56 PM To: [EMAIL PROTECTED] Cc: dev@maven.apache.org Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies Just some thoughts on enhancements: It'd be nice if we could 1) get this into the war plugin and 2) add 3 different modes: 1. Default - the way things are now, where dependencies aren't inherited. This would allow backwards compatibility and not suprise anyone. 2. Include Dependencies - excludes everything from WEB-INF/lib and includes all dependencies - making them available to all plugins as well (i.e. esp. IDEA, Eclipse and NetBeans). 3. Merge - has a way of allowing web.xml and other configuration files to be merged. Of course, it'd need certain include and exclude patterns. With #3, it may be possible to produce some sort of wars-as-plugins features where you could develop a small set of functionality and merge it into a larger application. This seems like a pretty simple way to do plugins. Of course, you'd probably have to create a pretty fancy XML parser/merger/munger. Thoughts? What are the chances of getting this plugin included in the war plugin? Matt On 11/11/06, Michael Horwitz [EMAIL PROTECTED] wrote: Hi, I have been helping out with the development of the AppFuse project over the last month where we make heavy use of the war overlay feature in the Maven war plugin. It is a really nifty feature! To get max power with war overlays I have developed the Warpath plugin that allows projects to use war artifacts as fully fledged dependencies. In brief: 1) The contents of the /WEB-INF/classes directory in the war dependency artifacts can be included in the project's classpath for normal compile, etc tasks. 2) Transitive dependencies from the war dependency artifacts become available for use by other plugins, e.g. compile and ear - so no more having to include all the dependencies when creating skinny wars! The plugin has now been actively used in the AppFuse project for the last few months, and I feel it is at a point where it is both usable and stable. Would the war plugin team be interested in including the warpath functionality inside the war plugin? It would seem to be the most natural place to host it. As a side issue one sticking point for us with war overlays has been the overlay by timestamp for files included in the web project being built. In a multi-web module project like AppFuse this has led to some unpredictable behaviour when a file from a dependent war overwrites a file in the war project being built. Although it is possible to influence the behaviour of the overlay using dependentWarExcludes, it is a maintenance heavy approach when many files are involved and requires continual updates to the project's pom file. Would it be possible to include functionality, perhaps as a configurable feature, in the Maven war plugin to automatically prefer all files from the war project being built over those from dependent war files regardless of file timestamp? I would be more than happy to do the necessary work and submit a patch. Thanks Mike Horwitz -- http://raibledesigns.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: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies
We do it quite extensively now. The problem is that I'm now dependent on an alpha war plugin that doesn't have the timestamp logic. I use the dependency:unpack goal to unpack the artifacts in a known order (to control order of inheritence) into the war folder before the war plugin starts. Then the war plugin will copy files over so local files always win. We have our code architected such that there is a common ui template that every war inherits. Then we may have several ui modules that can be reassembled into a final war package. (not always 1:1, sometimes a UI can be included in several packages and all assemblies almost always have multiple Uis). For unit testing purposes, all the ui's including the common template are deployable standalone. When I build the war in each of these modules, I actually build 2: I normal one for standalone deployment, and one reusable one that doesn't contain the jars. The problem is that since maven won't transitively inherit the war's dependencies, we manually have to make sure that the assembly project has all the direct dependencies copied from each of the UI poms. -Original Message- From: Michael Horwitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 9:31 AM To: Maven Developers List Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies It would be nice! In AppFuse only one war is ever overlayed. I am guessing here, but would imagine that projects that overlay more than one war will be pretty rare. For AppFuse it would be sufficient to prioritise the local files over those coming in from the overlay, which is a good deal simpler than overlay ordering? Does anyone have a specific need to overlay more than one war dependency? On 11/15/06, Brian E. Fox [EMAIL PROTECTED] wrote: I think it's also necessary to allow control over the ordering of the overlay. Otherwise it's kinda random based on the way the dependencies are resolved isn't it? -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 1:56 PM To: [EMAIL PROTECTED] Cc: dev@maven.apache.org Subject: Re: [appfuse-dev] War plugin overlays: New plugin to handle transitive dependencies Just some thoughts on enhancements: It'd be nice if we could 1) get this into the war plugin and 2) add 3 different modes: 1. Default - the way things are now, where dependencies aren't inherited. This would allow backwards compatibility and not suprise anyone. 2. Include Dependencies - excludes everything from WEB-INF/lib and includes all dependencies - making them available to all plugins as well (i.e. esp. IDEA, Eclipse and NetBeans). 3. Merge - has a way of allowing web.xml and other configuration files to be merged. Of course, it'd need certain include and exclude patterns. With #3, it may be possible to produce some sort of wars-as-plugins features where you could develop a small set of functionality and merge it into a larger application. This seems like a pretty simple way to do plugins. Of course, you'd probably have to create a pretty fancy XML parser/merger/munger. Thoughts? What are the chances of getting this plugin included in the war plugin? Matt On 11/11/06, Michael Horwitz [EMAIL PROTECTED] wrote: Hi, I have been helping out with the development of the AppFuse project over the last month where we make heavy use of the war overlay feature in the Maven war plugin. It is a really nifty feature! To get max power with war overlays I have developed the Warpath plugin that allows projects to use war artifacts as fully fledged dependencies. In brief: 1) The contents of the /WEB-INF/classes directory in the war dependency artifacts can be included in the project's classpath for normal compile, etc tasks. 2) Transitive dependencies from the war dependency artifacts become available for use by other plugins, e.g. compile and ear - so no more having to include all the dependencies when creating skinny wars! The plugin has now been actively used in the AppFuse project for the last few months, and I feel it is at a point where it is both usable and stable. Would the war plugin team be interested in including the warpath functionality inside the war plugin? It would seem to be the most natural place to host it. As a side issue one sticking point for us with war overlays has been the overlay by timestamp for files included in the web project being built. In a multi-web module project like AppFuse this has led to some unpredictable behaviour when a file from a dependent war overwrites a file in the war project being built. Although it is possible to influence the behaviour of the overlay using dependentWarExcludes, it is a maintenance heavy approach when many files are involved and requires continual updates to the project's pom
Closing bugs [was Re: siteDirectory and site.xml]
Dennis Lundberg wrote: Graham Leggett wrote: Dennis Lundberg wrote: [MSITE-91] There has not been any official release of the site-plugin yet, that incorporates this fix. You can build the plugin yourself from source, by downloading it from SVN. Then you just run mvn install. You alse need to bump the version number for the site-plugin in your pom to 2.0-SNAPSHOT. Is there any chance of a release soon? The bug was fixed in April/May, and it's now November :( Are there any showstoppers outstanding on this plugin? Regards, Graham The bug was fixed this weekend :) So, no it hasn't been released yet. Just my opinion here, but it seems wrong to 'close' a bug when there's no release on the horizon, because: (a) it might be closed to you, but if the fix depends on maven 2.1 it's as good as useless to real-world users. I think that you're not giving an accurate representation of the quality of the current release version (and hence the urgency of a release) by closing bugs as soon as the fix is committed to svn. (b) if I see a bug, I want to be able to search jira for it, whether it's going to be fixed in the next release or not. You need a distinction between bugs which were fixed before the current release, and those which will only be fixed in the next release. Isn't this what Status: Resolved is for? -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Error: building 2.0.5 from guide-building-m2.html
On 11/14/06, McNaught, Duncan [EMAIL PROTECTED] wrote: I'm building mvn 2.0.5 for the fix: http://jira.codehaus.org/browse/MNG-1908 I'm following the instructions at http://maven.apache.org/guides/development/guide-building-m2.html Duncan, the instructions for building the 2.0 branch have been updated. Please take a look and comment here or on MNG-2620 if you see anything that needs to be fixed. Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to include custom reports from pom packaging
I have a custom reporting plugin. It generates a surefire-report for projects whose packaging is set to pom. (sort of a custom aggregator). I want it's reports to be generated and included along with the other Project Reports when I run 'mvn site'. I tried putting the plugin in reporting section but in vain. I used the @execute phase=site in the Mojo that extends AbstractMavenReport. It goes into a endless loop [INFO] Preparing geronimo:generate-surefire-report [INFO] Preparing geronimo:generate-surefire-report ... Can someone please advise me as to how I can achieve this ? Thanx Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build Error: building 2.0.5 from guide-building-m2.html
Wendy, Thanks for updating that page. I followed the instructions and it produced the binary distribution with no problems. I'm still not getting the propget command to work (svn propget svn:externals) - it just returns blank. Do I need to change my svn preferences, or run it from somewhere other than maven-2.0.x? Thanks --Duncan From Wendy Smoak [EMAIL PROTECTED] Subject Re: Build Error: building 2.0.5 from guide-building-m2.html Date Wed, 15 Nov 2006 17:01:12 GMT On 11/14/06, McNaught, Duncan [EMAIL PROTECTED] wrote: I'm building mvn 2.0.5 for the fix: http://jira.codehaus.org/browse/MNG-1908 I'm following the instructions at http://maven.apache.org/guides/development/guide-building-m2.html Duncan, the instructions for building the 2.0 branch have been updated. Please take a look and comment here or on MNG-2620 if you see anything that needs to be fixed. Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Intuit Eclipse SCM 303 938 8801x1139
Re: Build Error: building 2.0.5 from guide-building-m2.html
On 11/15/06, McNaught, Duncan [EMAIL PROTECTED] wrote: I'm still not getting the propget command to work (svn propget svn:externals) - it just returns blank. Do I need to change my svn preferences, or run it from somewhere other than maven-2.0.x? It's working; there are no externals defined on the maven-2.0.x directory. (And that's not a required step, it's just informational.) I'll re-write that section -- It's related to checking out this url: http://svn.apache.org/repos/asf/maven/trunks/ It looks empty, but if you check it out, you'll get the trunk of each Maven sub-projects, plus the 2.0.x branch. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about release of Release
We are currently facing this problem : -we have about 50 modules with various level of dependencies -developers need to work using module SNAPSHOTs - the release plugin requires RELEASE dependencies - we really cannot modify every pom by hand at every change So we decided to use version ranges, and that works like a charm (almost). In order to have truly repeatable builds with version ranges we really need the generateReleasePoms working... Do you have any other suggestion? Are we mistaking the way maven should be used? Thanks in advance, Gabriele Brett Porter wrote: Yikes, I'm getting forgetful in my old age. I thought the section on that had been omitted from the final version of the book until it was implemented. Since we are no longer allowing changes to metadata in the repository (unless it is an extreme case), then repeatability shouldn't be a problem (notwithstanding bugs in the dependency mechanism which will effect it either way), unless you are using version ranges (which to date, haven't been popularly adopted because of the way they have been implemented). The main culprit is plugin versions, so populating those would be the most effective thing to do. It was my intention to review this overall with Maven 2.1 rather than slap this back onto the release plugin as it didn't have the full desired effect as is. - Brett On 08/11/2006, at 6:48 AM, Matthew Beermann wrote: (I asked this once before, but the thread got hijacked into other matters, so let's try this again...) Will the next release of the Release plugin include the generateReleasePoms functionality, e.g. the creation of a POM with resolved versions? If you were to believe Better Builds with Maven (p224), this functionality exists already, except it doesn't actually seem to. There doesn't seem to be a JIRA issue that tracks this, at least that I was able to find. Nor is it entirely clear from the current source code in Subversion - lots of commented-out code with TODOs. This is key for us, and soon, as it helps to enable truly repeatable builds. Thanks for the help, --Matthew Beermann - 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: Question about release of Release
On 15/11/06, Gabriele Contini [EMAIL PROTECTED] wrote: We are currently facing this problem : -we have about 50 modules with various level of dependencies -developers need to work using module SNAPSHOTs - the release plugin requires RELEASE dependencies - we really cannot modify every pom by hand at every change So we decided to use version ranges, and that works like a charm (almost). In order to have truly repeatable builds with version ranges we really need the generateReleasePoms working... Do you have any other suggestion? Are we mistaking the way maven should be used? We have similar problems here and have considered using version ranges, but was unaware of the generateReleasePoms option. See my posting on similar thread here: http://www.mail-archive.com/users@maven.apache.org/msg54759.html Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Closing bugs [was Re: siteDirectory and site.xml]
Richard van der Hoff wrote: Dennis Lundberg wrote: Graham Leggett wrote: Dennis Lundberg wrote: [MSITE-91] There has not been any official release of the site-plugin yet, that incorporates this fix. You can build the plugin yourself from source, by downloading it from SVN. Then you just run mvn install. You alse need to bump the version number for the site-plugin in your pom to 2.0-SNAPSHOT. Is there any chance of a release soon? The bug was fixed in April/May, and it's now November :( Are there any showstoppers outstanding on this plugin? Regards, Graham The bug was fixed this weekend :) So, no it hasn't been released yet. Just my opinion here, but it seems wrong to 'close' a bug when there's no release on the horizon, because: Thanks for your input Richard. (a) it might be closed to you, but if the fix depends on maven 2.1 it's as good as useless to real-world users. I think that you're not giving an accurate representation of the quality of the current release version (and hence the urgency of a release) by closing bugs as soon as the fix is committed to svn. The fix that was made is in itself not dependent on Maven 2.1, but other changes have been made to the site plugin that has created such a dependency. (b) if I see a bug, I want to be able to search jira for it, whether it's going to be fixed in the next release or not. You need a distinction between bugs which were fixed before the current release, and those which will only be fixed in the next release. You can search for unresolved as well as closed issues in JIRA. JIRA also has two version fields that helps to understand which versions an issued affects and in which version it was or will be solved. They are called Affects Version/s and Fix Version/s Regarding MSITE-91 it has Affects Version/s set to 2.0-beta-4 and Fix Version/s is set to 2.0. A look at the road map give an overview of which issues goes into which version. Isn't this what Status: Resolved is for? Resolved can be used to indicate that the developers think that the issue is solved but that they want to get feedback from the reporter, before closing the issue. But this is of course a matter of taste. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Maven logo?
Hi, Wanted to just go ahead and introduce myself formally on the list. I've previously worked with some of the Maven team on the publishing of the Better Builds w/ Maven book, and with some of the logo development for Maven, Continuum and recently Archiva. So, I was wondering if anyone else is interested in promoting a Built by/Powered by kind of program, like the one that Sun has here: http://logos.sun.com/logosite.jsp?Category=third -- of course, the simpler/easier the better for other projects the better, but we'd need to start it off with some basics, like logos for instance ;) If so, I would love to help out in this effort as I think it would be a plus for the Maven community overall, given that so many projects now build on M2, like http://db.apache.org/ http://directory.apache.org/ http://jackrabbit.apache.org/ http://maven.apache.org/ http://myfaces.apache.org/ http://shale.apache.org/ http://struts.apache.org/. and of course Maven itself... Alexandre Poitras wrote: Is there a maven logo out there, I mean different from the tradionnal apache feather? Would be very nice to have one, especially with the popularity Maven 2.0 is enjoying. -- Alexandre Poitras Québec, Canada -- View this message in context: http://www.nabble.com/-M2--Maven-logo--tf528936s177.html#a7365447 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
issue MWAR-9 and PLX-158
It exists an issue for the war plugin (MWAR-9) that seems to depend on PLX-158. As we are stuck with those issues could someone help on this? Do you know if it could be solve with maven 2.0.5? FYI there are 34 votes for issue MWAR-9 Thanks Yann. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
patch for surefire plugin to make it more Eclipse-friendly
hello there,
the attached patch checks first if the 'test' env-var value ends with
.java or not before constructing the reg-exp for single/specific
tests.
with this patch, Eclipse users can select a test and run one external
tool similar to the following:
?xml version=1.0 encoding=UTF-8?
launchConfiguration type=org.maven.ide.eclipse.Maven2LaunchConfigurationType
listAttribute key=M2_PROPERTIES
listEntry value=test=${resource_name}/
/listAttribute
stringAttribute key=M2_GOALS value=test/
stringAttribute key=org.eclipse.debug.core.ATTR_REFRESH_SCOPE
value=${project}/
listAttribute key=org.eclipse.debug.ui.favoriteGroups
listEntry value=org.eclipse.ui.externaltools.launchGroup/
/listAttribute
stringAttribute key=org.eclipse.jdt.launching.WORKING_DIRECTORY
value=${workspace_loc:/xxx/
/launchConfiguration
cheers;
rsn
Index:
/export/home/workspace/maven-plugins/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
===
---
/export/home/workspace/maven-plugins/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
(revision 475119)
+++
/export/home/workspace/maven-plugins/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
(working copy)
@@ -520,7 +520,8 @@
// Check to see if we are running a single test. The raw
parameter will
// come through if it has not been set.
-// FooTest - **/FooTest.java
+// FooTest - **/FooTest.java
+// FooTest.java - **/FooTest.java
includes = new ArrayList();
@@ -530,7 +531,10 @@
for ( int i = 0; i testRegexes.length; i++ )
{
-includes.add( **/ + testRegexes[i] + .java );
+if ( testRegexes[i].endsWith( .java ) )
+ includes.add( **/ + testRegexes[i] );
+else
+ includes.add( **/ + testRegexes[i] + .java );
}
}
else
pgpbVzXSgjmee.pgp
Description: PGP signature
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (34 issues) Subscriber: mavendevlist Key Summary MEV-459 Velocity should not depend on Velocity-dep http://jira.codehaus.org/browse/MEV-459 MEV-451 pom for xmlbeans:xbean:2.2 http://jira.codehaus.org/browse/MEV-451 MEV-457 Geronimo jar fails to download http://jira.codehaus.org/browse/MEV-457 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-443 Several projects have maven-metadata.xml files that are missing released versions http://jira.codehaus.org/browse/MEV-443 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-427 relocate ehcache:ehcache to net.sf.ehcache http://jira.codehaus.org/browse/MEV-427 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-375 Relocate xpp to xpp3 http://jira.codehaus.org/browse/MEV-375 MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit) http://jira.codehaus.org/browse/MEV-364 MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib http://jira.codehaus.org/browse/MEV-352 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-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 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]
[jira] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (40 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1235XOM 1.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1235 MAVENUPLOAD-1234Please upload EZMorph-0.9 http://jira.codehaus.org/browse/MAVENUPLOAD-1234 MAVENUPLOAD-1233Upload hibernate-entitymanager-3.2.0.cr2 http://jira.codehaus.org/browse/MAVENUPLOAD-1233 MAVENUPLOAD-1232Upload backport-util-concurrent-3.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1232 MAVENUPLOAD-1228Request for maven sync with m2.modularity.net.au http://jira.codehaus.org/browse/MAVENUPLOAD-1228 MAVENUPLOAD-1231Please upload qalab-1.0 and Maven 1 and Maven 2 plugins http://jira.codehaus.org/browse/MAVENUPLOAD-1231 MAVENUPLOAD-1225Upload Stripes 1.4.2 to IBiblio repository (please) http://jira.codehaus.org/browse/MAVENUPLOAD-1225 MAVENUPLOAD-1230Upload Joda-Time 1.4 http://jira.codehaus.org/browse/MAVENUPLOAD-1230 MAVENUPLOAD-1229Upload net.sf.oval-0.7 http://jira.codehaus.org/browse/MAVENUPLOAD-1229 MAVENUPLOAD-1209openArchitectureWare plugin for Maven 2 v1.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1209 MAVENUPLOAD-1227Upload EasyMock-PropertyUtils-1.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1227 MAVENUPLOAD-1205dtddoc-maven-plugin http://jira.codehaus.org/browse/MAVENUPLOAD-1205 MAVENUPLOAD-1226CLONE -synchronization script for org.slf4j http://jira.codehaus.org/browse/MAVENUPLOAD-1226 MAVENUPLOAD-1220Upload mx4j 3.0.2 http://jira.codehaus.org/browse/MAVENUPLOAD-1220 MAVENUPLOAD-1213HtmlUnit 1.10 upload request http://jira.codehaus.org/browse/MAVENUPLOAD-1213 MAVENUPLOAD-1214M2 StatCVS Plugin 3.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1214 MAVENUPLOAD-1178Upload Ajax4JSF 1.0.2 http://jira.codehaus.org/browse/MAVENUPLOAD-1178 MAVENUPLOAD-1143Upload Echo2 2.1.0.beta5 (corrected groupId) http://jira.codehaus.org/browse/MAVENUPLOAD-1143 MAVENUPLOAD-1161Maven XML Validation Plugin upload request http://jira.codehaus.org/browse/MAVENUPLOAD-1161 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-1144Upload Echo2-Extras 0.3 (corrected groupId) http://jira.codehaus.org/browse/MAVENUPLOAD-1144 MAVENUPLOAD-1104Elmo 3.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1104 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-1090Upload of Maven Docbkx Plugin http://jira.codehaus.org/browse/MAVENUPLOAD-1090 MAVENUPLOAD-1087Upload drools:drools-jsr94:3.0.4 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1087 MAVENUPLOAD-1059j2ssh (sshtools) 0.2.7 http://jira.codehaus.org/browse/MAVENUPLOAD-1059 MAVENUPLOAD-1055Please Upload Registry J2SE http://jira.codehaus.org/browse/MAVENUPLOAD-1055 MAVENUPLOAD-1060jstl-1.2.jar corrupt http://jira.codehaus.org/browse/MAVENUPLOAD-1060 MAVENUPLOAD-1056Please Upload Registry J2EE http://jira.codehaus.org/browse/MAVENUPLOAD-1056 MAVENUPLOAD-1033Please upload JBoss Cache Version 1.4.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1033 MAVENUPLOAD-1008Full bundle for xerces:dom3-xml-apis:1.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1008 MAVENUPLOAD-976Please upload SUN Java 1.2 rutime http://jira.codehaus.org/browse/MAVENUPLOAD-976 MAVENUPLOAD-789Tomcat 5.5.15 poms for existing jars http://jira.codehaus.org/browse/MAVENUPLOAD-789 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Closing bugs [was Re: siteDirectory and site.xml]
On 16/11/2006, at 3:25 AM, Richard van der Hoff wrote: Just my opinion here, but it seems wrong to 'close' a bug when there's no release on the horizon, because: (a) it might be closed to you, but if the fix depends on maven 2.1 it's as good as useless to real-world users. I think that you're not giving an accurate representation of the quality of the current release version (and hence the urgency of a release) by closing bugs as soon as the fix is committed to svn. The dependency on maven 2.1 is a flaw, it should be possible to release the plugin earlier than that. (b) if I see a bug, I want to be able to search jira for it, whether it's going to be fixed in the next release or not. You need a distinction between bugs which were fixed before the current release, and those which will only be fixed in the next release. By default, jira searches closed bugs too, so you can use the plugin version as your guide to availability. Obviously, we need to improve on timely releases, especially for plugins (and its a topic that has already been beaten to death here recently - we are certainly working on it, and open to suggestions on better tracking progress in general). Given this, I don't see any need to change the way we use the closed state or reintroduce the resolved workflow step. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for surefire plugin to make it more Eclipse-friendly
hello Brian, On Thursday 16 November 2006 10:30, Brian E. Fox wrote: Your best bet is to write an issue here: http://jira.codehaus.org/browse/MSUREFIRE and attach your patch. This way it won't get lost. done! http://jira.codehaus.org/browse/MSUREFIRE-180 thanks + cheers; rsn pgpF0CAOwQcou.pgp Description: PGP signature
Re: Publishing schemas
On 11/3/06, Brett Porter [EMAIL PROTECTED] wrote: On 04/11/2006, at 1:29 AM, Wendy Smoak wrote: I found .../xsd after I wrote the original note. If that's the correct place, then we can remove the ones directly under /www/maven.apache.org and add links to the actual files in .../xsd. Sounds like a good idea. Redirects might be better too. My only concern with redirects is whether validating editors (like JEdit) will be able to follow them. If so I'd agree that a permanent redirect would be better. What about filename conventions? Only 'maven' uses the v-and-underscores bit, (maven-v4_0_0.xsd) everything else is 'as generated', such as settings-1.0.0.xsd . I prefer the latter. Okay, I updated the instructions again http://docs.codehaus.org/display/MAVEN/Development+Procedures and published the v4 schema to http://maven.apache.org/xsd/maven-4.0.0.xsd If this is to be the official location and filename, we should change the Maven poms and examples. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New tools for testing (mostly integration-testing) Maven plugins
Hi everyone, I wanted to take a second and direct your attention to a new library I'm working on in the Maven sandbox. I'm calling it maven-plugin-test-tools, and it's meant to make the process of integration-testing a Maven plugin much simpler, using test builds. This idea has been implemented in a variety of ways in the recent past - actually going back quite some time in the maven-eclipse-plugin - but I'm attempting to learn from the quirks and oddities in each attempt, and come up with a single API that developers will find convenient for conducting these types of tests. I've modified the tests in the maven-eclipse-plugin (okay, they're currently *unit* tests, but we can fix that) to use this new library, so you can use the AbstractEclipsePluginTest as an example. Also, I've put together some documentation on the testing library in the form of a main index APT that describes the approach, and a set of relatively complete JavaDocs for each specific testing tool...they're here: http://people.apache.org/~jdcasey/maven-plugin-test-tool If any of you have time to review this site (and maybe the source and eclipse plugin example usage) and provide feedback or ideas, I'd really love to hear from you. I think it's absolutely critical to get plugin testing under control, and provide some standardized mechanisms to make the lives of plugin developers simpler. I'd like to keep fleshing this library out, and start converting more of the existing plugins in Maven's SVN to use this testing approach (along with a more well-suited approach to unit testing, perhaps using EasyMock). WDYT? Thanks, John
Re: New tools for testing (mostly integration-testing) Maven plugins
Sorry, that URL is: http://people.apache.org/~jdcasey/maven-plugin-test-tools (Hopefully I didn't just fat-finger that twice in 5 minutes... :-) -j On 11/16/06, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to take a second and direct your attention to a new library I'm working on in the Maven sandbox. I'm calling it maven-plugin-test-tools, and it's meant to make the process of integration-testing a Maven pluginmuch simpler, using test builds. This idea has been implemented in a variety of ways in the recent past - actually going back quite some time in the maven-eclipse-plugin - but I'm attempting to learn from the quirks and oddities in each attempt, and come up with a single API that developers will find convenient for conducting these types of tests. I've modified the tests in the maven-eclipse-plugin (okay, they're currently *unit* tests, but we can fix that) to use this new library, so you can use the AbstractEclipsePluginTest as an example. Also, I've put together some documentation on the testing library in the form of a main index APT that describes the approach, and a set of relatively complete JavaDocs for each specific testing tool...they're here: http://people.apache.org/~jdcasey/maven-plugin-test-toolhttp://people.apache.org/%7Ejdcasey/maven-plugin-test-tool If any of you have time to review this site (and maybe the source and eclipse plugin example usage) and provide feedback or ideas, I'd really love to hear from you. I think it's absolutely critical to get plugin testing under control, and provide some standardized mechanisms to make the lives of plugin developers simpler. I'd like to keep fleshing this library out, and start converting more of the existing plugins in Maven's SVN to use this testing approach (along with a more well-suited approach to unit testing, perhaps using EasyMock). WDYT? Thanks, John
Re: [REPOST] Maven2 repo : m1 plugins with .plugin extension !?
I'd like to create an MPA issue for this, but there's no MPA choice on JIRA create issue page. Is this jira category only for maven developer use ? Could you please enter an issue for me ? Nico. Nicolas DE LOOF a écrit : Got no reply to solve this issue : On maven2 public repository, maven (m1) plugins are packaged with .plugin extension : - http://repo1.maven.org/maven2/maven/maven-changelog-plugin/1.9.1 This was not the case some weeks ago. Maven-on-plugin creates .jar. This sounds like a repo-converter bug. Can any commiter take a look at this please ! Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPOST] Maven2 repo : m1 plugins with .plugin extension !?
I think the code that does the conversion is now from archiva. Jason can confirm this On 11/16/06, Nicolas DE LOOF [EMAIL PROTECTED] wrote: I'd like to create an MPA issue for this, but there's no MPA choice on JIRA create issue page. Is this jira category only for maven developer use ? Could you please enter an issue for me ? Nico. Nicolas DE LOOF a écrit : Got no reply to solve this issue : On maven2 public repository, maven (m1) plugins are packaged with .plugin extension : - http://repo1.maven.org/maven2/maven/maven-changelog-plugin/1.9.1 This was not the case some weeks ago. Maven-on-plugin creates .jar. This sounds like a repo-converter bug. Can any commiter take a look at this please ! Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - 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]
