Re: ContinuumStore refactoring
I'll create some examples asap. Emmanuel On Thu, Feb 28, 2008 at 4:07 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, Some code using a couple of Entities as examples would be nice :-) I still think the API would be verbose. Thanks, Rahul On Fri, Feb 22, 2008 at 11:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] wrote: 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. I don't want to see a new time a big class for the store part. it must be splitted in few domains. All named queries related to Project would be defined in the Project class, all named queries related to ProjectGroup would be defined in the ProjectGroup class... And we can add some more classes for particular results that aren't entities objects (we won't have a lot) With this, all concerns are separated and linked to a specific entity. Easy to code, easy to read, easy to understand. It's my opinion. Sorry, still not convinced ;-) I hope you are now ;-) Emmanuel Rahul
Re: CI Server Poll
thx Rahul for this link. We are #2 now :) On Thu, Feb 28, 2008 at 4:51 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, Any one seen this: http://www.wakaleo.com/polls/18-what-continuous-integration-server-are-you-using-in-2008 Another 5 steps to get to #1 :-) Rahul
Re: svn commit: r632127 - /maven/continuum/branches/continuum-1.x/pom.xml
yes, it is an error.
Emmanuel
On Thu, Feb 28, 2008 at 11:13 PM, Brett Porter [EMAIL PROTECTED] wrote:
The users one seems to be missing the users. prefix in both - is there
a reason for that?
- Brett
On 29/02/2008, at 8:58 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Thu Feb 28 13:58:44 2008
New Revision: 632127
URL: http://svn.apache.org/viewvc?rev=632127view=rev
Log:
Update markmail addresses
Modified:
maven/continuum/branches/continuum-1.x/pom.xml
Modified: maven/continuum/branches/continuum-1.x/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/branches/continuum-1.x/pom.xml?rev=632127r1=632126r2=632127view=diff
=
=
=
=
=
=
=
=
==
--- maven/continuum/branches/continuum-1.x/pom.xml (original)
+++ maven/continuum/branches/continuum-1.x/pom.xml Thu Feb 28
13:58:44 2008
@@ -41,22 +41,48 @@
inceptionYear2003/inceptionYear
mailingLists
mailingList
- nameContinuum Dev List/name
- subscribe[EMAIL PROTECTED]/subscribe
- unsubscribe[EMAIL PROTECTED]/
unsubscribe
- archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
-/mailingList
-mailingList
nameContinuum User List/name
+ post[EMAIL PROTECTED]/post
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-users/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchive
http://www.nabble.com/Continuum---Users-f13868.html
/otherArchive
+otherArchivehttp://continuum.markmail.org//otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Developer List/name
+ postcontinuum-dev@maven.apache.org/post
+ subscribe[EMAIL PROTECTED]/subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-dev/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/continuum-dev@maven.apache.org
/otherArchive
+otherArchivehttp://www.nabble.com/Continuum---Dev-f13867.html
/otherArchive
+otherArchivehttp://dev.continuum.markmail.org//
otherArchive
+ /otherArchives
/mailingList
mailingList
- nameContinuum Commit List/name
+ nameContinuum Commits List/name
subscribe[EMAIL PROTECTED]/
subscribe
unsubscribe[EMAIL PROTECTED]/
unsubscribe
archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-commits/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchivehttp://maven.continuum.commits.markmail.org//
otherArchive
+ /otherArchives
+/mailingList
+mailingList
+ nameContinuum Issues List/name
+ subscribe[EMAIL PROTECTED]/
subscribe
+ unsubscribe[EMAIL PROTECTED]/
unsubscribe
+ archive
http://mail-archives.apache.org/mod_mbox/maven-continuum-issues/
/archive
+ otherArchives
+otherArchive
http://www.mail-archive.com/[EMAIL PROTECTED]
/otherArchive
+otherArchive
http://www.nabble.com/Continuum---Issues-f29618.html
/otherArchive
+ /otherArchives
/mailingList
/mailingLists
scm
@@ -781,6 +807,11 @@
groupIdorg.codehaus.plexus.redback/groupId
artifactIdredback-data-management/artifactId
version${redback.version}/version
+ /dependency
+ dependency
+groupIdcommons-httpclient/groupId
+artifactIdcommons-httpclient/artifactId
+version3.1/version
/dependency
/dependencies
/dependencyManagement
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
Thanks Brett. Emmanuel On Thu, Feb 28, 2008 at 11:27 PM, Brett Porter [EMAIL PROTECTED] wrote: This has been done (and switch works just fine). No other changes should be needed on your end. - Brett On 26/02/2008, at 12:02 PM, Wendy Smoak wrote: On Mon, Feb 25, 2008 at 4:39 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. If you have local changes you don't want to commit, I think 'svn switch' will work afterwards to point an existing working copy at a new url. -- Wendy -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
why 1.1.x? On Thu, Feb 28, 2008 at 11:45 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Confused about the branches
On Thu, Feb 28, 2008 at 11:55 PM, Brett Porter [EMAIL PROTECTED] wrote: On 29/02/2008, at 9:52 AM, Emmanuel Venisse wrote: why 1.1.x? in case there was a bugfix release on 1.1? I thought that was what the branch was for... maintenance of 1.1. or is there going to be 2 completely different strands of development? I thought to do 1.x in the branch instead of only maintenance in 1.1.xbecause I don't know how many time we'll need for the first 2.0 release. User will probably need some new small feature before the 2.0release and not only maintenance. - Brett On Thu, Feb 28, 2008 at 11:45 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, I'm a bit confused about the current branch scenarios, we have 1.2 on a branch and 2.0 on trunk. Several changes have been made on each, and none merged to the other. Can I suggest we merge all branch changes to trunk, rename trunk to 1.2-SNAPSHOT, and the branch to continuum-1.1.x (1.1.1-SNAPSHOT) and use that for bugfixes only? WDYT? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
svn move (was: Re: Apache Continuum is now an Apache top level project)
I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. Brett, when will can you do the move? Emmanuel On Thu, Feb 21, 2008 at 12:10 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi Emmanuel, These are the incubator graduation steps and they mostly seem to apply here too: http://incubator.apache.org/guides/graduation.html#life-after-graduation . Many of them are for you to do directly. I've filed the infrastructure issue (INFRA-1532) and placed you in the chairs group already. Cheers, Brett On 21/02/2008, at 8:30 AM, Emmanuel Venisse wrote: Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn move (was: Re: Apache Continuum is now an Apache top level project)
On Tue, Feb 26, 2008 at 12:47 AM, Brett Porter [EMAIL PROTECTED] wrote: On 26/02/2008, at 10:39 AM, Emmanuel Venisse wrote: I created the svn group with all pmc members. The next step will be the svn move to the new location. I'd like to see the move done for the end of the week, so if you have some changes to commit, you must do it asap. Brett, when will can you do the move? I'll lock it in for Friday morning here (about 3 days from now): http://timeanddate.com/worldclock/fixedtime.html?month=2day=29year=2008hour=8min=0sec=0p1=240 Thanks. Emmanuel
Re: ContinuumStore refactoring
As I already explained, I'm in favor of named queries On Fri, Feb 22, 2008 at 2:54 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, I'd like to go ahead and pick up something towards the next Continuum iteration. I am thinking refactoring ContinuumStore interface as was earlier discussed on this list and as I did on the 'continuum-jpa' branch. To this end, I need to get a clear picture on a few items: 1) Which JPA provider are we going ahead with then? I'd like to start with toplink provider. 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. 3) Using Criteria Queries would mean that we use JPA extensions specific to provider. I don't see this as an issue as long as we are not expecting underlying JPA providers to be swapped. Thoughts? Continuum isn't a big application and I don't think we need provider extensions for now. Before to start the code, I'd like to see a DB model exported to an image so we'll can include it in the site. We must define too which datas will stay in the db and which datas will be externalized in some files. Look forward to hear. Cheers, Rahul
Re: ContinuumStore refactoring
On Fri, Feb 22, 2008 at 10:45 AM, Rahul Thakur [EMAIL PROTECTED] wrote: 2) Criteria vs Named Queries: I am not convinced (yet) that Named queries are the way to go. I did some digging around, they are indeed best practices for JPA but I think the decision merits other consideration(s). I still believe the Criteria Queries will help us define a cleaner Store interface. I'm always in favor of named queries. An other point about them that I haven't explain in previous threads (I think) is that with named queries, it is possible to modify queries externally with xml files so if with a DB we have some performance issues, it will be possible to override queries by a modified JPQL query or a native query. How do you see the refactored ContinuumStore interface using Named Queries? I suspect it will be just as verbose again. I don't want to see a new time a big class for the store part. it must be splitted in few domains. All named queries related to Project would be defined in the Project class, all named queries related to ProjectGroup would be defined in the ProjectGroup class... And we can add some more classes for particular results that aren't entities objects (we won't have a lot) With this, all concerns are separated and linked to a specific entity. Easy to code, easy to read, easy to understand. It's my opinion. Sorry, still not convinced ;-) I hope you are now ;-) Emmanuel Rahul
Re: [Discussion] Continuum 2.0 Roadmap
Thanks Rahul. Emmanuel On Feb 20, 2008 4:44 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, I have re-organised and updated content related to Continuum 2.0 Roadmap here: http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0+Roadmap Would appreciate if others can review/update/comment as appropriate. Also, I think we start cutting out concrete JIRA tasks from those umbrella issues listed on that page above and assign them fix versions. Thanks, Rahul Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel
Re: Apache Continuum is now an Apache top level project
Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
Thanks Brett. I'm +1 to open it. Emmanuel On Feb 13, 2008 8:43 AM, Brett Porter [EMAIL PROTECTED] wrote: no, permissions changes are non-destructive :) On 13/02/2008, at 6:33 PM, Rahul Thakur wrote: +1 as long as editing it requires a login :-) Should I hold off the migration from Codehaus? Rahul On Feb 13, 2008 6:32 PM, Brett Porter [EMAIL PROTECTED] wrote: On 13/02/2008, at 4:04 PM, Wendy Smoak wrote: On Feb 12, 2008 10:01 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, I've created two wiki's: ... http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index (exported to: http://cwiki.apache.org/CONTINUUMDEV/) This one is editable by developers only (accepts comments from anyone). This is for the roadmap and design docs. I only granted access to a few people that I could easily find - if you need to edit, just let me or a confluence admin know. Why would we not want to allow the community to participate in roadmap and design docs? The only reason I can think of to restrict access is to make sure we have a CLA for content we intend to redistribute. Both good points - I was following what we had in Maven already - what do others think - shall we just open it up? Or do we not even need the DEV space? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: [Discussion] Continuum 2.0 Roadmap
On Jan 30, 2008 9:05 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Hi, Great to see version 2.0 discussions kicking off! Thanks for putting the ideas on confluence, Emmanuel. :-) Some notes around the ideas outlined on the wiki: 1) Architecture Moving to JSE 5 and JPA is a good idea \o/, it been fairly overdue ;-). 1-1)Can you please elaborate a bit on relationships among - services, various types of facades and entities. A concrete example would help. All the code will be in some services classes like builder service or entity modifier service. Facades will be the front-end for a specific technology like an EJB, a web service or something. The facade will delegate client calls to the service and doesn't do more. 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I don't think. I don't see the interest to look at it for Continuum. We already use Plexus that works fine, and if we decide to move to something else, it should be for the interest of the project and features we don't have in Continuum. But maybe you have some arguments about Guice. 2) Database I am not hard and fast on any particular JPA provider. If Toplink cuts it, we should go with it. I have been toying around with OpenJPA, but I haven't used Toplink to comment on how both compare. OpenJPA is comprehensively documented and has a good support available on mailing lists. Having said that, JPA providers would ultimately be swap'able under the hood. I don't have something to compare too. Also, I think we should stick with JPA annotations on model entities instead of using Modello. I hope writing the data access code from scratch implies the current ContinuumStore will be refactored into something which is less verbose than what we have currently, and so would the Continuum interface. I'm totally agree. We must decide too which datas are kept into the database and which datas will move to some XML files. I think some datas should be stored in XML files because we don't use them for requests and they are rarely accessed, like scm files list. About entities, we need to review the object model because some fields like scm fields in Project aren't in a good place, they should be in a sub-object even if we keep the actual db schema. 3) Builders Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. I think the thing we have actually with project group that contains build definitions/notifiers is similar to your thoughts We'll can see later if we need to change the actual model. 4) Remote Builders I like this idea, but not sure how the build results will be aggregated from remote builders, but may be that is something that needs some more thought. I'll add more text about it 5) Plugins Is this similar to what AntHill Pro has? Are we going to have a notion of Build lifecycle (and phases) to support this? Is this something that can be borrowed in concept (and possibly implementation) from Maven? I don't know yet, all ideas are welcome about the design 6) External Access and UI improvements I am +1 for supporting different types of mechanisms to access and control Continuum. Web interface has been the primary interface until now and I totally agree that it needs to be improved to give a better user experience. I welcome the idea of using GWT for this. I am keen to focus more on Reporting as well for this version. As already outlined on the wiki, it would be nice if the reporting can be extended via plugins or some such mechanism. yep. 7) Documentation I would like to add and emphasize here on documenting the code itself as we write it. We are not going to get down to user documentation from day one but there will be users in the community who start consuming the code and contributing back as soon as we starting cooking it! :-) I would like to propose having Checkstyle to flag undocumented source code in codebase. I'm agree about the code documentation. Can you add it in the wiki? 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm agree. Thanks, Rahul Thanks for your comments, Emmanuel Emmanuel Venisse wrote: Hi I started a document [1] with my ideas about
Re: profile and projects/build definitions
A profile can't be applied to a project because generally, users want to build their projects for different environment. Maybe, we'll add a defaut project profile in future versions that can be overriden in the build definition Emmanuel On Jan 25, 2008 11:31 AM, Benoit Decherf [EMAIL PROTECTED] wrote: Hi I m' working on http://jira.codehaus.org/browse/CONTINUUM-1633 because it's blocker for us. I think that some other bugs on continuum release should be corrected if the release process is externalized to mvn. But there is a problem with CONTINUUM-1572 http://jira.codehaus.org/browse/CONTINUUM-1572. Actually, the profile is associated to a build definition. But the jdk version to use or the maven version should be associated to the component, don't you think ? I don't want to modify the core of continuum so have you plane to make a refactoring of the profile usage ? Or why a profile isn't associated to the project (or project group) ? Benoit
Re: Some continuum-jpa branch updates
On Jan 22, 2008 3:06 AM, Rahul Thakur [EMAIL PROTECTED] wrote: A Query object that wraps up criteria and is built programmatically affords us the ability to keep Store APIs lean and stable. That is the motivation behind building up queries programatically. IMHO, the current ContinuumStore is a bunch of methods that don't even vary that much underneath. I think the same can be easily achieved by using Query. With named queries, queries are cached in the persistence context so they don't need to be parsed each time. With named queries, an other good thing is that they can be overriden in the xml file if needed for performance for a specific DB and we can add query hints. The last thing is that with named queries, we know exactly which requests we execute so we can optimize the DB schema with some index, it isn't easy to do with dynamic queries. I don't say we won't use dynamic queries but only that it must be the majority of our requests and it's a JPA best practices. I am not sure if StringBuilder will be more performant than StringBuffer when you are concatenating only a few Strings. I think what is more important is a goal of a lean, test'able and clean API. It isn't important for a concatenation of few strings, but in your code, you do it in the Query generator. The concatenation will executed a lot because we execute lot of requests in all pages, so the benefit of StringBuilder is very important. I can't really comment on named queries (probably need to toy around with them a bit), and not sure how the implementation would end up making use of named queries, but if anyone else has any opinions, I am keen to understand. Cheers, Rahul Emmanuel Venisse wrote: As Christian said, named queries are pre-compiled to SQL. With dynamic queries, perf can be not good because for each execution, the JPQL request is recompile to SQL, so parsing, creation of the JPQL tree then SQL generation, and with your solution, you concatenate lot of String. It isn't important for one request but with lot of request, you use more time and cpu, for string concatenation, it is better to use StringBuilder that is more performant than String addition or StringBuffer. An other argument for named queries is that with dynamic queries, if they aren't written correctly (it isn't the case for your code ;) ), it is easy to introduce some malicious SQL code with parameters my two cents. Emmanuel On Jan 18, 2008 9:57 PM, Christian Edward Gruber[EMAIL PROTECTED] wrote: You can get some benefit from named queries in terms of query pre- compilation and caching on the underlying database. However, most database flavors and hibernate providers turn criteria queries into named queries (parameterized SQL) which is then cached, so, on the surface I suspect the performance characteristics will be similar. Christian. On 18-Jan-08, at 14:35 , Rahul Thakur wrote: Thanks Emmanuel! Responses inlined... Emmanuel Venisse wrote: Hi Rahul, After few days to look at JPA, I'm sure now it would be good to use it instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA). The code is very easy to write and to read with JPA. About your continuum-jpa branch, I have few remarks: - I don't think it's good to use directly some OpenJPA APIs. If possible, I'd prefer to use only standard JPA APIs so we'll can choose later the implementation we want to use (OpenJPA, TopLink, JPOX...) Agree. The only place where OpenJPA APIs are being used directly currently are the unit tests. - why do you use some Spring code? Experimental. Spring has a good transaction management framework out of the box. - we don't need to store the model encoding (CommonUpdatableModelEntity class) Sure. Easily fix'able. :-) - can you explain dateCreated/dateUpdated fields? How are they managed? These are for audit puposes, and can be used as range search query criteria for fetching entities. These were an extension I thought will be good. 'dateCreated' gets set when an entity is first inserted into the underlying store, subsequent updates update the 'dateUpdated'. - all the model is fectched eagerly and it isn't acceptable for performance Yes, the model does needs review and tweaks to annotations where we know we don't need to fetch 'eagerly'. - I'm not sure your Query pattern is good. I'd prefer to use named queries but maybe you have a reason I think using a Query like we have on the JPA branch nicely provides for a flexible construction of queries (i.e, only the criteria passed in contributes to the query). I am not sure if such is available with named queries; but I am interested to know why named queries might be better. Cheers, Rahul That's all for the moment. Emmanuel On Jan 16, 2008 11:30 PM, Rahul Thakur [EMAIL PROTECTED] wrote: Just wondering
Re: Continuum update
The continuuum-1.x is created Emmanuel On Jan 21, 2008 11:08 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, I'll probably create a new branch for 1.x dev and will reserve the trunk for 2.x dev. I think I'll do it this week or the next (if you're agree, of course :) ) I'll try to send at the same time my ideas for 2.x so we'll can discuss about them. Emmanuel
Re: Some continuum-jpa branch updates
As Christian said, named queries are pre-compiled to SQL. With dynamic queries, perf can be not good because for each execution, the JPQL request is recompile to SQL, so parsing, creation of the JPQL tree then SQL generation, and with your solution, you concatenate lot of String. It isn't important for one request but with lot of request, you use more time and cpu, for string concatenation, it is better to use StringBuilder that is more performant than String addition or StringBuffer. An other argument for named queries is that with dynamic queries, if they aren't written correctly (it isn't the case for your code ;) ), it is easy to introduce some malicious SQL code with parameters my two cents. Emmanuel On Jan 18, 2008 9:57 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: You can get some benefit from named queries in terms of query pre- compilation and caching on the underlying database. However, most database flavors and hibernate providers turn criteria queries into named queries (parameterized SQL) which is then cached, so, on the surface I suspect the performance characteristics will be similar. Christian. On 18-Jan-08, at 14:35 , Rahul Thakur wrote: Thanks Emmanuel! Responses inlined... Emmanuel Venisse wrote: Hi Rahul, After few days to look at JPA, I'm sure now it would be good to use it instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA). The code is very easy to write and to read with JPA. About your continuum-jpa branch, I have few remarks: - I don't think it's good to use directly some OpenJPA APIs. If possible, I'd prefer to use only standard JPA APIs so we'll can choose later the implementation we want to use (OpenJPA, TopLink, JPOX...) Agree. The only place where OpenJPA APIs are being used directly currently are the unit tests. - why do you use some Spring code? Experimental. Spring has a good transaction management framework out of the box. - we don't need to store the model encoding (CommonUpdatableModelEntity class) Sure. Easily fix'able. :-) - can you explain dateCreated/dateUpdated fields? How are they managed? These are for audit puposes, and can be used as range search query criteria for fetching entities. These were an extension I thought will be good. 'dateCreated' gets set when an entity is first inserted into the underlying store, subsequent updates update the 'dateUpdated'. - all the model is fectched eagerly and it isn't acceptable for performance Yes, the model does needs review and tweaks to annotations where we know we don't need to fetch 'eagerly'. - I'm not sure your Query pattern is good. I'd prefer to use named queries but maybe you have a reason I think using a Query like we have on the JPA branch nicely provides for a flexible construction of queries (i.e, only the criteria passed in contributes to the query). I am not sure if such is available with named queries; but I am interested to know why named queries might be better. Cheers, Rahul That's all for the moment. Emmanuel On Jan 16, 2008 11:30 PM, Rahul Thakur [EMAIL PROTECTED] wrote: Just wondering if anyone else got to the changes? Emmanuel Venisse wrote: I don't have the time to look at it these days but I'll do it asap (maybe in few weeks :( ) Emmanuel Rahul Thakur a écrit : Hi All, Scribbling some quick notes on some of the toying around I have been doing with OpenJPA, Generics etc on the continuum-jpa branch[1]: 1) Use JPA for persistence Motivation behind this has been to investigate how this compares to JPOX/JDO for managing the model - both in terms on performance and ease of use (Store APIs). Continuum model classes are annotated with JPA annotations on the branch. However, this needs a review as there are some elements (for example 'configuration' typed as Map) that I am not sure yet how to persist yet. The provider used is OpenJPA [2]. 2) Refactorings to Store interface Main motivation has been to keep the core Store interface lean and mean (read extensible). The Store interface[3] now has 4 methods: lookup() save() delete() query() The lookup(), save() and delete() act on single model Entity, while query() will filter and obtain matching Entities from the underlying database based on the Query specified. Query implementations control how a resulting JPQL gets constructed and which matching entities get pulled, and can be easily extended. To preserve compatibility with the existing Store interface, we can mimick the existing ContinuumStore interface operations by having a facade that can prepare requisite queries and delegate to a Store instance. 3) Misc. There are a few I am investigating: 1) Spring/Guice under the hood. 2) JUnit 4.4 (and Hamcrest library) , but these are still in early stages. I am keen to get a feedback
Re: Some continuum-jpa branch updates
I think it would be good to introduce some partial object like ProjectGroupWithoutProjects that we can use in JPQL request so we won't use non detached fields and we'll know exactly what we use and where. Emmanuel On Jan 21, 2008 10:59 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: As Christian said, named queries are pre-compiled to SQL. With dynamic queries, perf can be not good because for each execution, the JPQL request is recompile to SQL, so parsing, creation of the JPQL tree then SQL generation, and with your solution, you concatenate lot of String. It isn't important for one request but with lot of request, you use more time and cpu, for string concatenation, it is better to use StringBuilder that is more performant than String addition or StringBuffer. An other argument for named queries is that with dynamic queries, if they aren't written correctly (it isn't the case for your code ;) ), it is easy to introduce some malicious SQL code with parameters my two cents. Emmanuel On Jan 18, 2008 9:57 PM, Christian Edward Gruber [EMAIL PROTECTED] wrote: You can get some benefit from named queries in terms of query pre- compilation and caching on the underlying database. However, most database flavors and hibernate providers turn criteria queries into named queries (parameterized SQL) which is then cached, so, on the surface I suspect the performance characteristics will be similar. Christian. On 18-Jan-08, at 14:35 , Rahul Thakur wrote: Thanks Emmanuel! Responses inlined... Emmanuel Venisse wrote: Hi Rahul, After few days to look at JPA, I'm sure now it would be good to use it instead of the actual JDO/JPOX (I know JPOX 1.2 support JPA). The code is very easy to write and to read with JPA. About your continuum-jpa branch, I have few remarks: - I don't think it's good to use directly some OpenJPA APIs. If possible, I'd prefer to use only standard JPA APIs so we'll can choose later the implementation we want to use (OpenJPA, TopLink, JPOX...) Agree. The only place where OpenJPA APIs are being used directly currently are the unit tests. - why do you use some Spring code? Experimental. Spring has a good transaction management framework out of the box. - we don't need to store the model encoding (CommonUpdatableModelEntity class) Sure. Easily fix'able. :-) - can you explain dateCreated/dateUpdated fields? How are they managed? These are for audit puposes, and can be used as range search query criteria for fetching entities. These were an extension I thought will be good. 'dateCreated' gets set when an entity is first inserted into the underlying store, subsequent updates update the 'dateUpdated'. - all the model is fectched eagerly and it isn't acceptable for performance Yes, the model does needs review and tweaks to annotations where we know we don't need to fetch 'eagerly'. - I'm not sure your Query pattern is good. I'd prefer to use named queries but maybe you have a reason I think using a Query like we have on the JPA branch nicely provides for a flexible construction of queries (i.e, only the criteria passed in contributes to the query). I am not sure if such is available with named queries; but I am interested to know why named queries might be better. Cheers, Rahul That's all for the moment. Emmanuel On Jan 16, 2008 11:30 PM, Rahul Thakur [EMAIL PROTECTED] wrote: Just wondering if anyone else got to the changes? Emmanuel Venisse wrote: I don't have the time to look at it these days but I'll do it asap (maybe in few weeks :( ) Emmanuel Rahul Thakur a écrit : Hi All, Scribbling some quick notes on some of the toying around I have been doing with OpenJPA, Generics etc on the continuum-jpa branch[1]: 1) Use JPA for persistence Motivation behind this has been to investigate how this compares to JPOX/JDO for managing the model - both in terms on performance and ease of use (Store APIs). Continuum model classes are annotated with JPA annotations on the branch. However, this needs a review as there are some elements (for example 'configuration' typed as Map) that I am not sure yet how to persist yet. The provider used is OpenJPA [2]. 2) Refactorings to Store interface Main motivation has been to keep the core Store interface lean and mean (read extensible). The Store interface[3] now has 4 methods: lookup() save() delete() query() The lookup(), save() and delete() act on single model Entity, while query() will filter and obtain matching Entities from the underlying database based on the Query specified. Query implementations control how a resulting JPQL gets constructed and which matching entities get pulled, and can be easily extended
Continuum update
Hi, I'll probably create a new branch for 1.x dev and will reserve the trunk for 2.x dev. I think I'll do it this week or the next (if you're agree, of course :) ) I'll try to send at the same time my ideas for 2.x so we'll can discuss about them. Emmanuel
Re: [discuss] Graduate Continuum to its own TLP
hehe, thanks for the nomination :) Emmanuel Jesse McConnell a écrit : hehe, I am honored to be mentioned I would second brett's nomination of evenisse as chair, can't think of anyone that has given more to the project in the last couple of years :) jesse On Jan 7, 2008 3:00 PM, Rahul Thakur [EMAIL PROTECTED] 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: [discuss] Graduate Continuum to its own TLP
I'm ok too, but I don't have the time to work on it. Emmanuel Olivier Lamy a écrit : Hi, Agree to start processing this. If I can help I will. -- Olivier 2007/12/20, Brett Porter [EMAIL PROTECTED]: 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: [vote] Release Continuum 1.1 Final
I fixed it.
About the doc, I'll work on it this week and it will be deploywhen the vote
will be ok.
Emmanuel
Emmanuel Venisse a écrit :
I'll fix it today and will resend a message when you'll can retest.
Emmanuel
Stuart James Penrose a écrit :
Emmanuel Venisse wrote:
The binaries are available there: ...
http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/data-management-cli/1.1/data-management-cli-1.1-app.jar
The data management tool looks like it needs some 'assembly' work
('java -jar data-management-cli-1.1-app.jar' doesn't work):
1) If you list the root of the jar you see a list of *.jar entries,
not root package names
2) It appears that the main class is missing (DataManagementCli)
- xmlrpc backup tool :
http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/continuum-xmlrpc-backup/1.1/continuum-xmlrpc-backup-1.1-app.jar
The file generated by the backup tool can be used with data
management cli to re-import data.
How does the xml backup tool relate to the cli tool the recommended
backup/restore/upgrade strategy in general? Should the upgrade page
make mention of this new tool
(http://maven.apache.org/continuum/documentation/1_1/installation/upgrade.html)?
Everyone is encouraged to vote and give their feedback.
[ ] +1 Release it!
[ ] 0
[ ] -1 Don't release it, because...
-1 Don't release it, because the data management tool is broken and as
a result it's not clear how to upgrade 1.1-betaX installs to 1.1 final.
Stu Penrose
[vote] Release Continuum 1.1 Final
Hi, Continuum 1.1 Final is ready for release The highlights are - bug fixes - A new backup tool with xmlrpc for continuum db (not the users db) The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13605 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/continuum-plexus-runtime/1.1/continuum-plexus-runtime-1.1-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/continuum-webapp/1.1/continuum-webapp-1.1.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/data-management-cli/1.1/data-management-cli-1.1-app.jar - xmlrpc backup tool : http://people.apache.org/builds/maven/continuum/1.1/org/apache/maven/continuum/continuum-xmlrpc-backup/1.1/continuum-xmlrpc-backup-1.1-app.jar The file generated by the backup tool can be used with data management cli to re-import data. Everyone is encouraged to vote and give their feedback. [ ] +1 Release it! [ ] 0 [ ] -1 Don't release it, because... As we don't have a small bug fixes list, the vote will be open for one week to let you test it. So, cast your votes now ;-) Here's my +1 Thanks, Emmanuel
Continuum 1.1
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
Re: Fwd: [continuum build trunk - SKIPPED - checkout] Thu Nov 8 01:00:01 GMT 2007
Done. Emmanuel olivier lamy a écrit : Hi, Is it possible someone with karma maven.zones kill processes ? Thanks, -- Olivier -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 8 nov. 2007 02:00 Subject: [continuum build trunk - SKIPPED - checkout] Thu Nov 8 01:00:01 GMT 2007 To: [EMAIL PROTECTED] ci_continuum.sh already running... exiting continuu 24880 24200 0 Oct 24 ? 0:00 /bin/sh /export/home/continuum/ci_continuum.sh checkout continuu 24200 24169 0 Oct 24 ? 0:00 /bin/sh /export/home/continuum/ci_continuum.sh checkout continuu 24169 24167 0 Oct 24 ? 0:00 /bin/sh /export/home/continuum/ci_continuum.sh checkout
Re: converting from 1.0.3
Brett Porter a écrit : 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? No decision for the moment. 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. We have always some issues with data management. I'm looking at a XML-RPC client to Backup/Restore all datas that would be more robust than the data management anxd won't use lot of memory because it won't load all data from the db in one JDO request. About 1.0.3 migration, I'm not sure we can do it correctly, because we have lot of changes in the db and with a migration some data won't be set, but maybe it's possible. Emmanuel
Re: customising emails
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/
Re: customising emails
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/
Re: svn commit: r590819 - /maven/continuum/trunk/pom.xml
Jesse,
What is this change???
We don't have migrated to alpha-4 yet.
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: jmcconnell
Date: Wed Oct 31 13:42:00 2007
New Revision: 590819
URL: http://svn.apache.org/viewvc?rev=590819view=rev
Log:
revert to redback alpha 3 pending HAUS-1590
Modified:
maven/continuum/trunk/pom.xml
Modified: maven/continuum/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml?rev=590819r1=590818r2=590819view=diff
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Wed Oct 31 13:42:00 2007
@@ -671,6 +671,11 @@
/dependency
dependency
groupIdorg.codehaus.plexus.redback/groupId
+artifactIdredback-users-configurable/artifactId
+version${redback.version}/version
+ /dependency
+ dependency
+groupIdorg.codehaus.plexus.redback/groupId
artifactIdredback-system/artifactId
version${redback.version}/version
/dependency
Re: How to discuss about misspelling ?
Damien Lecan a écrit : here ## Some things to discuss for the french : release was not translated by Damien. What about : diffuser or distribuer ? At worst faire une 'release' It was translated by Damien but I reverted it because I always use release in french :) but if you prefer 'diffuser' or 'distribuer', it's ok. I think faire une 'release' would be better. Notifers : alertes, instead of Notifiers +1 Summary is translated by résumé, but bilan could fit better ok Success is translated by réussite, but succès could fit better +1 Plannification = Planification +1 Remove all capital letters inside sentence (Date de la Dernière Construction = Date de la dernière construction) +1 Projets de Membres = Membres du projet +1 ... Damien Blugeon did a great job with 1st translation, small improvements could lead to very good translation. Damien, what do you think about that ? Other french people ? I'm not sure Damien is on this list, but I'm french and Olivier too :) ## Some page are not translated, even if a translation is provided. For example, login page is in english, whereas all keys are translated (login.username, login.submit, ...) login, registration and users page are translated in Redback. I'll update Continuum to the latet Redback for Continuum 1.1 final so translation will be there. Translations are there: http://svn.codehaus.org/redback/redback/trunk/redback-integrations/redback-xwork/redback-xwork-integration/src/main/resources/org/codehaus/plexus/redback/xwork/ ## I can't find where date formatting is provided. webwork.date key is configured with dd MMM, hh:mm:ss aaa z, but dates appear like that : oct. 30, 2007 04:34:02 AM CET At worst, it should be dd MMM HH:mm:ss z Is time zone mandatory ? Date format is hardcoded for the moment, we'll see in next versions how to externalize it. Can you provide a patch for you translations fixes? Emmanuel Damien
Re: How to discuss about misspelling ?
Damien Lecan a écrit : release was not translated by Damien. What about : diffuser or distribuer ? At worst faire une 'release' It was translated by Damien but I reverted it because I always use release in french :) but if you prefer 'diffuser' or 'distribuer', it's ok. I think faire une 'release' would be better. +1 for faire une release Translations are there: http://svn.codehaus.org/redback/redback/trunk/redback-integrations/redback-xwork/redback-xwork-integration/src/main/resources/org/codehaus/plexus/redback/xwork/ Hum, was it reviewed ? Yes, but maybe I missed some strings. You can send a patch for it too :) Can you provide a patch for you translations fixes? I'll do it Damien
[Result] [vote] Release Continuum 1.1-beta-4
Below are the results of this vote: 3 Binding Votes (Wendy, Brett, and Myself) 3 Non-binding vote (Olivier, Damien, Ossi) I'll finalize the release and will send an update. Thanks, Emmanuel Emmanuel Venisse a écrit : Hi, Continuum 1.1-beta-4 is ready for release The highlights are - lot of bug fixes - A new page to view the build queue - Customization of mail subject The Release Notes is available there: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10540fixfor=13727 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-4/continuum-plexus-runtime-1.1-beta-4-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-webapp/1.1-beta-4/continuum-webapp-1.1-beta-4.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/data-management-cli/1.1-beta-4/data-management-cli-1.1-beta-4-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
[announce] Continuum 1.1-beta-4 is released
The Continuum team is pleased to announce the Continuum 1.1-beta-4 release Highlights are: * lot of bug fixes * A new page to view the build queue * Customization of mail subject You can grab the latest release from the download page : http://maven.apache.org/continuum/download.html To upgrade from a previous 1.1 beta, you can look at Upgrade Guide : http://maven.apache.org/continuum/documentation/1_1/installation/upgrade.html Below is the jira release notes for this release. Release Notes - Continuum - Version 1.1-beta-4 Sub-task * [CONTINUUM-1499] - Translate to Brazilian Portuguese * [CONTINUUM-1534] - Translate to French Bug * [CONTINUUM-811] - Documentation of Deployment Repository Directory * [CONTINUUM-1355] - No admin user found after Tomcat shutdown (Tomcat doesn't shutdown properly) * [CONTINUUM-1392] - Continuum tests require too much external set up * [CONTINUUM-1403] - Error on edit project group page * [CONTINUUM-1453] - Confirmation Page for Deleting a Build Definition is not Informative Enough * [CONTINUUM-1466] - Project name accepts blank spaces when edited in Project Summary Members Tab Edit Project * [CONTINUUM-1473] - Server Id in wagon notifier edit pages is required but doesn't have validation * [CONTINUUM-1474] - At the time of an addition of new BuildDefinition with XmlRPC client, the automatically generated buildDefinitionID cannot be recovered * [CONTINUUM-1476] - warning/error in the mail generation * [CONTINUUM-1481] - datamanagement-cli must support more db * [CONTINUUM-1487] - should not be allowed to delete a build result that is still executing * [CONTINUUM-1491] - Build history screen should show build definition description * [CONTINUUM-1494] - Maximum length for name column exceeded in makeAndStoreBuildResult * [CONTINUUM-1495] - Calling getAllProjectGroups() fails * [CONTINUUM-1502] - After changing the name of a project group, the project dissapears and is not accessible, not even by the admin user. * [CONTINUUM-1508] - NullPointerException when adding an empty installation to a profile * [CONTINUUM-1509] - always build option doesn't work with scheduler -- log = No files updated, not building * [CONTINUUM-1512] - Constraint Violation Exception when deleting an empty group * [CONTINUUM-1516] - Unable to send mail with more than one build definition * [CONTINUUM-1517] - missing includeBuildResult configuration * [CONTINUUM-1519] - Continuum does not respect build order for flat projects * [CONTINUUM-1520] - Scheduler is unstable * [CONTINUUM-1524] - Continuum don't find the default build definition for ANT/Shell projects * [CONTINUUM-1527] - NullPointer when Releasing without configuration node in the maven-release-plugin * [CONTINUUM-1530] - Problems releasing project in group with more than one project definition * [CONTINUUM-1532] - Remove TestResult/SuiteResult/TestCaseFailure from the model Improvement * [CONTINUUM-150] - Continuum site needs screenshots * [CONTINUUM-606] - Add Build Time to Project Summary Page * [CONTINUUM-703] - Display of last build date on Project Summary page * [CONTINUUM-789] - Show SCM branch/tag on summary screen * [CONTINUUM-815] - directory configuration * [CONTINUUM-1233] - Reduce number of clicks to add a project * [CONTINUUM-1254] - Clarification of Configuring Continuum as a Service in Getting Started Guide * [CONTINUUM-1388] - the NOTICE file is overzealous in declaring dependencies * [CONTINUUM-1436] - Add build definition template * [CONTINUUM-1483] - Better support for SCM like clearcase or SYNERGY * [CONTINUUM-1484] - Allow customization of email subject * [CONTINUUM-1493] - Data migration site documentation improvement * [CONTINUUM-1500] - remove ContinuumStore use from the webapp part * [CONTINUUM-1514] - Legend is hardcoded New Feature * [CONTINUUM-310] - customisable email templates * [CONTINUUM-583] - Show the build/checkout queues on the web interface * [CONTINUUM-1287] - editable build queue * [CONTINUUM-1328] - create build-definition-templates and link to them in build-definitons * [CONTINUUM-1331] - create new page: show current build queue with project name, next build time * [CONTINUUM-1332] - project group summary: show per project the last build time Task * [CONTINUUM-253] - Create a matrix of databases that Continuum can work with Wish * [CONTINUUM-409] - Email notifications could still include build stats when includeBuildResult is false * [CONTINUUM-1452] - Show a summary total of the Projects and Build Status columns on the Project Groups page
Re: [vote] Release Continuum 1.1-beta-4
If possible, I'd like to see more votes for this release from committers/PMC Thanks. Emmanuel Emmanuel Venisse a écrit : Hi, Continuum 1.1-beta-4 is ready for release The highlights are - lot of bug fixes - A new page to view the build queue - Customization of mail subject The Release Notes is available there: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10540fixfor=13727 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-4/continuum-plexus-runtime-1.1-beta-4-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-webapp/1.1-beta-4/continuum-webapp-1.1-beta-4.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/data-management-cli/1.1-beta-4/data-management-cli-1.1-beta-4-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: [vote] Release Continuum 1.1-beta-4
Wendy Smoak a écrit : On 10/29/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: If possible, I'd like to see more votes for this release from committers/PMC Sorry, I missed this until Sunday evening. I'll take a look at it tonight. Thanks (Continuum releases tend to come as a surprise to me. A message a few days before, I'm planning to do the release on Thursday... would help me plan my time better.) I sent a message on the dev@ list one week before to start the release ;) Emmanuel
Re: How to discuss about misspelling ?
Damien Lecan a écrit : Hello, I noticed new french translation in next 1.1-beta-4 version. This is a great job to translate such application in french, but some words should have been reviewed before being applied. So how can we discuss about misspelling, about words used in sentences, about missing translations, ... ? here, on irc, with a jira patch. Emmanuel Thanks Damien Lecan
Re: [vote] Release Continuum 1.1-beta-4
instructions are the same from previous version, replace beta-2 by beta-3 and beta-3 by beta-4 :) http://maven.apache.org/continuum/guides/mini/guide-data-management.html Emmanuel Dan Tran a écrit : have instructions to migrate beta-3 database to beta-4? -D On 10/25/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: Normally, the proxy info must be loaded from the settings.xml and used by wagon, but maybe I ommit some code in http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-data-management/data-management-cli/src/main/java/org/apache/maven/continuum/management/DataManagementCli.java in downloadArtifact(...) method Emmanuel olivier lamy a écrit : Hi, It's duplicate with CONTINUUM-1492. Can you detailled what kind of proxy you use ? (NTLM authentification ?). Because as I have explained in CONTINUUM-1492, I have tested this successfully with adding -Dhttp.proxyHost=proxyhost.com, -Dhttp.proxyPort=80 (but with auth in the proxy) in the cli. Have you try this [1]? -- Olivier [1] http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html 2007/10/25, Damien Lecan [EMAIL PROTECTED]: 2007/10/25, Emmanuel Venisse [EMAIL PROTECTED]: Hmm, file an issue and I'll try to fix it (but I don't have a proxy to do a real test) http://jira.codehaus.org/browse/CONTINUUM-1536 Damien
[vote] Release Continuum 1.1-beta-4
Hi, Continuum 1.1-beta-4 is ready for release The highlights are - lot of bug fixes - A new page to view the build queue - Customization of mail subject The Release Notes is available there: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10540fixfor=13727 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-4/continuum-plexus-runtime-1.1-beta-4-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-webapp/1.1-beta-4/continuum-webapp-1.1-beta-4.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/data-management-cli/1.1-beta-4/data-management-cli-1.1-beta-4-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: [vote] Release Continuum 1.1-beta-4
Where is your settings.xml? It must be under ${user.home}/.m2/
Emmanuel
Damien Lecan a écrit :
I removed few days ago some tables in the model because they wasn't used, but
they are exported by DMC beta-3.
Remove testResult tags in the xml file and it should be ok.
I'll add some instructions about it on the site when I'll do the release.
Ok, it works now.
DMC still doesn't read my settings.xml file (proxy + Continuum beta-4
stage repository), but it can wait for next beta/rc release to be
solved (or not).
So +1
Damien
Re: [vote] Release Continuum 1.1-beta-4
Hmm, file an issue and I'll try to fix it (but I don't have a proxy to do a
real test)
Emmanuel
Damien Lecan a écrit :
Where is your settings.xml? It must be under ${user.home}/.m2/
My settings.xml is under ${user.home}/.m2/
Here is what I get when I try to execute DMC and then
dependency:resolve with DMC pom file.
DMC alone :
[EMAIL PROTECTED] ~]$ java -jar data-management-cli-1.1-beta-4-app.jar ...
0 [main] INFO org.apache.maven.continuum.management.DataManagementCli
- Processing Continuum database...
Exception in thread main
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException:
Missing:
--
1) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.continuum
-DartifactId=data-management-jdo \
-Dversion=1.1-beta-4 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) dummy:dummy:pom:1.0
2) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
--
1 required artifact is missing.
for artifact:
dummy:dummy:pom:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
at
org.apache.maven.continuum.management.DataManagementCli.downloadArtifact(DataManagementCli.java:304)
at
org.apache.maven.continuum.management.DataManagementCli.processDatabase(DataManagementCli.java:185)
at
org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:158)
= same session, same maven 2, same settings.xml =
Then, with DMC pom file :
[EMAIL PROTECTED] ~]$ mvn dependency:resolve
[INFO] Scanning for projects...
Downloading:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-data-management/1.1-beta-4/continuum-data-management-1.1-beta-4.pom
2K downloaded
Downloading:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-parent/1.1-beta-4/continuum-parent-1.1-beta-4.pom
25K downloaded
Maven itself finds settings.xml and its configuration.
Damien
Re: [vote] Release Continuum 1.1-beta-4
ossi petz a écrit :
Hallo
anyone free to vote? :)
i tried to install the webapp within a tomcat 5.5.25 / java 1.5 but i
got stuck with a db driver problem (see below)
i tried to follow instructions at:
http://docs.codehaus.org/display/CONTINUUMUSER/Continuum+on+Tomcat
but i am not quite sure those instructions are not foolproof.
stupid questions part:
- the settings for tomcat 5.0 and 5.5 are the same?
no, and some version don't work due to missing libraries
- why is the war file not copied to webapps folder?
The war must be exploded to access to some conf file like
WEB-INF/classes/META-INF/plexus/application.xml
- how do i configure the logs location (it claims a missing
folder/file /logs/continuum.log)?
The logs location is configured in WEB-INF/classes/log4j.xml
By default, it use ${appserver.base}/logs/continuum.log and if you didn't
configured appserver.base property in your tomcat, it is empty.
- and finally where do i put the jdbc settings so the driver is found?
jdbc settings must be done in Tomcat because Continuum use JNDI for the
datasources
Look at this doc:
http://people.apache.org/~evenisse/continuum_1.1_site/documentation/1_1/installation/tomcat.html
Emmanuel
regards :)
ossi
stacktrace:
2007-10-25 19:06:29,414 [main] INFO org.codehaus.plexus.PlexusContainer
- Loading on start [role,roleHint]:
[org.apache.maven.continuum.Continuum,default]
2007-10-25 19:06:30,609 [main] ERROR JPOX.RDBMS.Schema - Failed
initialising database. Please check that your database JDBC driver is
accessible, and the database URL and username/passwor
d are correct. Exception : Cannot create JDBC driver of class '' for
connect URL 'null'
org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC
driver of class '' for connect URL 'null'
at
org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1150)
at
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
at org.jpox.util.FailoverUtils.getConnection(FailoverUtils.java:51)
at org.jpox.store.rdbms.RDBMSManager.init(RDBMSManager.java:241)
-- No suitable driver found
Emmanuel Venisse schrieb:
Hi,
Continuum 1.1-beta-4 is ready for release
The highlights are
- lot of bug fixes
- A new page to view the build queue
- Customization of mail subject
The Release Notes is available there:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10540fixfor=13727
The binaries are available there:
- Runtime:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-4/continuum-plexus-runtime-1.1-beta-4-bin.tar.gz
- Webapp:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-webapp/1.1-beta-4/continuum-webapp-1.1-beta-4.war
- data management cli:
http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/data-management-cli/1.1-beta-4/data-management-cli-1.1-beta-4-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
continuum-site branch
Hi, I'd like to merge continuum-site_1.1 branch in trunk tomorrow (before to start the release process of 1.1-beta-4) Are you ok? Emmanuel
Re: Continuum reference docs
Wendy Smoak a écrit : On 10/16/07, Wendy Smoak [EMAIL PROTECTED] wrote: Thanks! The site builds locally now, I'll give publishing it another try later. Success! It starts here: http://maven.apache.org/continuum/ref/latest/ (As with Archiva, 'latest' is symlinked to the most recent snapshot docs, in this case 1.1-beta-4.) Some examples of the UMLGraph alternate doclet for Javadoc in action: http://maven.apache.org/continuum/ref/latest/apidocs/org/apache/maven/continuum/release/ContinuumReleaseManager.html http://maven.apache.org/continuum/ref/latest/apidocs/org/apache/maven/continuum/web/action/AddMavenProjectAction.html This does introduce a dependency on GraphViz [1] in order to generate the diagrams. You need the 'dot' executable on your path. I think you can still build the Javadoc without it, you'll just get a broken image. [1] http://www.graphviz.org/ Thanks. I'll add more reports later. Emmanuel
next release
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
Re: next release
Brett Porter a écrit : I'm happy to bump 1475. I think 1388 needs to be fixed before a final release though? I don't think it need to be fixed for the final release (all maven plugins and maven are released actually with it without complaint) but if you really want it for the final release, I can work on this issue and do the release few days later. What about the 12 issues in 1.1 - are they all docs? Are you saying they'll just be addressed after the release? No, they aren't all documented, I'd want to work on them in next days and maybe finished them 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? I understand 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: Continuum reference docs
I modified redback-legacy pom to fix it. The problem was that we patch generated modello files in process-sources phase due to a bug in modellobut the javadoc reporting is executed in generate-sources phase so our patch wasn't applied. Emmanuel Wendy Smoak a écrit : On 10/15/07, Wendy Smoak [EMAIL PROTECTED] wrote: I'm going to work on publishing reference docs (Javadoc, reports) for Continuum under the maven.a.o/continuum/ref/$version url. Or not. Any idea what this is about? $ mvn site ... [INFO] Building Maven Continuum Plugin [INFO] [INFO] No goals needed for project - skipping [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [site:site] [INFO] Generate JavaDocs report. 1 error [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - /Users/wsmoak/svn/maven/continuum/continuum-data-management/data-management-redback-jdo/src/main/java/org/apache/maven/continuum/management/redback/LegacyJdoDataManagementTool.java:33: cannot access org.codehaus.plexus.security.authorization.rbac.jdo.v0_9_0.RbacJdoModelModelloMetadata bad class file: /Users/wsmoak/svn/maven/continuum/continuum-data-management/redback-legacy/target/generated-sources/modello/org/codehaus/plexus/security/authorization/rbac/jdo/v0_9_0/RbacJdoModelModelloMetadata.java file does not contain class org.codehaus.plexus.security.authorization.rbac.jdo.v0_9_0.RbacJdoModelModelloMetadata Please remove or make sure it appears in the correct subdirectory of the classpath. import org.codehaus.plexus.security.authorization.rbac.jdo.v0_9_0.RbacJdoModelModelloMetadata; ^ Command line was:cd /Users/wsmoak/svn/maven/continuum/target/site/apidocs /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc @options @packages
Re: Continuum Archiva on Tomcat together and appserver.base variable
What is the problem? Emmanuel Damien Lecan a écrit : Hello, Continuum and Archiva share the same use of appserver.base variable. This is a problem when they are deployed together, in Tomcat for example. How to specify one appserver.base for continuum and one for Archiva ? I don't know where to report that in Jira, Continuum or Archiva bug/enhancement ? Plexus one ? Thanks Damien Lecan
Continuum 1.2 Roadmap
Hi, We are near the end of 1.1, it's time to discuss of 1.2 roadmap :) For this new version, my vision is: - Rewrite all the UI with a full GWT site. I want to migrate to GWT because we need better performance on the UI even if it is correct now. The second point is that with GWT (and Ajax in general) we'll can add nice features (maybe not in 1.2) to users like auto-refresh of small part of pages, users spaces, dynamic chart... And the last point of the GWT choice is all the code is written in java with a verification of all parts by the compiler (properties undeclared or unused, css style doesn't exist,...) so we'll reduce typo errors that we got sometimes. - Externalization of all the configuration. In this version, I want to move all the conf that is actually embedded in application.xml to a file more visible by the user. We can use plexus-registry for this. - Better support of XML-RPC and other remote access (XFire, ...). For this point, I think it would be good to share the code with the GWT part with some services classes that will embed all the remote code with security checks - Better support of maven projects. Actually, we detect if a build is required by looking at scm changes and dependencies changes. The problem is in dependencies changes. We look only at dependencies that are a continuum project too, it would be good to check repositories to find if a new version exists like maven do it. An other problem with dependencies changes is we don't really check if a new version exists but only if a new build result was created, it's a problem in case of projects with more than one build definition (for example clean install and site). If a site is generated, a new build result is created and continuum consider it as a dependency change so it rebuild all dependent projects in the next step. About GWT, I found few guys (6) that want to spend some time to do the migration and investigate on some new UI features. This roadmap is short because I don't want to wait a new time a long wait before to release a new 1.x version and I'd like to attract new users. I'd like to release 1.2 betfore the end of the year. I'll send a new mail in few weeks about 2.0 roadmap that will require more work. wdyt? Emmanuel
Re: Continuum 1.2 Roadmap
On 10/3/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We are near the end of 1.1, it's time to discuss of 1.2 roadmap :) For this new version, my vision is: Sounds good in general. I'm not thrilled with GWT-- I'm suspicious of code generation-- but since I'm not doing the work I'm not going to complain (too much) (until it breaks). GWT seems to be good and easy to use. All GWT users I met don't want to change now and they work on some very big applications If you're going to completely change the UI, then this is going to feel like a 2.0 even if not much changes behind the scenes functionality wise. I don't think to change completely the UI in 1.2, only the web framework and some new UI features but pages will be approximatively the same we have actually. Big UI changes will be for 2.0, if we need to do big changes. We've talked about Continuum being distributed-- having a master server that farms out builds to others, or at least consolidates the build results from all of the others. That might be something for 2.0 (or 3.0, see above. :) though ). About the consolidation/dashboard, maybe we'll can add it in 1.2 but I don't think. But I'm sure distributed builds will be in 2.0, we'll can't wait 3.0 ;) Emmanuel
Re: CONTINUUM-310 - customizable email templates
I think the best way would be to allow the user to chosse his own template, if a template isn't define, continuum will choose the default. About the issue, I closed it because the mail is customizable (subject, print or not the build output...) but if we can allow new templates, we'll can reopen this issue or open a new one. Emmanuel Rahul Thakur a écrit : I think this might be a good feature to have in continuum. Users can be allowed to create their own notification templates that can be stored in DB for a given build. In case of no email template, we use the default. Thoughts? Cheers, Rahul Tomislav Stojcevich wrote: This was marked closed, should it have been? I still see no way of allowing the user to customize the content of the email body. Right now the velocity templates are part of the continuum-core project and are buried inside the core.jar so it's not easy for the users to edit the template. What does everybody think about adding a step to the continuum-webapp project that extracts the templates from the continuum-core.jar and puts a copy of them in the WEB-INF/classes directory. When the mail notifier loads the templates it should find the ones in the WEB-INF/classes before the ones in the jar and run with those. That way the users can edit them and customize them any way they want.
Re: CONTINUUM-310 - customizable email templates
Tomislav Stojcevich a écrit : I think it should be re-opened since there still is no way to completely customize the template itself other than turning on and off the output and summary. In my case the turning on the summary wiith the build output turned off will give me what I want but it is still too much. I'd like to be able to customize further, there are only a couple of things from the summary that I want to see. We could continue to add flags to the xml file and if checks within the template but where does it stop? And what about internationalization? that would have to be a separate issue but allowing access to be able to modify the templates directly would at least let those users that really need to change the language of the text that is hardcoded in the template to be able to do it should they need to. So how about my idea about extracting the templates from the core jar into the webapp during the webapp build, that way they can be directly modified? This at least allows the default templates to be customizable easily. I don't think it's the best solution. IMO, it would be better to allow the user to choose the template he want to use if he don't want the default. Another issue should be opened to provide the functionality that Rahul is suggesting about allowing different templates per group or project. That would involve more changes. There would have to be a place in the database to store template location per project or group or possibly store the template itself and provide a template edit screen. If we allow to have a template per group or project, in fact per mail notifier, it's easy to add this feature if the one above is implemented. We can store it in the mail notifier configuration field so we don't need to change the db schema for it. Emmanuel
Re: CONTINUUM-310 - customizable email templates
Wendy, All continuum conf will be externalized in 1.2 Emmanuel Wendy Smoak a écrit : On 10/1/07, Tomislav Stojcevich [EMAIL PROTECTED] wrote: What does everybody think about adding a step to the continuum-webapp project that extracts the templates from the continuum-core.jar and puts a copy of them in the WEB-INF/classes directory. When the mail notifier loads the templates it should find the ones in the WEB-INF/classes before the ones in the jar and run with those. That way the users can edit them and customize them any way they want. I have an outstanding make things pre-configurable requirement. Right now it's for the General Configuration that you're forced to edit the first time the app starts, and it will apply to this as well. So I need to be able to pre-configure 'what template to use' in an XML file and also place the templates somewhere prior to starting the app that they will be seen and used. There is already continuum.xml file that I planned to use for the general configuration, should I ever find time to work on that... Thanks,
Re: CONTINUUM-310 - customizable email templates
We can't move all in the db because schema updates can be a pain.
In 1.2 all the conf, actually written in application.xml, will be move to an external file. This file will can be stored in ${user.home} so each installs will can use it like it is done in
archiva-configuration.
Emmanuel
Rahul Thakur a écrit :
I haven't seen pebble config...
I was thinking what if you move database between Continuum installs?
Since your template resides outside the db, it won't be portable.
Jesse McConnell wrote:
I rather like the configuration of pebble where some of the
configuration is
just putting in classnames and the same could easily be done with the vm
template resource location, source from some configuration and then if
resource isn't found just use the default like emm was saying...
jesse
On 10/2/07, Rahul Thakur [EMAIL PROTECTED] wrote:
I agree with Emmanuel; extracting templates from core jar is not a
solution.
So far from this thread it seems there are quite a few things we could
do for the email template customization feature. IMO, We need to
brainstorm what might make best sense.
Do we allow custom email templates for:
1) each Build Definition?
2) each mail notifier defined?
3) each Project/Project Group?
and,
4) What is the order of precedence if there were custom templates
defined at different levels?
IMO, I think we should persist the notifiers in the database itself in a
separate field.
WDYT?
Rahul
Emmanuel Venisse wrote:
Tomislav Stojcevich a écrit :
I think it should be re-opened since there still is no way to
completely customize the template itself other than turning on and off
the output and summary. In my case the turning on the summary wiith
the build output turned off will give me what I want but it is still
too much. I'd like to be able to customize further, there are only a
couple of things from the summary that I want to see. We could
continue to add flags to the xml file and if checks within the
template but where does it stop?
And what about internationalization? that would have to be a separate
issue but allowing access to be able to modify the templates directly
would at least let those users that really need to change the language
of the text that is hardcoded in the template to be able to do it
should they need to.
So how about my idea about extracting the templates from the core jar
into the webapp during the webapp build, that way they can be directly
modified? This at least allows the default templates to be
customizable easily.
I don't think it's the best solution. IMO, it would be better to allow
the user to choose the template he want to use if he don't want the
default.
Another issue should be opened to provide the functionality that Rahul
is suggesting about allowing different templates per group or project.
That would involve more changes. There would have to be a place in
the database to store template location per project or group or
possibly store the template itself and provide a template edit screen.
If we allow to have a template per group or project, in fact per mail
notifier, it's easy to add this feature if the one above is
implemented. We can store it in the mail notifier configuration field
so we don't need to change the db schema for it.
Emmanuel
Re: CONTINUUM-310 - customizable email templates
Wendy Smoak a écrit :
On 10/2/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
We can't move all in the db because schema updates can be a pain.
In 1.2 all the conf, actually written in application.xml, will be move to an
external file. This file will can be stored in ${user.home} so each installs
will can use it like it is done in
archiva-configuration.
... or $CONTINUUM_HOME/conf, I assume?
of course :)
Rahul, not sure if that was meant for me, but I'm not in favor of
putting either the configuration or the email templates in the
database. Plain text rules. :)
Assuming they are loaded from the classpath, then the
path/package/filename goes in continuum.xml, and the files themselves
go somewhere that they end up on the classpath.
Re: how to install continuum betat 2 into tomcat?
On the continuum site ;) Emmanuel I am Who i am a écrit : where is beta-3 ? On 9/25/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: It would be better to use 1.1-beta-3 if you don't want to migrate your db between versions. I released it and I'll do the official announce in few hours when all files will be mirrored. but the continuum doc for tomcat is available there: http://docs.codehaus.org/display/CONTINUUMUSER/Continuum+on+Tomcat Emmanuel I am Who i am a écrit : Is there any doc available for this?
[announce] Continuum 1.1-beta-3 is released
The Continuum team is pleased to announce the Continuum 1.1-beta-3 release Highlights are: * lot of bug fixes * xwork/webwork update to fix remote code exploit in forms * mail notification to latest committers * LDAP authentication * performance improvement You can grab the latest release from: http://maven.apache.org/continuum/download.html To upgrade from 1.1-beta-2, you can look at this guide: http://maven.apache.org/continuum/guides/mini/guide-data-management.html Below is the jira release notes for this release. Release Notes - Continuum - Version 1.1-beta-3 : Sub-task * [CONTINUUM-1441] - Keep connection on irc server between each messages Bug * [CONTINUUM-697] - sizes incompatible with mssql (Patch Attached) * [CONTINUUM-1037] - Ant projects inherit a default build definition for Maven 2. * [CONTINUUM-1038] - Build definitions should list what type they are (ant, maven, maven2, shell) * [CONTINUUM-1041] - two defaults on the build definition page * [CONTINUUM-1181] - Continuum aborts when running Postgres under JBoss * [CONTINUUM-1296] - Continuum 1.1-alpha-1 does not copy Maven2 project pom.xml's /project/build/defaultGoal/text() value to Build Definition Goals field. * [CONTINUUM-1306] - templated roles are not added automatically if missing after upgrade * [CONTINUUM-1325] - Surefire Report history is not kept for prior builds * [CONTINUUM-1348] - jut of memory in build result * [CONTINUUM-1367] - granting group admin rights for a single project doesn't seem to work * [CONTINUUM-1384] - Build error when enqueing happens during SCM update * [CONTINUUM-1391] - Missing Download as text link * [CONTINUUM-1393] - change sets are duplicated on multiple failed builds * [CONTINUUM-1395] - check the permissions on the add project action for ant projects * [CONTINUUM-1404] - M2 Multi module projects still build non-recursively * [CONTINUUM-1411] - Link to display build surefire report doesn't work (in fact displaying surefire report per build is false) * [CONTINUUM-1412] - File Inclusion Vulnerability * [CONTINUUM-1415] - Javascript errors with IE * [CONTINUUM-1417] - continuum group administrator role should imply user + developer too * [CONTINUUM-1418] - Groups Roles aren't added automatically at startup in the available roles list if the users list was deleted * [CONTINUUM-1420] - Build Fresh and Profile columns are missed in group build definitions page for specific project build definitions * [CONTINUUM-1423] - Default project group is missing from the list * [CONTINUUM-1428] - Continuum must rebuild automatically a project that was in error in the previous build even if it haven't changesin the current update * [CONTINUUM-1429] - Initial checkout does not respect 'Use cached scm credentials' setting * [CONTINUUM-1435] - Release prepare not working * [CONTINUUM-1439] - Group Summary page display error * [CONTINUUM-1445] - Impossible to add two projects with the same name even if they have differents version and/or scmUrl * [CONTINUUM-1448] - upgrade to last webwork/xwork Improvement * [CONTINUUM-406] - irc notifications: support for registered nicks * [CONTINUUM-522] - IRC support needed for IRC servers not supporting /privmsg * [CONTINUUM-1093] - After validation, logged in user is shown the login page * [CONTINUUM-1218] - Automatically determine correct POM file location in Build Definition when checking out from SCMs like ClearCase * [CONTINUUM-1278] - Need to add description and/or name to build defintion * [CONTINUUM-1279] - Need to add Build Information to the build result reports and notification. * [CONTINUUM-1333] - show in project group summary per project also the status counters (as they are shown on the project groups pages) * [CONTINUUM-1366] - surefire report shown is always latest, even with a different build number * [CONTINUUM-1394] - continuum should not record change sets when it is a new checkout * [CONTINUUM-1396] - Continuum should have a separate permission to administer schedules * [CONTINUUM-1409] - A build does not say which build definition it came from * [CONTINUUM-1422] - The icon for 'Cancel Build' is missing from the legend * [CONTINUUM-1424] - Ability to Cancel Build for a subset of a project group * [CONTINUUM-1425] - URL in Company Pom should open in a new Window * [CONTINUUM-1427] - Ability to choose the build definition for 'Build all projects' and 'Build Project(s)' * [CONTINUUM-1430] - Split forms for environment variables and Ant/Maven/JDK installations * [CONTINUUM-1440] - write documentation how to use continuum-data-management * [CONTINUUM-1443] - Add an 'Always build' checkbox in 'build definition' * [CONTINUUM-1444] - IRC and Jabber notifiers accept invalid ports. * [CONTINUUM-1446] - Webwork Performance Tuning
Re: Documentation Plan
I'm agree Emmanuel Joakim Erdfelt a écrit : The order is a little odd. I would personally put the User's Guide as more important than the Developer's Guides. The FAQ should be higher in the list too. - Joakim Emmanuel Venisse wrote: Hi, Here is the structure of the documentation I'd like to have for 1.1-final. Installation/Upgrade Guides Installation (standalone, webapp, service...) Release Notes Upgrade Administrator's Guides Managing Users and Security Adding Project Group Managing Builders Managing JDKs Managing Profiles Managing Schedules Managing General Configuration (configuration and appearance) Developer's Guides SVN repository structure XML-RPC TO BE DEFINED User's Guides Managing a project Add (maven1, maven2, Ant, Shell), Remove, Edit SCM security hints Managing Build Definitions Managing Notification mail to an address, mail to latest committers, irc, jabber, msn, wagon, alwaysSend... Building a project Release Management Knowledge Base FAQ (sorted by categories, maybe one menu entry by category) Old versions 1.0.x site About videos, I don't know yet where to put them. Maybe a video attached to a page (like Add Maven2 project) instead of a specific videos page in the menu. WDYT? Emmanuel
Re: Documentation Plan
Wendy Smoak a écrit : On 9/24/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: For 1.0.3 doc, we'll let it as is but we must remove specific 1.1 doc in it. How will this be handled? Do we need continuum/1.0.3 and continuum/1.1 on the website? I don't know but if we remove 1.0.3 doc, how 1.0.3 users will read it? Emmanuel
[results] [vote] Release Continuum 1.1-beta-3
Below are the results of this vote: 3 Binding Votes (Wendy, Jesse, and Myself) 1 Non-binding vote (Olivier) I'll finalize the release and will send an update. Thanks, Emmanuel Emmanuel Venisse a écrit : Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-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: how to install continuum betat 2 into tomcat?
It would be better to use 1.1-beta-3 if you don't want to migrate your db between versions. I released it and I'll do the official announce in few hours when all files will be mirrored. but the continuum doc for tomcat is available there: http://docs.codehaus.org/display/CONTINUUMUSER/Continuum+on+Tomcat Emmanuel I am Who i am a écrit : Is there any doc available for this?
Re: build definition used on build result
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/
Re: build in error fix not working?
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/
Re: build definition used on build result
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/
Documentation Plan
Hi, Here is the structure of the documentation I'd like to have for 1.1-final. Installation/Upgrade Guides Installation (standalone, webapp, service...) Release Notes Upgrade Administrator's Guides Managing Users and Security Adding Project Group Managing Builders Managing JDKs Managing Profiles Managing Schedules Managing General Configuration (configuration and appearance) Developer's Guides SVN repository structure XML-RPC TO BE DEFINED User's Guides Managing a project Add (maven1, maven2, Ant, Shell), Remove, Edit SCM security hints Managing Build Definitions Managing Notification mail to an address, mail to latest committers, irc, jabber, msn, wagon, alwaysSend... Building a project Release Management Knowledge Base FAQ (sorted by categories, maybe one menu entry by category) Old versions 1.0.x site About videos, I don't know yet where to put them. Maybe a video attached to a page (like Add Maven2 project) instead of a specific videos page in the menu. WDYT? Emmanuel
Re: Continuum Model and Modello
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. b) Since 1.1 is in final stages, also wanted to see what other think about brainstorming ideas for the next Continuum release on wiki. But this might be a candidate for a separate thread. Yes, it's a separate thread ;) Emmanuel Thoughts? Thanks, Rahul
Re: Upgrade Mysql database from Continuum 1.1-beta-2 to beta-3
Hi, Commands to run will be available when we'll update the site for the release of 1.1-beta-3 For the moment, it isn't possible to migrate a mysql db (and other db that isn't derby) with this tool. We'll fix it in next version. But maybe you can write a patch for it so you'll can migrate, I can explain to you the codee to modify, it's a simple patch to write. Emmanuel Damien Lecan a écrit : Hello, I would like to upgrade my continuum 1.1-beta-2 instance running with Mysql to continuum beta-3 version. I tried to use data-management-cli-1.1-beta-3-app.jar but it doesn't seem to support Mysql database. This tool always wants to use Derby JDBC driver. How to specify JDBC driver ? Any doc somewhere about this tool ? Thanks Damien
Re: Upgrade Mysql database from Continuum 1.1-beta-2 to beta-3
http://jira.codehaus.org/browse/CONTINUUM-1481 Emmanuel Venisse a écrit : Changes must be done in http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-data-management/data-management-cli/src/main/java/org/apache/maven/continuum/management/DataManagementCli.java Look at the end to see derby parameters. A good patch would be to add an OTHER supported db that take parameters from the cli args Emmanuel Damien Lecan a écrit : 2007/9/21, Emmanuel Venisse [EMAIL PROTECTED]: Commands to run will be available when we'll update the site for the release of 1.1-beta-3 For the moment, it isn't possible to migrate a mysql db (and other db that isn't derby) with this tool. We'll fix it in next version. But maybe you can write a patch for it so you'll can migrate, I can explain to you the codee to modify, it's a simple patch to write. Ok, let's try, i've just checkout continuum 1.1 beta-3 source code. Damien
Re: Upgrade Mysql database from Continuum 1.1-beta-2 to beta-3
Damien Lecan a écrit : 2007/9/21, Emmanuel Venisse [EMAIL PROTECTED]: http://jira.codehaus.org/browse/CONTINUUM-1481 Ok, I've got a patch which allows data-management-cli (dmc) to use Mysql jdbc driver class or any other driver BUT : - dmc always fails to download dependencies. It doesn't seem to use settings.xml configuration file (I'm working behind a proxy). I found a workaround to do my patch but many people will have problems with that - dmc fails to export data with the following error : NestedThrowablesStackTrace: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Unknown column 'ELEMENT.ALWAYS_BUILD' in 'field list' at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936) ... at org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:164) The export tool itself fails to read old database schema. Something else to configure ? to export 1.1-beta-2 db, you must use dmc 1.1-beta-2 and to import in 1.1-beta-3 db, dmc 1.1-beta-3 About the settings.xml that isn't use, I fixed it this morning in trunk. Emmanuel
Re: relative path
It isn't too late for 1.1, we're releasing beta-3 and final won't be normally before one month. For your patch, please attach it to an issue. Emmanuel CAUSSE David MTP CAP GEM a écrit : Hi, I send to the list a patch to add better support for SCM providers that honour the relativePath field in ScmCheckoutResult. The idea is to add a new field in project because I think it's project specific and not build specific. This patch allow group builds to work with SCM like clearcase or SYNERGY (I'll send a scm patch soon for this one). I hope it is not too late for 1.1... -- David Causse DECLIC - DTE - Génie Logiciel - GCCL Tél: 04 67 04 79 09 Post-scriptum La Poste Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et La Poste, son contenu ne représente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en avertir immédiatement l'expéditeur.
Re: [vote] Release Continuum 1.1-beta-3
You can fix it by setting LC_ALL. Some threads give the solution: http://mail-archives.apache.org/mod_mbox/maven-continuum-users/200709.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-users/200705.mbox/[EMAIL PROTECTED] Emmanuel jrduncans a écrit : Emmanuel Venisse wrote: Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-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 This issues is preventing me from being able to check out projects from Subversion: http://jira.codehaus.org/browse/SCM-320
Re: [vote] Release Continuum 1.1-beta-3
Look at this page: http://redback.codehaus.org/integration/ldap.html Emmanuel jrduncans a écrit : Thanks. I had tried that, but I had an error in my startup script that was causing it not to effect Continuum. It's working now. The comments in apps/continuum/webapp/WEB-INF/classes/META-INF/plexus/application.xml for LDAP configuration point to documentation at a broken URL: apps/continuum/webapp/WEB-INF/classes/META-INF/plexus/application.xml -Stephen Emmanuel Venisse wrote: You can fix it by setting LC_ALL. Some threads give the solution: http://mail-archives.apache.org/mod_mbox/maven-continuum-users/200709.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/maven-users/200705.mbox/[EMAIL PROTECTED] Emmanuel jrduncans a écrit : Emmanuel Venisse wrote: Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-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 This issues is preventing me from being able to check out projects from Subversion: http://jira.codehaus.org/browse/SCM-320
Re: About CONTINUUM-1218
CAUSSE David MTP CAP GEM a écrit : Hi, in org.apache.maven.continuum.core.action.CheckoutProjectContinuumAction.execute(132) The default build definition is updated with the relative path into a finally block when relateivePath is not empty. This action shouldn't be done when first checkout is success instead of oldState == NEW ? If the first checkout failed there is no other options to recreate the project. maybe, if you can provide a patch and I'll look at it. I have another question : if the default buildDefinition is a group one, will this break my other builds within this group by setting a project specific relative path into a shared build definition? for project builds that require a relative path, it isn't possible to define it in group build def because I don't think other projects in the group use the same project relative path. Emmanuel Thanks for your help. -- David Causse DECLIC - DTE - Génie Logiciel - GCCL Tél: 04 67 04 79 09 Post-scriptum La Poste Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et La Poste, son contenu ne représente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en avertir immédiatement l'expéditeur.
[vote] Release Continuum 1.1-beta-3
Hi, Continuum 1.1-beta-3 is ready for release The highlights are - lot of bug fixes - LDAP support for authentication (thanks jesse) - performance improvement - committer mail notification The Release Notes is available there: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13661 The binaries are available there: - Runtime: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-3/continuum-plexus-runtime-1.1-beta-3-bin.tar.gz - Webapp: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/continuum-webapp/1.1-beta-3/continuum-webapp-1.1-beta-3.war - data management cli: http://people.apache.org/builds/maven/continuum/1.1-beta-3/org/apache/maven/continuum/data-management-cli/1.1-beta-3/data-management-cli-1.1-beta-3-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: pomRelativePath
CAUSSE David MTP CAP GEM a écrit : Hi, in org.apache.maven.continuum.scm.DefaultContinuumScm.checkOut(140) I can see : context.put( pomRelativePath, res.getRelativePathProjectDirectory() ); It seems to be unused, am I wrong? right, it's a bug and I fixed it few seconds ago. It is exactly what I need for the SYNERGY scm provider to work properly with continuum. I need to set and store a relative path for my projects, unless group builds won't work because pom files are not at the workingDirectory's root. Thanks for your help. -- David C. Post-scriptum La Poste Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et La Poste, son contenu ne représente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en avertir immédiatement l'expéditeur.
Re: Problems with MungedHttpsURL
Can you file an issue and attach to it your patch? We'll look at it later.
Thanks
Emmanuel
Dariusz Nowak a écrit :
Dear Developers,
For a long time I have tried to be able to add a new Maven2 project from
our SVN repository.
Unfortunately it was not possible neither in 1.0.2 nor 1.1-b2.
Finally I have found the cause of problems. It is the MungedHttpsURL
class. I do not know why but it does not work with my company's SVN
server. Every time I tried to create a new project 401 HTTP error was
returned to the continuum.
After hacking continuum to use HttpClient everything started to work.
Attached my changes.
Please let me know what information you need to fix the issue in future
releases.
BR,
Dariusz
---
src/main/java/org/apache/maven/continuum/project/builder/AbstractContinuumProjectBuilder.java
(revision 572578)
+++
src/main/java/org/apache/maven/continuum/project/builder/AbstractContinuumProjectBuilder.java
(working copy)
@@ -34,6 +34,10 @@
import java.net.URL;
import java.net.UnknownHostException;
+import org.apache.commons.httpclient.HttpClient;
+import org.apache.commons.httpclient.UsernamePasswordCredentials;
+import org.apache.commons.httpclient.methods.GetMethod;
+
/**
* @author a href=mailto:[EMAIL PROTECTED]Trygve Laugstoslash;l/a
* @version $Id$
@@ -51,11 +55,32 @@
getLogger().info( Downloading + metadata.toExternalForm() );
InputStream is = null;
+
+GetMethod get = null;
if ( metadata.getProtocol().startsWith( http ) )
{
-is =
-new MungedHttpsURL( metadata.toExternalForm(),
username, password ).getURLConnection().getInputStream();
+
+//is =
+//new MungedHttpsURL( metadata.toExternalForm(),
username, password ).getURLConnection().getInputStream();
+HttpClient client = new HttpClient();
+
+getLogger().info(Using HttpClient to get the resource,
credentials - user: + username + , password: + password);
+
+if (username != null) {
+client.getState().setCredentials(null, null, new
UsernamePasswordCredentials(username, password));
+}
+
+get = new GetMethod(metadata.toExternalForm());
+
+if (username != null) {
+get.setDoAuthentication(true);
+}
+int status = client.executeMethod(get);
+
+getLogger().info(Request status: + status);
+
+is = get.getResponseBodyAsStream();
}
else
{
@@ -115,6 +140,9 @@
is.close();
writer.close();
+if (get != null) {
+get.releaseConnection();
+}
return file;
}
Re: Wrong icons immediately after adding projects
Wendy Smoak a écrit : When I add a multi-module project, the project group summary shows the 'cancel build' icon for the first project, and 'queued build' icons for the rest. This is incorrect, nothing is building or queued at that time. Not exactly. All projects are in queue. It isn't the build queue but the checkout queue, so icons are correct. If I navigate away and come back, it correctly shows the 'build project' icon for all of them. because your projects are checked out. (This is in the 5th column from the right in r574073 built today.)
Re: SCM Matrix for Continuum?
I think it's up to date but I'll verify. cloumns that are used by Continuum are : changelog, checkout, update The release part use checkin, status, tag columns too edit/unedit and login columns can be used by some scm tools. Emmanuel Wendy Smoak a écrit : I'm in need of an SCM Matrix for a Continuum talk... can someone familiar with maven-scm take a look at the one on the wiki and let me know if it's up to date? http://docs.codehaus.org/display/SCM/SCM+Matrix Also, what columns are relevant for Continuum? Thanks,
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Without sql command: 1- with data-management: export the db java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_old_db -mode EXPORT 2- start Continuum to create an empty db (with the good schema) 3- stop Continuum 4- import datas with data-management java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_new_db -mode IMPORT 5- start Continuum data-management jar is available here: http://repo1.maven.org/maven2/org/apache/maven/continuum/data-management-cli/1.1-beta-2/data-management-cli-1.1-beta-2-app.jar Emmanuel Jesse McConnell a écrit : And this is what I did... I pulled the database someplace that I could run squirrelsql and ran the following sql statements to update the database, then I put the database back into place and started the updated version. -- ALTER TABLE INSTALLATION ADD installation_id integer not null default 0; ALTER TABLE PROFILE_ENVIRONMENTVARIABLES ADD installation_id_eid integer; alter table profiles add builder_installation_id_oid integer; alter table profiles add jdk_installation_id_oid integer; alter table projectdependency add modified_dependencies_id_own integer; alter table projectdependency add modified_dependencies_integer_idx integer; alter table profile_environmentvariables drop foreign key profile_envi2v_fk2; alter table profile_environmentvariables drop foreign key profile_envi2v_fk1; alter table profiles drop foreign key profiles_fk1; alter table profiles drop foreign key profiles_fk2; alter table installation drop primary key; alter table installation add primary key (installation_id); alter table profiles add CONSTRAINT profiles_fk1 foreign key (builder_installation_id_oid) references installation (installation_id); alter table profiles add CONSTRAINT profiles_fk2 foreign key (jdk_installation_id_oid) references installation (installation_id); alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk2 foreign key (installation_id_eid) references installation (installation_id); alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk1 foreign key (id_oid) references profiles (id); --- cheers! jesse On 8/17/07, Brett Porter [EMAIL PROTECTED] wrote: 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: Splitting up the Installations form
+1 Wendy, can you file an issue? Olivier, do you want to work on it? Emmanuel Wendy Smoak a écrit : I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts?
Re: Splitting up the Installations form
Maybe like notifier screens, we can have a process an installation in two steps: screen1: choose the installation type (tool or environment variable) screen2(tool): version, path, parameters... screen2(env var): name, value Emmanuel LAMY Olivier a écrit : Hi, Displaying the field (Environment Variable name bla bla ...) only when the user choose the type environnemt variable in the list box ? -- Olivier -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : mardi 4 septembre 2007 05:07 À : continuum-dev@maven.apache.org Objet : Splitting up the Installations form I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts? -- Wendy This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. **
Re: The specified resource isn't a file or the protocol used isn't allowed.
Graham Leggett a écrit : On Mon, September 3, 2007 12:39 pm, Graham Leggett wrote: When I enter the POM url of https://svn.server/svn/alchemy/Rhapsody/Development/native/trunk/pom.xml; I get the error: The specified resource isn't a file or the protocol used isn't allowed. Looking at the svn server log, it seems that when no username and password is specified, continuum correctly connects to the SSL svn server, 401 access denied is returned by the server, and continuum correctly handles the access denied condition. But - when a username and password *are* specified, continuum makes no attempt to contact the svn server, nothing appears in the server log. It looks like continuum is currently not capable of supporting building code from repositories which are password protected. I use it every day with user/password over https access and it works fine. For users discussion, please [EMAIL PROTECTED] Emmanuel
Re: [jira] Closed: (CONTINUUM-358) User Authentication via LDAP
I'd prefer too ;) Brett Porter a écrit : 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
Brett Porter a écrit : 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). I think it's necessary to record a build result so users know there is a problem with the SCM connection. Continuum can't know if the scm url is wrong or if the scm server is unreachable. 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. 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. Emmanuel 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: Anyone seen Continuum hanging in recent versions?
The problem is in beta-2 when the fresh build option is checked and the project contains lot of files in scm. The build controller merged scm results with old build results but it mustn't do it. I fixed this problem yesterday. Emmanuel Brett Porter a écrit : 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: CONTINUUM-605: notification feature
The patch doesn't seem to be complete, it's only a new class with a patch in other classes or components.xml I'll look at it in details to see if we can include it in 1.1 Emmanuel Brett Porter a écrit : 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
Re: error states
Brett Porter a écrit : 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 sure, I don't think we already have an issue about it (I'll search) so I'll create a new one 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) I'll check for the missing POM parent If we have some other case, we'll fix them later. Emmanuel
Re: [vote] Release Continuum 1.1-beta-2
4 binding +1's from PMC members: Brett, Stephane, Deng, Emmanuel I started to deployed all things. Thanks, Emmanuel Emmanuel Venisse a écrit : 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
[result] Release Continuum 1.1-beta-2
Change subject ;) Emmanuel Emmanuel Venisse a écrit : 4 binding +1's from PMC members: Brett, Stephane, Deng, Emmanuel I started to deployed all things. Thanks, Emmanuel Emmanuel Venisse a écrit : 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
[announce] Continuum 1.1-beta-2 is released
The maven/Continuum team is pleased to announce the Continuum 1.1-beta-2 release Highlights are: * lot of bug fixes * Installations/profiles screens improvement * screen flow improvement in Add Project part * cancellable builds You can grab the latest release from: http://maven.apache.org/continuum/download.html Below is the jira release notes for this release. Release Notes - Continuum - Version 1.1-beta-2 Bug * [CONTINUUM-617] - javax.jdo.JDODataStoreException: Insert request failed * [CONTINUUM-666] - Added (Jabber) Notifiers didn't persist * [CONTINUUM-927] - Internal error deleting a used schedule * [CONTINUUM-971] - Symbolic links are traversed on deletion * [CONTINUUM-1079] - show cancel build as disabled, not build now a disabled when build is in progress, but user has insufficient permissions * [CONTINUUM-1211] - Mail notification sent for Succes even though it is configured for Error, Failure and Warning only * [CONTINUUM-1265] - NullPointerException when adding modules to a project group * [CONTINUUM-1301] - JDO delete failure * [CONTINUUM-1303] - working directory in database should be a relative path so that configuration changes take effect * [CONTINUUM-1304] - cannot un-set deployment repository directory in configuration page * [CONTINUUM-1305] - after adding a project to a group from the group page, you should be returned to the group page * [CONTINUUM-1310] - cancel build button no longer present when a build is in progress * [CONTINUUM-1346] - Error while parsing test results * [CONTINUUM-1354] - meta refresh causes build loop * [CONTINUUM-1356] - intermittent (machine wise) test failure on trunk * [CONTINUUM-1359] - Installations removed from a profile when Save is clicked. * [CONTINUUM-1361] - saving a profile is confusing * [CONTINUUM-1362] - add profile page should take you to the edit page to add installations afterwards * [CONTINUUM-1369] - Profile add button does not work in IE6 * [CONTINUUM-1372] - NPE adding project group * [CONTINUUM-1373] - profile/installations pages must check users rights * [CONTINUUM-1374] - profile without jdk causes NPE in mail notification * [CONTINUUM-1375] - mail content is false regarding the profile/installations used in the build. * [CONTINUUM-1376] - Infernal gray dot is mocking me! * [CONTINUUM-1378] - Adding installations to profiles doesn't work in internet explorer, works in firefox * [CONTINUUM-1383] - build queued icons aren't showing up which is kind of confusing * [CONTINUUM-1385] - Foreign key konstraint violation Improvement * [CONTINUUM-980] - After deleting a project from a group, the UI flow should return to the group summary display. * [CONTINUUM-981] - Remove button on group actions is ambiguous and should be renamed Delete Group or Remove Group. * [CONTINUUM-982] - Project Group Actions should be renamed Group Actions to avoid confusion. * [CONTINUUM-983] - There should be real Group Actions that affect members of the group, and can affect subsets of group members based on selection. * [CONTINUUM-1086] - First form element should have focus * [CONTINUUM-1232] - Continuum should not steal window focus on page load * [CONTINUUM-1236] - Property in a notifier address element is not evaluated * [CONTINUUM-1243] - wording to explain no-build case * [CONTINUUM-1266] - Screen navigation should return to project view after adding a project to a group * [CONTINUUM-1349] - Improve add project screen flow * [CONTINUUM-1363] - create automatic profiles for each installation for simpler configuration by JDK, etc. * [CONTINUUM-1364] - should be able to configure MAVEN_OPTS for a Maven 2 installation * [CONTINUUM-1365] - unable to edit the name of an installation already created * [CONTINUUM-1368] - CLONE -Continuum doesn't work with MySQL New Feature * [CONTINUUM-990] - Pass some continuum information to build tools when executing a build Task * [CONTINUUM-1357] - release data-management with beta2
Re: [continuum build trunk - FAILED - update] Wed Aug 15 03:00:01 GMT 2007
M2_HOME was changed in ci_continuum.sh but it wasn't in .profile. I'm changing it and will see if it's better Emmanuel Brett Porter a écrit : 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
Re: Solving the notification problem
Thanks. Emmanuel Brett Porter a écrit : 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
[vote] Release Continuum 1.1-beta-2
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: svn commit: r564614 - in /maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution: AbstractBuildExecutor.java ant/AntBuildExecutor.java maven/m1/MavenOneBuildExecut
ok, I'll look at it
Christian Gruber a écrit :
I wonder if this could be expanded to include an alternate reference
with the SCM version number being used as a build identifier. While
this would suck with CVS, with P4 or SVN it would tend to better
identify the build, as continuum build numbers are local to the build
machine and can end up reset if you have to re-install.
That, or the ability to manually reset the current or base build number.
Christian.
On Aug 10, 2007, at 10:58 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Aug 10 07:58:57 2007
New Revision: 564614
URL: http://svn.apache.org/viewvc?view=revrev=564614
Log:
[CONTINUUM-990] Pass some continuum information to build tools (m1,
m2, ant) when executing a build
Modified:
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/AbstractBuildExecutor.java
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/ant/AntBuildExecutor.java
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/maven/m1/MavenOneBuildExecutor.java
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/maven/m2/MavenTwoBuildExecutor.java
Modified:
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/AbstractBuildExecutor.java
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/AbstractBuildExecutor.java?view=diffrev=564614r1=564613r2=564614
==
---
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/AbstractBuildExecutor.java
(original)
+++
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/AbstractBuildExecutor.java
Fri Aug 10 07:58:57 2007
@@ -42,6 +42,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import java.util.Properties;
/**
* @author a href=mailto:[EMAIL PROTECTED]Trygve Laugstoslash;l/a
@@ -263,6 +264,16 @@
envVars.put( installation.getVarName(),
installation.getVarValue() );
}
return envVars;
+}
+
+protected Properties getContinuumSystemProperties( Project project )
+{
+Properties properties = new Properties();
+properties.setProperty( continuum.project.group.name,
project.getProjectGroup().getName() );
+properties.setProperty( continuum.project.lastBuild.state,
String.valueOf( project.getOldState() ) );
+properties.setProperty( continuum.project.lastBuild.number,
String.valueOf( project.getBuildNumber() ) );
+properties.setProperty( continuum.project.nextBuild.number,
String.valueOf( project.getBuildNumber() + 1 ) );
+return properties;
}
public boolean isBuilding( Project project )
Modified:
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/ant/AntBuildExecutor.java
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/ant/AntBuildExecutor.java?view=diffrev=564614r1=564613r2=564614
==
---
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/ant/AntBuildExecutor.java
(original)
+++
maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/execution/ant/AntBuildExecutor.java
Fri Aug 10 07:58:57 2007
@@ -32,8 +32,10 @@
import java.io.File;
import java.util.Collections;
+import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
+import java.util.Properties;
/**
* @author a href=mailto:[EMAIL PROTECTED]Trygve Laugstoslash;l/a
@@ -72,17 +74,26 @@
String executable =
getInstallationService().getExecutorConfigurator(
InstallationService.ANT_TYPE )
.getExecutable();
-String arguments = ;
+StringBuffer arguments = new StringBuffer();
String buildFile = buildDefinition.getBuildFile();
if ( !StringUtils.isEmpty( buildFile ) )
{
-arguments = -f + buildFile + ;
+arguments.append( -f ).append( buildFile ).append( );
}
-arguments +=
-StringUtils.clean( buildDefinition.getArguments() ) +
+ StringUtils.clean( buildDefinition.getGoals() );
+arguments.append( StringUtils.clean(
buildDefinition.getArguments() ) ).append( );
+
+Properties props = getContinuumSystemProperties( project );
+for ( Enumeration itr = props.propertyNames();
itr.hasMoreElements(); )
+{
+String name = (String) itr.nextElement();
+String value = props.getProperty( name );
+arguments.append( \-D ).append( name ).append( =
).append( value
Re: redback-1.0-alpha-2 released
+1 to upgrade before Continuum 1.1-beta-2 Emmanuel Jesse McConnell a écrit : I released the alpha-2 of redback 1.0 this morning. It is working its way out into the main repositories and when its there I think we can safely upgrade continuum and archiva to it. Rather excited, this is the first time we haven't been tracking -SNAPSHOT on these apps and have been patiently waiting on redback releases.. a mini milestone! :) cheers, jesse
Re: Solving the notification problem
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?
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: Database model change for beta-1
I think null value will be enough. I think we'll need to test the null value in the UI but it isn't a problem. Emmanuel Brett Porter a écrit : 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: Solving the notification problem
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. 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. In 1.2, we'd can remove it and let users choose how they want to receive notifications. Emmanuel Brett Porter a écrit : Hi, I would like to see us address the problems of mass-notification which tends to be a blight on Continuum when dealing with projects with lots of modules in 1.1. I think with this simple usability improvement, the perception of the quality of the overall system would be greatly improved. So I wanted to start this thread to brainstorm ideas for what we might do to make it less noisy, but just as effective. I have some thoughts, but I'm interested to hear others first. What do others think? Should this be in 1.1, and if so how should it work? Cheers, Brett
Re: some issues for rescheduling?
I will look at them this week, sorry for the delay. Emmanuel Brett Porter a écrit : 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
