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
