geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Assembly is caching old junk
Date Wed, 25 Oct 2006 23:43:54 GMT
Thanks Jason!


On Oct 25, 2006, at 4:19 PM, Jason Dillon wrote:

> I think I may have fixed this.  Now, when installing car modules  
> into an assemblies repository, if the module already exists in the  
> target repo, the config.ser.sha1 in the source and target repos is  
> compared.  If they are the same, then the module is skipped (as was  
> the behavior before), else the module is uninstalled from the  
> target repo and then reinstalled.
> Logging output has been trimmed, so it only shows what is being  
> installed.  mvn -X shows full details about uninstalls and skipping.
> Lemme know if you still see old artifacts getting cached in  
> builds... there might still be a few more holes to patch, but this  
> was the big one.
> --jason
> On Oct 25, 2006, at 2:04 PM, Jason Dillon wrote:
>> Hrm... this ends up reinstalling way to many modules.  I think we  
>> may need to encode a guid in the car which can be inspected to  
>> find out if an installed car is the same as a car to be  
>> installed... so that we can intelligently skip reinstalling a  
>> car... instead of blindly skipping or reinstalling.
>> --jason
>> On Oct 25, 2006, at 1:49 PM, Jason Dillon wrote:
>>> Since people is still down I can't do much on gbuild, as there  
>>> are too may deps missing, and it would take too long to build the  
>>> deps or upload from my network...
>>> I looked into this problem... may have a fix, though I'm not 100%  
>>> sure this is all that needs to be done.  Looks like when we  
>>> install configs into the assembly's target store, we skip modules  
>>> that exist already.  I'm going to add a flag (default to true)  
>>> which will trigger existing modules to be uninstalled first  
>>> instead of just skipping them.
>>> --jason
>>> On Oct 19, 2006, at 4:34 PM, Dain Sundstrom wrote:
>>>> I don't understand how any of this stuff works.  All I know is  
>>>> when I run mvn install I don't get my source changes.  It would  
>>>> be nice to have a single command that does something reasonable.
>>>> -dain
>>>> On Oct 19, 2006, at 4:17 PM, David Jencks wrote:
>>>>> It might help anyone trying to fix this if you can determine  
>>>>> what is out of date in the assembly.  For instance,
>>>>> -- assembly might pick up timestamped jars instead of locally  
>>>>> build -SNAPSHOT jars
>>>>> -- assembly might include old copies of jars
>>>>> As workarounds for the first you can build offline after  
>>>>> removing all g. timestamped jars from your m2 repo
>>>>> for the second perhaps running mvn -o clean install in assembly  
>>>>> would help.
>>>>> Pesonally I try to only rebuild stuff that I've changed or  
>>>>> depends on stuff I've changed
>>>>> thanks
>>>>> david jencks
>>>>> On Oct 19, 2006, at 3:40 PM, Dain Sundstrom wrote:
>>>>>> The tck is moving very slow because when I make a simple  
>>>>>> change to a jar the final assembly is getting the old code.   
>>>>>> For example, I do the following:
>>>>>> * changing some code (In my case naming)
>>>>>> * run "mvn install" from the geronimo/server/trunk
>>>>>> At this point if I unpack an assembly and debug, it I get the  
>>>>>> old code. The only way I have found around this is to run a  
>>>>>> clean build (and a clean build again in the tck), which means  
>>>>>> the turn around time to test a single fix to a tck bug is  
>>>>>> about 30 minutes.  Can someone please fix this?
>>>>>> -dain

View raw message