Hello, Java3d 1.5.0 can now be build from the source. The code has though to be downloaded after registration via CVS. It is made of 3 main separate sections: - vecmath - java3d-core-utils - java3d-core I am trying to produce rudimentary ebuilds (these are my first ones) for this package. These are not professional polished ebuilds. They are just proof of concept, a basis to work on. Reproducible: Always Steps to Reproduce: 1. No java3d based on the source 2. I downloaded it 3. I am trying now to make ebuilds Actual Results: Rudimentary Ebuilds Expected Results: Polished, "bullet proof" ebuilds Regarding the source code. It has to be fetched on Sun's website after registration. I don't know how to deal with that in the ebuild. I am just using the tar balls I created locally. This should be improved.
Created attachment 112492 [details] A rudimentary but functional ebuild for Java3D vecmath. There is a test provided by Sun for this package. The test can be ran successfully (it's a flag) on my x86 box
Created attachment 112497 [details] An attempt for j3d-core Hello, I thought it would be simple... It seems that the classes in vecmath aren't seen... :(
Please dont KEYWORD ebuilds as stable (x86 in this case) Please also quote any variable that you use. For example unpack "${A}" within src_compile you do cd ${WORKDIR}/${PN} This can be simpilified by using the global variable S="${WORKDIR}/${PN}" Please do not run tests within src_compile, tests should be compiled and run within src_test. http://devmanual.gentoo.org/ is a great reference for ebuild writing. Also it could be useful to look at the ebuilds within the java overlay. A reasonable example is located here https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/scout/scout-0.7_rc2.ebuild It should also be noted that there is a EANT_DOC_TARGET that is by default set to javadoc these EANT_*_TARGET vars specify ant targets and this should mean you dont have to implement the src_compile function My appology for the state of this post. Im at work and am rather constrained by time and mental capacity. Come joint the java team on irc://freenode/#gentoo-java and well will be able to help you out. Thanks for the effort your put in so far
(In reply to comment #3) > Please also quote any variable that you use. For example > unpack "${A}" Well, not "any variable" blindly... for example, don't quote ${A} in unpack :) ${A} is a list of filenames and you don't want to pass this list as one parameter to unpack...
(In reply to comment #3) > Please dont KEYWORD ebuilds as stable (x86 in this case) > > > Please also quote any variable that you use. For example > unpack "${A}" > Actually ${A} should not be quoted are it will break when you have multiple files in SRC_URI. The ebuild format does not allow spaces in there any way.
Created attachment 112560 [details] Second attempt to an ebuild for Java3D vecmath v1.5.0 OK, I tried to include all the suggestions I got after my first attempt, yesterday evening. I think the present ebuild is much more "orthodox" and complete than the previous one. To get the beast running, you need to get the source code of vecmath and vecmath-test via cvs from Sun. You rename the directories, adding a '-1.5.0' at the end and you tar-gzipped them: vecmath-1.5.0 -> vecmath-1.5.0.tar.gz Then run the ebuild... 3 comments: - I cannot get the test part to function. It just says test[disabled] or something like this. - I still need to check that the new classes are now usable by the system (Java3d-core, to be precise) - It builds with Java 6
you should be able to run test by going FEATURES="test" USE="test" [ebuild|emerge] ..... also another good variable is to use JAVA_PKG_STRICT=true. This will bring up more QA warnings that might occur within you ebuild Your doing really well. Thanks for the effort so far.
Alistair, The test part does not work. Any idea of what I have done wrong? It seems that the library is not seen: BUILD SUCCESSFUL Total time: 9 seconds >>> Source compiled. Buildfile: build.xml warning-if-macosx: init: [mkdir] Created dir: /var/tmp/portage/dev-java/vecmath-1.5.0/work/vecmath-test-1.5.0/build compile-opt: [mkdir] Created dir: /var/tmp/portage/dev-java/vecmath-1.5.0/work/vecmath-test-1.5.0/build/opt/classes [javac] Compiling 8 source files to /var/tmp/portage/dev-java/vecmath-1.5.0/work/vecmath-test-1.5.0/build/opt/classes [javac] /var/tmp/portage/dev-java/vecmath-1.5.0/work/vecmath-test-1.5.0/test/javax/vecmath/Matrix3fTest.java:17: cannot find symbol [javac] symbol : class Vector3f [javac] location: class javax.vecmath.Matrix3fTest [javac] final Vector3f Z_AXIS = new Vector3f(0.0f, 0.0f, 1.0f); [javac] ^ [javac] /var/tmp/portage/dev-java/vecmath-1.5.0/work/vecmath-test-1.5.0/test/javax/vecmath/Matrix3fTest.java:17: cannot find symbol [javac] symbol : class Vector3f [javac] location: class javax.vecmath.Matrix3fTest [javac] final Vector3f Z_AXIS = new Vector3f(0.0f, 0.0f, 1.0f); etc....
(In reply to comment #6) > Created an attachment (id=112560) [edit] > Second attempt to an ebuild for Java3D vecmath v1.5.0 > > OK, > Some comments about the ebuild: >=dev-java/ant-1.6.1 source? ( app-arch/zip ) test? ( dev-java/junit )" Usually you need only ant-core which is added automatically to DEPEND nowadays by inheriting java-ant-2. If you need optional ant tasks, just add WANT_ANT_TASK="ant-nodeps" for example before inherit. src_unpack() { unpack ${A} } This is the default implementation so this is redundant LICENSE="sun-jrl sun-jdl" This means that vecmath has stuff under both licenses so || ( sun-jrl sun-jdl ) is more correct. KEYWORDS="~amd64 x86 -*" Using -* is deprecated. package.mask in appropriate profiles should be used instead. And new submissions should be ~arch for everything. SRC_URI="http://download.java.net/media/java3d/builds/stable/vecmath-1.5.0.tar.gz http://download.java.net/media/java3d/builds/stable/vecmath-test-1.5.0.tar.gz" use ${PV} instead of hardcoding the version. if use doc; then java-pkg_dojavadoc "build/javadocs/" dodoc *.txt docs/*.txt java-pkg_dohtml -r *.html fi There is no reason to not install *.txt files. The doc use flag is only used for stuff that needs to be generated (for example javadocs) or if the package has megabytes of documentation. Otherwise the user can use INSTALL_MASK if he does not want the text files. Don't be encouraged, everyone goes through the learning curve at some point.
Hello Petteri, Thank you for your comments on my ebuild. I will do the changes and indeed learn about the right way to produce some... What is worrying me the most at the moment is that it seems the newly installed classes are unusable (my test section does not work and when I try to build java3d-core, I can clearly see that he does not see vecmath). Any idea why it is like this? What have I done wrong? Daniel
(In reply to comment #10) > What is worrying me the most at the moment is that it seems the newly installed > classes are unusable (my test section does not work and when I try to build > java3d-core, I can clearly see that he does not see vecmath). Any idea why it > is like this? What have I done wrong? > Your java3d-core build does not put vecmath classes to classpath for the build system: http://www.gentoo.org/proj/en/java/java-devel.xml#doc_chap3 Basically you need to call one of the eclass functions and make ant see vecmath installed in the system.
(In reply to comment #9) > (In reply to comment #6) > > Created an attachment (id=112560) [edit] > > Second attempt to an ebuild for Java3D vecmath v1.5.0 > > > > OK, > > > > Some comments about the ebuild: > >=dev-java/ant-1.6.1 > source? ( app-arch/zip ) > test? ( dev-java/junit )" > > Usually you need only ant-core which is added automatically to DEPEND nowadays > by inheriting java-ant-2. If you need optional ant tasks, just add > WANT_ANT_TASK="ant-nodeps" for example before inherit. Where can I find the list of options to give to ANT_TASK? > src_unpack() { > unpack ${A} > } > > This is the default implementation so this is redundant Do you mean that I can simply remove it? > LICENSE="sun-jrl sun-jdl" > This means that vecmath has stuff under both licenses so || ( sun-jrl sun-jdl ) > is more correct. Here I do not really understand the syntax. How is it supposed to be written? > SRC_URI="http://download.java.net/media/java3d/builds/stable/vecmath-1.5.0.tar.gz > http://download.java.net/media/java3d/builds/stable/vecmath-test-1.5.0.tar.gz" > use ${PV} instead of hardcoding the version. I did the changes but this is temporary anyway. You need to download the source via CVS from the Sun website. Do you know how am I supposed to make this appear in the ebuild? > if use doc; then > java-pkg_dojavadoc "build/javadocs/" > dodoc *.txt docs/*.txt > java-pkg_dohtml -r *.html > fi > > There is no reason to not install *.txt files. The doc use flag is only used > for stuff that needs to be generated (for example javadocs) or if the package > has megabytes of documentation. Otherwise the user can use INSTALL_MASK if he > does not want the text files. Could you develop a bit further? I did not really understand what you meant. > Don't be encouraged, everyone goes through the learning curve at some point. Don't cry for me, Argentine... ;) Daniel
Created attachment 112832 [details] Third attempt for vecmath-1.5.0 I tried to integrate the modifications sugested by all of you (well, the one that I understood...). I do still have a problem with the test section. It does not use the vecmath classes for a reason unknown to me. Can someone take a look at this and make the changes necessary? I tried for 2 hours and now I do not find it funny anymore to play around, in vain, with 3 f...g lines of code.... Daniel
(In reply to comment #13) > Created an attachment (id=112832) [edit] > Third attempt for vecmath-1.5.0 > > I tried to integrate the modifications sugested by all of you (well, the one > that I understood...). > > I do still have a problem with the test section. It does not use the vecmath > classes for a reason unknown to me. Can someone take a look at this and make > the changes necessary? I tried for 2 hours and now I do not find it funny > anymore to play around, in vain, with 3 f...g lines of code.... > > Daniel > Sure. It's off no use to use too much time. In those cases it's just best for let us find the answer.
I am working now on jd3-core. I started the ebuild with: EANT_DOC_TARGET="docs" EANT_BUILD_TARGET="jar" EANT_GENTOO_CLASSPATH="vecmath" JAVA_PKG_STRICT=true src_unpack() { unpack ${A} cd "${WORKDIR}" ln -s "${PN}-${PV}" "${PN}" ln -s "${PN}-utils-${PV}" "${PN}-utils" ln -s j3d-examples-${PV} j3d-examples cd ${S} java-ant_rewrite-classpath # Symlink jars mkdir -p target/lib cd target/lib use test && java-pkg_jar-from junit } and it says: [javac] /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/src/classes/share/javax/media/j3d/Locale.java:15: package javax.vecmath does not exist [javac] import javax.vecmath.*; [javac] ^ [javac] /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/src/classes/share/javax/media/j3d/Transform3D.java:15: package javax.vecmath does not exist [javac] import javax.vecmath.*; [javac] ^ etc... Obviously my vecmath cannot be seen... Now I wonder, it says javax.vecmath.* When I created the vecmath.jar, did I use the right paths? I am not a specialist in Java. I know there are things like this.. Have I done (again...) anything wrong in my vecmath ebuild regarding the location of the classes? Daniel
Created attachment 113143 [details] alistairs dev-java/vecmath-1.5.0 Hi Daniel. Here is my vecmath ebuild. Still needs a little clean up (remove some of the comments etc etc. You will notice the comments at the top that detail how I extracted the packages out of cvs, thats always handy as it allows others to replicate the tar.gz's at a latter date. Also note as the tar's ain't hosted yet the SRC_URI is just a list of the files. The ebuild I did will also run the tests as well. Having a look at the java3d package it looks like we may need to patch the ebuild or recreate the vecmath project file structure (but only containing the vacmath jar).
Alistair, That was quick! ;) I wrote the comment on the forum 40mn ago or something... ;) Thank you very much for your help. It seems that I was not so far but still, I was not there. There is clearly some ebuild magic in this... ;) First comment: - When I try to build the packages it asks me for: =dev-java/ant-core-1.7.0 ~x86 =dev-java/ant-junit-1.7.0 ~x86 Is it really supposed to be like this? I did not have that before. paris vecmath # emerge -pv vecmath These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-java/ant-core-1.7.0 [1.6.5-r14] USE="doc -source" 6,683 kB [ebuild N ] dev-java/ant-junit-1.7.0 0 kB [ebuild R ] dev-java/vecmath-1.5.0 USE="doc -source* -test*" 0 kB [1] [blocks B ] <dev-java/ant-1.7.0 (is blocking dev-java/ant-core-1.7.0) [blocks B ] <dev-java/ant-tasks-1.7.0 (is blocking dev-java/ant-core-1.7.0)
(In reply to comment #17) > Alistair, > > That was quick! ;) I wrote the comment on the forum 40mn ago or something... ;) > Thank you very much for your help. > It seems that I was not so far but still, I was not there. There is clearly > some ebuild magic in this... ;) > > First comment: > - When I try to build the packages it asks me for: > =dev-java/ant-core-1.7.0 ~x86 > =dev-java/ant-junit-1.7.0 ~x86 Mmmm.. Sorry about that. The reason for that is because in >=ant-1.7 the ant-tasks package has been modularized. Easiest way to fix the ebuild is to remove WANT_ANT_TASKS and add "dev-java/ant-core dev-java/ant-tasks" to depend Im actually unsure about how (or if) <ant-1.7 and >=ant-1.7 can be handled easily within an ebuild. So its probably easier to just modify the ebuild to use the depreciated way. We will fix that up once it goes into the overlay/tree for you. It should also be noted that somehow I corrupted the header it should contain # $Header: $ as the third line. Not sure what I did to get rid of it. Oh and one last thing. I didn't rename the directories when I did my version so you will either need to remake the source tar.gz or modify the ebuild to reflect that.
Created attachment 113154 [details] Fourth attempt for vecmath-1.5.0 (based on Alistair's) Hello, I cleaned a bit the ebuild and I removed references to ant-1.7 and junit-4 (that was also a problem). - It builds! - It builds with Java 1.6 - It builds with the source - The tests work Thank you Alistair! Thanks a lot for your help. Now, time to work on Java-3d... You mentionned a patch. What did you mean?
(In reply to comment #19) > Created an attachment (id=113154) [edit] > Fourth attempt for vecmath-1.5.0 (based on Alistair's) > > Hello, > > I cleaned a bit the ebuild and I removed references to ant-1.7 and junit-4 > (that was also a problem). > - It builds! > - It builds with Java 1.6 > - It builds with the source > - The tests work > > Thank you Alistair! Thanks a lot for your help. > > Now, time to work on Java-3d... You mentionned a patch. What did you mean? Currently it looks like the build.xml file expects the vecmath source (and jars) to be located next to them so ${WORKDIR}/ j3d-core/ j3d-core-utils/ vecmath/ A solution might be to java-ant_rewrite-classpath the build.xml files that are the perpetrators. This and the next solution might not work if they build.xml files start attempting to cp files across from vecmath I would just see what happens when you do something along the lines of unpack() { unpack ${A} mkdir vecmath/build/..../ cd vecmath/build/.../ java-pkg_jarfrom vecmath #I believe there is both a debug and release jar so both may have to be #replaced. }
Created attachment 113205 [details] Second attempt for J3d-core Hello Alistair, Thank you again for your answer. It's fun collaborating with you. It works well... ;) Here is my second attempt for J3d-core. I based it on the vecmath ebuild and tried to integer the few things I found by myself as well as your comments. It does not work but we can use it as a common base for development and discussion. Best regards
Sorry, I had missed a few trivial errors: src_unpack() { unpack ${A} cd "${WORKDIR}" mkdir -p vecmath/build/ cd vecmath/build/ java-pkg_jarfrom vecmath cd "${WORKDIR}" ln -s "${PN}-${PV}" "${PN}" ln -s "${PN}-utils-${PV}" "${PN}-utils" ln -s j3d-examples-${PV} j3d-examples cd ${S} java-ant_rewrite-classpath } but still, it doesn't work. Vecmath is not seen/used
Alistair, Are we doing things in the right order? According to Sun (see below), j3d-core-utils is required to build j3d-core. Maybe the error messages that I see aren't vecmath missing classes but j3d-core-utils'. What do you think? Daniel This project contains the source code for the core Java 3DTM API package, javax.media.j3d. Related projects include: vecmath (the 3D vector math package), j3d-core-utils (the Java 3D core utilities), and j3d-examples (the Java 3D example programs). The vecmath and j3d-core-utils projects are required to build j3d-core. Developers should refer to the CVS download and build instructions for information on downloading the source code and building j3d-core. For all other project information, including contributing to Java 3D and reporting issues, please go to the parent java3d project.
(In reply to comment #22) > Sorry, > > I had missed a few trivial errors: > src_unpack() { > unpack ${A} > cd "${WORKDIR}" > mkdir -p vecmath/build/ #make this mkdir -p vecmath/build/opt/lib/ext && mkdir -p vecmath/build/debug/lib/ext #cd into 1 java-pkg_jarfrom vecmath #cd into 2 java-pkg_jarfrom vecmath > cd vecmath/build/ > java-pkg_jarfrom vecmath > cd "${WORKDIR}" > ln -s "${PN}-${PV}" "${PN}" > ln -s "${PN}-utils-${PV}" "${PN}-utils" > ln -s j3d-examples-${PV} j3d-examples > cd ${S} > > java-ant_rewrite-classpath #lets try and not use rewrite-classpath unless we have to. > } > > but still, it doesn't work. Vecmath is not seen/used After u have done this just do ebuild <blah> unpack and check whether the vecmath jars are linked in the correct locations > The build.xml files use <path id="vecmath.debug.classpath"> <pathelement location="${vecmath_home}/build/debug/lib/ext/vecmath.jar"/> </path> <path id="vecmath.opt.classpath"> <pathelement location="${vecmath_home}/build/opt/lib/ext/vecmath.jar"/> </path> for the vecmath classpath. So these jars must be available. Will also need to investigate if there are separate targets for the debug and release jars.
Hello Alistair, > > I had missed a few trivial errors: > > src_unpack() { > > unpack ${A} > > cd "${WORKDIR}" > > mkdir -p vecmath/build/ > > #make this > mkdir -p vecmath/build/opt/lib/ext && mkdir -p vecmath/build/debug/lib/ext > #cd into 1 > java-pkg_jarfrom vecmath > #cd into 2 > java-pkg_jarfrom vecmath So, it seems that I had in fact misunderstood what you meant... ;) Now I got the picture, I understood the principles. > After u have done this just do ebuild <blah> unpack and check whether the > vecmath jars are linked in the correct locations Well, I tried to build this beast and interesting things are happening now... It complains but not for the same reasons anymore. Vecmath is seen and used but... [javac] Compiling 757 source files to /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/build/linux-i586/opt/classes [javac] /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/src/classes/x11/javax/media/j3d/NativeConfigTemplate3D.java:19: warning: sun.awt.X11GraphicsDevice is Sun proprietary API and may be removed in a future release [javac] import sun.awt.X11GraphicsDevice; ^ sun.awt has an issue. How to solve that? > Will also need to investigate if there are separate targets for the debug and > release jars. You mean if vecmath is different for these 2 targets? I know both are built but we keep only one, the release jar. Daniel
(In reply to comment #25) /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/src/classes/x11/javax/media/j3d/NativeConfigTemplate3D.java:19: > warning: sun.awt.X11GraphicsDevice is Sun proprietary API and may be removed in > a future release > [javac] import sun.awt.X11GraphicsDevice; ^ That looks just a warning, unless there's also error below that the package is not found (shouldn't be, at least on sun-jdk? it's possible that ibm-jdk etc won't work because of this). And you can't solve that except asking upstream not to use this class :) But as a warning it shouldn't break the build, or does it?
Vlastimil > That looks just a warning, unless there's also error below that the package is > not found (shouldn't be, at least on sun-jdk? it's possible that ibm-jdk etc > won't work because of this). And you can't solve that except asking upstream > not to use this class :) But as a warning it shouldn't break the build, or does > it? You were right. These are just warning.... I use sun-jdk-1.6: !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="javac" It basically says: [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. The ebuild is broken but not for the reasons I thought at the beginning: BUILD FAILED /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/build.xml:398: The following error occurred while executing this line: /var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-1.5.0/src/classes/build.xml:194: /var/tmp/portage/dev-java/j3d-core-1.5.0/work/vecmath/src not found. It seems that the vecmath sources need to be included there as well. Daniel PS: Here is how the unpack section of the ebuild looks like at the moment (the rest being as the one I put as an attachment yesterday) src_unpack() { unpack ${A} cd "${WORKDIR}" mkdir -p vecmath/build/opt/lib/ext cd vecmath/build/opt/lib/ext java-pkg_jarfrom vecmath cd "${WORKDIR}" mkdir -p vecmath/build/debug/lib/ext cd vecmath/build/debug/lib/ext java-pkg_jarfrom vecmath cd "${WORKDIR}" ln -s "${PN}-${PV}" "${PN}" ln -s "${PN}-utils-${PV}" "${PN}-utils" ln -s j3d-examples-${PV} j3d-examples cd ${S} }
Created attachment 113274 [details] Third attempt with j3d-core Hello guys! Here are the results of a few hours of (not so) successful hacks and reflection... The third attempt with j3d-core (see attachment) is half functional. I explain myself... - It does build and does create two jars: j3dutils and j3dcore however... - The 'source' flag does not work (and I do not understand the origin of this): j3d-core-1.5.0.ebuild, line 70: Called java-pkg_dosrc '/var/tmp/portage/dev-java/j3d-core-1.5.0/work/j3d-core-utils-1.5.0.tar.gz/src/*' java-utils-2.eclass, line 605: Called die - The 'doc' flag does not work either, it seems that the code for vecmath is required - I do not know how to get the examples compiled and available - I need to specify clearly linux-i586 in my ebuild as a platform and this is bad, IMHO... So, as I said, a limited success... I looked in the build.xml for j3core and I have difficulties to comprehend it, my experience in the domain being about a week old now... :( Trying to find the reasons of the problems, I have started to wonder if to separate vecmath from j3core was a good idea to begin with. I did that because the explanation on the SUN website gave me the feeling that these packages could be independent of each others, j3core depending on j3dcore-utils and vecmath, for instance. But now, the way the ebuild behaves gives me the feeling that vecmath, j3dcore and j3dcore-utils should be build together at once, in one ebuild... So, what do you think? What's your opinion? Daniel
Created attachment 113300 [details] A fourth attempt to j3d-core Hello, I found the origin of the strange bug with the "source" flag. I did a copy/paste and I missed a little detail... Well, I changed that and now, when I use the "source" flag it complains that it lacks... vecmath source... So, I decided to give a try to the "Grand Unified Ebuild"... the sun-j3d ebuild...
Created attachment 113303 [details] A first attempt to the "Grand Unified Ebuild", sun-java3d From two, I made one.... First conclusions: - It builds... ;) - The source flag works, some source .zip file is created (I hope it contains everything it should) - The doc flags seems to work (some documentation is produced) - I still do not really know how to handle examples First questions: - There is a 'debug' flag. How can it be inserted in the ebuild such that when the flag is on, debug information are kept? - I wonder if I really put in the final package everything produced during the compilation of Sun-j3d. I saw, as a matter of fact, that classical libraries were also produced. What to do with them?
Created attachment 113306 [details] Second attempt to sun-java3d Here is my second attempt. The idea is to make it simpler by removing the version number in j3d-core directories. Unfortunately I cannot test anything anymore... :( For some unknown reason, portage refuses to see that the source codes are in the distfiles directory and keep on trying to download them from the net (where they aren't yet... :( ) Very strange and very frustrating In any cases, before this strange behavior starts, I have been able to see that the 'test' flag works as well Daniel
(In reply to comment #31) > Unfortunately I cannot test anything anymore... :( > For some unknown reason, portage refuses to see that the source codes are in > the distfiles directory and keep on trying to download them from the net Assuming you work on it via local overlay and using ebuild command? Try 'ebuild foo.ebuild digest' to recreate digests first. If it doesn't work for some reason, delete Manifest and files/digest-* and try again.
Created attachment 113334 [details] alistair dev-java/j3d-core-1.5.0.ebuild This is my attempt at doing the split j3-core ebuild. Things to note, I couldn't get the ebuild to build without using eclipse-ecj as the compiler (always getting OutOfMemory issues) javadoc are a problem. On that is going to have to be allowed for. Basically we will have to manually copy the 2-3 directorys into ${D}/use/share/doc/${P}/html/[api/] Maybe even have a gentoo themed html page to that links to the other directories. Also we should split utils from j3d-core
Created attachment 113336 [details] j3d-core-1.5.0.ebuild (alistairs number 2 but still uncomplete) You could have picked an easier package for your first, I hope you realize ;)
(In reply to comment #32) > (In reply to comment #31) > > Unfortunately I cannot test anything anymore... :( > > For some unknown reason, portage refuses to see that the source codes are in > > the distfiles directory and keep on trying to download them from the net > > Assuming you work on it via local overlay and using ebuild command? Try 'ebuild > foo.ebuild digest' to recreate digests first. If it doesn't work for some > reason, delete Manifest and files/digest-* and try again. Thank you! I had done everything you mentionned except removing the digest-* I had forgotten about them... This being done, now the ebuild works as usual, using the tar.gz files in the distfile directory. My second attempt to sun-java3d works as planned. It's still rough on the edge and many things are missing (I suppose), but it is a working base we can use. Daniel
(In reply to comment #34) > Created an attachment (id=113336) [edit] > j3d-core-1.5.0.ebuild (alistairs number 2 but still uncomplete) I'll test it. How strange that you need eclipse-ecj. Here I use sun-jdk-1.6 and it works well (it seems so) > You could have picked an easier package for your first, I hope you realize ;) Well, this is only the beginning, the "plat de resistance" is that one: http://www.opencfd.co.uk/openfoam/ Do you like challenges... ;) On the other hand, I have been learning quiet a lot the last few days. So, it's fun in itself...
Created attachment 113389 [details] Third attempt for an ebuild to sun-java3d Hello, This ebuild is a polished version of the previous one. It reacts to 5 flags: - doc : documents are built. It remains to be checked if they are coherent, functional and "good looking" - test : this works. I used the work done on the vecmath ebuild; - debug : I noticed that debug version of the jar are built anyway (I suppose I could try to use -Ddebug=OFF (or something like that) in the ant parameters to avoid this), so I thought that a flag would not hurt; - examples : examples are now added and properly built. I need to check that they work though... - source : install the source. This works too. One comment, I need to write explicitely 'linux-i586' in the ebuild. I think this is bad for portability. Maybe a variable depending on the platform would be a good idea... Daniel
Hello, One comment, one problem: - Comment: There are extra subprojects that can be extracted from the Sun website: https://java3d.dev.java.net/#Subprojects I don't know what to do with them. Some of the things there seem interesting. Maybe separate ebuilds. - Problem: I cannot run the examples... There it might be due to my lack of experience with Java. When I type (as specified in the README file): mhordraid hello_universe # cd /root/j3d-examples/ mhordraid j3d-examples # java org.jdesktop.j3d.examples.hello_universe.HelloUniverse Exception in thread "main" java.lang.NoClassDefFoundError: org/jdesktop/j3d/examples/hello_universe/HelloUniverse but: mhordraid j3d-examples # env | grep CLASS CLASSPATH=/usr/share/sun-java3d/lib/vecmath.jar:/usr/share/sun-java3d/lib/j3dutils.jar:/usr/share/sun-java3d/lib/j3dcore.jar:.:/usr/share/vtk/lib/vtk.jar So I don't know... Any help is welcome. So here my conclusions: There is now an ebuild to build sun-java3d. At the beginning I thought vecmath and j3d-core would have to be built separately. Now I am not so sure... I think I misunderstood what Sun meant. The 'Grand Unified ebild' seems to work fairly well. Some polish is certainly still required and I would like to be sure that the examples are working but otherwise, everything seems to be fine. Daniel
(In reply to comment #38) > Hello, > > One comment, one problem: > > - Comment: > There are extra subprojects that can be extracted from the Sun website: > https://java3d.dev.java.net/#Subprojects > I don't know what to do with them. Some of the things there seem interesting. > Maybe separate ebuilds. > > - Problem: > I cannot run the examples... There it might be due to my lack of experience > with Java. When I type (as specified in the README file): > mhordraid hello_universe # cd /root/j3d-examples/ > mhordraid j3d-examples # java > org.jdesktop.j3d.examples.hello_universe.HelloUniverse > Exception in thread "main" java.lang.NoClassDefFoundError: > org/jdesktop/j3d/examples/hello_universe/HelloUniverse > > but: > mhordraid j3d-examples # env | grep CLASS > CLASSPATH=/usr/share/sun-java3d/lib/vecmath.jar:/usr/share/sun-java3d/lib/j3dutils.jar:/usr/share/sun-java3d/lib/j3dcore.jar:.:/usr/share/vtk/lib/vtk.jar > > So I don't know... Any help is welcome. > > > So here my conclusions: There is now an ebuild to build sun-java3d. At the > beginning I thought vecmath and j3d-core would have to be built separately. Now > I am not so sure... I think I misunderstood what Sun meant. The 'Grand Unified > ebild' seems to work fairly well. Some polish is certainly still required and I > would like to be sure that the examples are working but otherwise, everything > seems to be fine. > > Daniel > Have you actually added the examples jar to the classpath?
(In reply to comment #39) > Have you actually added the examples jar to the classpath? Hello, How do I do that, the gentoo way? How do I cleanly add paths to the classpath? Daniel
(In reply to comment #40) > (In reply to comment #39) > > > Have you actually added the examples jar to the classpath? > > Hello, > > How do I do that, the gentoo way? How do I cleanly add paths to the classpath? > > Daniel > java -cp `java-config -d -p vecmath`:`java-config -d -p j3d-core`:<path to examples jar>` org.something.I.want.to.execute
(In reply to comment #41) > > java -cp `java-config -d -p vecmath`:`java-config -d -p j3d-core`:<path to > examples jar>` org.something.I.want.to.execute > java -cp `java-config -d -p vecmath,j3d-core` is shorter and you only need to call java-config once
Hello, > java -cp `java-config -d -p vecmath,j3d-core` is shorter and you only need to > call java-config once > I am trying this... Ain't got much success though... :( ted@paris /usr/share/sun-java3d/lib $ java -cp 'java-config -d -p vecmath,j3d-core,j3d-examples' org.jdesktop.j3d.examples.hello_universe.HelloUniverse Exception in thread "main" java.lang.NoClassDefFoundError: org/jdesktop/j3d/examples/hello_universe/HelloUniverse
(In reply to comment #43) > > I am trying this... Ain't got much success though... :( > > ted@paris /usr/share/sun-java3d/lib $ java -cp 'java-config -d -p > vecmath,j3d-core,j3d-examples' > org.jdesktop.j3d.examples.hello_universe.HelloUniverse > Exception in thread "main" java.lang.NoClassDefFoundError: > org/jdesktop/j3d/examples/hello_universe/HelloUniverse > You are using single quetes instead of back ticks. ' vs. ` Maybe java -cp $(java-config -d -p vecmath,j3d-core,j3d-examples) is more clear to you. I suggest man bash as a good reading on bash and http://www.tldp.org/LDP/abs/html/
Thank you for the help. So here is what I get: ted@paris /usr/share/sun-java3d/lib $ pwd /usr/share/sun-java3d/lib ted@paris /usr/share/sun-java3d/lib $ ls j3dcore.jar j3d-examples.jar j3dutils.jar vecmath.jar ted@paris /usr/share/sun-java3d/lib $ java -cp $(java-config -d -p vecmath,j3d-core,j3d-examples) org.jdesktop.j3d.examples.hello_universe.HelloUniverse !!! ERROR: Package vecmath was not found! !!! ERROR: Package j3d-core was not found! !!! ERROR: Package j3d-examples was not found! Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file)
Anything new on this front? dev-java/sun-java3d-bin is really outdated in the tree.
Already packaged in the tree as dev-java/vecmath. Closing this bug.
(In reply to Patrice Clement from comment #47) > Already packaged in the tree as dev-java/vecmath. Closing this bug. Ahem, no. vecmath is a dependency of Java3D.
