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: [vote] Request Graduation to a TLP
+1 On Feb 5, 2008 3:06 PM, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > Hi, > > Below is the current proposal for the Continuum TLP. > Please vote on whether to make this proposal a formal request to the Maven > PMC to apply for graduation. > > [ ] +1 > [ ] 0 > [ ] -1 > > Cheers, > Emmanuel > > > Establish the Apache Continuum Project > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the Foundation's > purpose to establish a Project Management Committee charged with > the creation and maintenance of open-source software related to > the domain of continuous integration. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Continuum PMC", be and > hereby is established pursuant to Bylaws of the Foundation; and > be it further > > RESOLVED, that the Apache Continuum PMC be and hereby is > responsible for the creation and maintenance of software related > to the domain of continuous integration based on software licensed > to the Foundation; and be it further > > RESOLVED, that the office of "Vice President, Apache Continuum" be > and hereby is created, the person holding such office to serve > at the direction of the Board of Directors as the chair of the > Apache Continuum PMC, and to have primary responsibility for > management of the projects within the scope of responsibility of > the Apache Continuum PMC; and be it further > > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Continuum PMC: > > - Maria Odea Ching ([EMAIL PROTECTED]) > - Joakim Erdfelt ([EMAIL PROTECTED]) > - Olivier Lamy ([EMAIL PROTECTED]) > - Trygve Laugstol ([EMAIL PROTECTED]) > - Jesse McConnell ([EMAIL PROTECTED]) > - Brett Porter ([EMAIL PROTECTED]) > - Edwin Punzalan ([EMAIL PROTECTED]) > - Carlos Sanchez ([EMAIL PROTECTED]) > - Wendy Smoak ([EMAIL PROTECTED]) > - Rahul Thakur ([EMAIL PROTECTED]) > - Emmanuel Venisse ([EMAIL PROTECTED]) > - Kenney Westerhof ([EMAIL PROTECTED]) > - Andrew Williams ([EMAIL PROTECTED]) > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Emmanuel Venisse be > appointed to the office of Vice President, Apache Continuum, to > serve in accordance with and subject to the direction of the > Board of Directors and the Bylaws of the Foundation until death, > resignation, retirement, removal or disqualification, or until a > successor is appointed; and be it further > > RESOLVED, that the initial Apache Continuum PMC be and hereby is > tasked with the creation of a set of bylaws intended to > encourage open development and increased participation in the > Apache Continuum Project; and be it further > > RESOLVED, that the initial Apache Continuum PMC be and hereby is > tasked with the migration and rationalization of the Apache > Maven PMC Continuum subproject; and be it further > > RESOLVED, that all responsibility pertaining to the Maven Continuum > sub-project and encumbered upon the Apache Maven PMC > are hereafter discharged. > -- 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=rev&rev=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=diff&rev=544179&r1=544178&r2=544179 > == > > --- maven/continuum/trunk/pom.xml (original) > +++ maven/continuum/trunk/pom.xml Mon Jun 4 09:32:12 2007 > @@ -65,6 +65,13 @@ > > > > + maven-compiler-plugin > + > +1.5 > +1.5 > + > + > + >maven-release-plugin > > https://svn.apache.org/repos/asf/maven/ > continuum/tags > -- 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:
> > 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
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: 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
+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: [discuss] iBatis, JPA and Java 5.0
On 1/2/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: 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: Are passwords required?
imo, password fields must be filled if they have the * as mandatory On 12/26/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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] -- 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: 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
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: 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=rev&rev=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=diff&rev=446713&r1=446712&r2=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=diff&rev=446713&r1=446712&r2=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 @@
> type="chain">projectGroupBuildDefinition
>
>
> - class="buildDefinition" method="removeFromGroup">
> + class="buildDefinition" method="removeFromProjectGroup">
>confirmBuildDefinitionRemoval.jsp result>
> type="chain">projectGroupBuildDefinition
>
>
> 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=diff&rev=446713&r1=446712&r2=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 @@
>
>
>
> -
> +
>
> +
>
>
>
>
> 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=auto&rev=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" %>
> +
> +
> +
> + title>
> +
> +
> +
> + h3>
> +
> +
> +
> + name="deleteBuildDefinition.confirmation.message">
> + ww:param>
> +
> +
> +
> +
> +
> + method="post">
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
> Propchange: maven/c
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: jpox 1.1.1 released (upgrade continuum & maven-user ?)
btw not long ago a guy from jpox stepped up, Erik Bengtson <[EMAIL PROTECTED]> http://www.nabble.com/introduction-t1911387.html He was very helpful. On 8/18/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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] -- 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=431246&view=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: 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=431246&view=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: 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: Continuum 1.1 roadmap
On 6/28/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Jason van Zyl a écrit : > > On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: > >> Hi, >> >> I started to define the roadmap of continuum 1.1. It will be done >> normally tomorrow. > > Are we deciding that these are the things are going to be in 1.1 and > take as long as we need? I would prefer that myself. Looking below there > I think that's a good list. I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each items, perhaps we'll do an intermediate release. > >> >> The major first things to do in this roadmap are: >> >> - Reimplementation of authentication/authorization management >> (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with >> acegi. Carlos will integrate acegi with plexus. This part must secure >> all requests in continuum and not only don't show some part of the >> interface. >> > > If a plexus component is made to integrate Acegi that's cool. As long as > Continuum itself has an abstraction for security and Acegi is not > coupled directly to Continuum that's fine. Normally, they won't be coupled. Carlos, can you add more informations? Acegi is coupled to some classes of Spring IoC to respond to events that we'll work around in some way with plexus. Everything else related to IoC is just wiring up objects, not tied to Spring. We'll need to get a minimal Spring jar with the classes needed: exceptions, utils,... > >> - Remove JDO (at least jpox) because it the source of lot of our issues >> > > +1 > >> - implementation of continuum profiles and installation >> screens(CONTINUUM-44,CONTINUUM-59) >> > > +1 > >> - integration of GBuild (CONTINUUM-563) >> > > +1 > >> - implementation of project groups (CONTINUUM-30, >> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) >> > > +1 > >> Other important things I'd want to see in it: >> >> - customization of the add project feature. In this part, I think to >> add a multi-project as a multiple projects or as a single project, scm >> connection string to use, add with a scm url, add all modules by a scm >> connection instead of an url contruction based on project url provided >> in the add screen >> > > +1 > >> - build on dependencies changes >> > > +1 > >> - add a tests result summary in build results >> > > +1 > >> I'll add missing issues in jira tomorrow when I'll continue the roadmap. >> > > Cool, thanks Emmanuel. > >> Emmanuel >> >> > > Jason van Zyl > [EMAIL PROTECTED] > > > > > > -- 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 > > > > > > > > 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! > > > > > > > >
Re: Security in Continuum
I can talk about acegi as I'm committer there: acegi provides three points of security - filter level, protect urls by using web filters - method invocation level - instance level (ACL) 1. filter level By adding filters to the webapp you can control what patterns of urls require what user roles This is transparent to your application so it doesn't matter what web framework do you use. 2. method invocation level You can specify what methods and classes a user is allowed to call based on the user roles, mostly used with spring managed beans 3. instance level (ACL) For each instance of an object you can define if the user rights, that's the same as a file system where files have user, group and everybody permissions, in fact this is the sample used in one of the Spring books. This is accomplished using Aspectj JoinPoints. http://www.acegisecurity.org/docbook/acegi.html#acls The best feature about acegi is that it almost doesn't interfere with your application. Authentication can be done using web forms, http basic, certificates, ... For the backend you can use LDAP, database, container managed users, JAAS, CAS (single sign on),... It also provides a lot of goodies like password encryption, forcing https, remember me, ... and everthing through configuration so you don't need to change code to enable/disable them About the concern of using spring, if you don't configure acegi through spring IOC you'll need to instantiate the objects and make the callbacks that spring does after. You'll still need some spring interfaces and utils that acegi depends on. Hope this helps. On 1/11/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > Hi, > > In 1.1, we have decided to rework all security features. > > I tried to use osuser but this framework is crappy : > - UserManager is a final class that load a osuser config file, we can't set > parameters with plexus > because all initialization phase are done in constuctor that read config file > - need to duplicate code between Authenticator and AccessProvider > - all providers interface extends a base provider interface that require some > methods without > relation with provider must do > > I looked at berkano too. This project use actually dao pattern and hibernate > and permission doesn't > seems to be supported > > I looked at seraph too. This project seems to be interesting, it's used by > confluence and jira. It > seems we have all we need in it but it require to be used in a web app > environment, so i think we > can't use it if we want to use security framework in a standalone app in > future. > > jaas: i think we need a more high level framework. I'd prefer to use a plugin > where jaas can be plugged > > acegisecurity: this framework seems to be the more advanced. The most > important problem for its > usage, it's that required spring framework. I don't like to include in > continuum a new IOC container > only for this feature especially with a 2Mo jar. Can we exclude easily spring > dependency from acegi > by writing a mockimplementation? Can we use it in a standalone app? > > last possibility : we can write our own security framework. If we choose it, > we'll can start with > features required by continuum (user, group, general and per project > permission schemes) and we'll > add more functionalities later if we need more. > > What do you think about all these frameworks? > Which do we choose? > > Emmanuel > >
[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: Design - Replacing Continuum's Web Framework
On 12/1/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Carlos Sanchez wrote: > > Acegi is based in servlet filters for the protection of urls, so the > > web framework used won't impact its use. > > That's great. Does it still require spring to be configured though? We > already have a massive download - I'd really like to reduce our > dependency set. You could be able to configure it in other way. Spring basically just call getters and setters. However some classes implement Spring interfaces and makes use of Spring tools. My first though and i think John agrees with me is let's include first Spring jars, and after worry about removing unneeded stuff. > > > I was in a project using JSF and seems that it's adoption is getting > > speed, with different implementations and a lot of extensions, > > utilities and tools. I've heard very good things about using > > Facelets+JSF to create components, and also about Spring MVC, but > > seems to me that people using Spring MVC is moving to JSF. > > I've heard a lot of negative points about its use without tools support > too. However I haven't done the necessary investigation. I flicked > through some examples and found the pages almost illegible for the > number of tags for a simple form, and haven't really seen an example of > templating (perhaps that is meant to be external?) > Yes, the spec by itself is not a good idea, you should use tools available. MyFaces provides some cool stuff, new components,... There are emerging a lot of projects surrounding JSF I suggest this read http://jroller.com/page/RickHigh > Although I don't have experience with either Spring MVC or WebWork, at > least with an action framework and JSP/velocity its a bit familiar - I'd > be worried about the learning curve of JSF as a barrier to contribution. > I get the feeling WW will be easy to learn for your average struts > veteran :) > I don't find it that difficult, and I think in a year new people will stop learning Struts, and go for JSF. I'm pretty sure that a high perecent of people willing to help will be *new* people, from universities and so, more than *old* people > Of those, WW seems the best choice to me as it is coming to Apache and > is the more mature solution, and probably most familiar wrt summit. > > I'd also endorse the use of sitemesh. That is a servlet filter that sits > in front of the app to "skin" it. It's very fast, and easy to use. There's really good integration between myfaces and tiles, it composes tha pages transparently for you. > > Cheers, > Brett >
Re: Design - Replacing Continuum's Web Framework
Acegi is based in servlet filters for the protection of urls, so the web framework used won't impact its use. Are you planning protecting just urls or any other stuff? acegi can do authorization and authentication at class, method and instance level too, but I think that's only needed in a few types of applications. I was in a project using JSF and seems that it's adoption is getting speed, with different implementations and a lot of extensions, utilities and tools. I've heard very good things about using Facelets+JSF to create components, and also about Spring MVC, but seems to me that people using Spring MVC is moving to JSF. My 2 cents On 12/1/05, John Casey <[EMAIL PROTECTED]> wrote: > Hi everyone, > > We've been talking about this for quite awhile in various channels, and > I wanted to take a few minutes and formalize the discussion. I'll > capture the highlights of this discussion in the wiki afterwards. I'll > start by posting my own thoughts, and let you all respond. > > Up to this point, Continuum has been built on a web framework called > Summit, which is part of the Plexus project, and using Velocity as the > page rendering technology. Summit is still a very young project, and as > a result has its problems. Given the proliferation of web frameworks out > there, it seems natural to wonder whether we couldn't find something > more mainstream and mature that will fit our needs. > > The key goal here is to make the web tier as easy to understand as > possible by the widest possible audience, without sacrificing anything > in the way of quality. To that end, criteria might include: > > * tool support > * maturity in the form of multiple final releases (or at least one) > * good integration with JSP (it's the most widely-used rendering > technology out there for java) > * ready availability of good documentation > * integration with a decent security library (think acegi) > * others? > > Another big concern is that we need to be able to make this web > framework integrate with Plexus without too much funny business. I don't > expect that to be a big problem, but worth mentioning. > > I know that a certain amount of work has been done by Trygve and > Emmanuel to get WebWork running inside Plexus. Is this the best > framework? A quick check of Amazon showed three books, only one of which > is completely concerned with WW. SpringMVC might be another option, > since it has probably the most natural integration with Acegi. There is > a certain amount of overlap between Spring and Plexus that we'd probably > have to map with a custom Spring container or something, but that's > likely to be everywhere, since dependency injection is such a hot topic > (and very useful). > > What do you all think? > > -john >
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. > >
