[Source] problem with jgeom build, java3d dependency

Don Brutzman brutzman at nps.edu
Sat Nov 30 08:25:06 PST 2013 

On 11/27/2013 5:45 AM, Vincent Marchetti wrote:
> Don,
> 
> I gather from this that you've solved one problem and thus found another -- which I may have solved, see below.
> 
> The problem you found was that the more recently submitted source
> file src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java
> depends at compile-time on the package javax.media.j3d ('Java3d')
> which either wasn't on your system or wasn't in the search path of
> your development environment. You solved the problem by installing
> this package and/or setting your search paths to find it. You raised
> the possibility of distributing this package with jgeom.

Concise and correct summary, thanks Vince.
 
> I'm not sure if distributing javax.media.j3d package with jgeom is a
> good idea (even though we partially do this by including vecmath.jar
> in our distribution). I may have to ponder this over some pumpkin
> pie, or at least try to find out what the Best Practices are thought
> to be for this. I thought the javax.* packages were supposed to be
> standard extensions, preinstalled or maintained by the JRE; and I
> wonder what other incompatibilities will be introduced if we start
> substituting our own updates to Java3d.

> On my own system (the venerable Mac OS X 10.6.8, running Java 1.6) I didn't have this problem -- I built everything from command line with 'ant', and it found the system-installed Java3d package without a problem.

hmmm, venerable!  more good information:

> On 11/27/2013 8:07 AM, Terry Norbraten wrote:
> Vince,
>> 
>> You’ll be interested to know that if/when you ever upgrade your Mac OS X to 10.8 (Mavericks), J3D is no longer distributed beginning with that O/S version.

Based on this feedback, I think it is OK for us to add java3d to the lib support so that someone can build jgeom out of the box.  This can also ensure that jgeom can compile/run using the correct version.

This is an acceptable practice for many projects.  We typically include lib jars in most of our projects so that separate changes in an independent jar can occur without breaking the build - jar upgrades can be performed more deliberately, when ready, and all relevant changes checked in at one time.  If not a 

If we eventually eliminate the dependencies of these example applications on java3d, then the lib jars can be removed.

If this is not agreeable, or only partially agreeable, then our alternative would be to add some build tasks that accomplished the installation of the jars in the local lib directory.

I'll hold off checking in until you two are ready to test that we didn't break any Mac configurations by adding them.  I doubt we will see any hiccups -- ant just would preferentially build and run jgeom using these jars rather than any separate system installations.

Please let me know what you think.

> I skipped immediately to the second problem you found, that the new source src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java also depends for compilation on the package net.jgeom.j3d.objects . I found this in another archive Sam Gerber sent us called 'jgeom extras'. I have entered this into the archive, and its jgeom dependencies, into the jgeom repository.

Wow you checked in a lot:

A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\MeshEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\BasicMeshEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\NurbsCurveEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\SDSurfaceEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\BasicNurbsCurveEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\NurbsSurfaceEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\BasicNurbsSurfaceEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\evaluators\BasicSDSEvaluator.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\objects
A    C:\java\jgeom\src\java\net\jgeom\j3d\objects\NurbsCurveShape.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\objects\SubdivisionShape.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\objects\RevolvedNurbsShape.java
A    C:\java\jgeom\src\java\net\jgeom\j3d\objects\NurbsSurfaceShape.java
A    C:\java\jgeom\src\java\net\jgeom\sds
A    C:\java\jgeom\src\java\net\jgeom\sds\SubdivisionScheme.java
A    C:\java\jgeom\src\java\net\jgeom\sds\SubdividableSurface.java
A    C:\java\jgeom\src\java\net\jgeom\sds\SubdivisionSurface.java
A    C:\java\jgeom\src\java\net\jgeom\sds\ArbitraryCatmullClark.java
A    C:\java\jgeom\src\java\net\jgeom\mesh
A    C:\java\jgeom\src\java\net\jgeom\mesh\DefaultEdgeFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\TriMeshBuilder.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\MeshBuilder.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\Edge.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\FaceFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\SDSVertex.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\BoolopFaceFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\LocatedFaceFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\CutLine.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\BoolopMath.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\Polygon.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\BoolopFace.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\LocatedFace.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\BooleanOperator.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\boolop\TriangleSplitter.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\DefaultFaceFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\EdgeFactory.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\Mesh.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\Face.java
A    C:\java\jgeom\src\java\net\jgeom\mesh\SDSEdge.java
Updated to revision 21.

> So my status report is that the svn.code.sf.net/p/jgeom/code repository at rev 21 builds using my system-installed Java3d. I have not been able to actually run the ArbitraryNURBSGeometry applet.
> 
> Vince

Running 'build all' went cleanly for me too.  The javadoc task reported five warnings - fixed.

Tried to check back in but got a subversion error - surprising.  perhaps sourceforge checkins are locked for some reason?  i am able to login via http... will try again later.

E175013: Commit failed (details follow):
E175013: POST of '/p/jgeom/code/!svn/me': 403 Forbidden (http://svn.code.sf.net)

Finally, still not able to run or launch any kind of an example...  that would be good to figure out next.

> On Nov 24, 2013, at 9:06 PM, Don Brutzman wrote:
> 
>> [cc: source at web3d.org mailing list which would seem to have some overlap with jgeom - does that seem OK?  it is the 'source' list, after all... and there are multiple overlaps of interest, especially since jgeom is used by Xj3D.  or perhaps there is a better place for jgeom discussion?]
>>
>> Hi Vince.  There is a problem with the jgeom build that has been lingering for awhile.  Error log excerpt:
>>
>> 	https://savage.nps.edu/jenkins/job/jgeom/
>> 	https://savage.nps.edu/jenkins/job/jgeom/109/console
>>
>> Looks like ArbitraryNURBSGeometry.java failing, it is looking for java3d.  This file was checked in some time ago as an example use of jgeom.
>>
>>> Started by timer
>>> Building in workspace /var/lib/jenkins/jobs/jgeom/workspace
>>> Updating http://svn.code.sf.net/p/jgeom/code/trunk at revision '2013-11-24T07:08:17.007 -0800'
>>> At revision 20
>>> no change for http://svn.code.sf.net/p/jgeom/code/trunk since the previous build
>>> [workspace] $ /usr/java/apache-ant-1.8.2/bin/ant all
>>> Buildfile: /var/lib/jenkins/jobs/jgeom/workspace/build.xml
>>>
>>> init:
>>>
>>> compile:
>>>    [javac] Compiling 59 source files to /var/lib/jenkins/jobs/jgeom/workspace/build
>>>    [javac] /var/lib/jenkins/jobs/jgeom/workspace/src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java:26: error: package javax.media.j3d does not exist
>>>    [javac] import javax.media.j3d.Alpha;
>>>    [javac]                       ^
>>>    [javac] /var/lib/jenkins/jobs/jgeom/workspace/src/java/net/jgeom/j3d/examples/ArbitraryNURBSGeometry.java:27: error: package javax.media.j3d does not exist
>>>    [javac] import javax.media.j3d.AmbientLight;
>>>    [javac]                       ^
>> etc. etc.
>>
>> Not 100% sure, but it looks like the latest java3d (built back in the days of Sun Microsystems) is at
>> http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138252.html
>>
>> Latest version found there is java3d 1.5.2 which README says requires JDK 1.5.0 or later
>>
>> /cygdrive/c/Program Files (x86)/Java/Java3D/1.5.2/lib/ext
>> $ ls -al
>> -rwx------+ 1 SYSTEM SYSTEM 2957997 Jun 30  2008 j3dcore.jar
>> -rwx------+ 1 SYSTEM SYSTEM 1704635 Jun 30  2008 j3dutils.jar
>> -rwx------+ 1 SYSTEM SYSTEM  318956 Jun 30  2008 vecmath.jar
>>
>> Inspecting this downloaded vecmath.jar shows
>>>
>>> Extension-Name: javax.vecmath
>>> Implementation-Version: 1.5.2
>>
>> We already have vecmath.jar version 1.5.1 in the jgeom/lib directory:
>>> Extension-Name: javax.vecmath
>>> Implementation-Version: 1.5.1
>>
>> So upgrading that shouldn't be a problem... Wondering if we should place all three of these later java3d jars in the jgeom/lib directory?  Seems safe to do.
>>
>> So I tested that.  Adding them on my local copy of jgeom (and updating the netbeans project lib references) greatly cleans up the errors in this class, leaving only:
>>
>>> Compiling 59 source files to C:\java\jgeom\build
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:42: error: package net.jgeom.j3d.objects does not exist
>>> import net.jgeom.j3d.objects.NurbsSurfaceShape;
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:154: error: cannot find symbol
>>>        NurbsSurfaceShape nss = new NurbsSurfaceShape(ns);
>>>  symbol:   class NurbsSurfaceShape
>>>  location: class ArbitraryNURBSGeometry
>>> C:\java\jgeom\src\java\net\jgeom\j3d\examples\ArbitraryNURBSGeometry.java:154: error: cannot find symbol
>>>        NurbsSurfaceShape nss = new NurbsSurfaceShape(ns);
>>>  symbol:   class NurbsSurfaceShape
>>>  location: class ArbitraryNURBSGeometry
>>
>> So it would seem that the jgeom class library evolved since this earlier example was written.
>>
>> Anyway, let me know if you agree that we should check in this version of java3d to the jgeom libs, and we can then continue troubleshooting this example (and maybe get some others too).
>>
>> All feedback welcome, thanks for looking at this.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

More information about the Source mailing list