directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Buildsystem studio
Date Mon, 05 Nov 2007 17:17:43 GMT
Hi guys,

On 11/5/07, Emmanuel Lecharny <> 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="">Apache Directory
> Project</a>
> >  * @version $Id: 350 2007-10-28 12:01:17Z felix
> $
> >  */
> >
> We are not using names into header. Here are our coding standards :

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

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 !


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.

> 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.
we should not have the same issues with the new dedicated machine.  Once we
this changelog and the ability to revert the server for tests instead of
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
 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.


View raw message