Re: [vote] Release Continuum 1.0 alpha 1

[Emmanuel Venisse]

+1

Emmanuel

- Original Message - 
From: "Trygve Laugstøl" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 26, 2005 1:55 AM
Subject: [vote] Release Continuum 1.0 alpha 1


> Hi
>
> I would like to propose that we tag and release the current version in
> the Subversion repository as "Continuum 1.0 alpha 1".
>
> [ ] +1, yes I agree
> [ ] +0
> [ ] -1, no I don't agree, please state a reason
>
> --
> Trygve
>
>

Re: svn commit: r209718 - /maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/core/DefaultContinuumCore.java

[Emmanuel Venisse]

trygvis,

why do you do this? I think set the correct svn property 
(svn:eol-style=native) will be better?


Emmanuel

[EMAIL PROTECTED] wrote:

Author: trygvis
Date: Fri Jul  8 01:41:47 2005
New Revision: 209718

URL: http://svn.apache.org/viewcvs?rev=209718&view=rev
Log:
o dos2unix.

Modified:

maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/core/DefaultContinuumCore.java

Re: plexus-test-runtime missing when bundling runtime

[Emmanuel Venisse]

I don't have this error but I run with m2 trunk version.

how do you build continuum?
Are you under windows? if yes, where do you have checkouted continuum?

Emmanuel

Yann Le Du wrote:

Hi,

On build 219839, I got the following error. Indeed, the plexus-test-runtime
isn't created yet, but I can't see why... Did that happen to anybody else ?
(building with m2 alpha 3).

[INFO] [plexus:bundle-runtime]
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Diagnosis: Error while bundling runtime.
[INFO]

[ERROR] Cause: 
org.apache.maven.plugin.MojoExecutionException: Error while bundling runtime.

at
org.codehaus.plexus.maven.plugin.BundlePlexusRuntimeMojo.execute(BundlePlexusRuntimeMojo.java:88)
...

Caused by: org.codehaus.plexus.builder.runtime.PlexusRuntimeBuilderException:
Error while creating the archive.
at
org.codehaus.plexus.builder.runtime.DefaultPlexusRuntimeBuilder.bundle(DefaultPlexusRuntimeBuilder.java:244)
...

Caused by: org.codehaus.plexus.archiver.ArchiverException:
/devel/continuum/trunk/continuum-plexus-application/target/plexus-test-runtime
isn't a directory.
at
org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:117)
...






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Continuum build

[Emmanuel Venisse]

Hi,

I fixed the wagon-1.0-alpha-3 pom in the repo.

Continuum build correctly now. All poms are right for it now.

We have some problems in continuum-core-it on windows, I'll try to fix 
it today.


Emmanuel

Re: Continuum build error (unpublished/missing artifact)

[Emmanuel Venisse]

we have modified some pom that didn't respect pom model v4.0.0

you need to remove jpox, marmalade and wagon directories in your local 
repository for download new versions


and you need to have the svn version of m2 (trunk version)

Emmanuel

Rinku wrote:
Hi, 

On building latest snapshot of Continuum, on a Linux box I am getting the following error. 
Is there an alternate accessible repository where this artifact is available ? 


Thanks,

Rahul 




[INFO] [modello:java {execution: foo}]
[INFO] outputDirectory: 
/opt/applications/sources/continuum/trunk/continuum-model/target/generated-sources
[INFO] [resources:resources]
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Main Error:
  Unable to read the metadata file
  jpox:jpox-enhancer:1.1.0-beta-4-c1:jar

from the specified remote repositories:
  http://repo1.maven.org/maven2
Path to dependency:
1) org.apache.maven.continuum:continuum-model:jar:1.0-beta-1-SNAPSHOT



Root error:
  Unrecognised tag: 'url' (position: START_TAG seen ...\n  
... @19:12)
[INFO] 

[INFO] Total time: 39 seconds
[INFO] Finished at: Sat Jul 23 07:58:56 NZST 2005
[INFO] Final Memory: 6M/11M
[INFO] 

Re: plexus-test-runtime missing when bundling runtime

[Emmanuel Venisse]

you need to have the m2 trunk version for build continuum

Emmanuel

Yann Le Du wrote:

It seems to be working now... There are errors during the test phase, but at
least, the build is done.

Thanks,

Yann


--- Yann Le Du <[EMAIL PROTECTED]> a écrit :



Hi Emmanuel,

At first, I built with m2 trunk version (rev. 219874), but even before this
error I got another one :

[INFO] [plexus:app]
---
constituent[0]:
file:/devel/maven/maven/lib/maven-artifact-2.0-beta-1-SNAPSHOT.jar
...
constituent[23]:
file:/devel/maven/maven/lib/wagon-provider-api-1.0-alpha-4.jar
---
Exception in thread "main" java.lang.NoSuchMethodError:



org.apache.maven.project.artifact.MavenMetadataSource.(Lorg/apache/maven/artifact/resolver/ArtifactResolver;Lorg/apache/maven/project/MavenProjectBuilder;Lorg/apache/maven/artifact/factory/ArtifactFactory;)V


   at



org.codehaus.plexus.builder.AbstractBuilder.findArtifacts(AbstractBuilder.java:240)


...


So I tried with the "stable" version m2-alpha3... By the way, which practice
is
the "good" one, i.e. what maven build should I use ?

I am building on Linux, continuum is checkouted in /devel/continuum/trunk.
File
rights seem correct.

Yann




--- Emmanuel Venisse <[EMAIL PROTECTED]> a écrit :



I don't have this error but I run with m2 trunk version.

how do you build continuum?
Are you under windows? if yes, where do you have checkouted continuum?

Emmanuel

Yann Le Du wrote:


Hi,

On build 219839, I got the following error. Indeed, the


plexus-test-runtime


isn't created yet, but I can't see why... Did that happen to anybody else


?


(building with m2 alpha 3).

[INFO] [plexus:bundle-runtime]
[INFO]







[ERROR] BUILD ERROR
[INFO]







[INFO] Diagnosis: Error while bundling runtime.
[INFO]






[ERROR] Cause: 
org.apache.maven.plugin.MojoExecutionException: Error while bundling


runtime.


   at




org.codehaus.plexus.maven.plugin.BundlePlexusRuntimeMojo.execute(BundlePlexusRuntimeMojo.java:88)


...

Caused by:


org.codehaus.plexus.builder.runtime.PlexusRuntimeBuilderException:


Error while creating the archive.
   at




org.codehaus.plexus.builder.runtime.DefaultPlexusRuntimeBuilder.bundle(DefaultPlexusRuntimeBuilder.java:244)


...

Caused by: org.codehaus.plexus.archiver.ArchiverException:




/devel/continuum/trunk/continuum-plexus-application/target/plexus-test-runtime


isn't a directory.
   at




org.codehaus.plexus.archiver.AbstractArchiver.addDirectory(AbstractArchiver.java:117)


...









___


Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo!


Messenger 


Téléchargez cette version sur http://fr.messenger.yahoo.com












___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com











___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: [continuum build - SUCCESS - update] Tue Aug 23 22:30:00 GMT 2005

[Emmanuel Venisse]

I think brett run it on cygwin.
Personally, I run it withoutout cygwin.

Can you send us the output?

Emmanuel

Rinku wrote:


Yes, I get a failure for Integration tests (ShellIntegrationTest 
failure) and couple of exceptions. I can confirm all the environment 
variables below are set.


Are you running your builds on cygwin?

Thanks for the help.

Cheers,

Rahul



- Original Message - From: "Brett Porter" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, August 25, 2005 12:01 AM
Subject: Re: [continuum build - SUCCESS - update] Tue Aug 23 22:30:00 
GMT 2005




Works for me. I assume it is the integration tests that fail? Make sure
you have Ant, Maven and M2 installed, with ANT_HOME, MAVEN_HOME and
M2_HOME set.

- Brett

Rinku wrote:


Hi,

What platform are Continuum builds succeeding on?

I am using XP and update and build M2 prior to updating and building
Continuum, but never get a successful build :-(

Anyone building on XP ? or is it known that build still has errors on 
XP.


Cheers,

Rahul

- Original Message - From: <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, August 24, 2005 10:37 AM
Subject: [continuum build - SUCCESS - update] Tue Aug 23 22:30:00 GMT
2005



Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20050823.223000.tar.gz 




Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050823.223000.txt 

Re: [continuum build - FAILED - update] Fri Sep 2 17:00:00 GMT 2005

[Emmanuel Venisse]

Brett,

Can you check this error? I think is due to your latest changes in m2.

Emmanuel

[EMAIL PROTECTED] wrote:

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050902.17.txt

Re: build errors

[Emmanuel Venisse]

Can you send stacktrace?

Emmanuel

Ashley Williams wrote:
Hi, I'm trying to build continuum and have been diligently preparing  
those jar files that don't automatically get downloaded. However the  
build still fails with a classnotfoundexception: SMTPTransport.html.  
This isn't actually in the mail.jar file I got from sun, but it is in  
the smtp.jar file and there doesn't seem to be a dependency on it in  
the build, else presumably I would have got a repository download  
exception. Am I supposed to add it in my java lib directory?


Don't know if it's important but I'm using Mac OS X.

AW

Re: priorities for beta-1

[Emmanuel Venisse]

Brett Porter wrote:

Hi,

These are all in JIRA. I've been talking to people setting up an
instance for ActiveMQ and related projects, and I'm thinking these are
the top development priorities for now:

1) Blame mechanism
2) Inclusion of junit test results
3) Security
4) browse working copy

Thoughts?

Also, I think we should consider trimming up the beta-1 release to just
new features and slate all the fixes for beta-2 to try and get it out
sooner. Does this sound reasonable?

- Brett

Re: priorities for beta-1

[Emmanuel Venisse]

all is ok for me.

Emmanuel

Brett Porter wrote:

Hi,

These are all in JIRA. I've been talking to people setting up an
instance for ActiveMQ and related projects, and I'm thinking these are
the top development priorities for now:

1) Blame mechanism
2) Inclusion of junit test results
3) Security
4) browse working copy

Thoughts?

Also, I think we should consider trimming up the beta-1 release to just
new features and slate all the fixes for beta-2 to try and get it out
sooner. Does this sound reasonable?

- Brett

Re: [vote] Release 1.0-alpha-4

[Emmanuel Venisse]

[X] +1 release it
[ ] -1 don't release it: fix _ first


Emmanuel

Re: Continuum Build: Integration Test failures

[Emmanuel Venisse]

I see failures in the continuous integration environment however - there
may be something else wrong. I will have a look tomorrow.



yes, it's a strange failure appeared after the clean repo and full 
checkout process. I fixed all test yesterday. We have perhaps a bad jar 
downloaded in the repo of ci platform, because I tryied to build all 
with a clean repo like it's done on the ci platform and all build fine here.


Will check after a new full clean/checkout process.

Emmanuel

Re: Continuum Build: Integration Test failures

[Emmanuel Venisse]

The problem is due to a missing pom in local repo :

[WARNING]
  * Using defaults for missing POM 
org.apache.maven.plugins:maven-clean-plugin:pom:2.0-beta-2-SNAPSHOT *


Emmanuel

Emmanuel Venisse wrote:


I see failures in the continuous integration environment however - there
may be something else wrong. I will have a look tomorrow.



yes, it's a strange failure appeared after the clean repo and full 
checkout process. I fixed all test yesterday. We have perhaps a bad jar 
downloaded in the repo of ci platform, because I tryied to build all 
with a clean repo like it's done on the ci platform and all build fine 
here.


Will check after a new full clean/checkout process.

Emmanuel

Re: svn commit: r290250 - in /maven/continuum/trunk: continuum-plexus-application/pom.xml pom.xml

[Emmanuel Venisse]

It wasn't reactivated in parent pom, so I don't know.

Emmanuel

Brett Porter wrote:

I thought XFire was working now?

- Brett

[EMAIL PROTECTED] wrote:



Author: evenisse
Date: Mon Sep 19 12:42:46 2005
New Revision: 290250

URL: http://svn.apache.org/viewcvs?rev=290250&view=rev
Log:
o Fix final name
o Remove continuum-xfire from dependency management

Modified:
  maven/continuum/trunk/continuum-plexus-application/pom.xml
  maven/continuum/trunk/pom.xml

Modified: maven/continuum/trunk/continuum-plexus-application/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/continuum/trunk/continuum-plexus-application/pom.xml?rev=290250&r1=290249&r2=290250&view=diff
==
--- maven/continuum/trunk/continuum-plexus-application/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-application/pom.xml Mon Sep 19 
12:42:46 2005
@@ -211,7 +211,7 @@
   
 src/assembly/bin.xml
 
-  continuum-1.0-alpha-4-SNAPSHOT
+  continuum-1.0-alpha-4
   
   
 

Modified: maven/continuum/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/continuum/trunk/pom.xml?rev=290250&r1=290249&r2=290250&view=diff
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Mon Sep 19 12:42:46 2005
@@ -149,11 +149,13 @@
   continuum-web
   1.0-alpha-4-SNAPSHOT
 
+  
 
   org.apache.maven.continuum
   continuum-xmlrpc

Re: Continuum Build: Integration Test failures

[Emmanuel Venisse]

Can you run this command in continuum-core-it?

m2 clean:clean package -Dtest=ShellIntegrationTest

Emmanuel

Rinku wrote:

and here's the log for the second failure...

cheers,

Rahul

- Original Message - From: "Emmanuel Venisse" 
<[EMAIL PROTECTED]>

To: 
Sent: Monday, September 19, 2005 1:30 AM
Subject: Re: Continuum Build: Integration Test failures



The problem is due to a missing pom in local repo :

[WARNING]
  * Using defaults for missing POM 
org.apache.maven.plugins:maven-clean-plugin:pom:2.0-beta-2-SNAPSHOT *


Emmanuel

Emmanuel Venisse wrote:



I see failures in the continuous integration environment however - 
there

may be something else wrong. I will have a look tomorrow.



yes, it's a strange failure appeared after the clean repo and full 
checkout process. I fixed all test yesterday. We have perhaps a bad 
jar downloaded in the repo of ci platform, because I tryied to build 
all with a clean repo like it's done on the ci platform and all build 
fine here.


Will check after a new full clean/checkout process.

Emmanuel





--- 


Battery: org.apache.maven.continuum.it.ShellIntegrationTest
--- 


testBasic(org.apache.maven.continuum.it.ShellIntegrationTest)

[ stdout ] ---

[WARNING] The specified JAR repository doesn't exist or is not a 
directory: 
'C:\continuum\continuum-core-it\target\level1\level2\plexus-home\lib'.
2005-08-25 08:24:31,796 [main] DEBUG PlexusContainer- 
Found 3 components to load on start
2005-08-25 08:24:31,796 [main] INFO  PlexusContainer- 
Loading on start [role]: [org.apache.maven.continuum.Continuum]
2005-08-25 08:24:31,796 [main] INFO  JdoFactory - 
Initializing JDO.
2005-08-25 08:24:31,796 [main] INFO  JDO- 
PersistenceManagerFactory - Vendor: JPOX  Version: 1.1.0-beta-4-SNAPSHOT
2005-08-25 08:24:31,796 [main] INFO  JDO- 
PersistenceManagerFactory initialised for datastore 
URL=jdbc:derby:C:\continuum\continuum-core-it\target\level1\level2\plexus-home/database;create=true 
driver=org.apache.derby.jdbc.EmbeddedDriver userName=sa
2005-08-25 08:24:31,796 [main] INFO  RAMJobStore- 
RAMJobStore initialized.
2005-08-25 08:24:31,796 [main] INFO  StdSchedulerFactory- 
Quartz scheduler 'scheduler1' initialized from an externally provided 
properties instance.
2005-08-25 08:24:31,796 [main] INFO  StdSchedulerFactory- 
Quartz scheduler version: 1.4.5
2005-08-25 08:24:31,796 [main] INFO  QuartzScheduler- 
Scheduler scheduler1_$_NON_CLUSTERED started.
2005-08-25 08:24:31,796 [main] INFO  Continuum  - 
Initializing Continuum.
2005-08-25 08:24:31,796 [main] INFO  Continuum  - 
Showing all projects: 2005-08-25 08:24:31,812 [main] INFO  
RDBMS  - RDBMS Adapter initialised : 
CloudscapeAdapter : Apache Derby version=10.0.2.1, major=10, minor=0, 
revision=2
Identifier Names : UPPERCASE Driver name=Apache Derby Embedded JDBC 
Driver, version=10.0.2.1, major=10, minor=0
Identifier Max Lengths : Table=128  Column=30  Constraint=18  Index=18  
Delimeters="

Identifier Support in DDL : catalog=false  schema=true
2005-08-25 08:24:31,812 [main] INFO  SCHEMA - 
Initialising Catalog "", Schema "SA" using "SchemaTable" auto-start option
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of 
org.apache.maven.continuum.model.project.ProjectDependency since it was 
managed previously
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of org.apache.maven.continuum.model.project.Profile 
since it was managed previously
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of org.apache.maven.continuum.model.scm.ScmResult 
since it was managed previously
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of 
org.apache.maven.continuum.model.project.ProjectDeveloper since it was 
managed previously
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of 
org.apache.maven.continuum.model.project.ProjectNotifier since it was 
managed previously
2005-08-25 08:24:31,843 [main] INFO  JDO- 
Managing Persistence of 
org.apache.maven.continuum.model.project.BuildResult since it was 
managed previously
2005-08-25 08:24:31,859 [main] INFO  JDO- 
Managing Persistence of 
org.apache.maven.continuum.model.system.Installation since it was 
managed previously
200

[Result] [vote] release beta-1

[Emmanuel Venisse]

Votes:
Binding +1 Brett, Emmanuel, Vincent M, Arnaud
Community +1 Jonny, Allan

Release is made.

Emmanuel

Brett Porter a écrit :

Hi,

Please vote on releasing continuum 1.0 beta 1


From me, +1


- Brett

[ANN] Continuum 1.0 Beta 1 Released

[Emmanuel Venisse]

The Maven team is pleased to announce the 1.0-beta-1 release of
Continuum. This release offers users both an advance look at what's in
Continuum 1.0 and a head start in helping to shape the final Continuum
release.

You can find everything here:

http://maven.apache.org/continuum";>http://maven.apache.org/continuum

The binaries can be found here:

href="http://maven.apache.org/continuum/download.html";>http://maven.apache.org/continuum/download.html


Among the improvements, we have now:
 - User/Group management
 - Added security features
 - Added blame mechanism
 - Added working copy browser
 - Added configuration page

The change log can be found here: href="http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=11908";>http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=11908


Features that already exist :
 - support of Maven1, Maven2, Ant and shell projects
 - scheduled and forced build
 - build definitions with command line settings
 - SCM supported : CVS, Subversion, Starteam
 - notification by mail, irc, MSN, Jabber

Re: [continuum build - FAILED - update] Thu Oct 20 07:00:00 GMT 2005

[Emmanuel Venisse]

Brett,

Do you have an idea about the pb in continuum-test?

Emmanuel

[EMAIL PROTECTED] a écrit :

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051020.07.txt

[ANN] Continuum 1.0 Final released

[Emmanuel Venisse]

The Maven team is pleased to announce the 1.0 of Continuum. Continuum is a
continous integration server.

We have progressively improved Continuum over five previous releases and now 
provides
the following features:

 * Support for Maven 2.x

 * Support for Maven 1.x

 * Support for Ant

 * Support for shell scripts

 * Tight integration with Maven SCM

* Subversion

* CVS

* Starteam

 * Easy to use web-based setup and  interface

 * XML-RPC and SOAP interfaces for integration, automation and remoting

 * Mail Notification

 * IM notification

   * IRC

   * Jabber

   * MSN

 * Blame Mechanism

For a complete list of changes please refer to the complete changelog:

http://maven.apache.org/continuum/change-log.html

To get started with Continuum take a look at the download and install
instructions:

http://maven.apache.org/continuum/download.html

And then take a look at our getting started guide:

http://maven.apache.org/continuum/guides/getting-started/index.html

[vote] Release Continuum 1.0.1

[Emmanuel Venisse]

Hi,

Please vote on releasing continuum 1.0.1

>From me, +1

Emmanuel

[ANN] Continuum 1.0.1 released

[Emmanuel Venisse]

The Maven team is pleased to announce Continuum 1.0.1. Continuum is a continous 
integration server.


This release includes the following improvements :

 * Support for domain names and ssl in jabber notifier

 * Support for registered nicks in irc notifier

 * Support for shell commands defined in user path

 * Improved cron expression validator

 * Bug fixes

For a complete list of changes please refer to the complete changelog:

http://maven.apache.org/continuum/change-log.html

To get started with Continuum take a look at the download and install 
instructions:

http://maven.apache.org/continuum/download.html

And then take a look at our getting started guide:

http://maven.apache.org/continuum/guides/getting-started/index.html

Re: svn commit: r345188 - /maven/continuum/trunk/continuum-api/pom.xml

[Emmanuel Venisse]

why do you add it? It comes with transitive dependencies.

Emmanuel

[EMAIL PROTECTED] a écrit :

Author: brett
Date: Wed Nov 16 20:43:09 2005
New Revision: 345188

URL: http://svn.apache.org/viewcvs?rev=345188&view=rev
Log:
this is required to compile

Modified:
maven/continuum/trunk/continuum-api/pom.xml

Modified: maven/continuum/trunk/continuum-api/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/continuum/trunk/continuum-api/pom.xml?rev=345188&r1=345187&r2=345188&view=diff
==
--- maven/continuum/trunk/continuum-api/pom.xml (original)
+++ maven/continuum/trunk/continuum-api/pom.xml Wed Nov 16 20:43:09 2005
@@ -14,8 +14,12 @@
   plexus-formica
 
 
+  org.codehaus.plexus
+  plexus-utils
+
+
   org.apache.maven.continuum
   continuum-model
 
   
-
\ No newline at end of file
+

Re: [continuum build - FAILED - update] Thu Nov 17 08:00:00 GMT 2005

[Emmanuel Venisse]

What's happen with plexus dependencies? poms are invalid.

Emmanuel

[EMAIL PROTECTED] a écrit :

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051117.08.txt

Re: Can't find jca artifact - jca-1.0.0.jar

[Emmanuel Venisse]

http://java.sun.com/j2ee/connector/download.html

Eric Starr a écrit :

I can't seem to find the jca artifact. I have looked on sun's website and
all I seem to find are solaris and linix versions of Java(tm) Communication
API 3.0 Update 1.
http://www.sun.com/download/products.xml?id=43208d3d

I am using WinXP. Anyone know where I can find a windows version?

I need this because I downloaded the latest code and attempted to build it,
but the build fails telling me that I need this artifact.

Downloading: http://repo1.maven.org/maven2/jca/jca/1.0.0/jca-1.0.0.jar
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org/maven2)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

GroupId: jca
ArtifactId: jca
Version: 1.0.0

Reason: Unable to download the artifact from any repository
jca:jca:1.0.0:jar

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
snapshots (http://snapshots.maven.codehaus.org/maven2)

Thanks,
Eric

Re: Multiple Build Definitions

[Emmanuel Venisse]

David Blevins a écrit :
I'm still not sure how having multiple build definitions comes into  
play.  I see now real way to use anything but the default.


The default build definition is used when you choose to force a build from web 
interface.



It's also a little confusing how the dont-execute-the-build-if-the- 
source-hasnt-changed-feature comes into play.  They all have their  own 
schedule and the source could get updated at anytime.  Is it just  a 
roll of the dice which build definition gets executed?  Seems the  first 
one to check would always be the one executed and the others  with 
perhaps a less aggressive schedule would never get used.  Or  what 
happens if build definitions have the same schedule, which gets  used then?


You're right. Actually, they will never used if there are no updates since 
first one execution.
We'll fix this in future version (certainly 1.1). Users will can choose on each build definitions to 
run them with a full checkout, always with an update or only if there are changes in update.


It isn't recommanded to have more than one build definition on a schedule. 
We'll run only the first one.



Seems there is something useful there about having multiple build  
definitions, though I just can't see the vision with what has been  
implemented so far.


-David

Re: Design - Replacing Continuum's Web Framework

[Emmanuel Venisse]

Carlos,

do you have a simple sample that use acegi?

Emmanuel

Carlos Sanchez a écrit :

Acegi is based in servlet filters for the protection of urls, so the
web framework used won't impact its use.
Are you planning protecting just urls or any other stuff? acegi can do
authorization and authentication at class, method and instance level
too, but I think that's only needed in a few types of applications.

I was in a project using JSF and seems that it's adoption is getting
speed, with different implementations and a lot of extensions,
utilities and tools. I've heard very good things about using
Facelets+JSF to create components, and also about Spring MVC, but
seems to me that people using Spring MVC is moving to JSF.

My 2 cents


On 12/1/05, John Casey <[EMAIL PROTECTED]> wrote:


Hi everyone,

We've been talking about this for quite awhile in various channels, and
I wanted to take a few minutes and formalize the discussion. I'll
capture the highlights of this discussion in the wiki afterwards. I'll
start by posting my own thoughts, and let you all respond.

Up to this point, Continuum has been built on a web framework called
Summit, which is part of the Plexus project, and using Velocity as the
page rendering technology. Summit is still a very young project, and as
a result has its problems. Given the proliferation of web frameworks out
there, it seems natural to wonder whether we couldn't find something
more mainstream and mature that will fit our needs.

The key goal here is to make the web tier as easy to understand as
possible by the widest possible audience, without sacrificing anything
in the way of quality. To that end, criteria might include:

* tool support
* maturity in the form of multiple final releases (or at least one)
* good integration with JSP (it's the most widely-used rendering
technology out there for java)
* ready availability of good documentation
* integration with a decent security library (think acegi)
* others?

Another big concern is that we need to be able to make this web
framework integrate with Plexus without too much funny business. I don't
expect that to be a big problem, but worth mentioning.

I know that a certain amount of work has been done by Trygve and
Emmanuel to get WebWork running inside Plexus. Is this the best
framework? A quick check of Amazon showed three books, only one of which
is completely concerned with WW. SpringMVC might be another option,
since it has probably the most natural integration with Acegi. There is
a certain amount of overlap between Spring and Plexus that we'd probably
have to map with a custom Spring container or something, but that's
likely to be everywhere, since dependency injection is such a hot topic
(and very useful).

What do you all think?

-john

Continuum 1.0.2 is released

[Emmanuel Venisse]

  The Apache Maven team is pleased to announce Continuum 1.0.2.

  Continuum 1.0.2 is available for download from 
http://maven.apache.org/continuum/download.html

  Continuum is a continous integration server that will ensure the health of 
your code base.

  This release includes the following improvements:

   * Improved performance

   * Support for Clearcase

   * Support for Perforce

   * Added a default build definition for Ant project

   * Added specific build definition screens for Ant and shell projects

   * Added support of Ant build file in a subdirectory

   * Allowed modification of default schedule

   * Bug fixes

  We hope you enjoy using Continuum! If you have any questions, please consult:

* The web site: http://maven.apache.org/continuum/

* The continuum-user mailing list: 
http://maven.apache.org/continuum/mail-lists.html

  For news and information, see:

* Maven Blogs: http://www.mavenblogs.com/

[Proposal] Continuum refactoring

[Emmanuel Venisse]

Hi,

I'd like to know your opinions about the continuum refactoring for 1.1

What we'll do?

Replace plexus-summit/velocity by JSP/WebWork/SiteMesh

What i'd like to do?

Actually, DefaultContinuum class is our centralized code class. With a framework like webwork, i 
think we can improve the architecture by splitting it with this :

- all data manipulations (CRUD) will be in several DAO classes
- all utility methods (is*InQueue, checkoutProject, buildProject* will be in several utility classes 
(or action classes in webwork terms)

- in DefaultContinuum, we'll keep only initialization methods

With this refactoring, i think it will be more easy to migrate to webwork, and maintenance will be 
more easy.


WDYT?

Emmanuel

Re: [Proposal] Continuum refactoring

[Emmanuel Venisse]

ok, so we'll have some data object store access (ProjectStore, BuildStore...) and DefaultContinuum 
will use them. Webwork actions will use them too or they'll use Continuum interface?


Emmanuel

Brett Porter a écrit :

+1

I'm all for splitting up into action components, but retaining a
Continuum interface as a single entry point to those

- Brett

John Casey wrote:


I think we have to be careful when splitting up a public api like
this. It's possible Continuum may need to be embedded someday, and if
so, it would be much better to have a single interface for controlling
it...even if it means that interface delegates most of its work. While
I think you can probably factor out a lot of the actual logic, we need
to preserve that coherent, single-interface accessibility IMO.
Besides, we do still have to maintain public API compatibility, since
it's only a x.y release...

My 2 cents.

-john

Emmanuel Venisse wrote:


Hi,

I'd like to know your opinions about the continuum refactoring for 1.1

What we'll do?

Replace plexus-summit/velocity by JSP/WebWork/SiteMesh

What i'd like to do?

Actually, DefaultContinuum class is our centralized code class. With
a framework like webwork, i think we can improve the architecture by
splitting it with this :
- all data manipulations (CRUD) will be in several DAO classes
- all utility methods (is*InQueue, checkoutProject, buildProject*
will be in several utility classes (or action classes in webwork terms)
- in DefaultContinuum, we'll keep only initialization methods

With this refactoring, i think it will be more easy to migrate to
webwork, and maintenance will be more easy.

WDYT?

Emmanuel

Re: Continuum v1.0.2 on MacOSX - no startup

[Emmanuel Venisse]

It's a known issue with wrapper (http://jira.codehaus.org/browse/CONTINUUM-385)

You can use bin/plexus.sh instead

Emmanuel

Graham Leggett a écrit :

Hi all,

Following the MacosX instructions for starting continuum, I managed to 
get this far:


Graham-Leggetts-Computer:~/Desktop/continuum/continuum-1.0.2/bin/macosx 
minfrin$ ./run.sh start

Starting continuum...
Graham-Leggetts-Computer:~/Desktop/continuum/continuum-1.0.2/bin/macosx 
minfrin$ ./run.sh stop

Stopping continuum...
Removed stale pid file: ./continuum.pid
continuum was not running.

I am now trying to figure out why continuum didn't start.

According to the MacOSX console, the wrapper crashed:


**

Host Name:  Graham-Leggetts-Computer
Date/Time:  2006-01-06 14:15:50.315 +0200
OS Version: 10.4.3 (Build 8F46)
Report Version: 3

Command: wrapper
Path:
/Users/minfrin/Desktop/continuum/continuum-1.0.2/bin/macosx/wrapper

Parent:  launchd [1]

Version: ??? (???)

PID:9289
Thread: Unknown

Link (dyld) error:

Symbol not found: _ftime
  Referenced from: 
/Users/minfrin/Desktop/continuum/continuum-1.0.2/bin/macosx/w

rapper
  Expected in: /usr/lib/libcrypto.0.9.7.dylib


Does anyone know what's up with this build, and whether it works on 
MacosX v10.4.3?


Regards,
Graham
--

Re: Errors running 1.1-SNAPSHOT

[Emmanuel Venisse]

1.1 isn't usable for the moment.
If you want to try it, you must use the war generated in continuum-webapps, and installed it in 
jetty6 beta


Emmanuel

Jens Zastrow a écrit :

After building with ">sh build.sh" i can create the "root" user.
Trying to login results allways in:

org.codehaus.plexus.action.ActionNotFoundException: Cannot find action:
login
at
org.codehaus.plexus.action.DefaultActionManager.lookup(DefaultActionMana
ger.java:61)
at
org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve
.java:62)
at
org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipe
line.java:70)
at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54)
at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520)
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupExcept
ion: Unable to lookup component
'org.codehaus.plexus.action.Actionlogin', it could not be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:335)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:436)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.PlexusContainerLo
cator.lookup(PlexusContainerLocator.java:38)
at
org.codehaus.plexus.action.DefaultActionManager.lookup(DefaultActionMana
ger.java:57)
... 19 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleExc
eption: Error starting component
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:327)
... 22 more
Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionExc
eption: Error composing component
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.
execute(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
... 25 more
Caused by:
org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field authenticator in object of type
org.apache.maven.continuum.web.action.Login because the requirement
ComponentRequirement{role='org.codehaus.plexus.security.Authenticator',
roleHint='built-in-store', fieldName='null'} was missing
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignR
equirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembl
eComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManage
r.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexu
sContainer.java:1476)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.
execute(CompositionPhase.java:29)
... 27 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupExcept
ion: Unable to lookup component
'org.codehaus.plexus.security.Authenticatorbuilt-in-store', it could not
be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:335)

Re: gbuild: maven scm updater issue

[Emmanuel Venisse]

I've never seen this error before.
How do you have updated your continuum to continuum-1.0.2?
Do you have all lib? a valid application.xml for 1.0.2?

Emmanuel

David Blevins a écrit :
I seem to have gotten a bad snapshot on my last build and now all the  
gbuild agents fail on scm update.  I was using an old continuum-1.1- 
SNAPSHOT but started running into this issue and changed it to  
continuum-1.0.2 for sanity sake, but still get the same issue.


Seems to all be triggered by a NoClassDefFoundError for "org/apache/ 
maven/artifact/versioning/InvalidVersionSpecificationException"  Not  
sure where this is coming from or why this isn't getting sucked in  
transitively.


Any ideas?

-David



2006-01-16 21:27:29,143 [Thread-2] INFO   ScmManager 
- Executing: svn --non-interactive update
2006-01-16 21:27:29,144 [Thread-2] INFO   ScmManager 
- Working directory: /home/dblevins/ 
gbuild-agent-1.0-SNAPSHOT/bin/linux/../../apps/gbuild-agent/agent/ work/51
2006-01-16 21:27:30,100 [Thread-130] DEBUG  
ScmManager - At revision 1131.

-
this realm = plexus.application.gbuild-agent
urls[0] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-model-2.0.jar
urls[1] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-artifact-manager-2.0.jar
urls[2] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/ognl-2.6.7.jar
urls[3] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/continuum-store-1.0.2.jar
urls[4] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/backport-util-concurrent-2.0_01_pd.jar
urls[5] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-settings-2.0.jar
urls[6] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/commons-cli-1.0.jar
urls[7] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/commons-pool-1.2.jar
urls[8] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/jca-1.0.0.jar
urls[9] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-scm-api-1.0-beta-2.jar
urls[10] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/plexus-velocity-1.1.2.jar
urls[11] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-artifact-2.0-alpha-2.jar
urls[12] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/jpox-dbcp-1.1.0-beta-4.jar
urls[13] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/doxia-sink-api-1.0-alpha-4.jar
urls[14] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-repository-metadata-2.0.jar
urls[15] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/jaas-1.0.1.jar
urls[16] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/commons-logging-api-1.0.4.jar
urls[17] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/plexus-action-1.0-alpha-6.jar
urls[18] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/continuum-api-1.0.2.jar
urls[19] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-scm-provider-svn-1.0-beta-2.jar
urls[20] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-plugin-parameter- 
documenter-2.0.jar
urls[21] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/continuum-notifier-api-1.0.2.jar
urls[22] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/commons-collections-2.0.jar
urls[23] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/plexus-jdo2-1.0-alpha-3.jar
urls[24] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/regexp-1.3.jar
urls[25] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/jpox-1.1.0-beta-4.jar
urls[26] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/concurrent-1.3.4.jar
urls[27] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/maven-plugin-descriptor-2.0.jar
urls[28] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/gbuild-agent-1.0-SNAPSHOT.jar
urls[29] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/derby-10.1.1.0.jar
urls[30] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ 
linux/../../apps/gbuild-agent/lib/m

Re: [continuum-build-log-20060127.020000] java.lang.NoSuchMethodError running

[Emmanuel Venisse]

The code in trunk isn't finished. I use an old version of plexus-utils for now 
for tracking some bug.

Replace plexus-utils in lib directory by a more recent version (1.1)

Note that this war isn't finished yet, so, you'll get lot of bug and no security. Why do you need a 
snapshot version?


Emmanuel

Jens Zastrow a écrit :

i installed a fresh Tomcat 5.5.15 and deployed the continuum-war.
i was able to add a maven2 project but building it results in a
java.lang.NoSuchMethodError.

java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.addSystemE
nvironment()V
at
org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.exec
uteShellCommand(DefaultShellCommandHelper.java:71)
at
org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.exec
uteShellCommand(DefaultShellCommandHelper.java:53)
at
org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShe
llCommand(AbstractBuildExecutor.java:190)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.b
uild(MavenTwoBuildExecutor.java:86)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.
execute(ExecuteBuilderContinuumAction.java:124)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.bui
ld(DefaultBuildController.java:232)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.e
xecuteTask(BuildProjectTaskExecutor.java:53)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Exe
cutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
at java.lang.Thread.run(Thread.java:595) 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Friday, January 27, 2006 3:35 AM

To: continuum-dev@maven.apache.org
Subject: [continuum build - SUCCESS - update] Fri Jan 27 02:00:00 GMT
2006

Distribution:
http://maven.zones.apache.org/~continuum/builds/continuum-20060127.02000
0.war

Log:
http://maven.zones.apache.org/~continuum/logs/continuum-build-log-200601
27.02.txt

Re: problem building continuum

[Emmanuel Venisse]

It's a connection problem with ibiblio

Retry. but this code isn't stable and you won't can use the generated war.

Emmanuel

Bob Herrrmann a écrit :

I downloaded maven 2.0.2 and put it in my path.

$  svn co http://svn.apache.org/repos/asf/maven/continuum/trunk/ continuum
...
$  sh build.sh
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Continuum Parent Project
[INFO]   Continuum Model
[INFO]   Continuum API
[INFO]   Continuum Test
[INFO]   Continuum Notifiers
[INFO]   Continuum Notifier API
[INFO]   Continuum Store
[INFO]   Continuum Core
[INFO]   Continuum Cruise Control Importer
[INFO]   Continuum XMLRPC Interface
[INFO]   Continuum MSN Notifier
[INFO]   Continuum Jabber Notifier
[INFO]   Continuum IRC Notifier
[INFO]   Continuum Web APP
[INFO]   Continuum Core Integration Test
[INFO] Searching repository for plugin with prefix: 'clean'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking for
updates from central
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.0/maven-clean-plugin-2.0.pom
470b downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom
6K downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.0/maven-clean-plugin-2.0.jar
5K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-maven-plugin/1.1.3/plexus-maven-plugin-1.1.3.pom
1K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/1.0.4/plexus-1.0.4.pom
5K downloaded
Downloading:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-maven-plugin/1.1.3/plexus-maven-plugin-1.1.3.jar
14K downloaded
[INFO]

[INFO] Building Continuum Parent Project
[INFO]task-segment: [clean:clean, install]
[INFO]

Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0/maven-plugin-api-2.0.pom
601b downloaded
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/maven/2.0/maven-2.0.pom
8K downloaded
[INFO] [clean:clean]
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates from central
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-4/maven-site-plugin-2.0-beta-4.pom
1K downloaded
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: org.apache.maven.plugins:maven-site-plugin

Reason: Error getting POM for 'org.apache.maven.plugins:maven-site-plugin'
from the repository: Error transferring file
  org.apache.maven.plugins:maven-site-plugin:pom:2.0-beta-4

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  snapshots (http://snapshots.maven.codehaus.org/maven2)



[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Jan 26 20:48:13 EST 2006
[INFO] Final Memory: 2M/4M
[INFO]

+ ret=0
+ '[' 0 '!=' 0 ']'

Re: problem building continuum

[Emmanuel Venisse]

Continuum use some SUN jars that can't be redistributed. So you need to download them from sun site 
and copy them in the correct group in your repository like describe there : 
http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html


Emmanuel

Bob Herrmann a écrit :

ok,

$ svn co 
http://svn.apache.org/repos/asf/maven/continuum/branches/continuum-1.0.x/

$ cd continuum-1.0.x
$ sh build.sh
...
[WARNING] Unable to get resource from repository central 
(http://repo1.maven.org/maven2)
[INFO] 
 


[ERROR] BUILD ERROR
[INFO] 
 


[INFO] Failed to resolve artifact.

required artifacts missing:
 javax.resource:connector:jar:1.0
 javax.transaction:jta:jar:1.0.1B

for the artifact:
 org.codehaus.mojo:maven-jpox-plugin:maven-plugin:1.0.1

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 snapshots (http://snapshots.maven.codehaus.org/maven2)


Why am I getting these missing resources?   I'm following the building 
continuum instructions,


   
http://maven.apache.org/continuum/guides/development/guide-build-continuum.html 



and dont see any reference to needed external stuff.  (I did already put 
maven-2.0.2 in my path.)


Cheers
-bob

Re: Questions/Ideas about Continuum

[Emmanuel Venisse]

Nacho Gonzalez Mac Dowell a écrit :
Hi all, I have a couple of questions regarding continuum's webapp. I've 
been looking through jira and haven't found these issues tackled.


1. Is it just me or permissions are not checked when adding/removing 
projects? If I log in, copy the url for deleting a project and then 
logout, it seems that I can delete the project anyways. After going 
through the sources, I didn't find where permissions are checked.


You're right, it's a big problem in actual code that will be fixed in 1.1 (not 
in 1.0.3).
We'll use acegi security framework for that.



2. What is the use of parsing the pom when introducing a new maven1 
project? IMHO the pom should be parsed after checkout. This would allow 
building projects which extend from others if the extension project is 
included first. Maybe it would be useful to specify the relative url of 
the pom when the checkout is performed. IMO all you need to build a 
maven project is the scm connection url and parameters and the relative 
url to the pom.


We need to parse the pom when we add it for initializing it in Continuum. We'll can perhaps allow to 
add maven1 project which extend an other but only for parent project in the same checkout tree.




3. Isn't the scm password stored as clear text on the db? Usually this 
is a unix user/password from the scm machine... I would consider making 
a certificate for ssh connection or something like that. Then the public 
key for the user could be available for download and put in the scm 
machine.


It's a possible solution to implement.



Obviestly I am willing to contribute with patches on these issues if 
they are welcome. I didn't want to open tickets just yet as it is my 
first approach to continuum...


All help are welcome. File an issue and attach your patches. We'll look at them.



Anyways, I think Continuum is a very nice tool that could be really made 
into a monster! Thanks a lot for the effort!


Thanks.

Emmanuel



Thank you for your attention

nacho

Re: Fwd: [ANN] Apache JDO 2.0 beta released

[Emmanuel Venisse]

it is there : http://www.ibiblio.org/maven2/javax/jdo/jdo2-api/2.0-beta/

Thanks. I'll switch.

Emmanuel

Brett Porter a écrit :

we should switch to this - not sure if its in the repo yet.

- Brett

-- Forwarded message --
From: Craig L Russell <[EMAIL PROTECTED]>
Date: Feb 1, 2006 5:47 AM
Subject: [ANN] Apache JDO 2.0 beta released
To: general@db.apache.org
Cc: JDO Expert Group <[EMAIL PROTECTED]>, Apache JDO project



The Apache JDO project http://db.apache.org/jdo is pleased to announce
the release of Apache JDO 2.0 beta, a preview release of Apache JDO 2.0.
Apache JDO is a subproject of the Apache DB project.

JDO is a JCP standard interface for persistence of Java objects.
It is datastore-agnostic and supports relational and non-relational
databases. For details, please see http://jcp.org/en/jsr/detail?id=243

The Apache JDO project builds the JDO API jars used by application
programmers and the JDO TCK jars, used to verify compliance with
the specification. The Apache JDO project does not build an implementation
of JDO 2.0. The JDO 2.0 Reference Implementation is JPOX,
which is available via its own download: http://jpox.org

Apache JDO API and TCK are available as a source download from mirrors
http://www.apache.org/dyn/closer.cgi
/db/jdo/2.0-beta. The jar files are available in binary form as maven form
from mirrors /java-repository/javax.jdo and
/java-repository/org.apache.jdo

JDO 2.0 builds on the JDO 1 API. Applications built to use JDO 1 need only
to be recompiled to run with JDO 2.0.

Features in the JDO 2.0 release include:

- Standard mapping from objects to relational databases
- Multi-tier support without use of Data Transfer Objects
- Improved query support including projections and aggregates
- Stored queries in metadata
- Deletion by query
- Optimized fetching of object graphs without writing special queries
- Extensive List and Map support
- Lazy loading of large collections
- Better support for single-field primary keys
- Object lifecycle event monitoring
- Improved support for bidirectional relationships




Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:[EMAIL PROTECTED]

P.S. A good JDO? O, Gasp!

Re: integrating with continuum

[Emmanuel Venisse]

You can't add an other type of project.

What is your project type?

We have a start of xmlrpc client in jira that can manage continuum, but it don't help you with new 
project type.


Emmanuel

Knut Wannheden a écrit :

Hi there,

I am new to Continuum and was wondering if it is possible to extend
Continuum by adding new "project types". I'd like to add my own "Add
XXX Project" link on the Continuum page next to the other links for
Maven, Maven2, Ant, and Shell projects. Or alternatively if I could
use an API to add my projects programatically to the database.

Is this already possible?

TIA,

Knut Wannheden

Re: integrating with continuum

[Emmanuel Venisse]

Knut Wannheden a écrit :

Emmanuel,

On 2/1/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


You can't add an other type of project.

What is your project type?




In our development enviroment we have our own project file format
(similar to Maven POM) and our own build tools on top of this. The
reason we are not using any existing tools, like Maven, ist that we
had some specific requirements which other tools could not handle at
the time we implemented this.

This development and build environment is developed in Java so I was
hoping that it would be easy to integrate as some kind of extension to
Continuum.

I'd like to add projects with interdependencies to Continuum. Can I
also use the shell project type for this?


You can use the shell project type. You only need a command line to launch your 
build.
Interdependencies between projects are available for now only for maven projects. We'll add this 
feature for ant and shell projects in 1.1




As we have very many projects, which also change over time, I'd like
to use some kind of API to keep the project definitions in Continuum
in sync. Thus I was wondering about adding new project types or an API
to add projects.


What sort of changes do you want to do?



Can you see a viable solution to this? Or should I enter a feature
request in JIRA?


Look at CONTINUUM-544 for a xmlrpc client. I'll integrate it later in continuum.



Regards,

--knut

Re: integrating with continuum

[Emmanuel Venisse]

Knut Wannheden a écrit :

I'd like to add projects with interdependencies to Continuum. Can I
also use the shell project type for this?


You can use the shell project type. You only need a command line to launch your 
build.
Interdependencies between projects are available for now only for maven 
projects. We'll add this
feature for ant and shell projects in 1.1




OK. I think I remember reading somewhere that the shell project type
is currently limited in that way. So I'm looking forward to the 1.1
release.



As we have very many projects, which also change over time, I'd like
to use some kind of API to keep the project definitions in Continuum
in sync. Thus I was wondering about adding new project types or an API
to add projects.


What sort of changes do you want to do?




I'm not sure I quite understand your question. But let me explain what
I'd like to do. We have 100+ projects in our development environment
and occasionally we add new projects and change the dependencies
between existing projects. We also change the developer list for the
projects. Obviously I'd like the definitions in Continuum to stay in
sync without having to enter and verify that manually.


I have my answer ;-)
You'll can do it by xmlrpc client api.





Can you see a viable solution to this? Or should I enter a feature
request in JIRA?


Look at CONTINUUM-544 for a xmlrpc client. I'll integrate it later in continuum.




That certainly looks interesting. I see this is also scheduled for
1.1. Is there an estimated relases date for 1.1?


It's perhaps in 1.0.3.

alpha of 1.1 will probably release in 2006Q1 and final in 2006Q2

Emmanuel



Regards,

--knut

Re: integrating with continuum

[Emmanuel Venisse]

Knut Wannheden a écrit :

Hi again,

On 2/1/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


I'm not sure I quite understand your question. But let me explain what
I'd like to do. We have 100+ projects in our development environment
and occasionally we add new projects and change the dependencies
between existing projects. We also change the developer list for the
projects. Obviously I'd like the definitions in Continuum to stay in
sync without having to enter and verify that manually.


I have my answer ;-)
You'll can do it by xmlrpc client api.




Thinking a little bit more about this I still have some questions.

I assume that the idea would be to use the XML-RPC API to propagate
any changes I make to the project definitions in the development
environment to Continuum.

The best way I can think of to get that right every time would be to
add a commit trigger to the version management system which would
remind the user to update the Continuum definitions every time a
project definition file is committed. Although even with that solution
the definitions will at best just be out of sync for a short period of
time, which with bad luck would cause the build to fail for that
reason.

How does this work with Maven projects? Will Continuum automatically
update its project definitions when it detects a change to the POM? If
that is the case I'd much prefer to be able to add custom project
types to Continuum which would let me achieve the same effect. Does
this sound reasonable or is this out of scope for the Continuum
project?


If pom changes, Continuum update project definition automatically, but not for 
all changes like scm url.
In 1.1, it will be *perhaps* more easy to add a new project type.

Emmanuel

Re: jdk 1.4 and 1.5 in same install?

[Emmanuel Venisse]

An other option is to set source and target argument on compiler plugin

David Blevins a écrit :

Sounds like a scary m1-style hack ... not going there.

Second install it is

-David

On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote:


What about compiler and test plugins options like fork,  executable, ...

On 2/8/06, David Blevins <[EMAIL PROTECTED]> wrote:


So i find myself needing jdk 1.4 for 90% of what i have in the
geronimo continuum install, some of those actually can't compile with
1.5 because of corba/vm ties.

But alas I do need 1.5 now for at least two projects.

Do i pretty much have to setup another continuum install for this?


-David

Re: svn commit: r376420 - /maven/continuum/branches/continuum-1.0.x/continuum-core-it/src/test/java/org/apache/maven/continuum/it/AbstractIntegrationTest.java

[Emmanuel Venisse]

Not me directly, but it seems it was the case for an other person.
Perhaps we need to move the code from clean plugin to FileUtils.deleteSomething() because it works 
fine and clean plugin will have only one line.


Emmanuel

Trygve Laugstøl a écrit :

On Thu, 2006-02-09 at 20:20 +, [EMAIL PROTECTED] wrote:


Author: evenisse
Date: Thu Feb  9 12:20:54 2006
New Revision: 376420

URL: http://svn.apache.org/viewcvs?rev=376420&view=rev
Log:
Test if temp directory is deleted before to start the test



This shouldn't be necessary, did you encounter a case where this was
needed? There was someone on #maven or #continuum that was talking about
FileUtils.deleteSomething() didn't properly delete the directories so
you migh be experiencing the same bug.

--
Trygve

Re: jdk 1.4 and 1.5 in same install?

[Emmanuel Venisse]

What about carlos's suggestion?

I'm sorry, but i can't include continuum profiles in 1.0.3

Emmanuel

David Blevins a écrit :
We have too much corba tie-in to the Sun ORB which makes it so we  can't 
compile a few chunks of the code or test it on anything other  than 
strict 1.4 vm (no 1.5 with 1.4 flags).


-David

On Feb 8, 2006, at 11:08 PM, Emmanuel Venisse wrote:


An other option is to set source and target argument on compiler  plugin

David Blevins a écrit :


Sounds like a scary m1-style hack ... not going there.
Second install it is
-David
On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote:

What about compiler and test plugins options like fork,   
executable, ...


On 2/8/06, David Blevins <[EMAIL PROTECTED]> wrote:


So i find myself needing jdk 1.4 for 90% of what i have in the
geronimo continuum install, some of those actually can't compile  with
1.5 because of corba/vm ties.

But alas I do need 1.5 now for at least two projects.

Do i pretty much have to setup another continuum install for this?


-David

Re: plexus-utils snapshot version in what repository?

[Emmanuel Venisse]

The repository is already included (http://snapshots.maven.codehaus.org/maven2/)

I think there was a connection pb to the repo when you tried.

Emmanuel

Barrie Treloar a écrit :

This should be an easy thing to solve, but I can not find any links to
the snapshot repository on the plexus site.

What repository should I be including?

Cheers

[INFO] Failed to resolve artifact.

required artifacts missing:
  org.codehaus.plexus:plexus-utils:jar:1.2-SNAPSHOT

for the artifact:
  org.apache.maven.continuum:continuum-api:jar:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.snapshots (http://cvs.apache.org/maven-snapshot-repository),
  snapshots (http://snapshots.maven.codehaus.org/maven2)

Re: new feature & trunk merge handling

[Emmanuel Venisse]

I'd prefer to wait the release of 1.0.3 before to merge. I have a lot of patch to apply and i'd 
prefer to apply them in the oreder they was added in branch so all of them will be apply.


Emmanuel

Brett Porter a écrit :

Hi,

I implemented CONTINUUM-609 so that, if configured, the built artifact
(roughly) is deployed to a special repository served by Continuum. It
only supports Maven 2 builds and only deploys
${project.build.directory}/${project.final.name}.ext if it exists, so is
a bit limited right now.

The repository can also be accessed at:
http://localhost:8080/continuum/repository in m2 layout.

Now, I was going to merge the change down to the trunk, as I expected
them to be in sync - but it seems because of the WW changes on trunk,
that the branch has not had any changes merged down or up. Is that
correct? If so, is it safe for me to leave this on the branch and know
the whole branch will merge to trunk after 1.0.3 is released? That seems
like the way to go at this point.

Thanks,
Brett

Re: svn commit: r386085

[Emmanuel Venisse]

sure, i'll do it

Emmanuel

Brett Porter a écrit :

[EMAIL PROTECTED] wrote:


Author: evenisse
Date: Wed Mar 15 06:49:02 2006
New Revision: 386085

URL: http://svn.apache.org/viewcvs?rev=386085&view=rev
Log:
o Add CHECKOUTED state, it's similar to NEW state but the difference is that 
sources are checkouted



Not to nitpick, but can this be renamed "CHECKEDOUT" ?

Thanks,
Brett

Re: FYI: building continuum today

[Emmanuel Venisse]

The build works fine on windows and linux.

Emmanuel

Bob Herrmann a écrit :

I checked out contiuum this morning and did a build... I get this...

sh build.xml # I'm using cygwin on win2k.
...
There was no such logger 
'org.apache.maven.artifact.transform.ArtifactTransforma 
tion:latest' 15282461.
[2006.03.15 10:13:50] Used 28859ms
[surefire] Running org.apache.maven.continuum.it.ShellIntegrationTest
[surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 28.891 sec

Results :
[surefire] Tests run: 5, Failures: 3, Errors: 0

[INFO] 
-   
  ---
[ERROR] BUILD ERROR
[INFO] 
-   
  ---
[INFO] There are some test failure.
[INFO] 
-   
  ---
[INFO] For more information, run Maven with the -e switch
[INFO] 
-   
  ---
[INFO] Total time: 36 minutes 8 seconds
[INFO] Finished at: Wed Mar 15 10:13:51 EST 2006
[INFO] Final Memory: 57M/63M
[INFO] 
-   
  ---

[vote] Release Continuum 1.0.3

[Emmanuel Venisse]

Hi,

I think it's time to release Continuum 1.0.3. This release will incorporate 65 issues, including 
some critical fixes. The full listing of fixes can be found here:


http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=12330

If you're interested, you can take the current release candidate for a test 
drive. The RC tarball is at:

http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060316.173001.tar.gz

I'll leave the vote open for the customary 72 hours before summarizing. Please 
cast your vote as:

[ ] +1 Yes, release
[ ]  0 No opinion
[ ] -1 No, don't release

Here's my +1.

Cheers,

Emmanuel

Re: Distributed Continuum (GBuild)

[Emmanuel Venisse]

+1

Emmanuel

Jason van Zyl a écrit :

Hi,

I have been talking with David Blevins about moving the GBuild code from 
Geronimo over to Continuum proper. GBuild is a version of Continuum that 
works in a distributed fashion. GBuild was created to test the Geronimo 
TCK across many different platforms with many different configurations 
and have the results all aggregated back on a master machine.


So what I would like to propose is to move the code from GBuild over 
into Continuum proper and give David Blevins and Kevan Miller commit 
access. They are both committers on the Geronimo project and are 
familiar with this distributed code and will continue to work on the 
code once in Continuum.


This is very exciting!

Here's my

+1

Jason van Zyl

Re: svn commit: r389193 - /maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml

[Emmanuel Venisse]

Brett,

we can't use compile class because we don't want jdo stuff in enhanced classes.

Emmanuel

[EMAIL PROTECTED] a écrit :

Author: brett
Date: Mon Mar 27 08:27:17 2006
New Revision: 389193

URL: http://svn.apache.org/viewcvs?rev=389193&view=rev
Log:
use model classes directly to help it compile

Modified:
maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml

Modified: maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml
URL: 
http://svn.apache.org/viewcvs/maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml?rev=389193&r1=389192&r2=389193&view=diff
==
--- maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml 
(original)
+++ maven/continuum/branches/continuum-1.0.x/continuum-rpc-client/pom.xml Mon 
Mar 27 08:27:17 2006
@@ -31,27 +31,9 @@
   commons-logging
   1.0.2
 
+
+  org.apache.maven.continuum
+  continuum-model
+
   
-
-  
-
-  
-org.codehaus.modello
-modello-maven-plugin
-1.0-alpha-9-SNAPSHOT
-
-  
-
-  java
-
-  
-
-
-  1.0.0
-  false
-  ../continuum-model/src/main/mdo/continuum.mdo
-
-  
-
-  
 

Re: Creating a notifier for Confluence

[Emmanuel Venisse]

Yes, you need to extends AbstractContinuumNotifier.

You can look at MailContinuumNotifier, IrcContinuumNotifier, JabberContinuumNotifier and 
MsnContinuumNotifier for samples


When your notifier will be implemented, do you want to donate it to us?

Emmanuel

Mang Jun Lau a écrit :

Hi,

Our company uses Atlassian Confluence as a wiki.  I want to try to create 
a notifier so that after a build, the notification is sent as a message to 
post on a Confluence page.  Since you can post to Confluence via SOAP web 
services calls, I think may be straightforward to create a notifier. Where 
do I look to start and what are some of the requirements?  Do I simply 
extend AbstractContinuumNotifier or what?


Any direction would help.  Thanks.


_Mang Lau

Re: Creating a notifier for Confluence

[Emmanuel Venisse]

Hi David,

Can you add some samples on swizzle site?

Emmanuel

David Blevins a écrit :

FYI, I have a library available for manipulating Confluence via XML-RPC

 http://cvs.codehaus.org/viewrep/swizzle/swizzle/swizzle-confluence/ 
src/main/java/org/codehaus/swizzle/confluence


You are unlikely to find anything more complete.  I have another one  
for Jira as well.


Binaries are available here:

 http://snapshot.repository.codehaus.org/org/codehaus/swizzle/

Can put out a final if you like.

-David

On Apr 5, 2006, at 12:39 AM, Emmanuel Venisse wrote:


Yes, you need to extends AbstractContinuumNotifier.

You can look at MailContinuumNotifier, IrcContinuumNotifier,  
JabberContinuumNotifier and MsnContinuumNotifier for samples


When your notifier will be implemented, do you want to donate it to  us?

Emmanuel

Mang Jun Lau a écrit :


Hi,
Our company uses Atlassian Confluence as a wiki.  I want to try to  
create a notifier so that after a build, the notification is sent  as 
a message to post on a Confluence page.  Since you can post to  
Confluence via SOAP web services calls, I think may be  
straightforward to create a notifier. Where do I look to start and  
what are some of the requirements?  Do I simply extend  
AbstractContinuumNotifier or what?

Any direction would help.  Thanks.
_Mang Lau

Re: [vote] Release Continuum 1.0.3

[Emmanuel Venisse]

Arnaud HERITIER a écrit :

I just tested it.

+0 actually

What I noticed :

1) Is it normal that I can't edit/remove the default notification for m1
projects ?
It's really annoying. I don't want to spam
[EMAIL PROTECTED] the build is successfull (just the
first time after a failure).


You can't because it's a project notifier and not a notifier defined by the user. If you don't want 
to spam the list, you can turn off your smtp server or configure a bad address in application.xml.


I think i'll add, in 1.1, an authorized sender in project notifier.



2) It seems also that I have a problem with the build number when the build
fails :
http://heritier.homeip.net/continuum/servlet/continuum/target/ProjectBuilds.vm/view/ProjectBuilds/id/1


The build number is incremented only when the build is in success, so you don't 
have a problem there.

Emmanuel



cheers

Arnaud

On 3/17/06, Punkin Head <[EMAIL PROTECTED]> wrote:


+1

On 3/16/06, Brett Porter <[EMAIL PROTECTED]> wrote:


I've been testing and its looking great, but can we hold off voting
until the final RC is ready? I'd like to follow the lead taken with the
Maven core which has resulted in us delaying the release due to bugs
that otherwise would have got by unnoticed.

- Brett

Emmanuel Venisse wrote:


Hi,

I think it's time to release Continuum 1.0.3. This release will
incorporate 65 issues, including some critical fixes. The full listing
of fixes can be found here:





http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=12330



If you're interested, you can take the current release candidate for a
test drive. The RC tarball is at:





http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060316.173001.tar.gz



I'll leave the vote open for the customary 72 hours before


summarizing.


Please cast your vote as:

[ ] +1 Yes, release
[ ]  0 No opinion
[ ] -1 No, don't release

Here's my +1.

Cheers,

Emmanuel






--
www.punkinshred.net  // punkin'head official homepage

www.myspace.com/punkinhead <-- for true shred

Re: [vote] Release Continuum 1.0.3

[Emmanuel Venisse]

What is your OS?

Emmanuel

Arnaud HERITIER a écrit :

I also have a lot of OutOfMemory errors
http://jira.codehaus.org/browse/CONTINUUM-653
I have to reboot my continuum server sevaral times per day :-(

Arnaud

On 4/10/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:




Arnaud HERITIER a écrit :


I just tested it.

+0 actually

What I noticed :

1) Is it normal that I can't edit/remove the default notification for m1
projects ?
It's really annoying. I don't want to spam
[EMAIL PROTECTED] the build is successfull (just the
first time after a failure).


You can't because it's a project notifier and not a notifier defined by
the user. If you don't want
to spam the list, you can turn off your smtp server or configure a bad
address in application.xml.

I think i'll add, in 1.1, an authorized sender in project notifier.



2) It seems also that I have a problem with the build number when the


build


fails :



http://heritier.homeip.net/continuum/servlet/continuum/target/ProjectBuilds.vm/view/ProjectBuilds/id/1

The build number is incremented only when the build is in success, so you
don't have a problem there.

Emmanuel



cheers

Arnaud

On 3/17/06, Punkin Head <[EMAIL PROTECTED]> wrote:



+1

On 3/16/06, Brett Porter <[EMAIL PROTECTED]> wrote:



I've been testing and its looking great, but can we hold off voting
until the final RC is ready? I'd like to follow the lead taken with the
Maven core which has resulted in us delaying the release due to bugs
that otherwise would have got by unnoticed.

- Brett

Emmanuel Venisse wrote:



Hi,

I think it's time to release Continuum 1.0.3. This release will
incorporate 65 issues, including some critical fixes. The full listing
of fixes can be found here:





http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=12330


If you're interested, you can take the current release candidate for a
test drive. The RC tarball is at:





http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060316.173001.tar.gz


I'll leave the vote open for the customary 72 hours before


summarizing.



Please cast your vote as:

[ ] +1 Yes, release
[ ]  0 No opinion
[ ] -1 No, don't release

Here's my +1.

Cheers,

Emmanuel





--
www.punkinshred.net  // punkin'head official homepage

www.myspace.com/punkinhead <-- for true shred

Re: [vote] Release Continuum 1.0.3

[Emmanuel Venisse]

Yes, it's one of our two problems to resolve before the release.
The other is the creation of duplicated projects when you kill Continuum when project is building. 
The result is a corrupted database (seems to be occurred only on linux/solaris, I can't reproduce it 
under windows)


Emmanuel

Kaare Nilsen a écrit :

Well..
based on the rc snapshot I also have alot problems with out of memory stuff.

I run
solaris10
jdk 1.5.0_04

eagerly awaiting the next rc

On 10/04/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:


Windows XP
JDK 1.4.2

If it runs (the projects list shouldn't be empty), you can take a look at it
here :
http://heritier.homeip.net/continuum/

Arnaud

On 4/10/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


What is your OS?

Emmanuel

Arnaud HERITIER a écrit :


I also have a lot of OutOfMemory errors
http://jira.codehaus.org/browse/CONTINUUM-653
I have to reboot my continuum server sevaral times per day :-(

Arnaud

On 4/10/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:




Arnaud HERITIER a écrit :



I just tested it.

+0 actually

What I noticed :

1) Is it normal that I can't edit/remove the default notification for


m1


projects ?
It's really annoying. I don't want to spam
[EMAIL PROTECTED] the build is successfull (just the
first time after a failure).


You can't because it's a project notifier and not a notifier defined by
the user. If you don't want
to spam the list, you can turn off your smtp server or configure a bad
address in application.xml.

I think i'll add, in 1.1, an authorized sender in project notifier.




2) It seems also that I have a problem with the build number when the


build



fails :





http://heritier.homeip.net/continuum/servlet/continuum/target/ProjectBuilds.vm/view/ProjectBuilds/id/1


The build number is incremented only when the build is in success, so


you


don't have a problem there.

Emmanuel




cheers

Arnaud

On 3/17/06, Punkin Head <[EMAIL PROTECTED]> wrote:




+1

On 3/16/06, Brett Porter <[EMAIL PROTECTED]> wrote:




I've been testing and its looking great, but can we hold off voting
until the final RC is ready? I'd like to follow the lead taken with


the


Maven core which has resulted in us delaying the release due to bugs
that otherwise would have got by unnoticed.

- Brett

Emmanuel Venisse wrote:




Hi,

I think it's time to release Continuum 1.0.3. This release will
incorporate 65 issues, including some critical fixes. The full


listing


of fixes can be found here:





http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540&styleName=Html&version=12330


If you're interested, you can take the current release candidate for


a


test drive. The RC tarball is at:





http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060316.173001.tar.gz


I'll leave the vote open for the customary 72 hours before


summarizing.




Please cast your vote as:

[ ] +1 Yes, release
[ ]  0 No opinion
[ ] -1 No, don't release

Here's my +1.

Cheers,

Emmanuel




--
www.punkinshred.net  // punkin'head official homepage

www.myspace.com/punkinhead <-- for true shred

Re: Non-public projects

[Emmanuel Venisse]

Yes, it will be in 1.1.

Emmanuel

Carlos Sanchez a écrit :

I think this is what it's planned for 1.1 by adding security through Acegi

On 4/13/06, David Blevins <[EMAIL PROTECTED]> wrote:


There is a new feature I need and I'd like to get feedback from the
group on how it may be implemented.  Don't know if I'll end up
writing, but at least I'd like to get some discussion going for now.

We at Geronimo desperately need to be able to setup a couple projects
in continuum that aren't public -- they're tck related.  So
basically, we need some way to mark a project as viewable by only
logged in individuals in a specific group.  Having them listed on the
main page with the other projects is ok, just clicking on anything
there should require you to be properly authenticated and authorized
to do so.

This is a big new can of worms for Continuum, so what does everyone
think?  Good feature/bad feature?  Any thought's on what'd be
required to implement it?

-David







--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

Re: memory leak investigations

[Emmanuel Venisse]

The memory leak seems to be fixed by my latest patch. Now I have always one statecontentgenerator in 
memory instead of several due to a strange thing with role-hint in components.xml in continuum-web


Emmanuel

Brett Porter a écrit :
Ok, just watching the telemetry. If I hit "show projects" repeatedly, 
then I get a steep increase in memory usage, which does not all get 
collected when I GC. So at about 300k lost per page refresh, that would 
be part of it, but probably not all (I was refreshing the project list 
often in the tests below). This could definitely be the 
statecontentgenerator.


I next ran a set of builds without doing anything on that screen, and 
the net result was very little. It seems it could be isolated to the 
SecureRunData and statecontentgenerator.


FWIW, if you want to see the snapshots, they are stored under ~bporter 
on ci.codehaus.org if you have access:


Launcher-2006-04-12.memory.gz
Launcher-2006-04-12-2.memory.gz

They're about 20mb each.

- Brett

Brett Porter wrote:


Hi,

I've done some investigation.

I was able to run the server where it was just checking for 
non-existant updates for some time, and it had no net result on memory 
usage (it constantly goes up, gc's back to the same level, etc).


When I ran a "build all" on cheddar (with no checkouts), net memory 
usage increased 40Mb to build all 130-odd projects (it was at 24mb, 
now it idles at 62 - it was around 80 but 20mb went away after GC). 
Now, it idles at the same level again (even after enqueuing all again, 
but not building).


I took a snapshot at the start and end, and there is 38mb in a single 
hashmap with 513 elements. This map is the 
componentManagersByComponentHashCode field of 
DefaultComponentManagerManager. This would have to be unreleased 
components, right?


Some more things high in the allocation count:
- SecureRunData has 2mb that wasn't there before. It is a possible 
suspect since it is new in 1.0.3. It occurs more than once.
- ContinuumStateContentGenerator has 2mb. Another possible suspect for 
an unreleased component. There are 3 of them in the top 20.
- The second most allocated is a hasmap in the projectBuilder 
(processedProjectCache), at 5mb. This may just be acceptable use.
- DefaultViewContext has much as well, but I think that's because it 
stores all the state generators


The rest seem to be more instances of the above 4.

I don't have more time to investigate - I'd suggest perhaps logging 
all components released when the container shuts down, and just build 
one project from scratch to see what components are left in there at 
the end..


So it seems the actual specs we need:
- 20mb baseline
- 20mb buffer to build
- caches (eg projects)

It should easily fit in 64mb, with 128mb being safe if we are to spec 
out requirements.


HTH,
Brett

Re: Non-public projects

[Emmanuel Venisse]

1.1 development is suspended until the release of 1.0.3 in few days.
We don't have for the moment a release date for 1.1

Emmanuel

David Blevins a écrit :

Woohoo.  So what's the status of 1.1 these days?

-David

On Apr 13, 2006, at 12:08 PM, Emmanuel Venisse wrote:


Yes, it will be in 1.1.

Emmanuel

Carlos Sanchez a écrit :

I think this is what it's planned for 1.1 by adding security  through 
Acegi

On 4/13/06, David Blevins <[EMAIL PROTECTED]> wrote:


There is a new feature I need and I'd like to get feedback from the
group on how it may be implemented.  Don't know if I'll end up
writing, but at least I'd like to get some discussion going for now.

We at Geronimo desperately need to be able to setup a couple  projects
in continuum that aren't public -- they're tck related.  So
basically, we need some way to mark a project as viewable by only
logged in individuals in a specific group.  Having them listed on  the
main page with the other projects is ok, just clicking on anything
there should require you to be properly authenticated and authorized
to do so.

This is a big new can of worms for Continuum, so what does everyone
think?  Good feature/bad feature?  Any thought's on what'd be
required to implement it?

-David




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

[vote] Release Continuum 1.0.3

[Emmanuel Venisse]

Hi,

I've fixed some issues since latest RC (memory leak, performance...)

Here is the latest RC. Please give it a try before voting.
http://www.codehaus.org/~evenisse/continuum/

Let's do another 72h round of voting.

+1/+0/-1

Here's my +1.

Thanks,

Emmanuel

Re: Continuum v1.0.3...?

[Emmanuel Venisse]

Hi,

you can try this : http://www.codehaus.org/~evenisse/continuum/
It's the RC.

Normally, 1.0.3 will be release soon.

Emmanuel

Graham Leggett a écrit :

Hi all,

Is this ready for release yet? I saw voting, but no final conclusion.

I am about to install a copy of v1.0.2, and was hoping to put in v1.0.3
instead if possible.

Regards,
Graham
--

Re: Continuum v1.0.3...?

[Emmanuel Venisse]

the wrapper doesn't work with some macosx.

You can run bin/plexus.sh instead

Emmanuel

Graham Leggett a écrit :

On Fri, April 21, 2006 7:19 pm, Graham Leggett said:



Running it on MacOSX v10.4.6 gives the following error with console,
neither start nor restart cause continuum to start.

Graham-Leggetts-Computer:~/src/continuum-1.0.3-SNAPSHOT minfrin$
./bin/macosx/run.sh console
Running continuum...
wrapper  | --> Wrapper Started as Console
dyld: lazy symbol binding failed: Symbol not found: _ftime



There is lots of reports of this problem in Google, but no solution, apart
from this tantalising clue:

http://dev.pols.co.uk/jira/browse/BJ-164

Seems "Java Service Wrapper" was upgraded to fix this problem.

Considering that the v1.0.3 candidate is broken out the box on MacosX, and
considering there is no documentation or warning in v1.0.3 that it is
broken out the box on MacosX, I'd say this RC should be fixed before
release.

Regards,
Graham
--

[Ann] Continuum 1.0.3 Released

[Emmanuel Venisse]

  The Apache Maven team is pleased to announce Continuum 1.0.3.

  Continuum 1.0.3 is available for download from 
{{http://maven.apache.org/continuum/download.html}}

  Continuum is a continous integration server that will ensure the health of 
your code base.

  This release includes the following improvements :

   * Improved performance

   * New web interface

   * Added an internal maven repository for built projects

   * Improved the project build for projects with multiple build definitions

   * Improved maven2 setings/profiles loading

   * Bug fixes

  For a complete list of changes please refer to the complete changelog:

* {{http://maven.apache.org/continuum/change-log.html}}

  We hope you enjoy using Continuum! If you have any questions, please consult:

* the web site: {{http://maven.apache.org/continuum/}}

* the continuum-user mailing list: 
{{http://maven.apache.org/continuum/mail-lists.html}}


Emmanuel

Re: trunk merge

[Emmanuel Venisse]

The merge is already done since Tuesday.

I'm not sure all works. I'll check it when codehaus server will be back.

Emmanuel

Brett Porter a écrit :

Hi,

I was wondering when the trunk merge was going to happen. I'm interested 
in playing around on trunk, but just wanted to know what state it is in.


Cheers,
Brett

Re: branch CI turned off

[Emmanuel Venisse]

I think we'll can remove it when trunk will be in a stable state. I'm not agree to remove the more 
stable branch even if it isn't the development branch.


Emmanuel

Brett Porter a écrit :
I've turned off the CI build for continuum-1.0.x, since the development 
focus will all be on trunk now.


I'm not sure if we should svn rm the branch to save confusion, or move 
it, or just leave it there. Any thoughts?


- Brett

Re: branch CI turned off

[Emmanuel Venisse]

theoretically, but it isn't really the case :-)

I applied a patch after the release and before the merge with trunk.

Brett Porter a écrit :

theoretically it shouldn't have changed since the last tag :)

Trygve Laugstøl wrote:


Brett Porter wrote:

Yep, I agree with you both. Perhaps removing it after the 1.1 release 
is the most appropriate.



+1, and include the last known rev in the README.txt :)

--
Trygve

Re: [continuum build trunk - FAILED - update] Mon May 29 22:00:00 GMT 2006

[Emmanuel Venisse]

Brett Porter a écrit :
All the integration tests are failing. Is this simply because they rely 
on the old webapp?


I'm not sure because it build fine on my laptop.


What needs to happen to get this working again?


I'll look at the test outputs.

Emmanuel


- Brett

[EMAIL PROTECTED] wrote:


Log:
http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060529.22.txt 

Re: Build failure with CVS not found error

[Emmanuel Venisse]

http://www.google.fr/search?q=cvs+client+mac

Chandrika a écrit :
hi, 


Thanks for ur reply...
but, im using cvs - eclipse in mac...and im connecting the cvs of my client
through vpn...my vpn is connected...so, is there any cvs client for
mac?...also, this repository is thru eclipse-cvs repositroy...
i m not getting a clear picture of the connection...
plz.suggest any solutions?

thanks
chandrika

--
View this message in context: 
http://www.nabble.com/Build+failure+with+CVS+not+found+error-t1704074.html#a4625603
Sent from the Continuum - Dev forum at Nabble.com.

Re: trunk merge

[Emmanuel Venisse]

I'll start it this week and I hope to finish the css changes and webwork 2.2.2 
for the end of next week

Emmanuel

Brett Porter a écrit :

Where are we at here?

Emmanuel Venisse wrote:

I have some plexus changes to apply because continuum trunk use some 
snapshot that must be updated.


I'll start to apply the new css to trunk too.

Emmanuel

Brett Porter a écrit :


What is required on the codehaus server? Were there plexus changes?

Emmanuel Venisse wrote:


The merge is already done since Tuesday.

I'm not sure all works. I'll check it when codehaus server will be 
back.


Emmanuel

Brett Porter a écrit :


Hi,

I was wondering when the trunk merge was going to happen. I'm 
interested in playing around on trunk, but just wanted to know what 
state it is in.


Cheers,
Brett

Re: Release Management for Maven/Continuum

[Emmanuel Venisse]

Thanks Jeremy

Emmanuel

Jeremy Whitlock a écrit :

Hi all,
   This is an email that Jason sent me to give you a better understanding
of the previous email I sent.  Please feel free to comment, question or add
suggestions to the effort.

Take care,

Jeremy

-- Forwarded message --
From: Jason Van Zyl <[EMAIL PROTECTED]>
Date: Jun 11, 2006 10:01 AM
Subject: Releasing with Continuum
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]

Hey,

I wrote a tiny diagram here:

http://people.apache.org/~jvanzyl/ReleasingWithContinuum.png 



I checked in some code into the release plugin for you. If you're watching
the commit logs then you'll see notes I'm leaving for you and I've also
marked todos for you with //TODO:JW so you can key off that if you're using
eclipse or IDEA. In IDEA you can customize that sort of thing.

What I've done so far is create the release descriptor model in the release
plugin. When you update the release plugin you'll see it:

http://svn.apache.org/viewvc/maven/plugins/trunk/maven-release-plugin/src/main/mdo/ 



When you run the build, the java sources will be generated. You can see the
configuration for modello in the POM for the release plugin.

I added a note in the PrepareReleaseMojo with TODO:JW which you can take a
peek at. Basically that's just the starting point as you'll have to add
everything you need in order to make the release descriptor be populated,
used and sent to Continuum.

I will now create a little module in Continuum that will use the stuff I
just created in the release plugin.

Ultimately we will probably make a separate release management build and as
you see Brett has already started the tool in the release plugin. So for 
now

a module in Continuum that uses this will depend on a Maven plugin because
it will need the release descriptor model but that's fine for now. Maybe 
you

can think about separating out the release management tool in the release
plugin as you go. Brett probably has some ideas on that.

Ok, I will try to whip something off quick in Continuum for you.

Jason van Zyl
[EMAIL PROTECTED]

Continuum 1.1 roadmap

[Emmanuel Venisse]

Hi,

I started to define the roadmap of continuum 1.1. It will be done normally 
tomorrow.

The major first things to do in this roadmap are:

- Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): 
this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must 
secure all requests in continuum and not only don't show some part of the interface.


- Remove JDO (at least jpox) because it the source of lot of our issues

- implementation of continuum profiles and installation 
screens(CONTINUUM-44,CONTINUUM-59)

- integration of GBuild (CONTINUUM-563)

- implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, 
CONTINUUM-292)


Other important things I'd want to see in it:

- customization of the add project feature. In this part, I think to add a multi-project as a 
multiple projects or as a single project, scm connection string to use, add with a scm url, add all 
modules by a scm connection instead of an url contruction based on project url provided in the add 
screen


- build on dependencies changes

- add a tests result summary in build results

I'll add missing issues in jira tomorrow when I'll continue the roadmap.

Emmanuel

Re: Continuum 1.1 roadmap

[Emmanuel Venisse]

Jason van Zyl a écrit :


On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote:


Hi,

I started to define the roadmap of continuum 1.1. It will be done 
normally tomorrow.


Are we deciding that these are the things are going to be in 1.1 and 
take as long as we need? I would prefer that myself. Looking below there 
I think that's a good list.


I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each 
items, perhaps we'll do an intermediate release.






The major first things to do in this roadmap are:

- Reimplementation of authentication/authorization management 
(CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with 
acegi. Carlos will integrate acegi with plexus. This part must secure 
all requests in continuum and not only don't show some part of the 
interface.




If a plexus component is made to integrate Acegi that's cool. As long as 
Continuum itself has an abstraction for security and Acegi is not 
coupled directly to Continuum that's fine.


Normally, they won't be coupled. Carlos, can you add more informations?




- Remove JDO (at least jpox) because it the source of lot of our issues



+1

- implementation of continuum profiles and installation 
screens(CONTINUUM-44,CONTINUUM-59)




+1


- integration of GBuild (CONTINUUM-563)



+1

- implementation of project groups (CONTINUUM-30, 
CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292)




+1


Other important things I'd want to see in it:

- customization of the add project feature. In this part, I think to 
add a multi-project as a multiple projects or as a single project, scm 
connection string to use, add with a scm url, add all modules by a scm 
connection instead of an url contruction based on project url provided 
in the add screen




+1


- build on dependencies changes



+1


- add a tests result summary in build results



+1


I'll add missing issues in jira tomorrow when I'll continue the roadmap.



Cool, thanks Emmanuel.


Emmanuel




Jason van Zyl
[EMAIL PROTECTED]

Re: Continuum 1.1 roadmap

[Emmanuel Venisse]

- Remove JDO (at least jpox) because it the source of lot of our 
issues



+1


My only opinion on this is to think about it, but save the work until we 
bump into the next big problem that is going to require a lot of effort 
to fix. It seems stable enough in 1.0.3 and if it remains that way 
through 1.1 it can buy us some time.


I'm interested in seeing how JPA progresses as a replacement for this 
(even if it requires Java 5, which it would be nice to move to anyway :) 
There should be a better choice of implementations and the API is 
similar I think.


It's a shame we're having so many problems, as the jdo api is actually 
quite nice.


BTW, have we done much trials with databases other than hsqldb and 
derby? Maybe the problem isn't JDO :)


I open an issue for the replacement of it (CONTINUUM-740). Actually, it's planned for 1.1 and we'll 
can move it to another version if we think it isn't necessary to spend lot of time on it.


Some users use Continuum with posgres, mysql or mssql and I don't know if they have issues (except 
for database schema).


Emmanuel

Re: Continuum 1.1 roadmap

[Emmanuel Venisse]

- customization of the add project feature. In this part, I think 
to add a multi-project as a multiple projects or as a single 
project, scm connection string to use, add with a scm url, add all 
modules by a scm connection instead of an url contruction based on 
project url provided in the add screen


Absolutely. We should talk through this one a bit more, as maybe the 
solution is to have it better understand module relationships. This also 
relates to something I'd like to see happen where we have the checkout 
in the normal layout instead of isolated directories (to avoid checking 
out the modules twice - once in the parent and once for each module).




I created a new issue (CONTINUUM-741)

Emmanuel

Re: Continuum 1.1 roadmap

[Emmanuel Venisse]

ok, I think the roadmap is done now. We have 159 issues.

I'll be happy if we can include all these issues in 1.1 :-)

Emmanuel

Emmanuel Venisse a écrit :

Hi,

I started to define the roadmap of continuum 1.1. It will be done 
normally tomorrow.


The major first things to do in this roadmap are:

- Reimplementation of authentication/authorization management 
(CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with 
acegi. Carlos will integrate acegi with plexus. This part must secure 
all requests in continuum and not only don't show some part of the 
interface.


- Remove JDO (at least jpox) because it the source of lot of our issues

- implementation of continuum profiles and installation 
screens(CONTINUUM-44,CONTINUUM-59)


- integration of GBuild (CONTINUUM-563)

- implementation of project groups (CONTINUUM-30, 
CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292)


Other important things I'd want to see in it:

- customization of the add project feature. In this part, I think to add 
a multi-project as a multiple projects or as a single project, scm 
connection string to use, add with a scm url, add all modules by a scm 
connection instead of an url contruction based on project url provided 
in the add screen


- build on dependencies changes

- add a tests result summary in build results

I'll add missing issues in jira tomorrow when I'll continue the roadmap.

Emmanuel

Re: Continuum 1.1 roadmap

[Emmanuel Venisse]

Trygve Laugstøl a écrit :

+1 to most stuff, comments inline.

Emmanuel Venisse wrote:

Hi,

I started to define the roadmap of continuum 1.1. It will be done 
normally tomorrow.


The major first things to do in this roadmap are:

- Reimplementation of authentication/authorization management 
(CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with 
acegi. Carlos will integrate acegi with plexus. This part must secure 
all requests in continuum and not only don't show some part of the 
interface.


- Remove JDO (at least jpox) because it the source of lot of our issues


Remove JPOX, not JDO unless it's required by the new implementation. JDO 
is a really nice specification and we already have a lot of code that 
uses it so if we can avoid it that should be prioritized.




- implementation of continuum profiles and installation 
screens(CONTINUUM-44,CONTINUUM-59)


- integration of GBuild (CONTINUUM-563)


-0, I think that this is a very useful feature but Continuum needs to 
get the basic stuff right before we start getting fancy. There is 
nothing wrong in adjusting Continuum so that it is easier to implement 
this in the future though.


- implementation of project groups (CONTINUUM-30, 
CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292)


Other important things I'd want to see in it:

- customization of the add project feature. In this part, I think to 
add a multi-project as a multiple projects or as a single project, scm 
connection string to use, add with a scm url, add all modules by a scm 
connection instead of an url contruction based on project url provided 
in the add screen


+1, but we need to discuss this as there are many ways of implementing it.


- build on dependencies changes


This is a very useful feature, have gotten lots of requests for this.


- add a tests result summary in build results


This one too.

Other things that I consider important:

* Dead Build Notification

Add a thread that will try to see if a build has been hanging for too 
long. Options include looking at the wall time elapsed, new build output.


When it discovers a hung build it can email the administrator of the 
server, automatically restart Continuum etc. If more features related to 
process control it can also try to kill the process.


We don't have this in jira, but only a stop button for hung build.
The thread will be a nice feature. I'll create an issue for this.



* Customizable Mail Templates
This is something that people find rather useful and should be pretty 
easy to include. Make sure to make room for both HTML and plain text 
emails. Document the objects that are available in the Velocity context.


The customization is already in the roadmap.

Emmanuel

Re: introduction

[Emmanuel Venisse]

Thanks Erik.

In Continuum, we use jpox with derby. Lot of users get some exception with them on requests that 
failed like foreign key violation, insert/delete errors, deadlock errors...


Our problem is this errors doesn't appears all the time and it's very difficult to reproduce them. 
I'm not sure (but I think) errors are in jpox and not in derby. I know deadlock lock and timeout 
lock are fixed in the new derby version and we'll update it.


You can see some errors in users list: 
http://www.nabble.com/forum/Search.jtp?forum=13868&local=y&query=jpox


and some issue in our jira: 
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10540&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12224


An other pb is at the continuum startup, we update the state of all projects and store it in 
database, all the code is ok but when we look in database state isn't updated. The same code is used 
 in an other part and it works fine.


Don't hesitate if you need more informations and if you want to look at our 
code.

Emmanuel

Erik Bengtson a écrit :

Hi All,

I'm a JPOX developer and because Continuum uses JPOX I thought it may be a good
idea to keep an eye in this list to help you guys in sorting out issues with
the product.

As outcome of following this project, I'm willing to reduce the troubleshooting
time spent when using JPOX and thus improve JPOX operating tools, like
documentation, logging, clear error messages and so on.

Regards,

Erik Bengtson

Re: introduction

[Emmanuel Venisse]

Thanks for your answers.

Comments inline

Erik Bengtson a écrit :

Salut,

Some issues from user list

issue 1:
Re: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR
'javax.jdo.JDODataStoreException


The data you are storing is probably larger than the column size. You should
consider changing the BUILDRESULT.ERROR column to BLOB or truncating the error
text before storing.


ok, we'll try it.



issue 2:
Using continuum with Sybase SQLServer

Emmanuel says: "So it's a jpox bug."


I'm not able to understand the issue, however I noticed that you create the
tables during the first transaction. You should instead have an init process
that invokes the JPOX schematool in order to do that, for the only reason that
some databases does not allow creating tables and quering or inserting in the
same transaction.

Secondly, to improve performance the PMF that runs your transactions should have
validation and creation of schema disabled. This is very critical for
performance.


it will improve performance at startup only, right?



issue 3:
How do i intergrate Continuum with mysql database ?


Error happening during validation of schema due to the buggy mysql jdbc driver.
(oracle and mysql have very poor jdbc drivers. mysql has very often lots of
regressions)

To avoid these issues, again the solution is to disable validation of schema.


ok.



issue 4:
[vote] Release Continuum 1.0.3

"Wrong precision for column CHANGEFILE.MODEL_ENCODING : was
255 (according to the JDBC dr
iver) but should be 256 (based on the MetaData definition). "


Sadly, JDO 2 final has changed the default length from 255 to 256. JPOX default
used to be 255 and in newer versions it is 256. JPOX allows changing this
default in a PMF setting. See docs.


I know it. we use 255 so old database are always compatible with the new schema.
If we change some fields to blob for issue 1, we'll need a migration tool for 
the new schema.



Issue 5:
Continuum 1.0.3 RC require some tester
For the memory leak, it seems it's a problem with jpox rc1.


JPOX has corrected issues on memory handling in latest versions. JPOX no longer
has such problems.


Continuum too :-)



Issue 6:
3984 [WrapperSimpleAppMain] ERROR JPOX.RDBMS.SCHEMA - An exception was thrown
while adding/validating class(es) : The size (8192) given to the column
'COMMENT' exceeds the maximum allowed for any data type (8000).
java.sql.SQLException: The size (8192) given to the column 'COMMENT' exceeds the
maximum allowed for any data type (8000).


Some databases limits the "row" length or have data types limits.

To solve it change this column to BLOB.

Issue 7:
Foreign Keys violation and locking issues.


Locking issues is usually due to concurrency and isolation levels. This is
something you have to handle in the application and configure the isolation
levels it fits better for your app. I dont believe you have any issue in derby
or jpox. If you increase isolation levels, you probably have more contention,
but less dead locks.

On foreign keys, this is usually a problem in the application for not
adding/removing dependencies first.


We don't add/remove dependencies first, it's done in cascade. It works well but in some case (hard 
to reproduce) we have foreign Keys violation and locking issues.






I strongly recommend during QA testing to use a good RDBMS that enforces
constraints, like derby, oracle, db2 or mssql. Mysql is not a good choice in
this case.


For our tests, we use hsqldb because the database is created quickly. And we use derby for 
production and integration tests





An other pb is at the continuum startup, we update the state of all projects
and store it in
database, all the code is ok but when we look in database state isn't
updated. The same code is used
  in an other part and it works fine.


if you have more info, I may be able to help


http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/DefaultContinuum.java?view=markup
at line 1968, state is always equals to p.getState(), so it's wrong. jpox doesn't update the 
database there





Don't hesitate if you need more informations and if you want to look at our
code.


I would love to but my time is short, however if you have design documents, I
can do a review.


Quoting Emmanuel Venisse <[EMAIL PROTECTED]>:


Thanks Erik.

In Continuum, we use jpox with derby. Lot of users get some exception with
them on requests that
failed like foreign key violation, insert/delete errors, deadlock errors...

Our problem is this errors doesn't appears all the time and it's very
difficult to reproduce them.
I'm not sure (but I think) errors are in jpox and not in derby. I know
deadlock lock and timeout
lock are fixed in the new derby version and we'll update it.

You can see some errors in users list:
http://www.nabbl

Re: How make my projects pom.xml SVN independent?

[Emmanuel Venisse]

You need to specify it in your pom because this information is used by continuum and by some maven 
plugins like release, changelog plugins.


What is the pb with this information in your pom? You don't change scm every day. It's the same type 
of inforation that repository or distribution tags. If you change the address of your remote 
repository, you need to change your pom too.


It's necessary to have these informations in the pom, because it's more simple to manage datas in 
one place.


Note: users messages must be sent to continuum-users@maven.apache.org

Emmanuel

Markus Wahl a écrit :

I fell I should like to specify:

--...I would like to give the url "svn:
https://daHost/repository/trunk/framework/CRM/EJB/pom.xml"; to ...-

So that Continuum knows I am talking about svn. That information is
necessary to give to continuum, but I don't think it should be necessary to
write that in my pom.xml which afterall should be SVN independant since I
can not be sure it will be stored in SVN in the future

On 8/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


I am attempting Continuum for a maven2 pom.xml that specifies a scm that
points out a subversion repository where the other project files reside.
And it works.
But the pom.xml contains the full reference to the subversion server and
the trunk of the repository:

   scm:svn:https://daHost/repository/trunk/framework/CRM/EJB

   scm:svn:
https://daHost/repository/trunk/framework/CRM/EJB


OK, so why is it necessary to include that in the pom? It is really bad
since the pom is no longer portable if the svn server changes host, or
changes to cvs e g, or even portable between branches since the URL hard
coded in the pom would not reflect the branch and instead always point to
the trunk. How can this be avoided? Ideally I would like to give the 
url "

https://daHost/repository/trunk/framework/CRM/EJB/pom.xml"; to the
Continuum web interface when adding the project, and the pom.xml would 
NOT

contain any reference to the svn. Are you with me?

The alternative of course is that I have misunderstodd something
basic. please correct me.

mvh,
markus

Re: svn commit: r431764 - /maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp

[Emmanuel Venisse]

me too.

Emmanuel

Brett Porter a écrit :

Since it's an action URL, I strong suggest using ww:url instead.

- Brett

On 16/08/2006 12:04 PM, Carlos Sanchez wrote:

i've seen this problem with tomcat. Works fine with jetty.

Please add a jira to put back the right url composition, your changes
won't work in some cases (we just moved all url composition to use
c:url)

On 8/15/06, Brett Porter <[EMAIL PROTECTED]> wrote:

There are two versions of c: - core, and core_rt. If you are including a
TLD in the webapp, make sure you have the right one.

I usually just omit the tlds in the webapp and use:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %>
(note this is JSTL 1.1, the URL is different for JSTL 1.0, which might
also be the problem).

This gets pulled from the JAR. Seems to work just fine in MRM.

- Brett

On 16/08/2006 11:41 AM, [EMAIL PROTECTED] wrote:
> Author: kenney
> Date: Tue Aug 15 18:41:17 2006
> New Revision: 431764
>
> URL: http://svn.apache.org/viewvc?rev=431764&view=rev
> Log:
> Use 
>  tags don't evaluate the expressions, somehow. Not sure why 
this doesn't

> work..
>
> This problem also exists in schedules.jsp (and probably other places).
>
> Added a workaround for the main page for now.
>
> Modified:
> maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp
>
> Modified: 
maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp
> URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp?rev=431764&r1=431763&r2=431764&view=diff 

> 
== 

> --- 
maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp 
(original)
> +++ 
maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp 
Tue Aug 15 18:41:17 2006

> @@ -19,13 +19,8 @@
>
>  cell="org.apache.maven.continuum.web.view.StateCell"/>
>  title="summary.projectTable.name" width="48%">
> -
> -href="/projectView.action?projectId=${project.id}">${project.name}
> +value="/projectView.action"/>
> +${project.name}

>  
>  title="summary.projectTable.version" width="13%"/>
>  title="summary.projectTable.build" width="5%" 
cell="org.apache.maven.continuum.web.view.BuildCell"/>

>
>


--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

Re: Please review/comment on the updated cron editor in the continuum white site

[Emmanuel Venisse]

Can you add a link to http://www.opensymphony.com/quartz/api/org/quartz/CronExpression.html, so 
users will know available formats for each fields, or add available formats near each fields


Emmanuel

Maria Odea Ching a écrit :

Sorry, I forgot to put the link for the staging site.
It's http://people.apache.org/~oching/continuum-uml/editSchedule.html 
 :)


Maria Odea Ching wrote:


Hi Everyone,

I submitted a patch for CONTINUUM-847 that updates the current cron 
editor field in the

scheduler for the white site (this is for the editSchedule.html page).

Any comments are welcome :)

Thanks,
Odea

Re: svn commit: r441173 - /maven/continuum/branches/continuum-acegi/continuum-core/pom.xml

[Emmanuel Venisse]

Why don't you use what is used in trunk? It will be hard to find difference between trunk and branch 
if you don't use the same thing in the same way.


Emmanuel

[EMAIL PROTECTED] a écrit :

Author: carlos
Date: Thu Sep  7 11:43:20 2006
New Revision: 441173

URL: http://svn.apache.org/viewvc?view=rev&rev=441173
Log:
[CONTINUUM-667] Exclude BuildProjectTaskExecutorTest

Modified:
maven/continuum/branches/continuum-acegi/continuum-core/pom.xml

Modified: maven/continuum/branches/continuum-acegi/continuum-core/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/branches/continuum-acegi/continuum-core/pom.xml?view=diff&rev=441173&r1=441172&r2=441173
==
--- maven/continuum/branches/continuum-acegi/continuum-core/pom.xml (original)
+++ maven/continuum/branches/continuum-acegi/continuum-core/pom.xml Thu Sep  7 
11:43:20 2006
@@ -159,4 +159,19 @@
   test
 
   
+
+  
+
+  
+org.apache.maven.plugins
+maven-surefire-plugin
+
+  
+
+**/BuildProjectTaskExecutorTest.*
+  
+
+  
+
+  
 

Re: Please review/comment on the updated cron editor in the continuum white site

[Emmanuel Venisse]

With this screen, all quartz cron expression will be available because we'll reconstruct it by 
concatenation.


Do you think to an expression in particular?

Emmanuel

Christian Edward Gruber a écrit :
It's quite nice.  I wonder, since there are some ways to construct cron 
schedules that don't use all fields, if it makes sense to have an 
"advanced" alternate ui that does away with the individual form values 
and tries out the single string.  In general, however, I think this 
interface is much harder to make mistakes with, which is more 
important.  I just want to make sure we don't lose any quartz 
functionality through an interface constraint.  Good job, though.


A slight variant might also work (attached).  It lays out the same form 
horizontally, so that it's visually closer to the cron.


regards,
Christian. 



Emmanuel Venisse wrote:
Can you add a link to 
http://www.opensymphony.com/quartz/api/org/quartz/CronExpression.html, 
so users will know available formats for each fields, or add available 
formats near each fields


Emmanuel

Maria Odea Ching a écrit :

Sorry, I forgot to put the link for the staging site.
It's http://people.apache.org/~oching/continuum-uml/editSchedule.html 
<http://people.apache.org/%7Eoching/continuum-uml/editSchedule.html> :)


Maria Odea Ching wrote:


Hi Everyone,

I submitted a patch for CONTINUUM-847 that updates the current cron 
editor field in the

scheduler for the white site (this is for the editSchedule.html page).

Any comments are welcome :)

Thanks,
Odea











--

*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*

Re: remove continuum-web on trunk?

[Emmanuel Venisse]

+1

Emmanuel

Brett Porter a écrit :

subject says it all... any objections?

continuum-webapp seems in adequate shape.

Re: rbac-integration continuum branch

[Emmanuel Venisse]

+1 for the merge

Emmanuel

Jesse McConnell a écrit :

Over the course of the past 3 weeks I've worked with joakim on the
plexus-security effort to bring rbac based security to Archiva.
We succeeded.

Last Friday (or so) I took the continuum/trunk and created the
rbac-integration branch.
I wanted from to test the integration of rbac based security, using
the plexus-security project, into continuum.

It integrated beautifully, without a whole lot of work, in record
time, and is pretty functional now ...

Some of the fun things that plexus-security brings with it are:

* full separation between application webapp and security (lightweight
integration).
* proper modularization for security components (authentication,
authorization, policy, system, web, etc...)
* rbac (role based access control) authorization provider.
* full user management war overlay (using healthy chunk of maven-user
to make it happen)
* toggle-able guest user authorization.
* remember me and single sign on authentication.
* forced admin account creation (through use of interceptor)
* key based authentication (remember me, single sign on, new user
validation emails, and password resets).
* http auth filters (basic and digest).
* aggressive plexus utilization.
* aggressive xwork / webwork integration.
* xwork interceptors for force admin, auto login (remember me),
secured action, and environment checks.
* secured actions for all of the /security namespace and at least one
continuum secured action (these are enforced by the
pssSecureActionInterceptor)
* all the password validation, user management stuff (again maven-user 
origins)

* continuum-security artifact containing the actual static and dynamic
roles, and a continuum role manager that merges permissions to the
core system, user, and guest users
* ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags.
* placeholders for ldap authentication, authorization and user details
retrieval using plexus ldap components
* ability to re-use Acegi for authentication

I think it is very usable now, its a matter of some jsp and action
work to clean up some things and hide some other knobs and buttons.

I'd like to get feedback and discussion from the others here about the
implementation, and consider a vote to merge it to trunk after that. I
believe it is stable enough to move forward with.

jesse

Re: [vote] rbac-integration branch merge to trunk

[Emmanuel Venisse]

+1

Emmanuel

Jesse McConnell a écrit :

Brett suggested we do a vote for this today so I figured I would just
do that now.

[-1/0/+1] vote will be open for 72 hours

Pulling from the other mail, this branch was pulled a bit over a week
ago to test out the plexus-security integration with continuum.  Some
of the added features are

* full separation between application webapp and security (lightweight
integration).
* proper modularization for security components (authentication,
authorization, policy, system, web, etc...)
* rbac (role based access control) authorization provider.
* full user management war overlay (using healthy chunk of maven-user
to make it happen)
* toggle-able guest user authorization.
* remember me and single sign on authentication.
* forced admin account creation (through use of interceptor)
* key based authentication (remember me, single sign on, new user
validation emails, and password resets).
* http auth filters (basic and digest).
* aggressive plexus utilization.
* aggressive xwork / webwork integration.
* xwork interceptors for force admin, auto login (remember me),
secured action, and environment checks.
* secured actions for all of the /security namespace and at least one
continuum secured action (these are enforced by the
pssSecureActionInterceptor)
* all the password validation, user management stuff (again maven-user 
origins)

* continuum-security artifact containing the actual static and dynamic
roles, and a continuum role manager that merges permissions to the
core system, user, and guest users
* ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags.
* placeholders for ldap authentication, authorization and user details
retrieval using plexus ldap components
* ability to re-use Acegi for authentication


+1 from me

cheers,
jesse

Re: Trunk system not adding or editing build definition

[Emmanuel Venisse]

It's a bug and I'll fix it today.

Emmanuel

Christian Edward Gruber a écrit :

Hey folks.  It seems that the edit build def is not hooked up, and the
add new build def gets an invalid group id error. 


I don't have time to hunt them down, but I wanted to check if they're
real bugs or are "in process" before I log to JIRA.

Christian.

Re: contents of a 1.1 release

[Emmanuel Venisse]

Next week, I'll start implementation of UI tests for all screens.

Emmanuel

Jason van Zyl a écrit :


On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote:

I agree with Emmanuel. IIRC, the profiles are already in the model, 
and basic choice of which JDK and maven/ant installation to use should 
be straightforward and extremely useful. I agree that making it more 
pervasive and using the toolchain support would be even better, but I 
don't believe it needs to wait for that.




I would be against any more radical changes until the testing setup is 
rock solid. We're slipping in this area. We don't really know what 
machines this stuff runs on and I don't think anything is automated 
anymore. We need to stop paying lip service to what we are preaching.


Jason.


- Brett

On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote:

The introduction of continuum profiles isn't impacted by the 
DefaultContinuum refactoring.
If we don't provide a full continuum profiles implementation in 1.1, 
I think we can do a minimal one  with only the possibility to choose 
the maven1/maven2/ant/java home directories and use them instead of 
using maven/ant/mvn/java from the PATH. This feature isn't big to do.


In 1.1, I'd like to see the possibility to choose in build 
definitions if a project is built with an update (like it's done 
actually) or with a clean checkout.


The last point, I'd like to see in 1.1 is the dependency/parent 
change build-trigger.


All these features are awaited by users since a long time. I don't 
think the implementation will take lot of time, so they can be add in 
1.1.


Of course, we need a database migration tool for the release too.

Emmanuel

Jesse McConnell a écrit :

I was going to try and wrap my head about what needed to get wrapped
up for a 1.1 release of continuum this week when I got to talking to
emmanuel this morning.
I had been under the impression that we were getting near a point that
we might want to polish things up and cut a 1.1 release but emm was
thinking that we ought to have another big push for new features
before we start polishing things up.  So I told him I would mention
our talk and see what kinda interest we got from people on new
features and who might want to tackle what in the short term, or if we
wanted to put some things out into the longer term bin.
One of the major things that I had been thinking we would push off to
the 1.2 release was the profiles.  Its a slightly overridden term as
it has little to do with maven profiles, but in my mind at least the
profiles were going to be 1/3 of a trinity by which builds could be
setup to run.
The trinity being: profile (maven instance, env vars, maven profiles,
jdk instance, etc), temporal ( scheduled cron, when dependency
changes, scm activity, etc) and the project group (bundle of
projects).  I was figuring that those three things taken together
ought meet the requirements for building what, where and when.  It
would be a matter of setting up the permutations of those three
components, for example: 2 profiles, 1 schedule, 1 project group would
make 2 instances of schedulable FOO.
Anyway, I digress...profiles would be one large feature that would be
wonderful to have in continuum, sooner the better.  But it would be
pretty massive effects on the codebase.  So massive that I would think
we ought to consider splitting up the DefaultContinuum object into the
workflows that have been kicked around, making things like 'Add
Project To Project Group' extensible by users so they can trigger any
other processes they might want running on those events.  Trygve has
some definite ideas in this area, perhaps using the plexus-spe code.
The actions in continuum have been a first pass attempt at starting to
break things out of the DC object which is pretty big atm.
If we were going to rip the top off of the DefaultContinuum object and
add/modify in the profile concepts into the store then we really ought
to clean up the whole store api which is more painful to work with
then it really should be.  joakim and I had a lot of success with
structuring things nicely in the plexus-security jdo stores and we
could probably apply a ton of the concepts there in terms of api to
the continuum-store and make it scads easier to work with.
and on and on.
I agree with Emmanuel that since 1.1 as it currently stands is not
backwards compatible (I think) with the old database we ought to just
add in what we need now...But doing this will definitely move out a
1.1 release into the new year...and is that something we want to do?
I dunno really, personally I would be cool with adding in profiles and
refactoring the core chunks of continuum up now and get it over with,
but does anyone else have anything to say on the matter?  I know we
have had a lot more interest recently by folks like rahul and
christian on participating, would you guys be interested in taking on
some of these cha

Re: contents of a 1.1 release

[Emmanuel Venisse]

jwebunit

Dan Tran a écrit :

Just curious, what kind of web test framework are you going to use?

-D


On 10/18/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


Next week, I'll start implementation of UI tests for all screens.

Emmanuel

Jason van Zyl a écrit :
>
> On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote:
>
>> I agree with Emmanuel. IIRC, the profiles are already in the model,
>> and basic choice of which JDK and maven/ant installation to use should
>> be straightforward and extremely useful. I agree that making it more
>> pervasive and using the toolchain support would be even better, but I
>> don't believe it needs to wait for that.
>>
>
> I would be against any more radical changes until the testing setup is
> rock solid. We're slipping in this area. We don't really know what
> machines this stuff runs on and I don't think anything is automated
> anymore. We need to stop paying lip service to what we are preaching.
>
> Jason.
>
>> - Brett
>>
>> On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote:
>>
>>> The introduction of continuum profiles isn't impacted by the
>>> DefaultContinuum refactoring.
>>> If we don't provide a full continuum profiles implementation in 1.1,
>>> I think we can do a minimal one  with only the possibility to choose
>>> the maven1/maven2/ant/java home directories and use them instead of
>>> using maven/ant/mvn/java from the PATH. This feature isn't big to do.
>>>
>>> In 1.1, I'd like to see the possibility to choose in build
>>> definitions if a project is built with an update (like it's done
>>> actually) or with a clean checkout.
>>>
>>> The last point, I'd like to see in 1.1 is the dependency/parent
>>> change build-trigger.
>>>
>>> All these features are awaited by users since a long time. I don't
>>> think the implementation will take lot of time, so they can be add in
>>> 1.1.
>>>
>>> Of course, we need a database migration tool for the release too.
>>>
>>> Emmanuel
>>>
>>> Jesse McConnell a écrit :
>>>> I was going to try and wrap my head about what needed to get wrapped
>>>> up for a 1.1 release of continuum this week when I got to talking to
>>>> emmanuel this morning.
>>>> I had been under the impression that we were getting near a point
that
>>>> we might want to polish things up and cut a 1.1 release but emm was
>>>> thinking that we ought to have another big push for new features
>>>> before we start polishing things up.  So I told him I would mention
>>>> our talk and see what kinda interest we got from people on new
>>>> features and who might want to tackle what in the short term, or if
we
>>>> wanted to put some things out into the longer term bin.
>>>> One of the major things that I had been thinking we would push 
off to

>>>> the 1.2 release was the profiles.  Its a slightly overridden term as
>>>> it has little to do with maven profiles, but in my mind at least the
>>>> profiles were going to be 1/3 of a trinity by which builds could be
>>>> setup to run.
>>>> The trinity being: profile (maven instance, env vars, maven 
profiles,

>>>> jdk instance, etc), temporal ( scheduled cron, when dependency
>>>> changes, scm activity, etc) and the project group (bundle of
>>>> projects).  I was figuring that those three things taken together
>>>> ought meet the requirements for building what, where and when.  It
>>>> would be a matter of setting up the permutations of those three
>>>> components, for example: 2 profiles, 1 schedule, 1 project group
would
>>>> make 2 instances of schedulable FOO.
>>>> Anyway, I digress...profiles would be one large feature that 
would be

>>>> wonderful to have in continuum, sooner the better.  But it would be
>>>> pretty massive effects on the codebase.  So massive that I would
think
>>>> we ought to consider splitting up the DefaultContinuum object into
the
>>>> workflows that have been kicked around, making things like 'Add
>>>> Project To Project Group' extensible by users so they can trigger 
any

>>>> other processes they might want running on those events.  Trygve has
>>>> some definite ideas in this area, perhaps using the plexus-spe code.
>>>> The actions in continuum have been a first pass attempt at starting
to
>>>> break things out of the DC objec

Test

[Emmanuel Venisse]

This is a test.

Emmanuel

Re: build scheduling issues

[Emmanuel Venisse]

Yes, we need a global ordering, so projects will be build independently of groups, because in some 
case a cycle can be created between groups (not necessary between projects).


In case a cycle is detected between projects, continuum can't find the build order. In this case, I 
think we need to sort a little project so will reduce build errors. So if we have a cycle, we can 
sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in 
a group.


Emmanuel

Brett Porter a écrit :
I think you want global ordering. Grouping should just be a 
display/management technique, not anything that changes how projects are 
handled.


However, this needs to be reviewed as a whole (which I think Emmanuel is 
doing), such that builds can be triggered when their dependencies change 
which will help with the ordering as it won't be dependant on them all 
being triggered at the same time?


- Brett

On 08/11/2006, at 9:51 AM, Jesse McConnell wrote:


I was reading through the DefaultContinuum.buildProjects( Schedule id
) method and after discussing some things with Emmanuel...I think we
have a problem here.  When I went through and refactored things to
support a more Project Group centric setup with continuum I changed
this method a bit.

Originally, this method would gather up all projects that would be
triggered by that schedule, run them all through the project sorter
and then build each in sequence.

When I added the project groups to this mix, I changed things to be on
a project group basis, so that on a project group by project group
basis it would order the projects and build them.  At the time I
thought this was the way to go...but maybe not.

17:14  we need to take all projects from all groups, sort them
17:15  if we don't have a cycle, it's ok and we build all
17:15  if it isn't ok, we sort project by group

For example, if we loaded up a Plexus group and a Maven group...the
way it currently is (with my change) it would process all triggered
builds within one group and then process all triggered builds in the
other group.   This would not take into account potential dependencies
between the two.

Does anyone have any thoughts on this?  I am inclined to fix it up so
its like it used to be where all projects across all project groups
are thrown into the graphI keep feeling like I am missing
something wrong with this, but I can't pin it down.

One thing that perhaps Emmanuel could explain a bit more is the third
comment there.  In our conversation on this he said that he thinks
that the cycles are cropping up all the time, and if thats the case
then we are building a lot of unordered builds which would account for
some of the strange reports we have been getting.  Are you saying that
if we detect the cycle we default back to the way I am doing it now?
order within the groups...

jesse





--jesse mcconnell
[EMAIL PROTECTED]

Re: svn commit: r479498 - in /maven/continuum/trunk: ./ continuum-cc/ continuum-distributed/ continuum-sandbox/continuum-cc/ continuum-sandbox/continuum-distributed/ continuum-sandbox/continuum-update

[Emmanuel Venisse]

It's isn't an old module but a not used module, so it should be in sandbox.

Emmanuel

Jason van Zyl a écrit :

continuum-distributed is not an old module, please put that one back.

Jason.

On 26 Nov 06, at 9:54 PM 26 Nov 06, [EMAIL PROTECTED] wrote:


Author: brett
Date: Sun Nov 26 18:54:54 2006
New Revision: 479498

URL: http://svn.apache.org/viewvc?view=rev&rev=479498
Log:
move old modules to the sandbox

Added:
maven/continuum/trunk/continuum-sandbox/continuum-cc/
  - copied from r479496, maven/continuum/trunk/continuum-cc/
maven/continuum/trunk/continuum-sandbox/continuum-distributed/
  - copied from r479496, maven/continuum/trunk/continuum-distributed/
maven/continuum/trunk/continuum-sandbox/continuum-updater/
  - copied from r479496, maven/continuum/trunk/continuum-updater/
maven/continuum/trunk/continuum-sandbox/continuum-xfire/
  - copied from r479496, maven/continuum/trunk/continuum-xfire/
Removed:
maven/continuum/trunk/continuum-cc/
maven/continuum/trunk/continuum-distributed/
maven/continuum/trunk/continuum-updater/
maven/continuum/trunk/continuum-xfire/
Modified:
maven/continuum/trunk/pom.xml

Modified: maven/continuum/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diff&rev=479498&r1=479497&r2=479498 

== 


--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Sun Nov 26 18:54:54 2006
@@ -82,7 +82,6 @@
   
 continuum-api
 continuum-security
-continuum-cc
 

 continuum-core
 continuum-model
@@ -92,7 +91,6 @@
 continuum-rpc-client
 continuum-store
 continuum-test
- 

 continuum-webapp
 continuum-xmlrpc
 continuum-release

Re: CONTINUUM-990: New properties to pass to m2 builds from Continuum?

[Emmanuel Venisse]

I don't have objections but I think we can do the same thing for m1 and ant 
projects.

Emmanuel

Brett Porter a écrit :

Hi,

There is a proposal to add the following properties for continuum to 
pass to m2 builds:


properties.setProperty("continuum.project.group.name", 
project.getProjectGroup().getName());
properties.setProperty("continuum.project.lastBuild.state", 
String.valueOf(project.getOldState()));
properties.setProperty("continuum.project.lastBuild.number", 
String.valueOf(project.getBuildNumber()));
properties.setProperty("continuum.project.nextBuild.number", 
String.valueOf(project.getBuildNumber() + 1));


These all seem useful - any objections to applying the patch?

- Brett

Re: CONTINUUM-798: module discovery

[Emmanuel Venisse]

Brett Porter a écrit :

Hi Jesse,

I see you took this one a couple of months ago. It looks like a good 
feature - is the patch a good enough start to use for now?


It was submitted by John Didion - John, are you hanging around? Are you 
able to help get that applied and work through some of the limitations?


I'm pretty keen to see this one land :)


Me too, and it will be fix CONTINUUM-1098

Emmanuel

Re: CONTINUUM-798: module discovery

[Emmanuel Venisse]

Yes, we can use, it seems to be good but it won't work for modules with a 
relative path like ../mymodule

Emmanuel

Brett Porter a écrit :

Great - can the patch be used as a starting point?

On 03/01/2007, at 2:27 AM, Emmanuel Venisse wrote:




Brett Porter a écrit :

Hi Jesse,
I see you took this one a couple of months ago. It looks like a good 
feature - is the patch a good enough start to use for now?
It was submitted by John Didion - John, are you hanging around? Are 
you able to help get that applied and work through some of the 
limitations?

I'm pretty keen to see this one land :)


Me too, and it will be fix CONTINUUM-1098

Emmanuel

Re: CONTINUUM-798: module discovery

[Emmanuel Venisse]

yes, it will be the easiest solution, but in future we'll can resolve them too if we search in the database the project with the scm url (svn_url_of current_pom/module_path), if it doesn't exist, we 
checkout the module and add it in continuum.



Brett Porter a écrit :
fair enough, as long as we have sensible, pre-emptive error messages 
(perhaps just a warning that module X was ignored due to invalid path).


On 04/01/2007, at 12:57 AM, Emmanuel Venisse wrote:

Yes, we can use, it seems to be good but it won't work for modules 
with a relative path like ../mymodule


Emmanuel

Brett Porter a écrit :

Great - can the patch be used as a starting point?
On 03/01/2007, at 2:27 AM, Emmanuel Venisse wrote:



Brett Porter a écrit :

Hi Jesse,
I see you took this one a couple of months ago. It looks like a 
good feature - is the patch a good enough start to use for now?
It was submitted by John Didion - John, are you hanging around? Are 
you able to help get that applied and work through some of the 
limitations?

I'm pretty keen to see this one land :)


Me too, and it will be fix CONTINUUM-1098

Emmanuel

Re: continuum build error

[Emmanuel Venisse]

ant projects works fine. Probably a bad project config.

Send us your logs and the build definition of your project.

Emmanuel

prash57 a écrit :

I'm trying to build using Continuum/ANT and and running into the following
error.

The system cannot find the batch label specified - end

When I try to run the ant.bat file directly vi a command prompt, it works
fine

I'm using ANT 1.6.5



plz help

thx

Re: svn commit: r498659 - in /maven/continuum/trunk: ./ continuum-plexus-application/ continuum-plexus-runtime/ continuum-release/ continuum-store/src/test/java/org/apache/maven/continuum/store/ conti

[Emmanuel Venisse]

I wanted to test modello-aplha-14 (MODELLO-80) with maven-2.0.5 before to use 
this patch

Emmanuel

[EMAIL PROTECTED] a écrit :

Author: jvanzyl
Date: Mon Jan 22 07:46:49 2007
New Revision: 498659

URL: http://svn.apache.org/viewvc?view=rev&rev=498659
Log:
CONTINUUM-1101 Updating continuum to the lastest app server
Submitted by: Andy Williams

Modified:
maven/continuum/trunk/continuum-plexus-application/pom.xml
maven/continuum/trunk/continuum-plexus-runtime/pom.xml
maven/continuum/trunk/continuum-release/pom.xml

maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java
maven/continuum/trunk/continuum-webapp/pom.xml
maven/continuum/trunk/pom.xml

Modified: maven/continuum/trunk/continuum-plexus-application/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-plexus-application/pom.xml?view=diff&rev=498659&r1=498658&r2=498659
==
--- maven/continuum/trunk/continuum-plexus-application/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-application/pom.xml Mon Jan 22 
07:46:49 2007
@@ -32,7 +32,7 @@
   
 org.codehaus.plexus
 plexus-appserver-maven-plugin
-2.0-alpha-5
+2.0-alpha-7-SNAPSHOT
 true
 
   
src/conf/application.xml

Modified: maven/continuum/trunk/continuum-plexus-runtime/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-plexus-runtime/pom.xml?view=diff&rev=498659&r1=498658&r2=498659
==
--- maven/continuum/trunk/continuum-plexus-runtime/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-runtime/pom.xml Mon Jan 22 07:46:49 
2007
@@ -39,13 +39,13 @@
 
   org.codehaus.plexus
   plexus-appserver-host
-  2.0-alpha-5
+  2.0-alpha-7-SNAPSHOT
 
 
 
   org.codehaus.plexus
   plexus-appserver-service-jetty
-  2.0-alpha-5
+  2.0-alpha-7-SNAPSHOT
   plexus-service
 
 
@@ -90,7 +90,7 @@
   
 org.codehaus.plexus
 plexus-appserver-maven-plugin
-2.0-alpha-5
+2.0-alpha-7-SNAPSHOT
 true
 
   

Modified: maven/continuum/trunk/continuum-release/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-release/pom.xml?view=diff&rev=498659&r1=498658&r2=498659
==
--- maven/continuum/trunk/continuum-release/pom.xml (original)
+++ maven/continuum/trunk/continuum-release/pom.xml Mon Jan 22 07:46:49 2007
@@ -63,6 +63,12 @@
   org.apache.maven.release
   maven-release-manager
   1.0-SNAPSHOT
+  
+
+  classworlds
+  classworlds
+
+  
 
 
   org.codehaus.plexus

Modified: 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java?view=diff&rev=498659&r1=498658&r2=498659
==
--- 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java
 (original)
+++ 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java
 Mon Jan 22 07:46:49 2007
@@ -430,6 +430,8 @@
 {
 super.tearDown();
 
+store.eraseDatabase();

+
 store.closeStore();
 }
 


Modified: maven/continuum/trunk/continuum-webapp/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?view=diff&rev=498659&r1=498658&r2=498659
==
--- maven/continuum/trunk/continuum-webapp/pom.xml (original)
+++ maven/continuum/trunk/continuum-webapp/pom.xml Mon Jan 22 07:46:49 2007
@@ -253,7 +253,7 @@
 
   org.codehaus.plexus
   plexus-xwork-integration
-  1.0-alpha-3
+  1.0-alpha-5-SNAPSHOT
 
 
   javax.servlet

Modified: maven/continuum/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diff&rev=498659&r1=498658&r2=498659
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Mon Jan 22 07:46:49 2007
@@ -140,8 +140,13 @@
 
 
   org.codehaus.plexus
+  plexus-component-api
+  1.0-alpha-16-SNAPSHOT
+
+
+  org.codehaus.plexus
   plexus-container-default
-  1.0-alpha-10
+  1.0-alpha-16-SNAPSHOT
 
   
   
@@ -150,6 +155,12 @@
 org.apache.maven
 maven-core
 ${maven.version}
+

Re: svn commit: r498659 - in /maven/continuum/trunk: ./ continuum-plexus-application/ continuum-plexus-runtime/ continuum-release/ continuum-store/src/test/java/org/apache/maven/continuum/store/ conti

[Emmanuel Venisse]

same pb with or without this patch.

Emmanuel

Emmanuel Venisse a écrit :
I wanted to test modello-aplha-14 (MODELLO-80) with maven-2.0.5 before 
to use this patch


Emmanuel

[EMAIL PROTECTED] a écrit :

Author: jvanzyl
Date: Mon Jan 22 07:46:49 2007
New Revision: 498659

URL: http://svn.apache.org/viewvc?view=rev&rev=498659
Log:
CONTINUUM-1101 Updating continuum to the lastest app server
Submitted by: Andy Williams

Modified:
maven/continuum/trunk/continuum-plexus-application/pom.xml
maven/continuum/trunk/continuum-plexus-runtime/pom.xml
maven/continuum/trunk/continuum-release/pom.xml

maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java 


maven/continuum/trunk/continuum-webapp/pom.xml
maven/continuum/trunk/pom.xml

Modified: maven/continuum/trunk/continuum-plexus-application/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-plexus-application/pom.xml?view=diff&rev=498659&r1=498658&r2=498659 

== 


--- maven/continuum/trunk/continuum-plexus-application/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-application/pom.xml Mon Jan 
22 07:46:49 2007

@@ -32,7 +32,7 @@
   
 org.codehaus.plexus
 plexus-appserver-maven-plugin
-2.0-alpha-5
+2.0-alpha-7-SNAPSHOT
 true
 
   
src/conf/application.xml 



Modified: maven/continuum/trunk/continuum-plexus-runtime/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-plexus-runtime/pom.xml?view=diff&rev=498659&r1=498658&r2=498659 

== 


--- maven/continuum/trunk/continuum-plexus-runtime/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-runtime/pom.xml Mon Jan 22 
07:46:49 2007

@@ -39,13 +39,13 @@
 
   org.codehaus.plexus
   plexus-appserver-host
-  2.0-alpha-5
+  2.0-alpha-7-SNAPSHOT
 
 
 
   org.codehaus.plexus
   plexus-appserver-service-jetty
-  2.0-alpha-5
+  2.0-alpha-7-SNAPSHOT
   plexus-service
 
 
@@ -90,7 +90,7 @@
   
 org.codehaus.plexus
 plexus-appserver-maven-plugin
-2.0-alpha-5
+2.0-alpha-7-SNAPSHOT
 true
 
   

Modified: maven/continuum/trunk/continuum-release/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-release/pom.xml?view=diff&rev=498659&r1=498658&r2=498659 

== 


--- maven/continuum/trunk/continuum-release/pom.xml (original)
+++ maven/continuum/trunk/continuum-release/pom.xml Mon Jan 22 
07:46:49 2007

@@ -63,6 +63,12 @@
   org.apache.maven.release
   maven-release-manager
   1.0-SNAPSHOT
+  
+
+  classworlds
+  classworlds
+
+  
 
 
   org.codehaus.plexus

Modified: 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java 

URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java?view=diff&rev=498659&r1=498658&r2=498659 

== 

--- 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java 
(original)
+++ 
maven/continuum/trunk/continuum-store/src/test/java/org/apache/maven/continuum/store/AbstractContinuumStoreTestCase.java 
Mon Jan 22 07:46:49 2007

@@ -430,6 +430,8 @@
 {
 super.tearDown();
 
+store.eraseDatabase();

+
 store.closeStore();
 }
 


Modified: maven/continuum/trunk/continuum-webapp/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?view=diff&rev=498659&r1=498658&r2=498659 

== 


--- maven/continuum/trunk/continuum-webapp/pom.xml (original)
+++ maven/continuum/trunk/continuum-webapp/pom.xml Mon Jan 22 07:46:49 
2007

@@ -253,7 +253,7 @@
 
   org.codehaus.plexus
   plexus-xwork-integration
-  1.0-alpha-3
+  1.0-alpha-5-SNAPSHOT
 
 
   javax.servlet

Modified: maven/continuum/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?view=diff&rev=498659&r1=498658&r2=498659 

== 


--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Mon Jan 22 07:46:49 2007
@@ -140,8 +140,13 @@
 
 
   org.codehaus.plexus
+  plexus-component-api
+  1.0-alpha-16-SNAPSHOT
+
+
+  org.codehaus.pl