geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Assembly is caching old junk
Date Wed, 25 Oct 2006 21:04:16 GMT
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.


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