Re: Last remaining CI failures... EAR, Repository, Eclipse plugins
Hi, On 1/15/07, Brett Porter <[EMAIL PROTECTED]> wrote: Anyone have any ideas what these problems are? EAR: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2272&projectId=16&projectGroupId=2#org.apache.maven.plugin.ear.E arMojoTest XMLUnit asserts that the generated deployment descriptor is compliant regarding a particular project. The error we have is: Could not assert deployment descriptor The markup declarations contained or pointed to by the document type declaration must be well-formed 31,32,33 tests the jboss-app.xml configuration so I guess the problem lies there. I can't reproduce on my local box. I don't think I have access to this machine but if I do, let me know how and I'll have a look. Otherwise, check target/projects/project-XXX/target/jboss-app.xml or application.xml (where XXX is 031, 032 or 033). Nothing has changed on our side regarding this (same version of xmlunit, same version of EAR plugin, waiting for a release). I guess that something is wrong on this environment. Thanks, Stéphane Eclipse: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2273&projectId=17&projectGroupId=2 Repository: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2286&projectId=30&projectGroupId=2 Thanks, 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: Bazaar test failures
Hi, It's been a while since I updated the Bazaar provider, so it might be changes in Bazaar itself. I'll look into it in a day or two... Regards, Torbjørn On 1/15/07, Brett Porter <[EMAIL PROTECTED]> wrote: Hi, There appears to be a test failure in Continuum for Bazaar now that I have the client installed again. This is bzr-0.13, Python-2.5, Solaris 10 x86. http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2367&projectId=202&projectGroupId=16#org.apache.maven.scm.provid er.bazaar.command.changelog.BazaarChangeLogCommandTckTest Anyone have any ideas? - Brett
AntRun integration test failures
I get these locally as well as in CI. http://maven.zones.apache.org/continuum/buildResult.action? buildId=2374&projectId=4&projectName=Maven+AntRun+Plugin Any ideas? Also, is there a way we could get the integration tests to be via surefire so that we generate the normal reports? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Last remaining CI failures... EAR, Repository, Eclipse plugins
Anyone have any ideas what these problems are? EAR: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2272&projectId=16&projectGroupId=2#org.apache.maven.plugin.ear.E arMojoTest Eclipse: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2273&projectId=17&projectGroupId=2 Repository: http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2286&projectId=30&projectGroupId=2 Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
That doesn't actually matter for the client side speed boost. I'm running 1.4.2 on continuum now. - Brett On 15/01/2007, at 2:21 PM, Brian E. Fox wrote: The svn.apache.org server is a little old too: Powered by Subversion version 1.3.1 (r19032). -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, January 14, 2007 6:46 PM To: continuum-dev@maven.apache.org Subject: Re: Trusting in our own dog food yeah, it's subversion 1.1.4 (ouch!). I'm going to look at upgrading! On 11/01/2007, at 11:27 PM, Federico Yankelevich wrote: I read on svn changelog that SVN v1.4 increased a lot the speed for comparing local copy with repository. Maybe continuum is very slow in SVN update because it is using SVN 1.3 (both client and server needs to be updated) see http://subversion.tigris.org/svn_1.4_releasenotes.html just my 2 cents, Federico brettporter wrote: 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 -- View this message in context: http://www.nabble.com/Trusting-in-our- own-dog-food-tf2955860.html#a8276485 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: BUILD ERROR: Maven Plugins
I think so. I just updated to trunk. I'll look into it. On 15/01/2007, at 1:56 PM, Brian E. Fox wrote: Is this a continuum issue? "Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Unable to read the Maven project descriptor '/export/home/continuum/continuum_data/working-directory/1/pom.xml': add.project.artifact.not.found.error" The build works fine for me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, January 14, 2007 8:19 PM To: notifications@maven.apache.org Subject: [continuum] BUILD ERROR: Maven Plugins Online report : http://maven.zones.apache.org/continuum/buildResult.action? buildId=2208& projectId=1 Build statistics: State: Error Previous State: Ok Started at: Mon, 15 Jan 2007 01:17:39 + Finished at: Mon, 15 Jan 2007 01:19:19 + Total time: 1m 39s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java version : 1.5.0_09(Sun Microsystems Inc.) ** ** SCM Changes: ** ** Changed: brianf @ Mon, 15 Jan 2007 00:09:28 + Comment: MDEP-26: added site info Files changed: /maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/ apache/ma ven/plugin/dependency/AbstractDependencyMojo.java ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/ apache/ma ven/plugin/dependency/BuildClasspathMojo.java ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/ index.apt ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/ usage.apt ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/ apache/ma ven/plugin/dependency/TestBuildClasspathMojo.java ( 496197 ) ** ** SCM Changes since last success: ** ** ** ** Dependencies Changes: ** ** No dependencies changed ** ** Build Error: ** ** org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'deploy-artifact' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perf or mAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.buil d( DefaultBuildController.java:147) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.ex ec uteTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor $Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors $RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run (FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor $Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor $Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Unable to read the Maven project descriptor '/export/home/continuum/continuum_data/working-directory/1/pom.xml': add.project.artifact.not.found.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.ge tD eployableArtifacts(MavenTwoBuildExecutor.java:176) at org.apache.maven.continuum.core.action.DeployArtifactContinuumAction.e xe cute(DeployArtifactContinuumAction.java:106) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perf or mAction(DefaultBuildController.java:406) ... 8 more - 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
The svn.apache.org server is a little old too: Powered by Subversion version 1.3.1 (r19032). -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, January 14, 2007 6:46 PM To: continuum-dev@maven.apache.org Subject: Re: Trusting in our own dog food yeah, it's subversion 1.1.4 (ouch!). I'm going to look at upgrading! On 11/01/2007, at 11:27 PM, Federico Yankelevich wrote: > > I read on svn changelog that SVN v1.4 increased a lot the speed for > comparing local copy with repository. > Maybe continuum is very slow in SVN update because it is using SVN > 1.3 (both > client and server needs to be updated) > > see http://subversion.tigris.org/svn_1.4_releasenotes.html > > just my 2 cents, > Federico > > > > brettporter wrote: >> >> 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 >> >> > > -- > View this message in context: http://www.nabble.com/Trusting-in-our- > own-dog-food-tf2955860.html#a8276485 > Sent from the Continuum - Dev mailing list archive at Nabble.com.
FW: BUILD ERROR: Maven Plugins
Is this a continuum issue? "Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Unable to read the Maven project descriptor '/export/home/continuum/continuum_data/working-directory/1/pom.xml': add.project.artifact.not.found.error" The build works fine for me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, January 14, 2007 8:19 PM To: notifications@maven.apache.org Subject: [continuum] BUILD ERROR: Maven Plugins Online report : http://maven.zones.apache.org/continuum/buildResult.action?buildId=2208&; projectId=1 Build statistics: State: Error Previous State: Ok Started at: Mon, 15 Jan 2007 01:17:39 + Finished at: Mon, 15 Jan 2007 01:19:19 + Total time: 1m 39s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: maven.zones.apache.org Operating system : SunOS(unknown) Java version : 1.5.0_09(Sun Microsystems Inc.) SCM Changes: Changed: brianf @ Mon, 15 Jan 2007 00:09:28 + Comment: MDEP-26: added site info Files changed: /maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/apache/ma ven/plugin/dependency/AbstractDependencyMojo.java ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/apache/ma ven/plugin/dependency/BuildClasspathMojo.java ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/index.apt ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/usage.apt ( 496197 ) /maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/apache/ma ven/plugin/dependency/TestBuildClasspathMojo.java ( 496197 ) SCM Changes since last success: Dependencies Changes: No dependencies changed Build Error: org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'deploy-artifact' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build( DefaultBuildController.java:147) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.exec uteTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Unable to read the Maven project descriptor '/export/home/continuum/continuum_data/working-directory/1/pom.xml': add.project.artifact.not.found.error at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getD eployableArtifacts(MavenTwoBuildExecutor.java:176) at org.apache.maven.continuum.core.action.DeployArtifactContinuumAction.exe cute(DeployArtifactContinuumAction.java:106) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.perfor mAction(DefaultBuildController.java:406) ... 8 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release compiler plugin 2.0.2
-1 (sorry) * license headers are not updated * svn revision needs to be provided * staged bundle/snapshot needs to be provided otherwise in favour of preparing a release, though. As for the branch: what was it for before? - Brett On 15/01/2007, at 10:25 AM, Carlos Sanchez wrote: It fixes a couple of annoying issues for windows users http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&pid=11130&fixfor=12484 One question, can the 2.0.x branch no longer needed be deleted to avoid confusion? https://svn.apache.org/repos/asf/maven/plugins/branches/maven- compiler-plugin-2.0.x -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-solaris-plugin
Joerg, I'm actually in hot pursuit of discussions right now. If you look a few posts down you will see: Maven RPM Creation and Quality Control Factory I'm about to send this out on dev@mojo.codehaus.org, to see whether there's more interest there. I also forwarded your solaris mojo post to the Apache Directory project. dev@directory.apache.org If you by chance need a Solaris install of the Apache Directory server, I know we would love to work with you on it. Cheers, - Ole --- Joerg Hohwiller <[EMAIL PROTECTED]> wrote: > Hi there, > > for those who are interested: > http://jira.codehaus.org/browse/MNG-2761 > > Please get into discussion about creating deployment > packages (also DEB, RPM, > etc.) with maven. > > Regards > Jörg > > Hi > > > > I think the best way is to create an issue for the > sandbox component > > http://jira.codehaus.org/browse/MNG > > > > Cheers, > > > > Vincent > > > > 2006/8/29, Joerg Hohwiller <[EMAIL PROTECTED]>: > > Hi there, > > > > as I promised some time ago, I wanted to provide > my work in creating a > > maven2 > > plugin for solaris packaging. I uses an ant mojo > and only works on a > > solaris > > machine with pkgtools installed. > > > > For the moment I set in the POM > > groupId to org.apache.maven.plugins and artifactId > maven-solaris-plugin. > > > > Should I set groupId to org.codehaus.mojo instead? > > > > Where should I put the current state? > > > > I have the plugin itself and a dummy example > project that is using the > > plugin. > > Should I create the example as archtype? > > > > Best regards > > Jörg > >> > - > 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] > > Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven RPM Creation and Quality Control Factory
OK - I'll try dev@mojo.codehaus.org and hopefully they will see it. Thanks, - Ole --- Brett Porter <[EMAIL PROTECTED]> wrote: > http://svn.codehaus.org/mojo/c-builds/ > > Don't know if it has a web site up yet at > http://mojo.codehaus.org/ > > On 15/01/2007, at 11:03 AM, Ole Ersoy wrote: > > > Oh - cool - thanks Brett. > > > > Do you know what the project URL for c-builds is > by > > chance? > > > > I tried: > > > > http://c-builds.codehaus.org/ > > > > I also tried googleing, and > > looking through all the confluence projects > > at codehaus, but did not see a c-builds (Just so > you > > know I made attempts before asking :-) ) > > > > Thanks again, > > - Ole > > > > > > --- Brett Porter <[EMAIL PROTECTED]> wrote: > > > >> Seems consistent with what's happening in the > >> c-builds stuff at > >> mojo.codehaus.org - you might want to ask there? > >> > >> The additions to archiva sound interesting too. > >> > >> - Brett > >> > >> On 14/01/2007, at 3:35 AM, Ole Ersoy wrote: > >> > >>> Hi, > >>> > >>> I'm in need of a RPM repository that is yum > >>> accessible, where all the RPMs are produced by > >> Maven, > >>> and I wanted to check if anyone else is > interested > >> in > >>> the same thing? > >>> > >>> The primary goal is to be able to produce yum > >> installs > >>> of Apache and other servers/applications that > were > >>> built using a dependencies from a Maven > repository > >>> that is synchronized with the RPM repository. > >>> > >>> There will be a layer on top of this that > ensures > >>> Maven best practices with respect to dependency > >>> management and plugin management of the poms > that > >> are > >>> used to produce the RPM spec file (Later I want > to > >>> combine it with the Archiva server for automatic > >>> signature checking). > >>> > >>> Here's a brief synapsis of the > >> requirements/benefits. > >>> > >>> EASE OF USE > >>> - A Maven download with preconfigured repository > >>> settings pointing to a Maven repository that is > >> synced > >>> with the corresponding RPM repository is made > >>> available for download. The purpose of this > >> download > >>> is to minimize the effort required by developers > >> who > >>> wish to write artifacts that will commit RPMs to > >> the > >>> repository. Thus it will come with archetypes > >> that > >>> produce Java projects and other project which > >> ensure > >>> repository quality requirements are met. > >>> > >>> ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY > >>> - Only Maven artifacts will be allowed in the > RPM > >>> repository, at least in the beginning. The > reason > >> for > >>> this is to focus quality control automation > around > >> a > >>> set of Maven plugins. > >>> > >>> ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING > >> MAVEN > >>> PROJECT > >>> - This is so that RPMS are automatically > generated > >> and > >>> applications that depend on these RPMS have a > 1:1 > >>> match with the original dependencies that > >> developers > >>> used when creating the application / server. > >>> > >>> SERVER INSTALL AUTOMATION TOOLS FOR RPM > >>> - So that servers built from the maven artifacts > >> can > >>> be easily generated and installed. These > servers > >> will > >>> use an the standard UNIX/LINUX FHS layout, and > use > >>> best practices with respect to UNIX/LINUX file > >>> permissions and ownership. > >>> > >>> I have a lot of this work done already, I just > >> wanted > >>> to see whether there are others interested in > this > >>> type of approach and whether there are any > >> thoughts on > >>> how to go about creating the central location > for > >> this > >>> type of effort? > >>> > >>> Cheers, > >>> - Ole > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > __ > >> > >>> __ > >>> Don't pick lemons. > >>> See all the new 2007 cars at Yahoo! Autos. > >>> http://autos.yahoo.com/new_cars.html > >>> > >>> > >> > > > - > >>> 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] > >> > >> > > > > > > > > > > > __ > > > __ > > It's here! Your new message! > > Get new email alerts with the free Yahoo! Toolbar. > > > http://tools.search.yahoo.com/toolbar/features/mail/ > > > > > - > > 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 RPM Creation and Quality Control Factory
http://svn.codehaus.org/mojo/c-builds/ Don't know if it has a web site up yet at http://mojo.codehaus.org/ On 15/01/2007, at 11:03 AM, Ole Ersoy wrote: Oh - cool - thanks Brett. Do you know what the project URL for c-builds is by chance? I tried: http://c-builds.codehaus.org/ I also tried googleing, and looking through all the confluence projects at codehaus, but did not see a c-builds (Just so you know I made attempts before asking :-) ) Thanks again, - Ole --- Brett Porter <[EMAIL PROTECTED]> wrote: Seems consistent with what's happening in the c-builds stuff at mojo.codehaus.org - you might want to ask there? The additions to archiva sound interesting too. - Brett On 14/01/2007, at 3:35 AM, Ole Ersoy wrote: Hi, I'm in need of a RPM repository that is yum accessible, where all the RPMs are produced by Maven, and I wanted to check if anyone else is interested in the same thing? The primary goal is to be able to produce yum installs of Apache and other servers/applications that were built using a dependencies from a Maven repository that is synchronized with the RPM repository. There will be a layer on top of this that ensures Maven best practices with respect to dependency management and plugin management of the poms that are used to produce the RPM spec file (Later I want to combine it with the Archiva server for automatic signature checking). Here's a brief synapsis of the requirements/benefits. EASE OF USE - A Maven download with preconfigured repository settings pointing to a Maven repository that is synced with the corresponding RPM repository is made available for download. The purpose of this download is to minimize the effort required by developers who wish to write artifacts that will commit RPMs to the repository. Thus it will come with archetypes that produce Java projects and other project which ensure repository quality requirements are met. ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY - Only Maven artifacts will be allowed in the RPM repository, at least in the beginning. The reason for this is to focus quality control automation around a set of Maven plugins. ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING MAVEN PROJECT - This is so that RPMS are automatically generated and applications that depend on these RPMS have a 1:1 match with the original dependencies that developers used when creating the application / server. SERVER INSTALL AUTOMATION TOOLS FOR RPM - So that servers built from the maven artifacts can be easily generated and installed. These servers will use an the standard UNIX/LINUX FHS layout, and use best practices with respect to UNIX/LINUX file permissions and ownership. I have a lot of this work done already, I just wanted to see whether there are others interested in this type of approach and whether there are any thoughts on how to go about creating the central location for this type of effort? Cheers, - Ole __ __ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - 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] __ __ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - 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 RPM Creation and Quality Control Factory
Oh - cool - thanks Brett. Do you know what the project URL for c-builds is by chance? I tried: http://c-builds.codehaus.org/ I also tried googleing, and looking through all the confluence projects at codehaus, but did not see a c-builds (Just so you know I made attempts before asking :-) ) Thanks again, - Ole --- Brett Porter <[EMAIL PROTECTED]> wrote: > Seems consistent with what's happening in the > c-builds stuff at > mojo.codehaus.org - you might want to ask there? > > The additions to archiva sound interesting too. > > - Brett > > On 14/01/2007, at 3:35 AM, Ole Ersoy wrote: > > > Hi, > > > > I'm in need of a RPM repository that is yum > > accessible, where all the RPMs are produced by > Maven, > > and I wanted to check if anyone else is interested > in > > the same thing? > > > > The primary goal is to be able to produce yum > installs > > of Apache and other servers/applications that were > > built using a dependencies from a Maven repository > > that is synchronized with the RPM repository. > > > > There will be a layer on top of this that ensures > > Maven best practices with respect to dependency > > management and plugin management of the poms that > are > > used to produce the RPM spec file (Later I want to > > combine it with the Archiva server for automatic > > signature checking). > > > > Here's a brief synapsis of the > requirements/benefits. > > > > EASE OF USE > > - A Maven download with preconfigured repository > > settings pointing to a Maven repository that is > synced > > with the corresponding RPM repository is made > > available for download. The purpose of this > download > > is to minimize the effort required by developers > who > > wish to write artifacts that will commit RPMs to > the > > repository. Thus it will come with archetypes > that > > produce Java projects and other project which > ensure > > repository quality requirements are met. > > > > ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY > > - Only Maven artifacts will be allowed in the RPM > > repository, at least in the beginning. The reason > for > > this is to focus quality control automation around > a > > set of Maven plugins. > > > > ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING > MAVEN > > PROJECT > > - This is so that RPMS are automatically generated > and > > applications that depend on these RPMS have a 1:1 > > match with the original dependencies that > developers > > used when creating the application / server. > > > > SERVER INSTALL AUTOMATION TOOLS FOR RPM > > - So that servers built from the maven artifacts > can > > be easily generated and installed. These servers > will > > use an the standard UNIX/LINUX FHS layout, and use > > best practices with respect to UNIX/LINUX file > > permissions and ownership. > > > > I have a lot of this work done already, I just > wanted > > to see whether there are others interested in this > > type of approach and whether there are any > thoughts on > > how to go about creating the central location for > this > > type of effort? > > > > Cheers, > > - Ole > > > > > > > > > > > > > > > __ > > > __ > > Don't pick lemons. > > See all the new 2007 cars at Yahoo! Autos. > > http://autos.yahoo.com/new_cars.html > > > > > - > > 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] > > It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trusting in our own dog food
yeah, it's subversion 1.1.4 (ouch!). I'm going to look at upgrading! On 11/01/2007, at 11:27 PM, Federico Yankelevich wrote: I read on svn changelog that SVN v1.4 increased a lot the speed for comparing local copy with repository. Maybe continuum is very slow in SVN update because it is using SVN 1.3 (both client and server needs to be updated) see http://subversion.tigris.org/svn_1.4_releasenotes.html just my 2 cents, Federico brettporter wrote: 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 -- View this message in context: http://www.nabble.com/Trusting-in-our- own-dog-food-tf2955860.html#a8276485 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: Trusting in our own dog food
so... you're saying you don't trust our dog food? :) The only thing it tests differently is: - works by cron, whereas continuum might go down/hang/something else (which is something we should work on fixing if it does, rather than rely on ci.sh) - runs a reactor (can add that as a less frequent build execution in continuum too, though). So, I don't see any reason to keep it - wdyt? - Brett On 11/01/2007, at 7:57 PM, Trygve Laugstøl wrote: Brett Porter wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? I don't see why it should be turned off, but perhaps the automatic notifications can be turned off or just send failures. That way it would verify the product (it will in itself be an integration test) because if the Continuum instance says that something is failing, you should expect an email saying the same right after. Or at least you can check the logs directory if you're suspecting some other failure. -- Trygve
Re: [result] consolidate sandboxes
Hi brett, You can move it. Our scripts in the sandbox (except scm settings in the main POM) doesn't rely on a given path. Plugins in the sandbox are never called from the core. After the move, I'll just have to update the external in /maven-1/trunks Thx Arnaud On 1/15/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 15/01/2007, at 9:51 AM, Brett Porter wrote: >> /maven-1-plugins (from /maven-1/plugins-sandbox) Arnaud, I hestitated to do this one, just in case it mucks up any existing scripts/refs. I'll leave it up to those actively working on it as to whether this is the best idea or not. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release compiler plugin 2.0.2
It fixes a couple of annoying issues for windows users http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11130&fixfor=12484 One question, can the 2.0.x branch no longer needed be deleted to avoid confusion? https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler-plugin-2.0.x -- 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: Maven RPM Creation and Quality Control Factory
Seems consistent with what's happening in the c-builds stuff at mojo.codehaus.org - you might want to ask there? The additions to archiva sound interesting too. - Brett On 14/01/2007, at 3:35 AM, Ole Ersoy wrote: Hi, I'm in need of a RPM repository that is yum accessible, where all the RPMs are produced by Maven, and I wanted to check if anyone else is interested in the same thing? The primary goal is to be able to produce yum installs of Apache and other servers/applications that were built using a dependencies from a Maven repository that is synchronized with the RPM repository. There will be a layer on top of this that ensures Maven best practices with respect to dependency management and plugin management of the poms that are used to produce the RPM spec file (Later I want to combine it with the Archiva server for automatic signature checking). Here's a brief synapsis of the requirements/benefits. EASE OF USE - A Maven download with preconfigured repository settings pointing to a Maven repository that is synced with the corresponding RPM repository is made available for download. The purpose of this download is to minimize the effort required by developers who wish to write artifacts that will commit RPMs to the repository. Thus it will come with archetypes that produce Java projects and other project which ensure repository quality requirements are met. ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY - Only Maven artifacts will be allowed in the RPM repository, at least in the beginning. The reason for this is to focus quality control automation around a set of Maven plugins. ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING MAVEN PROJECT - This is so that RPMS are automatically generated and applications that depend on these RPMS have a 1:1 match with the original dependencies that developers used when creating the application / server. SERVER INSTALL AUTOMATION TOOLS FOR RPM - So that servers built from the maven artifacts can be easily generated and installed. These servers will use an the standard UNIX/LINUX FHS layout, and use best practices with respect to UNIX/LINUX file permissions and ownership. I have a lot of this work done already, I just wanted to see whether there are others interested in this type of approach and whether there are any thoughts on how to go about creating the central location for this type of effort? Cheers, - Ole __ __ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html - 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: [result] consolidate sandboxes
On 15/01/2007, at 9:51 AM, Brett Porter wrote: /maven-1-plugins (from /maven-1/plugins-sandbox) Arnaud, I hestitated to do this one, just in case it mucks up any existing scripts/refs. I'll leave it up to those actively working on it as to whether this is the best idea or not. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] consolidate sandboxes
Ok, I'm going ahead with this. On 12/01/2007, at 7:04 PM, Brett Porter wrote: Hi, Thought I'd put this to a vote in case others weren't following the proposal. Same as the previous proposal, so carrying over the +1 from Emmanuel, Dennis, Rahul, Trygve, Arnaud, Vincent S, Joakim, and myself unless they say otherwise. When we earlier opened the Maven sandbox to all ASF committers, I think it was the intention to do this for all sandboxes, but that wasn't the case in practice. To have a cleaner ACL, and cleaner externals on /trunks, I'd like to propose we consolidate the sandboxes. The structure would be: /maven/sandbox /maven /benchmark (from /sandbox) /maven-1.x-integration (from /sandbox) /shared /maven-artifact-tools (from /sandbox) /maven-repository-checker (from /sandbox) /maven-shared-jar (from /sandbox) /maven-shared-java-parser (from /sandbox) /maven-shared-license (from /sandbox) /plugins (as now) /other /acm (from /sandbox) /grafo (from /sandbox) /issue (from /sandbox) /marmalade (from /sandbox) /maven-dynamic-web (from /sandbox) /maven-metamorphosis (from /sandbox) /reports (from /sandbox) /ssh-tester (from /sandbox) /taxonomy (from /sandbox) /wiki (from /sandbox) /wagon /wagon-scm (from /sandbox) /scm (from /scm/trunk/sandbox) /surefire (from /surefire/trunk/sandbox) /doxia (from /doxia/trunk/sandbox) /continuum (from /continuum/sandbox) /archiva (from /archiva/sandbox) /maven-1-plugins (from /maven-1/plugins-sandbox) 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: [VOTE] Release Maven 2.0.5
Jason, Would you consider upgrading the dependency on modello-maven-plugin in maven-model to alpha-13 (or alpha-14 if that is released) for this release? It would bring in a couple of nice features for the generated documentation. If not, I'll add it to JIRA for 2.0.6. Also I found a couple of typos in maven.mdo that I fixed in trunk and the 2.0.x branch. Is it OK if I merge these into the 2.0.5 tag as well? Jason van Zyl wrote: Hi, The entire release is staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/ The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC That's about it. Play around with it, if there are things wrong and I'll fix stuff. We haven't released in so long there very well may be some problems. We should probably let it sit until Tuesday as most folks won't try it out over the weekend. +1 Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r495802 - in /maven/sandbox/wagon-scm: ./ src/main/java/org/apache/maven/wagon/providers/scm/ src/test/java/org/apache/maven/wagon/providers/scm/
[EMAIL PROTECTED] a écrit : Author: kenney Date: Fri Jan 12 16:42:33 2007 New Revision: 495802 URL: http://svn.apache.org/viewvc?view=rev&rev=495802 Log: Lots of fixes and improvements: * changed the ScmCvsExeWagonTest to extend from the abstractCVS wagon test, so it actually tests CVS and not SVN * disabled CVS testing because that is broken - it probably never worked. Last time I looked at wagon-scm (2 or 3 weeks ago), all worked. Emmanuel * Enabled all unit tests in the WagonTestCase (removed dummy overrides in AbstractScmWagonTest), and fixed the implementation so all tests pass. Removed the use of provider.getParent since that's not implemented everywhere. * had to update deps to cvs/svn scm's since I had to implement the list functionality for the new algorithm. Modified: maven/sandbox/wagon-scm/pom.xml maven/sandbox/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java maven/sandbox/wagon-scm/src/test/java/org/apache/maven/wagon/providers/scm/AbstractScmSvnWagonTest.java maven/sandbox/wagon-scm/src/test/java/org/apache/maven/wagon/providers/scm/AbstractScmWagonTest.java maven/sandbox/wagon-scm/src/test/java/org/apache/maven/wagon/providers/scm/ScmCvsExeWagonTest.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-solaris-plugin
c-builds folks seem to have some native packaging mojos. Perhaps this plugin belongs there. -D On 1/14/07, Joerg Hohwiller <[EMAIL PROTECTED]> wrote: Hi there, for those who are interested: http://jira.codehaus.org/browse/MNG-2761 Please get into discussion about creating deployment packages (also DEB, RPM, etc.) with maven. Regards Jörg > Hi > > I think the best way is to create an issue for the sandbox component > http://jira.codehaus.org/browse/MNG > > Cheers, > > Vincent > > 2006/8/29, Joerg Hohwiller <[EMAIL PROTECTED]>: > Hi there, > > as I promised some time ago, I wanted to provide my work in creating a > maven2 > plugin for solaris packaging. I uses an ant mojo and only works on a > solaris > machine with pkgtools installed. > > For the moment I set in the POM > groupId to org.apache.maven.plugins and artifactId maven-solaris-plugin. > > Should I set groupId to org.codehaus.mojo instead? > > Where should I put the current state? > > I have the plugin itself and a dummy example project that is using the > plugin. > Should I create the example as archtype? > > Best regards > Jörg >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-solaris-plugin
Hi there, for those who are interested: http://jira.codehaus.org/browse/MNG-2761 Please get into discussion about creating deployment packages (also DEB, RPM, etc.) with maven. Regards Jörg > Hi > > I think the best way is to create an issue for the sandbox component > http://jira.codehaus.org/browse/MNG > > Cheers, > > Vincent > > 2006/8/29, Joerg Hohwiller <[EMAIL PROTECTED]>: > Hi there, > > as I promised some time ago, I wanted to provide my work in creating a > maven2 > plugin for solaris packaging. I uses an ant mojo and only works on a > solaris > machine with pkgtools installed. > > For the moment I set in the POM > groupId to org.apache.maven.plugins and artifactId maven-solaris-plugin. > > Should I set groupId to org.codehaus.mojo instead? > > Where should I put the current state? > > I have the plugin itself and a dummy example project that is using the > plugin. > Should I create the example as archtype? > > Best regards > Jörg >> - 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]
MNG-1577 for 2.0.6
Ralph, Mike, Can you guys work in the /maven/sandbox on MNG-1577 so that when you think it's ready I can apply it to trunk and the branch? I think this would be the easiest way. I think we chatted briefly but on the branch the existing behaviour must be preserved with an option to turn on what we've deemed to be correct, and on the trunk it will be on by default. I am working to make the integration tests dead simple to use and will be done by time you start working on the patch in the sandbox. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven mirror
Ah cool, sounds like I am gonna use this one :) Thanks, Stéphane On 1/14/07, Cedric Gavage <[EMAIL PROTECTED]> wrote: FYI, We have added a mirror for Maven. [www] - http://maven2.mirrors.skynet.be/pub/maven2/ [ftp] - ftp://maven2.mirrors.skynet.be/pub/maven2/ Belgacom S.A. - Belgium. -- Cedric Gavage Belgacom S.A. - IT & Network Department Security, Internet & Applications http://www.belgacom.be DISCLAIMER http://www.belgacom.be/maildisclaimer - 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]
