geronimo-dev mailing list archives

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

-dain

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


Mime
View raw message