Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44CBCA36.7090709@iktek.com>
Date: Sat, 29 Jul 2006 22:51:02 +0200
From: Emmanuel Lecharny <elecharny@iktek.com>
Reply-To: elecharny@iktek.com
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
MIME-Version: 1.0
To: dev@directory.apache.org
Subject: Apache DS build, Maven and targeting 1.0 release...
Content-Type: multipart/mixed;
 boundary="------------070507070003050105060208"

This is a multi-part message in MIME format.
--------------070507070003050105060208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ok, guys, I think we have a recurrent problem with builds.

We need  a build system that is reliable, reproductible, and not only 
for the last version, but for a tag that is 2 years old. If I want to 
build last year 0.8 version of apache ds, i should be able to do so. 
With maven, atm, this is totally impossible, because repositories are 
moving, plugins are moving, and this could break everything.

We have to find another way to build this project. I am serious about 
that. It's just not "maven is cr*p" or "ant is better", is much more a 
question of what should be done to be able to guarantee that a simple 
user check out the full project and build it on its platform, any time, 
anywhere, for any version.

Here is what I excpect for a reliable build system :

- I want to build version X with maven plugins that have been used when 
I tagged the version X. In two years, I want those plugins to be 
available, even if they are full of bugs, just because the build has 
been validated when X tag has been created. I don't want ANY plugin to 
be updated on the fly. Is it possible ?

- I want to build version X with the jars that have been used to create 
the version. I don't want to change the pom.xml files just because the 
remote repository has disapeared or the server name has been changed to 
something different. I don't want that somebody - for any good or bad 
reason - has modified a pom.xml of any jar just because he realized that 
something were wrong when this jar has been pushed on the maven repository.
That means we *must* have our own private local repository with all the 
jars used by a version tagged and stored on subversion, and that we 
*NEVER* download a jar from a remote repository. Remote repository 
totally break the notion of reliable build. It's against common sense 
when you have products running in production and that you need to figure 
out what is going on for a user, and that you need to recreate it's 
environnment.
The remote repository concept is good when you want to get some new 
jars, but not for an old version.

Those two conditions are mandatory. If one of them is missing, then we 
should push a request to maven to fix something. If it's not possible 
before we release ADS 1.0, then we may consider switching to another 
build tool.

We also have some other disturbing points :
 - maven should work offline by default. I don't know if there is some 
options we can set in the configuration files to allow this mode by 
default ( and not have to type maven -o)
 - if new versions of plugins are available, then maven should ask if it 
is allowed to download them, and not dowload them by default (of course, 
the default answer will be no, not yes : "version x.y.z of surfire 
plugin available. Download ? [n]". Of course too, this question should 
be asked only once for a specific version. A "upgrade-plugins" mode 
should also be available. And plugins should be stored in the local 
repository, and versionned in svn, like jars.
 - Surfire should be improved to store errors in a separate directory 
than success. When you have something like dozens tests in a directory, 
this is painfull to check all of them to know which ones have failed 
(but this is a maven issue, not an apacheds problem ;)

May be we can use middle term solutions like storing checksums of jars 
in svn to avoid storing full jars, but, IMHO, jars are not changing 
every days, and we don't have thousands of them, so I think this will 
just means more work to save few mega bytes...

So, now, we have some points we need to discuss :
- we don't have Maven active experts right now, and may be some of you 
would give us a hand to address those problems
- the need of a local repo, where all the jars are stored, and 
versionned, seems to me mandatory
- plugins should be - like jars - versionned
- offline mode must be the default

Ok, this is my opinion. I'm sure that you may agree on some points, and 
disagree on others. I just want to start this dicussion on the ML, as we 
now have some more committers, and we need to find a way to stabilize 
the build before 1.0.

Feel free to express what you think, and it can be as radical as "Let's 
move to ant + ivy". I think that some decision will lead to a vote at 
some point.

wdyt ?

Emmanuel

--------------070507070003050105060208
Content-Type: text/x-vcard; charset=utf-8;
 name="elecharny.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="elecharny.vcf"

begin:vcard
fn;quoted-printable:Emmanuel L=C3=A9charny
n;quoted-printable:L=C3=A9charny;Emmanuel
org:IKTEK
adr:;;13 rue Salomon de Rotschild;Suresnes;;92150;France
email;internet:elecharny@iktek.com
x-mozilla-html:FALSE
url:http://www.iktek.com
version:2.1
end:vcard


--------------070507070003050105060208--