What about Maven ?

Hi guys !

I'm Kraft from France ...
I'm a user of jogl, joal and of course gluegen. ^^
I'm happy to see that jo*l are not dead.
I think those projects are very important for the java community.
So congratulations for all your work.

I'm developping a bunch of games that use jogl and joal.
I recently switched my project management to Maven.
It is a great help in managment of dependencies, versions, sources, releases, deployment and repository.

So my question is :
Do you plan on providing a Maven repository for the jars ? (or use the central maven repository)
It would be a great help for you to manage the whole JogAmp project and for developers that uses JogAmp in there projects.

Here are some links about Maven if you want to know more about it :
- what is maven ?
- Getting started !

I hope you will find some interest in Maven.

Regards,

Kraft

---

View message @ http://jogamp.762907.n3.nabble.com/What-about-Maven-tp844816p844816.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

		<repository>
			<id>blackpad-nexus</id>
			<name>Blackpad Nexus</name>
			<layout>default</layout>
			<url>http://www.blackpad.fr/nexus/content/groups/public</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>

		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>gluegen-rt</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>gluegen-rt-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>nativewindow.all</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>nativewindow-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>jogl.all</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>jogl-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>

	<build>
		<plugins>
			
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <id>unpack</id>
            <phase>compile</phase>
            <goals>
              <goal>unpack</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>gluegen-rt-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>jogl-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>nativewindow-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
              </artifactItems>
            </configuration>
          </execution>
        </executions>
      </plugin>
      
  		</plugins>
  	</build>

Hi !

Maybe this will help other user of jogl to use current JARs into their maven projects.
After some days trying many solutions, here is what i found :

My goal :
My goal was to make use of
- gluegen-rt.jar
- gluegen-rt-natives-linux-i586.jar
- jogl.all.jar
- jogl.all-natives-linux-i586.jar
- nativewindow.all.jar
- nativewindow-natives-linux-i586.jar
in Ubuntu+Eclipse+Maven+Nexus.

I wanted to configure all stuff about dependencies to jogl into the pom.xml of my project.
Then other members of my dev team just have to checkout the project (including the pom.xml) from the svn repository to have a complete configured project.

My solution :

* in Nexus, i uploaded the artifact listed above in the 3rd party repository.
I set the groupid to "jogamp" and the articatid to the name of the jar (without .jar)

* In Eclipse, in the pom.xml of the project,
i declared the repository like this (you can utilize my nexus repository if you want but at your own risks ^^)

		<repository>
			<id>blackpad-nexus</id>
			<name>Blackpad Nexus</name>
			<layout>default</layout>
			<url>http://www.blackpad.fr/nexus/content/groups/public</url>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
  

I declared the dependencies to jogl like this :

		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>gluegen-rt</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>gluegen-rt-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>nativewindow.all</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>nativewindow-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>jogl.all</artifactId>
			<version>0.0.1</version>
		</dependency>
		<dependency>
			<groupId>jogamp</groupId>
			<artifactId>jogl-natives-linux-i586</artifactId>
			<version>0.0.1</version>
		</dependency>
  

Then 2 steps to make maven add the .so (for linux but you can adapt to windows or macos) into the java.library.path.

- First, i configured the maven-dependency-plugin to unpack the natives jars into /target/lib after downloading them

	<build>
		<plugins>
			
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <id>unpack</id>
            <phase>compile</phase>
            <goals>
              <goal>unpack</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>gluegen-rt-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>jogl-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
                <artifactItem>
                  <groupId>jogamp</groupId>
                  <artifactId>nativewindow-natives-linux-i586</artifactId>
                  <version>0.0.1</version>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  <outputDirectory>${project.build.directory}/lib</outputDirectory>
                </artifactItem>
              </artifactItems>
            </configuration>
          </execution>
        </executions>
      </plugin>
      
  		</plugins>
  	</build>
  

- Second, to let java found the natives libs, when i run the project using the "Run As" menu, i made a new Run Configuration and added -Djava.library.path=/target/lib as argument.


That's it !

With some adjustments , this solution let you use jogl in a maven project on any platform.
Hope i'm understandable, anyway i'm open to questions :)

---

View message @ http://jogamp.762907.n3.nabble.com/What-about-Maven-tp844816p861275.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

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://michael-bien.com/

On Monday, August 23, 2010 14:09:54 Michael Bien [via jogamp] wrote:

>
>   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.

However .. whatever somebody will do with a Maven support of JogAmp modules,
please consider the following - without them it would make no sense at all:

1 - for all JogAmp modules
2 - being merged 'back' into the JogAmp master
3 - being build on JogAmp and distributed
4 - being maintained

so .. we won't do 1 and 4,
and you also have to help us with 2 and 3 - of course.

But if it's beneficial to your work, just do so,
then we can collaborate on 2 and 3, but please be there for point 4 :)

If this will be only an initial effort from your side
then we can forget about all of this, since then it's just dead stuff.

~Sven

>
> 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
> > <<Link Removed>>.
> >
> >
>
>

--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

---

View message @ http://jogamp.762907.n3.nabble.com/What-about-Maven-tp844816p1336595.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

-- 
http://michael-bien.com/

Michael Bien wrote

Just want to note that this are actually two distinct goals:
1. provide maven artefacts
2. build with maven

Michael Bien wrote

you would have to start somewhere. Having a temporary mix of ant + maven is completely fine. As long nobody starts at the root of the tree.
JOAL/JOCL are leaves.

Michael Bien wrote:

Just want to note that this are actually two distinct goals:
1. provide maven artefacts
2. build with maven

Michael Bien wrote:

you would have to start somewhere. Having a temporary mix of ant + maven is completely fine. As long nobody starts at the root of the tree.
JOAL/JOCL are leaves.

Yep, just put GlueGen 1.0-beta07-SNAPSHOT to oss.sonatype.org : https://oss.sonatype.org/index.html#nexus-search;quick~gluegen
Gonna update the snapshot on commits to master and deploy further tagged versions. Currently there are natives present only for linux-amd64, cause I didn't do the crossbuild yet. But you can use the new buildfile to quickly install to the local repo everything you build on your system with target "maven.install"

And yes, that's just calling maven from ant to install/deploy artifacts. Didn't touch the build itself - currently it's too much of a task for me to rewrite gluegen build from ant to maven, and no need to do it too, cause it works fine as it is. So just added maven calls to deploy created files at the bottom of build.xml

Guess I'll do it the same way for the rest of jogamp.org, but let me finish it with GlueGen first. To do it properly I need to fulfill requirements of sonatype's forge (and, for that matter, those of maven central repo ), and compose some valid and descriptive pom files. To help me do this, you can answer these questions:

   1) What are the artifacts dependencies - what depends on what? natives on gluegen.jar, or the contrary, or neither. Sorry, I don't use gluegen directly, so I don't understand that. And what does -rt and -cdc mean? Just give me a link please, I'll read and try to understand that myself.

   2) Is there some link to the BSD license version used in gluegen officially published on the net?

   3) As part of future better maven compatibility, can you guys rename your artifacts so they have the os-and-platform part of their names at the end? I mean, name them gluegen-rt-natives-cdc-linux-amd64.jar, not gluegen-rt-natives-linux-amd64-cdc.jar That would gradually simplify maven deployment, cause maven puts platform classifier at the end of filenames, and I can't change that.

Think I already know all the other info I need for now.

-- 
- - - -
http://michael-bien.com

Michael Bien wrote

Just want to note that this are actually two distinct goals:
1. provide maven artefacts
2. build with maven

1. should be relatively easy, 2 is lots of work... really. 1. is
probably also the feature the community wants (just add project x as
dependency). I am relatively new to maven, maybe i am oversimplifying
things here, but why not start with the simple task first?

Michael Bien wrote

gluegen.jar is just build-time infrastructure... not needed at runtime.

Elijah Menifee wrote

The upsides of using a maven project pom is it provides a cross-ide project that can be used by Eclipse, Netbeans, and I believe IntelliJ.

Elijah Menifee wrote

Also instead of relying on published artifact versions for a specific platform, a maven project could depenend on another maven source/snapshot project, and descend and build the dependancy first for the local platform.

Elijah Menifee wrote

Of course all the work to make the existing project maven compatable may not be worth the effort for the additional benefits.