OK, I also figured it out (using the new build system).
I've just committed changes that implement a new target:
ant hackyInstaller.runGUI
This does an incremental build of hackyInstaller.jar and invokes it from
within Ant. With a clean environment, it takes around 20 seconds on my
laptop; after that (i.e. after sensorshell jars are unpacked and so forth)
it takes around 7-10 seconds each time, which will be typical when you're
repeatedly editing installer code and rebuilding. In the new build system,
it was pretty easy to write this target (runGUI consists of five previously
defined dependent targets and one call to <java>). Of course, you don't
have to have tomcat running and no webapp related processing occurs.
To reduce the build time below 7-10 seconds will be a little difficult as
it will require decomposing the sensorshell targets, not building the
hackyInstaller.jar, and all this would maybe only save 2-3 seconds per
invocation. It seems more reliable in the long run to just build the
hackyInstaller.jar file in the 'normal' way.
Also, this new target works as expected with respect to the set of
available modules--if you only have kernel and installer available, it will
build the 'minimum' version of hackyInstaller.jar; if you add more modules,
it will build hackyInstaller.jar with whatever sensors are in the
configuration. This is nice because it comes for free in the new build
system structure and without creating the circular dependencies that Aaron
was worried about below.
By the way, in the new build system, hackyInstaller.jar has shrunk from 9MB
to 4MB. It turns out that there was a bunch of jar files and other
directories included into hackyInstaller.jar that shouldn't have been
there.
It's funny to me, as I go through this process, to discover how afraid I
was (and, I expect, everyone else) of 'touching' the old build system. It
led to a lot of classic maintenance behavior: "I don't know why this target
is in there, but I'm not going to touch it!". Thankfully, I feel like I'm
back in a position of control over the build process. :-)
Cheers,
Philip
--On Wednesday, October 12, 2005 10:29 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
Ok, so I figured it out. Well, almost.
1) Run org.hackystat.kernel.installer.controller.Control as a Java
Application 2) Add
"-DinstallerResources=C:\java\cvs\hackyBuild\build\war\WEB-INF\installer"
or something similar to the VM arguments. This can be set by clicking on
Run... , then go to the arguments tab. 3) The tricky thing is that you
have to delete all the sensor installer.<sensor>.xml files from the
"C:\java\cvs\hackyBuild\build\war\WEB-INF\installer" directory, because
HackyInstaller will try to load the sensor installer implementations. For
example, you will get:
HackyInstaller Version:
Wed Oct 12 22:18:49 HST 2005: GUI initialized.
org.hackystat.stdext.sensor.ant.locc.installer.LoccSensorInstallerjava.la
ng.ClassNotFoundException:
org.hackystat.stdext.sensor.ant.locc.installer.LoccSensorInstaller
at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:188) at
java.lang.ClassLoader.loadClass(ClassLoader.java:306) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at
java.lang.ClassLoader.loadClass(ClassLoader.java:251) at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at
java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at
org.hackystat.kernel.installer.model.sensor.SensorDescriber.getInstallerI
nstance(SensorDescriber.java:156) at
org.hackystat.kernel.installer.model.path.ConfigPersistor.persistSensorVe
rsions(ConfigPersistor.java:285) at
org.hackystat.kernel.installer.util.Environment.systemCheck(Environment.j
ava:234) at
org.hackystat.kernel.installer.controller.Control$1.construct(Control.jav
a:161) at
EDU.oswego.cs.dl.util.concurrent.misc.SwingWorker$2.call(Unknown Source)
at EDU.oswego.cs.dl.util.concurrent.FutureResult$1.run(Unknown
Source) at
EDU.oswego.cs.dl.util.concurrent.misc.SwingWorker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:595)
So, delete these installer.<sensor>.xml files. But, you have to leave
proxy.xml, installer.common.xml, hackyinstaller.xsd, and usermaps.xsd.
4) Run the Control class. You will see an "empty" hackyInstaller
application, which will let you test out all the buttons that don't do
things with sensors.
I'll leave it to you guys to figure out how to run hackyInstaller with a
sensor. Note, that I was thinking that we could make hackyInstaller
depend on hackyAnt, but that is not possible because hackyAnt depends on
hackyInstaller. But, you see that hackyInstaller functionally depends
(through reflection) on hackyAnt. Circle dependency!
I hope that solves some of the build time problems for you InstallHack
guys.
thanks, aaron
At 09:24 PM 10/12/2005, you wrote:
I've been looking at running hackyInstaller through eclipse, i.e.
running Control.main() as a Java Application. There are some problems
with getting the right System.properties. For example, I'm not quite
sure how installerResources gets set or how it is used. It is probably
really worth sitting down for a couple of hours (if it even takes that
long) to figure out how to do it. Then you can run hackyInstaller for
these GUI UI debugging without even the Ant based build.
Austin, Hongbing is probably the best person to help you figure this out.
thanks, aaron
At 09:17 PM 10/12/2005, Philip Johnson wrote:
--On Wednesday, October 12, 2005 6:32 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
And maybe the GUI creation process won't be as painful when the new
build system is in.
Whoa, using even quickStart to do your kind of GUI UI debugging is way
too much overhead!
For this kind of iterative development, you should create an ant target
(in hackyInstaller/local.build.xml) that just recompiles the sources
and then invokes <java> with the appropriate classpath and main class
to start with. Two or three seconds max should be all you should need
wait for the window.
As Aaron says, of course run the test suite before committing your
changes, but if you're just doing button placement there's no sense in
redeploying the server or anything.
Cheers,
Philip
