directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Apache DS build, Maven and targeting 1.0 release...
Date Sun, 30 Jul 2006 14:42:18 GMT
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 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.


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

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

>
> Furthermore if you switch to ant+ivy you have to store both ant and 
> ivy versions in your repository or build with that specific release.

That's very true.

>
> If there is a bug in an ant-plugin you want it to be reproduced later, 
> when building that version, even if the new ant-plugin fixed the bug, 
> right?

yep. Because if we have had a bug in a plugin (ant plugin or maven 
plugin), but ifg the build succeeded, then I want to use this buggy 
version. You must consider that if the bug was serious, then a 
workaround has been used, and this workaround will certainly fail with a 
new version of a downloaded plugin, breaking the build. What I mean is 
when a version builds, then it must build for ever, unless you change 
something, which should not happen. The reason behind this "weird" way 
of using bugy plugins is that when you need to build an old version to 
fix a bug, generally speaking, this is urgent ( your client used a very 
old version, then a bug suddenly poped out, an your client need a quick 
fix. If you spend hours -or even days- to fix the build system itself, 
then you are loosing time - and sometime a client ;)

> Stefano
>
Emmanuel

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

Mime
View raw message