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: 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
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: 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: 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
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: 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)
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: 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/
Confused about the branches
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: 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: [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: 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
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: [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: [discuss] Graduate Continuum to its own TLP
So, it seems like we are unanimous in favour of Emmanuel as the chair, and by lazy consensus agree to the committer list and initial PMC below :) Emmanuel, will you put together the proposed project description, and then the proposal for us to vote on? Cheers, Brett On 05/01/2008, at 10:00 AM, Brett Porter wrote: So the poll for progressing seems in favour. Before we continue to vote on a proposal to send to the board, we need to decide on a description for the project, the initial PMC/ committers, and a chair. I would like to nominate Emmanuel as the chair of the project. Are there any other nominations? I have the current committers list as: Maria Odea Ching Joakim Erdfelt Olivier Lamy Trygve Laugstol Jesse McConnell Brett Porter Edwin Punzalan Carlos Sanchez Wendy Smoak Rahul Thakur Emmanuel Venisse Kenney Westerhof Andrew Williams Anyone on that list that doesn't feel they should be a committer? Did I miss anyone? The following have committed only once, or have declared themselves emeritus: Herve Boutemy Dan Diephouse Fabrizio Giustina Arnaud Heritier Lukas Theussl Jason van Zyl Anyone on that list that would like to be included? Finally - I propose that the initial PMC be equal to the list of committers. Any objections or opinions about that? Cheers, Brett On 20/12/2007, at 5:42 PM, Brett Porter wrote: So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy
Re: [discuss] Graduate Continuum to its own TLP
Thanks Rahul. I appreciate the thought, however I decline the nomination at this time :) On 08/01/2008, at 5:00 AM, Rahul Thakur wrote: And the nominations are. (~opens the envelope~) 1) Brett Porter , and 2) Jesse McConnell Cheers :-) Rahul Brett Porter wrote: of course :) On 07/01/2008, at 5:09 PM, Rahul Thakur wrote: Are more than one nominations allowed per person? Rahul Brett Porter wrote: So the poll for progressing seems in favour. Before we continue to vote on a proposal to send to the board, we need to decide on a description for the project, the initial PMC/ committers, and a chair. I would like to nominate Emmanuel as the chair of the project. Are there any other nominations? I have the current committers list as: Maria Odea Ching Joakim Erdfelt Olivier Lamy Trygve Laugstol Jesse McConnell Brett Porter Edwin Punzalan Carlos Sanchez Wendy Smoak Rahul Thakur Emmanuel Venisse Kenney Westerhof Andrew Williams Anyone on that list that doesn't feel they should be a committer? Did I miss anyone? The following have committed only once, or have declared themselves emeritus: Herve Boutemy Dan Diephouse Fabrizio Giustina Arnaud Heritier Lukas Theussl Jason van Zyl Anyone on that list that would like to be included? Finally - I propose that the initial PMC be equal to the list of committers. Any objections or opinions about that? Cheers, Brett On 20/12/2007, at 5:42 PM, Brett Porter wrote: So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy
Re: Side effects of project groups page auto-refresh
ISTR Emmanuel going through these at one point, so I expect there are not many that remain - you could look in the xwork.xml to see the ones that don't use redirect though. - Brett On 03/01/2008, at 4:42 AM, Wendy Smoak wrote: The 'Project Groups' page automatically refreshes itself every so often. Unfortunately, this now causes errors when existing actions forward to that page rather than redirect to it. One such problem (after performing a release) was reported and fixed in CONTINUUM-1560 [1]. But it also happens when adding a project group. There are probably more places this needs to be fixed. Is there an easy way to identify the actions that are affected by this? [1] http://jira.codehaus.org/browse/CONTINUUM-1560 Thanks, -- Wendy
Re: [discuss] Graduate Continuum to its own TLP
So the poll for progressing seems in favour. Before we continue to vote on a proposal to send to the board, we need to decide on a description for the project, the initial PMC/ committers, and a chair. I would like to nominate Emmanuel as the chair of the project. Are there any other nominations? I have the current committers list as: Maria Odea Ching Joakim Erdfelt Olivier Lamy Trygve Laugstol Jesse McConnell Brett Porter Edwin Punzalan Carlos Sanchez Wendy Smoak Rahul Thakur Emmanuel Venisse Kenney Westerhof Andrew Williams Anyone on that list that doesn't feel they should be a committer? Did I miss anyone? The following have committed only once, or have declared themselves emeritus: Herve Boutemy Dan Diephouse Fabrizio Giustina Arnaud Heritier Lukas Theussl Jason van Zyl Anyone on that list that would like to be included? Finally - I propose that the initial PMC be equal to the list of committers. Any objections or opinions about that? Cheers, Brett On 20/12/2007, at 5:42 PM, Brett Porter wrote: So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy
Re: svn commit: r607431 - /maven/site/trunk/src/site/resources/.htaccess
On 30/12/2007, at 2:45 AM, [EMAIL PROTECTED] wrote: Author: wsmoak Date: Sat Dec 29 07:45:18 2007 New Revision: 607431 URL: http://svn.apache.org/viewvc?rev=607431view=rev Log: Update redirects to latest Maven version. Add redirect for Continuum docs. Modified: maven/site/trunk/src/site/resources/.htaccess Modified: maven/site/trunk/src/site/resources/.htaccess URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/resources/.htaccess?rev=607431r1=607430r2=607431view=diff = = = = = = = = == --- maven/site/trunk/src/site/resources/.htaccess (original) +++ maven/site/trunk/src/site/resources/.htaccess Sat Dec 29 07:45:18 2007 @@ -2,12 +2,13 @@ Redirect Permanent /guides/mini/guide-ibiblio-upload.html http://maven.apache.org/guides/mini/guide-central-repository-upload.html Redirect Permanent /faq.html http://maven.apache.org/general.html +Redirect Permanent /continuum/documentation/1_1 http://maven.apache.org/continuum/docs/1.1 Should this go in Continuum's site .htaccess? Cheers, Brett
Re: svn commit: r607431 - /maven/site/trunk/src/site/resources/.htaccess
done :) On 30/12/2007, at 12:48 PM, Wendy Smoak wrote: On Dec 29, 2007 5:08 PM, Brett Porter [EMAIL PROTECTED] wrote: On 30/12/2007, at 2:45 AM, [EMAIL PROTECTED] wrote: Modified: maven/site/trunk/src/site/resources/.htaccess Should this go in Continuum's site .htaccess? It could, but there isn't one at the moment. No objection to adding it... -- Wendy
Re: [discuss] Graduate Continuum to its own TLP
So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy
Re: Continuum 1.1
Given that there have been not-insignificant code changes since the last release, and this falls over the weekend - I'd suggest a longer vote period on this. On 13/11/2007, at 11:55 AM, Emmanuel Venisse wrote: Hi, All issues for Continuum 1.1 final will be closed this week, so I'll try to prepare the release next Friday (Nov. 16) Before to do the release, I'll try (I'm not sure yet) to add pagination in the build results list page to save some memory when users call it for projects with lot of build results. Emmanuel -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
customising emails
Hi, Got a request for vmbuild for a project to limit the size of the build log emails (since they are huge) - are we able to customise email templates easily enough in the current version? I'm assuming the best thing to do here is to just not show the output at all and let the user clickthrough. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: customising emails
But what if we only want to do this for one set of projects? Shouldn't that be a mail notifier property? On 05/11/2007, at 11:53 PM, Emmanuel Venisse wrote: We can set includeBuildResult to false in application.xml Emmanuel Brett Porter a écrit : Hi, Got a request for vmbuild for a project to limit the size of the build log emails (since they are huge) - are we able to customise email templates easily enough in the current version? I'm assuming the best thing to do here is to just not show the output at all and let the user clickthrough. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: customising emails
np :) http://jira.codehaus.org/browse/CONTINUUM-1545 On 06/11/2007, at 12:14 AM, Emmanuel Venisse wrote: For the moment, it's a global option, but would be good to set it in the notifier configuration. Can you file an issue? Emmanuel Brett Porter a écrit : But what if we only want to do this for one set of projects? Shouldn't that be a mail notifier property? On 05/11/2007, at 11:53 PM, Emmanuel Venisse wrote: We can set includeBuildResult to false in application.xml Emmanuel Brett Porter a écrit : Hi, Got a request for vmbuild for a project to limit the size of the build log emails (since they are huge) - are we able to customise email templates easily enough in the current version? I'm assuming the best thing to do here is to just not show the output at all and let the user clickthrough. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
converting from 1.0.3
Hi, I'm anticipating this could be a common question after 1.1 is released - was there a decision made about whether the data converter should support importing from 1.0.3 projects? I know this was something I was going to implement that I never quite got around to after finishing the bits to convert from other 1.1 alphas - but if the data management is working ok now then it might be a good alternative. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: build in error fix not working?
I didn't keep track of the changes after this - was it fixed? On 24/09/2007, at 6:52 PM, Emmanuel Venisse wrote: Hmm, I'll look at it to fix it definitively Emmanuel Brett Porter a écrit : Hi, Note this build: http://maven.zones.apache.org/continuum/ buildResults.action?projectId=272projectGroupId=8 It is stuck in error - but I thought this was fixed in beta-3? Could it be because it is an error on SCM update that it isn't detected as fixed? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: next release
I'm happy to bump 1475. I think 1388 needs to be fixed before a final release though? What about the 12 issues in 1.1 - are they all docs? Are you saying they'll just be addressed after the release? I think it's very close, I wonder if it might be worth having one last beta to get a bit of feedback to see if there is any blockers while the docs, etc are done? Just my 2c, I'm happy either way :) - Brett On 17/10/2007, at 6:31 PM, Emmanuel Venisse wrote: Hi, In jira, we have now 3 issues opened, I don't think I'll can fix CONTINUUM-1388 before the release because it require changes and releases of remote-resources-plugin, apache-jar-resource-bundle and maven parent pom. I'm not sure to fix CONTINUUM-1475 too. About the docs, we have already few pages done, I'll can work on others in next days. What do you think about the version to use for the continuum release? We have two choices: 1.1-beta-4 or 1.1 final. Personnally, I'd prefer 1.1 final. I tested all parts and all seems to be ok, I just need to test more the ANT/shell part. I'd like to prepare the Continuum release next week. Emmanuel -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: build definition used on build result
also when it is in progress On 24/09/2007, at 6:50 PM, Emmanuel Venisse wrote: olivier lamy a écrit : Hi, * Yes it's stored in the database with the buildResult (like a clone and add of the buildDefinition). * Yes it is in the email. * It looks we have to store the buildDefinition even if the scm update/checkout failed no, if the build fails in checkout/update, the build def must be hidden in the build result. Emmanuel -- Olivier 2007/9/23, Brett Porter [EMAIL PROTECTED]: A couple of questions/issues on this new feature: * is this stored with the build result, or is it referring to what is in the database now? (ie, what happens to the result if the build definition is later removed?) * is it in the email template? (haven't looked yet) * issue: it shows up on builds that are in error as empty: http:// maven.zones.apache.org/continuum/buildResult.action? buildId=23999projectId=272projectGroupId=8 Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: build definition used on build result
It's empty too On 24/09/2007, at 7:30 PM, Emmanuel Venisse wrote: Brett, you want to hide it when it is in progress or it is empty too? If it is empty, it's a bug but I don't want to hide it when the build is started. Emmanuel Brett Porter a écrit : also when it is in progress On 24/09/2007, at 6:50 PM, Emmanuel Venisse wrote: olivier lamy a écrit : Hi, * Yes it's stored in the database with the buildResult (like a clone and add of the buildDefinition). * Yes it is in the email. * It looks we have to store the buildDefinition even if the scm update/checkout failed no, if the build fails in checkout/update, the build def must be hidden in the build result. Emmanuel -- Olivier 2007/9/23, Brett Porter [EMAIL PROTECTED]: A couple of questions/issues on this new feature: * is this stored with the build result, or is it referring to what is in the database now? (ie, what happens to the result if the build definition is later removed?) * is it in the email template? (haven't looked yet) * issue: it shows up on builds that are in error as empty: http:// maven.zones.apache.org/continuum/buildResult.action? buildId=23999projectId=272projectGroupId=8 Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
build definitions in UI
Hi, Sorry, didn't take a look at these before the beta-3 release. What do folks think of the following changes? - replace select all/unselect all by a checkbox above the checkbox column that functions in this way (seems a more standard convention) instead of the links - put delete project(s) last in the line - change all the group buttons to be consistent: edit group, delete group, release group, build group - add release project(s) to the bottom - put build project(s), build group and add project on lines of their own Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
build in error fix not working?
Hi, Note this build: http://maven.zones.apache.org/continuum/ buildResults.action?projectId=272projectGroupId=8 It is stuck in error - but I thought this was fixed in beta-3? Could it be because it is an error on SCM update that it isn't detected as fixed? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: Continuum Model and Modello
On 21/09/2007, at 5:31 PM, Emmanuel Venisse wrote: Rahul Thakur a écrit : I have been wanting to pop this questions for sometime now. For generation/maintenance of continuum-model: a) Why are we using Modello? More specifically what does it buy us? I know the model is expressed as xml and separate from Java sources, but I don't see a benefit of having it in XML as opposed to annotations in java sources. modello file generate for use all model POJOs and the jpox metadata file. With it, we can define old fields that doesn't exist in the nex version and the migration tool use the model to do the db conversion. I don't think we can all of that with annotations. The DB conversion is less than ideal though. I think the tools that OpenJPA already provide for doing such things are superior (from the brief look I've had). I'm thinking the model conversion is a bit of a seemed like a good idea at the time thing that I did... I'd be happier with coding it up by hand now and making the store simpler. In making the store simpler, and carefully mapping to tables, I think we can avoid the need for conversion anyway by trying to only make additions. I'd be willing to experiment with alternatives - perhaps it would be best to do this piece by piece though, rather than one big conversion (as the impl. currently leaks out all over - we need to better isolate the lazy loading and fetching of data through the actions before safely extracting pieces). Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: [discuss] Graduate Continuum to its own TLP
On 22/09/2007, at 7:34 AM, Rahul Thakur wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. I agree. It is effectively running itself already. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. While I am for Continuum as TLP, I don't understand the rationale behind having committers from different companies. How would this help to make Continuum more stable? Stability from a community point of view. Firstly, we need to ensure we have enough committers in the first place - for example, to ensure that if Emmanuel decided he could no longer participate, the project would need to be able to survive (though obviously, miss him greatly :) Having those committers from a diverse set of companies is an extra safeguard to ensure that no single company either controls the direction of the project, or could cause it problems by withdrawing people's time on it. To be clear, there's no reason to suspect this is a problem now - it's just a worthy thing to have in a project. I think everything is on track here - the first focus should be on getting 1.1 out of course, but if we keep doing what we are doing this totally makes sense. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
turning off continuum_ci.sh?
Now that Continuum is self-hosting, shall we turn off the hourly build to save some cpu cycles? - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: [jira] Closed: (CONTINUUM-358) User Authentication via LDAP
Should this be open until we actually switch? :) On 01/09/2007, at 6:14 AM, Jesse McConnell (JIRA) wrote: [ http://jira.codehaus.org/browse/CONTINUUM-358? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed CONTINUUM-358. - Assignee: Jesse McConnell Resolution: Fixed Fix Version/s: (was: Future) 1.1-beta-3 providing we get continuum updated to use redback-alpha-3 readonly ldap support should exist in 1.1-beta-3 User Authentication via LDAP Key: CONTINUUM-358 URL: http://jira.codehaus.org/browse/CONTINUUM-358 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Frank Zhao Assignee: Jesse McConnell Fix For: 1.1-beta-3 Please add LDAP support for the user authentication in Continuum user management function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: error states
Anyone have any thoughts on this? On 20/08/2007, at 10:59 AM, Brett Porter wrote: I think I understand this problem more now. the svn errors are a transient problem - it occurs before a build takes place, but they are recorded as a built result. So when they succeed again, no build occurs because no update has taken place. I see two possible corrections to this problem: 1) don't record a build result for update failures (have some sort of project level error and different way of notifying/correcting). 2) rebuild a project that was in error state before. Only the first would also address the problem of having difficulties diagnosing errors that occur even earlier and don't record a build result at all. It also is a nice separation of configuration/environmental errors vs actual build failures. It helps with the separation of roles when you have a server admin and developers that just commit on the code. However, it's a lot more work, and it might be better to schedule that for the future and fix it via (2) for 1.1. what do others think? - Brett On 16/08/2007, at 1:46 PM, Brett Porter wrote: I'm also seeing where there is a real error, like the SVN server not being reachable, and it not trying to build ever again. On 16/08/2007, at 1:40 PM, Brett Porter wrote: I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
Re: error states
On 29/08/2007, at 7:48 PM, Emmanuel Venisse wrote: 2) rebuild a project that was in error state before. I think it's the best solution for now and won't be a lot of work. agreed... can we sneak this into the 1.1 JIRA? :D Only the first would also address the problem of having difficulties diagnosing errors that occur even earlier and don't record a build result at all. It also is a nice separation of configuration/environmental errors vs actual build failures. It helps with the separation of roles when you have a server admin and developers that just commit on the code. However, it's a lot more work, and it might be better to schedule that for the future and fix it via (2) for 1.1. I'm agree even if I don't know yet how to find the error type. Anything that can set an error state on the project needs to be reviewed to make sure it records a build result if it doesn't already - I've definitely found some that don't (eg, missing POM parent after scm update) - Brett
CONTINUUM-605: notification feature
Hi, I know where in feature freeze, but I'd really like this and it has a patch :) Anyone think it is worth considering? - Brett
Anyone seen Continuum hanging in recent versions?
We get this occasionally on vmbuild1: https://issues.apache.org/jira/ browse/INFRA-1326 I've not yet seen it on the zone. There's nothing in the logs to report. Anyone seen this? Cheers, Brett
Re: error states
I think I understand this problem more now. the svn errors are a transient problem - it occurs before a build takes place, but they are recorded as a built result. So when they succeed again, no build occurs because no update has taken place. I see two possible corrections to this problem: 1) don't record a build result for update failures (have some sort of project level error and different way of notifying/correcting). 2) rebuild a project that was in error state before. Only the first would also address the problem of having difficulties diagnosing errors that occur even earlier and don't record a build result at all. It also is a nice separation of configuration/ environmental errors vs actual build failures. It helps with the separation of roles when you have a server admin and developers that just commit on the code. However, it's a lot more work, and it might be better to schedule that for the future and fix it via (2) for 1.1. what do others think? - Brett On 16/08/2007, at 1:46 PM, Brett Porter wrote: I'm also seeing where there is a real error, like the SVN server not being reachable, and it not trying to build ever again. On 16/08/2007, at 1:40 PM, Brett Porter wrote: I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
Re: Continuum on vmbuild machines at apache.
Thanks for the heads up. One issue is that it was using an old instance that had stalled and meant to be shut down, the other is the problem I reported on the list yesterday about the stuck error state. - Brett On 17/08/2007, at 6:35 AM, Joakim Erdfelt wrote: Looks like the Cocoon and Tuscany projects are having long build issues (3+ weeks. eek!) on the vmbuild machines at apache.org. Tuscany SCA contact: Luciano Resende [EMAIL PROTECTED] Cocoon contact: Grzegorz Kossakowski [EMAIL PROTECTED] Might want to contact them on the details of their issues. -- - Joakim Erdfelt [EMAIL PROTECTED]
Re: [jira] Commented: (CONTINUUM-1234) Improve user role management
On 17/08/2007, at 12:13 PM, Wendy Smoak wrote: FYI, I moved this issue to PLXREDBACK and promptly lost the ability to edit it. :( See: http://jira.codehaus.org/browse/PLXREDBACK-95 yeah, need to be a plexus committer in xircles (BTW, the reply-to on this was [EMAIL PROTECTED], not continuum-dev.) we only have one issues list, and it sets the reply-to (not JIRA). -- Wendy On 8/16/07, Brett Porter (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.codehaus.org/browse/CONTINUUM-1234? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_105065 ] Brett Porter commented on CONTINUUM-1234: - looks good, just: - change the name from templated/non-templated to something else :) - make sure it matches the normal visual styles
brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Here's what I did (this is a once off thing, though we really need to make sure changes are backwards compatible and can handle missing metadata in the future...) - run data-management from 1.1-beta-1 to export the build database (I had to build this from source) - edit the exported builds.xml to add installationId1/ installationId to each installation (using sequential numbers) - change name=... to installationId=... in each profile by replacing the name with the corresponding installation ID - comment out the environmentVariables profile since it would cause a duplicate PK (maybe a bug in the data management) - import the database again using data management from 1.1-beta-2. In case anyone needs it :) Cheers, Brett
Re: [vote] Release Continuum 1.1-beta-2
+1 I gave it the basic run through - added a project, some profiles, checked the licenses. All is well. Very nice work everyone that's done stuff. It's starting to shape up well! - Brett On 15/08/2007, at 12:56 AM, Emmanuel Venisse wrote: Hi, Continuum 1.1-beta-2 is ready for release The highlights are - lot of bug fixes - Installations/profiles screens improvement - screen flow improvement in Add Project part - cancellable builds The Release Notes is available there: http://jira.codehaus.org/ secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13606 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1- beta-2/org/apache/maven/continuum/continuum-plexus-runtime/1.1- beta-2/continuum-plexus-runtime-1.1-beta-2-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1- beta-2/org/apache/maven/continuum/continuum-webapp/1.1-beta-2/ continuum-webapp-1.1-beta-2.war - data management cli: http://people.apache.org/builds/maven/ continuum/1.1-beta-2/org/apache/maven/continuum/data-management-cli/ 1.1-beta-2/data-management-cli-1.1-beta-2-app.jar Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... The vote will be open for 72 hours. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Re: Solving the notification problem
Files as 1389 and 1390, with some additional comments about the alwaysSend bit. On 11/08/2007, at 2:59 AM, Emmanuel Venisse wrote: Yes they are improvments requests to file. I'm not sure about 2) because we already have the alwaysSend parameter that can be set I won't look at it for 1.1-beta-2 but I'll try for 1.1-beta-3 Emmanuel Brett Porter a écrit : Did I understand the summary to be the following to improvement requests to file? 1) for group notifiers, don't send a mail if another build is scheduled in the group already (instead, have the results added to the mail for that group). Make this a configurable option, on the group notifier itself. Default is off for consistency with current behaviour. 2) add a threshold of messages, particularly for errors - don't send a message that is identical to one sent in the last X hours. Cheers, Brett On 02/08/2007, at 6:26 PM, Emmanuel Venisse wrote: Brett Porter a écrit : On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote: For a project notifier, I think we can keep what we have actually, but for a group notifier, we can send a single mail by project group. The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't need to modify the db schema for this new feature. Sounds good to me. That and eliminating the error condition would be great. I'd like to keep the usage we have actually, so we can use a new parameter in the continuum conf where admin will choose if mail are sent one by one or by project group. Do you think this is a continuum conf, or a group notifier conf? It can be a group notifier conf (it will be better than a global continuum conf) because we don't have specific fields in db for notifier config so we can add what we want. If we do that, what will be the default? Will we allow to set the default in the global conf? Emmanuel
error states
I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
Re: error states
I'm also seeing where there is a real error, like the SVN server not being reachable, and it not trying to build ever again. On 16/08/2007, at 1:40 PM, Brett Porter wrote: I see too often project's getting stuck in error state, and it's quite hard to diagnose what's wrong. They don't automatically recover, and there is no build result for the actual error (so clicking the icon takes you to the last successful one) Anyone have any thoughts on how we can improve this? - Brett
Re: [continuum build trunk - FAILED - update] Wed Aug 15 03:00:01 GMT 2007
is this just a bad env on the zone? might be a hint that the release stuff could have a problem with certain environments too - worth checking. On 15/08/2007, at 3:05 AM, [EMAIL PROTECTED] wrote: Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build- log-20070815.030002.txt
[OT] Mini-interview with Emmanuel Venisse
Hi all, I already posted this to the users@ list, but I thought some folk here might be more particularly interested in what Emmanuel had to say when we talked recently: http://www.devzuz.org/?q=node/12. Enjoy! Cheers, Brett
Re: Solving the notification problem
Did I understand the summary to be the following to improvement requests to file? 1) for group notifiers, don't send a mail if another build is scheduled in the group already (instead, have the results added to the mail for that group). Make this a configurable option, on the group notifier itself. Default is off for consistency with current behaviour. 2) add a threshold of messages, particularly for errors - don't send a message that is identical to one sent in the last X hours. Cheers, Brett On 02/08/2007, at 6:26 PM, Emmanuel Venisse wrote: Brett Porter a écrit : On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote: For a project notifier, I think we can keep what we have actually, but for a group notifier, we can send a single mail by project group. The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't need to modify the db schema for this new feature. Sounds good to me. That and eliminating the error condition would be great. I'd like to keep the usage we have actually, so we can use a new parameter in the continuum conf where admin will choose if mail are sent one by one or by project group. Do you think this is a continuum conf, or a group notifier conf? It can be a group notifier conf (it will be better than a global continuum conf) because we don't have specific fields in db for notifier config so we can add what we want. If we do that, what will be the default? Will we allow to set the default in the global conf? Emmanuel
Re: Two week sprints on Continuum Beta releases?
I think following the same approach as Archiva is the best way to go. Let's pick out how many we can do in the first two weeks, then do a big bug bash to try and find all the known issues and file them either for further betas or 1.1.x. Then we should know how many betas we'll have left. I would think about 3 (2 more). I expect we've hammered a lot more out of Continuum already. - Brett On 02/08/2007, at 6:23 PM, Emmanuel Venisse wrote: How many beta do you want to do? I think 2 or 3 will be enough. But I'm agree we can't resolve all beta-2 issues by Aug 15. Emmanuel Brett Porter a écrit : Hi, How do people feel about planning betas to fit into: Aug 15, Aug 29, Sep 12, Sep 26? (for releases, votes are the monday before) If so, is the current beta-2 list achievable by Aug 15? Looks like it needs to be trimmed (and we also have 11 unscheduled to find a home for) Cheers, Brett
Re: Solving the notification problem
On 02/08/2007, at 7:46 AM, Emmanuel Venisse wrote: For a project notifier, I think we can keep what we have actually, but for a group notifier, we can send a single mail by project group. The mail can be sent after the build of the latest project of the group, I don't think it will be a problem to know if the project is the latest and we won't need to modify the db schema for this new feature. Sounds good to me. That and eliminating the error condition would be great. I'd like to keep the usage we have actually, so we can use a new parameter in the continuum conf where admin will choose if mail are sent one by one or by project group. Do you think this is a continuum conf, or a group notifier conf? - Brett
Re: Solving the notification problem
On 01/08/2007, at 12:01 PM, Jesse McConnell wrote: well, 1.1 is in beta now so ideally no more features, but maybe we just call this a bug fix for now.. yeah, I'm looking more for a small improvement than a revolution. Avoiding schema changes and such. I really should have said something before beta-1. I guess the first suggestion might be a batch email option with a summary presented at the top of the mail...that would almost have to be on a per notifier though, but that is made easier by the group level inherited notifiers...That is another db schema change though :) Yeah, and we don't really have anything that can keep track of when to send that - there's no notion of a group schedule. We could alter the notifications to prepare web reports that have the links mailed out, and suppress mails based on time or if a given link has been mailed recently. We already have the web reports, so maybe a configurable time threshold is the best (ok, it might require an addition to the notifier schema, but it's innocuous :) what conditions do we find the highest lvl of easily ignorable mails go out? I can think of things like SCM outage and things like that...out of memory errors... Errors are definitely the biggest nuisance, and probably chain reaction failures. If we could even take care of the error condition stuff it might be enough. - Brett
Database model change for beta-1
Hi, I've narrowed down the problem in upgrading from alpha-2 to beta-1 to the following model change: field namebuildDefinition/name version1.1.0+/version association xml.reference=true stash.part=true jpox.dependent=false typeBuildDefinition/type /association /field The problem here is that Continuum has no idea how to pre-populate the value for this. Should we/can we simply add a default value of null for this? Or will the data management app need some smarts to set it to the default build definition where it doesn't exist? Thanks, Brett
Re: some issues for rescheduling?
Anyone have any thoughts on these, or should I just go ahead and make the changes? (Sorry Emmanuel, I know you've been offline a bit recently :) Cheers, Brett On 25/07/2007, at 5:13 PM, Emmanuel Venisse wrote: Thanks Brett, I'll review them. Emmanuel Brett Porter a écrit : Hi, I took a look through future for things that could be adjusted, and came up with the following list. I didn't want to 'just do it', since I'm not that close to the status of the project right now, so if someone could review these it'd be much appreciated. to close: CONTINUUM-933 (acegi branch) CONTINUUM-450 (the wagon notifier does this?) CONTINUUM-37 (superceded) CONTINUUM-516 (can't see why it's neeeded, enqueue is fast) CONTINUUM-924 (already exists?) CONTINUUM-841 (duplicate of 678, no longer an issue) CONTINUUM-1112 (seems fixed already) CONTINUUM-882 (from acegi) CONTINUUM-938 (I think it no longer applies - test and close) CONTINUUM-960 (out of date) CONTINUUM-128 (no longer needed) CONTINUUM-640 (I think it dupes 347?) CONTINUUM-467 (I think it dupes 347?) CONTINUUM-344 (out of date) CONTINUUM-721 (out of date) CONTINUUM-737 (out of date) CONTINUUM-660 (out of date) CONTINUUM-751 (out of date?) CONTINUUM-752 (out of date?) CONTINUUM-1176 (out of date) CONTINUUM-1247 (not a Continuum bug?) CONTINUUM-1248 (not a Continuum bug?) CONTINUUM-1249 (not a Continuum bug?) CONTINUUM-1253 (won't fix - use mvn deploy instead) to schedule for 1.1: CONTINUUM-692 (possibly - talks about profile dependency being the only blocker) CONTINUUM-347 (documentation) CONTINUUM-815 (documentation) CONTINUUM-1063 (just do it) CONTINUUM-618 (it's really annoying, and simple to fix) CONTINUUM-1037 (seems a fatal flaw in Ant use) CONTINUUM-811 (documentation) CONTINUUM-1079 (the feature exists, it's just not visible due to this problem and probably related security issues) CONTINUUM-1310 (goes with above) CONTINUUM-1333 CONTINUUM-1265 (NPE should generally be fixable) CONTINUUM-1255 (is ugly, should be easy to disable) Thanks, Brett
some issues for rescheduling?
Hi, I took a look through future for things that could be adjusted, and came up with the following list. I didn't want to 'just do it', since I'm not that close to the status of the project right now, so if someone could review these it'd be much appreciated. to close: CONTINUUM-933 (acegi branch) CONTINUUM-450 (the wagon notifier does this?) CONTINUUM-37 (superceded) CONTINUUM-516 (can't see why it's neeeded, enqueue is fast) CONTINUUM-924 (already exists?) CONTINUUM-841 (duplicate of 678, no longer an issue) CONTINUUM-1112 (seems fixed already) CONTINUUM-882 (from acegi) CONTINUUM-938 (I think it no longer applies - test and close) CONTINUUM-960 (out of date) CONTINUUM-128 (no longer needed) CONTINUUM-640 (I think it dupes 347?) CONTINUUM-467 (I think it dupes 347?) CONTINUUM-344 (out of date) CONTINUUM-721 (out of date) CONTINUUM-737 (out of date) CONTINUUM-660 (out of date) CONTINUUM-751 (out of date?) CONTINUUM-752 (out of date?) CONTINUUM-1176 (out of date) CONTINUUM-1247 (not a Continuum bug?) CONTINUUM-1248 (not a Continuum bug?) CONTINUUM-1249 (not a Continuum bug?) CONTINUUM-1253 (won't fix - use mvn deploy instead) to schedule for 1.1: CONTINUUM-692 (possibly - talks about profile dependency being the only blocker) CONTINUUM-347 (documentation) CONTINUUM-815 (documentation) CONTINUUM-1063 (just do it) CONTINUUM-618 (it's really annoying, and simple to fix) CONTINUUM-1037 (seems a fatal flaw in Ant use) CONTINUUM-811 (documentation) CONTINUUM-1079 (the feature exists, it's just not visible due to this problem and probably related security issues) CONTINUUM-1310 (goes with above) CONTINUUM-1333 CONTINUUM-1265 (NPE should generally be fixable) CONTINUUM-1255 (is ugly, should be easy to disable) Thanks, Brett
Re: Heads up regarding VMBuild
So, is anyone interested? On 11/07/2007, at 11:06 PM, Brett Porter wrote: Hi folks, I'm currently doing the rounds of all the people using Continuum on VMBuild. The set up on there ballooned despite the box being underpowered and the installation intended to be experimental, so was never very well maintained. We have a new box to move vmbuild to now and with the features in continuum 1.1 I think we can make a decent go at it. I was going to set up the next release (with profiles and 'single module build' support) and start setting up projects on there and maintain it properly. Hopefully we can get some additional feedback in to the 1.1 final release. Is anyone interested in helping out? Cheers, Brett
Re: Proposition for CONTINUUM-798
This sounds fine to me. Questions I think weren't answered here: - how do you track when the modules change - by comparing modules to the list of projects in a group? If so, how to handle the edge cases where extra projects are added to or removed from a group aside from the modules? - how do you handle the removal of a module from a POM when the project is still in Continuum? Will that just delete the project, and if so what happens to the build history, etc.? (sounds dangerous!) Would you be able to write this up as a short proposal on the website? The only other thought I have is that this is a new feature - is it intended to land before 1.1-beta-1, or will it be on a feature branch for a later version of Continuum? Cheers, Brett On 11/07/2007, at 4:40 PM, Maria Odea Ching wrote: Hi All, I'm trying to fix up http://jira.codehaus.org/browse/CONTINUUM-798, which is Modules automatic discovery. I think the patch submitted is already outdated and there was the issue about recursive modules. Anyway, below is how I thought to implement the fix for this: Create an update-modules action in continuum-core that will check for new modules in the pom. The action would be invoked when a project build is triggered (forced or scheduled), after the project is updated from SCM (in DefaultBuildController). To add the new module to Continuum, I think we could make use of the addMavenTwoProject(..) method in DefaultContinuum. We can derive the required parameters from the parent project. The metadata url can be gotten from the SCM url of the parent (since the SCM urls of modules are just constructed from the parent project's SCM url by inserting the module's name in the url). The group id can also be derived from the parent project, as well as the SCM username and SCM password. Then after the module is added and checked-out.. the project can just be added in the build queue so that it will be included in the triggered build. From the above implementation, I think we can recurse even through the modules if they are multi-module projects as well. What do you guys think? Any thoughts would be greatly appreciated :-) Thanks, Deng
Re: Proposition for CONTINUUM-798
On 11/07/2007, at 5:51 PM, Emmanuel Venisse wrote: Brett Porter a écrit : This sounds fine to me. Questions I think weren't answered here: - how do you track when the modules change - by comparing modules to the list of projects in a group? If so, how to handle the edge cases where extra projects are added to or removed from a group aside from the modules? - how do you handle the removal of a module from a POM when the project is still in Continuum? Will that just delete the project, and if so what happens to the build history, etc.? (sounds dangerous!) I don't think we should delete projects that are already in Continuum, it should be a manual opration done by a group admin. I agree - what I'm wondering is how the group admin knows to do so (for now, a simple email should probably suffice). - Brett
features scheduled after 1.1-beta-1
Hi, I haven't looked beyond this issue - so there may be more - but I see CONTINUUM-761 is a new feature scheduled for 1.1-beta-2. Shouldn't this be in beta-1, or a future version? - Brett
Heads up regarding VMBuild
Hi folks, I'm currently doing the rounds of all the people using Continuum on VMBuild. The set up on there ballooned despite the box being underpowered and the installation intended to be experimental, so was never very well maintained. We have a new box to move vmbuild to now and with the features in continuum 1.1 I think we can make a decent go at it. I was going to set up the next release (with profiles and 'single module build' support) and start setting up projects on there and maintain it properly. Hopefully we can get some additional feedback in to the 1.1 final release. Is anyone interested in helping out? Cheers, Brett
Re: continuum 1.1-beta-1 update
On 03/07/2007, at 5:54 AM, Emmanuel Venisse wrote: Jesse McConnell a écrit : Just to capture some talk on irc today... I think the strategy moving forward is going to be get some of jira cleaned up a la the recent maven jira push and continuum 1.1 is going to get wrapped up a bit for the first feature complete beta release very soon. I'll start to move some issues tomorrow. Versions will be 1.1-beta-1, 1.1, 1.x and maybe 2.X I'd go with: - 1.1-beta-1 - 1.1-beta-2 (I think we'll need at least this one, any beyond that we can add later) - 1.1 - 1.1.x (bugs that we accept won't be fixed in 1.1, but will be addressed before any feature releases) - Future. 1.1 should be empty or have very few bugs so that it's not a lot of changes happening close to release. Cheers, Brett
Re: Jetty proxy config required?
I believe you can use that configuration, but like you I never have, just pointing it directly at :8080 from httpd. On 01/07/2007, at 3:11 PM, Wendy Smoak wrote: Is the Jetty Configuration section on this page up to date? http://maven.apache.org/continuum/guides/mini/guide- configuration.html I don't have access at the moment, but I'm pretty sure I'm using Apache httpd and mod_proxy with ProxyPass and ProxyPassReverse without configuring anything at all in Continuum. -- Wendy
Re: svn commit: r546588 - in /maven/continuum/trunk: ./ continuum-data-management/data-management-cli/src/main/java/org/apache/maven/continuum/management/ continuum-data-management/data-management-jdo
On 13/06/2007, at 5:49 AM, Jason van Zyl wrote: On 12 Jun 07, at 11:37 AM 12 Jun 07, [EMAIL PROTECTED] wrote: Author: brett Date: Tue Jun 12 11:37:19 2007 New Revision: 546588 URL: http://svn.apache.org/viewvc?view=revrev=546588 Log: other aspect of CORE-3297 requires a patch to OID instead This the CORE I know? http://www.jpox.org/servlet/jira/browse/CORE-3297 - Brett
JDK 5 in Continuum
If my memory serves, we had decided we were ready to take this step for the applications, but not Maven itself until the toolchain support is final. Any objections? - Brett On 05/06/2007, at 2:32 AM, [EMAIL PROTECTED] wrote: Author: brett Date: Mon Jun 4 09:32:12 2007 New Revision: 544179 URL: http://svn.apache.org/viewvc?view=revrev=544179 Log: Start using JDK 5 for Continuum Modified: maven/continuum/trunk/pom.xml Modified: maven/continuum/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml? view=diffrev=544179r1=544178r2=544179 == --- maven/continuum/trunk/pom.xml (original) +++ maven/continuum/trunk/pom.xml Mon Jun 4 09:32:12 2007 @@ -65,6 +65,13 @@ pluginManagement plugins plugin + artifactIdmaven-compiler-plugin/artifactId + configuration +source1.5/source +target1.5/target + /configuration +/plugin +plugin artifactIdmaven-release-plugin/artifactId configuration tagBasehttps://svn.apache.org/repos/asf/maven/ continuum/tags/tagBase
Re: [VOTE] release continuum-1.1-alpha-2
+1.
Gave it a quick fire up on the Mac.
- Brett
On 31/05/2007, at 6:38 AM, Jesse McConnell wrote:
I would like to get alpha-2 released to the community now.
Highlights are:
revamped xml-rpc support
converted to use rebranded plexus-security, aka redback
continuum maven plugin
many bug fixes and ui improvements.
I have it staged at:
http://people.apache.org/~jmcconnell/continuum-1.1-alpha-2
If this vote passes, I will move the relevant tar and zip balls to the
following location like I did with the first alpha release.
http://people.apache.org/builds/maven/continuum/1.1-alpha-2
I'll also update the continuum wiki to point to the new alpha release
and get the continuum website updated with the information as well.
I'll also announce all this to the continuum users list. This will
hopefully be the last of the alpha releases followed by a beta release
in a month or so.
Normal voting rules, 72 hours, +1/0/-1
Below this is the jira release notes for this release.
Release Notes - Continuum - Version 1.1-alpha-2
** Bug
* [CONTINUUM-620] - Changes section in Continuum build result and
build e-mail only show blank columns and file names
* [CONTINUUM-684] - Access to Continuum using XML-RPC is not
authenticated.
* [CONTINUUM-1229] -
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Invalid default
value for 'SCM_USE_CACHE'
* [CONTINUUM-1269] - Recforing of the XMLRPC server, must be a
servlet on the same port used by the webapp instead of a specific port
* [CONTINUUM-1275] - Project Group Name that contains only spaces
can be added.
* [CONTINUUM-1276] - Error in editing the Project name using
spaces only
* [CONTINUUM-1282] - Adding or editing a Project Build Definition
can accept spaces in pom file name
* [CONTINUUM-1289] - Sorting Usernames in Build Management's
Project Group member list does not work in Firefox 2
* [CONTINUUM-1290] - Project ID is not validated when adding a
Project Group
* [CONTINUUM-1292] - Error when clicking build icon in Project
Build Definitions summary
* [CONTINUUM-1293] - Hitting 'Add' button repetitively in adding
an Ant, Shell and Schedule using empty string only accumulates
validation prompts
* [CONTINUUM-1294] - Adding a Schedule, Ant/ Shell Projects can
accept spaces
** Improvement
* [CONTINUUM-1035] - Dependent builds not triggered via XMLRPC
* [CONTINUUM-1186] - Application should unpack to continuum-$
{version}
* [CONTINUUM-1297] - update to redback from plexus-security
** New Feature
* [CONTINUUM-683] - Implement a ping service that XML-RPC
clients can use to test connection.
** Task
* [CONTINUUM-1242] - Update Continuum Model
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Allowing the file protocol in 1.1-alpha-1
I don't think it's possible to put it anywhere other than the webapp META-INF location at this point, without changing the way it's configured. - Brett On 20/05/2007, at 11:24 PM, Wendy Smoak wrote: In the FAQ [1] we say to uncomment an allowedScheme element in apps/continuum/conf/application.xml to allow use of the file:// protocol. However, the element doesn't exist there, and instead can only be found down in apps/continuum/webapp/WEB-INF/classes/META-INF/plexus/ application.xml . What is the correct way to allow the file:// protocol now? Copy the entire allowedSchemes section to conf/application.xml and edit it there? Should we move (or duplicate?) that section since it's something the user may be expected to edit? [1] http://maven.apache.org/continuum/faqs.html#can-i-use-file- protocol-in-add-project-view -- Wendy
Re: Allowing the file protocol in 1.1-alpha-1
That should be the webapp/continuum/conf/application.xml file that you can copy, not the one from META-INF. Unfortunately, because of the way the webapp integration currently works those files are split. Though, having said that, it may actually work as an override, so it's worth a try - I'm honestly not sure. - Brett On 21/05/2007, at 6:59 AM, Wendy Smoak wrote: On 5/20/07, Brett Porter [EMAIL PROTECTED] wrote: I don't think it's possible to put it anywhere other than the webapp META-INF location at this point, without changing the way it's configured. On the Deploying page on the wiki [1] there's a comment that You can also copy and edit this file in /path/to/continuum/conf/continuum/application.xml to keep the data separate from the installation That's why I thought copying the allowed schemes into a file in the 'conf' directory would work, though I see I got the path wrong in my original note. So, how does configuration work? (I need to make a checkbox elsewhere in the app configurable as well, so general info would be helpful here...) [1] http://docs.codehaus.org/display/CONTINUUMUSER/Deploying -- Wendy
Re: svn commit: r535724 - in /maven/continuum/trunk/continuum-webapp/src/main: java/org/apache/maven/continuum/web/bean/ProjectGroupUserBean.java webapp/WEB-INF/jsp/projectGroupMembers.jsp
Did you update this particular commit with svn pe --revprop -r535724 svn:log ? On 09/05/2007, at 7:40 PM, Maria Odea Ching wrote: Ok, I'll take note of that Trygve Laugstøl wrote: [EMAIL PROTECTED] wrote: Author: oching Date: Sun May 6 20:34:07 2007 New Revision: 535724 URL: http://svn.apache.org/viewvc?view=revrev=535724 Log: CONTINUUM-1256 Applied patch submitted by Teodoro Cue Can you please include some information about what changed when committing stuff? It's annoying having to go through the patch and/ or read the issue for smaller stuff. [snip] -- Trygve !DSPAM:602,4641b305257069182317745!
is alpha 1 really released?
I'm trying to find the official release, and I can only find the file in Jesse's home directory, and no announcement. Bit lost. Can we do these? - put in the main repo - put in /dist/ - put on the website - announce to lists / blogs Cheers, Brett
Re: is alpha 1 really released?
On 02/05/2007, at 4:10 PM, Jesse McConnell wrote: there was discussion on this on another thread on this list...but I will reiterate here that I feel uncomfortable shoving big war files and these alpha-1 artifacts into the main repository. No one is programming against these things in the main repository...we don't even publish incremental snapshots of continuum that I know of during development, so why shove all that stuff into the main repositories, especially for an alpha release...the final artifacts I am all for, but these alpha builds? I don't object, I just don't understand why it would be any different from every other alpha thing in the repository :) Personally, I see this as more of a milestone than an alpha release anyway. Anyway, I think we can at least put it in /dist/. It's just nicer for downloaders/infra that they get a mirror. as for updating the site, its on my list of things to do, but I haven't tackled it yet, it might only take me a few minutes, but then I haven't released a site at apache yet so...its on my list, just haven't gotten there yet. cool I am set to try and get some time on continuum soon and release an alpha-2 on May 21stmaybe we can make that one have more announcement bits.. yep, at least [EMAIL PROTECTED] (probably not [EMAIL PROTECTED]). - Brett
Re: DB schema migration
Hi Erik, Took a look at this - it's not actually the jpox tables (we don't use the pre-configured schema), but problems when we turn on autocreation: In an ALTER TABLE statement, the column 'INTEGER_IDX' has been specified as NOT NULL and either the DEFAULT clause was not specified or was specified as DEFAULT NULL. we also have (which is probably because of our metadata): In an ALTER TABLE statement, the column 'CHANGEDATE' has been specified as NOT NULL and either the DEFAULT clause was not specified or was specified as DEFAULT NULL. So I think I'm going to do the migration tool. - Brett On 24/04/2007, at 7:35 AM, Erik Bengtson wrote: Quoting Brett Porter [EMAIL PROTECTED]: Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. If you mean by private tables the JPOX_TABLES, you can drop it and JPOX will automatically recreate if it's needed.
Re: DB schema migration
Thanks Erik - I'll give that a try ASAP. On 24/04/2007, at 7:35 AM, Erik Bengtson wrote: Quoting Brett Porter [EMAIL PROTECTED]: Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. If you mean by private tables the JPOX_TABLES, you can drop it and JPOX will automatically recreate if it's needed.
Re: DB schema migration
This was one of the things I was going to try and have done before alpha-1 - I just forgot. Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. I already have the tools to do an xml export of the old tables, it just needs to somehow be set to run in dump mode using the old jpox, and import using the new one. I'll look at that during ApacheCon, I think. If anyone else wants to take the task while I'm on holidays, let me know... we should also make the tool work with 1.0.3 databases if possible. This is definitely one for the release notes, btw. alpha-1 will not work with 1.0.3 (or earlier 1.1 snapshot) databases. - Brett On 22/04/2007, at 2:10 PM, Erik Bengtson wrote: If you guys need some tooling from JPOX, let me know and I could plan to implement some kind of export to XML, and import from XML. In between export/import you could apply Xqueries to transform data to match the new schema Quoting Stephane Nicoll [EMAIL PROTECTED]: Hi, I'm currently running a 1.1-SNAPSHOT from February which runs ok except a few minor issues. I'd like to upgrade to 1.1 alpha 1 as soon as it's out to provide feedback co. Last time I tried to upgrade, I had to revert because the model schema has changed and it was really difficult to update my existing data. Is there something scheduled for alpha1 regarding this (at least a manual procedure to upgrade my schema if necessary). Thanks, Stéphane
Re: DB schema migration
The problems Stephane has is because of the JPOX upgrade, not the schema changes we've made. I'm not saying it won't be possible to migrate from 1.0.3, it just won't come out of the box (or necessarily be ready by the time the release goes out). - Brett On 23/04/2007, at 9:00 PM, Jesse McConnell wrote: any remaining changes in 1.1 will at _most_ be additive in the form of a boolean value here or there for some improvement, there should be no more changing of column names or anything of that ilk...Those were taken care of in one fel swoop when we fixed things up to remove potential DB keyword conflicts jesse On 4/23/07, Stephane Nicoll [EMAIL PROTECTED] wrote: Can I be sure at least that the DB model won't change as from alpha-1? If so I can maybe drop completely my database and recreate my projects. Thanks, Stéphane On 4/23/07, Brett Porter [EMAIL PROTECTED] wrote: This was one of the things I was going to try and have done before alpha-1 - I just forgot. Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. I already have the tools to do an xml export of the old tables, it just needs to somehow be set to run in dump mode using the old jpox, and import using the new one. I'll look at that during ApacheCon, I think. If anyone else wants to take the task while I'm on holidays, let me know... we should also make the tool work with 1.0.3 databases if possible. This is definitely one for the release notes, btw. alpha-1 will not work with 1.0.3 (or earlier 1.1 snapshot) databases. - Brett On 22/04/2007, at 2:10 PM, Erik Bengtson wrote: If you guys need some tooling from JPOX, let me know and I could plan to implement some kind of export to XML, and import from XML. In between export/import you could apply Xqueries to transform data to match the new schema Quoting Stephane Nicoll [EMAIL PROTECTED]: Hi, I'm currently running a 1.1-SNAPSHOT from February which runs ok except a few minor issues. I'd like to upgrade to 1.1 alpha 1 as soon as it's out to provide feedback co. Last time I tried to upgrade, I had to revert because the model schema has changed and it was really difficult to update my existing data. Is there something scheduled for alpha1 regarding this (at least a manual procedure to upgrade my schema if necessary). Thanks, Stéphane -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. It is a pain, but having said that we could potentially add it in a later milestone. I wouldn't want a final version without it. anyone have anything to add? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Poll: release continuum alpha
Agreed. Someone needs to: - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. On 24/02/2007, at 8:26 PM, Stephane Nicoll wrote: On 2/23/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: A milestone should focus on showing the fancy new features and bugs fixed. Stuff like security, upgrading existing databases etc are all secondary. I understand what you mean but I think database upgrade is very important because users will want to test continuum 1.1 with their data. This first release will also give you a chance to test your upgrade procedure. Stephane This will give the community the ability to check in on the latest development and make sure that the developers don't stray too far away from what the users actually need. [+1/0/-1] I though you said that this wasn't a vote? ;) Thanks a whole lot for listening to me and taking the time to do this Jesse. I am very interested in getting 1.1 (or 1.0.4 if it has to be) out the door and can hopefully do some work for you guys. -- Trygve
Re: Poll: release continuum alpha
I agree with an alpha-1 labelled release. I think someone will need to flush JIRA before cutting the release (close things that are no longer relevant, or fixed, or duplicate). - Brett On 24/02/2007, at 8:35 AM, Jesse McConnell wrote: I was talking to trygve a bit on irc and it dovetailed nicely with some plans I had talked about late last year in regard to continuum...I am just about a month late is all. We thought we ought to take a poll on here about continuum and see what folks thought. This is not a vote, its just a poll and perhaps a discussion starter on short to mid term plans with continuum. I just know it bothers me a bit everytime someone pops on IRC and asks questions about continuum 1.0.3...which is quite aged atm with so many of the bugs on it resolved on the trunk. Question: Should we take all the work that has been done on continuum in the last year+ and get it pushed out as an Alpha1 or a Milestone1 or some suitable equivalent? [+1/0/-1] jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: oching, please subscribe to [EMAIL PROTECTED]
Actually, it's continuum-commits. However, I already did the -allow thing in case she was subscribed under a different address. On 20/02/2007, at 5:44 PM, Trygve Laugstøl wrote: your commit emails are beeing moderated. -- Trygve
Re: svn commit: r509415 [1/3] - in /maven/continuum/trunk: continuum-security/src/main/java/org/apache/maven/continuum/security/p rofile/ continuum-webapp/src/main/java/org/apache/maven/continuum/we
Can you do svn propedit svn:log -r509415 --revprop And add that to the front? - Brett On 20/02/2007, at 8:38 PM, [EMAIL PROTECTED] wrote: Hi Wendy, This is for CONTINUUM-1147 Thanks, Deng On 2/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: oching Date: Mon Feb 19 18:41:37 2007 New Revision: 509415 URL: http://svn.apache.org/viewvc?view=revrev=509415 Log: Added isAuthorized* methods in ContinuumActionSupport for checking authorization in action classes with different permissions. Implemented SecureAction in some of the action classes that has a specific permission. Also added 'modify-project-notifier' operation in ProjectDeveloperDynamicRoleProfile. Is there a JIRA issue for this? -- Wendy
Moving configuration service to plexus-registry
Any objections to me moving the configuration service out of the database (and take some of the bits out of application.xml) and putting them in the registry? Basically the same thing I've just done for Archiva. Docs on the registry are here: https://svn.codehaus.org/plexus/plexus- sandbox/trunk/plexus-components/plexus-registry/src/site/apt/index.apt Cheers, Brett
Re: Trusting in our own dog food
Worth investigating - though I'd prefer we move to a trigger rather than poll based build if we can, and move the poll to daily in case a trigger gets missed. Also, remember not all SCMs support this (eg, CVS). - Brett On 16/01/2007, at 12:54 AM, Emmanuel Venisse wrote: I think we need to change the changes check. Actually, we do an update on all projects to check if we have changes. It will be better to use the status command (I don't know if this command exist in all SCM), but with svn, we'll can use 'svn status -u' I think the changes check will improve performance when working copy is up-to-date Emmanuel Brett Porter a écrit : That doesn't actually matter for the client side speed boost. I'm running 1.4.2 on continuum now. - Brett On 15/01/2007, at 2:21 PM, Brian E. Fox wrote: The svn.apache.org server is a little old too: Powered by Subversion version 1.3.1 (r19032). -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, January 14, 2007 6:46 PM To: continuum-dev@maven.apache.org Subject: Re: Trusting in our own dog food yeah, it's subversion 1.1.4 (ouch!). I'm going to look at upgrading! On 11/01/2007, at 11:27 PM, Federico Yankelevich wrote: I read on svn changelog that SVN v1.4 increased a lot the speed for comparing local copy with repository. Maybe continuum is very slow in SVN update because it is using SVN 1.3 (both client and server needs to be updated) see http://subversion.tigris.org/svn_1.4_releasenotes.html just my 2 cents, Federico brettporter wrote: Yes, I have a script to automate installing the latest build (though would need changes if continuum_ci was turned off). 1.1 is running very well thanks to some sleuthing by Wendy and quick fixes from Emmanuel. My biggest concern is the scalability of polling. It currently takes about 30 minutes to just run through all the required svn up commands to detect if builds are needed for all the Maven projects. - Brett On 11/01/2007, at 10:26 AM, Arnaud HERITIER wrote: good luck ;-) did you update the 2.1 snapshot ? Arnaud On 1/11/07, Brett Porter [EMAIL PROTECTED] wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? - Brett -- View this message in context: http://www.nabble.com/Trusting-in- our- own-dog-food-tf2955860.html#a8276485 Sent from the Continuum - Dev mailing list archive at Nabble.com.
Re: Trusting in our own dog food
Ok, fair enough. I've left it on, and made it use a different local repository. I'd say once we release Continuum 1.1 and are happy it is stable enough to use, we can turn this off. On 15/01/2007, at 11:02 PM, Trygve Laugstøl wrote: Brett Porter wrote: so... you're saying you don't trust our dog food? :) No, I'm saying it's there to verify the dog food. If there is no discrepancies between what the cron is saying and the C instance is saying, it's good. If there is an discrepancy it's not good. It will be more a tool to verification tool that a CI (but that might be two sides of the same story :) -- Trygve The only thing it tests differently is: - works by cron, whereas continuum might go down/hang/something else (which is something we should work on fixing if it does, rather than rely on ci.sh) - runs a reactor (can add that as a less frequent build execution in continuum too, though). So, I don't see any reason to keep it - wdyt? - Brett On 11/01/2007, at 7:57 PM, Trygve Laugstøl wrote: Brett Porter wrote: Folks, I'd like to turn off continuum_ci.sh and instead only use Continuum itself to do CI for Continuum. Any objections? I don't see why it should be turned off, but perhaps the automatic notifications can be turned off or just send failures. That way it would verify the product (it will in itself be an integration test) because if the Continuum instance says that something is failing, you should expect an email saying the same right after. Or at least you can check the logs directory if you're suspecting some other failure. -- Trygve
Re: Continuum and svn connections
I saw it yesterday too. I actually had the problem before svn kicked in, as far as I could tell. ie, retrieving POMs might be the problem. On 06/01/2007, at 9:30 AM, Wendy Smoak wrote: The ASF Subversion server limits connections to 10 per IP address, and with several ASF projects loaded up, Continuum is regularly exceeding this limit. I'm not sure if it's just opening too many, or if they aren't getting closed properly, or what, but it ends up meaning that I can't connect to svn from anything here until they time or or otherwise go away. Typically, I see 10 connections in CLOSE_WAIT and one in SYN_SENT. I've had two versions of Continuum running all week, and this just started today (with r493025.) -- Wendy
Re: CONTINUUM-798: module discovery
fair enough, as long as we have sensible, pre-emptive error messages (perhaps just a warning that module X was ignored due to invalid path). On 04/01/2007, at 12:57 AM, Emmanuel Venisse wrote: Yes, we can use, it seems to be good but it won't work for modules with a relative path like ../mymodule Emmanuel Brett Porter a écrit : Great - can the patch be used as a starting point? On 03/01/2007, at 2:27 AM, Emmanuel Venisse wrote: Brett Porter a écrit : Hi Jesse, I see you took this one a couple of months ago. It looks like a good feature - is the patch a good enough start to use for now? It was submitted by John Didion - John, are you hanging around? Are you able to help get that applied and work through some of the limitations? I'm pretty keen to see this one land :) Me too, and it will be fix CONTINUUM-1098 Emmanuel
Re: CONTINUUM-798: module discovery
Great - can the patch be used as a starting point? On 03/01/2007, at 2:27 AM, Emmanuel Venisse wrote: Brett Porter a écrit : Hi Jesse, I see you took this one a couple of months ago. It looks like a good feature - is the patch a good enough start to use for now? It was submitted by John Didion - John, are you hanging around? Are you able to help get that applied and work through some of the limitations? I'm pretty keen to see this one land :) Me too, and it will be fix CONTINUUM-1098 Emmanuel
Re: selenium tests
Only on clean - which you want to do to clean out the database, etc but not the container install. I would rather the cargo plugin used the maven repository, myself :) - Brett On 29/12/2006, at 6:22 PM, Rahul Thakur wrote: The container shouldn't be downloaded everytime by default. But I agree perhaps another temp location is a better candidate for setting up container installation - may be 'target' directory under top level root? Rahul - Original Message - From: Brett Porter [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 29, 2006 6:56 PM Subject: Re: selenium tests 8) store the cargo container installs somewhere other than target, so I can run clean tests without the massive download. On 28/12/2006, at 12:51 PM, Franz Allan Valencia See wrote: On 12/27/06, Brett Porter [EMAIL PROTECTED] wrote: 6) we should use dbunit or something similar to set the database up into a consistent state for the respective tests, and tear it down again. Running through the web interface in tearDown is time consuming, and error prone (if you add a new test that doesn't tear itself down, then a different test fails). On 27/12/2006, at 3:57 PM, Brett Porter wrote: see below On 27/12/2006, at 3:09 PM, Brett Porter wrote: On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding todos in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to user authenticated assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look later. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus-security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett 5) the continuum tearDown should not swallow exceptions (retthrow them, but that means changing the abstract selenium test case to throw it too) 7.) Switch to Tomcat 5.5.17 to support the email validations ( a bug in 5.5.20 prohibits that ).
Re: short term branch for project/group keys
Yes, it's fetch groups. The store (pre-groups) took all this into account, however the lack of central management for some of it caused it to be pretty error prone. Those problems were related to Continuum's design, not anything to do with the use of JPOX (and something that'd be encountered in iBatis, or JPA, or anything else we used). On 28/12/2006, at 7:33 PM, Rahul Thakur wrote: On 27/12/2006, at 7:10 PM, Rahul Thakur wrote: Updates to any children hanging off key entities should cascade. This makes sense if and only if the children are dependent. So, for build definitions - that's right. Profiles and such are all 'links' and so will be managed by the normal foreign key construct. Thanks Brett! I might need some help with Jpox when I hit this scenario. It would be nice to have some sort of 'lazy' intialization to happen when children hanging off key entities are retrieved, but not sure yet what Jpox offers (fetch groups?). Cheers, Rahul
selenium tests
Hi, A few observations on these. Does anyone else have outstanding todos in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to user authenticated assertions failing. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett
Re: selenium tests
On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding todos in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to user authenticated assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett
Re: selenium tests
see below On 27/12/2006, at 3:09 PM, Brett Porter wrote: On 27/12/2006, at 2:08 PM, Brett Porter wrote: Hi, A few observations on these. Does anyone else have outstanding todos in this area? Would like to gatehr them up and get them resolved to make them useful. 1) these need to be run regularly to be really useful. They aren't part of the main build ( a good idea, since it requires a UI and takes forever). Is there a way to run them in rhino so we can run them as part of the main build and then turn on the other profiles when we have mutliple platforms to test on? 2) they currently all fail - Franz says it's due to UI changes we haven't caught up to. See #1 :) Are the UI changes abstracted sufficiently that this will be a quick fix, or is it going to a be a big search and replace job? They fail due to user authenticated assertions failing. Fixed the fundamental problem, now it's just UI changes. Down to 14 :) Down to 5 (AccountSecurityTest, ProjectGroupTest). I'll look later. 3) Is there a way to get it to stop after a certain number of failures? 39 open firefox browser instances caused my mac to kernel panic. 4) I underestand that the plexus-security related tests are shared across both webapps. Should we put some helper code into plexus- security that can be used by these tests so that changes there can be addressed there (preferably using the example webapp)? I think this is the list of things to get done - I can put them in JIRA if there isn't anything extra or anything I've missed in the list. - brett 5) the continuum tearDown should not swallow exceptions (retthrow them, but that means changing the abstract selenium test case to throw it too)
Re: short term branch for project/group keys
On 23/12/2006, at 12:24 AM, Jesse McConnell wrote: the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. Ok, so a project(Group)? will have: id : int key : String name : String ... Where key is used as a reference, id is used as a datastore/model identity, and name is used as a display. Sounds good. We could then have a table of old names: id : int oldKey : String These could be used so that failed lookup on a key could then look in the old key's to find out what the new one is (like when you move an issue in JIRA). I'm not sure this is needed initially - only if we support picking up renames to the project itself. I suggest that a project should, by default, use the Maven group ID and artifact Id as the group key and project key respectively. Obviously, for Ant/Shell/etc, this will need to be entered by hand. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Cool. We could also do nice things with the URLs using a WW mapper: /continuum/org.apache.maven/maven-project/buildHistory Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation For now sounds good (would like to review immutability later), though suggest using Maven IDs where possible. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. Sounds good. I'm not sure how often you really need to reference a schedule or build definition (or how you'd really appropriately describe them). We don't want to go to the point where you have to make up extra information that is not useful. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Whoa. Repeat the mantra - convention over configuration :) One of the great strengths of Continuum is that it takes its defaults from Maven. Sure, they can be changeable, but they *must* be the default. That's not a mess. As for multiple branches - I'm not convinced either way yet. I Can see the merits in your example of simply making them new projects, but then they need to be reconfigured (often in the same way). On the other hand, it could be that branches should be a subsection of the project, not an additional project. The hierachy would be group project branch/instance. Notifiers and build definitions would be attached to the group or the project, and can be excluded from a given branch/instance if not used there. Let's discuss that separately as it's obviously new functionality, whereas loading them up as new projects is a workable current solution. If we take the defaults, all that means is that adding a second one should complain, and you need to edit the key. No big deal. - Brett
Re: short term branch for project/group keys
Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED]
