The problem is really in the configs build... and is compounded by
the assembly build, especially for the bits which are picked up from
a boilerplate.
--jason
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
