geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Unable to build using m2
Date Thu, 29 Jun 2006 09:04:20 GMT


Jason Dillon wrote:
>>> 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.

"In theory there is no difference in theory and practice.  In practice there is."

I agree with your comments but I also recognize that it is a slippery slope.  Who is responsible
for 
tracking the changes and lobbying the other groups?  My limited experience tells me that this
will 
likely end up being a set of forked code from other projects that will be very difficult to
manage. 
  for instance...say a quick change is made to XMLBeans and it get's put into our "local"
copy.  4 
months later the XMLBeans folks have not done anything with the patch and now after discussing
it 
further decide that it doens't fit with their direction.  During that time Geronimo has relied
on 
the patch and changing direction is going to be painful.

I realize this is a worse case scenario but we had a similar situation with the Axis guys
in cutting 
a 1.4 release for us.  It took about 6 months and I think was only done because David Blevins
was 
made a committer.

In order to consider this it would be great if you could flush out the different scenarios
as you 
see them and how we would handle them.  I'm not the most administrative person on the planet
and 
what you are proposing sounds great and scare the heck out of me at the same time ;-0

> 
> --jason
> 
> 
> 

Mime
View raw message