Re: Apache Continuum is now an Apache top level project
nice! On Wed, Feb 20, 2008 at 12:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
well, if you want to have a plugin based architecture, what better that OSGi? and it may help too for distributiion of build machines On Feb 6, 2008 2:08 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Are you thinking what I am thinking - an OSGi based runtime underneath and plugins/extensions that could be loaded runtime? :-) Carlos Sanchez wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: 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 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [VOTE] release continuum-1.1-alpha-2
+1
On 5/30/07, Jesse McConnell [EMAIL PROTECTED] wrote:
I would like to get alpha-2 released to the community now.
Highlights are:
revamped xml-rpc support
converted to use rebranded plexus-security, aka redback
continuum maven plugin
many bug fixes and ui improvements.
I have it staged at:
http://people.apache.org/~jmcconnell/continuum-1.1-alpha-2
If this vote passes, I will move the relevant tar and zip balls to the
following location like I did with the first alpha release.
http://people.apache.org/builds/maven/continuum/1.1-alpha-2
I'll also update the continuum wiki to point to the new alpha release
and get the continuum website updated with the information as well.
I'll also announce all this to the continuum users list. This will
hopefully be the last of the alpha releases followed by a beta release
in a month or so.
Normal voting rules, 72 hours, +1/0/-1
Below this is the jira release notes for this release.
Release Notes - Continuum - Version 1.1-alpha-2
** Bug
* [CONTINUUM-620] - Changes section in Continuum build result and
build e-mail only show blank columns and file names
* [CONTINUUM-684] - Access to Continuum using XML-RPC is not authenticated.
* [CONTINUUM-1229] -
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Invalid default
value for 'SCM_USE_CACHE'
* [CONTINUUM-1269] - Recforing of the XMLRPC server, must be a
servlet on the same port used by the webapp instead of a specific port
* [CONTINUUM-1275] - Project Group Name that contains only spaces
can be added.
* [CONTINUUM-1276] - Error in editing the Project name using spaces only
* [CONTINUUM-1282] - Adding or editing a Project Build Definition
can accept spaces in pom file name
* [CONTINUUM-1289] - Sorting Usernames in Build Management's
Project Group member list does not work in Firefox 2
* [CONTINUUM-1290] - Project ID is not validated when adding a Project Group
* [CONTINUUM-1292] - Error when clicking build icon in Project
Build Definitions summary
* [CONTINUUM-1293] - Hitting 'Add' button repetitively in adding
an Ant, Shell and Schedule using empty string only accumulates
validation prompts
* [CONTINUUM-1294] - Adding a Schedule, Ant/ Shell Projects can
accept spaces
** Improvement
* [CONTINUUM-1035] - Dependent builds not triggered via XMLRPC
* [CONTINUUM-1186] - Application should unpack to continuum-${version}
* [CONTINUUM-1297] - update to redback from plexus-security
** New Feature
* [CONTINUUM-683] - Implement a ping service that XML-RPC
clients can use to test connection.
** Task
* [CONTINUUM-1242] - Update Continuum Model
--
jesse mcconnell
[EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: XML RPC security
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
Re: [Vote] release continuum 1.1 alpha 1
1 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 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Preparing for continuum-1.1-alpha-1
i'd say, get the alpha asap and then worry about tooling, people will request it but hopefully we'll get help when people start trying it. On 3/7/07, Jesse McConnell [EMAIL PROTECTED] wrote: Ok, well the little poll thread I made seemed to be strongly in favor of getting things pulled together to start getting alpha releases out of continuum. So with that in mind here is a list of a few things that we need to get in order for an alpha release that I shamelessly started base on bretts comments - properly mark up the model as it was for 1.0.3 release - add methods to continuum-data-management to utilise that and then make any necessary transformations (c-d-m will do the basic 1-to-1 conversions) - probably write a little CLI to fire it off. - vet jira for a 1.1 alpha 1 release version and maybe schedule out a couple of alpha-# releases. I think I'll start in on the data management bit now since that seems like the biggest hurdle. I am not convinced we really need to worry about a continuum 1.0.3 - continuum 1.1 migration ability...its not a difficult thing to get projects loaded back up into continuum...but we'll see I guess. anyone have anything to add? 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
Re: Poll: release continuum alpha
+1 for a beta, if everything it's cool let's go for 1.1 and push to 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
Re: Poll: release continuum alpha
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
Re: Poll: release continuum alpha
I really don't like the idea of pushing again the release for more features, because what today are couple features and a week of work it's gonna end in another alpha release 5 months later as it happened with maven and it's happening with continuum. We have to be reasonable about how many features fit in a release. What's wrong with getting 1.2 when that features are out? remember, we are the enablers of agile development and we release once a year. On 2/24/07, Jesse McConnell [EMAIL PROTECTED] wrote: 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [discuss] iBatis, JPA and Java 5.0
On 1/2/07, Rahul Thakur [EMAIL PROTECTED] wrote: - Original Message - From: Brett Porter [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Wednesday, January 03, 2007 4:59 PM Subject: Re: [discuss] iBatis, JPA and Java 5.0 I've been thinking stay with JDO for now, look at JPA in the long term. I haven't used iBatis, and would be happy to hear some practical experience from people who have. I tend to think of it as a more productive JDBC, as opposed to the different programming model of JDO/Hibernate/JPA. I haven't used it either, but that thread got me thinking about what would drive the choice of a persistence solution if we were rethinking jpox. I did use it and yes, it's a more productive JDBC. If you need to do low level stuff then go for ibatis, but I wouldn't do it for Continuum unless really needed, it's going to be pretty verbose. I don't thing it's a good idea to have several implementations of the data store (JDO, ibatis, JPA,...), there's gonna be a lot of refactoring work and one will be the default while the others won't get a good level of stability not being widely used. Having worked with a number of models myself on large production sites (straight jdbc, castor, object structured jdbc, and now jdo2), I really like the design of the jdo2 API. It does a good job of giving a nice clean API that manages to keep the declarativeness while still allowing good performance through fetch groups and lazy loading. I think the store itself that we have is quite stable, but it's API is too simple. Yep, it is verbose, IMHO. I am keen to explore and see if we can consolidate some of them by wrapping up the possible criteria in a 'Query' object and make the store interface leaner. I think that the way we use the store hasn't taken into consideration the way that the objects are returned (ie, they may be missing some fields you didn't request, etc). The way Continuum is designed means you get to a certain point where you want to save an object and you find that you can't, or you aren't saving everything you want, etc. I am not sure what you refer to by: [snip] The way Continuum is designed means you get to a certain point where you want to save an object and you find that you can't, or you aren't saving everything you want, etc. [/snip] Could you please give an example? Changing to another type of store will make that worse and we'll discover the same problems and have to make the same design choices then. So, I'd prefer to address them first. Yeah, possibly will make it worse if and when we start :-), and +1 on the design choices bit. IMO, we need to centralise more of the object access. So, obviously we've centralised JDO to the store, which is good. But I think you'll find the use of the store itself is a little too proliferated, at least for the level of abstraction you have. That is what we want to try on that branch that Jesse created. I am hoping I can get a proof out before Jesse wraps up his changes :-) Rahul What you ideally want to be able to do is say that a certain set of actions are going to constitute the entire transaction, and do the reading from the store at the start and the saving at the end I'm oversimplifying, but that's what I'm generally thinking. I haven't looked at that code in a year and a half though - so maybe it's not quite as relevant now. - Brett On 03/01/2007, at 2:43 PM, Rahul Thakur wrote: These buzzwords have been making rounds on IRC and dev list :-), and after slight digging around I found a reference to a similar discussion here: http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/ msg01251.html Agreed that the store implementation for Continuum should be pluggable, and if we are rethinking JPOX, then IMHO it might be worth taking into account JPA and Java 5.0. What do others think? Cheers, Rahul -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: New User Registration problems
hehe, please file jira issue On 12/26/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'm having trouble with new user registration. (The creation-verification-change password flow works, but so do some things that shouldn't.) 1. Register for an account 2. Ignore the confirmation email 3. Attempt to log in with the new userid. Leave the password blank 4. You are prompted to 'Change Password' 5. Leave the 'existing password' blank, and enter a new password (twice). 6. You are logged in and on the Edit Details screen 1a. The newly created account is not Locked (even though the registration confirmation page says it will be.) 1b. Even if you log in as admin and lock the account, steps 3-5 still work. 4a. If you navigate away from the change password page without completing it, you appear to be logged in and can see everything from project groups down to build results. (Possibly related to [1] where a guest user with no roles can also see everything.) [1] http://www.nabble.com/Projects-are-visible-to-a-guest-user-with-no-roles-t2873616s177.html -- Wendy -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: rbac-integration continuum branch
is it using maven-user? there's already all user management code there to avoid duplication in different applications. On 9/28/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 for the merge Emmanuel Jesse McConnell a écrit : 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 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: svn commit: r446713 - in /maven/continuum/branches/continuum-acegi/continuum-webapp/src/main: java/org/apache/maven/continuum/web/action/ resources/ webapp/
next week i'm going to sync bug fixes in both
On 9/17/06, Brett Porter [EMAIL PROTECTED] wrote:
Does this affect trunk too?
- Brett
On 16/09/2006, at 6:04 AM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Fri Sep 15 13:04:10 2006
New Revision: 446713
URL: http://svn.apache.org/viewvc?view=revrev=446713
Log:
[CONTINUUM-905] Deleting a project build definition by clicking the
'delete' link results in a 404.
Added:
maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/deleteBuildDefinition.jsp (with props)
Modified:
maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/java/org/apache/maven/continuum/web/action/
BuildDefinitionAction.java
maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/resources/xwork.xml
maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/confirmBuildDefinitionRemoval.jsp
Modified: maven/continuum/branches/continuum-acegi/continuum-webapp/
src/main/java/org/apache/maven/continuum/web/action/
BuildDefinitionAction.java
URL: http://svn.apache.org/viewvc/maven/continuum/branches/
continuum-acegi/continuum-webapp/src/main/java/org/apache/maven/
continuum/web/action/BuildDefinitionAction.java?
view=diffrev=446713r1=446712r2=446713
==
--- maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/java/org/apache/maven/continuum/web/action/
BuildDefinitionAction.java (original)
+++ maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/java/org/apache/maven/continuum/web/action/
BuildDefinitionAction.java Fri Sep 15 13:04:10 2006
@@ -192,7 +192,7 @@
{
if ( confirmed )
{
-getContinuum().removeBuildDefinitionFromProject
( projectGroupId, buildDefinitionId );
+getContinuum().removeBuildDefinitionFromProjectGroup
( projectGroupId, buildDefinitionId );
return SUCCESS;
}
Modified: maven/continuum/branches/continuum-acegi/continuum-webapp/
src/main/resources/xwork.xml
URL: http://svn.apache.org/viewvc/maven/continuum/branches/
continuum-acegi/continuum-webapp/src/main/resources/xwork.xml?
view=diffrev=446713r1=446712r2=446713
==
--- maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/resources/xwork.xml (original)
+++ maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/resources/xwork.xml Fri Sep 15 13:04:10 2006
@@ -121,7 +121,7 @@
result name=success
type=chainprojectGroupBuildDefinition/result
/action
-action name=removeGroupBuildDefinition
class=buildDefinition method=removeFromGroup
+action name=removeGroupBuildDefinition
class=buildDefinition method=removeFromProjectGroup
result name=confirmconfirmBuildDefinitionRemoval.jsp/
result
result name=success
type=chainprojectGroupBuildDefinition/result
/action
Modified: maven/continuum/branches/continuum-acegi/continuum-webapp/
src/main/webapp/confirmBuildDefinitionRemoval.jsp
URL: http://svn.apache.org/viewvc/maven/continuum/branches/
continuum-acegi/continuum-webapp/src/main/webapp/
confirmBuildDefinitionRemoval.jsp?
view=diffrev=446713r1=446712r2=446713
==
--- maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/confirmBuildDefinitionRemoval.jsp (original)
+++ maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/confirmBuildDefinitionRemoval.jsp Fri Sep 15 13:04:10 2006
@@ -19,8 +19,9 @@
/p
/div
div class=functnbar3
- ww:form action=removeProjectBuildDefinition
+ ww:form action=removeGroupBuildDefinition
ww:hidden name=buildDefinitionId/
+ww:hidden name=projectGroupId/
ww:hidden name=projectId/
ww:hidden name=confirmed value=true/
c1:submitcancel value=%{getText('delete')} cancel=%
{getText('cancel')}/
Added: maven/continuum/branches/continuum-acegi/continuum-webapp/
src/main/webapp/deleteBuildDefinition.jsp
URL: http://svn.apache.org/viewvc/maven/continuum/branches/
continuum-acegi/continuum-webapp/src/main/webapp/
deleteBuildDefinition.jsp?view=autorev=446713
==
--- maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/deleteBuildDefinition.jsp (added)
+++ maven/continuum/branches/continuum-acegi/continuum-webapp/src/
main/webapp/deleteBuildDefinition.jsp Fri Sep 15 13:04:10 2006
@@ -0,0 +1,31 @@
+%@ taglib uri=/webwork prefix=ww %
+%@ taglib uri=continuum prefix=c1 %
+html
+ ww:i18n name=localization.Continuum
+head
+ titleww:text name=deleteBuildDefinition.page.title//
title
+/head
+
Continuum build for official release [CONTINUUM-727]
I've merged the changes in https://svn.apache.org/repos/asf/maven/continuum/branches/release-integration into continuum and the release plugin to enable the build for official release feature that i think will be very useful to everybody. If anyone has any concern please let me know. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Continuum build for official release [CONTINUUM-727]
right On 9/17/06, Brett Porter [EMAIL PROTECTED] wrote: So, as I understand it - Jeremy and Edwin can continue to work on the branch and we can merge again as there are more changes? - Brett On 18/09/2006, at 11:13 AM, Carlos Sanchez wrote: I've merged the changes in https://svn.apache.org/repos/asf/maven/continuum/branches/release- integration into continuum and the release plugin to enable the build for official release feature that i think will be very useful to everybody. If anyone has any concern please let me know. -- 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
Re: Cancelling builds
On 9/14/06, Kenney Westerhof [EMAIL PROTECTED] wrote: Hi Team, Yesterday I've committed some code to enable cancelling builds: * Schedules have a setting that indicates the maximum job execution time, where job means BuildProjectTask; 0 means indefinitely, the default being 1 hour. * You can cancel a running build. I'm not sure where to put the cancel build button, so right now I've added a '(cancel)' link to the StateCell that's displayed in the projectGroupSummaryAction page (and probably other places). Some questions/remarks: - What's the best place to place the cancel build button? Perhaps just list the job on the summary page as 'current job' (in the future: current jobs) and add a cancel button there. - The build ID of the cancelled task will either be 0 or max(build id), depending on when it's cancelled. The project _is_ set in error state so it finishes normally. This gives me the idea that the build number issue already was there; this needs to be fixed (I'm looking into it). - The results page is broken - some jdo detached error with scmResults. I can't figure out why it doesn't work. This and a lot more bugs have been fixed in the acegi branch. I'll merge them back when I have some time, but if you need something look there first. - We might want to set a timeout on individual actions instead of the entire job (1.2?) - An issue Emmanuel has pointed out to me is that cancelling builds on windows doesn't work well. I've dug into the sun site and found several others with the same problem. The issue is that on windows, if you execute a batchfile (Runtime.exec) and you cancel that, any process started in the batchfile isn't killed. This is due to windows process management. Just a question: why not call m1/m2/java from a new classloader/thread within continuum itself? Saves some shell magick, and it's more easily killed (using the concurrent package). Or call java directly - also no problem with killing that and any child processes. -- Kenney -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: svn commit: r431246 - /maven/continuum/trunk/continuum-webapp/
that be great, but in the meantime this is very handy
On 8/13/06, Brett Porter [EMAIL PROTECTED] wrote:
Wouldn't it be better to fix the tests/execution to create this in a
more normal place, like target/plexus.home as it used to be?
- Brett
On 14/08/2006 7:29 AM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Sun Aug 13 14:29:07 2006
New Revision: 431246
URL: http://svn.apache.org/viewvc?rev=431246view=rev
Log:
Ignore db folder
Modified:
maven/continuum/trunk/continuum-webapp/ (props changed)
Propchange: maven/continuum/trunk/continuum-webapp/
--
--- svn:ignore (original)
+++ svn:ignore Sun Aug 13 14:29:07 2006
@@ -1,3 +1,4 @@
+
target
.classpath
.project
@@ -5,3 +6,4 @@
continuum-webapp.iml
*.ipr
*.iws
+${plexus.home}
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: svn commit: r431246 - /maven/continuum/trunk/continuum-webapp/
Emmanuel told me that this was about to be fixed, but this was more
than a month ago.
Added as CONTINUUM-812
On 8/13/06, Brett Porter [EMAIL PROTECTED] wrote:
kind of against the principles of Continuum to sweep things under the
carpet :)
Do you want to create a jira for it?
- Brett
On 14/08/2006 7:49 AM, Carlos Sanchez wrote:
that be great, but in the meantime this is very handy
On 8/13/06, Brett Porter [EMAIL PROTECTED] wrote:
Wouldn't it be better to fix the tests/execution to create this in a
more normal place, like target/plexus.home as it used to be?
- Brett
On 14/08/2006 7:29 AM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Sun Aug 13 14:29:07 2006
New Revision: 431246
URL: http://svn.apache.org/viewvc?rev=431246view=rev
Log:
Ignore db folder
Modified:
maven/continuum/trunk/continuum-webapp/ (props changed)
Propchange: maven/continuum/trunk/continuum-webapp/
--
--- svn:ignore (original)
+++ svn:ignore Sun Aug 13 14:29:07 2006
@@ -1,3 +1,4 @@
+
target
.classpath
.project
@@ -5,3 +6,4 @@
continuum-webapp.iml
*.ipr
*.iws
+${plexus.home}
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: svn commit: r420933 - in /maven/continuum/branches/continuum-acegi/continuum-webapp/src/main/resources: commons-logging.properties log4j.properties
it's not that I just ignore it, I thought that was the way to do it. On 7/19/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: Carlos Sanchez wrote: I don't know how to configure commons-logging and log4j through plexus for Acegi Then you should ask instead of just ignoring the issue. I just saw that Kenney did the same thing, I hope that he'll fix it once and for all now. -- Trygve -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Continuum Security design
I've updated the wiki with my latest thoughts. I suggest this reading http://acegisecurity.org/docbook/acegi.html#domain-acls which explains how to add instance based security with ACLs. It's a good option and allows fine grained permissions for user, project and type of operation. On 7/11/06, Jesse McConnell [EMAIL PROTECTED] wrote: well, here are my thoughts on the matter summed up after some subsequent discussion on this between joakim, carlos and myself: If continuum is to scale up to multiple projects, say continuum building in the same instance along side maven and the maven repository manager then we are going to need a simple fine grained security mechanism that isn't clunky to use. the perhaps ill chosen 'unholy marriage of security strategies' phrase above basically refers to the current implementation of groups and roles. We have role based security for all of the different types functionalities, and then it has been kicked around to have group based access to different projects...and these groups are made up of sets of roles. Perhaps there was some misunderstanding on the specifics but at least my thoughts on the matter are that we are best served with a straight forward role based security model where access to special views and the ability to perform certain actions are governed by individual roles on a per project basis. ie, if there is a role for 'FORCE_BUILDS' then there ought to be one of these roles for each project in continuum, in the above example we might have 'CONTINUUM_FORCE_BUILD', MAVEN_FORCE_BUILD' and 'MRM_FORCE_BUILD'. Each user would have the ability to be assigned these roles and would then have that access for each of the particular projects. If we have this simple role based approach then all of the security checks, which as joakim mentioned are the vast majority of usage for the security', are very simple role checks. It becomes then a matter of figuring out the best way to manage these roles and there are lots of different examples of that out in the wild, be they the ability to make profiles of roles that can be applied to users, to long lists of checkboxes (not so fun). Joakim had mentioned that the roles would likely be dynamic based on the projects as they were added in and that we could put in some simple dynamic filters or profiles that would initialize the project and a user with the necessary settings and then further access could be pushed out from there.. I talked to trygve about this a bit and he mentioned that jason has put some rbac (http://en.wikipedia.org/wiki/RBAC) code into plexus sometime ago...and that is ultimately where any of this needs to end up so that other projects can have immediate access to the different security mechanisms. carlos, joakim...I miss anything in this? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: introduction
Thanks Erik, I'm pretty sure Emmanuel will have some questions for you ;) On 7/8/06, Erik Bengtson [EMAIL PROTECTED] wrote: Hi All, I'm a JPOX developer and because Continuum uses JPOX I thought it may be a good idea to keep an eye in this list to help you guys in sorting out issues with the product. As outcome of following this project, I'm willing to reduce the troubleshooting time spent when using JPOX and thus improve JPOX operating tools, like documentation, logging, clear error messages and so on. Regards, Erik Bengtson -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Non-public projects
I think this is what it's planned for 1.1 by adding security through Acegi On 4/13/06, David Blevins [EMAIL PROTECTED] wrote: There is a new feature I need and I'd like to get feedback from the group on how it may be implemented. Don't know if I'll end up writing, but at least I'd like to get some discussion going for now. We at Geronimo desperately need to be able to setup a couple projects in continuum that aren't public -- they're tck related. So basically, we need some way to mark a project as viewable by only logged in individuals in a specific group. Having them listed on the main page with the other projects is ok, just clicking on anything there should require you to be properly authenticated and authorized to do so. This is a big new can of worms for Continuum, so what does everyone think? Good feature/bad feature? Any thought's on what'd be required to implement it? -David -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Fwd: [ANN] Apache JDO 2.0 beta released
Is it right to be in javax.jdo when the reference implementation seems to be jpox? On 1/31/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: it is there : http://www.ibiblio.org/maven2/javax/jdo/jdo2-api/2.0-beta/ Thanks. I'll switch. Emmanuel Brett Porter a écrit : we should switch to this - not sure if its in the repo yet. - Brett -- Forwarded message -- From: Craig L Russell [EMAIL PROTECTED] Date: Feb 1, 2006 5:47 AM Subject: [ANN] Apache JDO 2.0 beta released To: general@db.apache.org Cc: JDO Expert Group [EMAIL PROTECTED], Apache JDO project jdo-dev@db.apache.org The Apache JDO project http://db.apache.org/jdo is pleased to announce the release of Apache JDO 2.0 beta, a preview release of Apache JDO 2.0. Apache JDO is a subproject of the Apache DB project. JDO is a JCP standard interface for persistence of Java objects. It is datastore-agnostic and supports relational and non-relational databases. For details, please see http://jcp.org/en/jsr/detail?id=243 The Apache JDO project builds the JDO API jars used by application programmers and the JDO TCK jars, used to verify compliance with the specification. The Apache JDO project does not build an implementation of JDO 2.0. The JDO 2.0 Reference Implementation is JPOX, which is available via its own download: http://jpox.org Apache JDO API and TCK are available as a source download from mirrors http://www.apache.org/dyn/closer.cgi /db/jdo/2.0-beta. The jar files are available in binary form as maven form from mirrors /java-repository/javax.jdo and /java-repository/org.apache.jdo JDO 2.0 builds on the JDO 1 API. Applications built to use JDO 1 need only to be recompiled to run with JDO 2.0. Features in the JDO 2.0 release include: - Standard mapping from objects to relational databases - Multi-tier support without use of Data Transfer Objects - Improved query support including projections and aggregates - Stored queries in metadata - Deletion by query - Optimized fetching of object graphs without writing special queries - Extensive List and Map support - Lazy loading of large collections - Better support for single-field primary keys - Object lifecycle event monitoring - Improved support for bidirectional relationships Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
[jira] Commented: (CONTINUUM-508) Unable to add multimodule projects from CVS
[ http://jira.codehaus.org/browse/CONTINUUM-508?page=comments#action_53286 ] Carlos Sanchez commented on CONTINUUM-508: -- So seems that you have to install it first with maven? that doesn't sound very user friendly Unable to add multimodule projects from CVS --- Key: CONTINUUM-508 URL: http://jira.codehaus.org/browse/CONTINUUM-508 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Carlos Sanchez Priority: Critical If you try to add a multimodule hosted in CVS you get things like * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/core/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\core\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/core-tiger/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\core-tiger\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/adapters/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\adapters\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/domain/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\domain\pom.xml (The system cannot find the path specified) You can try with http://cvs.sourceforge.net/viewcvs.py/*checkout*/acegisecurity/acegisecurity/pom.xml -- 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-508) Unable to add multimodule projects from CVS
Unable to add multimodule projects from CVS --- Key: CONTINUUM-508 URL: http://jira.codehaus.org/browse/CONTINUUM-508 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Carlos Sanchez Priority: Critical Fix For: 1.1 If you try to add a multimodule hosted in CVS you get things like * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/core/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\core\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/core-tiger/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\core-tiger\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/adapters/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\adapters\pom.xml (The system cannot find the path specified) Check the logs for more details. * Could not download file:/C:/apps/continuum-1.0.2/bin/../temp/summit-1/domain/pom.xml: C:\apps\continuum-1.0.2\bin\..\temp\summit-1\domain\pom.xml (The system cannot find the path specified) You can try with http://cvs.sourceforge.net/viewcvs.py/*checkout*/acegisecurity/acegisecurity/pom.xml -- 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
Re: Design - Replacing Continuum's Web Framework
On 12/2/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: I never used JSF, but i've heard too some negatives points. I think it's more simple to do the migration to jsp technology because (if we need some help, tools, components...) lot of resources are available JSF is JSP based, you can use jstl and taglibs to write your jsps.
Re: Any reason why jaas would be missing from the repository at ibiblio
Because it can not be redistributed due to license constraints. http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html On 11/15/05, Eric Starr [EMAIL PROTECTED] wrote: Just downloaded continuum svn co http://svn.apache.org/repos/asf/maven/continuum/trunk/ continuum and tried to build but the build failed. Downloading: http://repo1.maven.org/maven2/jaas/jaas/1.0.1/jaas-1.0.1.jar [WARNING] Unable to get resource from repository central ( http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Does anyone know why jaas would be missing from the repository? http://www.ibiblio.org/maven2/jaas/jaas/1.0.1/ Thanks, Eric S.
