>
>   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...
> >
> > ------------------------------------------------------------------------
> > View message @
> > http://jogamp.762907.n3.nabble.com/What-about-Maven-tp844816p1284007.html
> > To start a new topic under jogamp, email
> > [hidden email]
> > To unsubscribe from jogamp, click here
> > <http://jogamp.762907.n3.nabble.com/template/NodeServlet.jtp?tpl=unsubscribe_by_code&node=762907&code=YmllbmF0b3JAYXJjb3IuZGV8NzYyOTA3fDQxNTEwMDY0OA==>.
> >
> >
>
>