geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Unable to build using m2
Date Wed, 28 Jun 2006 16:19:34 GMT

On Jun 27, 2006, at 2:15 PM, Jason Dillon wrote:

>>> Any idea where the stax:stax-api:1.1.1-dev comes from?
>>>
>>> The root pom states that stax:stax-api:1.0 should be used... but  
>>> the errors with the xmlbeans plugin all state 1.1.1-dev.
>>
>> I've filed a bunch of bugs all over the place and the current  
>> status is:
>>
>> -- I'm working with the xmlbeans team to publish correct poms for  
>> xmlbeans 2.0.0-1, 2.1.0-1, and 2.2.0.  This will take a while, but  
>> apparently won't conflict with the maven evangelism rules (my  
>> first attempt revealed that the evangelism instructions had no  
>> relationship to the actual process the maven team uses)
>
> How long is a while?

don't know, I think I understand the dependencies properly, but I'd  
like to come up with plausible non-minimal poms for them.
>
> Urg... this is another thing about Maven that really bothers me...  
> we are SO completely dependent on other projects for our own  
> project to succeed.
>
> This would not be a problem if we had our own repo that we had  
> complete ownership of.  We could fix any poms and install fixed  
> plugins.

How would we get these fixes back into the community?  I worry that  
having our own repo would make it harder to assure that we are using  
generally available versions of other projects, and make it harder to  
contribute our fixes back to those projects.  For instance, it took  
me some time to get an m2 build of howl working and find out how to  
get it published, but the result is IMO much better for both howl and  
us than if we simply said "we'll just stick a pom for howl in our  
private repo".

>   And... the build would be completely repeatable.  Chances are  
> that in a year or two, if anyone tries to build anything with Maven  
> off of an old branch it will fail miserably.  IMO this is not  
> acceptable.

Future build failures should only result from someone trashing the  
supposedly permanent ibiblio repo.  As far as your other points, any  
time we decide to use software written by some other community, we  
are depending on them to do some work for us.  I think we need to  
adopt a process that assures our contributions to their project in  
fact get back to their project in a timely fashion.

>
>
>> -- The maven xmlbeans plugin has had a couple fixes applied, but  
>> whether a snapshot is publically available is not clear to me.  I  
>> strongly recommend building the xmlbeans plugin from source.  IIRC  
>> this will eliminate the need for the bogus stax dependencies.   
>> Here's the latest relevant jira:  http://jira.codehaus.org/browse/ 
>> MXMLBEANS-20?page=all
>>
>> After all the fixes are in we should not need any dependencies on  
>> stax-api and the bogus dependencies on stax can be removed.
>
> I really don't like to have to go and check out a bunch of external  
> tools or libraries and then go step by step, configure and build  
> them... and hope like heck that their builds work all of the time,  
> and pray that Maven does not freak-out halfway through a long build  
> due to a missing dependency or repository timeout... just to get  
> the right bits in place to maybe get our build moving forward,

Seems to me the alternative is to not use anyone elses code, which I  
find unacceptable.
>
> This is a nightmare IMO.  I remember a certain nightmarish build  
> way back in the day that needed a bit of magic... in comparison to  
> our build, that nightmare was the sweetest of dreams.
>
>  * * *
>
> The more I think about it the more it appears thats something major  
> is going to need to be done to really fix things...

I surely don't have all the answers, but I'd prefer that anything we  
adopt doesn't result in our having all sorts of private changes that  
are not accepted by projects we use.  So, some kind of geronimo repo  
that has a subset of publically available stuff is ok with me, but  
putting private patches that aren't from the originating project  
seems like asking for trouble.

thanks
david jencks

>
> --jason


Mime
View raw message