Re: svn commit: r448344 - in /maven/archiva/trunk/archiva-webapp/src/main: resources/META-INF/plexus/application.xml webapp/WEB-INF/
Replies are inline. Brett Porter wrote: > > On 21/09/2006, at 7:16 AM, [EMAIL PROTECTED] wrote: > >> + >> + >> +audit >> +DEBUG >> + > ... >> >> + >> + >> org.apache.maven.archiva.web.servlet.repository.RepositoryMapping >> >> +DEBUG, audit >> + > > Why DEBUG? No reason actually. Habit. I believe that class only logs at info level. We could bump it up to that. > >> +log >> +template > > Should these be cleaned too? I chose to only ignore the log directory, as those log files could prove useful, even in development. > > Also, I noticed a /template (as well as /WEB-INF/template), is that > meant to be cleaned too? Or is ti a dupe that isn't meant to be there? The template directory is showing up as part of a war overlay. I haven't bothered to track down where from (yet) - Joakim
RE: Review of maven-release-plugin documentation
Assuming the current version is a SNAPSHOT version, then it should remove the SNAPSHOT for the version to be released (and tagged), then it should increment the version and add SNAPSHOT again. I believe the increment increments the lowest non-zero value. When you're using an interactive command-line, it should ask what versions to release and put in the trunk and offers defaults based on what I just mentioned. For example, if the current version is 1.2-SNAPSHOT, then 1.2 is released and the trunk is left at 1.3-SNAPSHOT. If the version is 1.2.1-SNAPSHOT, then 1.2.1 is released and the trunk is left at 1.2.2-SNAPSHOT. You can test this by using the dryRun property and looking at the pom.xml.XXX files to see what it does. -Nathan > -Original Message- > From: Franz Allan Valencia See [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 20, 2006 9:31 PM > To: Maven Developers List > Subject: Re: Review of maven-release-plugin documentation > > Good day to you, John, > > I am not really sure myself, so I'll just forward the question from the > user's mailing list here (as a probable revision to the documentation). > > Does maven-release-plugin automatically increments the version number, or > does the user have to manually specify the version? This question came > from > this thread [1], specifically, this post [2]. > > Thanks, > Franz > > [1] http://www.nabble.com/forum/ViewPost.jtp?post=6382491&framed=y > [2] http://www.nabble.com/forum/ViewPost.jtp?post=6382907&framed=y > > On 9/18/06, John Tolentino <[EMAIL PROTECTED]> wrote: > > > > maven-release-plugin documentation is now ready for review. > > Staging site can be found here: > > > > http://people.apache.org/~jtolentino/maven-release-plugin/ > > > > jira issue: > > > > http://jira.codehaus.org/browse/MRELEASE-141 > > > > Thanks, > > John Tolentino > > > > - > > 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: Review of maven-release-plugin documentation
Good day to you, John, I am not really sure myself, so I'll just forward the question from the user's mailing list here (as a probable revision to the documentation). Does maven-release-plugin automatically increments the version number, or does the user have to manually specify the version? This question came from this thread [1], specifically, this post [2]. Thanks, Franz [1] http://www.nabble.com/forum/ViewPost.jtp?post=6382491&framed=y [2] http://www.nabble.com/forum/ViewPost.jtp?post=6382907&framed=y On 9/18/06, John Tolentino <[EMAIL PROTECTED]> wrote: maven-release-plugin documentation is now ready for review. Staging site can be found here: http://people.apache.org/~jtolentino/maven-release-plugin/ jira issue: http://jira.codehaus.org/browse/MRELEASE-141 Thanks, John Tolentino - 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 (25 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1145JIntellitype 1.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1145 MAVENUPLOAD-1143Upload Echo2 2.1.0.beta5 (corrected groupId) http://jira.codehaus.org/browse/MAVENUPLOAD-1143 MAVENUPLOAD-1144Upload Echo2-Extras 0.3 (corrected groupId) http://jira.codehaus.org/browse/MAVENUPLOAD-1144 MAVENUPLOAD-1134Upload net.sf.oval_0.6 http://jira.codehaus.org/browse/MAVENUPLOAD-1134 MAVENUPLOAD-1133Upload wsdl4j-1.5.3 http://jira.codehaus.org/browse/MAVENUPLOAD-1133 MAVENUPLOAD-1121Jericho HTML Parser 2.3 http://jira.codehaus.org/browse/MAVENUPLOAD-1121 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-978Upload ejb-3.0-public-draft-20060502 (needed for hibernate) http://jira.codehaus.org/browse/MAVENUPLOAD-978 MAVENUPLOAD-1129Rhino js-1.5R4-RC3 http://jira.codehaus.org/browse/MAVENUPLOAD-1129 MAVENUPLOAD-1053Upload hibernate-tools 3.2.0-beta6 http://jira.codehaus.org/browse/MAVENUPLOAD-1053 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]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (27 issues) Subscriber: mavendevlist Key Summary MEV-392 bad dependencies in commons-logging-1.1.pom http://jira.codehaus.org/browse/MEV-392 MEV-443 Several projects have maven-metadata.xml files that are missing released versions http://jira.codehaus.org/browse/MEV-443 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]
Re: Please sync Apache m2 repository for MyFaces
done On 9/20/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 9/18/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > MyFaces Core 1.1.4 has been deployed to m2-ibiblio-rsync-repository. > Please sync it to the central Maven repo when you have a chance. > > Vote thread: http://www.nabble.com/-VOTE--Release-MyFaces-Core-1.1.4-t2253192.html Carlos? I thought this might have gotten picked up with the sync for Geronimo 1.1.1, but I don't see ours out there yet. Let me know if there's something wrong... Thanks, Wendy - 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]
maven.eclipse.workspace
Is there an expression or any other means of accessing the Eclipse workspace
directory (as either a File object or a String) like you're able to in Jelly
in Maven 1.x with ${maven.eclipse.workspace}.
Thanks!
--
View this message in context:
http://www.nabble.com/maven.eclipse.workspace-tf2306467.html#a6411278
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Muse 2.0.0 release
Jason van Zyl wrote: On 20 Sep 06, at 3:04 PM 20 Sep 06, Steve Loughran wrote: Daniel Jemiolo wrote: > The Muse development team has worked hard over the spring and summer > months, enhancing, refactoring, fixing, and polishing the 2.x code base, > and the time has come to vote on a release for version 2.0.0. I am very > proud of the members of our team - both the committers who have > contributed and taken responsibility for large sections of code, and > non-committers who have rolled up their sleeves and wrestled with the > code, samples, and build artifacts until the project met the expectations > we had set for it. I'm also excited to see other open source projects > already using our code, as it gives us fresh perspectives on how to make > WSRF and WSDM easier for other programmers. > > To the committers and PMC members: please cast your vote on the release of > Muse 2.0.0, the artifacts for which are found here: > > http://www.apache.org/~danj/muse/2.0.0 > > Here's my +1 for this release. > Daniel, I'm going to vote -1 until the binaries dont include any dependent jars marked -SNAPSHOT This problem can easily be alleviated using the release plugin. I also had an experience the other day that leads me to believe that official releases should be barred unless you use the release plugin. Exposing the options to enable release info should be turned off. Usually it's inadvertent but it happens all the time. I was helping Dan (Xfire) the other day and he did a release by enabling the updateReleaseInfo property so he release the JARs only. The sources and javadoc did not go up which is bad. There should only be one way to do a release and the release should go through archiva which could detect the intactness of a release. Releases without sources or Javadocs should just get rejected, and if the release plugin is used it's impossible for SNAPSHOTs to slip through. As far as releases go, if projects don't use the release plugin it's not a release. +1 to that. Perhaps the Apache repository could somehow detect which artifacts had been tagged as formally released, or at least approved by archiva. Of course, non-maven projects still have the right to update content, but their stuff may need to go through some staging process before it is accepted as legitimate. -Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Muse 2.0.0 release
On 20 Sep 06, at 3:43 PM 20 Sep 06, Daniel Jemiolo wrote: Hi Steve, Thanks for taking the time to check out our project. The SNAPSHOT jars that are in Muse are from Axis2 - we are dependent on fixes that happened post-1.0, and the 1.1 version is not out yet. You can still use timestamped versions or you can get access to make an interim release. We only included the Axis2 WAR as a convenience to people who wanted to use the code generation tooling (it generates a complete Axis2 project, not just Java code). We could modify the build to not include the Axis2 WAR and ask people to download it themselves if that would help. That's probably inconvenient for your users. You just need to create artifacts with versions which are not subject to arbitrary changes. SNAPSHOTs are subject to arbitrary changes which makes the build unstable for your users. Thanks, Dan Steve Loughran <[EMAIL PROTECTED]> 09/20/2006 09:04 AM Please respond to muse-user@ws.apache.org To [EMAIL PROTECTED], Daniel Jemiolo/Durham/[EMAIL PROTECTED] cc muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List Subject Re: [VOTE] Muse 2.0.0 release Daniel Jemiolo wrote: The Muse development team has worked hard over the spring and summer months, enhancing, refactoring, fixing, and polishing the 2.x code base, and the time has come to vote on a release for version 2.0.0. I am very proud of the members of our team - both the committers who have contributed and taken responsibility for large sections of code, and non-committers who have rolled up their sleeves and wrestled with the code, samples, and build artifacts until the project met the expectations we had set for it. I'm also excited to see other open source projects already using our code, as it gives us fresh perspectives on how to make WSRF and WSDM easier for other programmers. To the committers and PMC members: please cast your vote on the release of Muse 2.0.0, the artifacts for which are found here: http://www.apache.org/~danj/muse/2.0.0 Here's my +1 for this release. Daniel, I'm going to vote -1 until the binaries dont include any dependent jars marked -SNAPSHOT We had this problem with muse 1.0, which also shipped using -SNAPSHOT libraries. It was impossible for anyone else to rebuild the application. you take the source as supplied, point maven at it, and end up pulling down different artifacts which may not link, and if they do, may not work correctly. It also raises problems downstream with support calks. If axiom-on-muse fails, who do I take this up with? Muse will bounce to Axiom, axiom will say 'old snapshot, not supported, go away'. I raised this issue with the muse 1.0 team in personal emails, and have just reviewed the 2.0 .zip file to see if the problem has gone away. It hasnt. In an ideal world, a project would not release with dependencies on anything other than supported, x.0 artifacts, just as in an ideal world standards cannot depend on anything other than stable release of other standards. Given that WSN must go down in OASIS history as the first specification to depend on two different draft versions of another spec, namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the value in having stable and consistent underpinnings. If the -SNAPSHOT artifacts can be dated and the ant/maven build which ships with the source includes these dated artifacts such that I can do a build from that source snapshot and have .class files that match those of the release, then I will vote +1. Please dont take this as any fault of the muse 2.0 release itself; I look forward to interop testing a public endpoint against my Alpine stack. I just dont want us to ship out as a point release something that end users cannot rebuild. If we do that, we have lost the downstream developer community. -Steve cc:d the maven dev list to emphasise that somehow this needs to be addressed. the ease of pulling in snapshots of other projects means that people tend to do it at release time. kept the muse-dev and -user lists, but I'm not sure if they will get through as I am not subscribing to them. - 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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Muse 2.0.0 release
Hi Steve, Thanks for taking the time to check out our project. The SNAPSHOT jars that are in Muse are from Axis2 - we are dependent on fixes that happened post-1.0, and the 1.1 version is not out yet. We only included the Axis2 WAR as a convenience to people who wanted to use the code generation tooling (it generates a complete Axis2 project, not just Java code). We could modify the build to not include the Axis2 WAR and ask people to download it themselves if that would help. Thanks, Dan Steve Loughran <[EMAIL PROTECTED]> 09/20/2006 09:04 AM Please respond to muse-user@ws.apache.org To [EMAIL PROTECTED], Daniel Jemiolo/Durham/[EMAIL PROTECTED] cc muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List Subject Re: [VOTE] Muse 2.0.0 release Daniel Jemiolo wrote: > The Muse development team has worked hard over the spring and summer > months, enhancing, refactoring, fixing, and polishing the 2.x code base, > and the time has come to vote on a release for version 2.0.0. I am very > proud of the members of our team - both the committers who have > contributed and taken responsibility for large sections of code, and > non-committers who have rolled up their sleeves and wrestled with the > code, samples, and build artifacts until the project met the expectations > we had set for it. I'm also excited to see other open source projects > already using our code, as it gives us fresh perspectives on how to make > WSRF and WSDM easier for other programmers. > > To the committers and PMC members: please cast your vote on the release of > Muse 2.0.0, the artifacts for which are found here: > > http://www.apache.org/~danj/muse/2.0.0 > > Here's my +1 for this release. > Daniel, I'm going to vote -1 until the binaries dont include any dependent jars marked -SNAPSHOT We had this problem with muse 1.0, which also shipped using -SNAPSHOT libraries. It was impossible for anyone else to rebuild the application. you take the source as supplied, point maven at it, and end up pulling down different artifacts which may not link, and if they do, may not work correctly. It also raises problems downstream with support calks. If axiom-on-muse fails, who do I take this up with? Muse will bounce to Axiom, axiom will say 'old snapshot, not supported, go away'. I raised this issue with the muse 1.0 team in personal emails, and have just reviewed the 2.0 .zip file to see if the problem has gone away. It hasnt. In an ideal world, a project would not release with dependencies on anything other than supported, x.0 artifacts, just as in an ideal world standards cannot depend on anything other than stable release of other standards. Given that WSN must go down in OASIS history as the first specification to depend on two different draft versions of another spec, namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the value in having stable and consistent underpinnings. If the -SNAPSHOT artifacts can be dated and the ant/maven build which ships with the source includes these dated artifacts such that I can do a build from that source snapshot and have .class files that match those of the release, then I will vote +1. Please dont take this as any fault of the muse 2.0 release itself; I look forward to interop testing a public endpoint against my Alpine stack. I just dont want us to ship out as a point release something that end users cannot rebuild. If we do that, we have lost the downstream developer community. -Steve cc:d the maven dev list to emphasise that somehow this needs to be addressed. the ease of pulling in snapshots of other projects means that people tend to do it at release time. kept the muse-dev and -user lists, but I'm not sure if they will get through as I am not subscribing to them. - 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]
Propose structure for multiproject
Hello all, Please help to get out of the following confusions: I am having many projects which may be dependent on each other or not.But we need to make one ear having all the archives file made of all projects. In one project, we can have one jar,jar+war,jar+war+har,or some other application specific archives like if har not supported by other applciation servers. These all projects are different cvs modules in the following structure but with no maven files(also we can't place file there) and test contains the testcases for all sub projects(object/services/UI) of one project/CVS module. Following is the structure: Project1 src objects(har) java resource services(jar) java resource UI(war) java resource webapps test So two problems: 1)Is it possible that we place our maven scripts somewhere at our system and projects are somewhere else, Can maven build all subprojects,make war,har,jar etc from that location and then package all of them to make ear? 2)Now i want ot run the testcases after building the project,not after making war/har/jar.I know if we place test in subproject thjen before making any archive it will run the testcases but ours is different case.Our testcases are in Main project not in different subprojects,so how can we achieve it?
Re: calling external maven
Just so you know, there is a project in the shared-component space to do this (I don't think it's been released yet, though). It's called maven-invoker, and it has the advantage that eventually its API is meant to be converged with the embedder (in the maven 2.1 timeframe). I'm using it now to run functional tests for the latest assembly plugin snapshots, by way of the maven-invoker-plugin, in the sandbox. If you were interested, that plugin offers some insight into using the invoker. SVN: invoker: http://svn.apache.org/repos/asf/maven/shared/trunk/maven-invoker invoker-plugin http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-invoker-plugin HTH, john On 9/20/06, Philippe Faes <[EMAIL PROTECTED]> wrote: Hi Raphaël, Thanks for your help. I decided on using org.apache.maven.plugins.release.exec.ForkedMavenExecutor It's too bad I have to depend on the entire release plugin, but it seems to work just fine. Philippe On Wed, 2006-09-20 at 10:24 +0200, Raphaël Piéroni wrote: > Hi, > > you can use : > - the embedder (as in mevenide) > - execute an inner lifecycle (as in the release or cargo plugins) > > Hope ths helps. > > Raphaël > > 2006/9/20, Philippe Faes <[EMAIL PROTECTED]>: > > > > Dear all, > > > > I'm creating a mvn plug-in that needs to start an external maven build. > > Is there an API function I can use for this? > > > > thanks > > > > -- > > ir. Philippe Faes > > Ghent University - Department ELIS > > Sint-Pietersnieuwstraat 41 -- B-9000 Gent > > Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 > > http://www.elis.UGent.be/~pfaes > > ON5DEU -- LPIC1 -- gpg-key:173720B6 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- ir. Philippe Faes Ghent University - Department ELIS Sint-Pietersnieuwstraat 41 -- B-9000 Gent Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 http://www.elis.UGent.be/~pfaes ON5DEU -- LPIC1 -- gpg-key:173720B6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Muse 2.0.0 release
On 20 Sep 06, at 3:04 PM 20 Sep 06, Steve Loughran wrote: Daniel Jemiolo wrote: > The Muse development team has worked hard over the spring and summer > months, enhancing, refactoring, fixing, and polishing the 2.x code base, > and the time has come to vote on a release for version 2.0.0. I am very > proud of the members of our team - both the committers who have > contributed and taken responsibility for large sections of code, and > non-committers who have rolled up their sleeves and wrestled with the > code, samples, and build artifacts until the project met the expectations > we had set for it. I'm also excited to see other open source projects > already using our code, as it gives us fresh perspectives on how to make > WSRF and WSDM easier for other programmers. > > To the committers and PMC members: please cast your vote on the release of > Muse 2.0.0, the artifacts for which are found here: > > http://www.apache.org/~danj/muse/2.0.0 > > Here's my +1 for this release. > Daniel, I'm going to vote -1 until the binaries dont include any dependent jars marked -SNAPSHOT This problem can easily be alleviated using the release plugin. I also had an experience the other day that leads me to believe that official releases should be barred unless you use the release plugin. Exposing the options to enable release info should be turned off. Usually it's inadvertent but it happens all the time. I was helping Dan (Xfire) the other day and he did a release by enabling the updateReleaseInfo property so he release the JARs only. The sources and javadoc did not go up which is bad. There should only be one way to do a release and the release should go through archiva which could detect the intactness of a release. Releases without sources or Javadocs should just get rejected, and if the release plugin is used it's impossible for SNAPSHOTs to slip through. As far as releases go, if projects don't use the release plugin it's not a release. We had this problem with muse 1.0, which also shipped using - SNAPSHOT libraries. It was impossible for anyone else to rebuild the application. you take the source as supplied, point maven at it, and end up pulling down different artifacts which may not link, and if they do, may not work correctly. It also raises problems downstream with support calks. If axiom-on-muse fails, who do I take this up with? Muse will bounce to Axiom, axiom will say 'old snapshot, not supported, go away'. I raised this issue with the muse 1.0 team in personal emails, and have just reviewed the 2.0 .zip file to see if the problem has gone away. It hasnt. In an ideal world, a project would not release with dependencies on anything other than supported, x.0 artifacts, just as in an ideal world standards cannot depend on anything other than stable release of other standards. Given that WSN must go down in OASIS history as the first specification to depend on two different draft versions of another spec, namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the value in having stable and consistent underpinnings. If the -SNAPSHOT artifacts can be dated and the ant/maven build which ships with the source includes these dated artifacts such that I can do a build from that source snapshot and have .class files that match those of the release, then I will vote +1. Please dont take this as any fault of the muse 2.0 release itself; I look forward to interop testing a public endpoint against my Alpine stack. I just dont want us to ship out as a point release something that end users cannot rebuild. If we do that, we have lost the downstream developer community. -Steve cc:d the maven dev list to emphasise that somehow this needs to be addressed. the ease of pulling in snapshots of other projects means that people tend to do it at release time. kept the muse-dev and - user lists, but I'm not sure if they will get through as I am not subscribing to them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please sync Apache m2 repository for MyFaces
On 9/18/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: MyFaces Core 1.1.4 has been deployed to m2-ibiblio-rsync-repository. Please sync it to the central Maven repo when you have a chance. Vote thread: http://www.nabble.com/-VOTE--Release-MyFaces-Core-1.1.4-t2253192.html Carlos? I thought this might have gotten picked up with the sync for Geronimo 1.1.1, but I don't see ours out there yet. Let me know if there's something wrong... Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Muse 2.0.0 release
Daniel Jemiolo wrote: > The Muse development team has worked hard over the spring and summer > months, enhancing, refactoring, fixing, and polishing the 2.x code base, > and the time has come to vote on a release for version 2.0.0. I am very > proud of the members of our team - both the committers who have > contributed and taken responsibility for large sections of code, and > non-committers who have rolled up their sleeves and wrestled with the > code, samples, and build artifacts until the project met the expectations > we had set for it. I'm also excited to see other open source projects > already using our code, as it gives us fresh perspectives on how to make > WSRF and WSDM easier for other programmers. > > To the committers and PMC members: please cast your vote on the release of > Muse 2.0.0, the artifacts for which are found here: > > http://www.apache.org/~danj/muse/2.0.0 > > Here's my +1 for this release. > Daniel, I'm going to vote -1 until the binaries dont include any dependent jars marked -SNAPSHOT We had this problem with muse 1.0, which also shipped using -SNAPSHOT libraries. It was impossible for anyone else to rebuild the application. you take the source as supplied, point maven at it, and end up pulling down different artifacts which may not link, and if they do, may not work correctly. It also raises problems downstream with support calks. If axiom-on-muse fails, who do I take this up with? Muse will bounce to Axiom, axiom will say 'old snapshot, not supported, go away'. I raised this issue with the muse 1.0 team in personal emails, and have just reviewed the 2.0 .zip file to see if the problem has gone away. It hasnt. In an ideal world, a project would not release with dependencies on anything other than supported, x.0 artifacts, just as in an ideal world standards cannot depend on anything other than stable release of other standards. Given that WSN must go down in OASIS history as the first specification to depend on two different draft versions of another spec, namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the value in having stable and consistent underpinnings. If the -SNAPSHOT artifacts can be dated and the ant/maven build which ships with the source includes these dated artifacts such that I can do a build from that source snapshot and have .class files that match those of the release, then I will vote +1. Please dont take this as any fault of the muse 2.0 release itself; I look forward to interop testing a public endpoint against my Alpine stack. I just dont want us to ship out as a point release something that end users cannot rebuild. If we do that, we have lost the downstream developer community. -Steve cc:d the maven dev list to emphasise that somehow this needs to be addressed. the ease of pulling in snapshots of other projects means that people tend to do it at release time. kept the muse-dev and -user lists, but I'm not sure if they will get through as I am not subscribing to them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request to apply patch for CONTINUUM-755
Hi, I've attached an updated patch for http://jira.codehaus.org/browse/CONTINUUM-755 Could somebody please apply it? The name of the patch file is CONTINUUM-755-continuum-weebapp-09202006.patch. Thanks in advance :) - Odea
Request to apply patch for CONTINUUM-897
Hi, I submitted a patch for http://jira.codehaus.org/browse/CONTINUUM-897. Can anyone please apply it to trunk? :) Thanks, Odea
Re: calling external maven
Hi Raphaël, Thanks for your help. I decided on using org.apache.maven.plugins.release.exec.ForkedMavenExecutor It's too bad I have to depend on the entire release plugin, but it seems to work just fine. Philippe On Wed, 2006-09-20 at 10:24 +0200, Raphaël Piéroni wrote: > Hi, > > you can use : > - the embedder (as in mevenide) > - execute an inner lifecycle (as in the release or cargo plugins) > > Hope ths helps. > > Raphaël > > 2006/9/20, Philippe Faes <[EMAIL PROTECTED]>: > > > > Dear all, > > > > I'm creating a mvn plug-in that needs to start an external maven build. > > Is there an API function I can use for this? > > > > thanks > > > > -- > > ir. Philippe Faes > > Ghent University - Department ELIS > > Sint-Pietersnieuwstraat 41 -- B-9000 Gent > > Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 > > http://www.elis.UGent.be/~pfaes > > ON5DEU -- LPIC1 -- gpg-key:173720B6 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- ir. Philippe Faes Ghent University - Department ELIS Sint-Pietersnieuwstraat 41 -- B-9000 Gent Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 http://www.elis.UGent.be/~pfaes ON5DEU -- LPIC1 -- gpg-key:173720B6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Separating the Indices
On 19 Sep 06, at 3:17 PM 19 Sep 06, Brett Porter wrote: IT's not hooked up, but there is a "minimal" index too that should be much smaller. It's the original one used by the eclipse plugin. But no objections from me if you want to work on the other one. Cool, I'll work with Eugene as he had some good ideas about how the indices could be generated and staged so that they are most useful for tools. - Brett On 19/09/2006, at 11:13 PM, Jason van Zyl wrote: Hi, I'm currently using the md5 information in the index to lookup artifacts but the index as a whole is 175mb which is a little unwieldy. Anyone mind if I take a shot at separating the indices and coming up with a plan for segmenting them on daily, weekly, monthly chunks and having lucene aggregate them again? This is somethign that I would like for the build conversion tool I'm writing and I'll need it next week when I work with Milos on the embedder. The index file needed by IDEs for selecting dependencies is fairly small compressed, trying to pull down a compressed archive of 17mb (bzip2, but growing) is a bit much. Jason van Zyl [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED]
Re: calling external maven
Hi, you can use : - the embedder (as in mevenide) - execute an inner lifecycle (as in the release or cargo plugins) Hope ths helps. Raphaël 2006/9/20, Philippe Faes <[EMAIL PROTECTED]>: Dear all, I'm creating a mvn plug-in that needs to start an external maven build. Is there an API function I can use for this? thanks -- ir. Philippe Faes Ghent University - Department ELIS Sint-Pietersnieuwstraat 41 -- B-9000 Gent Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 http://www.elis.UGent.be/~pfaes ON5DEU -- LPIC1 -- gpg-key:173720B6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
calling external maven
Dear all, I'm creating a mvn plug-in that needs to start an external maven build. Is there an API function I can use for this? thanks -- ir. Philippe Faes Ghent University - Department ELIS Sint-Pietersnieuwstraat 41 -- B-9000 Gent Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 http://www.elis.UGent.be/~pfaes ON5DEU -- LPIC1 -- gpg-key:173720B6 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
