Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
This should do something reasonble: mvn clean install At the cost of taking longer... :-( --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
Re: Assembly is caching old junk
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
Re: Assembly is caching old junk
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
