geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Unable to build using m2
Date Wed, 28 Jun 2006 21:20:39 GMT
>> 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".

We could use JIRA to manage any customizations that we have been  
forced to make to get _our_ build working, and then work with the  
external groups to merge the changes and ultimately get sync'd up  
with more official drops.

BUT, I still believe that it is in our communities best interest to  
maintain our own repository.


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

I agree completely.  What I am suggesting is that we use our own repo  
to facilitate this process while letting our project move forward.   
The alternative is that we must work in lock step with every other  
community... where a trivial change to a pom takes weeks to get  
implemented and pushed.


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

I don't believe that not using thirdparty code is an option.  We just  
need to find and implement a better way of dealing with them.

I do believe that for a large project like Geronimo, that the central  
remote repository model breaks down and is not very functional for  
current builds or for repeatable builds of older code.


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

I do not believe that this will be the case.  The repo would mostly  
exist to support the longevity of our builds and for short-term fixes  
while we wait the term and lobby external groups to get changes  
pushed back into their community.


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


I agree, though as mentioned above, some artifacts may be custom in  
the short-term.  For example, we could "fix" the xmlbeans artifacts  
and poms, deploy them to our repo and then track the progress of  
integrating them back into the main xmlbeans community with JIRA.   
This is a case where we have a private version in the repo, but it  
will only live there (with a specialized version of course) until the  
time is passed when the xmlbeans team can work in the changes.

--jason

Mime
View raw message