Personally, I find working with jme to be a lot easier if source files are attached to the jars. As far as I know, there is a standard way to attach source files to java class files. Is there a way to get nightly jars with attached source files? (Maybe this should be default, because no sane person would release a project with nightly builds)
idk what you are talking about, the jme libraries in the SDK (stable and nightly) have javadoc and sources attached.
I’m not using the SDK for programming, because netbeans lacks some required functionality such as a plugin for my favorite parser generator:)
Then tell your IDE where the sources are and all is fine. What parser generator? I doubt you can’t integrate it in NetBeans.
Everybody have a “very good” reason to not use the SDK, and we are ok with that.
The fact is we DO distribute the sources along the SDK
Just look for the pros and cons :
Your IDE has your plugin vs the SDK comes with sources and javadocs, make your choice.
Also sources are available on google code…
@nehon said:
The fact is we DO distribute the sources along the SDK
As far as I can see, the jar files distributed along the SDK are not containing the source files, which is not very surprising, because the build script excludes them explicitly. So removed the *.java excludes from the build script, enabled debug and build the engine myself and it just works. The file size nearly doubles, but with about 70MiB its not much, so one could even distribute libs with source files attached. This is btw. the only standard way to attach source files to jars.
Open any jME-project in the SDK, go to the Libraries. Open a library, right-click (or ctrl-click), select Edit from the pop-up menu, you should get the “Customize library” dialog, click the sources tab. You’ll see that the sources are included in the jMonekyEngine3-sources.zip file.
There is no standard that I know of that applies here but there is the way that maven does it which is about as close to a “most commonly used practice” as you’ll get for this. There sources is packaged in a separate jar to avoid bloating the binary. Personally I think that is a better way.
There is no standard that I know of that applies here [...]
JVM Spec §4.7.7:
http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html#79868
together with the mere fact, that jar is a zip extension, as specified in:
http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html
The fact that most IDEs allow to specify alternate source file directories is mostly because of people releasing jars only with debug information stripped away.
@kardinal said:
As far as I can see, the jar files distributed along the SDK are not containing the source files, which is not very surprising, because the build script excludes them explicitly. So removed the *.java excludes from the build script, enabled debug and build the engine myself and it just works. The file size nearly doubles, but with about 70MiB its not much, so one could even distribute libs with source files attached. This is btw. the only standard way to attach source files to jars.
If thats the standard way then we don't want to do that. Would have been nice if you had put this information up front instead of downvoting.
@kardinal said:
JVM Spec §4.7.7:
http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html#79868
together with the mere fact, that jar is a zip extension, as specified in:
http://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html
The fact that most IDEs allow to specify alternate source file directories is mostly because of people releasing jars only with debug information stripped away.
You are confusing the source attribute in the .class file (and other debugging information) with some kind of standard for where to put the source file. I can guarantee you that bulking up a jar file with source is definitely NOT a standard.
Usually when projects release something they put out the version that is most convenient for distribution, ie: as small as needed. Often this does not include the debug info in the class file (though generally that's relatively small). The theory is that if you are going to be debugging the library that you'll probably want to build it yourself anyway.
But I've never encountered a project that included the .java files right in the distribution .jar. Even Maven projects (and many derivatives) make separate -sources.jar and -javadoc.jar files to sit along side the releases.
1 Like
@normen: I’m not the only one downvoting your posts. And the reason is that its not helpful to tell my that I should use your SDK project.
@pspeed: sure, usually one has release versions, where all debug informations are stripped away and debug versions, where all debug informations are present.
EDIT: I dont mind building the debug jars myself; it takes like a minute to pull svn repo, modify the ant script and build the jars. I mind looking confused at the jars supplied with the SDK, because I was told the have attached source files, which is just wrong, because they simply do not. Instead the SDK attaches them automatically, which is something completely different. Maybe I should just have kept my mouth shut and figured out how to do it the right way instead of asking for help:-/
@kardinal said:
@normen: I'm not the only one downvoting your posts. And the reason is that its not helpful to tell my that I should use your SDK project.
Edit: I don't think the downvotes were a proper form of communication here, what does it matter if other people downvote me for other things elsewhere? Cause here nobody else but you did downvote me.
1 Like
@kardinal said:
@pspeed: sure, usually one has release versions, where all debug informations are stripped away and debug versions, where all debug informations are present.
Which is still miles and miles and miles away from having sources in the jars.
1 Like
And feel free to downvote that one too. I might have been convinced that including debug info by default is harmless but I’m no longer interested in helping if I’m just going to get down voted for trying to carry on a conversation. But since we’re all being painfully honest now, Including java files in the jars is one of the stupidest things I’ve ever heard of.
Have fun alienating yourself from the rest of the community, too.
1 Like
I +1 all but one of the posts on -1 on this thread 
1 Like