What about Maven ?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What about Maven ?

Kraft
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
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Sven Gothel
Administrator
On Wednesday, May 26, 2010 15:00:13 Kraft [via jogamp] wrote:

>
> 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  http://maven.apache.org/ 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.

No - not within the next few month ..

But, a big one, if you contribute, show us the benefits
and actually provide and maintain those maven deployment/repository files, whatever that will be,
then we can talk for sure.

>
> Here are some links about Maven if you want to know more about it :
> -  http://maven.apache.org/what-is-maven.html what is maven ?
> -  http://maven.apache.org/guides/getting-started/index.html Getting started
> !
>
> I hope you will find some interest in Maven.
Whatever .. time is currently the most tight resource, so read above.

~Sven

>
> 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 http://jogamp.762907.n3.nabble.com/subscriptions/Unsubscribe.jtp?code=c2dvdGhlbEBqYXVzb2Z0LmNvbXw3NjI5MDd8MzkxNDI4MzU5
>


--
health & wealth
mailto:[hidden email] ; www  : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
In reply to this post by Kraft
as soon we have a release version we will provide some kind of maven support.
We will have to change the library loading code a bit since i don't think maven cares about the library.path property... but this was on the todo list anyway.

for now just import it into your local repository :)

tanks and best regards,
michael


On 05/26/2010 03:00 PM, Kraft [via jogamp] wrote:
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.

Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Kraft
In reply to this post by Sven Gothel
Thanks for the answers.

> time is currently the most tight resource

I totally understand.

> But, a big one, if you contribute, show us the benefits
> and actually provide and maintain those maven deployment/repository files, whatever that will be,
> then we can talk for sure.

I will try something, if it gives results then i will tell you.

> We will have to change the library loading code a bit since i don't think maven cares about the library.path property...

That is the problem i encountered. Maven seems to propose a solution.
I will give it a shot.

> for now just import it into your local repository :)

Sadly that's what i'm doing right now ;)

A bientôt :)

Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Kraft
Hi !

Maybe this will help other user of jogl to use JARs of the current build 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 :)
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
thank you for the nice tutorial Kraft, worked great.

regards,
michael

On 06/01/2010 02:36 PM, Kraft [via jogamp] wrote:
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.

Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Elijah Menifee
In reply to this post by Kraft
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...
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Kraft
That would be great :D
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
In reply to this post by Elijah Menifee
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://michael-bien.com/
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Sven Gothel
Administrator
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
> > <http://jogamp.762907.n3.nabble.com/template/NodeServlet.jtp?tpl=unsubscribe_by_code&node=762907&code=YmllbmF0b3JAYXJjb3IuZGV8NzYyOTA3fDQxNTEwMDY0OA==>.
> >
> >
>
>


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
I disagree with 1)

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


On 08/25/2010 07:41 PM, Sven Gothel [via jogamp] wrote:
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/
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Sven Gothel
Administrator
On Wednesday, August 25, 2010 20:53:27 Michael Bien [via jogamp] wrote:
>
>   I disagree with 1)
>
> 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.
>

Just tried to outline the objectives, the overall goal,
so that this will not become some unmaintained patch for one of our modules.

~Sven

> -michael
>
>
> On 08/25/2010 07:41 PM, Sven Gothel [via jogamp] wrote:
> > 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 
> > <http://jogamp.762907.n3.nabble.com/What-about-Maven-tp844816p1284007.html?by-user=t>
> > > > To start a new topic under jogamp, email
> > > > [hidden email] </user/SendEmail.jtp?type=node&node=1336595&i=0>
> > > > To unsubscribe from jogamp, click here
> > > > <<Link Removed>>.
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > 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://jogamp.762907.n3.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=762907&code=YmllbmF0b3JAYXJjb3IuZGV8NzYyOTA3fDQxNTEwMDY0OA==>.
> >
> >
>
>


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Kraft
In reply to this post by Elijah Menifee
Hi Elijah !

Are you still working on this task ?
I would be happy to assist you, just let me know :)
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Elijah Menifee
I have been on vacation, and have not had a chance to get back to looking at the JogAmp stuff.  I still plan on altering the build to support the maven build system, so we can setup a repository for other maven projects to import and build from JogAmp dependencies.  As suggested by Michael I have started off with looking into porting the jocl stuff first.

The last thing I remember looking at a couple of weeks ago was the custom ant tasks, and thinking that the ant task that checks for the latest CL api headers, could be a sub-project that provides the latest header, and that the header transformation task could be yet another sub-project or better yet a utility/project that could be configured via templates to do file transformations that would provide modified headers as a maven resource import to use for any glugen process where the input headers do not exactly match the expected input for gluegen.

I probably will not have a chance to look into the details until sometime late this weekend or next week.  I still need to do some research on the different available maven plugins designed for native and JNI to replace some of the gluegen-cpptasks setup stuff.  I remember coming across an article about a maven plugin several months ago that did all the OS specific compiler variables and setup for platform dependent  JNI compile/link tasks but will need to find the details again.

The initial step might be creating a maven pom and restructuring as a maven project that uses the AntRun plugin, and altering from there.  However I am still in the dissecting phase and have slept in the past two weeks while on vacation.  Not yet sure where assistance will be needed, but I will keep it in mind.
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
  Hi Elijah,

On 09/10/2010 01:01 AM, Elijah Menifee [via jogamp] wrote:
> I have been on vacation, and have not had a chance to get back to
> looking at the JogAmp stuff.  I still plan on altering the build to
> support the maven build system, so we can setup a repository for other
> maven projects to import and build from JogAmp dependencies.
nice. Hope you spent your vacation well.

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?

>  As suggested by Michael I have started off with looking into porting
> the jocl stuff first.
>
> The last thing I remember looking at a couple of weeks ago was the
> custom ant tasks, and thinking that the ant task that checks for the
> latest CL api headers, could be a sub-project that provides the latest
> header, and that the header transformation task could be yet another
> sub-project or better yet a utility/project that could be configured
> via templates to do file transformations that would provide modified
> headers as a maven resource import to use for any glugen process where
> the input headers do not exactly match the expected input for gluegen.
>
> I probably will not have a chance to look into the details until
> sometime late this weekend or next week.  I still need to do some
> research on the different available maven plugins designed for native
> and JNI to replace some of the gluegen-cpptasks setup stuff.  I
> remember coming across an article about a maven plugin several months
> ago that did all the OS specific compiler variables and setup for
> platform dependent  JNI compile/link tasks but will need to find the
> details again.
>
> The initial step might be creating a maven pom and restructuring as a
> maven project that uses the AntRun plugin, and altering from there.
>  However I am still in the dissecting phase and have slept in the past
> two weeks while on vacation.  Not yet sure where assistance will be
> needed, but I will keep it in mind.
>

best regards,
michael

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

Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Michael Bien
In reply to this post by Elijah Menifee
  fyi,
http://github.com/sgothel/gluegen/pull/1
someone else already started with gluegen.
-michael

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

Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

utgarda
In reply to this post by Kraft
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.
Reply | Threaded
Open this post in threaded view
|

Re: maven artifacts

Michael Bien
On 09/11/2010 10:49 PM, utgarda [via jogamp] wrote:
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"
great!


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.
all projects depend on gluegen-rt.jar (speak gluegen runtime). gluegen.jar is just build-time infrastructure... not needed at runtime.
cdc means connected device configuration (->low end mobile... lets ignore it for now.)

JOGL is more complicated since it has tons of potential artifacts.
but lets start with the full distribution:
- jogl.all.jar
- newt.all.jar
- nativewindow.all.jar

where:
- jogl.all.jar depends on newt.all.jar + nativewindow.all.jar
- newt.all.jar depends on nativewindow.all.jar (but I am not sure about that, maybe even in the other direction)


   2) Is there some link to the BSD license version used in gluegen officially published on the net?
http://jogamp.org/gluegen/LICENSE.txt
(we should update the license since the Sun copyright does obviously not apply to the code we contributed since the fork happened)



   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.
i suppose we could do that. At least I don't see anything blocking this. But lets ignore cdc for now :)


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

Thank you for your efforts!

michael
-- 
- - - -
http://michael-bien.com
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

Elijah Menifee
In reply to this post by Michael Bien
I agree that providing maven artifacts alone would be much easier and would probably be a good starting point.  I agree this would cover what most people in the community wants.  In fact I myself could probably get by with just the artifacts being available.

Adding an ant script to deploy the latest pull/build artifacts to your local repository for depedent projects when working on the bleeding edge as a snapshot would probably suffice.

I still think that building with maven long term might be desireable, but a lower priority.  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.  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.  Of course all the work to make the existing project maven compatable may not be worth the effort for the additional benefits.

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?
Reply | Threaded
Open this post in threaded view
|

Re: What about Maven ?

utgarda
In reply to this post by Kraft
Michael Bien wrote
gluegen.jar is just build-time infrastructure... not needed at runtime.
So, do you think I should even deploy gluegen.jar? Would anyone want it as dependency, or it's just for the ant build?

Now deploying gluegen with valid POMs, so, when the next version arrives, it will be able to go to sonatype's staging repo or even further to maven central. I didn't dig commit histories really hard, so just put in the 2 latest most active people as developers. Maybe you want to put there some of the people who did all the coding before you, as developers or committers, to give them some credit: http://github.com/utgarda/gluegen/commit/d7eb33b02604133f2593e468393f7d56c4c50f8f#diff-2
Maybe the file requires some other editing too, so please have a look.

Sorry guys, I put your emails openly, hope those files never get indexed by nasty spammers.

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.
Yep, IntelliJ Idea does that allright.
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.
Yep, that's cool. But with properly deployed pre-built artifacts their dependencies are recoursively resolved too, so the effect is pretty much the same, and in a way even better - you have the benefit of pre-built stuff.
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.
Totally. Of course, we don't know until we try it, but I'm scared even to think of doing what it takes - seems such a load of work to me.
12