Re: Account locked
all accounts lock to prevent raw dictionary attacks, and you can unlock by restarting the server, then all admin accounts unlock jesse On Tue, Mar 4, 2008 at 7:07 AM, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, After trying to log into our continuum v1.1 instance as an admin, continuum is telling us: Account Locked Project Groups list is empty. Why would the admin account ever be locked, and how does one unlock it? Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: Apache Continuum is now an Apache top level project
\o/ nice! On Wed, Feb 20, 2008 at 3:30 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Cool, great news. Thanks Brett (and others) Emmanuel On Feb 20, 2008 9:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum update
along these lines I released the 1.0 for redback this weekend (including configuration web page!) and am setting up a similar 1.0.x branch for it so continuum and the other projects using it can maintain fixes as needed. http://archive.redback.codehaus.org/dev/a43524d00801201757r2fa2d7d8h51de14d3d87e6577%40mail.gmail.com am hoping we can get some neat things in place for 2.x continuum :) jesse p.s. for wendy: http://redback.codehaus.org/configuration.html On Jan 21, 2008 4: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 -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
sorry, so it is clear in my previous mail...I second the nomination of evenisse _and_ decline the nomination myself. If he doesn't want it then I'll think about it, but in my mind there is no one more worthy of that role. cheers! jesse On Jan 9, 2008 6:50 PM, Brett Porter [EMAIL PROTECTED] wrote: Thanks Rahul. I appreciate the thought, however I decline the nomination at this time :) On 08/01/2008, at 5:00 AM, Rahul Thakur wrote: And the nominations are. (~opens the envelope~) 1) Brett Porter , and 2) Jesse McConnell Cheers :-) Rahul Brett Porter wrote: of course :) On 07/01/2008, at 5:09 PM, Rahul Thakur wrote: Are more than one nominations allowed per person? Rahul Brett Porter wrote: So the poll for progressing seems in favour. Before we continue to vote on a proposal to send to the board, we need to decide on a description for the project, the initial PMC/ committers, and a chair. I would like to nominate Emmanuel as the chair of the project. Are there any other nominations? I have the current committers list as: Maria Odea Ching Joakim Erdfelt Olivier Lamy Trygve Laugstol Jesse McConnell Brett Porter Edwin Punzalan Carlos Sanchez Wendy Smoak Rahul Thakur Emmanuel Venisse Kenney Westerhof Andrew Williams Anyone on that list that doesn't feel they should be a committer? Did I miss anyone? The following have committed only once, or have declared themselves emeritus: Herve Boutemy Dan Diephouse Fabrizio Giustina Arnaud Heritier Lukas Theussl Jason van Zyl Anyone on that list that would like to be included? Finally - I propose that the initial PMC be equal to the list of committers. Any objections or opinions about that? Cheers, Brett On 20/12/2007, at 5:42 PM, Brett Porter wrote: So, what's next? This seems generally in favour - now might be a good time to get started on it? From past experience the steps would be: - poll the current maven committers to see who is interested in participating in the TLP - draft a resolution with those committers as the initial PMC - vote on sending the resolution to the board The board next meets in mid-January. Any thoughts on moving forward with this? - Brett On 24/09/2007, at 6:59 AM, Wendy Smoak wrote: On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: So I think it would be good for Continuum to become a Top Level Project at ASF and the continuum community will have more chance to grow. My concern for the moment is we don't have enough committer from different companies, To be stable, at least 3 committers from different companies would be good. It definitely feels like it's time for this to happen, or at least to start the process. Assuming there is general agreement here, let's talk about it on [EMAIL PROTECTED] and see who else might be interested in joining us in a TLP. IMO, anyone who has access to the code now as part of Maven is welcome to come along when it moves out, or at any point in the future. That's how we handled the Tiles move (from Struts) and it worked well. -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
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 -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r590819 - /maven/continuum/trunk/pom.xml
hm...that is not the change I thought it was...
I must not have committed the update to 4 like I thought I had...I must have
been waiting for it to go out to the repos before I committed..and just
locally reverted my change..
oops :)
On Nov 1, 2007 3:21 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote:
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
--
jesse mcconnell
[EMAIL PROTECTED]
Re: CONTINUUM-310 - customizable email templates
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 -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
I actually would prefer to have an increased focus on maven and maven2 integration. tbh there are many different continuous integration servers and the ties with maven could be increased some more and leverage some really nice features in maven. I don't really think continuum needs to really try and compete in the shell script launched builds and tying ourselves to these kinda ideas limits the fun things that can be done. with increased maven integration we could integrate build and reporting tools automatically into the builds, just injecting these kinda reports into maven2 projects that are under CI. lots of things possible but increasing the maven2 support just my thoughts :) jesse On 9/29/07, Mauro Talevi [EMAIL PROTECTED] wrote: 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? +1 for move to TLP, but the project needs to shift its emphasis from maven. Currently the Jira description still states: Continuum is a continuous integration tool designed specifically for use with maven project. It would also be good to have a comparison page with other open-source build tools - eg CruiseControl. Cheers -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] Graduate Continuum to its own TLP
I agree, I think continuum would make a good TLP and move out from the direct maven umbrella. We can attract committers that might not be totally driven with the maven2 koolaid if we are not strictly associated with that project. I know there are a lot of plans for continuum in the relatively near future and I think its an ideal time to take continuum up as a TLP. As for more committers, I think they will come with time and some of the work that is planned. Emm and I work for the same company but olamy is really active and new committer, and Rahul will probably be stepping up some more as we start working on some of the refactoring bits that have been discussed some (and he gets that whole marriage deal worked out). Anyway, I support this and it has been kicked around in the background for a while now. jesse On 9/21/07, Emmanuel Venisse [EMAIL PROTECTED] 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? Emmanuel -- jesse mcconnell [EMAIL PROTECTED]
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
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 -- jesse mcconnell [EMAIL PROTECTED]
redback-1.0-alpha-2 released
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 -- jesse mcconnell [EMAIL PROTECTED]
Re: Solving the notification problem
well, 1.1 is in beta now so ideally no more features, but maybe we just call this a bug fix for now.. I guess the first suggestion might be a batch email option with a summary presented at the top of the mail...that would almost have to be on a per notifier though, but that is made easier by the group level inherited notifiers...That is another db schema change though :) We could alter the notifications to prepare web reports that have the links mailed out, and suppress mails based on time or if a given link has been mailed recently. what conditions do we find the highest lvl of easily ignorable mails go out? I can think of things like SCM outage and things like that...out of memory errors... jesse On 7/31/07, Brett Porter [EMAIL PROTECTED] wrote: 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 -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] release continuum 1.1-beta-1
+1! \o/ On 7/20/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi, I'd like to do a release of the 1.1-beta-1 This version is very stable and usable in production. Highlights are: - Continuum Profiles definition linked to build definitions. - multi-builddefinitions on a project Release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10540styleName=Htmlversion=13432 I have staged it in this repo: http://people.apache.org/~evenisse/stage/continuum-repo/ This repo include too the continuum plugin and th xml-rpc client API Standalone version: http://people.apache.org/~evenisse/stage/continuum-repo/org/apache/maven/continuum/continuum-plexus-runtime/1.1-beta-1/ Webapp version: http://people.apache.org/~evenisse/stage/continuum-repo/org/apache/maven/continuum/continuum-webapp/1.1-beta-1/continuum-webapp-1.1-beta-1.war The site will be updated in the next beta, only the download page will be updated for this version. My +1 Emmanuel -- jesse mcconnell [EMAIL PROTECTED]
Re: Heads up regarding VMBuild
ya, I can help out too. On 7/20/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: I can help you. Emmanuel Brett Porter wrote: So, is anyone interested? On 11/07/2007, at 11:06 PM, Brett Porter wrote: Hi folks, I'm currently doing the rounds of all the people using Continuum on VMBuild. The set up on there ballooned despite the box being underpowered and the installation intended to be experimental, so was never very well maintained. We have a new box to move vmbuild to now and with the features in continuum 1.1 I think we can make a decent go at it. I was going to set up the next release (with profiles and 'single module build' support) and start setting up projects on there and maintain it properly. Hopefully we can get some additional feedback in to the 1.1 final release. Is anyone interested in helping out? Cheers, Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum 1.1-beta-1
they have been released... continuum 1.1-beta-1 will be out next week :) \o/ On 7/13/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We must release plexus-contextualizer and plexus-utils-1.4.3 first. Volunteers? Emmanuel Emmanuel Venisse a écrit : Hi, All 1.1-beta-1 issues are closed. I'll prepare the release in next hours or next week. Emmanuel -- jesse mcconnell [EMAIL PROTECTED]
continuum 1.1-beta-1 update
Just to capture some talk on irc today... I think the strategy moving forward is going to be get some of jira cleaned up a la the recent maven jira push and continuum 1.1 is going to get wrapped up a bit for the first feature complete beta release very soon. there are some cool things going on for the next major release and we need to get 1.1 out of the way so that work can start landing. that is my update...others can add as they see fit :) jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum Profiles
Emm, as we talked about on irc... I think if we get the first part of this done in the next month then the next alpha-release should be beta-1, with maybe a beta-2 a couple of weeks after that and then get this thing out the door and released. We have a lot on board for 1.2 and we can't really get moving on it until we get this out the door... jesse On 6/8/07, LAMY Olivier [EMAIL PROTECTED] wrote: Hi, Very nice idea. Just some remarks concerning the actual continuum model. Builder and Jdk have the same type (Installation), I think this must be splitted in two types in order to prevent user to add a Builder as a Jdk (screen [1]) when they build a profile. Then it could be nice to can add some environnement variable for builder/jdk (as MAVEN_OPTS or some stuff like -Djava.awt.headless=true for a jdk) (as say [2]). -- Olivier [1] http://people.apache.org/~evenisse/design/continuum/continuum_profiles/profile.htm [2] http://people.apache.org/~evenisse/design/continuum/continuum_profiles/installations.htm -Message d'origine- De : Emmanuel Venisse [mailto:[EMAIL PROTECTED] Envoyé : vendredi 8 juin 2007 20:16 À : continuum-dev@maven.apache.org Objet : Continuum Profiles Hi, I wrote a little doc (http://docs.codehaus.org/display/CONTINUUM/CI+profiles) about what I think we need to implement to add profiles in Continum. I don't think we can implement all features in 1.1 because it's a big work. The work can be split like that: 1.1: add installation screens, basic profile screens (set of installations) and the possibility to add a profile to a build definition 1.2: advanced profiles (Remove build definitions and move schedule, build file, scm policy to the profile) with combined profiles. Screens attached to CONTINUUM-44 don't integrate advanced profiles, I think they will be available next week. Any comments are welcome. Thanks. Emmanuel 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. ** -- jesse mcconnell [EMAIL PROTECTED]
Re: LDAP-Module for Continuum
does your ldap lib connect up to arbitrary ldap servers? I have been poking around recently with using apacheds as an embedded ldap server and writing a general ldap user manager and ldap authenticator against it. I am not sure if I can use the GPL part of that. jesse On 6/6/07, David Goemans [EMAIL PROTECTED] wrote: Jesse McConnell schrieb: we are willing to contribute the ldap-module under apache license. But this module uses also our LDAP-lib, which we only want to contribute under GPL. To function of my module: it is an implementation of the plexus-redback user manager (But only a simple one, which don't offer pwd-change etc.). David could you make that apache license? then you can add it to issue http://jira.codehaus.org/browse/PLXREDBACK-74 and I'll take a look-see, I have been kicking around different ways to use ldap so it will be nice to see what you have :) jesse On 6/5/07, David Goemans [EMAIL PROTECTED] wrote: Hi, I've written a LDAP-Module for User-Management in Continuum (Plexus-redback). This has already worked fine. But it doesn't work with the actual trunk. I think something has changed with redback-configuration. I think a LDAP-Module for Continuum were a good feature and my company is willing to contribute it under GPL-License. David -- jesse mcconnell [EMAIL PROTECTED]
Re: LDAP-Module for Continuum
I was actually referring to working on adding ldap support to redback itself, I am one of the developers on it. as for the jpox plugin, I would think it would just provide the same jpox functionality that we use with derby and postgres or whatever rdbms we happen to have backing the jpox store. with that we pretty much get ldap support in redback and by extension continuum and archiva for free (albeit with a bit of metadata tweakage) erik, what kinda changes are we talking about metadata wise? do you have docs on this yet? if you want to look at the package.jdo we are using, its in here: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/plexus/redback/redback-users-jdo/1.0-alpha-1/redback-users-jdo-1.0-alpha-1.jar jesse On 6/6/07, David Goemans [EMAIL PROTECTED] wrote: Like I already said, we are willing to share the implementation of ldapUserManager under Apache license, but not the LDAP-Lib. But I think if you decide to take parts of my implementation (ldapUserManager), I'm willing to help you migrating it to an other library which is licensed under Apache. @ Erik Bengtson I see one problem in your JPOX implementation? How do you validate pwds? The problem is that there are many different algorithms like (md5, crypt etc). I solved it by validating on LDAP. @ jesse If your implementation of LDAP-UserManager and LDAP authenticator public. If yes, I could try to help you, to make this work. But only if you want. If your implementation work, you could contribute it under Apache license and continuum has LDAP. David Erik Bengtson wrote: Hi, I'm currently writing a JPOX plugin to connect to LDAP databases. In other words, you can stick to JDO and support either RDBMS or LDAP databases. Of course, you will be required to set ldap specific metadata in metadata files. If you are interested, can you please point me to your object model that maps to users, groups, roles, etc? I would like to validate the ldap module works. Regards, Erik Bengtson Quoting Carlos Sanchez [EMAIL PROTECTED]: Using LGPL is going to be tricky, but if you contribute the code of your part under Apache we could try to reuse it with other library like Spring-LDAP http://www.springframework.org/ldap On 6/6/07, David Goemans [EMAIL PROTECTED] wrote: First my LDAP-Lib does more than a normal LDAP-Connection library. For example it provides a LDAP-User, which allready contains all attributes of a user. And it also provides methods to get all attributes of a LDAP-Node. I used JNDI in this Lib to connect to LDAP, so it should work with any ldap-server. But I have only tested it with OpenLDAP and ADS. David Jesse McConnell schrieb: does your ldap lib connect up to arbitrary ldap servers? I have been poking around recently with using apacheds as an embedded ldap server and writing a general ldap user manager and ldap authenticator against it. I am not sure if I can use the GPL part of that. jesse On 6/6/07, David Goemans [EMAIL PROTECTED] wrote: Jesse McConnell schrieb: we are willing to contribute the ldap-module under apache license. But this module uses also our LDAP-lib, which we only want to contribute under GPL. To function of my module: it is an implementation of the plexus-redback user manager (But only a simple one, which don't offer pwd-change etc.). David could you make that apache license? then you can add it to issue http://jira.codehaus.org/browse/PLXREDBACK-74 and I'll take a look-see, I have been kicking around different ways to use ldap so it will be nice to see what you have :) jesse On 6/5/07, David Goemans [EMAIL PROTECTED] wrote: Hi, I've written a LDAP-Module for User-Management in Continuum (Plexus-redback). This has already worked fine. But it doesn't work with the actual trunk. I think something has changed with redback-configuration. I think a LDAP-Module for Continuum were a good feature and my company is willing to contribute it under GPL-License. David -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- jesse mcconnell [EMAIL PROTECTED]
Re: JDK 5 in Continuum
+1! On 6/4/07, Brett Porter [EMAIL PROTECTED] wrote: If my memory serves, we had decided we were ready to take this step for the applications, but not Maven itself until the toolchain support is final. Any objections? - Brett On 05/06/2007, at 2:32 AM, [EMAIL PROTECTED] wrote: Author: brett Date: Mon Jun 4 09:32:12 2007 New Revision: 544179 URL: http://svn.apache.org/viewvc?view=revrev=544179 Log: Start using JDK 5 for Continuum Modified: maven/continuum/trunk/pom.xml Modified: maven/continuum/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml? view=diffrev=544179r1=544178r2=544179 == --- maven/continuum/trunk/pom.xml (original) +++ maven/continuum/trunk/pom.xml Mon Jun 4 09:32:12 2007 @@ -65,6 +65,13 @@ pluginManagement plugins plugin + artifactIdmaven-compiler-plugin/artifactId + configuration +source1.5/source +target1.5/target + /configuration +/plugin +plugin artifactIdmaven-release-plugin/artifactId configuration tagBasehttps://svn.apache.org/repos/asf/maven/ continuum/tags/tagBase -- jesse mcconnell [EMAIL PROTECTED]
[VOTE] release continuum-1.1-alpha-2
I would like to get alpha-2 released to the community now.
Highlights are:
revamped xml-rpc support
converted to use rebranded plexus-security, aka redback
continuum maven plugin
many bug fixes and ui improvements.
I have it staged at:
http://people.apache.org/~jmcconnell/continuum-1.1-alpha-2
If this vote passes, I will move the relevant tar and zip balls to the
following location like I did with the first alpha release.
http://people.apache.org/builds/maven/continuum/1.1-alpha-2
I'll also update the continuum wiki to point to the new alpha release
and get the continuum website updated with the information as well.
I'll also announce all this to the continuum users list. This will
hopefully be the last of the alpha releases followed by a beta release
in a month or so.
Normal voting rules, 72 hours, +1/0/-1
Below this is the jira release notes for this release.
Release Notes - Continuum - Version 1.1-alpha-2
** Bug
* [CONTINUUM-620] - Changes section in Continuum build result and
build e-mail only show blank columns and file names
* [CONTINUUM-684] - Access to Continuum using XML-RPC is not authenticated.
* [CONTINUUM-1229] -
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Invalid default
value for 'SCM_USE_CACHE'
* [CONTINUUM-1269] - Recforing of the XMLRPC server, must be a
servlet on the same port used by the webapp instead of a specific port
* [CONTINUUM-1275] - Project Group Name that contains only spaces
can be added.
* [CONTINUUM-1276] - Error in editing the Project name using spaces only
* [CONTINUUM-1282] - Adding or editing a Project Build Definition
can accept spaces in pom file name
* [CONTINUUM-1289] - Sorting Usernames in Build Management's
Project Group member list does not work in Firefox 2
* [CONTINUUM-1290] - Project ID is not validated when adding a Project Group
* [CONTINUUM-1292] - Error when clicking build icon in Project
Build Definitions summary
* [CONTINUUM-1293] - Hitting 'Add' button repetitively in adding
an Ant, Shell and Schedule using empty string only accumulates
validation prompts
* [CONTINUUM-1294] - Adding a Schedule, Ant/ Shell Projects can
accept spaces
** Improvement
* [CONTINUUM-1035] - Dependent builds not triggered via XMLRPC
* [CONTINUUM-1186] - Application should unpack to continuum-${version}
* [CONTINUUM-1297] - update to redback from plexus-security
** New Feature
* [CONTINUUM-683] - Implement a ping service that XML-RPC
clients can use to test connection.
** Task
* [CONTINUUM-1242] - Update Continuum Model
--
jesse mcconnell
[EMAIL PROTECTED]
towards continuum 1.1 alpha 2
May 21 is fast approaching and that when I want to get the alpha-2 release of continuum out. The advances we have made since alpha-1 are mostly in the area of a few more bug fixes, redback integration and shifting off of the plexus-security-rbac-profile artifact for role management to the different implementation of role management that has an easier api into client applications like continuum. load up continuum trunk and take a look the following url to see the roles and role templates and what operations they grant access to, etc. http://localhost:9090/security/roleModel.action (you will need to log in and manually visit this url atm) Also on continuum trunk at the moment is some work from emmanual with regard to the xmlrpc bits and pieces of continuum. They are now authn an (increasing authz as its implemented) protected. The clients are pretty simple and its looking pretty nice. anyway, that is a little update on things as they stand. jesse -- jesse mcconnell [EMAIL PROTECTED]
Fwd: Continuum 1.1 alpha 1
forwarding here since this just went to continuum-users -- Forwarded message -- From: Jesse McConnell [EMAIL PROTECTED] Date: Apr 23, 2007 9:17 PM Subject: Continuum 1.1 alpha 1 To: [EMAIL PROTECTED] Well, its finally happened...continuum has had an alpha release to show off some of the work that has been done over the last year. you can obtain the latest release at the following location. http://people.apache.org/builds/maven/continuum/1.1-alpha-1/org/apache/maven/continuum/continuum-plexus-runtime/1.1-alpha-1/continuum-plexus-runtime-1.1-alpha-1-bin.tar.gz war file is - http://people.apache.org/builds/maven/continuum/1.1-alpha-1/org/apache/maven/continuum/continuum-webapp/1.1-alpha-1/continuum-webapp-1.1-alpha-1.war This is the first of the alpha series of continuum, and the plan is to try and get an few alpha's out before we release. There are more issues then I care to think about resolved in this release as well as a number of fun improvements. I am hoping we get some momentum from this and and power through a number of the remaining issues in the jira. If you come a bug or feature request your more then welcome to open the issue in jira at http://jira.codehaus.org/browse/CONTINUUM. If you do open an issue, please try and include as much information as possible, if we can't replicate, we can't fix. Patches are welcome and your best response will be garnered from hopping on irc and talking to us about it. irc.codehaus.org #continuum One of the things that we need to get spruced up before release is documentation, and if you wish to contribute some, we have a wiki setup for continuum users. http://docs.codehaus.org/display/CONTINUUMUSER thanks much! jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: XML RPC security
I have never really messed with authenticated web services at all so
not sure what to say..
I'll take a look through that though, thanks carlos
jesse
On 4/30/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
I don't think you need to handle the authentication part in the
continuum code, nor need to create tokens,...
If you use standard Digest authentication the password is encrypted,
and if you tie that with https then it's completely secure.
Acegi uses a filter to process all the requests and populate the auth
info or return the standard http codes if user not authenticated
http://www.acegisecurity.org/docbook/acegi.html#digest
On 4/30/07, Jesse McConnell [EMAIL PROTECTED] wrote:
I am hoping to get a couple of authn and authz web services running in
redback this week, once I finish up the role profile refactor and
clean up, I want to wack out a webservice and then start getting
continuum integrated to using the new redback setup.
sounds like that would work perfectly for this xml-rpc stuff in continuum.
rahul, planning on using xfire until the apache CXF stuff gets it
first release out of the incubator...that sound good?
jesse
On 4/30/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Maybe, but I can't find it.
Emmanuel
Rahul Thakur a écrit :
I thought there was something similar to this that exists in Redback?
Rahul
- Original Message - From: Emmanuel Venisse
[EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, April 28, 2007 12:37 AM
Subject: Re: XML RPC security
I think it's best solution. With a token, we don't have login/password
over the network for each request.
XmlRpcService
String login( username, password ) //return a token
{
tokenManager.login( username, password );
}
Object method1( token, params ) //null token for guest user or a
getGuestToken() method that will return it
{
User user = tokenManager.getUser( token );
...
}
Object method2( token, params )
{
...
}
TokenManager
String login( username, password ); //return a token
User getUser( token )
The TokenManager can be a plexus component with a default
implementation for redback.
wdyt?
Emmanuel
Emmanuel Venisse a écrit :
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'.
Thoughts?
Rahul
--
jesse mcconnell
[EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
--
jesse mcconnell
[EMAIL PROTECTED]
Re: [Vote] release continuum 1.1 alpha 1
ok, I got it fixed up.. http://people.apache.org/~jmcconnell/continuum/org/apache/maven/continuum/continuum-plexus-runtime/1.1-alpha-1/ that is the tar.gz and it has the license and notice in it so I think we are good to go for this. thanks for all the votes :) I'll let it run a little bit over before I make the vote summary mail jesse On 4/21/07, LAMY Olivier [EMAIL PROTECTED] wrote: Non binding : +1. -- Olivier -Message d'origine- De : Jesse McConnell [mailto:[EMAIL PROTECTED] Envoyé : vendredi 20 avril 2007 21:28 À : continuum-dev@maven.apache.org Objet : [Vote] release continuum 1.1 alpha 1 Its that time, to start releasing continuum in alpha to get some users and feedback on it. The fixes are far too numerous to specify a concise list of, hundred's of jira's fixed and many new additions in functionality. I have it staged at: http://people.apache.org/~jmcconnell/continuum Normal voting rules, 72 hours, +1/0/-1 As wendy mentioned in the thread for preparing this release, a successful vote here will allow me to make an announcement on the continuum users list and I'll move the relevant files to http://people.apache.org/builds/maven/continuum/1.1-alpha-1 +1 from me jesse -- jesse mcconnell [EMAIL PROTECTED] 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. ** -- jesse mcconnell [EMAIL PROTECTED]
Re: [Vote] release continuum 1.1 alpha 1
Summary: (binding) +1 (jmcconnell, csanchez, evenisse, rahul, oching, aheritier) (non-binding) +1 (nakees, cgruber, gmisura, jvandermeeren, olamy) (non-binding) +0 (wsmoak, license issue was addressed) I'll get this release migrated out... thanks everyone! jesse On 4/23/07, Misura, Gabriel [EMAIL PROTECTED] wrote: +1 Gabriel Misura 20111 120th Ave NE, Cube 2337D Bothell, WA MSN: [EMAIL PROTECTED] Office: 425-288-6217 -Original Message- From: Jesse McConnell [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 12:28 PM To: continuum-dev@maven.apache.org Subject: [Vote] release continuum 1.1 alpha 1 Its that time, to start releasing continuum in alpha to get some users and feedback on it. The fixes are far too numerous to specify a concise list of, hundred's of jira's fixed and many new additions in functionality. I have it staged at: http://people.apache.org/~jmcconnell/continuum Normal voting rules, 72 hours, +1/0/-1 As wendy mentioned in the thread for preparing this release, a successful vote here will allow me to make an announcement on the continuum users list and I'll move the relevant files to http://people.apache.org/builds/maven/continuum/1.1-alpha-1 +1 from me jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
well, I think it will bridge the gap really...its an official release in that it has tags and was generated through the release process, but I hesitate to shove it out into the main repositories only to follow up with an alpha 2 in a few weeks.. jesse On 4/20/07, Rahul Thakur [EMAIL PROTECTED] wrote: Since this would be a proper release (not a build), I'd imagine this going on to the main repository (and subsequently mirrored). Cheers, Rahul - Original Message - From: Wendy Smoak [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, April 21, 2007 7:14 AM Subject: Re: Preparing for continuum-1.1-alpha-1 On 4/20/07, Jesse McConnell [EMAIL PROTECTED] wrote: What do you guys think? just call a vote on it and get it pushed into the wild or can we just do the alpha's like this through the staging setup? The vote makes it an official release tha can be annouced on the user list. Whether to put it on the mirrors is a separate issue. Many projects use people.apache.org/builds for both snapshots and releases that aren't mirrored for whatever reason. I created people.a.o/maven/archiva for archiva-0.9-alpha-1 (which remains a development build.) How about putting it under http://people.apache.org/builds/maven/continuum/1.1-alpha-1 ? BTW, please make sure it contains LICENSE and NOTICE. I don't see them in my last Continuum build. -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
well, my thought is that its not like anyone would be coding against the modules in continuum as a dependency, so why bother putting these minor releases into the main repositories? We don't even deploy updated snapshots of continuum modules much if at all.. jesse On 4/20/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: I don't think it's a pb to release alpha in 2 weeks and put them in the main repo. Emmanuel Jesse McConnell a écrit : well, I think it will bridge the gap really...its an official release in that it has tags and was generated through the release process, but I hesitate to shove it out into the main repositories only to follow up with an alpha 2 in a few weeks.. jesse On 4/20/07, Rahul Thakur [EMAIL PROTECTED] wrote: Since this would be a proper release (not a build), I'd imagine this going on to the main repository (and subsequently mirrored). Cheers, Rahul - Original Message - From: Wendy Smoak [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, April 21, 2007 7:14 AM Subject: Re: Preparing for continuum-1.1-alpha-1 On 4/20/07, Jesse McConnell [EMAIL PROTECTED] wrote: What do you guys think? just call a vote on it and get it pushed into the wild or can we just do the alpha's like this through the staging setup? The vote makes it an official release tha can be annouced on the user list. Whether to put it on the mirrors is a separate issue. Many projects use people.apache.org/builds for both snapshots and releases that aren't mirrored for whatever reason. I created people.a.o/maven/archiva for archiva-0.9-alpha-1 (which remains a development build.) How about putting it under http://people.apache.org/builds/maven/continuum/1.1-alpha-1 ? BTW, please make sure it contains LICENSE and NOTICE. I don't see them in my last Continuum build. -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: [Vote] release continuum 1.1 alpha 1
dangit, thats what I get for going the last bit by hand since that war signing deal cropped up. I'll take a look and see if I can get that ironed out real quick jesse On 4/20/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/20/07, Jesse McConnell [EMAIL PROTECTED] wrote: Its that time, to start releasing continuum in alpha to get some users and feedback on it. The fixes are far too numerous to specify a concise list of, hundred's of jira's fixed and many new additions in functionality. I have it staged at: http://people.apache.org/~jmcconnell/continuum Normal voting rules, 72 hours, +1/0/-1 -1 -- the .tar.gz distribution does not contain the required LICENSE and NOTICE files. :( http://www.apache.org/dev/release.html#what-must-every-release-contain -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: JPOX 1.1.7 ?
I set the transaction lvls to READ_COMMITTED as well, so that didn't fix you either huh? hrm On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: JPOX 1.1.7 doesn't correct the problems with Postgres. I've added an updated stack trace to http://jira.codehaus.org/browse/CONTINUUM-1181 On 3/13/07, Jesse McConnell [EMAIL PROTECTED] wrote: yes, and I setup the bundled for m2 and got them into place about an hour ago...will be synced into the main repos sometime soon jesse On 3/13/07, Thierry Lach [EMAIL PROTECTED] wrote: Did JPOX 1.1.7 get released yesterday? On 3/7/07, Erik Bengtson [EMAIL PROTECTED] wrote: FYI, JPOX 1.1.7 will be released next monday. It fixes the issue with postgres. You can try it out, if you like, before we release. http://www.jpox.org/downloads/maven/jpox/jars/jpox-1.1-SNAPSHOT.jar Regards Quoting Jesse McConnell [EMAIL PROTECTED]: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. anyone have anything to add? jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. Why not? Using the Maven plugin is generally easier than doing it by hand. Only issue that comes to mind are snapshots dependencies. having to resolve the snapshot dependencies are precisely the reason I didn't want to mess with the maven release plugin for this. I would have to release a new plexus-security and probably a couple of other little higgly piggly bits. I think we can get by with the timestamped SNAPSHOT dependencies for these things, means we can release alpha's more frequently as well since we don't have to deal with micro-releasing the dependencies each time. Seems like a good pick, but I have a couple of comments: CONTINUUM-253: why? can't it be done after the release? it can, it is just done partially in a couple of places and I thought it might be nice to have that all collated together, but yes..it can be pushed a bit CONTINUUM-827: sounds to me like this is something that can take a while, is it worth waiting for? Remember that the target for the next alpha should be within a month. fine by me :) What is the time estimate on completing all of the issues? I want to see this pushed this week and then every couple of weeks from here on out. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Preparing for continuum-1.1-alpha-1
ok, I'll plow through the rest of the uncategorized issues now :) jesse On 3/12/07, Thierry Lach [EMAIL PROTECTED] wrote: I'd like to see the JBoss integration http://jira.codehaus.org/browse/CONTINUUM-1167 added somewhere in the alpha process. On 3/12/07, Erik Bengtson [EMAIL PROTECTED] wrote: CLOB is supported by most of the databases, and Oracle is the only one with a particular API rather than plain JDBC Quoting Brett Porter [EMAIL PROTECTED]: Isn't Oracle the only database to offer a CLOB? I think writing it to a file in the build results directory like the other output makes perfect sense. Unless we are planning to search them, but then maybe lucene is a better choice anyway. Hmm, indexed and correlated build failures. I like that idea. Shiny. / me loses focus. - Brett On 12/03/2007, at 2:09 AM, Trygve Laugstøl wrote: Jesse McConnell wrote: sounds good to me, imo either trunc it or maybe switch the model over to a clob for that in the db... I tried to make it a CLOB once but couldn't get it to work because of some JPOX issues IIRC so for alpha-1 just chop the exception and/ or write it to a separate file and put the ideal solution into a later alpha. Keep moving! -- Trygve jesse On 3/9/07, Stephane Nicoll [EMAIL PROTECTED] wrote: On 3/9/07, Jesse McConnell [EMAIL PROTECTED] wrote: I have gone through jira issues there were assigned to 1.1 and spread things out a bit. here is my criteria I used in separating out the issues: 1.1-alpha-1 - issues that need to be addressed asap before we pull any kinda alpha Not because I opened this but I think CONTINUUM-1194 should be fixed. I'll try to provide a patch this sunday for this. As a summary, if an error occurs and the stacktrace is higher than 8000 chars: * The build is stuck in Build In Progress * No notification is triggered (an error has occured?!) Thanks, Stéphane 1.1-alpha-2 - higher importance issues and ones generally related to xml-rpc 1.1-alpha-# - issues that probably ought to be resolved in the alpha releases Future - stuff that probably ain't going to get done any day soon the idea being that we can make new sequential release issues off of the 1.1-alpha-# release tag until we are done with alpha releases. I think once 1.1-alpha-1 is released then we can go through 1.1- alpha-2 and decide what should be done, make a new release called 1.1- alpha-3 and bulk move issues that aren't going to be addressed then (like maybe all the xml-rpc issues) I think we shouldn't worry about making these actually releases cut with the maven-release-plugin. I say we just make a build and get it available for download. Also tag the continuum trunk accordingly. Then we ought to try to release a new alpha every few weeks until we have the alpha-# issues converging towards 0. When we actually get to beta/rc releases then we can cut actual releases. Now about my allocation of issues, its not gospel! If you disagree with any of my assigning of fix versions then just fix it yourself (the version, or better yet the bug). At the time of this writing I have the 1.1-alpha-1 release down to a modest 8 issues with a few of those questionable and/or waiting for a bit of feedback. I have yet to go through the 200 or so unfiled issues though so that might go up a bit, I'll do that now. thoughts? jesse On 3/7/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: We don't need it the migration tool now. We'll can see to it when we'll release a first beta on rc. Emmanuel Brett Porter a écrit : On 07/03/2007, at 9:52 AM, Jesse McConnell wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum
Re: Preparing for continuum-1.1-alpha-1
well that is a bit of awesome news, thanks erik! On 3/7/07, Erik Bengtson [EMAIL PROTECTED] wrote: FYI, JPOX 1.1.7 will be released next monday. It fixes the issue with postgres. You can try it out, if you like, before we release. http://www.jpox.org/downloads/maven/jpox/jars/jpox-1.1-SNAPSHOT.jar Regards Quoting Jesse McConnell [EMAIL PROTECTED]: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. anyone have anything to add? jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Write access to wiki
you might more active feedback if you just correspond with the mailing list like this, at least in my opinion.. as for the wiki access, that might be possible, what kinda stuff will you be adding there? information specific to your implementation? where would that implementation be located? are you just going to create and maintain a patchset on continuum trunk? inquiring minds want to know! :) anyway, I for one am interested in some more information on your thesis, the sentence you provide sounds like it is already a feature of continuum jesse On 3/7/07, Erik Drolshammer [EMAIL PROTECTED] wrote: Hi! I'm writing a proof of concept (PoC) implementation as my master thesis which extends Continuum. Problem text: The purpose of this Master thesis is to improve existing techniques for Continuous Integration. The focus is on determining whether a new version of a module breaks the build of old clients or builds successfully. One possible approach is to continuously integrate the clients with the new implementation. The task is to write a PoC implementation using Continuum as the underlaying build engine. I have Trygve Laugstøl as my counselor and he suggested that I try to report on my progress on the wiki and hopefully obtain some feedback from the active developers. Can I get write access to your wiki? It looks like my project is related to an existing wiki page [1], but perhaps it is simpler to start a new page? [1] http://docs.codehaus.org/display/CONTINUUM/Triggering+a+build+if+dependencies+are+changed -- Regards Erik Drolshammer, username Sherriff -- jesse mcconnell [EMAIL PROTECTED]
Re: Poll: release continuum alpha
ideally we will revisit a couple of fundamentals for this release still like build profiles, so yes, a couple of planned new features, hopefully assisted by a new person or two interested jesse On 2/24/07, Carlos Sanchez [EMAIL PROTECTED] wrote: if we are not planning to add new features and just bugfixes then I understand it's a beta On 2/24/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 24 Feb 07, at 1:05 PM 24 Feb 07, Carlos Sanchez wrote: +1 for a beta, if everything it's cool let's go for 1.1 and push to -1 for beta This version has so many changes it cannot be called a beta until it has been tried en masse. It is most certainly an alpha. Jason. 1.1.1 whatever else that needs to be fixed On 2/23/07, Jesse McConnell [EMAIL PROTECTED] wrote: I was talking to trygve a bit on irc and it dovetailed nicely with some plans I had talked about late last year in regard to continuum...I am just about a month late is all. We thought we ought to take a poll on here about continuum and see what folks thought. This is not a vote, its just a poll and perhaps a discussion starter on short to mid term plans with continuum. I just know it bothers me a bit everytime someone pops on IRC and asks questions about continuum 1.0.3...which is quite aged atm with so many of the bugs on it resolved on the trunk. Question: Should we take all the work that has been done on continuum in the last year+ and get it pushed out as an Alpha1 or a Milestone1 or some suitable equivalent? [+1/0/-1] jesse -- jesse mcconnell [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- jesse mcconnell [EMAIL PROTECTED]
Re: Metrics Gathering Tracking
I was figuring we would add something like this as some kinda continuum extension for when the workflow is added to the continuum object. being able to activate a module that started doing code analysis and metrics gathering and then putting into a db and then providing trending and graphing on that is a natural fit for continuum...this has been kicked around for a long time now...just a matter of getting time to get the bits and pieces together for it. On 1/18/07, Hilco Wijbenga [EMAIL PROTECTED] wrote: On 1/18/07, Erik Bengtson [EMAIL PROTECTED] wrote: Please let me know if there are metrics you would like to collect from the store (JPOX). I will make a list of the various metrics I was thinking of collecting. We should probably define some sort of interface that anybody can implement and add to the list whenever there's more metrics to be gathered. -- jesse mcconnell [EMAIL PROTECTED]
Re: Metrics Gathering Tracking
thats certainly up in the air, suggestions are good :) jesse On 1/18/07, Rahul Thakur [EMAIL PROTECTED] wrote: Jesse McConnell wrote: I was figuring we would add something like this as some kinda continuum extension for when the workflow is added to the continuum object. Is this going to be impelmented using plexus-spe or OS workflow? Rahul -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int-long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur [EMAIL PROTECTED] wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Building continuum
what are your errors? On 1/2/07, Roald Bankras [EMAIL PROTECTED] wrote: Hey all All the best wishes for 2007! Last year I tried to do some work on continuum. But my checkout of the head failed to build successfully. Then I tried to checkout 1.0.3 but that also failed. Is there something specific I need to do, to make a successful build? Thx Roald Bankras Software Engineer JTeam b.v. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.1/611 - Release Date: 12/31/2006 12:47 PM -- jesse mcconnell [EMAIL PROTECTED]
Re: Building continuum
updated trunk builds cleanly for me right now... what o/s jdk and mvn version are you using? and are you sure you don't have local modifications jesse On 1/2/07, Roald Bankras [EMAIL PROTECTED] wrote: Continuum-core fails 1 testcase with 2 errors. --- Test set: org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.656 sec FAILURE! testCreateProjectsWithModules(org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest) Time elapsed: 1.594 sec FAILURE! junit.framework.AssertionFailedError: expected:1 but was:2 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest.testCreateProjectsWithModules(MavenTwoContinuumProjectBuilderTest.java:184) testCreateProjectWithoutModules(org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest) Time elapsed: 1.406 sec FAILURE! junit.framework.AssertionFailedError: expected:0 but was:1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumProjectBuilderTest.testCreateProjectWithoutModules(MavenTwoContinuumProjectBuilderTest.java:274) Roald Bankras Software Engineer JTeam b.v. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 1/1/2007 2:50 PM -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r490000 - in /maven/continuum/branches/key-based-refactor/continuum-store/src/test/java/org/apache/maven/continuum/store: AbstractContinuumStoreTestCase.java ContinuumStoreTest.java
On 12/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rinku
Date: Sun Dec 24 00:12:41 2006
New Revision: 49
URL: http://svn.apache.org/viewvc?view=revrev=49
Log:
o updates to store unit tests for refactorings.
Modified:
@@ -896,7 +902,9 @@
{
try
{
-store.getProject( project.getId() );
+// TODO: Review! Since the Project key is unique only within a
group
+// shouldn't we specify the Group Key as well for deletion.
+store.getProject( new GroupProjectKey(null, project.getKey() ) );
fail( Project should no longer exist );
}
catch ( ContinuumObjectNotFoundException expected )
yes, most definitely we need to make sure these checks pull the group
key into context, otherwise we'll end up with arrays of results
instead of a particular unique project. I was just looking for
instances of this when I saw your comment so happy we both had it in
mind.
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Are passwords required?
imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... we restrict it already that users are not by default allowed to make empty passwords but with a but of configuration they should be allowed to not have passwords, if that is the admin's desire. also, admins can make passwords that don't follow the password conventions, but by default they are setup to be forced to make a password that does conform on first login jesse On 12/26/06, Wendy Smoak [EMAIL PROTECTED] wrote: In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no password, even though the two password fields have asterisks displayed next to them. If I then edit the user and uncheck the 'Change Password Next Login' box, the user can log in without a password. Should this be possible? -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: Add project group button not protected from unauthenticated users.
there are a number of things along these lines that I noticed in an little audit of the action classes that I noticed. Once rahul and I get the key based refactor wrapped up I think we'll try and link up with some work jason has been kicking around to improve the UI and xmlrpc code interface and security wise in one swoop. jesse On 12/26/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/28/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: Hey. Just FYI, in the trunk the unauthenticated user (and other logged-in, unempowered users) can create new project groups. Thanks, this appears to be fixed in the latest code. (The 'Add project group' button no longer appears.) -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. jesse On 12/22/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make it super easy to have multiple versions of Doxia load up in continuum and execute in their little sandboxes. Group Keys of Doxia and Doxia-Refactor (just an example branch) should be able to seamlessly import the doxia project from its relative sources and peacefully coexist. And it should be just as easy to do the same with a number of ant, shell and maven1 projects. Anyway, some foreseeable real world example keys in one continuum instance: Group: Maven-Trunk Projects: Core Api Artfiact Group: Maven-2.0.5 Projects: Core Api Artifact Group: Continuum Projects: Core Api Store Webapp cheers, jesse - Brett On 22/12/2006, at 6:30 AM, Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big
Re: short term branch for project/group keys
project keys are not unique, you need the group key and project key together to get the actual summary. it should be fine in the store since the index is the uniqifying bit..the project class will need a group key in it as well to make that work a couple of other things came up today so I haven't started that branch yet but hopefully soon as I clear off a couple of things now. jesse On 12/22/06, Rahul Thakur [EMAIL PROTECTED] wrote: So, if we have 2 sessions using the same project as target - user A opens up some Project X's summary for viewing - user B updates Project X's string key to Y. Wouldn't that invalidate the key values being used by user A's session? How will this be handled? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, December 23, 2006 6:48 AM Subject: Re: short term branch for project/group keys nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. jesse On 12/22/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other lookup keys could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: On 12/22/06, Brett Porter [EMAIL PROTECTED] wrote: Sounds good, as long as the store remains independent of them. I don't want to get into the situation like in JIRA where you can't rename a string key. Yes, jason pinged me on this since I guess I wasn't completely clear in that summary. the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. The UI will never pass around a projectId=26 param on a url making you wonder what the heck it was. A nice side effect of this IMO is that the #'s in the working directory would go away as well, defaulting instead to a nested directory structure of workingDirectory/GroupKey/ProjectKey/pom.xml Now I had honestly been thinking of making the key's immutable, since the names of the group's and project's are to be used for all presentational type things. I was going to treat keys under the same functional requirements that usernames generally have. Maybe we offer a 'Clone' option that makes a deep copy of the data in the DB into a new name and then allow the deletion of the old one... Anyway, here are the restrictions I thought of placing on the keys. * [a-zA-Z1-9.-:] for all keys * group key is unique * group key + project key is unique * project key should _not_ need to be unique (ex Doxia/Core + Maven/Core + Continuum/Core) * keys are immutable, set upon creation Before starting to hack on this, perhaps you could list out all the keys you think are needed, and some examples? I'm interested in how it relates to group IDs and artifact IDs in particular. Initially I was planning on doing just the project key and group key since there is so much involved with getting just those two in place. However everything would probably go that way so that Profiles, Schedules, BuildDefinitions, etc...anything with an int ID that is used around in continuum would be converted to use a strongly typed string key insteadthe ones other then project and group are less important in the short term since they are not a constant source of confusion...but eventually yes anything with and ID would get a Key like this. If the branch is a success and is voted back onto trunk then those could take place on trunk I think since they are smaller scope. As for how they would relate to groupId's and artifactId's it was not my intent to deal with those at all. One of the things that got us into the mess that currently exists was too great a focus on the m2 side of continuum. IMO the group and project keys should be kept external to any concept of project type. That way we can always maintain a clear delineation between a group and its member projects in relation to other groups. For instance, one of my goals here is to make
Re: short term branch for project/group keys
The web pages use a combination of id's which are currently jpox id's and in some places the actual freeform name string is being passed around on the URL in order to influence program logic and security decisions.. all of that is what I want to unite behind stronger typed string keys. jesse On 12/21/06, Christian Edward Gruber [EMAIL PROTECTED] wrote: Sounds great to me. But I'm confused. Are the api's passing around keys as in database keys (id), or so-called business keys, i.e. the project group's text id and the project's text id? I presume the latter, given the earlier discussions. Christian. Jesse McConnell wrote: I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023* -- jesse mcconnell [EMAIL PROTECTED]
Re: Updating JIRA
By that logic then I think alpha is definitely what we could start pulling off now and then with some milestones. I know I really want to get the shortcuts bit that I been promoting on another thread in place and that is some more api changes...for the better too since I really want to see the api's from top to bottom working off of things like projectKeys and groupKeys instead of jpox id's and freeform string names of things. I am actually hoping to spend some of my vacation over xmas working on getting that into place. continuum 1.0.3 has been out for a while now and there have been a lot of tangible improvements that we should get into peoples hands in the form of the alpha releases. I figured with labeling of alpha we can freely change the model if we need to and not worry about migrating peoples old databases, though that might be good practice to get into place... so what do others think? shall I make an 1.1-alpha-1 version in the jira and we can get the issues that we want to have really resolved for that in place? Target January for a 1.1-alpha-1 release and then every month after that until we are feature complete and start doing a beta or two...? jesse On 12/9/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 9 Dec 06, at 11:37 AM 9 Dec 06, Jesse McConnell wrote: right, last time I brought this up the goal was to resolve all those for an actual 1.1 release.. If that's the case that's cool. I would like to see maybe an alpha-1 release in January perhaps followed up a beta or two once all the confirmed new features are in place (like profiles, etc). I think what is critical and what is not being done is being honest about over stability of the product and of the API. Provided the API is know to be stable and the stability of the tool itself is good then a beta is fine to release. We're labeling stuff like Archiva as beta and it's not even close which I can attest to with having to try and keep it up on central for the last month. This stuff cannot go out as beta in alpha form. People will consume releases, we just have to be honest about it. I think the decision had not be to actually break out something like alpha and beta releases into jira but for sanities sake perhaps we could reevaluate that. I think the EAP stuff is fine and that could be considered the alphas but I think people like the markers. So EAPs can go out weekly, I think that's a good thing but even folks like Intellij releases betas. I think they just do the EAP thing for marketing so that it doesn't actually say alpha when it really is. I know I went through about a month ago and poked through most of the issues making sure they were in the right components at least...but I think actually breaking down further into achievable shorter term goals would be a good thing. I think so. I mean it will be April before those 163 issues get resolved. Jason. jesse On 12/9/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, If anything is thinking of doing a release of Continuum anytime soon can you please update Continuum's JIRA so that it's representative of what's going to be fixed for at least the next release like Kenney and I have done for Maven itself: http://jira.codehaus.org/browse/MNG I don't think you're doing to be fixing 163 issues for Continuum 1.1. Thanks, Jason. -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [continuum build trunk - FAILED - checkout] Mon Dec 4 01:00:00 GMT 2006
yes, emm and I have seem them crop up from time to time in both the -release module and the -core. The -core ones are that its complaining that it can't load the role profiles for generating the rbac roles. Its a component definition not found exception if I remember right on both of them. I was able to add logging enough to get that message out of the core action execution on the continuum-core once about a month ago and then the problem just disappeared...it resurfaced on a build I was doing early last week and then disappeared again. emm and I were kicking it around on thur/friday about how to try and find the stinker, maybe hook it up to a debugger and run it a whole mess of times until it manifests in an environment we can work with. jesse On 12/3/06, Brett Porter [EMAIL PROTECTED] wrote: Anyone have any ideas on what these 5 intermittent test failures are all about? - Brett On 04/12/2006, at 1:07 AM, [EMAIL PROTECTED] wrote: Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build- log-20061204.01.txt -- jesse mcconnell [EMAIL PROTECTED]
Re: build scheduling issues
sorry, once changed how? once the group dependencies are sorted out? if we are taking all projects across all groups and trying to generate a cycle free graph then cycles are potentially a problem. just so we are clear in my mind: * grab all projects across all groups * attempt to sort * if success, build normally * if failure, notify of cycle and proceed to sequentially process groups, sorting projects in that group only and building * if cycle detected in that group then build all projects in that group in any old order that comes out of the database The difference between this and what used to exist before my group changes is that it will attempt to order inside the group and build as opposed to before where it would just failover to building all projects in whatever order came from the db. is that where we are with this? jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: That's a cycle between the groups, not the projects, so shouldn't be a problem once changed. - Brett On 09/11/2006, at 1:57 AM, Jesse McConnell wrote: the issue isn't cycles within a normal m2 build, but when you shove 4 or 5 of them together into one continuum instance and then ask them all to play together. For example if you shoved continuum, maven-shared and archiva all into the same continuum instance and triggered a build with all of them in the same directed graph then we have had instances of cycles in the past (not sure about right now, mpir cycle might be refactored out thanks to joakim). emm had another example last night when we were talking about it as well. jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: Sorry, am I missing something? How do we end up with a cycle in Continuum? Is there a specific example? I know it's possible - we had to allow it in the repository (eg, dom4j - jaxen), but it is certainly undesirable and honestly should be rare, especially in m2 built artifacts. Should it produce a build warning? Basically, the treatment there is to just stop following the tree when you hit the cycle, rather than changing the way things are ordered. So it's really arbitrary which might come first, but isn't really a concern there. Anyway, just wondering. Cheers, Brett On 08/11/2006, at 11:46 PM, Emmanuel Venisse wrote: Yes Jesse McConnell a écrit : we should add a page that analyzes each schedule for cycles...that would be a cool little feature On 11/8/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Yes, we need a global ordering, so projects will be build independently of groups, because in some case a cycle can be created between groups (not necessary between projects). In case a cycle is detected between projects, continuum can't find the build order. In this case, I think we need to sort a little project so will reduce build errors. So if we have a cycle, we can sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in a group. Emmanuel Brett Porter a écrit : I think you want global ordering. Grouping should just be a display/management technique, not anything that changes how projects are handled. However, this needs to be reviewed as a whole (which I think Emmanuel is doing), such that builds can be triggered when their dependencies change which will help with the ordering as it won't be dependant on them all being triggered at the same time? - Brett On 08/11/2006, at 9:51 AM, Jesse McConnell wrote: I was reading through the DefaultContinuum.buildProjects ( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence. When I added the project groups to this mix, I changed things to be on a project group basis, so that on a project group by project group basis it would order the projects and build them. At the time I thought this was the way to go...but maybe not. 17:14 evenisse we need to take all projects from all groups, sort them 17:15 evenisse if we don't have a cycle, it's ok and we build all 17:15 evenisse if it isn't ok, we sort project by group For example, if we loaded up a Plexus group and a Maven group...the way it currently is (with my change) it would process all triggered builds within one group and then process all triggered builds in the other group. This would not take into account potential dependencies between the two. Does anyone have any thoughts on this? I am inclined to fix it up so its like it used to be where all projects across all project groups
Re: [Patch] Missing dependency in continuum-trunk
hm, someone else seeing this Christian! your not the only one now! graham, what o/s and version of maven and jdk are you using? jesse On 11/9/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, There is a missing dependency on activation.jar within continuum-war. The following patch fixes it. Index: continuum-webapp/pom.xml === --- continuum-webapp/pom.xml(revision 472890) +++ continuum-webapp/pom.xml(working copy) @@ -200,6 +200,12 @@ version1.0-alpha-2/version /dependency dependency + groupIdjavax.activation/groupId + artifactIdactivation/artifactId + version1.1/version + scopeprovided/scope +/dependency +dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.4/version Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: build scheduling issues
the issue isn't cycles within a normal m2 build, but when you shove 4 or 5 of them together into one continuum instance and then ask them all to play together. For example if you shoved continuum, maven-shared and archiva all into the same continuum instance and triggered a build with all of them in the same directed graph then we have had instances of cycles in the past (not sure about right now, mpir cycle might be refactored out thanks to joakim). emm had another example last night when we were talking about it as well. jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: Sorry, am I missing something? How do we end up with a cycle in Continuum? Is there a specific example? I know it's possible - we had to allow it in the repository (eg, dom4j - jaxen), but it is certainly undesirable and honestly should be rare, especially in m2 built artifacts. Should it produce a build warning? Basically, the treatment there is to just stop following the tree when you hit the cycle, rather than changing the way things are ordered. So it's really arbitrary which might come first, but isn't really a concern there. Anyway, just wondering. Cheers, Brett On 08/11/2006, at 11:46 PM, Emmanuel Venisse wrote: Yes Jesse McConnell a écrit : we should add a page that analyzes each schedule for cycles...that would be a cool little feature On 11/8/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Yes, we need a global ordering, so projects will be build independently of groups, because in some case a cycle can be created between groups (not necessary between projects). In case a cycle is detected between projects, continuum can't find the build order. In this case, I think we need to sort a little project so will reduce build errors. So if we have a cycle, we can sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in a group. Emmanuel Brett Porter a écrit : I think you want global ordering. Grouping should just be a display/management technique, not anything that changes how projects are handled. However, this needs to be reviewed as a whole (which I think Emmanuel is doing), such that builds can be triggered when their dependencies change which will help with the ordering as it won't be dependant on them all being triggered at the same time? - Brett On 08/11/2006, at 9:51 AM, Jesse McConnell wrote: I was reading through the DefaultContinuum.buildProjects ( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence. When I added the project groups to this mix, I changed things to be on a project group basis, so that on a project group by project group basis it would order the projects and build them. At the time I thought this was the way to go...but maybe not. 17:14 evenisse we need to take all projects from all groups, sort them 17:15 evenisse if we don't have a cycle, it's ok and we build all 17:15 evenisse if it isn't ok, we sort project by group For example, if we loaded up a Plexus group and a Maven group...the way it currently is (with my change) it would process all triggered builds within one group and then process all triggered builds in the other group. This would not take into account potential dependencies between the two. Does anyone have any thoughts on this? I am inclined to fix it up so its like it used to be where all projects across all project groups are thrown into the graphI keep feeling like I am missing something wrong with this, but I can't pin it down. One thing that perhaps Emmanuel could explain a bit more is the third comment there. In our conversation on this he said that he thinks that the cycles are cropping up all the time, and if thats the case then we are building a lot of unordered builds which would account for some of the strange reports we have been getting. Are you saying that if we detect the cycle we default back to the way I am doing it now? order within the groups... jesse --jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: project group shortcuts
oh, and perhaps I ought to do this on a quick branch for the duration of it... jesse On 11/4/06, Jesse McConnell [EMAIL PROTECTED] wrote: Ok, I am going to try this out I think, here is a laundry list of what would happen followed by the benefits. * the id on project group and project classes usage is deprecated and goes back to being internal to the store, nothing references to a project or a group by 0,1,2,3 etc anymore. * groupId on the project group class becomes the unique string by which you access a project group, it is currently kinda floating around usage wise as sometimes the groupId from the pom loaded up on m2 projects * projectId is added to Project and is the unique string by which you refer to a project in a project group * groupId and projectId would be restricted to [a-zA-Z0-9.-] with no spaces and are the short names to refer to these group and project objects on the UI layer and everywhere else in continuum * cascading effects throughout a large chunk of continuum as the integer projectId and the freeform strings for projectGroupName and integer projectGroupId are deprecated and converted to the short names. benefits: * UI layer will standardize on how to refer to project groups and projects in those groups, without passing around internal jdo store identifiers, free form text strings or even the combination of both of those in some cases (this is a failing of mine from the project group refactor I did, it made the UI work clunkier in referring to these things) * by treating m1/ant/shell/m2 projects the same in the UI it should alleviate a ton of oddball UI issues that are cropping up where groups are created, not created, not referred to correctly, names not being passed around between linked actions, etc * following a convention for naming your groups and projects across instances of continuum will make clustering a lot easier, group 7 on this instance isn't necessarily group 7 in that instance * specifying the string group Id that you will refer to that group by on the adding of the project will allow you to load up multiple instances of the same project (ex one instance on trunk and one on a branch) into the same instance of continuum (versions in the poms for m2 should lets these play together nicely), right now I think the projects from that second addition will just add into the same project group unless you rename the name in the pom you are loading * the unique string project Id can be the same for the same project across multiple usages of that project in different groups, letting you refer to them as [Doxia/DoxiaCore] and [Doxia1.2/DoxiaCore] * m1/shell/m2/ant project groups are referred to in the exact same way, and get their values from the same source, on the adding of the group and underlying projects * we can have a GroupNamingMapper and ProjectNamingMapper interface that can be configurable to be used in the automatic generation of the string groupId and projectId so this naming process can be automated by following a convention in the naming of the poms for m2 * the groupId and projectId string values can be edited at any time, letting the user load up the Doxia group and then later change it to the DoxiaTrunk group and then add in a DoxiaBranchFoo group I am sure there are other benefits, but these are the ones that keep pointing me in this direction. I just think that we really need to take a step like this to clean up a lot of messy interactions between the UI layer and continuum core and the confusing mishmash of webwork action linkages involving groups and projects. anyone have any thoughts on this? I am pretty sure I can have this all done in a couple of days of work and I really think it will help maintenance and future development. jesse On 10/30/06, Jesse McConnell [EMAIL PROTECTED] wrote: last week I mentioned this in rahul's zero-conf mail if this is really what we want to change here then perhaps we ought to make it an option for configuration of the project group in all cases, the ability to specify the name of the project group...or give it some kinda short identification element. I kinda like that idea, then we can use 'Doxia' for 'The Doxia Project' and we can even use the short user input project group Id in the urls... to do this I would put a textfield on the project group creation screens and then an edittable one in the project config screens, and add it to the model. This shortcut would replace the locations where the projectGroupName is currently being passed around on actions to let projects know what group is being interacted with. Api changes obviously to support this as well, but I don't think this would be too terribly bad to get into place. We get to avoid passing around the jdo projectGroupId values which might get screwy with clustering if we have different stores and the project groups are not in sync. We would also be able to do some mapping to allow for direct url friendly
Re: [discuss] Zero config and more control over configuration (was: [jira] Commented: (CONTINUUM-924) Add ability to edit group)
one of the problems here is that if you start letting the CI admin make changes to project and project group names then you are breaking the linkage between the POM and the representation of the project in continuum. Unless you start adding in mapping functionalities and thats just a pain when really, the name in the CI ought to reflect reality in the project. Now perhaps the project group is something that can be opened more for some configuration changes since it is kind of an external concept being mapped onto the poms...its using the pom that you load up for these defaults and then also making a project for that same project group, mapping it twice into continuum as a group and as a project... if this is really what we want to change here then perhaps we ought to make it an option for configuration of the project group in all cases, the ability to specify the name of the project group...or give it some kinda short identification element. I kinda like that idea, then we can use 'Doxia' for 'The Doxia Project' and we can even use the short user input project group Id in the urls... it would be nice if we could setup a mapping for http://ci.host.org/Doxia and take you to the project group. I know brett had that desire a while back, this would more then address that and make it easier to work with the project group in general jesse On 10/27/06, Rahul Thakur [EMAIL PROTECTED] wrote: I believe its more to do with - auto/dynamic configuration, or, giving a CI server admin more control to setup their continuum installation. I think Continuum should be able to support both modes, a) zero-config (almost), and b) the ablity to afford more control to the user, like in the case of edit/reorganize project groups. With dynamic configuration it would make it easy for a project team to change the pom.xml and have the changes reflect in Continuum, but same time - the CI admin user (as can be the case with organisations where this is a separate role/job) , this would mean the projects can, for example, hop groups as and when changes are detected. Thoughts? Cheers, Rahul - Original Message - From: Jesse McConnell (JIRA) [EMAIL PROTECTED] To: issues@maven.apache.org Sent: Saturday, October 28, 2006 5:36 AM Subject: [jira] Commented: (CONTINUUM-924) Add ability to edit group [ http://jira.codehaus.org/browse/CONTINUUM-924?page=comments#action_78658 ] Jesse McConnell commented on CONTINUUM-924: --- I wonder about this one a bit. Rahul was asking about the same sort of thing on irc a day or two ago and I am glad I found this issue here. My ultimate question on this is would we be better served to change things such that when the pom changes in the m2 project and have that automagically applied to the names of projects and project groups. Yes this needs to be added for the ant and shell script project groups...but for m2 and maybe m1 projects can be pull this info from the pom. The Project Object Model is actually supposed to represent all the major aspects of the project so perhaps we can get away with that. Add ability to edit group - Key: CONTINUUM-924 URL: http://jira.codehaus.org/browse/CONTINUUM-924 Project: Continuum Issue Type: Sub-task Affects Versions: 1.1 Reporter: Carlos Sanchez Assigned To: Henry S. Isidro Now that groups are added it'd be nice to have the ability of changing group name or moving projects from group. -- 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 -- jesse mcconnell [EMAIL PROTECTED]
Re: Is 1.1 trunk usable?
and its been fixed up now :) On 10/26/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/26/06, Rahul Thakur [EMAIL PROTECTED] wrote: Is 1.1 trunk at a point that I can put it to use . erm . in production? Well, I *was* going to say I'm running it straight from a svn checkout, but now it won't build. I thought it was CONTINUUM-970, but that's closed. continuum-release wants maven-release-manager, and once I build that, continuum-webapp won't compile: c:\svn\maven\continuum\continuum-webapp\src\main\java\org\apache\maven\continuum \web\action\ReleaseProjectGoalAction.java:[22,47] package org.apache.maven.plugi ns.release.config does not exist ... I'm bugging Jesse about it on IM now. :) -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: Is 1.1 trunk usable?
then you can get away with running continuum trunk I think, you'll at least get the chance to have johnny on the spot fixed committed and available :P jesse On 10/26/06, Rahul Thakur [EMAIL PROTECTED] wrote: For now 1.0.3 is giving me enough 'heartburn' ;-( I just want something that works , i.e, lets me add a project and builds on schedule... nothing fancy really. Cheers, Rahul Jesse McConnell wrote: as a critical 'OMG we're all going to die if this goes down' app, I would hesitate.. but with the understanding that you _might_ run into situations that you will need to smoke the database and start over from scratch sometime and that doesn't cause you much heartburn really...probably safe to do :) oh course I make no promises and unless you pay for the trip I won't come on site to help you :P jesse On 10/26/06, Graham Leggett [EMAIL PROTECTED] wrote: Rahul Thakur wrote: Is 1.1 trunk at a point that I can put it to use . erm . in production? I built it from source, and deployed it within tomcat as a war - it's up and running, but not doing anything yet awaiting a move from vss to subversion, but so far so good... Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] Writing WebWork actions
I also bounced this off of a couple other people over the last day or to..
there seems to be a general consensus from folks that I talked to that
its a good idea to try and group all the CRUD (Create, Read, Update,
Delete) actions on objects grouped into a single action.
On that note, it would be good to standardize the method names as
well, perhaps to:
public String add() {}
public String update() {}
public String view() {}
public String remove() {}
Then we would have the decision of the xwork.xml which could have
actions for each of these methods on the class, like
action name=addFoo class=continuum-foo method=add
or on the jsp's we could just use the shortcut of ww:form action=foo!add
how does this grab folks? I think this is a valuable step in things
since it will give us a chance to audit all of the actions, improve
the -webapp project for contributors...and -webapp is a great place
for people to start with continuum...and it will also serve as a good
swift kick towards finishing off the testing work that emmanuel will
be committing soon.
jesse
On 10/25/06, Rahul Thakur [EMAIL PROTECTED] wrote:
Jesse and I tossed some ideas about having some sort of consistent
patterns for writing Webwork actions in Continuum. Below is a transcript
from yesterday's chat. We wanted to bring this up for discussion and
would be great to have any ideas/suggestions other might have.
Cheers,
Rahul
snip
rahul hello there
jesse heya
rahul just had some ideas that I wanted to jot down here quickly
jesse shoot
rahul ok, here goes (and pls bear with me if I have to go check on
breakfast :) )
rahul ok, i have quick run thru of the patterns/conventions that we
are using in our internal framework
rahul starting with xwork.xml , the equivalent config.xml is broken up
into 3 files
rahul 1) defines components - lets call it components.xml
rahul 2) defines pages (that are composite of layout templates +
components) , lets call it pages.xml
rahul 3) defanes action patch mappings (page flow) - lets call it
mappings.xml
rahul 1) follows convention that all component names are prefixed with
'component.' - ex: 'component.group.notifier.edit'
rahul 2) has page names prefixed with 'page.' - ex:
'page.notifier.summary'
rahul action mappings are pretty much similar to what is there in
xwork.xml currently - i will come to method name later
rahul i am just rattling off here with notes :) - you will have to
help me see these elements can/do map to WW or can be made to map
rahul Components are supported by component handlers - that prepare
the display of and help render components - The java classes are
suffixed XXXComponentHandler. I have come across this with notifiers
rahul Action classes are ManageAction - that process requests
for - edit/update/delete. I think the create one is different (I will
have to check again)
rahul methods in ManageXXXAction follow convention (like I
mentioned) - processEditRequest, processUpdateRequest,
processDeleteRequest
rahul and validations are performed in the actions themselves (but I
like what WW does from validation.xmls)
rahul for 'result' returned from the action - 'success' and 'failure'
are by default available and another convention is 'failure.system' for
any internal errors
rahul other results can map to the action request - 'success.edit' ,
'success.delete' - I am adding this from my end :)
rahul so, what do you reckon?
rahul sorry i haven't been able to put it in an email yet
jesse reading latest
jesse I have actually been kicking around something brett mentioned a
while back about generating actions automatically for CRUD things
jesse and I talked to patrick lightbody and he was a fan of all CRUD
operations being in one object
jesse which was where I had started out
jesse which seemed to be what your detailing up here
jesse so I think I would do ProjectNotifierAction and
GroupNotifierAction
jesse with associated add/edit/view/remove methods
rahul cool! is it possible to structure xwork.xml like I said above?
jesse not sure about the need of the success.edit stuff
jesse you could do that by having one action and using the
action|method syntax in the jsp
jesse or just have multiple actions referencing the same class and
using the method=x attribute
rahul ah, you are right :)
rahul ok, i gotta run in a minute. do you still want to put this on
the list?
jesse its probably worth it
rahul ok, mind if I just stick in the transcript with a little
background?
jesse you have my authorization :P
rahul aye cap'tn :)
rahul thanks! - i gotta run for work now
rahul cheers
jesse laters
/snip
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Project Group Notifiers
My only slight reservation would be if group-level notifiers can act differently than project-level notifiers. If that's the case, then the behavior of Continuum builds will differ based on which POM is used to add a hierarchy, since the child POMs that are also parents will have their notifiers added at the project level, and would behave accordingly. well, from the model the actual notifiers are the same class in both the groups and the projects, they are just added to a different list depending on if they are in the group or the project...so I don't _think_ that will be an issue. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: building continuum
always works for me on macosx, jdk 1.5, maven 2.0.4 On 10/18/06, Joakim Erdfelt [EMAIL PROTECTED] wrote: The automated unit testing of continuum-release is very hit and miss. Hard to track down. For some people it works every time. For others it works randomly. Even a few people report that the tests work only after executing them multiple times. What I'd like to know is what the differences in environment are between all of these developers? What OS? What JDK? What version of Maven? etc ... - Joakim ben short wrote: Hi Philippe, I wanted to do the same to see if there where any cool new features andran into the same problem. if you do mvn -Dmaven.test.failure.ignore=true package you can grab the war and deploy it tomcat ( or an app server of your choice ) you'll then need to setup 2 jndi jdbc resources which you can see the names for in the log file. I was hoping to see the release stuff like the maestro project server has. I guess this is a feature that has been added by the guys at mergere. Anyway just set the flag and you will get a bit further. Ben On 10/18/06, Philippe Faes [EMAIL PROTECTED] wrote: Dear all, I'd like to get my hands diry on continuum, but I cannot build the continuum trunk http://svn.apache.org/repos/asf/maven/continuum/trunk by running mvn clean install Is this a temprary issue or am I doing something wrong? Also, can I compile (and run the tests) while I have a production continuum-1.0.3 running on the default ports? thanks Philippe --- Test set: org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest --- Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 2.773 sec FAILURE! testReleaseSimpleProject(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) Time elapsed: 1.724 sec FAILURE! junit.framework.AssertionFailedError: Test dev version at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleaseSimpleProject(ReleaseTaskExecutorTest.java:96) testReleaseSimpleProjectWithNextVersion(org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest) Time elapsed: 0.992 sec FAILURE! junit.framework.AssertionFailedError: Test dev version at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.maven.continuum.release.executors.ReleaseTaskExecutorTest.testReleaseSimpleProjectWithNextVersion(ReleaseTaskExecutorTest.java:132) -- ir. Philippe Faes Ghent University - Department ELIS Sint-Pietersnieuwstraat 41 -- B-9000 Gent Tel:+32 9 264 95 25 - Fax:+32 9 264 35 94 http://www.elis.UGent.be/~pfaes ON5DEU -- LPIC1 -- gpg-key:173720B6 -- jesse mcconnell [EMAIL PROTECTED]
Re: contents of a 1.1 release
well, I am working on finishing up some lingering project group functionality now, but once I knock it off my list I'll work on the testing some. I'll need to get up to speed on the latest integration testing work you have been working on jason, and emm mentioned on irc a while back that he was going to take a stab at bringing the web testing back on line so I'll ping him and work with him on that... also, its looks like there is a bit of a split on where to go release wise atm, but I think we can all generally acknowledge that the tests need to get improved, at the very least getting the web testing back where it was before the ui refactor to webwork. Perhaps we should shoot for a feature freeze of sorts for the middle of november and check where we are for a 1.1 release around that time. A month should be more then enough time to get the test case positions recovered to an acceptable lvl and get a mess of the outstanding issues resolved/lacking features fixed up. jesse On 10/17/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful
Re: [vote] rbac-integration branch merge to trunk
summary: +1 - 8 binding would be 5 I think.. So I'll get this merged over in the next couple of days, probably early next week actually, there are some jsp integration issues that will have to take place from what I have heard. but we'll integrate this over to trunk asap, jesse On 10/4/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: 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 -- jesse mcconnell [EMAIL PROTECTED]
rbac-integration continuum branch
Over the course of the past 3 weeks I've worked with joakim on the plexus-security effort to bring rbac based security to Archiva. We succeeded. Last Friday (or so) I took the continuum/trunk and created the rbac-integration branch. I wanted from to test the integration of rbac based security, using the plexus-security project, into continuum. It integrated beautifully, without a whole lot of work, in record time, and is pretty functional now ... Some of the fun things that plexus-security brings with it are: * full separation between application webapp and security (lightweight integration). * proper modularization for security components (authentication, authorization, policy, system, web, etc...) * rbac (role based access control) authorization provider. * full user management war overlay (using healthy chunk of maven-user to make it happen) * toggle-able guest user authorization. * remember me and single sign on authentication. * forced admin account creation (through use of interceptor) * key based authentication (remember me, single sign on, new user validation emails, and password resets). * http auth filters (basic and digest). * aggressive plexus utilization. * aggressive xwork / webwork integration. * xwork interceptors for force admin, auto login (remember me), secured action, and environment checks. * secured actions for all of the /security namespace and at least one continuum secured action (these are enforced by the pssSecureActionInterceptor) * all the password validation, user management stuff (again maven-user origins) * continuum-security artifact containing the actual static and dynamic roles, and a continuum role manager that merges permissions to the core system, user, and guest users * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. * placeholders for ldap authentication, authorization and user details retrieval using plexus ldap components * ability to re-use Acegi for authentication I think it is very usable now, its a matter of some jsp and action work to clean up some things and hide some other knobs and buttons. I'd like to get feedback and discussion from the others here about the implementation, and consider a vote to merge it to trunk after that. I believe it is stable enough to move forward with. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: rbac-integration continuum branch
on a related note and the heels of the last emailsome things to ponder There are a few policy decisions that I wanted to bring up for some feedback... 1) when a project group is added, should the 'Project Developer' role for that project automatically be assigned to the admin user? I think it should, since the admin is able to just go and grant it anyway, but will that encourage making everyone and admin? should that be an option anyway? 2) when a project group is added, should the Project User role be granted to the guest user? I think so, but only if we are going to wrap these things behind authorization... which we really don't have to...which leads to following questions I suppose 3) who should be granted the role that allows for adding projects to continuum? right now that is only the system administrator. Perhaps we make a Continuum Manager role as well that grants that kind of top lvl authorization without handing full sysad rights away...I kinda like that idea. 4) how deep into continuum should the guest user be allowed? should they have access to all levels of the project group information wise, just not able to twiddle any dials or knobs? perhaps for now since continuum was always pretty open before we try and maintain the same lvl of access for guest users, just protect the knobs and buttons. In the long run these behaviors should be configurable I think, but we need to decide on some sane defaults. jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: unit testing headache
could you generate a diff with what you are trying to do and I'll apply the to a fresh checkout and see what I can figure out can't help much unless I can see what your trying to do specifically :) jesse On 8/30/06, Brill Pappin [EMAIL PROTECTED] wrote: all I want to do it write a regression test for some code before I make any changes... But I seem to be unable to inject my fakes into the code under test (members not exposed). So I took a look at some of the other test that use an abstract base test... however it initializes a whole in memory database. it also doesn't seem to work as I keep getting a jpox error about bad mappings: org.jpox.metadata.InvalidMetaDataException: Error in MetaData for field projectGroup in class Project : this is declared as org.apache.maven.continuum.model.project.ProjectGroup with persistence-modifier=none yet has either default-fetch-group=true or primary-key=true specified! These should be false. at org.jpox.metadata.AbstractPropertyMetaData.populate(AbstractPropertyMetaData.java:818) at org.jpox.metadata.ClassMetaData.populatePropertyMetaData(ClassMetaData.java:418) at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:238) at org.jpox.metadata.MetaDataManager.populateClassesInterfacesInFile(MetaDataManager.java:1308) at org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1430) at org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:544) at org.jpox.metadata.MetaDataManager.getMetaDataForClassInternal(MetaDataManager.java:509) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:392) at org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:378) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.getReferencedClasses(RDBMSManager.java:2852) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTables(RDBMSManager.java:2603) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2915) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2540) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2397) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:603) at org.jpox.SchemaTool.createSchemaTables(SchemaTool.java:279) at org.apache.maven.continuum.AbstractContinuumTest.getStore(AbstractContinuumTest.java:132) at org.apache.maven.continuum.AbstractContinuumTest.setUp(AbstractContinuumTest.java:62) at org.apache.maven.continuum.buildcontroller.DefaultBuildControllerTest.setUp(DefaultBuildControllerTest.java:26) If i fix the jdo file manually, I get another one just like this for another mapping... and so on, and so on... Do I really need to use this base test, or does someone have a way to write a simple unit test? - Brill Pappin -- jesse mcconnell [EMAIL PROTECTED]
Re: NPE running trunk
was that just hitting the localhost:9090/ ? I don't think that has been fixed up yet, I mostly just go straight to a page, like http://localhost:9090/groupSummary.jsp I'll take a look at that though and get the / working if its not, pretty sure it wasn't jesse On 8/22/06, Brett Porter [EMAIL PROTECTED] wrote: Hi, I've tried to run Continuum from trunk (just the normal svn up, mvn clean install, cd continuum-webapp, mvn jetty:run), but I get this: :WARN: / java.lang.NullPointerException at org.mortbay.jetty.servlet.DefaultServlet.passConditionalHeaders (DefaultServlet.java:485) at org.mortbay.jetty.servlet.DefaultServlet.doGet (DefaultServlet.java:422) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Anyone seen that? It's a weird one... I wonder if maybe the plexus listener is dying on startup and swallowing the exception? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: jpox 1.1.1 released (upgrade continuum maven-user ?)
someone mentioned we were a couple of versions behind plexus's jdo library too, might be a good time to just get up to date on both of those things... anyway, I think its a good idea so long as it doesn't bust everything up :) +1 On 8/18/06, Joakim Erdfelt [EMAIL PROTECTED] wrote: I'd like to propose that we upgrade to jpox 1.1.1. With the official release of jpox 1.1.1 we should be able to move away from the custom compiled jpox 1.1.0 (pre-release codebase) that we are using in continuum. We are currently using the following for both continuum maven-user ... http://www.ibiblio.org/maven2/org/apache/maven/continuum/jpox/jpox/1.1.0-20060413/ With the eventual upload of jpox 1.1.1 (found in MAVENUPLOAD-1063) we should be able to eliminate jpox / jdo as a source of bugs during the work with CONTINUUM-800. The TestCase in CONTINUUM-800-maven-user-model-testing.patch identified several jpox API changes that - Joakim Erdfelt -- jesse mcconnell [EMAIL PROTECTED]
Re: continuum-webapp issues [was: Re: svn commit: r431764 - /maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp]
URL:
http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp?rev=431764r1=431763r2=431764view=diff
==
---
maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp
(original)
+++
maven/continuum/trunk/continuum-webapp/src/main/webapp/summary.jsp
Tue Aug 15 18:41:17 2006
@@ -19,13 +19,8 @@
ec:row highlightRow=true
ec:column property=state title=nbsp; width=1%
cell=org.apache.maven.continuum.web.view.StateCell/
ec:column property=name
title=summary.projectTable.name width=48%
-!--this doesn't work as the project.id isn't
interpolated
-c:url var=projectViewUrl
value=/projectView.action
- c:param name=projectId value=${project.id}/
-/c:url
-a href=c:out
value='${projectViewUrl}'/${project.name}/a
---
-a
href=/projectView.action?projectId=${project.id}${project.name}/a
+c:url var=projectViewUrl
value=/projectView.action/
+a href=c:out
value='${projectViewUrl}?projectId=${project.id}'/${project.name}/a
/ec:column
ec:column property=version
title=summary.projectTable.version width=13%/
ec:column property=buildNumber
title=summary.projectTable.build width=5%
cell=org.apache.maven.continuum.web.view.BuildCell/
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
--
jesse mcconnell
[EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
it disappeared into the ether of the mailing list? :) I still think its a good idea, thanks for bringing it back up...could be very useful on some of the larger issues like security and project groups, etc.. jesse On 7/12/06, Rinku [EMAIL PROTECTED] wrote: Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse -- jesse mcconnell [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Jesse McConnell updated CONTINUUM-258: -- Attachment: secure-url-continuum-core.patch secure-url-continuum-api.patch secure-url-plexus.patch /home/jesse/osrc/plexus/secure-url-plexus.patch used in combination with the MungedHttpsURL file attached /home/jesse/osrc/continuum/secure-url-continuum-api.patch includes pom.xml addition to add the plexus-formica package as a dependency for the new class /home/jesse/osrc/continuum/secure-url-continuum-core.patch includes pom.xml addition to add the plexus-formica package as a dependency for the new class in all cases the change to the interface has forces changes in a number of unit tests which are as included and all still validates locally (given the patch into plexus) There was talk about new components, or different ways to solve the problem, but this at least gets the change in a fairly nonintrusive manner..if someone wants me to look into building out a different type of component or mechanism then let me know. cheers https:// doesn't seem to be a supported mechanism for referencing a pom --- Key: CONTINUUM-258 URL: http://jira.codehaus.org/browse/CONTINUUM-258 Project: Continuum Type: Bug Components: continuum-web Reporter: Jesse McConnell Fix For: 1.0-alpha-4 Attachments: MungedHttpsURL.java, secure-url-continuum-api.patch, secure-url-continuum-core.patch, secure-url-continuum-pre.patch, secure-url-plexus.patch, secure-url-validation.patch I have a svn repository setup with https:// certificate and AD LDAP password authentication... would be real nice to be able to point to a pom with https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml and have it picked up. right now it just grumbles about Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] (in red even :) -- 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
[jira] Commented: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=comments#action_45216 ] Jesse McConnell commented on CONTINUUM-258: --- attachments from the 25th are the ones that ought to be good to go, the others were for review and whatnot https:// doesn't seem to be a supported mechanism for referencing a pom --- Key: CONTINUUM-258 URL: http://jira.codehaus.org/browse/CONTINUUM-258 Project: Continuum Type: Bug Components: continuum-web Reporter: Jesse McConnell Fix For: 1.0-alpha-4 Attachments: MungedHttpsURL.java, secure-url-continuum-api.patch, secure-url-continuum-core.patch, secure-url-continuum-pre.patch, secure-url-plexus.patch, secure-url-validation.patch I have a svn repository setup with https:// certificate and AD LDAP password authentication... would be real nice to be able to point to a pom with https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml and have it picked up. right now it just grumbles about Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] (in red even :) -- 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
[jira] Created: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
https:// doesn't seem to be a supported mechanism for referencing a pom --- Key: CONTINUUM-258 URL: http://jira.codehaus.org/browse/CONTINUUM-258 Project: Continuum Type: Bug Components: continuum-web Reporter: Jesse McConnell I have a svn repository setup with https:// certificate and AD LDAP password authentication... would be real nice to be able to point to a pom with https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml and have it picked up. right now it just grumbles about Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] (in red even :) -- 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
