Switching to Maven

brandon-enochs · 05-07-2009, 09:59 PM

I propose that the World Wind team switch to Apache Maven. Apache Maven is build system intended to replace adhoc ant build such as the one's currently being used by the World Wind SDK. Maven provides an easy to use module system, standard direct layout, and a standard way of expressing version numbers and dependencies. It has really improved our work flow on Flying Squirrel at the Naval Research Laboratory. I encourage the World Wind developers to check out http://maven.apache.org and http://repo.exist.com/dist/maestro/1...sWithMaven.pdf. If need be, I can write your project object models for you.

Thanks,
Brandon

TomServo · 05-07-2009, 10:11 PM

I'll pass it along to them, but no guarantees though.

TomServo · 05-07-2009, 10:15 PM

Now I recognize the name after seeing the Flying Squirrel. Put a case for it forward and may be able to convince them.

zolyfarkas · 05-14-2009, 12:28 AM

dependency management is most important(no more jar hell):

http://maven.apache.org/guides/intro...mechanism.html

Will make building and running worldwind significantly easier by command line and all major IDE's support maven, will also allow to easily modularize the worldwind project ...

I am already using maven to build wwj, still have some work to do related to platform specific dependencies...

I am more than happy to contribute my m2 work

ddriggs · 07-10-2009, 05:12 PM

Please keep in mind that not all developers have an internet connection! The lowest level of Jar Hell is transferring all your code over to a stand-alone network and realizing you don't have a jar that maven fetched unbeknownst to you.

buzz3791 · 04-21-2010, 07:56 PM

Using Maven definitely makes it easier to incorporate open source projects like World Wind for Java into other projects.

Maven makes team development easier, because everyone is synchronized on the same JAR versions.

Maven support does require some effort. But the effort gets reused by all project clients. Somebody has to deal with dependency problems once and everyone gets to benefit.

A specific example where Maven would make versions clearer. We're incorporating both the server and the SDK into our application. The server releases (latest Jan 2010) are currently lagging the SDK releases (latest April 2010). Right now, I can't get the server code to compile because of this error

Code:

C:\rw_apps\dev\Maxview\MVServer\WorldWindMapServer\src\main\java\gov\nasa\worldwind\servers\wms\generators\BILGenerator.java:[40,12] cannot find symbol
symbol  : class DataDescriptor
location: class gov.nasa.worldwind.servers.wms.generators.BILGenerator

The root cause appears to be that I'm compiling the server against the wrong worldwind.jar SDK version. But I can't easily determine the worldwind.jar SDK version included in the server release. We're building worldwind.jar SDK from source. So I'm having to compile the server against various SDK versions until I find a match.

Brian

dmcmanam · 05-13-2010, 05:28 PM

The complaint about worldwind.jar lacking a version number can be addressed in the ant build.

Switching to Maven is a great idea for most projects, I particularly like the ease of generating a website and documentation. For WWJ, the big issue is how to deal with JOGL's JNI files, Maven2 is currently lousy at dealing with native libraries. You'll notice that most projects that have native files build with ant. If you think this isn't a Maven2 shortcoming I suggest submitting your own WWJ pom.xml, I would write it if I knew how.

nmschulte · 06-22-2011, 11:53 PM

Has anything come of this? Using Maven to package WWJ, I mean.

The last post in the thread was about issues with JOGL and its native components. I took the approach that the jogamp.org community took with JOGL 2.0; separate jars for the natives. This allows one to use the maven profiles to select which native to use (for deployment), while allowing worldwind to depend upon only the runtime (of both JOGL and GlueGen). I haven't tackled GDAL yet, mainly because of it's rather invasive inclusion in the WWJ code (lib-externals directory and platform detection...). I simply mvn install:install-file'd it to my local repository and hook it that way.

If WWJ was to switch to JOGL 2.0, one wouldn't need to bother with packaging JOGL/GlueGen 1.1.1 with separate native jars. However, if switching to JOGL 2.0 just isn't a possibility (I don't know why not) and packaging of JOGL/GlueGen 1.1.1 was an issue, I can share my packaged jars in hopes of getting things off the ground.

petebrew · 06-27-2011, 05:04 PM

The issue of packaging the native JOGL/Gluegen libraries seems to have been solved by this guy: http://devblog.iscpif.fr/?p=76

WWJ is a huge project with a lot of dependencies that would hugely benefit from moving over to Maven. So a definite +1 from me.

heidtmare · 06-28-2011, 02:39 PM

just throw the worldwind jar into your artifactory and package the natives into your own application. this has worked out very well for me on multiple projects.

05-07-2009, 09:59 PM	#1
brandon-enochs Junior Member Join Date: May 2009 Posts: 1	Switching to Maven I propose that the World Wind team switch to Apache Maven. Apache Maven is build system intended to replace adhoc ant build such as the one's currently being used by the World Wind SDK. Maven provides an easy to use module system, standard direct layout, and a standard way of expressing version numbers and dependencies. It has really improved our work flow on Flying Squirrel at the Naval Research Laboratory. I encourage the World Wind developers to check out http://maven.apache.org and http://repo.exist.com/dist/maestro/1...sWithMaven.pdf. If need be, I can write your project object models for you. Thanks, Brandon

05-07-2009, 10:11 PM	#2
TomServo God. Root. What is difference? Join Date: Sep 2004 Location: Eastern Pennsylvania Posts: 2,847	I'll pass it along to them, but no guarantees though. __________________ Earth is Square blog PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this forum post, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.

05-07-2009, 10:15 PM	#3
TomServo God. Root. What is difference? Join Date: Sep 2004 Location: Eastern Pennsylvania Posts: 2,847	Now I recognize the name after seeing the Flying Squirrel. Put a case for it forward and may be able to convince them. __________________ Earth is Square blog PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this forum post, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe.

05-14-2009, 12:28 AM	#4
zolyfarkas Junior Member Join Date: Apr 2009 Posts: 4	+1 dependency management is most important(no more jar hell): http://maven.apache.org/guides/intro...mechanism.html Will make building and running worldwind significantly easier by command line and all major IDE's support maven, will also allow to easily modularize the worldwind project ... I am already using maven to build wwj, still have some work to do related to platform specific dependencies... I am more than happy to contribute my m2 work

04-21-2010, 07:56 PM	#6
buzz3791 Junior Member Join Date: Apr 2010 Posts: 12	+1 Using Maven definitely makes it easier to incorporate open source projects like World Wind for Java into other projects. Maven makes team development easier, because everyone is synchronized on the same JAR versions. Maven support does require some effort. But the effort gets reused by all project clients. Somebody has to deal with dependency problems once and everyone gets to benefit. A specific example where Maven would make versions clearer. We're incorporating both the server and the SDK into our application. The server releases (latest Jan 2010) are currently lagging the SDK releases (latest April 2010). Right now, I can't get the server code to compile because of this error Code: C:\rw_apps\dev\Maxview\MVServer\WorldWindMapServer\src\main\java\gov\nasa\worldwind\servers\wms\generators\BILGenerator.java:[40,12] cannot find symbol symbol : class DataDescriptor location: class gov.nasa.worldwind.servers.wms.generators.BILGenerator The root cause appears to be that I'm compiling the server against the wrong worldwind.jar SDK version. But I can't easily determine the worldwind.jar SDK version included in the server release. We're building worldwind.jar SDK from source. So I'm having to compile the server against various SDK versions until I find a match. Brian Last edited by buzz3791; 08-20-2010 at 02:17 PM. Reason: provide example where maven would help world wind users

07-10-2009, 05:12 PM	#5
ddriggs Newbie Join Date: Apr 2009 Location: Denver Posts: 11	Please keep in mind that not all developers have an internet connection! The lowest level of Jar Hell is transferring all your code over to a stand-alone network and realizing you don't have a jar that maven fetched unbeknownst to you.

05-13-2010, 05:28 PM	#7
dmcmanam Junior Member Join Date: May 2010 Posts: 5	Maven2 switch unlikely The complaint about worldwind.jar lacking a version number can be addressed in the ant build. Switching to Maven is a great idea for most projects, I particularly like the ease of generating a website and documentation. For WWJ, the big issue is how to deal with JOGL's JNI files, Maven2 is currently lousy at dealing with native libraries. You'll notice that most projects that have native files build with ant. If you think this isn't a Maven2 shortcoming I suggest submitting your own WWJ pom.xml, I would write it if I knew how.

06-22-2011, 11:53 PM	#8
nmschulte Junior Member Join Date: Jun 2011 Posts: 1	Has anything come of this? Using Maven to package WWJ, I mean. The last post in the thread was about issues with JOGL and its native components. I took the approach that the jogamp.org community took with JOGL 2.0; separate jars for the natives. This allows one to use the maven profiles to select which native to use (for deployment), while allowing worldwind to depend upon only the runtime (of both JOGL and GlueGen). I haven't tackled GDAL yet, mainly because of it's rather invasive inclusion in the WWJ code (lib-externals directory and platform detection...). I simply mvn install:install-file'd it to my local repository and hook it that way. If WWJ was to switch to JOGL 2.0, one wouldn't need to bother with packaging JOGL/GlueGen 1.1.1 with separate native jars. However, if switching to JOGL 2.0 just isn't a possibility (I don't know why not) and packaging of JOGL/GlueGen 1.1.1 was an issue, I can share my packaged jars in hopes of getting things off the ground.

06-27-2011, 05:04 PM	#9
petebrew Junior Member Join Date: Aug 2010 Posts: 4	Include native libs The issue of packaging the native JOGL/Gluegen libraries seems to have been solved by this guy: http://devblog.iscpif.fr/?p=76 WWJ is a huge project with a lot of dependencies that would hugely benefit from moving over to Maven. So a definite +1 from me.