Re: [vote] release maven-ear-plugin 2.3.1
+1 On 8 Jan 07, at 4:29 PM 8 Jan 07, Stephane Nicoll wrote: Hi, I'd like to release the ear plugin which contains a backward compatibility issue in 2.3 [1]. The issue has been fixed and the reporter has validated his builds successfully. Revision 492264 Snapshot available http://people.apache.org/~snicoll/maven-stage-repo/org/apache/maven/ plugins/maven-ear-plugin/2.3.1-SNAPSHOT/ Votes open for 72h. My +1, Stéphane [1] http://jira.codehaus.org/browse/MEAR-53 - 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: calling vote for 2.0.5
On 11 Jan 07, at 12:37 AM 11 Jan 07, Ralph Goers wrote: Well, if you absolutely positively promise to release 2.0.6 when MNG-1577 is applied ;-) . Seriously, it has been rather frustrating as I can't even use Maven 2 without that fix. I'm sure if you and Mike work together then I can help you get that patch in. But this needs to be released. Just updating the headers, sorting out some release bits, and setting up blessed build box to create a build and we'll be ready for the vote. Jason. Ralph Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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: calling vote for 2.0.5
Well, if you absolutely positively promise to release 2.0.6 when MNG-1577 is applied ;-) . Seriously, it has been rather frustrating as I can't even use Maven 2 without that fix. Ralph Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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]
Moving site plugin webapp to another plugin
Can we put the webapp stuff that's currently in the site plugin in another plugin so that when you simply want to generate your site you don't drag down Jetty and all its dependencies? It really is something unexpected and isn't something most would associate with just generating a site. The functionality is cool, I just think it belong in another plugin. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r495101 - /maven/components/trunk/maven-embedder/src/main/java/org/apache/maven/embedder/MavenEmbedder.java
On 10 Jan 07, at 10:41 PM 10 Jan 07, Brett Porter wrote:
If the artifact was created with an artifact factory, isn't there
already a getHandler() method on the artifact itself?
In what there is currently yes, but I'm not going to using it because
the artifact is data and should not carry with with components like
ArtifactHandlers and Repositories. Makes trying to serialize them or
index them very difficult. So I'm not making any of the IDE folks use
them, and ultimately I don't want to even expose that much: this is a
stop gap so Eugene can merge some Eclipse notions of classpaths with
what we provide.
On 11/01/2007, at 2:39 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Wed Jan 10 19:39:22 2007
New Revision: 495101
URL: http://svn.apache.org/viewvc?view=rev&rev=495101
Log:
o add method so that the artifact handler can be looked up, useful
in IDEs where we want to look up whether a particular artifact
should be added to the classpath.
Modified:
maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java
Modified: maven/components/trunk/maven-embedder/src/main/java/org/
apache/maven/embedder/MavenEmbedder.java
URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-
embedder/src/main/java/org/apache/maven/embedder/
MavenEmbedder.java?view=diff&rev=495101&r1=495100&r2=495101
=
=
--- maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java (original)
+++ maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java Wed Jan 10 19:39:22 2007
@@ -20,6 +20,8 @@
import org.apache.maven.MavenTools;
import org.apache.maven.SettingsConfigurationException;
import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.handler.ArtifactHandler;
+import
org.apache.maven.artifact.handler.manager.ArtifactHandlerManager;
import org.apache.maven.artifact.factory.ArtifactFactory;
import org.apache.maven.artifact.repository.ArtifactRepository;
import
org.apache.maven.artifact.repository.ArtifactRepositoryFactory;
@@ -95,6 +97,8 @@
private ArtifactRepositoryLayout
defaultArtifactRepositoryLayout;
+private ArtifactHandlerManager artifactHandlerManager;
+
private Maven maven;
private MavenTools mavenTools;
@@ -296,6 +300,11 @@
artifactResolver.resolve( artifact, remoteRepositories,
localRepository );
}
+public ArtifactHandler getArtifactHandler( Artifact artifact )
+{
+return artifactHandlerManager.getArtifactHandler
( artifact.getType() );
+}
+
//
-
-
// Plugins
//
-
-
@@ -465,6 +474,8 @@
defaultsPopulator =
(MavenExecutionRequestDefaultsPopulator) container.lookup(
MavenExecutionRequestDefaultsPopulator.ROLE );
+
+artifactHandlerManager = (ArtifactHandlerManager)
container.lookup( ArtifactHandlerManager.ROLE );
// These three things can be cached for a single
session of the embedder
settings = mavenTools.buildSettings
( req.getUserSettingsFile(), req.getGlobalSettingsFile(), false );
-
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: r495101 - /maven/components/trunk/maven-embedder/src/main/java/org/apache/maven/embedder/MavenEmbedder.java
If the artifact was created with an artifact factory, isn't there
already a getHandler() method on the artifact itself?
On 11/01/2007, at 2:39 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Wed Jan 10 19:39:22 2007
New Revision: 495101
URL: http://svn.apache.org/viewvc?view=rev&rev=495101
Log:
o add method so that the artifact handler can be looked up, useful
in IDEs where we want to look up whether a particular artifact
should be added to the classpath.
Modified:
maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java
Modified: maven/components/trunk/maven-embedder/src/main/java/org/
apache/maven/embedder/MavenEmbedder.java
URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-
embedder/src/main/java/org/apache/maven/embedder/MavenEmbedder.java?
view=diff&rev=495101&r1=495100&r2=495101
==
--- maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java (original)
+++ maven/components/trunk/maven-embedder/src/main/java/org/apache/
maven/embedder/MavenEmbedder.java Wed Jan 10 19:39:22 2007
@@ -20,6 +20,8 @@
import org.apache.maven.MavenTools;
import org.apache.maven.SettingsConfigurationException;
import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.handler.ArtifactHandler;
+import
org.apache.maven.artifact.handler.manager.ArtifactHandlerManager;
import org.apache.maven.artifact.factory.ArtifactFactory;
import org.apache.maven.artifact.repository.ArtifactRepository;
import
org.apache.maven.artifact.repository.ArtifactRepositoryFactory;
@@ -95,6 +97,8 @@
private ArtifactRepositoryLayout defaultArtifactRepositoryLayout;
+private ArtifactHandlerManager artifactHandlerManager;
+
private Maven maven;
private MavenTools mavenTools;
@@ -296,6 +300,11 @@
artifactResolver.resolve( artifact, remoteRepositories,
localRepository );
}
+public ArtifactHandler getArtifactHandler( Artifact artifact )
+{
+return artifactHandlerManager.getArtifactHandler
( artifact.getType() );
+}
+
//
--
// Plugins
//
--
@@ -465,6 +474,8 @@
defaultsPopulator =
(MavenExecutionRequestDefaultsPopulator) container.lookup(
MavenExecutionRequestDefaultsPopulator.ROLE );
+
+artifactHandlerManager = (ArtifactHandlerManager)
container.lookup( ArtifactHandlerManager.ROLE );
// These three things can be cached for a single
session of the embedder
settings = mavenTools.buildSettings
( req.getUserSettingsFile(), req.getGlobalSettingsFile(), false );
-
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 (29 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1317SweetXML 0.2 bundles ready for repository http://jira.codehaus.org/browse/MAVENUPLOAD-1317 MAVENUPLOAD-1316upload vraptor 2.3.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1316 MAVENUPLOAD-1315Upload antlr-3.0b5 http://jira.codehaus.org/browse/MAVENUPLOAD-1315 MAVENUPLOAD-1314Upload antlr-2.7.7 http://jira.codehaus.org/browse/MAVENUPLOAD-1314 MAVENUPLOAD-1313Upload stringtemplates-3.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1313 MAVENUPLOAD-1312Upload ZK 2.2.1 to the central repository http://jira.codehaus.org/browse/MAVENUPLOAD-1312 MAVENUPLOAD-1311Upload net.sf.oval-0.8 http://jira.codehaus.org/browse/MAVENUPLOAD-1311 MAVENUPLOAD-1310NanoXML Lite http://jira.codehaus.org/browse/MAVENUPLOAD-1310 MAVENUPLOAD-1304org.springframework:beandoc:0.7.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1304 MAVENUPLOAD-1282PMD 3.9 bundle http://jira.codehaus.org/browse/MAVENUPLOAD-1282 MAVENUPLOAD-1309iBatis 2.2.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1309 MAVENUPLOAD-1307XML Bind Builder [Ant] http://jira.codehaus.org/browse/MAVENUPLOAD-1307 MAVENUPLOAD-1306XML Bind Generator http://jira.codehaus.org/browse/MAVENUPLOAD-1306 MAVENUPLOAD-1308XML Bind Builder [Maven] http://jira.codehaus.org/browse/MAVENUPLOAD-1308 MAVENUPLOAD-1305XML Bind Runtime http://jira.codehaus.org/browse/MAVENUPLOAD-1305 MAVENUPLOAD-1284upload new artifact to The Central Repository http://jira.codehaus.org/browse/MAVENUPLOAD-1284 MAVENUPLOAD-1264UrlRewriteFilter 2.6 http://jira.codehaus.org/browse/MAVENUPLOAD-1264 MAVENUPLOAD-1267Upload of novell jldap http://jira.codehaus.org/browse/MAVENUPLOAD-1267 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-483 Still invalid deps in 3.2.1, 3.2.2, 3.2.3, 3.2.4 http://jira.codehaus.org/browse/MEV-483 MEV-478 jakarta-poi requires commons-lang as dependency http://jira.codehaus.org/browse/MEV-478 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: continuum-store and JDO
im looking into it, but i cant seen to install the modules locally - im getting a weird random access denied error... On 1/10/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Yes. A global patch would be better instead of separate patches. I tried your 2 patches and updated locally jpox-* to 1.1.3 in continuum parent pom. With them, all tests works fine, but continuum doesn't start. Emmanuel Marcelo Fukushima a écrit : > Hello dear devs. > > After everyone's help, ive noticed that jpox was saving the > BuildDefinition with wrong values (the buildFresh and arguments and > possibly others too)... since i dont know how jpox work, the first > thing i tried was to update to a more recent version of it (namely > 1.1.3) and everything worked fine... > im going to attach the test case to jira (actually a patch to the > testcase to check those things too), but should i attach a patch to > the pom too? > > On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: >> The metadata file (and enhanced classes) are generated when you use >> Maven to build the project. As long as eclipse doesn't overwrite the >> class files it should be fine. Alternatively, you can use the eclipse >> plugin for jpox to make sure the classes get enhanced and just run >> maven once to generate the metadata file. I've never used that >> plugin, but it is available from the jpox site. >> >> Thanks! >> - Brett >> >> On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: >> >> > hello folks! i sent a couple of emails to the user list, but i guess i >> > could help a little too, right? so i just checked out the code from >> > SVN and wanted to tackle >> > http://jira.codehaus.org/browse/CONTINUUM-1103 >> > while i could isolate the bug (the property is not getting persisted >> > on the db) but since i know almost nothing about jdo, i cant run the >> > tests inside eclipse to try to figure out the solution and i couldnt >> > find where the metadata file or the enhanced version of the classes >> > are found... >> > is there any doc that can help me with that kinda of info? thanks >> > in advance >> > -- >> > []'s >> > Marcelo Takeshi Fukushima >> > > -- []'s Marcelo Takeshi Fukushima
Changing property during execution of particular mojo
Forwarding to dev list
-- Forwarded message --
From: Ben Alex <[EMAIL PROTECTED]>
Date: Jan 10, 2007 1:28 PM
Subject: Changing property during execution of particular mojo
To: [EMAIL PROTECTED]
Cc: Stewart Alan <[EMAIL PROTECTED]>
Hi Carlos
Just related to MCOMPILER-48, the plugin contains:
@parameter expression="${maven.compiler.failOnError}"
How can I arbitrarily set this value to false from within my mojo? I
only need the compile step to be false when it is spawned in a parallel
execution by my mojo. It's probably better it be true (the default) when
executing the "real" compile step in the compile phase of the project.
The header of my mojo is as follows BTW:
* @goal java
* @phase generate-sources
* @execute phase="test-compile"
* @requiresDependencyResolution compile
Any suggestions, links to check or keywords to search on appreciated.
cheers
Ben
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
Yes, I have a script to automate installing the latest build (though would need changes if continuum_ci was turned off). 1.1 is running very well thanks to some sleuthing by Wendy and quick fixes from Emmanuel. My biggest concern is the scalability of polling. It currently takes about 30 minutes to just run through all the required svn up commands to detect if builds are needed for all the Maven projects. - Brett On 11/01/2007, at 10:26 AM, Arnaud HERITIER wrote: good luck ;-) did you update the 2.1 snapshot ? Arnaud On 1/11/07, Brett Porter <[EMAIL PROTECTED]> wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? - Brett
Re: calling vote for 2.0.5
On 10 Jan 07, at 6:07 PM 10 Jan 07, Brian E. Fox wrote: Sounds like a plan to me. To clarify, are you targeting all maven core only releases for this machine, or all maven related releases (ie plugins, shared etc)? I think it makes sense to consolidate as many as possible to the same machine, it's how we operate our corporate builds anyway. It will have the benefit of being setup and ready to go so new releasers won't have as high a hurdle to jump in and help. For now, the core release, but eventually all things Maven should be built from a blessed box. Jason. +1 from me. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 5:20 PM To: Maven Developers List Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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: Trusting in our own dog food
good luck ;-) did you update the 2.1 snapshot ? Arnaud On 1/11/07, Brett Porter <[EMAIL PROTECTED]> wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? - Brett
RE: calling vote for 2.0.5
Sounds like a plan to me. To clarify, are you targeting all maven core only releases for this machine, or all maven related releases (ie plugins, shared etc)? I think it makes sense to consolidate as many as possible to the same machine, it's how we operate our corporate builds anyway. It will have the benefit of being setup and ready to go so new releasers won't have as high a hurdle to jump in and help. +1 from me. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 5:20 PM To: Maven Developers List Subject: calling vote for 2.0.5 Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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]
Trusting in our own dog food
Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? - Brett
Re: [continuum] BUILD FAILURE: Maven Site plugin
I think this is because the other CI builds are nuking the local repository. I'll need to make continuum use a different one. - Brett On 11/01/2007, at 8:28 AM, [EMAIL PROTECTED] wrote: Online report : http://maven.zones.apache.org/continuum/ buildResult.action?buildId=612&projectId=32&projectName=Maven Site plugin Build statistics: State: Failed Previous State: Ok Started at: Wed, 10 Jan 2007 21:28:34 + Finished at: Wed, 10 Jan 2007 21:28:37 + Total time: 2s Build Trigger: Schedule Build Number: 3 Exit code: 1 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_09(Sun Microsystems Inc.) ** ** SCM Changes: ** ** No files changed ** ** SCM Changes since last success: ** ** ** ** Dependencies Changes: ** ** org.apache.maven.doxia:doxia-site-renderer:1.0-alpha-9-SNAPSHOT org.apache.maven.doxia:doxia-decoration-model:1.0-alpha-9-SNAPSHOT ** ** Test Summary: ** ** Tests: 1 Failures: 0 Total time: 878 ** ** Output: ** ** [INFO] Scanning for projects... [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugins Version: 8-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:8-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] -- -- [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-site-plugin:maven-plugin:2.0-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java: 315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.maven.plugins:maven-plugins for project: null:maven-site-plugin:maven-plugin:2.0-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage (DefaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal (DefaultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFil eInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java: 447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.maven.plugins:maven-plugins' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:8-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepos itory(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage (DefaultMavenProjectBuilder.java:1157) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNot
Re: calling vote for 2.0.5
Agreed to the plan - thanks for getting this moving. (Presuming this is not an actual vote though) - Brett On 11/01/2007, at 9:20 AM, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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: calling vote for 2.0.5
I haven't called the vote yet, just wanted to settle on picking a machine to dispatch it from. It's coming, it's coming :-) jason. On 10 Jan 07, at 5:20 PM 10 Jan 07, Jason van Zyl wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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: [discuss] site layout for /maven/*
On 09/01/2007, at 11:18 PM, Vincent Siveton wrote: Hi, In the same way of Brett's thread [1], WDYT to move all /maven/*/*-site to /maven/site/*? I've considered this before, but I agree with Trygve that we don't want this in particular. The problem is that when you want to do something with the doxia site, you rarely want to do something with the rest of the site, but you often want to do something with the doxia code. So they belong together. That said - an externals for all sites so that we can redeploy them all at once would have occasional value (when you change the skin, for example), so perhaps that is something to look at instead? Actually, archiva, jxr and doxia have no standard layout for site and problems of deployment can appear (throw a glance to [2] about doxia site). We could consolidate them instead of. Thoughts? Definitely agree that we need more standardisation and consistency, proper production of development reports, and separation of the user material from that. I think it might be better for us to put the time into this. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: calling vote for 2.0.5
+1 I'm all for more frequent releases. I believe the 2.0.5 snapshot works ok with our build. Ship it! On 1/10/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. 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]
calling vote for 2.0.5
Hi, I want to call a vote for 2.0.5. All the issues that are going to get done are done. We'll release and move on. I would like to start building all releases from a standard machine with the same JDK. I would like to propose the maven.org machine which is monitored 24/7 running Linux. It serves as the central repository but can easily handle a few builds. They can be built from that machine and deployed to Apache. I think this is far better then each of us building stuff from our own machines and deploying. Otherwise everything for 2.0.5 is ready to go. I will also chop up what's in JIRA into some smaller versions as I think some micro releases for improvements and smaller changes is better then waiting 7 months for another release. If we schedule them out them people can decide whether they want to upgrade or not. But I know there are several things I would like to get in and I know that Mike/Ralph would like to get in MNG-1577 which we can squeeze into a 2.0.6 in a week or two. These are micro release. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy surefire snapshot
hehe so this is why releases were failing at my end! Rahul Kenney Westerhof wrote: Prasad Kashyap wrote: I suspect this to be the cause of my woes :-) [INFO] [INFO] Surefire report directory: C:\Apache\geronimo\trunk\testsuite\deployment-testsuite\deployment-tests\target\surefire-reports [INFO] java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter [INFO] Exception in thread "main" [INFO] [ERROR] There are test failures. Hi, I just solved this by deploying the surefire plugin itself. The version should be *-9.jar now. -- kenney My tests used to work fine just until recently. I use the 2.3-SNAPSHOT of maven-surefire-plugin. The latest jar in the repo is maven-surefire-plugin-2.3-20070110.125545-8.jar The surefire-booter that it depends on is a 2.1-SNAPSHOT and the latest timestamped jar in the repo is surefire-booter-2.1-20070108.094711-10.jar Cheers Prasad On 1/8/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: done On 1/8/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > Hi, > > Could somebody deploy a surefire snapshot (including the > surefire-junit4 provider) ? > > thanks, > > Tom > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy surefire snapshot
Thanx Kenney. Problem solved. Cheers Prasad On 1/10/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote: Prasad Kashyap wrote: > I suspect this to be the cause of my woes :-) > > [INFO] [INFO] Surefire report directory: > C:\Apache\geronimo\trunk\testsuite\deployment-testsuite\deployment-tests\target\surefire-reports > > [INFO] java.lang.NoClassDefFoundError: > org/apache/maven/surefire/booter/SurefireBooter > [INFO] Exception in thread "main" > [INFO] [ERROR] There are test failures. Hi, I just solved this by deploying the surefire plugin itself. The version should be *-9.jar now. -- kenney > > My tests used to work fine just until recently. > > I use the 2.3-SNAPSHOT of maven-surefire-plugin. The latest jar in the > repo is > maven-surefire-plugin-2.3-20070110.125545-8.jar > > The surefire-booter that it depends on is a 2.1-SNAPSHOT and the > latest timestamped jar in the repo is > surefire-booter-2.1-20070108.094711-10.jar > > Cheers > Prasad > > > > On 1/8/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: >> done >> >> On 1/8/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Could somebody deploy a surefire snapshot (including the >> > surefire-junit4 provider) ? >> > >> > thanks, >> > >> > Tom >> > >> > - >> > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy surefire snapshot
Prasad Kashyap wrote: I suspect this to be the cause of my woes :-) [INFO] [INFO] Surefire report directory: C:\Apache\geronimo\trunk\testsuite\deployment-testsuite\deployment-tests\target\surefire-reports [INFO] java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter [INFO] Exception in thread "main" [INFO] [ERROR] There are test failures. Hi, I just solved this by deploying the surefire plugin itself. The version should be *-9.jar now. -- kenney My tests used to work fine just until recently. I use the 2.3-SNAPSHOT of maven-surefire-plugin. The latest jar in the repo is maven-surefire-plugin-2.3-20070110.125545-8.jar The surefire-booter that it depends on is a 2.1-SNAPSHOT and the latest timestamped jar in the repo is surefire-booter-2.1-20070108.094711-10.jar Cheers Prasad On 1/8/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: done On 1/8/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > Hi, > > Could somebody deploy a surefire snapshot (including the > surefire-junit4 provider) ? > > thanks, > > Tom > > - > 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: [discuss] site layout for /maven/*
Trygve Laugstøl wrote: Vincent Siveton wrote: Hi, 2007/1/10, Jason van Zyl <[EMAIL PROTECTED]>: On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: > Hi, > > In the same way of Brett's thread [1], WDYT to move all > /maven/*/*-site to /maven/site/*? > > Actually, archiva, jxr and doxia have no standard layout for site and > problems of deployment can appear (throw a glance to [2] about doxia > site). We could consolidate them instead of. Thoughts? > I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Agree. So, I propose to consolidate doxia project, ie move /maven/doxia/site to /maven/doxia/trunk/doxia-site WDYT to standardize archiva and jxr project like other sub projects? I mean creating archiva-site and jxr-site? -0, the site is a living thing that lives outside of the project itself. If the project has _documentation_ that is released with the project and deployed in addition to the site you can add doxia-site and make that contain the documentation for a particular version. -0 too, I agree. The X-site projects should contain stuff that's not tied to the version of the project (which will usually be very small). Also, why have a top level project X-site at all? Having src/site in the top level project works fine. It will also help with the layout of the site because the modules are at the right place. -- Kenney -- Trygve - 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: deploy surefire snapshot
I suspect this to be the cause of my woes :-) [INFO] [INFO] Surefire report directory: C:\Apache\geronimo\trunk\testsuite\deployment-testsuite\deployment-tests\target\surefire-reports [INFO] java.lang.NoClassDefFoundError: org/apache/maven/surefire/booter/SurefireBooter [INFO] Exception in thread "main" [INFO] [ERROR] There are test failures. My tests used to work fine just until recently. I use the 2.3-SNAPSHOT of maven-surefire-plugin. The latest jar in the repo is maven-surefire-plugin-2.3-20070110.125545-8.jar The surefire-booter that it depends on is a 2.1-SNAPSHOT and the latest timestamped jar in the repo is surefire-booter-2.1-20070108.094711-10.jar Cheers Prasad On 1/8/07, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: done On 1/8/07, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > Hi, > > Could somebody deploy a surefire snapshot (including the > surefire-junit4 provider) ? > > thanks, > > Tom > > - > 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: [vote] Collapse Maven permission groups
[X] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) I think that anybody that got a committer status in any of the maven subproject should at least be considered enough smart to understand by himself if he has enough knowledge and confidence with the other subproject before starting committing to them. Mistakes can happen but can easily be reverted, and this could encourage an easier transition between modules. fabrizio On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: Hi, Since there was no objection to calling a vote, as discussed in the proposal, I'd like to call a vote on this. To see the proposal and discussion: http://mail-archives.apache.org/ mod_mbox/maven-dev/200612.mbox/%3c67FC84B5-4510-469B-AEC1- [EMAIL PROTECTED] Vote to operate as - requiring 2/3rds of the PMC to vote (13), with a majority within those votes for it to pass (ie, add them all and if the result is > 0). Other votes would be welcome with reasons as advisory, but not binding. - Votes can be changed at any time before result is posted. - Vote is open for at least 72 hours, completing once enough have voted after that. - There are two different +1 options. If there is a majority for "collapse all groups" against both other options, then it will pass. If it fails, then all votes will be transferred to the "retain subproject access restrictions" and recounted. The proposal is to collapse all access groups into a single ACL for Maven, with the following list of 37 committers: Fabrice Bellingard, David Blevins, John Casey, Maria Ching, Joakim Erdfelt, Dan Fabulich (pending), Brian Fox, Fabrizio Giustina, Arnaud Heritier, Jeff Jensen, Shinobu Kawai, Milos Kleint, Trygve Laugstol, Felipe Leme, Dennis Lundberg, Vincent Massol, Jesse McConnell, Stephane Nicoll, Mike Perham, Brett Porter, Edwin Punzalan, Daniel Rall, Allan Ramirez, Carlos Sanchez, Vincent Siveton, Wendy Smoak, Torbjorn Smorgrav, James Strachan, Chris Stevenson, Rahul Thakur, Lukas Theussl, John Tolentino, Dan Tran, Emmanuel Venisse, Kenney Westerhof, Andrew Williams, Henri Yandell, and Jason van Zyl. The alternate proposal is to retain subproject access restrictions, so the groups will be (PMC members removed, as they retain access to all areas): maven=wsmoak,felipeal,jjensen,shinobu,dlr,mkleint,handyande,epunzalan,ar amirez,dantran,chrisjs,brianf,bellingard,oching (/maven-1,/ components,/plugins,/archetype,/core-integration-testing,/jxr,/ release,/skins,/resources,/release-testing) doxia=dblevins archiva=bayard,epunzalan,oching continuum=dblevins,rinku scm=dantran,smorgrav wagon= surefire= All of the above groups will have access to: /pom, /project, /site, / shared in this proposal, so it is essentially to collapse the @maven group, making the permission groups match the existence of a corresponding dev lists. [ ] +1 for the full proposal - collapse all groups (implies a vote for the next option if vote doesn't pass) [ ] +1 for the partial proposal - retain subproject access restrictions [ ] 0 abstain from vote [ ] -1 do not alter the current permissions Cheers, 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]
Re: Where to put branches?
atm the group name can be pretty much anything since its not making the project groups automatically anymore, you have to make it manually and then just load in the project...so I would just make a couple of project groups, one for each...it will render out under the current UI better anyway the groupId (not the jpox id one) is just a string so it doesn't have to really be a package space.. but ultimately I am more in favorite of an idea I think you mentioned a while back about optionally digging deeper into the model for unique projects to build and making it not just a matter of Group/Project unique combinations to build but Group/Project/Version which would all for the differing scm urls and whatnot. jesse On 1/9/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: You can add it in the current project group, but you'll have project names duplicated (trunk and branch) if you don't rename project names. The way I prefer is to create a new project group and you can choose what you want for the groupId (org.apache.maven[2.0.x branch] ?) Emmanuel Brett Porter a écrit : > I'd like to add Maven 2.0.5 to continuum in the same way I have added > trunk. > > But how am I supposed to do this with the new project groups? It should > probably have it's own group (since there is no way to particularly > configure the alternate branch within an existing one), but the group id > can't match an existing one. > > Any thoughts from those that implemented this on how it might work? > > - Brett > > > -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum-store and JDO
Yes. A global patch would be better instead of separate patches. I tried your 2 patches and updated locally jpox-* to 1.1.3 in continuum parent pom. With them, all tests works fine, but continuum doesn't start. Emmanuel Marcelo Fukushima a écrit : Hello dear devs. After everyone's help, ive noticed that jpox was saving the BuildDefinition with wrong values (the buildFresh and arguments and possibly others too)... since i dont know how jpox work, the first thing i tried was to update to a more recent version of it (namely 1.1.3) and everything worked fine... im going to attach the test case to jira (actually a patch to the testcase to check those things too), but should i attach a patch to the pom too? On 1/9/07, Brett Porter <[EMAIL PROTECTED]> wrote: The metadata file (and enhanced classes) are generated when you use Maven to build the project. As long as eclipse doesn't overwrite the class files it should be fine. Alternatively, you can use the eclipse plugin for jpox to make sure the classes get enhanced and just run maven once to generate the metadata file. I've never used that plugin, but it is available from the jpox site. Thanks! - Brett On 09/01/2007, at 2:27 PM, Marcelo Fukushima wrote: > hello folks! i sent a couple of emails to the user list, but i guess i > could help a little too, right? so i just checked out the code from > SVN and wanted to tackle > http://jira.codehaus.org/browse/CONTINUUM-1103 > while i could isolate the bug (the property is not getting persisted > on the db) but since i know almost nothing about jdo, i cant run the > tests inside eclipse to try to figure out the solution and i couldnt > find where the metadata file or the enhanced version of the classes > are found... > is there any doc that can help me with that kinda of info? thanks > in advance > -- > []'s > Marcelo Takeshi Fukushima
Re: [vote] Collapse Maven permission groups
+1 for the partial proposal, retaining subproject access restrictions. On 1/10/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: [X] +1 for the partial proposal - retain subproject access restrictions On 1/9/07, John Tolentino <[EMAIL PROTECTED]> wrote: > > Brett Porter wrote: > > [ ] +1 for the full proposal - collapse all groups (implies a vote for > > the next option if vote doesn't pass) > > [X] +1 for the partial proposal - retain subproject access restrictions > > [ ] 0 abstain from vote > > [ ] -1 do not alter the current permissions > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Collapse Maven permission groups
[X] +1 for the partial proposal - retain subproject access restrictions On 1/9/07, John Tolentino <[EMAIL PROTECTED]> wrote: > Brett Porter wrote: > [ ] +1 for the full proposal - collapse all groups (implies a vote for > the next option if vote doesn't pass) > [X] +1 for the partial proposal - retain subproject access restrictions > [ ] 0 abstain from vote > [ ] -1 do not alter the current permissions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] site layout for /maven/*
Vincent Siveton wrote: Hi, 2007/1/10, Jason van Zyl <[EMAIL PROTECTED]>: On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: > Hi, > > In the same way of Brett's thread [1], WDYT to move all > /maven/*/*-site to /maven/site/*? > > Actually, archiva, jxr and doxia have no standard layout for site and > problems of deployment can appear (throw a glance to [2] about doxia > site). We could consolidate them instead of. Thoughts? > I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Agree. So, I propose to consolidate doxia project, ie move /maven/doxia/site to /maven/doxia/trunk/doxia-site WDYT to standardize archiva and jxr project like other sub projects? I mean creating archiva-site and jxr-site? -0, the site is a living thing that lives outside of the project itself. If the project has _documentation_ that is released with the project and deployed in addition to the site you can add doxia-site and make that contain the documentation for a particular version. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] site layout for /maven/*
On 10 Jan 07, at 11:29 AM 10 Jan 07, Vincent Siveton wrote: Hi, 2007/1/10, Jason van Zyl <[EMAIL PROTECTED]>: On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: > Hi, > > In the same way of Brett's thread [1], WDYT to move all > /maven/*/*-site to /maven/site/*? > > Actually, archiva, jxr and doxia have no standard layout for site and > problems of deployment can appear (throw a glance to [2] about doxia > site). We could consolidate them instead of. Thoughts? > I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Agree. So, I propose to consolidate doxia project, ie move /maven/doxia/site to /maven/doxia/trunk/doxia-site WDYT to standardize archiva and jxr project like other sub projects? I mean creating archiva-site and jxr-site? +1 Vincent Jason > Cheers, > > Vincent > > [1] http://mail-archives.apache.org/mod_mbox/maven-dev/ 200701.mbox/% > [EMAIL PROTECTED] > [2] http://mail-archives.apache.org/mod_mbox/maven-dev/ 200701.mbox/% > [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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] site layout for /maven/*
Hi, 2007/1/10, Jason van Zyl <[EMAIL PROTECTED]>: On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: > Hi, > > In the same way of Brett's thread [1], WDYT to move all > /maven/*/*-site to /maven/site/*? > > Actually, archiva, jxr and doxia have no standard layout for site and > problems of deployment can appear (throw a glance to [2] about doxia > site). We could consolidate them instead of. Thoughts? > I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Agree. So, I propose to consolidate doxia project, ie move /maven/doxia/site to /maven/doxia/trunk/doxia-site WDYT to standardize archiva and jxr project like other sub projects? I mean creating archiva-site and jxr-site? Vincent Jason > Cheers, > > Vincent > > [1] http://mail-archives.apache.org/mod_mbox/maven-dev/200701.mbox/% > [EMAIL PROTECTED] > [2] http://mail-archives.apache.org/mod_mbox/maven-dev/200701.mbox/% > [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: [discuss] site layout for /maven/*
On 9 Jan 07, at 7:18 AM 9 Jan 07, Vincent Siveton wrote: Hi, In the same way of Brett's thread [1], WDYT to move all /maven/*/*-site to /maven/site/*? Actually, archiva, jxr and doxia have no standard layout for site and problems of deployment can appear (throw a glance to [2] about doxia site). We could consolidate them instead of. Thoughts? I like the sites with the projects as I would like something that 1) Facilitates deploying the site as an artifact and 2) Having the documentation with the project you're documenting. Moving it all to one place doesn't make any sense to me. Jason Cheers, Vincent [1] http://mail-archives.apache.org/mod_mbox/maven-dev/200701.mbox/% [EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/maven-dev/200701.mbox/% [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-eclipse-plugin] addVersionToProjectName
On 10 Jan 07, at 8:18 AM 10 Jan 07, Richard van der Hoff wrote: Jason van Zyl wrote: We're going to be releasing a new version (looking like tomorrow) so you can take a look at the roadmap after that. Wasn't there a release made like last week? What's changed this time? [I'd like to put in a bid for MECLIPSE-151's patch to be applied]. Sorry I'm talking about MNGECLIPSE, the Maven integration for Eclipse. Jason. Richard -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven-eclipse-plugin] addVersionToProjectName
Jason van Zyl wrote: We're going to be releasing a new version (looking like tomorrow) so you can take a look at the roadmap after that. Wasn't there a release made like last week? What's changed this time? [I'd like to put in a bid for MECLIPSE-151's patch to be applied]. Richard -- 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: [discuss] site layout for /maven/*
Vincent Siveton wrote: Hi, In the same way of Brett's thread [1], WDYT to move all /maven/*/*-site to /maven/site/*? Actually, archiva, jxr and doxia have no standard layout for site and problems of deployment can appear (throw a glance to [2] about doxia site). We could consolidate them instead of. Thoughts? I'm not sure if I see the why we'd like that as now the documentation is coupled to the source code which makes the most sense to me. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
