Re: Confused about the branches
IMHO, we can remove. 2008/3/10, Rahul Thakur [EMAIL PROTECTED]: There are some other branches residing in Continuum SVN. Should we remove any (or all) of the following if they are not in active development? I know (id-refactor and key-based-refactor can go) # continuum-acegi # continuum-site_1.1 # gbuild # id-refactor # key-based-refactor # osworkflow-integration # release-integration Cheers, Rahul Brett Porter wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r635719 - in /continuum/trunk: ./ continuum-api/ continuum-commons/ continuum-configuration/ continuum-core/ continuum-data-management/ continuum-data-management/continuum-legacy/ cont
On 11/03/2008, at 9:05 AM, [EMAIL PROTECTED] wrote:
- value${JAVA_HOME}/value
+ value${java.homr}/value
java.home?
- value${M2_HOME}/value
+ value${m2.home}/value
maven.home?
:)
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: Confused about the branches
The branches have been removed except for 'continuum-site_1.1' which had some updates a few months ago. If this is not required please feel free to remove. Rahul Olivier Lamy wrote: IMHO, we can remove. 2008/3/10, Rahul Thakur[EMAIL PROTECTED]: There are some other branches residing in Continuum SVN. Should we remove any (or all) of the following if they are not in active development? I know (id-refactor and key-based-refactor can go) # continuum-acegi # continuum-site_1.1 # gbuild # id-refactor # key-based-refactor # osworkflow-integration # release-integration Cheers, Rahul Brett Porter wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trouble building maven-plugins parent pom in Continuum
Even though it uses --non-recursive to build, the checkout does not exclude any subdirectories. This would occur in the checkout/update and building changesets. On 10/03/2008, at 4:08 AM, Wendy Smoak wrote: I added maven/plugins/trunk/pom.xml to Continuum 1.1 and forced a build of the maven-plugins parent pom. (This is my own instance, not vmbuild or the maven zone.) It's using the default --non-recursive build definition, so I don't understand this error: INFO | jvm 1| 2008/03/09 09:55:55 | edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDOFatalUserException: Attempt to store value /maven/plugins/trunk/maven-dependency-plugin/src/site/apt/examples/ resolving-conflicts-using-the-dependency-tree.apt (from /maven/plugins/branches/maven-dependency-plugin-MDEP-100/src/ site/apt/examples/resolving-conflicts-using-the-dependency-tree.apt: 591694) in column NAME that has maximum length of 255. Please correct your data! The full stack trace from the logs is here: http://wiki.wsmoak.net/cgi-bin/wiki.pl?Continuum/MavenPluginsError Any ideas? -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trouble building maven-plugins parent pom in Continuum
On Sun, Mar 9, 2008 at 12:48 PM, Brett Porter [EMAIL PROTECTED] wrote: Even though it uses --non-recursive to build, the checkout does not exclude any subdirectories. This would occur in the checkout/update and building changesets. Is a build error and Please correct your data! the right response here, or can Continuum do something useful like truncate the data and keep going? -- Wendy
Re: Trouble building maven-plugins parent pom in Continuum
I think Continuum needs to allow longer values in here - it certainly should not error out. On 10/03/2008, at 7:13 AM, Wendy Smoak wrote: On Sun, Mar 9, 2008 at 12:48 PM, Brett Porter [EMAIL PROTECTED] wrote: Even though it uses --non-recursive to build, the checkout does not exclude any subdirectories. This would occur in the checkout/update and building changesets. Is a build error and Please correct your data! the right response here, or can Continuum do something useful like truncate the data and keep going? -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trouble building maven-plugins parent pom in Continuum
Hi, Currently the max size for this field is 512. class nameChangeFile/name packageNameorg.apache.maven.continuum.model.scm/packageName version1.0.9+/version fields field name stash.maxSize=512name/name version1.0.9+/version typeString/type /field Which doens't look enough. 1024 ? -- Olivier 2008/3/9, Brett Porter [EMAIL PROTECTED]: I think Continuum needs to allow longer values in here - it certainly should not error out. On 10/03/2008, at 7:13 AM, Wendy Smoak wrote: On Sun, Mar 9, 2008 at 12:48 PM, Brett Porter [EMAIL PROTECTED] wrote: Even though it uses --non-recursive to build, the checkout does not exclude any subdirectories. This would occur in the checkout/update and building changesets. Is a build error and Please correct your data! the right response here, or can Continuum do something useful like truncate the data and keep going? -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trouble building maven-plugins parent pom in Continuum
512 should be - the error Wendy got was going over 255. On 10/03/2008, at 9:08 AM, Olivier Lamy wrote: Hi, Currently the max size for this field is 512. class nameChangeFile/name packageNameorg.apache.maven.continuum.model.scm/packageName version1.0.9+/version fields field name stash.maxSize=512name/name version1.0.9+/version typeString/type /field Which doens't look enough. 1024 ? -- Olivier 2008/3/9, Brett Porter [EMAIL PROTECTED]: I think Continuum needs to allow longer values in here - it certainly should not error out. On 10/03/2008, at 7:13 AM, Wendy Smoak wrote: On Sun, Mar 9, 2008 at 12:48 PM, Brett Porter [EMAIL PROTECTED] wrote: Even though it uses --non-recursive to build, the checkout does not exclude any subdirectories. This would occur in the checkout/update and building changesets. Is a build error and Please correct your data! the right response here, or can Continuum do something useful like truncate the data and keep going? -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: VMBuild needs volunteers
Hi, If I can help I will (propably not a 24/7 support :-) ). 2008/3/8, Wendy Smoak [EMAIL PROTECTED]: We have a Continuum instance available for ASF projects to use: http://vmbuild.apache.org/continuum/groupSummary.action This is our (internal) public face, and it would be great to have more volunteers keeping an eye on it! It was down this morning, so I re-started it (at 11AM MST.) I didn't investigate why it was unhappy. One thing we really need to do is upgrade it to the latest version. I'm hesitant to take that on alone, but maybe someone else is braver than I, or 2-3 people might collaborate to get it done and documented. Sure won't be so easy (is all the build history important ?) And there are 11 open issues: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10410component=12311662resolution=-1sorter/field=prioritysorter/order=DESC There is some documentation here: http://cwiki.apache.org/confluence/display/vmbuild/Home (This needs to be moved into svn to better conform with other infra documentation, something that's been on my list for a while now...) Ok but where ? (something like https://svn.apache.org/repos/asf/vmbuild or https://svn.apache.org/repos/asf/continuum/vmbuild). Using a site write with the maven format (apt xdoc) ? -- Wendy
Re: Confused about the branches
2008/3/4, Brett Porter [EMAIL PROTECTED]: On 05/03/2008, at 5:18 AM, Olivier Lamy wrote: 2008/3/4, Brett Porter [EMAIL PROTECTED]: On 04/03/2008, at 10:47 AM, Olivier Lamy wrote: Agree on this. Currently there is a blocking issue with xml-rpc CONTINUUM-1590 which prevent using xml-rpc :-(. Cool - shall we just start using the 1.2 bucket in JIRA? There are only 14 issues there now so maybe we could keep that to 20-30 issues all together and release it. +1 ok, I'll get my stuff in there I found these changes on trunk that are not on the branch: r617400. (The rest is documentation) I found these changes on the branch that are not on trunk: r627196, r620613, r620612, r620611 I think we should just merge all those from the branch to trunk, set it as v1.2, and close the branch for now? +1. (Perso, I don't really like the idea of starting a parrallel branch/trunk a la mvn 2.1 :-) ) I'll merge the changes to trunk - but will wait to hear other's opinions on this too before changing the branch It looks we don't have any objections/opinions. All changes from branch has been merged. I will rename the version in the trunk to 1.2 (tomorow). If no objections, I will change root pom to not have anymore maven pom as parent. Sounds good - do you think we should have a Continuum parent POM like we do for Archiva? https://svn.apache.org/repos/asf/continuum/parent/trunk ? A new pom without parent ? (I can certainly copy some contents from the maven parent pom) With an ASF parent instead of the Maven one, yep. Question : do we have to change the groupId in the poms : org.apache.maven.continuum - org.apache.continuum ( java package too ? looks a big bang) I don't see any downside to doing this :) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
There are some other branches residing in Continuum SVN. Should we remove any (or all) of the following if they are not in active development? I know (id-refactor and key-based-refactor can go) # continuum-acegi # continuum-site_1.1 # gbuild # id-refactor # key-based-refactor # osworkflow-integration # release-integration Cheers, Rahul Brett Porter wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Build Error against trunk - First Build
Thanks all. I added the repository in pom and it started working fine, but
seems to be stuck in the package phase (jar:jar) at:
*[WARNING] DEPRECATED [descriptor]: Please use descriptors instead
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : ...\workspace\Continuum1\continuum-ple
xus-runtime\target\apache-continuum-2.0-SNAPSHOT-bin.tar.gz
[INFO] Building tar : ...\workspace\Continuum1\continuum-ple
xus-runtime\target\apache-continuum-2.0-SNAPSHOT-bin.tar.bz2
*BTW, I did a mvn -Dmaven.test.skip clean install.*
*
Also, Can we change the svn URL in this page -
http://maven.apache.org/continuum/source-repository.html - to the right one
please? It took me a while to find the right one.
Thanks.
Murali
On Fri, Mar 7, 2008 at 5:53 PM, Olivier Lamy [EMAIL PROTECTED] wrote:
Oops.
I have fixed that in the branch but not in the trunk. (my bad !!).
The parent pom is deployed in the apache snapshot repo.
You can fix that by adding the following repo in your settings.
!-- comment when continuum parent is released --
repository
idpeople.apache.org/id
nameApache Snapshot Development Repository/name
urlhttp://people.apache.org/repo/m2-snapshot-repository/url
releases
enabledfalse/enabled
/releases
/repository
Again sorry I will fix that.
--
Olivier
2008/3/7, Wendy Smoak [EMAIL PROTECTED]:
On Fri, Mar 7, 2008 at 10:13 AM, murali mohan [EMAIL PROTECTED]
wrote:
Downloaded the source from svn trunk. Trying to compile, but get this
error
- *
org.apache.maven.reactor.MavenExecutionException: Cannot find
parent:
org.apache
.continuum:continuum-parent for project:
org.apache.continuum:continuum:pom:2.0-
SNAPSHOT for project
org.apache.continuum:continuum:pom:2.0-SNAPSHOT*
Sorry about that, we're still under construction during the move to a
top-level project.
I suspect it's this one:
http://svn.apache.org/repos/asf/continuum/parent/trunk/
Try checking that out and building it locally, then building Continuum
again.
--
Wendy
Re: Account locked
all accounts lock to prevent raw dictionary attacks, and you can unlock by restarting the server, then all admin accounts unlock jesse On Tue, Mar 4, 2008 at 7:07 AM, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, After trying to log into our continuum v1.1 instance as an admin, continuum is telling us: Account Locked Project Groups list is empty. Why would the admin account ever be locked, and how does one unlock it? Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: Confused about the branches
2008/3/4, Brett Porter [EMAIL PROTECTED]: On 04/03/2008, at 10:47 AM, Olivier Lamy wrote: Agree on this. Currently there is a blocking issue with xml-rpc CONTINUUM-1590 which prevent using xml-rpc :-(. Cool - shall we just start using the 1.2 bucket in JIRA? There are only 14 issues there now so maybe we could keep that to 20-30 issues all together and release it. +1 I found these changes on trunk that are not on the branch: r617400. (The rest is documentation) I found these changes on the branch that are not on trunk: r627196, r620613, r620612, r620611 I think we should just merge all those from the branch to trunk, set it as v1.2, and close the branch for now? +1. (Perso, I don't really like the idea of starting a parrallel branch/trunk a la mvn 2.1 :-) ) If no objections, I will change root pom to not have anymore maven pom as parent. Sounds good - do you think we should have a Continuum parent POM like we do for Archiva? https://svn.apache.org/repos/asf/continuum/parent/trunk ? A new pom without parent ? (I can certainly copy some contents from the maven parent pom) Question : do we have to change the groupId in the poms : org.apache.maven.continuum - org.apache.continuum ( java package too ? looks a big bang) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
On 05/03/2008, at 5:18 AM, Olivier Lamy wrote: 2008/3/4, Brett Porter [EMAIL PROTECTED]: On 04/03/2008, at 10:47 AM, Olivier Lamy wrote: Agree on this. Currently there is a blocking issue with xml-rpc CONTINUUM-1590 which prevent using xml-rpc :-(. Cool - shall we just start using the 1.2 bucket in JIRA? There are only 14 issues there now so maybe we could keep that to 20-30 issues all together and release it. +1 ok, I'll get my stuff in there I found these changes on trunk that are not on the branch: r617400. (The rest is documentation) I found these changes on the branch that are not on trunk: r627196, r620613, r620612, r620611 I think we should just merge all those from the branch to trunk, set it as v1.2, and close the branch for now? +1. (Perso, I don't really like the idea of starting a parrallel branch/trunk a la mvn 2.1 :-) ) I'll merge the changes to trunk - but will wait to hear other's opinions on this too before changing the branch If no objections, I will change root pom to not have anymore maven pom as parent. Sounds good - do you think we should have a Continuum parent POM like we do for Archiva? https://svn.apache.org/repos/asf/continuum/parent/trunk ? A new pom without parent ? (I can certainly copy some contents from the maven parent pom) With an ASF parent instead of the Maven one, yep. Question : do we have to change the groupId in the poms : org.apache.maven.continuum - org.apache.continuum ( java package too ? looks a big bang) I don't see any downside to doing this :) - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r633704 - in /continuum/branches/continuum-1.x: ./ continuum-api/ continuum-commons/ continuum-configuration/ continuum-core-it/ continuum-core/ continuum-data-management/ continuum-da
On 05/03/2008, at 10:28 AM, [EMAIL PROTECTED] wrote:
use new continuum parent
change groupId to org.apache.continuum (continuun is now TLP :-) )
Will this be merged to trunk too?
archive
manifest
-
mainClassorg.apache.maven.continuum.management.DataManagementCli/
mainClass
+
mainClassorg.apache.continuum.management.DataManagementCli/
mainClass
/manifest
/archive
/configuration
...
dependencies
dependency
- groupIdorg.apache.maven.continuum/groupId
+ groupIdorg.apache.continuum/groupId
artifactIdcontinuum-xmlrpc-client/artifactId
version${project.version}/version
/dependency
@@ -60,7 +60,7 @@
arguments
argument-classpath/argument
classpath /
-
argumentorg.apache.maven.continuum.xmlrpc.backup.Backup/argument
+argumentorg.apache.continuum.xmlrpc.backup.Backup/
argument
argument-h/argument
/arguments
/configuration
@@ -73,7 +73,7 @@
descriptorsrc/assembly/app.xml/descriptor
archive
manifest
-
mainClassorg.apache.maven.continuum.xmlrpc.backup.Backup/mainClass
+ mainClassorg.apache.continuum.xmlrpc.backup.Backup/
mainClass
/manifest
/archive
/configuration
...
!-- automatically creates the classpath using all
project dependencies,
also adding the project build directory --
classpath /
-
argumentorg.apache.maven.continuum.xmlrpc.client.SampleClient/
argument
+
argumentorg.apache.continuum.xmlrpc.client.SampleClient/argument
/arguments
/configuration
/plugin
...
configuration
roleDefaults
roleDefault
-
role
org.apache.maven.continuum.xmlrpc.server.ContinuumXmlRpcComponent/
role
+
roleorg.apache.continuum.xmlrpc.server.ContinuumXmlRpcComponent/
role
instantiation-strategyper-lookup/instantiation-
strategy
/roleDefault
/roleDefaults
These all look to be in error because they refer to packages (not yet
migrated).
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: svn commit: r633704 - in /continuum/branches/continuum-1.x: ./ continuum-api/ continuum-commons/ continuum-configuration/ continuum-core-it/ continuum-core/ continuum-data-management/ continuum-da
2008/3/5, Brett Porter [EMAIL PROTECTED]:
On 05/03/2008, at 10:28 AM, [EMAIL PROTECTED] wrote:
use new continuum parent
change groupId to org.apache.continuum (continuun is now TLP :-) )
Will this be merged to trunk too?
Yep
archive
manifest
-
mainClassorg.apache.maven.continuum.management.DataManagementCli/
mainClass
+
mainClassorg.apache.continuum.management.DataManagementCli/
mainClass
/manifest
/archive
/configuration
...
dependencies
dependency
- groupIdorg.apache.maven.continuum/groupId
+ groupIdorg.apache.continuum/groupId
artifactIdcontinuum-xmlrpc-client/artifactId
version${project.version}/version
/dependency
@@ -60,7 +60,7 @@
arguments
argument-classpath/argument
classpath /
-
argumentorg.apache.maven.continuum.xmlrpc.backup.Backup/argument
+argumentorg.apache.continuum.xmlrpc.backup.Backup/
argument
argument-h/argument
/arguments
/configuration
@@ -73,7 +73,7 @@
descriptorsrc/assembly/app.xml/descriptor
archive
manifest
-
mainClassorg.apache.maven.continuum.xmlrpc.backup.Backup/mainClass
+ mainClassorg.apache.continuum.xmlrpc.backup.Backup/
mainClass
/manifest
/archive
/configuration
...
!-- automatically creates the classpath using all
project dependencies,
also adding the project build directory --
classpath /
-
argumentorg.apache.maven.continuum.xmlrpc.client.SampleClient/
argument
+
argumentorg.apache.continuum.xmlrpc.client.SampleClient/argument
/arguments
/configuration
/plugin
...
configuration
roleDefaults
roleDefault
-
role
org.apache.maven.continuum.xmlrpc.server.ContinuumXmlRpcComponent/
role
+
roleorg.apache.continuum.xmlrpc.server.ContinuumXmlRpcComponent/
role
instantiation-strategyper-lookup/instantiation-
strategy
/roleDefault
/roleDefaults
These all look to be in error because they refer to packages (not yet
migrated).
Yep good catch error
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: release button in project group page.
I think this is because the release plugin is being called at the parent pom once to also release all its modules whereas builds are being called at each project in the project group. On Sun, Mar 2, 2008 at 3:23 AM, Benoit Decherf [EMAIL PROTECTED] wrote: Hi, The release button of the project group page only works if all projects in the group have the same parent and the parent is in the group. Why doesn't it make a release of all projects in the group ? I think that it should work as the build all projects button. Benoit.
Re: release button in project group page.
Yes, but I think that it should release all projects in the group. It's really strange that this button doesn't work as the build all projects button. And it would be a very great feature if it do it. Benoit. Edwin Punzalan wrote: I think this is because the release plugin is being called at the parent pom once to also release all its modules whereas builds are being called at each project in the project group. On Sun, Mar 2, 2008 at 3:23 AM, Benoit Decherf [EMAIL PROTECTED] wrote: Hi, The release button of the project group page only works if all projects in the group have the same parent and the parent is in the group. Why doesn't it make a release of all projects in the group ? I think that it should work as the build all projects button. Benoit.
Re: Confused about the branches
On 29/02/2008, at 10:04 AM, Emmanuel Venisse wrote: On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? I thought to do 1.x in the branch instead of only maintenance in 1.1.xbecause I don't know how many time we'll need for the first 2.0 release. User will probably need some new small feature before the 2.0release and not only maintenance. With the roadmap discussion recently, I thought it was going to be an incremental move towards 2.0 on trunk - 1.2 will have some parts and refactorings, 1.3, 1.4 and so on. I'm not sure why there would need to be two streams of development? I think there's a real danger of getting lost in the 2.0 trap (c.f. Maven 1.0, Maven 2.0 and Maven 2.1 :) I'm actually keen to do a couple of small things myself and get a release out: - a few small bug fixes, like the lost change sets for some builds - better error handling - switch to a Jetty runtime without the plexus appserver so we can use jetty 6 - add a call to svn info --xml to check whether to do an svn update to speed up working copy updates Just stuff I see from running vmbuild and the maven zone. I think that and a couple of other refactorings that are being discussed on here would make a good 1.2 in the next couple of months. WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
Agree on this. Currently there is a blocking issue with xml-rpc CONTINUUM-1590 which prevent using xml-rpc :-(. If no objections, I will change root pom to not have anymore maven pom as parent. -- Olivier 2008/3/4, Brett Porter [EMAIL PROTECTED]: On 29/02/2008, at 10:04 AM, Emmanuel Venisse wrote: On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? I thought to do 1.x in the branch instead of only maintenance in 1.1.xbecause I don't know how many time we'll need for the first 2.0 release. User will probably need some new small feature before the 2.0release and not only maintenance. With the roadmap discussion recently, I thought it was going to be an incremental move towards 2.0 on trunk - 1.2 will have some parts and refactorings, 1.3, 1.4 and so on. I'm not sure why there would need to be two streams of development? I think there's a real danger of getting lost in the 2.0 trap (c.f. Maven 1.0, Maven 2.0 and Maven 2.1 :) I'm actually keen to do a couple of small things myself and get a release out: - a few small bug fixes, like the lost change sets for some builds - better error handling - switch to a Jetty runtime without the plexus appserver so we can use jetty 6 - add a call to svn info --xml to check whether to do an svn update to speed up working copy updates Just stuff I see from running vmbuild and the maven zone. I think that and a couple of other refactorings that are being discussed on here would make a good 1.2 in the next couple of months. WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
On 04/03/2008, at 10:47 AM, Olivier Lamy wrote: Agree on this. Currently there is a blocking issue with xml-rpc CONTINUUM-1590 which prevent using xml-rpc :-(. Cool - shall we just start using the 1.2 bucket in JIRA? There are only 14 issues there now so maybe we could keep that to 20-30 issues all together and release it. I found these changes on trunk that are not on the branch: r617400. (The rest is documentation) I found these changes on the branch that are not on trunk: r627196, r620613, r620612, r620611 I think we should just merge all those from the branch to trunk, set it as v1.2, and close the branch for now? If no objections, I will change root pom to not have anymore maven pom as parent. Sounds good - do you think we should have a Continuum parent POM like we do for Archiva? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
Brett Porter wrote: On 29/02/2008, at 10:04 AM, Emmanuel Venisse wrote: On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? I thought to do 1.x in the branch instead of only maintenance in 1.1.xbecause I don't know how many time we'll need for the first 2.0 release. User will probably need some new small feature before the 2.0release and not only maintenance. With the roadmap discussion recently, I thought it was going to be an incremental move towards 2.0 on trunk - 1.2 will have some parts and refactorings, 1.3, 1.4 and so on. I'm not sure why there would need to be two streams of development? I think there's a real danger of getting lost in the 2.0 trap (c.f. Maven 1.0, Maven 2.0 and Maven 2.1 :) We haven't pegged any version numbers to the tasks extracted from the roadmap discussion. I think we should consider what architecture rework we intend to do (and impact), and if it merits keeping 2 streams (or not). I'm actually keen to do a couple of small things myself and get a release out: - a few small bug fixes, like the lost change sets for some builds - better error handling - switch to a Jetty runtime without the plexus appserver so we can use jetty 6 - add a call to svn info --xml to check whether to do an svn update to speed up working copy updates I agree on getting something out frequently. Having said that if there is a consensus on 2 streams then I think we need to keep the momentum up on both to get releases/milestones out there. Just stuff I see from running vmbuild and the maven zone. I think that and a couple of other refactorings that are being discussed on here would make a good 1.2 in the next couple of months. WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ Cheers, Rahul
Re: Splitting the website and documentation
On Fri, Dec 28, 2007 at 7:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/12/2007, at 1:35 PM, Wendy Smoak wrote: I was just going to leave it under continuum/trunk as continuum-docs and continuum-site. Cool, thanks for that. Should be pretty straightforward to move the site up at a later date if needed. ... and the later date is now. :) I'm going to move trunk/continuum-site up a level to repos/asf/continuum/site. I don't think it needs trunk|branches|tags of its own, especially if we're going to keep continuum's own trunk|branches|tags at the top level like they are now. (If we really want to tag the site it can go in repos/asf/continuum/tags.) -- Wendy
Re: CI disabled for Continuum due to svn move
I was due to move it to vmbuild anyway so I'll just do that now. Sorry about that, should have remembered. - Brett On 02/03/2008, at 3:12 AM, Wendy Smoak wrote: On the Maven zone, I changed the schedule for the Continuum Parent group to 'On Demand' so that it won't run. AFAIK there's no way to tell it where the source code moved, so we'll have to delete and re-add the projects. (Talking about using Continuuum to build Continuum is confusing...) -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
Hi, What about the sandbox content ? [1] Not sure it's well maintained code ;-). -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/continuum/ 2008/2/28, Brett Porter [EMAIL PROTECTED]: This has been done (and switch works just fine). No other changes should be needed on your end. - Brett On 26/02/2008, at 12:02 PM, Wendy Smoak wrote: On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
done :) On 01/03/2008, at 9:27 AM, Olivier Lamy wrote: Hi, What about the sandbox content ? [1] Not sure it's well maintained code ;-). -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/continuum/ 2008/2/28, Brett Porter [EMAIL PROTECTED]: This has been done (and switch works just fine). No other changes should be needed on your end. - Brett On 26/02/2008, at 12:02 PM, Wendy Smoak wrote: On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Continuum fisheye hosting
Go for it - I had no idea it was in place already :) On 01/03/2008, at 12:11 PM, Olivier Lamy wrote: Hi, As continuum has moved in the apache svn. The project is no longer available here http://fisheye6.cenqua.com. I have created an issue [1] to ask the hosting. Is there any objections before notifying/asking infra ? Thanks, -- Olivier [1] https://support.atlassian.com/browse/FSH-580 -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: ContinuumStore refactoring
I'll create some examples asap. Emmanuel On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, Some code using a couple of Entities as examples would be nice :-) I still think the API would be verbose. Thanks, Rahul On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] wrote: 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. I don't want to see a new time a big class for the store part. it must be splitted in few domains. All named queries related to Project would be defined in the Project class, all named queries related to ProjectGroup would be defined in the ProjectGroup class... And we can add some more classes for particular results that aren't entities objects (we won't have a lot) With this, all concerns are separated and linked to a specific entity. Easy to code, easy to read, easy to understand. It's my opinion. Sorry, still not convinced ;-) I hope you are now ;-) Emmanuel Rahul
Re: CI Server Poll
thx Rahul for this link. We are #2 now :) On Thu, Feb 28, 2008 at 4:51 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, Any one seen this: http://www.wakaleo.com/polls/18-what-continuous-integration-server-are-you-using-in-2008 Another 5 steps to get to #1 :-) Rahul
Re: svn commit: r632127 - /maven/continuum/branches/continuum-1.x/pom.xml
The users one seems to be missing the users. prefix in both - is there
a reason for that?
- Brett
On 29/02/2008, at 8:58 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Thu Feb 28 13:58:44 2008
New Revision: 632127
URL: http://svn.apache.org/viewvc?rev=632127view=rev
Log:
Update markmail addresses
Modified:
maven/continuum/branches/continuum-1.x/pom.xml
Modified: maven/continuum/branches/continuum-1.x/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/branches/continuum-1.x/pom.xml?rev=632127r1=632126r2=632127view=diff
=
=
=
=
=
=
=
=
==
--- maven/continuum/branches/continuum-1.x/pom.xml (original)
+++ maven/continuum/branches/continuum-1.x/pom.xml Thu Feb 28
13:58:44 2008
@@ -41,22 +41,48 @@
inceptionYear2003/inceptionYear
mailingLists
mailingList
- nameContinuum Dev List/name
- subscribe[EMAIL PROTECTED]/subscribe
- unsubscribe[EMAIL PROTECTED]/
unsubscribe
- archivehttp://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
-/mailingList
-mailingList
nameContinuum User List/name
+ post[EMAIL PROTECTED]/post
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archivehttp://mail-archives.apache.org/mod_mbox/maven-continuum-users/
/archive
+ otherArchives
+otherArchivehttp://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchivehttp://www.nabble.com/Continuum---Users-f13868.html
/otherArchive
+otherArchivehttp://continuum.markmail.org//otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Developer List/name
+ postcontinuum-dev@maven.apache.org/post
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archivehttp://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
+ otherArchives
+otherArchivehttp://www.mail-archive.com/continuum-dev@maven.apache.org
/otherArchive
+otherArchivehttp://www.nabble.com/Continuum---Dev-f13867.html
/otherArchive
+otherArchivehttp://dev.continuum.markmail.org//
otherArchive
+ /otherArchives
/mailingList
mailingList
- nameContinuum Commit List/name
+ nameContinuum Commits List/name
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archivehttp://mail-archives.apache.org/mod_mbox/maven-continuum-commits/
/archive
+ otherArchives
+otherArchivehttp://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchivehttp://maven.continuum.commits.markmail.org//
otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Issues List/name
+ subscribe[EMAIL PROTECTED]/
subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archivehttp://mail-archives.apache.org/mod_mbox/maven-continuum-issues/
/archive
+ otherArchives
+otherArchivehttp://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchivehttp://www.nabble.com/Continuum---Issues-f29618.html
/otherArchive
+ /otherArchives
/mailingList
/mailingLists
scm
@@ -781,6 +807,11 @@
groupIdorg.codehaus.plexus.redback/groupId
artifactIdredback-data-management/artifactId
version${redback.version}/version
+ /dependency
+ dependency
+groupIdcommons-httpclient/groupId
+artifactIdcommons-httpclient/artifactId
+version3.1/version
/dependency
/dependencies
/dependencyManagement
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
This has been done (and switch works just fine). No other changes should be needed on your end. - Brett On 26/02/2008, at 12:02 PM, Wendy Smoak wrote: On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r632127 - /maven/continuum/branches/continuum-1.x/pom.xml
yes, it is an error.
Emmanuel
On Thu, Feb 28, 2008 at 11:13 PM, Brett Porter [EMAIL PROTECTED] wrote:
The users one seems to be missing the users. prefix in both - is there
a reason for that?
- Brett
On 29/02/2008, at 8:58 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Thu Feb 28 13:58:44 2008
New Revision: 632127
URL: http://svn.apache.org/viewvc?rev=632127view=rev
Log:
Update markmail addresses
Modified:
maven/continuum/branches/continuum-1.x/pom.xml
Modified: maven/continuum/branches/continuum-1.x/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/branches/continuum-1.x/pom.xml?rev=632127r1=632126r2=632127view=diff
=
=
=
=
=
=
=
=
==
--- maven/continuum/branches/continuum-1.x/pom.xml (original)
+++ maven/continuum/branches/continuum-1.x/pom.xml Thu Feb 28
13:58:44 2008
@@ -41,22 +41,48 @@
inceptionYear2003/inceptionYear
mailingLists
mailingList
- nameContinuum Dev List/name
- subscribe[EMAIL PROTECTED]/subscribe
- unsubscribe[EMAIL PROTECTED]/
unsubscribe
- archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
-/mailingList
-mailingList
nameContinuum User List/name
+ post[EMAIL PROTECTED]/post
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-users/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchive
http://www.nabble.com/Continuum---Users-f13868.html
/otherArchive
+otherArchivehttp://continuum.markmail.org//otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Developer List/name
+ postcontinuum-dev@maven.apache.org/post
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/continuum-dev@maven.apache.org
/otherArchive
+otherArchivehttp://www.nabble.com/Continuum---Dev-f13867.html
/otherArchive
+otherArchivehttp://dev.continuum.markmail.org//
otherArchive
+ /otherArchives
/mailingList
mailingList
- nameContinuum Commit List/name
+ nameContinuum Commits List/name
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-commits/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchivehttp://maven.continuum.commits.markmail.org//
otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Issues List/name
+ subscribe[EMAIL PROTECTED]/
subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-issues/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchive
http://www.nabble.com/Continuum---Issues-f29618.html
/otherArchive
+ /otherArchives
/mailingList
/mailingLists
scm
@@ -781,6 +807,11 @@
groupIdorg.codehaus.plexus.redback/groupId
artifactIdredback-data-management/artifactId
version${redback.version}/version
+ /dependency
+ dependency
+groupIdcommons-httpclient/groupId
+artifactIdcommons-httpclient/artifactId
+version3.1/version
/dependency
/dependencies
/dependencyManagement
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
Thanks Brett. Emmanuel On Thu, Feb 28, 2008 at 11:27 PM, Brett Porter [EMAIL PROTECTED] wrote: This has been done (and switch works just fine). No other changes should be needed on your end. - Brett On 26/02/2008, at 12:02 PM, Wendy Smoak wrote: On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
why 1.1.x? On Thu, Feb 28, 2008 at 11:45 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? - Brett On Thu, Feb 28, 2008 at 11:45 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? I thought to do 1.x in the branch instead of only maintenance in 1.1.xbecause I don't know how many time we'll need for the first 2.0 release. User will probably need some new small feature before the 2.0release and not only maintenance. - Brett On Thu, Feb 28, 2008 at 11:45 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: ContinuumStore refactoring
Hi, Some code using a couple of Entities as examples would be nice :-) I still think the API would be verbose. Thanks, Rahul On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] wrote: 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. I don't want to see a new time a big class for the store part. it must be splitted in few domains. All named queries related to Project would be defined in the Project class, all named queries related to ProjectGroup would be defined in the ProjectGroup class... And we can add some more classes for particular results that aren't entities objects (we won't have a lot) With this, all concerns are separated and linked to a specific entity. Easy to code, easy to read, easy to understand. It's my opinion. Sorry, still not convinced ;-) I hope you are now ;-) Emmanuel Rahul
svn move (was: Re: Apache Continuum is now an Apache top level project)
I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. Brett, when will can you do the move? Emmanuel On Thu, Feb 21, 2008 at 12:10 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi Emmanuel, These are the incubator graduation steps and they mostly seem to apply here too: http://incubator.apache.org/guides/graduation.html#life-after-graduation . Many of them are for you to do directly. I've filed the infrastructure issue (INFRA-1532) and placed you in the chairs group already. Cheers, Brett On 21/02/2008, at 8:30 AM, Emmanuel Venisse wrote: Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
On 26/02/2008, at 10:39 AM, Emmanuel Venisse wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. Brett, when will can you do the move? I'll lock it in for Friday morning here (about 3 days from now): http://timeanddate.com/worldclock/fixedtime.html?month=2day=29year=2008hour=8min=0sec=0p1=240 Emmanuel On Thu, Feb 21, 2008 at 12:10 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi Emmanuel, These are the incubator graduation steps and they mostly seem to apply here too: http://incubator.apache.org/guides/graduation.html#life-after-graduation . Many of them are for you to do directly. I've filed the infrastructure issue (INFRA-1532) and placed you in the chairs group already. Cheers, Brett On 21/02/2008, at 8:30 AM, Emmanuel Venisse wrote: Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
On Tue, Feb 26, 2008 at 12:47 AM, Brett Porter [EMAIL PROTECTED] wrote: On 26/02/2008, at 10:39 AM, Emmanuel Venisse wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. Brett, when will can you do the move? I'll lock it in for Friday morning here (about 3 days from now): http://timeanddate.com/worldclock/fixedtime.html?month=2day=29year=2008hour=8min=0sec=0p1=240 Thanks. Emmanuel
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy
Re: ContinuumStore refactoring
As I already explained, I'm in favor of named queries On Fri, Feb 22, 2008 at 2:54 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, I'd like to go ahead and pick up something towards the next Continuum iteration. I am thinking refactoring ContinuumStore interface as was earlier discussed on this list and as I did on the 'continuum-jpa' branch. To this end, I need to get a clear picture on a few items: 1) Which JPA provider are we going ahead with then? I'd like to start with toplink provider. 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. 3) Using Criteria Queries would mean that we use JPA extensions specific to provider. I don't see this as an issue as long as we are not expecting underlying JPA providers to be swapped. Thoughts? Continuum isn't a big application and I don't think we need provider extensions for now. Before to start the code, I'd like to see a DB model exported to an image so we'll can include it in the site. We must define too which datas will stay in the db and which datas will be externalized in some files. Look forward to hear. Cheers, Rahul
Re: ContinuumStore refactoring
2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. Sorry, still not convinced ;-) Rahul
Re: ContinuumStore refactoring
On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] wrote: 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. I don't want to see a new time a big class for the store part. it must be splitted in few domains. All named queries related to Project would be defined in the Project class, all named queries related to ProjectGroup would be defined in the ProjectGroup class... And we can add some more classes for particular results that aren't entities objects (we won't have a lot) With this, all concerns are separated and linked to a specific entity. Easy to code, easy to read, easy to understand. It's my opinion. Sorry, still not convinced ;-) I hope you are now ;-) Emmanuel Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Thanks Rahul. Emmanuel On Feb 20, 2008 4:44 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, I have re-organised and updated content related to Continuum 2.0 Roadmap here: http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap Would appreciate if others can review/update/comment as appropriate. Also, I think we start cutting out concrete JIRA tasks from those umbrella issues listed on that page above and assign them fix versions. Thanks, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: Apache Continuum is now an Apache top level project
Great news! Congrats everyone :-) Rahul Brett Porter wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
\o/ nice! On Wed, Feb 20, 2008 at 3:30 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- jesse mcconnell [EMAIL PROTECTED]
Re: Apache Continuum is now an Apache top level project
Wonderful ! -- Olivier 2008/2/20, Brett Porter [EMAIL PROTECTED]: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
Another feature (rather features) that i would like to see is around Change tracking/audit. I would like to add to the feature list - integration with some of popular Change management/ Bug tracking systems, such that user can see issues fixed in a build. On a related note, I think we are already capturing changes in the SCM but we should present them in the separate view for more visibility. WDYT? Cheers, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
On 21/02/2008, at 9:57 AM, Rahul Thakur wrote: Another feature (rather features) that i would like to see is around Change tracking/audit. I would like to add to the feature list - integration with some of popular Change management/ Bug tracking systems, such that user can see issues fixed in a build. I think just keep adding them and make this a collection page rather than a 2.0 page. Then they can gather volunteers, more info. Then split out the really focused ones that you're planning to work on right now. On a related note, I think we are already capturing changes in the SCM but we should present them in the separate view for more visibility. +1 WDYT? Cheers, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
Fantastic news! Congrats everyone! - Joakim Brett Porter wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
Yay! Congrats everyone! :-) -Deng On Thu, Feb 21, 2008 at 4:15 AM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
Yay! Congrats! Cheers! Nap On Thu, Feb 21, 2008 at 9:07 AM, Maria Odea Ching [EMAIL PROTECTED] wrote: Yay! Congrats everyone! :-) -Deng On Thu, Feb 21, 2008 at 4:15 AM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
wow. cool ! ^_^ congrats everyone ! ^_^ On Thu, Feb 21, 2008 at 10:16 AM, Napoleon Esmundo C. Ramirez [EMAIL PROTECTED] wrote: Yay! Congrats! Cheers! Nap On Thu, Feb 21, 2008 at 9:07 AM, Maria Odea Ching [EMAIL PROTECTED] wrote: Yay! Congrats everyone! :-) -Deng On Thu, Feb 21, 2008 at 4:15 AM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Apache Continuum is now an Apache top level project
nice! On Wed, Feb 20, 2008 at 12:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Apache Continuum is now an Apache top level project
\o/ On Wed, Feb 20, 2008 at 12:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
Hi, I have re-organised and updated content related to Continuum 2.0 Roadmap here: http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap Would appreciate if others can review/update/comment as appropriate. Also, I think we start cutting out concrete JIRA tasks from those umbrella issues listed on that page above and assign them fix versions. Thanks, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
Sorry, just caught up with my mails today.. Anyway, +1 on the things in the wiki. All the ideas are exciting :) As what have been mentioned already in the thread, I agree that it would be easier and more manageable to implement these plans in milestones not just in one blow. And if Continuum will be switching databases, I'd go with JPA. Comparing my experience in using JPA and JPOX, I'd say that it has been more pleasant with JPA. I also think switching from Plexus to a different framework would attract more contributors as a lot of people outside the Maven community aren't really very familiar on how to use Plexus. Thanks, Deng On Jan 30, 2008 6:34 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
Maria Odea Ching wrote: Anyway, +1 on the things in the wiki. All the ideas are exciting :) As what have been mentioned already in the thread, I agree that it would be easier and more manageable to implement these plans in milestones not just in one blow. Smaller iterations and more frequent releases is a very good idea. If the transition from 1.0.3 to 1.1 had been done in smaller iterations I think Continuum would have been a lot more popular today than it is now. (Frequent releases seem to be one of the things that attract people to Hudson...) And if Continuum will be switching databases, I'd go with JPA. Comparing my experience in using JPA and JPOX, I'd say that it has been more pleasant with JPA. I also think switching from Plexus to a different framework would attract more contributors as a lot of people outside the Maven community aren't really very familiar on how to use Plexus. If I could choose between Jpox and JPA and Plexus and Spring, I'd chosen JPA and Spring in a heartbeat. However, if you haven't got any really _need_ for functionality only provided by JPA or Spring/whatever, the value added to Continuum compared to the cost of implementation is not worth it IMHO. I also want to address the wish to attract more contributors. As some of you might know, I have developed an extension to Continuum that I now call Backward Compatibility Tester [1]. I thus feel that I can give feedback with regards to how it is to start developing on Continuum. IMHO the most serious showstoppers are 1. I'm unable to run tests that extend AbstractContinuumTest in my IDE (IntelliJ) 2. I'm unable to run tests that extend AbstractContinuumTest in my IDE (IntelliJ) 3. I'm unable to run tests that extend AbstractContinuumTest in my IDE (IntelliJ) 4. Lack of documentation. E.g., I haven't found a single design diagram/description that explains how the 30~ modules interact... 5. There are 30 or so modules in the same maven project. 5.1 The build is horribly slow (6min 28secs on a Intel Core2 6300 CPU @ 1.86GHz with 2GB ram). 5.2 It is hard to grasp the underlaying architecture. 5.3. Are really all these modules needed to check out some code from a repository and run mvn clean install? Yes, I try to suggest that some of the functionality should be moved to separate projects. Perhaps a plugin-based architecture is the solution, but I think much can be achieved by refactoring to a smaller set of libraries that different products can use. (This might be a first step towards Continuum with distributed builds.) Perhaps continuum-model, continuum-xmlrpc or maven-continuum-plugin can be split out to separate maven projects? 6. JPOX is buggy, hard to debug and difficult to work with. [1] https://bct.dev.java.net/ (only a prototype, not production ready) -- Regards Erik Drolshammer Sherriff @ #continuum and #maven
Re: [Discussion] Continuum 2.0 Roadmap
Hello Everyone, I have re-organized the document on the cwiki.apache.org http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Continuum+2.0+Roadmap* *and, moved the items into their own child pages. I think we should have a template to lend some structure to requirements captured and expand them. Any suggestions? Cheers, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
I have created an page for Continuum 2.0 related stuff (treat this as a dashboard with links to related C2 docs). http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0 The other content will keep moving in the background. Cheers, Rahul Emmanuel Venisse wrote: Thanks Brett. I'm +1 to open it. Emmanuel On Feb 13, 2008 8:43 AM, Brett Porter [EMAIL PROTECTED] wrote: no, permissions changes are non-destructive :) On 13/02/2008, at 6:33 PM, Rahul Thakur wrote: +1 as long as editing it requires a login :-) Should I hold off the migration from Codehaus? Rahul On Feb 13, 2008 6:32 PM, Brett Porter [EMAIL PROTECTED] wrote: On 13/02/2008, at 4:04 PM, Wendy Smoak wrote: On Feb 12, 2008 10:01 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, I've created two wiki's: ... http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index (exported to: http://cwiki.apache.org/CONTINUUMDEV/) This one is editable by developers only (accepts comments from anyone). This is for the roadmap and design docs. I only granted access to a few people that I could easily find - if you need to edit, just let me or a confluence admin know. Why would we not want to allow the community to participate in roadmap and design docs? The only reason I can think of to restrict access is to make sure we have a CLA for content we intend to redistribute. Both good points - I was following what we had in Maven already - what do others think - shall we just open it up? Or do we not even need the DEV space? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Thanks Brett. I'm +1 to open it. Emmanuel On Feb 13, 2008 8:43 AM, Brett Porter [EMAIL PROTECTED] wrote: no, permissions changes are non-destructive :) On 13/02/2008, at 6:33 PM, Rahul Thakur wrote: +1 as long as editing it requires a login :-) Should I hold off the migration from Codehaus? Rahul On Feb 13, 2008 6:32 PM, Brett Porter [EMAIL PROTECTED] wrote: On 13/02/2008, at 4:04 PM, Wendy Smoak wrote: On Feb 12, 2008 10:01 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, I've created two wiki's: ... http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index (exported to: http://cwiki.apache.org/CONTINUUMDEV/) This one is editable by developers only (accepts comments from anyone). This is for the roadmap and design docs. I only granted access to a few people that I could easily find - if you need to edit, just let me or a confluence admin know. Why would we not want to allow the community to participate in roadmap and design docs? The only reason I can think of to restrict access is to make sure we have a CLA for content we intend to redistribute. Both good points - I was following what we had in Maven already - what do others think - shall we just open it up? Or do we not even need the DEV space? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
On 13/02/2008, at 4:04 PM, Wendy Smoak wrote: On Feb 12, 2008 10:01 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, I've created two wiki's: ... http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index (exported to: http://cwiki.apache.org/CONTINUUMDEV/) This one is editable by developers only (accepts comments from anyone). This is for the roadmap and design docs. I only granted access to a few people that I could easily find - if you need to edit, just let me or a confluence admin know. Why would we not want to allow the community to participate in roadmap and design docs? The only reason I can think of to restrict access is to make sure we have a CLA for content we intend to redistribute. Both good points - I was following what we had in Maven already - what do others think - shall we just open it up? Or do we not even need the DEV space? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. Is this close to what you are thinking? http://www.eclipse.org/alf/index.php Rahul
Re: [Discussion] Continuum 2.0 Roadmap
snipped 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. My motivations behind this were: # leverage Java 5 language and other library features, and enable Continuum to do the same. # Encourage more contributions by using tools/libraries that have a good user base. snipped 3) Builders Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. This is way to detailed to be on a roadmap. Yep, way too detailed for the roadmap but that was just a random thought, please ignore it at this stage ;-) snipped 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm not sure what you're trying to say here. The current way to installing Continuum (unpack, run bin/plexus.sh) is still giving me wow when doing demos. I was just hinting if Continuum dist could be leaner, but again may be too early at this point in time What I would like to see is talk about the different ways of doing remoting and tool integration (IDEs in particular, but also desktop widgets). +1 Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. +1 If someone is going down the plugin path, it is essential to me that these plugins can be written in vi inside an existing installation and copied around. This implies to me that we have to support a plugin language like jython, jruby or groovy. I agree with the possibility supporting multiple plugin languages in the long run but just having support for Java based plugins for starters. I am not yet sure what all is involved in supporting plugins in other languages. Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Here's my list: 1) Peformance improvements. 2) A slicker User Interface. Ability to let the user work in an offline mode (Google Gears!) and sync periodically. 3) Good user and developer documentation. 4) Better public APIs (rework Store and Continuum) Rahul Napoleon Esmundo C. Ramirez wrote: Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. Again, just my thoughts. Cheers! Nap On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED] wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
1. +1 on distributed builds, along with examples on the 2 main use cases I see for distributed builds: a. building on many platforms for native builds that need multiple distributions. b. distribute the build across many machines to decrease the latency of building everything. 2. +1 on the docs comment below. 3. As to slicker UI, I'm not sure it's as necessary, and there's nothing stopping 1.x from getting a better UI. The bigger issues for me are: a) better co-ordination of reports/dashboards b) integrations with various other systems and dashboards and monitors (mylyn, jira, etc.) 4. Full configuration of the bootstrapping/staging of the build environment. I'm still experimenting with the current mechanisms, but I think it still needs work. 5. Apart from distributed builds, I think we need parallel building of mutually independent projects. I care less about the underlying technologies because most people won't be adding osgi or plexus or picocontainer components willy- nilly. I would replace plexus if it is deficient, but unless there's a compelling reason to switch, I wouldn't work at it too hard. For example, if it was based on Tapestry (not a plug, just an example), then moving to tapestry-ioc would make sense because t5 comes with it, it's based on that model, and it cleanly integrates with spring for extension. In that case, however, it's a change for convenience. I'd be even happier if such a switch of any given subsystem was because of a solid decision of either defect in the current approach, or improvement in the new one. Spring makes me a bit woodgy because while it's an IoC container, it's not really (in my experience) a great plug-in system. An infrastructure around a plugin lifecycle would need to be built on or (3rd party) added to spring to make it really useable that way. Christian. On 7-Feb-08, at 21:56 , Rahul Thakur wrote: Here's my list: 1) Peformance improvements. 2) A slicker User Interface. Ability to let the user work in an offline mode (Google Gears!) and sync periodically. 3) Good user and developer documentation. 4) Better public APIs (rework Store and Continuum) Rahul Napoleon Esmundo C. Ramirez wrote: Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. Again, just my thoughts. Cheers! Nap On Feb 6, 2008 8:12 AM, Carlos Sanchez[EMAIL PROTECTED] wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse[EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [vote] Request Graduation to a TLP
+1 -john On Feb 5, 2008, at 6:06 PM, Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged. --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: [vote] Request Graduation to a TLP
+1 Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: Some continuum-jpa branch updates
Its seems TopLink can do Criteria Queries (using Expressions and ExpressionBuilders, correct me if I am wrong). It seems quite a few JPA implementations provide some sort of Criteria Query API extension. Hibernate does that too ! Damien
Re: [vote] Request Graduation to a TLP
Definitely, +1 Congratulations! On Feb 5, 2008 3:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [Discussion] Continuum 2.0 Roadmap
Some good points emerging from this discussion! :-) Would it be a nice idea to put following on wiki: 1) State goals/philosophy for C2 in light of lessons learnt from 1.x development - lean, mean, extensible (~add any other here~) 2) Document *all* features/requirements we want to see in C2 on wiki (even if they are already present in 1.x!). 3) Draw a proposed architecture. 4) Assign items in (1) a priority/weight. Add use-cases to each item in (1) to determine this. 5) Group the priortised requirements/features into milestones. 6) Start cutting code. Thoughts? PS: Codehaus wiki seems to be very slow. Any chance we can have a space created on Apache wiki? Or, I guess it will have to wait for TLP vote. Cheers, Rahul Brett Porter wrote: This looks very exciting, and agree with most of the thread that follows. I'm just going to reply in summary - most of my thoughts are actually non-technical :) Regarding databases: I don't think xml files are the solution (except for the configuration where it makes a lot more sense :) - the data needs to be queryable. I think Andy made a good point in his comment on the roadmap - we need to look at the actual problems. Here's what I think needs to be improved: - better centralisation of access. The architecture of Continuum bleeds JDO decisions all through the code since you access lazy stuff for the first time in obscure places. - I think this might be that the model is too complicated (sorry, my fault) - it assumes complex relationships are handled easily. It seems to be going ok these days, but I feel it would be hard to modify. I haven't looked at Rahul's branch yet, but I think we should consider a more decoupled database (ie, lookup build results for a project but keep them separate in the model to avoid the need to lazyload 90% of the time), and more centralised database logic. I would consider JPA just because it gives more options in terms of an implementation. It is quite easy to use from a development standpoint. But we also need to consider what functionality is needed up front - I think high on the list needs to be migrations between versions. Also, We are probably going to need to store more data in the future, and be able to query it (particularly historical datapoints). On the container: I would prefer to move off Plexus simply because it's a moving target and it's a barrier to entry for new developers. Now, my more general observations. Firstly, the roadmap doesn't appear to have any features - these are all technology changes. Some of that might be cool and a feature in itself, but I think there needs to be a balance between evolution, features, and bugfixing. I would also emphasise that features should be creative new things Continuum can do (for which we've had plenty of ideas), not just catching up to other CI servers :) I think the first part of the roadmap is key - separating the layers out, and basically building Continuum to be lightweight and distributed from the ground up. I hope that's the focus of the development. Note this also impacts the database as it should store much less information on builder machines (it can ship history back to the main server). I also think that supporting plugins is a good idea - it has been a huge bonus in other apps and in Maven itself. I'd like to investigate using OSGi for this. But by far the biggest question I have is what happened to 1.2? I think Continuum needs to set a target to achieve, but get there in gradual steps that at each stage sees a production release. The long 1.1 cycle really set Continuum back - a lot of it was changing features, but there was also a lot of changing technologies :) I don't think Continuum will survive another year-and-a-half release cycle. So the start could be to break all the actions out (plexus, not webwork) into services and add some features, then the next release could adjust the database model and add some other features. And as we split these things out we make sure they are nicely documented and tested. That's my thoughts :) Cheers, Brett On 30/01/2008, at 9:34 AM, Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
Are you thinking what I am thinking - an OSGi based runtime underneath and plugins/extensions that could be loaded runtime? :-) Carlos Sanchez wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
Hi, This looks very exciting (I love the plugin idea). As all of this features can be long to implement, I agree with Brett to separate into different millestones releases. (IMHO a full big bang will be very long). And currently they are some blocking issues in the 1.1 release. -- Olivier 2008/1/29, Emmanuel Venisse [EMAIL PROTECTED]: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
We can create such a wiki any time - the challenge is converting existing content. If someone is happy to lose history and do it by hand, it can be done straight away. On 06/02/2008, at 9:25 PM, Rahul Thakur wrote: Some good points emerging from this discussion! :-) Would it be a nice idea to put following on wiki: 1) State goals/philosophy for C2 in light of lessons learnt from 1.x development - lean, mean, extensible (~add any other here~) 2) Document *all* features/requirements we want to see in C2 on wiki (even if they are already present in 1.x!). 3) Draw a proposed architecture. 4) Assign items in (1) a priority/weight. Add use-cases to each item in (1) to determine this. 5) Group the priortised requirements/features into milestones. 6) Start cutting code. Thoughts? PS: Codehaus wiki seems to be very slow. Any chance we can have a space created on Apache wiki? Or, I guess it will have to wait for TLP vote. Cheers, Rahul Brett Porter wrote: This looks very exciting, and agree with most of the thread that follows. I'm just going to reply in summary - most of my thoughts are actually non-technical :) Regarding databases: I don't think xml files are the solution (except for the configuration where it makes a lot more sense :) - the data needs to be queryable. I think Andy made a good point in his comment on the roadmap - we need to look at the actual problems. Here's what I think needs to be improved: - better centralisation of access. The architecture of Continuum bleeds JDO decisions all through the code since you access lazy stuff for the first time in obscure places. - I think this might be that the model is too complicated (sorry, my fault) - it assumes complex relationships are handled easily. It seems to be going ok these days, but I feel it would be hard to modify. I haven't looked at Rahul's branch yet, but I think we should consider a more decoupled database (ie, lookup build results for a project but keep them separate in the model to avoid the need to lazyload 90% of the time), and more centralised database logic. I would consider JPA just because it gives more options in terms of an implementation. It is quite easy to use from a development standpoint. But we also need to consider what functionality is needed up front - I think high on the list needs to be migrations between versions. Also, We are probably going to need to store more data in the future, and be able to query it (particularly historical datapoints). On the container: I would prefer to move off Plexus simply because it's a moving target and it's a barrier to entry for new developers. Now, my more general observations. Firstly, the roadmap doesn't appear to have any features - these are all technology changes. Some of that might be cool and a feature in itself, but I think there needs to be a balance between evolution, features, and bugfixing. I would also emphasise that features should be creative new things Continuum can do (for which we've had plenty of ideas), not just catching up to other CI servers :) I think the first part of the roadmap is key - separating the layers out, and basically building Continuum to be lightweight and distributed from the ground up. I hope that's the focus of the development. Note this also impacts the database as it should store much less information on builder machines (it can ship history back to the main server). I also think that supporting plugins is a good idea - it has been a huge bonus in other apps and in Maven itself. I'd like to investigate using OSGi for this. But by far the biggest question I have is what happened to 1.2? I think Continuum needs to set a target to achieve, but get there in gradual steps that at each stage sees a production release. The long 1.1 cycle really set Continuum back - a lot of it was changing features, but there was also a lot of changing technologies :) I don't think Continuum will survive another year-and-a-half release cycle. So the start could be to break all the actions out (plexus, not webwork) into services and add some features, then the next release could adjust the database model and add some other features. And as we split these things out we make sure they are nicely documented and tested. That's my thoughts :) Cheers, Brett On 30/01/2008, at 9:34 AM, Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [vote] Request Graduation to a TLP
+1 -Vincent On Feb 6, 2008, at 12:06 AM, Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [vote] Request Graduation to a TLP
+1 ~nakees Emmanuel To Venisse continuum-dev@maven.apache.org [EMAIL PROTECTED] cc .net [EMAIL PROTECTED] Subject Sent by: [vote] Request Graduation to a TLP emmanuel.venisse@ gmail.com 05/02/2008 06:06 PM Please respond to [EMAIL PROTECTED] en.apache.org Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [Discussion] Continuum 2.0 Roadmap
well, if you want to have a plugin based architecture, what better that OSGi? and it may help too for distributiion of build machines On Feb 6, 2008 2:08 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Are you thinking what I am thinking - an OSGi based runtime underneath and plugins/extensions that could be loaded runtime? :-) Carlos Sanchez wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
On Feb 6, 2008 6:52 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: LOL. I'm so out of date. I used to work with TopLink way back in the earliest days, and tracked it up to the Oracle buyout. After that I didn't pay attention, and it's clearly changed direction. Never knew the core was open-sourced. Anyway, it's always been one of the better OR/M platforms, so I'd be cool with it if the license is Apache-compatible. BTW Hibernate is LGPL so as far as I know it's not Apache-compatible. Regards, Tomek
Re: [Discussion] Continuum 2.0 Roadmap
If everyone is happy to keep the history till date on codehaus wiki, I can help copy stuff across to Apache wiki :-) Rahul Brett Porter wrote: We can create such a wiki any time - the challenge is converting existing content. If someone is happy to lose history and do it by hand, it can be done straight away. On 06/02/2008, at 9:25 PM, Rahul Thakur wrote: Some good points emerging from this discussion! :-) Would it be a nice idea to put following on wiki: 1) State goals/philosophy for C2 in light of lessons learnt from 1.x development - lean, mean, extensible (~add any other here~) 2) Document *all* features/requirements we want to see in C2 on wiki (even if they are already present in 1.x!). 3) Draw a proposed architecture. 4) Assign items in (1) a priority/weight. Add use-cases to each item in (1) to determine this. 5) Group the priortised requirements/features into milestones. 6) Start cutting code. Thoughts? PS: Codehaus wiki seems to be very slow. Any chance we can have a space created on Apache wiki? Or, I guess it will have to wait for TLP vote. Cheers, Rahul Brett Porter wrote: This looks very exciting, and agree with most of the thread that follows. I'm just going to reply in summary - most of my thoughts are actually non-technical :) Regarding databases: I don't think xml files are the solution (except for the configuration where it makes a lot more sense :) - the data needs to be queryable. I think Andy made a good point in his comment on the roadmap - we need to look at the actual problems. Here's what I think needs to be improved: - better centralisation of access. The architecture of Continuum bleeds JDO decisions all through the code since you access lazy stuff for the first time in obscure places. - I think this might be that the model is too complicated (sorry, my fault) - it assumes complex relationships are handled easily. It seems to be going ok these days, but I feel it would be hard to modify. I haven't looked at Rahul's branch yet, but I think we should consider a more decoupled database (ie, lookup build results for a project but keep them separate in the model to avoid the need to lazyload 90% of the time), and more centralised database logic. I would consider JPA just because it gives more options in terms of an implementation. It is quite easy to use from a development standpoint. But we also need to consider what functionality is needed up front - I think high on the list needs to be migrations between versions. Also, We are probably going to need to store more data in the future, and be able to query it (particularly historical datapoints). On the container: I would prefer to move off Plexus simply because it's a moving target and it's a barrier to entry for new developers. Now, my more general observations. Firstly, the roadmap doesn't appear to have any features - these are all technology changes. Some of that might be cool and a feature in itself, but I think there needs to be a balance between evolution, features, and bugfixing. I would also emphasise that features should be creative new things Continuum can do (for which we've had plenty of ideas), not just catching up to other CI servers :) I think the first part of the roadmap is key - separating the layers out, and basically building Continuum to be lightweight and distributed from the ground up. I hope that's the focus of the development. Note this also impacts the database as it should store much less information on builder machines (it can ship history back to the main server). I also think that supporting plugins is a good idea - it has been a huge bonus in other apps and in Maven itself. I'd like to investigate using OSGi for this. But by far the biggest question I have is what happened to 1.2? I think Continuum needs to set a target to achieve, but get there in gradual steps that at each stage sees a production release. The long 1.1 cycle really set Continuum back - a lot of it was changing features, but there was also a lot of changing technologies :) I don't think Continuum will survive another year-and-a-half release cycle. So the start could be to break all the actions out (plexus, not webwork) into services and add some features, then the next release could adjust the database model and add some other features. And as we split these things out we make sure they are nicely documented and tested. That's my thoughts :) Cheers, Brett On 30/01/2008, at 9:34 AM, Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [vote] Request Graduation to a TLP
Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 +1 -- Trygve
Re: [vote] Request Graduation to a TLP
+1 Vincent 2008/2/5, Emmanuel Venisse [EMAIL PROTECTED]: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [Discussion] Continuum 2.0 Roadmap
I can only agree on the pointers given in the wiki. However, I'd like to reiterate the low significance of database portability in a CI server. I think speed matters but not really portability. Andy seems to be willing to help solve the database problems Continuum is experiencing. Just my 2 cents, though. ^_^ On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: [Discussion] Continuum 2.0 Roadmap
Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
RE: [vote] Request Graduation to a TLP
+1. I was about to query on this + archiva earlier as I saw various discussions on their dev lists. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Venisse Sent: Tuesday, February 05, 2008 3:07 PM To: continuum-dev@maven.apache.org Cc: [EMAIL PROTECTED] Subject: [vote] Request Graduation to a TLP Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [vote] Request Graduation to a TLP
+1 Rahul Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [vote] Request Graduation to a TLP
+1 -Deng On Feb 6, 2008 7:06 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [vote] Request Graduation to a TLP
This is great news +1 On Feb 6, 2008 10:00 AM, Maria Odea Ching [EMAIL PROTECTED] wrote: +1 -Deng On Feb 6, 2008 7:06 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [Discussion] Continuum 2.0 Roadmap
Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. Again, just my thoughts. Cheers! Nap On Feb 6, 2008 8:12 AM, Carlos Sanchez [EMAIL PROTECTED] wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [vote] Request Graduation to a TLP
+1 On Feb 6, 2008 10:06 AM, Henry Isidro [EMAIL PROTECTED] wrote: This is great news +1 On Feb 6, 2008 10:00 AM, Maria Odea Ching [EMAIL PROTECTED] wrote: +1 -Deng On Feb 6, 2008 7:06 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [Discussion] Continuum 2.0 Roadmap
On 06/02/2008, at 1:20 PM, Napoleon Esmundo C. Ramirez wrote: Just some thoughts, I strongly agree to the proposed technology changes, particularly in the database, as it will definitely improve the storage performance. In line with the objectives to make Continuum a slick CI server, I think the design changes is a good move as well. In my opinion, having plugins will provide a platform for flexibility and a workflow-type of approach in managing the builds. +1 My proposed features would be the following: 1. Aside from the improvement in the UI, I think a visual representation of statistics would be nice. Graphs of the success rates, charts of project health, etc. I think Bamboo has it as telemetry. Yeah, though I think we can be creative here - both by allowing plugins and by looking into different ways to represent it. I really want my sparklines :) 2. Distributed builds, this has been started before but it was never used. I think this would be a strong point in using Continuum if it were available. Hudson has it, iirc. I think implementing it as a plugin would provide more control to it. I think that actually this needs to be a fundamental part of the design - by decentralising the data. The plugin side would be more how the resultant data is handled? - Brett
Re: [vote] Request Graduation to a TLP
+1 On Feb 5, 2008 6:22 PM, Napoleon Esmundo C. Ramirez [EMAIL PROTECTED] wrote: +1 On Feb 6, 2008 10:06 AM, Henry Isidro [EMAIL PROTECTED] wrote: This is great news +1 On Feb 6, 2008 10:00 AM, Maria Odea Ching [EMAIL PROTECTED] wrote: +1 -Deng On Feb 6, 2008 7:06 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged.
Re: [vote] Request Graduation to a TLP
On Feb 5, 2008 4:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. ... +1 -- Wendy
Re: [vote] Request Graduation to a TLP
+1 Arnaud On Feb 6, 2008 12:06 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Cheers, Emmanuel Establish the Apache Continuum Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the domain of continuous integration. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Continuum PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Continuum PMC be and hereby is responsible for the creation and maintenance of software related to the domain of continuous integration based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Continuum be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Continuum PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Continuum PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Continuum PMC: - Maria Odea Ching ([EMAIL PROTECTED]) - Joakim Erdfelt ([EMAIL PROTECTED]) - Olivier Lamy ([EMAIL PROTECTED]) - Trygve Laugstol ([EMAIL PROTECTED]) - Jesse McConnell ([EMAIL PROTECTED]) - Brett Porter ([EMAIL PROTECTED]) - Edwin Punzalan ([EMAIL PROTECTED]) - Carlos Sanchez ([EMAIL PROTECTED]) - Wendy Smoak ([EMAIL PROTECTED]) - Rahul Thakur ([EMAIL PROTECTED]) - Emmanuel Venisse ([EMAIL PROTECTED]) - Kenney Westerhof ([EMAIL PROTECTED]) - Andrew Williams ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be appointed to the office of Vice President, Apache Continuum, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Continuum Project; and be it further RESOLVED, that the initial Apache Continuum PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Continuum subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Continuum sub-project and encumbered upon the Apache Maven PMC are hereafter discharged. -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: [Discussion] Continuum 2.0 Roadmap
Good to see C2 discussions picking up! \o/ Re. TopLink TopLink Essentials is governed by this license: https://glassfish.dev.java.net/public/CDDLv1.0.html I am not sure if that license is compatible with our goals or not. Also, EclipseLink has already been mentioned on this thread earlier. Rahul Christian Edward Gruber wrote: Toplink is mentioned, but it's a commercial app, and I don't think they'll license it in a way that's compatible (unless they've radically changed policies recently). I'm not a huge hibernate fan, but at least its supported. At least with JPA and decent abstraction, you should be able to have more swapability though at the O/R-M level I find it's rare to get true swapability. I've been using and supporting spring for a long time, but after doing some tapestry work, and re-thinking IoC approaches, I'm moving in favor of picocontainer. Tapestry doesn't use picocontainer but has an IoC framework that's got some similar design concepts. Actually, that gets to another point, which is that Tapestry is happy and easy and fun (well, T5), and since it comes with an IoC framework that can integrate cleanly with Spring if we want that benefit, you can get the whole kit together. The other nice thing about Tapestry, is that several people have made quickstart projects which include everything Continuum would likely use including Spring, spring-acegi, hibernate/jpa, etc. One could use that as a structural basis, and T5 is (currently) built with maven, and will at least be deployed to maven repositories in perpetuity. Christian. On 5-Feb-08, at 19:12 , Carlos Sanchez wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Some continuum-jpa branch updates
I would have liked this thread to merge with Continuum 2.0 discussion thread, but anyway... Its seems TopLink can do Criteria Queries (using Expressions and ExpressionBuilders, correct me if I am wrong). It seems quite a few JPA implementations provide some sort of Criteria Query API extension. And from what I gather online, its quite likely that JPA 2.0 would standardize a Criteria API. So, no more performance overhead of String concatenations ;-) Rahul Christian Edward Gruber wrote: You can still use parameterized queries dynamically, you just use strings that contain ? and they get turned into pre-compiled queries in the db. However, named queries can be further optimized by Hibernate before it even gets to the db (pre-compiling at load, etc.) Criteria queries are the other way to go. They're programmatically constructed and they can get a lot of the jdbc benefits of named queries. Christian. On 21-Jan-08, at 16:59 , Emmanuel Venisse wrote: As Christian said, named queries are pre-compiled to SQL. With dynamic queries, perf can be not good because for each execution, the JPQL request is recompile to SQL, so parsing, creation of the JPQL tree then SQL generation, and with your solution, you concatenate lot of String. It isn't important for one request but with lot of request, you use more time and cpu, for string concatenation, it is better to use StringBuilder that is more performant than String addition or StringBuffer. An other argument for named queries is that with dynamic queries, if they aren't written correctly (it isn't the case for your code ;) ), it is easy to introduce some malicious SQL code with parameters my two cents. Emmanuel On Jan 18, 2008 9:57 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: You can get some benefit from named queries in terms of query pre- compilation and caching on the underlying database. However, most database flavors and hibernate providers turn criteria queries into named queries (parameterized SQL) which is then cached, so, on the surface I suspect the performance characteristics will be similar. Christian. On 18-Jan-08, at 14:35 , Rahul Thakur wrote: Thanks Emmanuel! Responses inlined... Emmanuel Venisse wrote: Hi Rahul, After few days to look at JPA, I'm sure now it would be good to use it instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA). The code is very easy to write and to read with JPA. About your continuum-jpa branch, I have few remarks: - I don't think it's good to use directly some OpenJPA APIs. If possible, I'd prefer to use only standard JPA APIs so we'll can choose later the implementation we want to use (OpenJPA, TopLink, JPOX...) Agree. The only place where OpenJPA APIs are being used directly currently are the unit tests. - why do you use some Spring code? Experimental. Spring has a good transaction management framework out of the box. - we don't need to store the model encoding (CommonUpdatableModelEntity class) Sure. Easily fix'able. :-) - can you explain dateCreated/dateUpdated fields? How are they managed? These are for audit puposes, and can be used as range search query criteria for fetching entities. These were an extension I thought will be good. 'dateCreated' gets set when an entity is first inserted into the underlying store, subsequent updates update the 'dateUpdated'. - all the model is fectched eagerly and it isn't acceptable for performance Yes, the model does needs review and tweaks to annotations where we know we don't need to fetch 'eagerly'. - I'm not sure your Query pattern is good. I'd prefer to use named queries but maybe you have a reason I think using a Query like we have on the JPA branch nicely provides for a flexible construction of queries (i.e, only the criteria passed in contributes to the query). I am not sure if such is available with named queries; but I am interested to know why named queries might be better. Cheers, Rahul That's all for the moment. Emmanuel On Jan 16, 2008 11:30 PM, Rahul Thakur [EMAIL PROTECTED] wrote: Just wondering if anyone else got to the changes? Emmanuel Venisse wrote: I don't have the time to look at it these days but I'll do it asap (maybe in few weeks :( ) Emmanuel Rahul Thakur a écrit : Hi All, Scribbling some quick notes on some of the toying around I have been doing with OpenJPA, Generics etc on the continuum-jpa branch[1]: 1) Use JPA for persistence Motivation behind this has been to investigate how this compares to JPOX/JDO for managing the model - both in terms on performance and ease of use (Store APIs). Continuum model classes are annotated with JPA annotations on the branch. However, this needs a review as there are some elements (for example 'configuration' typed as Map) that I am not sure yet how to persist yet. The provider used is OpenJPA [2]. 2) Refactorings to Store interface Main motivation has been to keep the core Store interface lean and mean (read extensible). The
Re: [Discussion] Continuum 2.0 Roadmap
LOL. I'm so out of date. I used to work with TopLink way back in the earliest days, and tracked it up to the Oracle buyout. After that I didn't pay attention, and it's clearly changed direction. Never knew the core was open-sourced. Anyway, it's always been one of the better OR/M platforms, so I'd be cool with it if the license is Apache-compatible. Christian. On 6-Feb-08, at 00:03 , Rahul Thakur wrote: TopLink Essentials
Re: Some continuum-jpa branch updates
Nice! On 6-Feb-08, at 00:31 , Rahul Thakur wrote: I would have liked this thread to merge with Continuum 2.0 discussion thread, but anyway... Its seems TopLink can do Criteria Queries (using Expressions and ExpressionBuilders, correct me if I am wrong). It seems quite a few JPA implementations provide some sort of Criteria Query API extension. And from what I gather online, its quite likely that JPA 2.0 would standardize a Criteria API. So, no more performance overhead of String concatenations ;-) Rahul
