--On Monday, September 19, 2005 10:55 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
Here is my initial version:
<http://csdl.ics.hawaii.edu/~kagawaa/hackyMaven-0.1.1.zip>. With
Philip's permission, I will commit this module to CVS.
Sure thing. Just so that I am clear on the intent: I assume that what
this provides is the ability for Hackystat sensors to work in a project
that uses Maven as its build facility? If so, then this module would
probably be called hackyApp_Maven in version 7 of Hackystat.
1) There is something wrong with the Maven plugin for LOCC (I it from
CVS). Apparently, it creates an xml file with sizeType="javaLine".
Weird. Who wrote this plugin? (Tim?) Is this due to a simple typo
somewhere?
2) For some reason (probably because I don't understand it fully), Maven
wants to download sensorshell.jar as sensorshell-.jar and I couldn't get
rid of the "-"-".
This provides yet additional motivation for a feature I would like to
provide in the next generation of our build.xml. Currently, each module
can define its own 'install' task in its local.build.xml. This task runs
before the main build.xml creates sensorshell.jar. It turns out that some
sensors/modules want to do some post-processing after the sensorshell.jar
is created (hackyEclipse and hackyInstaller are examples, in that they want
to create a jar file containing the contents of sensorshell.jar).
Currently, to do this the main build.xml has to be hacked to include a task
specific to that sensor/module that runs after sensorshell is created.
To fix this violation of modularity, what we can do is change our
requirements for the contents of the local.build.xml from a single
'install' task to two tasks: 'install-presensorshell' and
'install-postsensorshell'. (OK, the names aren't great, and I am open to
improvements.)
The 'install-presensorshell' task runs at the point in the build that the
current 'install' task runs. So, all of the current modules can simply
change the name of their install task to install-presensorshell to retain
their current behavior.
The 'install-postsensorshell' task can be defined as the no-op task if a
module doesn't need it, but for modules that want a hook into the build
environment after sensorshell has been created, this will do the trick. I
am pretty sure that the hackyInstaller and hackyEclipse-specific code in
the main build.xml can be moved to such a local install-postsensorshell
task.
With respect to your Maven issue, if Maven requires the '-' in sensor
names, then the hackyApp_Maven module can get this behavior by implementing
a install-postsensorshell task that makes a copy of sensorshell.jar in the
download directory called sensorshell-.jar.
3) I noticed that maven v. 1.0.2 depends on ant-1.5.3. I'm not sure if
that will be a problem for the sensors and/or CSDL tools.
I just checked the Maven home page; as of 12-Sep they support Ant 1.6.5.
This was a little harder that I thought it was going to be... I think I
don't really like Maven anymore... :)
I have this attraction/repulsion relationship with Maven 1.x---the idea is
so promising, but the execution seems a little off somehow. (That's
probably how a lot of folks feel about Hackystat!)
but, I suppose its pretty cool
that our existing Ant Sensors can be called via Maven without very much
work. Oh, and I have no idea on how hackyMaven would integrate with
Hackystat; not sure one how to write hackyInstaller code for this because
it isn't really a sensor and doesn't have sensor code.
I plan to hack on this more later on: (1) make a maven jblanket sensor,
(2) think of some way to integrate this into hackystat, (3) more
exploration of maven, (4) take a look at the new version of maven.
The Maven 2.0 release seems worth taking a look at.
Question: Is it possible to use Maven to build www.hackystat.org instead of
hackyDevSite, but not 'infect' our current development environment? In
other words, can regular developers continue to build and run hackystat
just as they do now without any knowledge of Maven (or hackyDevSite), but
Maven would be used to build the www.hackystat.org website (instead of
hackyDevSite)? And would moving from hackyDevSite to Maven be a step
forward or a step backward?
Cheers,
Philip
