directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject g
Date Mon, 31 Jul 2006 07:15:41 GMT
Alex Karasulu a écrit :

> Emmanuel Lecharny wrote:
>> repositories are moving, plugins are moving, and this could break 
>> everything.
> I share your frustration.

It's not a frustration. It's a fear...

> ...
>> - 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 think there is a way for us to do this.  Just use specific plugin 
> versions to stabilize the build wrt plugin variance.  This is the root 
> of the problem.

Yeah, I think there should be a way to tell maven - like we do for jars 
- that we want to use a specific version of a plugin. Maven guys, any clue ?

>> - 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. 
> Forgive me bro but I disagree with this idea.  I just think we're not 
> using maven properly.  Maven has it's issues but overall we're not 
> tuning our build to make it work consistently with updates to plugins 
> in the repository.  We can do better and have some advice from the 
> other emails I've seen.

It's not a problem with maven. It's a general build concept. Whatever 
tool you use, you want to be able to build an old version with the good 
jars. Good jars means jars which have the same tags. With a remote repo, 
you have zero guarantee that somebody didn't change it. This is the 
concern I have, it's not a problem of using maven instead of another 
tool. Sorry if I wasn't able to express it clearly. Signature of jars is 
something that could be used to verify that a remote jar is good, but if 
this remote jar disapear, you are dead.

> ...
>> 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.
> I'm open to other tools but only after we have grasped the use of the 
> current build tool's features better.  I don't think we've done that 
> (speaking more for myself).  Also what's scary is I'm perhaps one of 
> the most Maven savvy on this team besides Brett Porter.

No, don't get me wrong. Again, it's not a question of dumping maven 
because it's maven. (man, we are using maven 2, it's not anymore maven1 
! ;) but I really think that we should be able to reach the two points I 
mentionned before. I don't know how to do that with Maven atm. I hope 
that this thread with help to get some maven gurus to give us some good 
advices. But again, there are some points we need to address, whatever 
tool we use./ /And I'm perfectly aware of the cost of a migration to 
ant+ivy, and I think it's better to stick to something that work, if we 
can have this needed reliability.

> *wish* :)
> I really wish Brett had the time to step in and show us some tricks to 
> help fix these problems (hint hint).

Brett, or any other Maven guy who know better that we do how to 
configure it. Ole ?

> ...
>> - 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 totally agree, this is one of my biggest issues with this plugin.

Yeah, this is not really an issue, it's much more a pain ...


View raw message