geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: no more modules for specs...
Date Sat, 16 Dec 2006 14:08:35 GMT

On 16 Dec 06, at 2:50 AM 16 Dec 06, Jason Dillon wrote:

> On Dec 15, 2006, at 11:05 PM, Jason van Zyl wrote:
>> I doubt it. When it came down to releases and updating artifacts  
>> and trying to tie everything all together. Lots of people might  
>> have problems but even now I bet there are people who could help  
>> with the build if necessary. If you did it in Ant you would be the  
>> only person who would know how it worked. You would get the nice  
>> Inner Platform Effect with a build your size:
>> I'd bet my life you would have more overall problems using Ant.  
>> Just because you could get it to work doesn't mean it would scale  
>> or be something anyone else could comprehend. It's probably  
>> already hard enough with what you have.
> Dang, I could not resist...
> I think that the mvn build we have no is already fairly hard for  
> folks to comprehend and would probably fall apart unless someone  
> like me was here to answer everyones questions and monitor changes  
> to keep things in check.  I think that is no different than if we  
> were using Ant.

I think you under estimate what other people know about Maven in that  
they can apply their knowledge of the infrastructure from other  
projects here provided you're following standard conventions. And  
it's complicated because you're fighting a losing battle with too  
many SNAPSHOTs. Even if the snapshot artifact resolution was perfect  
you would still have these problems. You are getting bitten by some  
severe technical problems in Maven, no doubt, but you are  
exacerbating the situation by using the "SNAPSHOT" identifier  
everywhere which inherently means "a shifting pile of sand" to Maven.  
Start moving to eliminate them and your instabilities will lessen  

> I actually think that Ant + a few tasks to manage limited remote  
> dep inclusion + groovy scripting would be a very powerful  
> combination and would be at least half as complicated as our Maven  
> build.

That's what people always say, but I have first hand experience with  
many large companies with large builds and they are moving away from  
their homebrew systems because they are sinking projects. If you used  
Maven in a way you describe above you would have stability i.e. no  
snapshots. If you're going to script something then create a plugin  
to walk your dependencies and replace the "SNAPSHOT" markers with  
real timestamps and you will have stability. You are so much closer  
to having something working all the time then you think.

> But... I'd rather have Maven with a richer control over how deps  
> get pulled from remote repos, and more control over how local repos  
> get installed/pulled into the cache.
>  * * *
> Anyways, I just want to be able to build G projects/components from  
> source, pull in external binary deps and generate assemblies for  
> specific branches.  This was working fine before... and only the  
> recent change of the specs versioning has tossed me through a  
> loop.  The solution is to make more project configurations to  
> handle each spec, but that is not scalable at all...
> And... well, I think the only fault here really is that people look  
> at other mvn projects and just follow them... regardless if they  
> make sense for the problem at hand.
> I still think remote repos suck... but, maybe you guys will  
> eventually find a better solution to that.

I don't think they suck, I think you're just getting bitten severely  
by the erratic snapshot handling and overuse of snapshots. We will  
eventually get the repository under control as it's clear now they  
have become a mission critical resource for many people, we  
understand that and it will be fixed. There's going to be a lot of  
bitching when we actually turn on the gauntlet. Any release, for  
example which contains a "SNAPSHOT" identifier anywhere in the graph  
will simply be rejected.


> --jason

View raw message