Re: What about Maven ?
Posted by
Michael Bien on
Aug 23, 2010; 12:09pm
URL: https://forum.jogamp.org/What-about-Maven-tp844816p1289502.html
this is not a fun task to spend your freetime on :). Using maven for
our build wouldn't have many benefits, we would only loose some
flexibility. The jogl build does not contain much what could be
simplified via the convention over configuration paradigm. In fact
the scripts are highly custom. Its more than just compiling stuff.
If you would like to still experiment with it i recommend to start
with JOCL. JOCL is a leaf of the dependency tree (depends on
gluegen-rt and jogl) and has only a tiny build script (~330 lines).
To keep things simple you could just like Kraft did import jogl and
gluegen-rt in your local repository and add it as dependencies. But
even the JOCL build will not work without a way of being able to
script parts of it...
jocl has a build-time dependency to gluegen and a compiletime
dependency to jogl and gluegen-rt.
best regards,
michael
On 08/23/2010 06:08 AM, emenifee [via jogamp] wrote:
I agree Time is a tight resource....
I was looking at accelerated graphics frameworks for a Java based
game I was planning on creating, and decided to learn maven for my
managing my project. I was disappointed to find that the current
versions of jogl and/or java3d were not in maven, only old
versions...
So now I have decided that my spare time could best be spent
converting jogl to build under maven, so that eventually it can be
maintained / built / referenced by other maven projects. Since at
the lowest level everything seems to depend on gluegen I have
forked that project, with the intent of branching to creating a
pom file, and rearranging the source and dependencies to match a
standard maven project.
Hopefully I can make this work...and hopefully I can then follow
up by making jogl into a maven project that depends on the gluegen
maven repository. At this point i am hip deep in learning maven
and git along with how everything in gluegen builds and fits
together.
As far as plans for the branch I understand that git properly
handles symlinks (on systems that support them) so I was going to
build a new directory structure that symlinked back to the normal
repository build / layout files so that upstream changes would
easily merge, and once I got it working with symlinks and
accepted, hope to re-factor the structure up a level to make it
the default build routine by actually replacing symlinks with
original files at new locations...( that step might be a pain for
other developers...not sure how git handles refactoring / code
location changes during a merge )
In addition to the article about unpacking and moving libs around
at http://buildanddeploy.com/node/14,
I came across another article about a maven plugin for JNI stuff
that puts the lib files under the jar's META-INF directory with a
special library loader class that would pull the lib as a resouce
file, save to a temporary location, then use System.load("path").
I think this is similar to what JavaWS does with JNLP's that
reference custom JNI code...
So assuming I have not bitten off more than I can chew, and you
are patient enough Kraft, you may eventually get an up-to date
maven build for jogl...
--
http://michael-bien.com/