[kepler-dev] Maven and Ptolemy
tristan.king at jcu.edu.au
Sun Aug 17 21:36:00 PDT 2008
WARNING! DO NOT run "mvn clean" with the pom.xml from the ptII svn. mvn
clean is dumb and just removes the outputDirectory folder, which in this
case happens to be the main directory, which happens to include my .git
directory. Hopefully I can configure git to link to the svn again without
having the clone the whole thing again :(.
This makes it very tough to use maven while keeping all the development
environment behaviour to the current ptII method. If everything is jared up
together (including src code), but stored in a maven directory hierarchy for
development would this be suitable?
There are a lot of different perspectives to view this decision from. I
prefer to have my source code separated from my project files and compiled
code. but my perspective is just that of a programmer, not an academic.
I'm working on getting your pom.xml to compile, but i'm having a bit of
trouble getting the javacc plugins to behave. will send a patch when i get
it all going.
On Mon, Aug 18, 2008 at 10:00 AM, Tristan King <tristan.king at jcu.edu.au>wrote:
> Ah, I've been waiting on some discussion about this. Comments below.
> 2008/8/16 Christopher Brooks <cxh at eecs.berkeley.edu>
>> Ok, I was able to build using Maven. I started from Tristan's notes
>> and created $PTII/doc/coding/maven.htm, which I've attached.
>> There are a few issues to contend with:
>> * Why does "make maven" copy the .java files? This means
>> that we have yet another copy of the code and that changes to the
>> master .java files are not propagated? This was a problem with ant
>> in Kepler, we should see about avoiding it.
>> The tool should fit our current directory structure, we should
>> not need to change our directory structure to fit the tool.
> "make maven" copies the files because I wanted to play with it in a
> separate directory, leaving the original ptII in tact so that "svn up" still
> works. this behaviour is easily changed by modifying the COPY_OP variable.
> something like "svn mv" would be what you would use if you were going to
> make this change. i was originally playing with "git mv" which
> handled propagation.
> I think David has said enough about the directory structure, so I wont
> repeat what he said.
>> * Having resources separate from the sources makes no sense for a
>> componetized architecture. Every time a package is moved, the
>> resources need to be moved. The resources should be in the
>> jar that uses the resources.
> The resources get put into the jar at jar build time, so if you're working
> with just the jars this isn't an issue. I'll update ptII-maven to work with
> the latest ptII revision today so you can hopefully get things going.
>> I know that webstart has a hard time finding resources that are not
>> in the jar file that contains the .class file that references the
>> Maven seems to want resources in a separate directory. David and I
>> have exchanged some email on this, and I'm not yet convinced that
>> having resources away from the code makes any sense.
>> The Maven docs say
>> "Having a common directory layout would allow for users familiar with
>> one Maven project to immediately feel at home in another Maven
>> project. The advantages are analogous to adopting a site-wide
>> So, it sounds like this is a Maven standard. The great thing about
>> standards is that there are so many to choose from. :-)
>> * The $PTII/pom.xml file lists dev.archer.edu.au
>> as the repository, this should probably be changed to the Ptolemy
>> website. Should this be a configuration time choice?
> The references to dev.archer.edu.au referers to our maven repository here
> at JCU. I have deployed all the non standard jar files that ships with ptII
> here which means you don't have to do the manual add step (step 6). This
> could be changed to the ptolemy site if you wanted to set up a maven
> repository there.
>> * There is this entire issue of how to generate the pom.xml file, what
>> to do not all of the optional components are available. Right now,
>> it is fairly easy to build a stripped down Ptolemy that does not
>> include packages like Java 3D. Do we still need a configure step?
> For me, just moving ptII into maven isn't good enough. IMO, optional
> components should be separated out of the core of ptolemy and put into their
> own projects. however, to get this working would require some form of plugin
> architecture. I think the configure step (in it's current incarnation)
> should not be necessary.
>> * Can we automatically generate run-vergil.sh? That
>> file has version numbers hard coded in. Can we have a Maven step
>> that generates this file? We could also generate it via configure.
> The classpath is generated from a maven target, it wouldn't be hard to auto
> generate. I use "mvn exec:exec" which doesn't need the run-vergil.sh file at
> all. The shell script is just an artifact from before i set up the exec:exec
>> * What about the Eclipse jar files for backtracking? There is an
>> eclipse maven plugin, but I could not get the dependencies to work.
> Someone more eclipse savvy may have to look into this. I just use the
> command line tools.
>> * maven is very network-centric, to build Ptolemy with Maven, you _must_
>> have a network connection because it downloads various modules the
>> first time it runs. We would have to do quite a bit of monkeying
>> around for Maven to build for the first time for a user who did not
>> have a fast network connection. This caused me problems when I was
>> connected via a modem and had not yet build using Maven. This is not
>> a huge problem, just something of which to be aware.
> The extra maven jars that need to be downloaded in the initial bootstrap is
> ~11MB (no testing has been done to figure that out, i just "du -sh
> ~/.m2/repository/org/apache/maven/"). ptII is well over 200MB. I would think
> that someone starting dev would be grabbing everything, so the extra, even
> tho annoying as it would be over dial-up, wouldn't be a lot more in the
> grand scheme of things.
> Also, who are you referring to when you talk about "users" here ? If you
> mean, someone doing development, than this stands. If you're talking about
> people simply using ptII, I think there should be a separate deployment
> strategy. IMO users should not have to use development tools, or even have
> them installed.
> Another idea i've thought about: bootstraping development of actors and
> other components. This could be done in two ways, 1. building a maven
> archetype, or 2. building an eclipse template plugin. I've looked
> very briefly into each, and both seem quite do able, but a lot more time
> needs to be put into it than I have available. Both options could (in the
> example of an actor) give a pom.xml with the required dependencies and a
> java file with the basic actor structure, documenting what each function
> does and how to add ports and anything else. This I think would be the first
> step towards a ptII/kepler SDK.
> I still want to push the actor IO idea as well, and would like to hear any
> thoughts and comments on the work i've already done, and if anyone has any
> resources free to work more on this I can help get them started. But i'm not
> too keen to put any more time into something that no one is interested in.
> (i've done a quick powerpoint that can be viewed here:
> Tristan King
> Research Officer,
> eResearch Centre
> James Cook University, Townsville Qld 4811
> Phone: +61747816902
> E-mail: tristan.king at jcu.edu.au www: http://eresearch.jcu.edu.au
James Cook University, Townsville Qld 4811
E-mail: tristan.king at jcu.edu.au www: http://eresearch.jcu.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kepler-dev