Hi guys,

On 11/5/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Hi Felix,

Felix Knecht wrote:
> I've still no commit access to the sandbox directory. Never the less I started to adapt the doc "Build Apache Directory
> Studio" and put it into the Apache Directory Sandbox [1] (I think that's the way do to).
>
Hmmm... Let me check that this afternoon...
> Still some questions I couldn't find (or haven't seen) an answer in the docs:
>
> a) Which svn:keywords are set and used? Looking at some files I can see different svn:keywords set, but they not always
> seem to match with the references in the code.
>
There is no current list of used svn:keywords...
> If no rule exists yet I'd like to suggest the following:
>
> svn:keyword Id
>
> /**
>  * Foo bar
>  *
>  * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
>  * @version $Id: AbstractStudioMojo.java 350 2007-10-28 12:01:17Z felix $
>  */
>
We are not using names into header. Here are our coding standards :

http://cwiki.apache.org/DIRxDEV/coding-standards.html

I guess this is the result of a substitution performed by SVN on the Id macro.  I don't think
Felix was intending to add an @author tag which is essentially the basis of the ASF wide
recommendation.

I know there are distinct rules about the @author tag but did we ever agree on whether or not
to use other tags like Id, Date, Revision etc?  Can't remember sorry.

> b) I haven't found any documentation about project/modules/code which is done automatically (e.g. maven reports, maven
> site, JavaDocs, ...).
> Is this all done either in the cwiki or packaged into a downloadable/buildable distribution?
>
We don't anymore generate the site from code, we use confluence for that.

We should generate Javadocs though, but I'm not a maven guru enough to
guarantee that the current maven configuration allows that. And I would
add that I would be very pleased if you can tell me ;)

Generating maven reports would be a very valuable addition, too !

+1

It would be nice if we integrated nicely the javadocs and reports so they deployed to areas that our
confluence generated site can point to by default. 

>
> c) Do any ideas about automated continuous integration exists, e.g. continuum?
>
We tried continuum once upon a time, we also tried bamboo, and we
currently have some another continuous integration server running,

I think Chris setup TeamCity from JetBrains on his servers.  Once Chris get's some free
time we intend to move this setup over to a dedicated server with much more power and
network bandwidth.  The resources have been acquired it's just a time thing.

Felix if you want to be involved in building up this environment let me know and we can
work together with Chris as well to set it up sooner rather than later.

but
we would like to speed up the tests a lot before fully activating the
continuous build again. FYI, building the server 'cost' 20 minutes on my
laptop, and around 10 minutes on a fast server. We also have had by
spamming experience with continuous integration (a mail every 3 minutes
sent to the full dev list - 200 peeps - 2 days long ...), so we are not
really keen to play this game again, unless someone who *knows* how to
correctly setup such an environment handle it (ie, not me, obviously :)

Yes this was killing Chris' hardware and there were some other issues.  However
we should not have the same issues with the new dedicated machine.  Once we have
this changelog and the ability to revert the server for tests instead of stopping,
destroying, reinstalling and restarting the server the tests will run on the order of
5-10X faster.  I personally use a ramdrive to speed things up but I only get a 2X
improvement: this is a hack.

Anyways I would like to setup the new build/CI server to do a few things:

 o synchronize a partial read-only mirror repository off of http://svn.apache.org/repos/asf/directory
 o use this read-only repository for checkouts and to trigger events via custom hooks
    - takes load off of Apache repository
    - much faster since checkouts are local
    - simplifies managing custom hooks
 o build unofficial daily snapshots and expose for testing and download
 o perform standard CI sequence with repository changes
 o integrate VSLDAP conformance tests with CI on dedicated VSLDAP server
 o deploy builds to SLAMD environment for accumulating a panel of simple performance metrics
    used to correlate changes to the server

This is pretty ambitious and will take some time but we have the tools to do the job.  The pay
off I think with automating all this is huge and so the time expense is well worth it.

Alex