Re: [Discussion] Continuum 2.0 Roadmap
Rahul Thakur 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. Annotations is nice, but really isn't what is stopping Continuum from moving ahead. Moving to standardized, mature technologies will probably be smart in the long run as it is easier to get help and for other to contribute. 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. 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. 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. JPA annotations is probably a good idea as you'll get IDE support etc from the start. 3) Builders > Build definitions Just thinking out loud here... Does anyone else see the current Continuum model to be centered around 'Project'? What do you think about 'Build' or BuildDefinition being central? You can add one or more Projects to a Build - we don't need Project Groups, as all we deal with is a Build. Order and dependency can be imposed on a Build composed of more than one project. Notifiers are added to a Build and BuildResult(s) produced for a Build. This is way to detailed to be on a roadmap. 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. This is something that definitely should be at the core of the 2.0 architecture. 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? Same as the previous point, +1. 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. GWT vs anything else again way to specific when you're talking roadmap. Doing experiments is a good thing, I'm not trying to shoot anything down here, but focus needs to stay on *features* and then we can try to find a suiting set of *technologies* when/if it comes down to that. 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. Reporting is something that definitely can be improved. 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. More documentation is always useful, yes. 8) Installation Lastly, I think it would nice to have a core Continuum install to be lean and small with features that can be added by dropping in relevant JARs (and minimal or no configuration). We can actually try different options with development releases before finalizing what should go into the main distro (if at all we break it up) - sounds reasonable? I'm not sure what you're trying to say here. The current way to installing Continuum (unpack, run bin/plexus.sh) is still giving me "wow" when doing demos. What I would like to see is talk about the different ways of doing remoting and tool integration (IDEs in particular, but also desktop widgets). Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug in their own steps and functionality. If someone is going down the plugin path, it
Re: [vote] Request Graduation to a TLP
Emmanuel Venisse wrote: Hi, Below is the current proposal for the Continuum TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 +1 -- Trygve
Re: [discuss] Graduate Continuum to its own TLP
Emmanuel Venisse wrote: Hi, At the begin, Continuum was designed to support maven2 projects so we thought it was good to put it under the maven umbrella. But now it supports other project types (ANT, shell scripts) too so it isn't centered on maven projects. An other thing is that we have lot of users (not only maven users) with actually 450 subscribers to the users list, and I think we can get more with a TLP project. My last point is that with the maven project, it isn't easy to add new committers because a new committer have the hand on all maven umbrella code and not only one project. 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. WDYT? I think Continuum fits both under the Maven umbrella and and a separate TLP on Apache and I would support both outcomes. -- Trygve
Re: [vote] release continuum 1.1-beta-1
Emmanuel Venisse wrote: Hi, I'd like to do a release of the 1.1-beta-1 +1, works for me. -- Trygve
Re: Heads up regarding VMBuild
Brett Porter wrote: Hi folks, I'm currently doing the rounds of all the people using Continuum on VMBuild. The set up on there ballooned despite the box being underpowered and the installation intended to be experimental, so was never very well maintained. We have a new box to move vmbuild to now and with the features in continuum 1.1 I think we can make a decent go at it. I was going to set up the next release (with profiles and 'single module build' support) and start setting up projects on there and maintain it properly. Hopefully we can get some additional feedback in to the 1.1 final release. Is anyone interested in helping out? I must have missed that memo, what is VMBuild? A VMWare instance running continuum? -- Trygve
Re: Continuum Profiles
Emmanuel Venisse wrote: I don't know yet if we must add the second part in a second beta or in 1.2. The first part will change the database and the second part too. We'll need a migration tool between between actual db and first part and an other between first part and second part. Maybe we can change all db things in the first part so we won't need db migration between first and second parts. Do you know what will go to 1.2? It would be good to define it in jira. It shouldn't go into 1.1 as 1.1 is already way behind schedule and should focus on getting the features already in or scheduled to be added. The idea is good and I think it will be a very useful feature, but the focus should be on delivering a final 1.1 before anything else. -- Trygve
Re: svn commit: r535724 - in /maven/continuum/trunk/continuum-webapp/src/main: java/org/apache/maven/continuum/web/bean/ProjectGroupUserBean.java webapp/WEB-INF/jsp/projectGroupMembers.jsp
[EMAIL PROTECTED] wrote: Author: oching Date: Sun May 6 20:34:07 2007 New Revision: 535724 URL: http://svn.apache.org/viewvc?view=rev&rev=535724 Log: CONTINUUM-1256 Applied patch submitted by Teodoro Cue Can you please include some information about what changed when committing stuff? It's annoying having to go through the patch and/or read the issue for smaller stuff. [snip] -- Trygve
Re: XML RPC security
Rahul Thakur wrote: Sounds good! Pointers would be great, if you have it handy :-) If you're using the servlet way (which I'd recommend) you should be able to use Redback as a filter for that URL. Way easier that my hack. -- Trygve TIA, Rahul - Original Message ----- From: "Trygve Laugstøl" <[EMAIL PROTECTED]> To: Sent: Saturday, April 28, 2007 12:14 AM Subject: Re: XML RPC security Rahul Thakur wrote: Hey guys, Some quick notes on the security for XML RPC interface. This is what I am thinking... Have an AuthenticatedXmlRpcService component that services the xml rpc requests. The first request from a client to the service is a request for authentication. A successful authentication returns an authentication Token, which is passed along with subsequent requests by the client. A Token can go stale (configurable time period?) if there were not requests detected for it. Also, we could have a service that answers any polling requests and keeps a Token 'alive'. How about using HTTP and Redback for security? We can make the XML-RPC server listen on localhost:8000 only and then make a servlet that is proxying to localhost:8000/xml-rpc. The proxying servlet should come after a Redback security filter. I made a servlet like that once acting as a facade for a Subversion repository which I think I added to Plexus (aka the kitchen sink), if not I can dig it up for you. -- Trygve
Re: XML RPC security
Rahul Thakur wrote: Hey guys, Some quick notes on the security for XML RPC interface. This is what I am thinking... Have an AuthenticatedXmlRpcService component that services the xml rpc requests. The first request from a client to the service is a request for authentication. A successful authentication returns an authentication Token, which is passed along with subsequent requests by the client. A Token can go stale (configurable time period?) if there were not requests detected for it. Also, we could have a service that answers any polling requests and keeps a Token 'alive'. How about using HTTP and Redback for security? We can make the XML-RPC server listen on localhost:8000 only and then make a servlet that is proxying to localhost:8000/xml-rpc. The proxying servlet should come after a Redback security filter. I made a servlet like that once acting as a facade for a Subversion repository which I think I added to Plexus (aka the kitchen sink), if not I can dig it up for you. -- Trygve
Re: DB schema migration
Stephane Nicoll wrote: Can I be sure at least that the DB model won't change as from alpha-1? If so I can maybe drop completely my database and recreate my projects. We've been over this before, but I'll repeat: Alphas give no guarantee of API (including DB) stability. Hopefully it won't change too much, but it should in no way stop the developers from breaking stuff. The database is in particular something that can, and most likely will change in one form or another. The only thing that's supposed to be stable in Continuum are the remote interfaces (socket and xml-rpc stuff) and the internal notification APIs. What is important here is the ability to dump the database to an external DB file (xml would be a natural choice) which can be read by a newer Continuum. Hopefully 1.1 will be pretty stable so it can be released ASAP and bugs can be fixed on a 1.1.x branch. -- Trygve Thanks, Stéphane On 4/23/07, Brett Porter <[EMAIL PROTECTED]> wrote: This was one of the things I was going to try and have done before alpha-1 - I just forgot. Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. I already have the tools to do an xml export of the old tables, it just needs to somehow be set to run in dump mode using the old jpox, and import using the new one. I'll look at that during ApacheCon, I think. If anyone else wants to take the task while I'm on holidays, let me know... we should also make the tool work with 1.0.3 databases if possible. This is definitely one for the release notes, btw. alpha-1 will not work with 1.0.3 (or earlier 1.1 snapshot) databases. - Brett On 22/04/2007, at 2:10 PM, Erik Bengtson wrote: > If you guys need some tooling from JPOX, let me know and I could > plan to > implement some kind of "export" to XML, and "import" from XML. In > between > export/import you could apply Xqueries to transform data to match > the new > schema > > Quoting Stephane Nicoll <[EMAIL PROTECTED]>: > >> Hi, >> >> I'm currently running a 1.1-SNAPSHOT from February which runs ok >> except a few minor issues. I'd like to upgrade to 1.1 alpha 1 as soon >> as it's out to provide feedback & co. >> >> Last time I tried to upgrade, I had to revert because the model >> schema >> has changed and it was really difficult to update my existing >> data. Is >> there something scheduled for alpha1 regarding this (at least a >> manual >> procedure to upgrade my schema if necessary). >> >> Thanks, >> Stéphane >> > >
Re: error on continuum rpc server
Andrew Williams wrote: OK, not entirely sure what to do about this problem now... Calling getBuildResultsForProject over RPC yields this exception on the server side. Caused by: javax.jdo.JDODetachedFieldAccessException: You have just attempted to access field "modifiedDependencies" yet this field was not detached when you detached the object. Either dont access this field, or detach the field when detaching the object. at org.apache.maven.continuum.model.project.BuildResult.jdoGetmodifiedDependencies(BuildResult.java) at org.apache.maven.continuum.model.project.BuildResult.getModifiedDependencies(BuildResult.java:219) ... 20 more Does anyone have suggestions on how to fix this? IIRC you can set fields that the XML-RPC tool shouldn't try to unmarshall when crawling the object graph. But as I wrote this two years ago or something my mind might be slipping :) I'm going to be reading Continuum source code all afternoon today so if you ping me on IRC we can see if we can figure it out there. -- Trygve
Re: Poll: release continuum alpha
Stephane Nicoll wrote: On 2/23/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: A milestone should focus on showing the fancy new features and bugs fixed. Stuff like security, upgrading existing databases etc are all secondary. I understand what you mean but I think database upgrade is very important because users will want to test continuum 1.1 with their data. This first release will also give you a chance to test your upgrade procedure. Given than adding projects to Continuum is so easy it is (imo) not an important option and should in no way stand in the way of a *milestone* release. To me this release is important for two different cases: 1) The last release was April 25th 2006. That is close to a year and I doubt 1.1 will be out by April 25th 2007 in any case, I would have serious issues voting on a release that you can't say is done today and start testing from now till the 25th. The point is that the users need to see progress in features and stability. 2) There are as far as I know only "old" developers working on Continuum these days and by getting stuff out it will hopefully spark a few people to start contributing patches and possibly become developers. I'm also sure a lot of bug reports will be filed and the development will make sure that they're going in the right direction. -- Trygve
oching, please subscribe to [EMAIL PROTECTED]
your commit emails are beeing moderated. -- Trygve
Re: [vote] merge id-refactor branch changes
Rahul Thakur wrote: [snip] Can you please come up with a realistic use case where IDs would start on something other than 0 or 1? The database is controlled by Continuum and is an internal thing which we have complete control over. I don't have a specific use case for Continuum handy, but I guess Continuum can be used in other products/projects. Not sure I understand what you mean that the database is controlled by Continuum? I mean that the database, it's tables and content is under Continuum's control and it's up to Continuum to define the types of its domain. In this case an int was chosen because the ability to have 4 billion projects is sufficient. IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. Ok, agree on this one. Breaking API changes should be a change in major version. :) -- Trygve
Re: [vote] merge id-refactor branch changes
Christian Edward Gruber wrote: Trygve Laugstøl wrote: 1.0 to a 1.1 is not the time when you break an API. You can add stuff with minor released, but not break things. This is the versioning conventions used for all Maven-related projects. Perhaps trunk should be 2.0, but as long as it's 1.1 it can't break the API. Well, in the Java world, this convention (While good) is not very well followed. I agree, however, that 1.1. should be backwards compatible in a good versioning system, so I support your notion that trunk should be 2.0. I think there is enough change that is substantial enough in operation and features that 2.x is probably a more useful description. This isn't a small increment in functionality. It is the standard we've been following for years. IMO there isn't a whole lot of features, just a bunch of (very useful) enhancements. To me there is no reason to break the existing API as from what I can tell there haven't been any fundamental changes in the APIs and concepts on how Continuum works. This is in no way meant as a critique to all the hard work all the guys has been putting in Continuum. I've heard nothing but good stuff from all the people I have gotten to try out Continuum trunk, many who are still running it in production. I thank all of you for your hard work! -- Trygve
Re: [vote] merge id-refactor branch changes
Rahul Thakur wrote: Trygve Laugstøl wrote: Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. Yep, I know, I was referring to the +ve 2 billions. I could say a case where Id generation could be set to start from a fairly large value and so are the Id sequence increments. One could argue this is an edge case ;-). Can you please come up with a realistic use case where IDs would start on something other than 0 or 1? The database is controlled by Continuum and is an internal thing which we have complete control over. IMHO the version change to 1.1 is a fair indication that the API might have changed. Having said that, I will go with whatever most of us think sounds practical :-) The only thing you can do is to add stuff, not break existing code. -- Trygve
Re: [vote] merge id-refactor branch changes
Christian Edward Gruber wrote: Um, 1.0 to 1.1 seems like the right time to break an api if you are going to eventually. Better if it were a 1.x to 2.x, but certainly it's not a 1.0.12 to 1.0.13 situation. I think it woudl be hard to argue on a purely needs basis. Apache as a whole is approaching 500,000 commits in their subversion repo over its lifetime, which couldn't amount to more than 4x results in any table, could it? What are the real characteristics of how many keys are generated given a repo of a certain size, etc? 1.0 to a 1.1 is not the time when you break an API. You can add stuff with minor released, but not break things. This is the versioning conventions used for all Maven-related projects. Perhaps trunk should be 2.0, but as long as it's 1.1 it can't break the API. I didn't understand the last part of your paragraph WRT to the Apache svn repository, please clarify it if I missed your point. Besides, the database will be broken and need migration or re-building between 1.0.3 and 1.1 anyway, so that's no barrier. If we're running 1.1-SNAPSHOTs, well, guess what... they're snapshots - not guaranteed to function the same upon release. Not reasons to do it, mind you, just rebuttals to some reasons to not do it. That is really not relevant in this case. We're talking about the external API for applications, not the database. Running a tool to alter the database is fine. -- Trygve Christian. Trygve Laugstøl wrote: Rahul Thakur wrote: 'int' ids are now converted to 'long' across the project and to allow really large values. This should cater to scenarios where the id generation could be started from an arbitrary large value. Won't this break the API? Yep, it would. What is the use case where 4 billion IDs isn't sufficient? 2 billion you mean :-). But this also more of something that I have noticed 'traditionally' that ids are specified as long and stored as bigints in database No, 4 billion. an int is +-2billion. Anyway, just because longs are more traditionally used that is not a good enough reason to switch to longs and break the API to me. -- Trygve
Re: Continuum and svn connections
Wendy Smoak wrote:
The ASF Subversion server limits connections to 10 per IP address, and
with several ASF projects loaded up, Continuum is regularly exceeding
this limit.
I'm not sure if it's just opening too many, or if they aren't getting
closed properly, or what, but it ends up meaning that I can't connect
to svn from anything here until they time or or otherwise go away.
Typically, I see 10 connections in CLOSE_WAIT and one in SYN_SENT.
I've had two versions of Continuum running all week, and this just
started today (with r493025.)
I would guess that something is using URL.openInputStream() without
closing it in a finally{}.
--
Trygve
Re: [vote] rbac-integration branch merge to trunk
Jesse McConnell wrote: Brett suggested we do a vote for this today so I figured I would just do that now. [-1/0/+1] vote will be open for 72 hours +1 -- Trygve
Re: svn commit: r429342 - in /maven/continuum/branches/continuum-acegi/continuum-security/continuum-security-acegi/src/test/java/org/apache/maven/continuum/security/acegi/aspectj: AbstractMethodSecuri
On Mon, 2006-08-07 at 13:56 +, [EMAIL PROTECTED] wrote: > Author: carlos > Date: Mon Aug 7 06:56:43 2006 > New Revision: 429342 [snip] > +setContinuum( (Continuum) lookup( > "org.apache.maven.continuum.Continuum" ) ); Here you should use Continuum.ROLE instead to make everything consistent. -- Trygve
Re: JPOX errors on startup
On Sat, 2006-08-12 at 05:18 -0700, Erik Bengtson wrote: > I've downloaded continuum 1.3 and collected some errors from the first > startup. > If they are expected, IMO they should not be printed to the logs, unless DEBUG > is enabled. > > > I must say the first startup takes very long. Please let me know where I can > help. > > 1- > > > jvm 1| 2006-08-12 14:00:44,656 [WrapperSimpleAppMain] INFO SCHEMA >- Initialising Catalog "", Schema "SA" using "SchemaTable" > auto-s > tart option The Continuum code is not logging this, AFAIK it somewhere between JPOX and Derby. > > 2- > > org.codehaus.plexus.personality.plexus.lifecycle.phase.StoppingException: > Error > storing the Continuum configuration. This seems to be because of other JPOX issues that we're having. I remember Emmanuel or you had some clues on how to fix this earlier which I'm pretty sure will fix this issue too. > > > 3 -- > jvm 3| 2006-08-12 14:04:59,468 [WrapperSimpleAppMain] WARN RDBMS >- Column BUILDDEFINITION.LATEST_BUILD_ID should not allow > nulls b > ut does. You can prevent nulls by specifying "allows-null" as "false" for the > ield> in the MetaData Dunno, Emmanuel? Another issue I've looked into is the two minute (or 2x 1 minute) delay when starting up. IIRC you said it was because JPOX was validating the database, and that seems to be the cause but I haven't been able to stop JPOX from validating it. I've set the three properties to false, but it didn't help. I don't have the logs here but I can make a tarball illustrating the problem later. -- Trygve
Re: svn commit: r422021 - in /maven/continuum/trunk: ./ continuum-webapp/ continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/ continuum-webapp/src/main/resources/ continuum-webapp/sr
[EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Jul 14 13:24:49 2006
New Revision: 422021
URL: http://svn.apache.org/viewvc?rev=422021&view=rev
Log:
[CONTINUUM-759] Generate plexus-request.xml with plexus-cdc
Submitted by: Jesse McConnell
Added:
maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/AbstractContinuumAction.java
(with props)
Why is this in Continuum and not in plexus-xwork?
[snip]
Added:
maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/AbstractContinuumAction.java
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/AbstractContinuumAction.java?rev=422021&view=auto
==
---
maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/AbstractContinuumAction.java
(added)
+++
maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/AbstractContinuumAction.java
Fri Jul 14 13:24:49 2006
@@ -0,0 +1,71 @@
+package org.apache.maven.continuum.web.action;
+
+/*
+ * Copyright 2001-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import org.codehaus.plexus.logging.LogEnabled;
+import org.codehaus.plexus.logging.Logger;
+import com.opensymphony.xwork.ActionSupport;
+
+/**
+ * AbstractContinuumAction:
+ *
+ * @author: jesse
+ * @date: Jul 13, 2006
+ * @version: $ID:$
+ */
+public abstract class AbstractContinuumAction
+extends ActionSupport
+implements LogEnabled
+{
+private Logger logger;
+
+public void enableLogging( Logger logger )
+{
+this.logger = logger;
+}
+
+protected Logger getLogger()
+{
+return logger;
+}
+
vvv
+protected void setupLogger( Object component )
+{
+setupLogger( component, logger );
+}
+
+protected void setupLogger( Object component, String subCategory )
+{
+if ( subCategory == null )
+{
+throw new IllegalStateException( "Logging category must be
defined." );
+}
+
+Logger logger = this.logger.getChildLogger( subCategory );
+
+setupLogger( component, logger );
+}
+
+protected void setupLogger( Object component, Logger logger )
+{
+if ( component instanceof LogEnabled )
+{
+( (LogEnabled) component ).enableLogging( logger );
+}
+}
^^^ what is this stuff used for? The container is handling the logging
configuration of the components.
[snip]
--
Trygve
Re: Listeners for build events
Ahmed Omarjee wrote: Hi, I have a requirement to perform other operations before checkout of a project, as well as after a successful or failed build. The context of why I need this is as follows; I am using PVCS at a corporate client, and have already begun writing a maven-scm-plugin for PVCS (I can't sit around waiting for Serena to contribute their plugin). Using agile methodology, I would normally perform a checkout, start the build process (if changes are detected), and on successful build apply a label to the source repository. But alas, PVCS does not have metadata locally thus a label can not be applied to the version that was originally checked out, which may result in inconsistencies. A solution we have come it with (read hack), is : - label the repository before checkout with a tag (eg. Building #123 - 01/07/2006 9:00) - checkout using that label - perform the build - and on success rename the label (which strangely PVCS supports) (eg. Build #123 - 01/07/2006 9:00) - and on failure the label is removed (which strangely PVCS also supports) Sounds good as long as all of the steps are optional and configurable. If only we could have listeners to some important events such as build start, on success, on failure, build finished, etc. this could be pluggable behaviour. Correct, this will happen before a build is even started. I don't mind having a look at this and take up the challenge of maybe implementing it, but I need some guidance and advice on the appropriateness of this as a solution. That would be great if you would like to take a look just beware that it won't be a trivial task and will take a while. This is something that has been requested several times and is something I think would be nice to add. To get started check out the Continuum code from trunk [1] and try to build it with ./build.sh. You might have to download some dependencies from Sun or likewise places but Maven should inform you. [1]: https://svn.apache.org/repos/asf/maven/continuum/trunk/ -- Trygve
Re: svn commit: r420933 - in /maven/continuum/branches/continuum-acegi/continuum-webapp/src/main/resources: commons-logging.properties log4j.properties
Trygve Laugstøl wrote: [EMAIL PROTECTED] wrote: Author: carlos Date: Tue Jul 11 10:29:53 2006 New Revision: 420933 URL: http://svn.apache.org/viewvc?rev=420933&view=rev Log: Add logging config files -1 to the log4j configuration -1 might be a bit strong, I just meant to say that we configure logging through Plexus. -- Trygve
Re: svn commit: r420933 - in /maven/continuum/branches/continuum-acegi/continuum-webapp/src/main/resources: commons-logging.properties log4j.properties
[EMAIL PROTECTED] wrote: Author: carlos Date: Tue Jul 11 10:29:53 2006 New Revision: 420933 URL: http://svn.apache.org/viewvc?rev=420933&view=rev Log: Add logging config files -1 to the log4j configuration Logging is configured through Plexus, see application.xml -- Trygve
Re: introduction
Emmanuel Venisse wrote: Thanks Erik. In Continuum, we use jpox with derby. Lot of users get some exception with them on requests that failed like foreign key violation, insert/delete errors, deadlock errors... Our problem is this errors doesn't appears all the time and it's very difficult to reproduce them. I'm not sure (but I think) errors are in jpox and not in derby. I know deadlock lock and timeout lock are fixed in the new derby version and we'll update it. Another issue I would like to figure out is why jpox+derby is using exactly 2.0 minutes to start up. Thanks for starting this effort, we've been really close to dumping jpox unless we get some help to figure out our issues with it. -- Trygve
Re: svn commit: r419036 - /maven/continuum/trunk/continuum-webapp/pom.xml
[EMAIL PROTECTED] wrote: Author: evenisse Date: Tue Jul 4 08:34:42 2006 New Revision: 419036 URL: http://svn.apache.org/viewvc?rev=419036&view=rev Log: (empty) Modified: maven/continuum/trunk/continuum-webapp/pom.xml Modified: maven/continuum/trunk/continuum-webapp/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?rev=419036&r1=419035&r2=419036&view=diff == --- maven/continuum/trunk/continuum-webapp/pom.xml (original) +++ maven/continuum/trunk/continuum-webapp/pom.xml Tue Jul 4 08:34:42 2006 @@ -127,7 +127,8 @@ org.codehaus.plexus - plexus-mail-sender-api + plexus-mail-sender-javamail + 1.0-alpha-3 The version should be specified in the root pom. -- Trygve
Re: branch CI turned off
Brett Porter wrote: Yep, I agree with you both. Perhaps removing it after the 1.1 release is the most appropriate. +1, and include the last known rev in the README.txt :) -- Trygve
Re: branch CI turned off
Brett Porter wrote: I've turned off the CI build for continuum-1.0.x, since the development focus will all be on trunk now. I'm not sure if we should svn rm the branch to save confusion, or move it, or just leave it there. Any thoughts? I'd prefer to leave it, at least for a while, as people might have their own custom versions of continuum going and removing it might make it more complicated maintaining patch sets etc. A README.txt could be added to the root to clarify the current state of the branches. -- Trygve
Re: Distributed Continuum (GBuild)
On Mon, 2006-03-20 at 14:01 -0800, Jason van Zyl wrote: > Hi, > > I have been talking with David Blevins about moving the GBuild code from > Geronimo over to Continuum proper. GBuild is a version of Continuum that > works in a distributed fashion. GBuild was created to test the Geronimo > TCK across many different platforms with many different configurations > and have the results all aggregated back on a master machine. I've also talked a bit to David and read a fair bit of the code and think this is a very valuable addition to Continuum. > So what I would like to propose is to move the code from GBuild over > into Continuum proper and give David Blevins and Kevan Miller commit > access. They are both committers on the Geronimo project and are > familiar with this distributed code and will continue to work on the > code once in Continuum. > > This is very exciting! > > Here's my And there's mine! +1 -- Trygve
Re: svn commit: r376420 - /maven/continuum/branches/continuum-1.0.x/continuum-core-it/src/test/java/org/apache/maven/continuum/it/AbstractIntegrationTest.java
On Thu, 2006-02-09 at 20:20 +, [EMAIL PROTECTED] wrote: > Author: evenisse > Date: Thu Feb 9 12:20:54 2006 > New Revision: 376420 > > URL: http://svn.apache.org/viewcvs?rev=376420&view=rev > Log: > Test if temp directory is deleted before to start the test This shouldn't be necessary, did you encounter a case where this was needed? There was someone on #maven or #continuum that was talking about FileUtils.deleteSomething() didn't properly delete the directories so you migh be experiencing the same bug. -- Trygve
Re: Security in Continuum
On Wed, 2006-01-11 at 19:13 +0100, Emmanuel Venisse wrote: > Hi, > > In 1.1, we have decided to rework all security features. I haven't looked at osuser in particular yet, but I still think it might work for us. Anyway I'm suggesting the following strategy: 1) Make a set of Continuum-specific interfaces: * ContinuumAuthentication has a login( username, password ) and a logout() method * ContinuumAuthorization canExecute( authenticationToken, protectedResourceId ) * ContinuumUserManager User and Group object CRUD methods, addUserToGroup() and the likes. 2) Make a LDAP implementation of these interfaces and include Apache Directory in Continuum as the default database or write a Derby-specific implementation as that's what we're already shipping with. The advantage by including Directory is that we have one less implementation to write and it's easier to migrate to a proper LDAP database as you can connect to the Directory service and dump the existing database. The disadvantage is the increased size of the Continuum binary distribution. I'm currently not sure how big the Directory server is in terms of bytes. The binary ApacheDS distro[1] is 10MB but I really doubt all of that is required. It shouldn't be really hard to write a Derby implementation and it will probably be the fastest implementation. By following this strategy we isolate Continuum from the implementation as the interfaces are Continuum-oriented and should be pretty stable from day one, and we can add JAAS implementations later on. By having a standalone (Derby), LDAP and JAAS implementation I think that we've covered all possible integration points. I'd guess that 90% of all people wanting authenticate with an external system would use LDAP anyway. Thoughts? [1]: http://cvs.apache.org/dist/directory/apacheds/ -- Trygve
Re: design discussions
On Mon, 2005-11-21 at 10:00 +1100, Brett Porter wrote: > I've noticed John has posted a number of documents here: > http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Design+Discussions > > I've provided some feedback - it'd be great if anyone else could take a > look. Before the feature breakdown happens. I've added a brain dump of some of the stuff that Jason and I discussed last summer while I was in Canada: http://docs.codehaus.org/display/CONTINUUM/Design+Ideas+for+1.1 -- Trygve
Re: [vote] release beta-2
On Fri, 2005-10-21 at 18:38 +0200, Emmanuel Venisse wrote: > Hi, > > Please vote on releasing continuum 1.0 beta 2 > > >From me, +1 +1 -- Trygve
Re: svn commit: r327219 - /maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/notification/mail/MailContinuumNotifier.java
On Fri, 2005-10-21 at 16:36 +, [EMAIL PROTECTED] wrote: > Author: evenisse > Date: Fri Oct 21 09:36:00 2005 > New Revision: 327219 > > URL: http://svn.apache.org/viewcvs?rev=327219&view=rev > Log: > define buildHost to localhost if InetAddress.getLocalHost().getHostName() > return null I think "unknown" might be a better name, WDYT? -- Trygve
Re: please unsubscribe me
On Fri, 2005-09-16 at 14:32 +0530, Sadasivam, Sendhil (Cognizant) wrote: > Hai > > Please unsubscribe my mail id. > Thanks To unsubscribe send a mail to [EMAIL PROTECTED] almost like you did when you subscribed. Make sure that you use the same email address that you used when you subscribed to send the mail. -- Trygve
Re: [vote] Release 1.0-alpha-4
On Fri, 2005-09-16 at 10:06 +1000, Brett Porter wrote: > This is a vote to release Continuum 1.0 alpha 4. Open for 72 hours. +1 -- Trygve
Re: Continuum White Site
On Tue, Aug 09, 2005 at 07:20:49PM +1200, Rinku wrote: > >>2) I like the way the 'generated artifacts' are hyperlinked on the > >>build details page - is it possible not to have the Reports inlined on > >>the same page but on different page (JUnit, site reports) > > > >I'm not sure about inlining the reports - they could be quite large > >(though I guess the same is true of the build output). If it is going to > >be a click away anyway, I'm not sure what the advantage is? > > - Yep, thats what I meant 'not' inlining the reports or build logs on the > same page as these can get too big for usability/navigability reasons. I > think it would be better to keep links to detailed logs/reports. > > >> > >>ohh...btw, Continuum logo is neat :-) ! > > > >Yes, I think so too (we're lucky it wasn't me designing it :) > > > >- Brett > > > Is one one for M2 in design ;-) ? > > On another note, we could use Javascripting for doing stuff (hide/show > project groups, expand nodes...), but what about browsers with Javascript > disabled? or perhaps I am missing something and its been taken care of (in > which case we can skip this!) Is there really *anyone* that doesn't have a JS enabled browser? I don't think requiring JS to be enabled for using Continuum is a big deal. -- Trygve signature.asc Description: Digital signature
Re: Continuum White Site
On Sun, Aug 07, 2005 at 06:02:27PM +1000, Brett Porter wrote: > Hi, > > I have put this up here: > http://people.apache.org/~brett/white-site/ > > This is how I see continuum 1.0 looking. There are a few notes still to > be reconciled, and I haven't added the project group (should basically > be like the project page itself) or general configuration page (not much > to this I don't think). > > Can I get some feedback on things that are good/bad. Hopefully we can > work towards a version we agree on, and that will set the mark for what > Continuum 1.0 should look like. My points: * The front page should show a summary of all projects with stats pr project group. Stats would be numbers like numb of ok, failed and error builds * Possibly using Java Script to hide and show all the projects in the group on the front page, or going directly to the project group view. * I'd like to add the "drill down" links that they have on the Tigris style project[1]. Where you have "Welcome, Guest | Login" I'd like to see an addition like this: "Welcome, Guest | Login | | " for the project view and similar for the other objects. Come to think of it the project might be the only project with a "parent" object. Project view: * Like like the tabs on the top * * Dependencies: collaps into a single header with two sub headers for example: - "incoming dependencies" and "outgoing dependencies" - "dependencies" and "reverse dependencies" Other: * The ability to use URLs like these is something that I would think could the very useful: http://continuum/project/groupId/artifactId Possibly having version on the end there when we support building multiple branches. For the Plexus container the link would be: http://continuum/project/plexus/plexus-container-default The same thing should work for project groups too: http://continuum/projectGroup/plexus [1]: http://style.tigris.org/nonav/docs/sampler_tigris.html -- Trygve signature.asc Description: Digital signature
Re: continuum jira
On Fri, Aug 05, 2005 at 01:14:05PM +0200, Vincent Massol wrote: > > > > -Original Message- > > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > > Sent: vendredi 5 août 2005 12:58 > > To: continuum-dev@maven.apache.org > > Subject: Re: continuum jira > > > > On Fri, Aug 05, 2005 at 01:53:25PM +1000, Brett Porter wrote: > > > please note I've renamed the releases so 1.0-alpha-4 comes next, and > > > 1.0-beta-1 after that. When closing issues, please close them for > > > alpha-4 (despite what the pom says). > > > > > > Good justification for using 1.0-SNAPSHOT in the POM and labelling a > > > release at release time, I think :) > > > > +1, I like how that turned out with the Maven 2 alphas > > Are you saying you'd do it this way: > > 1.0-SNAPSHOT -> 0.1 -> 1.0-SNAPSHOT -> 0.2 -> ... Yes. > > Instead of: > > 0.1-SNAPSHOT -> 0.1 -> 0.2-SNAPSHOT -> 0.2 -> ... No, we've beend doing like this: 1.0-alpha-1-SNAPSHOT -> 1.0-alpha-1 -> 1.0-alpha-2-SNAPSHOT -> .. -- Trygve signature.asc Description: Digital signature
Re: continuum jira
On Fri, Aug 05, 2005 at 01:53:25PM +1000, Brett Porter wrote: > please note I've renamed the releases so 1.0-alpha-4 comes next, and > 1.0-beta-1 after that. When closing issues, please close them for > alpha-4 (despite what the pom says). > > Good justification for using 1.0-SNAPSHOT in the POM and labelling a > release at release time, I think :) +1, I like how that turned out with the Maven 2 alphas -- Trygve signature.asc Description: Digital signature
Re: plexus-test-runtime missing when bundling runtime
On Wed, Jul 20, 2005 at 02:47:01PM +0200, Yann Le Du wrote: > Hi Emmanuel, > > At first, I built with m2 trunk version (rev. 219874), but even before this > error I got another one : > > [INFO] [plexus:app] > --- > constituent[0]: > file:/devel/maven/maven/lib/maven-artifact-2.0-beta-1-SNAPSHOT.jar > ... > constituent[23]: > file:/devel/maven/maven/lib/wagon-provider-api-1.0-alpha-4.jar > --- > Exception in thread "main" java.lang.NoSuchMethodError: > org.apache.maven.project.artifact.MavenMetadataSource.(Lorg/apache/maven/artifact/resolver/ArtifactResolver;Lorg/apache/maven/project/MavenProjectBuilder;Lorg/apache/maven/artifact/factory/ArtifactFactory;)V > at > org.codehaus.plexus.builder.AbstractBuilder.findArtifacts(AbstractBuilder.java:240) > ... > > > So I tried with the "stable" version m2-alpha3... By the way, which practice > is > the "good" one, i.e. what maven build should I use ? We're using the latest version from trunk until the beta-1 is released. -- Trygve signature.asc Description: Digital signature
Re: Google Summer of Code project
On Fri, Jun 10, 2005 at 05:40:09PM +0300, Vasyl Stashuk wrote: > Hi! > > I'm interested in integrating Continuum and Eclipse. > What should I do to take this project ? I assume that you are talking about this[1] project. This is a Codehaus project, not a Apache project so you will have to discuss this with the mevenide folk. Subscribe to their dev list ([EMAIL PROTECTED]) and ask there. Even though this is not a Apache project I will help you with any Continuum issues you are having. I'm also on the mevenide lists. [1]: http://docs.codehaus.org/display/HAUS/Google+Summer+of+Code -- Trygve > > -- > All the best, > Vasyl Stashuk signature.asc Description: Digital signature
"build signaled" state removed
Hi I just removed the "build signaled" state from the ContinuumProjectState enum. I removed the reference to it in the state decoder in continuum-web for now. Of course we have to be able to show to the user that the project is signaled for build but that can be read from the queue. The only question is how we want the web interface to get this information from the core. Either we can have a transient flag on ContinuumProject to indicate it or have another method in Continuum to get the list of scheduled projects. -- Trygve
[vote] Release Continuum 1.0 alpha 1
Hi I would like to propose that we tag and release the current version in the Subversion repository as "Continuum 1.0 alpha 1". [ ] +1, yes I agree [ ] +0 [ ] -1, no I don't agree, please state a reason -- Trygve
Re: commit privs for dan diephouse
On Mon, 2005-04-18 at 20:41 -0700, Jason van Zyl wrote: > Howdy, > > Dan is working on the SOAP interface for Continuum and I'd like to just > grant him access to work on this stuff. +1 -- Trygve > > +1 >
