On the branching front, it seems like we could be making more use of
branches with subversion. I've just been reading this:
http://svnbook.red-bean.com/en/1.0/ch04s07.html
and this
http://www.onlamp.com/pub/a/onlamp/2004/08/19/subversiontips.html?page=1
and having a look at other repositories like the apacheds one:
http://svn.apache.org/repos/asf/directory/
It seems like if I needed to do some work that was intended for a future
release I could quite easily create a branch, e.g
svn copy -m "Creating branch for ldap template integration"
https://svn.sourceforge.net/svnroot/acegisecurity/trunk/acegisecurity
https://svn.sourceforge.net/svnroot/acegisecurity/branch/mytempbranch
then at some time in the future, merge the changes into the trunk and
remove the branch using "svn delete".
The apacheds guys maintain a readme.txt file to keep a record of
previous "dead code" to allow them to locate it if needed, without
having to rad through log files.
http://svn.apache.org/repos/asf/directory/sandbox/readme.txt
This seems like quite a practical way of working as it allows developers
to experiment with changes to the main codebase in isolation from
everyone else without cluttering up the repository for future development.
Presumably it is also easy to create branches "retrospectively"? i.e. we
can create a 1.0.x release "branch/copy" from a previous revision number.
I'll try and look at the site generation stuff when I get some time
(probably after mid-September). Converting the html files will be a bit
of a pain if it has to be done. We could get a trial site up and running
before a final move (on a branch, for example :).
I think we should ditch the jar signing and use PGP instead. If we sign
each other's keys when we get a chance and publish them on the web site
then that should be adequate.
cheers,
Luke.
Ben Alex wrote:
> Luke Taylor wrote:
>> That's good. You'll be an expert on branching with subversion then :-).
>>
>> I'd like to get the automatic build upgraded to Maven 2 as well (and
>> running again). There are a couple of issues I've come across so far:
>
> I am a BIG fan of moving to Maven 2 ASAP. Acegi Security is the only
> application I still have which requires Maven 1.0.2, and every time we
> release it requires a slightly different workaround (typically
> MAVEN_OPTS parameters for JVM memory/stack allocation). I'd much prefer
> the improved robustness of Maven 2, even if it means most of the reports
> are lost. The only essential use cases are compile, JAR, test, DocBook,
> unit test coverage report, and site build.
>
>> 1. The new site generation doesn't seem to support html files. Do you
>> know if they all have to converted to xdoc, apt or whatever to be part
>> of the main site (with the menu etc).
>>
>> 2. The contacts app is too complicated - I thought about refactoring
>> this into a single web-app where people can comment select which
>> contexts are included in the web.xml file.
>
> As discussed on Skype, I am happy for this to proceed. It is more
> user-friendly in any event that people wanting to try X509 certificates,
> CAS or container adapters be able to do so without the inconvenience of
> building from source.
>
>> There was also some guy in the forum complaining about the fact that the
>> jar wasn't signed. We should probably formalize the use of PGP keys, add
>> them to the website and arrange to do some key signing when possible.
>> The readme file also needs to be changed.
>
> I have a PGP key these days (ID 0x9BBCD24D) and know that both Luke and
> Carlos do, so it's pretty easy to go with ZIP-level signing - plus
> there's a lot of precedence for this approach courtesy of Apache. Do
> people feel we should continue to sign the JAR using keytool, though, as
> well? Does anyone actually rely upon JAR signing? Carlos, has Maven got
> any smarts in terms of automatic verification of JARs downloaded from
> repositories against the public keys in the repository or similar? I
> don't see a lot of value in maintaining two signing approaches, as it
> would make life harder for someone else to perform releases. In any
> event, I'm a little tired of annually renewing keytool certificates when
> PGP keys can be configured to never expire (yet still provide a
> revocation approach).
>
> Cheers
> Ben
>
--
Luke Taylor. Monkey Machine Ltd.
PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lis
