directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: Apache DS build, Maven and targeting 1.0 release...
Date Sun, 30 Jul 2006 01:48:42 GMT
Comments Inline

> 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.

Plugin versions can be specified
in the pom.

project > build > plugins > plugin > version


>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 ?

At http://www.ibiblio.org/maven2
all the builds of various plugins and
implementations/apis have been versioned.

I suspect the same is true for most other repositories
like codehaus.

The only way to protect against someone changing an
existing
version, or removing it,  is to download that version
into the local maven repository, and
check that version in with the build or create our own
maven plugin repository, and keep the
plugin versions there.  So we should do this if we
consider that
version to be critical to that build, and we really
really want to make sure we can come
back and rebuild any time.   If we check the version
in with the build, we have to document that
so that someone can restore it to a local maven
repository.  If apacheDS has its own plugin
repository,
then we just point maven there, and away we go.  That
repository could also be used by anyone
to build specific versions of ADS.


>
> - 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.

Same answer as above.  We have to localize it.

> 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.

Yup - So we would just initialize the local repository
- then set
the offline attribute in settings.xml, so that maven
does everything offline.


> Remote repository
> totally break the notion of reliable build. It's
> against common sense

Well - Personally - I have to say I love being able to
add a dependency
and have maven take care of the rest.  I've never
experienced anyone changing
an existing version of a plugin or dependency api,
thus breaking my build.  Although
you are right, we still need to buffer against that. 
Setting up a maven plugin repository is really easy
though.
 
> 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.
>

I think what gets put on ibiblio stays there for a
long time.  We could check with them to see if they
have
some sort of version rotation policy.

In the end the only way to really protect each build
is to have a local repository with plugin and api
dependencies in it, as well
as the version of maven that was used for the build.


> We also have some other disturbing points :
>  - maven should work offline by default.

Set the offline attribute in settings.xml before
firing up maven.


> 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.

Settings.xml has a releases element that has an
updatePolicy attribute.  Here's what the doc says
about it:
updatePolicy
The frequency for downloading updates - can be
"always", "daily" (default), "interval:XXX" (in
minutes) or "never" (only if it doesn't exist
locally).

 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
> ;)

I know that surefire is supposed to create a nicely
formatted html report:
http://maven.apache.org/plugins/maven-surefire-report-plugin/report-mojo.html

I'd have to look and see precisely what it reports on
though.

>
> 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...


That sounds like a really good idea!







--- Emmanuel Lecharny <elecharny@iktek.com> wrote:

> 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
> > 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
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message