On Jul 1, 2006, at 2:14 PM, Jason Dillon wrote:
Bummer... highly sucky that we must clean to make a build. Stuff
like this negates some of the intelligence the build uses to reduce
the amount of work (and time to execute).
In general I recommend that a normal build never need to clean,
move or delete files, so that steps that have completed previously
do not need to be redone (where applicable).
Anyways, not a major issue right now, but going forward we will
want to clean this up.
This requires careful analysis of what files determine the content of
a car file. If all versions are specified in
explicit_versions.properties, geronimo-dependency.xml inside jars,
the pom, or the plan, then explicit_versions.properties, pom.xml, and
the plan might be sufficient. However if there are any snapshot jars
in use, if any of those have changed you need to rebuild. If there
is an unspecified version anywhere, you need to check if there is a
newer version than was used previously. Since this might have been
downloaded from somewhere else, and built well before the last build,
I'm not sure that timestamp comparison will work... I'm not sure how
dates get set when you copy or move a file. I can't say i'm very
attracted to trying to make this logic foolproof: building all the
configs all the time seems a bit more reliable to me.
* * *
Is it the local module's target than needs to be cleaned?
yes
If so, we can add a step that runs before car to invoke the clean
plugin's clean goal. This is only a short-term fix though, I do
not recommend that we start adding this pre-cleaning anywhere else.
The assemblies should in my experience also be cleaned first, or you
tend to get into trouble if you remove a car from the assembly.
Timestamp checking could help here too, but again this isn't
something I have a burning desire to experiment with.
thanks
david jencks
--jason
On Jul 1, 2006, at 12:47 PM, David Jencks wrote:
The packaging plugin needs to be made to do a clean first, the m1
plugin did this with jelly.
I always run mvn -o clean install inside configs, which is
annoying, but I haven't had time to investigate how to do "clean"
from within an m2 plugin. Maybe you or someone else knows how?
thanks
david jencks
On Jul 1, 2006, at 12:17 PM, Jason Dillon wrote:
This happens during the m2 build... and actually the build ends
up cycling between 2 errors, this one and another that is an
internal plugin error regarding some JCL classes...
:-(
At least it appears to switch back and forth between these two
errors and is not completly random... but still its _whack_ that
the same build fails in different ways on consecutive runs.
I was just running this over and over:
mvn -o -Dmaven.test.skip=true
(with changes applied from GERONIMO-2161)
--jason
On Jul 1, 2006, at 12:08 PM, Jacek Laskowski wrote:
On 7/1/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Is there any reason why a rebuild (with no clean) would cause
errors
like this:
<snip>
[INFO]
------------------------------------------------------------------
------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------
------
[INFO] java.lang.reflect.InvocationTargetException
Configuration already exists: org.apache.geronimo.configs/rmi-
naming/
1.2-SNAPSHOT/car
</snip>
Just a guess, isn't Geronimo already populated with the config and
thus the error? I believe the script uses deploy nor redeploy. What
command did you use? It's M1 build, isn't it?
--jason
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
