directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <>
Subject Re: Apache DS build, Maven and targeting 1.0 release...
Date Sun, 30 Jul 2006 23:20:16 GMT
Emmanuel Lecharny wrote:
> Hi Stefano !
> Stefano Bagnara a écrit :
>> Emmanuel Lecharny wrote:
>>> So, now, we have some points we need to discuss :
>>> - the need of a local repo, where all the jars are stored, and 
>>> versionned, seems to me mandatory
>> I think that you don't need versioning when using maven repositories.
>> Maven repository expect that each new version of a jar get a new name 
>> and you never override it (it caches artifacts by they version).
>> Imho you just need a repository, you don't need a versioned repository.
>> You should also make sure that you always use specific version in 
>> "dependency/version" and never use an open range.
> This is an assertion that does not resist to facts. If anyone just 
> change a pom.xml file just because there were something wrong ( and 
> regarding the number of jars in a full maven repo, and all the 
> dependencies any jars have ), this is more than likely to occurs. Let 
> say this will occur (and it has already occured). At least, the pom.xml 
> and .sha1 related with any jars should be versionned, but then to 
> guarantee that the jar remains available, then the jar itslef should be 
> versionned.

I think that if you start having different versioned artifact for each 
version you will have much problems with Maven2. Imo you should try to 
avoid this at all costs. Btw I'm not a maven expert.. just used it in a 
few projects.
The pom is part of the artifact, if you change it you HAVE to make a new 
release and create a new version for it.

> I know this seems to me a little bit extermist, but at the end, this is 
> the way to go. And considering that jars are not changing very often, a 
> versionned repo seems just common sense to me. For the sake of reliable 
> builds.

Well, "versioned" is an additional option: imho it is not needed and you 
should avoid to use versioning for artifacts, but the fact that you have 
them in a versionable file system is not a problem :-)

>>> [..]
>>> 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 ?
>> What do you think that ivy repository will fix from maven2 repository?
> Nothing at all. It's just totell people who may want to switch to ant : 
> "guys, it's ant PLUS ivy, not ant alone". The problem here is not maven 
> against ant, it's more or less the way we should manage this project. 
> But if we found 10 people wanting to help building a reliable build 
> system that want to switch to ant+ivy and only a couple of maven 
> afficionados, then there is a clear balance for ant+ivy. The problem we 
> have is more or less competence. I'm definitively not a maven or ant 
> guru, and we really are loosing a lot of time fixing those build issues, 
> and it's occuring too often. So just consider this mail as a SOS, not a 
> rant against maven.

This make sense. If you have skilled people on ivy then it worth working 
with it. I've used both, but I'm not an expert. I feel maven2 (2!) is 
already better and its architecture allow for much more improvements via 
plugins. I would flee on another planet if you asked me to build 
directory using ant+ivy: you have a lot of modules and a complex 
dependency tree!

>> If you need the ant way to do thing, you can store the jar in the lib 
>> folder and declare the dependency scope as "system" so maven2 does not 
>> use the repository but read the jar from the folder you specified.
> Thanks for the trick ! Do you have any pointer to documentation about 
> this feature ?

I used this in past:

Unfortunately currently the site generation (dependency.html generation) 
throw an NPE if you have system scoped libraries.

Btw I think that repositories are really cool and having a repository 
for that libraries is better than having them in the source repository.

> [...]
> PS: As far as I know, I see that James project is using a /lib directory 
> to store all the jars it uses, so I assume that it is somehow related to 
> the issue we currently try to address. And I don't think that the James 
> project has done the wrong choice, IMHO :)

Please note that James Server currently use ANT as a build system. I 
introduced a pom.xml only to generate the new james project website and 
that pom.xml takes almost "random" dependency to be able to run tests 
and create reports but is not intended as a build system for James 
Server (Note to myself: I should add a disclaimer somewhere to make this 

So we have jars in lib because we use basic ant ;-)

I've replied to this message because we (James PMC) are currently 
discussing of maven2 and repository problems, similar to what you rised 
here, and I think that we all (ASF projects) have similar requisites and 
problems and we can discuss this things together.

As an example we evaluated the idea to create a maven2 repository for 
james project and store there everything needed to build/run james 
products. I currenlty have put some third party artifact in a temporary 
repository while we search for a solution to this issue.

I'm reading the archives of ml and I saw that 
there is ongoing discussion about an ASF repository (already created) 
and a new third party library repository (currently discussed).
I think that the solutions proposed for the ASF release/snapshot 
repositories are good but I cannot see a solution for third party 
libraries yet: I hope they will decide soon to create a third-party 
libraries repository. I think that we can try to have a single 
repository for all the ASF projects (I hope we can keep a cleaner 
repository than ibiblio) and the maven2 repository structure make sense 
even for non-maven users (I think).

I believe that maven2 is the way, and being it an ASF project we should 
find collaboration from them to provide us the features we need.
I really like your "offline by default" and "interactive update" 
suggestions. I think that maven2 developers will be happy to address our 
problems: if we (other apache projects) leave maven in favor of another 
build system they really failed their goal (IMO).

I also think that maven architecture and its plugin system should allow 
us to create an "ASF release plugin" that simplify the creation/upload 
of artifacts with md5/sha/pgp hashes/signatures.

That said my holidays are near now.. I'll look forward for your progress 
at the end of august. Currenlty I think the best way is to create a 
custom maven2 repository for each apache project (coordination need too 
much time, now) and put there plugins and third party products needed to 
build so that you have a "source repository" and an "artifact 
repository", then we can try to merge to a single ASF repository for 
third party artifacts. Btw I'm not strong with this idea.. I hope that 
something better will be proposed here or on repository@...


View raw message