Operating System: All
Those jars in the Maven repository should have their corresponding source jar
files to assist developers.
Any chances that the source code will ever be released on the java maven repository?
What's the status of this now that Java EE 7 has been released?
This has massively ruined my day. I'm moving from Glassfish and my JSF tutorial isn't printed out the bean value to the view. I just wanted to debug the FaceServlet init method to make sure it was being loaded. Normally a 10 second job but looks like it's going to be another few hours down the pan.
Reassigning to Romain since Ludo is no longer on the project.
Romain, that is great news! Thanks!
It would be even better if it was done for Java EE 6 as well, but as EE 7 is the way forward anyway that's good enough for me.
If it isn't done for EE 6 though, shouldn't this issue be either closed or renamed?
Fixing this for ee6 is not a priority.
However it will be done correctly for ee7.
Any progress here? I know legal aspects take a long time to resolve, but has any of the legal work been started 2 years ago?
Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
Legal aspect issue, not for 3.1. Moving to P4
As I wrote, it doesn't matter if the actual jar file has executable byte code in
it or not; IDE doesn't use them.
Even if your IDE has the EE6 docs bundled, I doubt if it kicks in when importing
a Maven project. Those javadocs are presumably associated with system-defined
"JavaEE" library, but when I load my Maven project, it doesn't use those as
dependencies; it just depends on ~/.m2/repository/javax/javaee-api/6.0/javaee-
api-6.0.jar as a library, and IDE won't have any javadoc nor the source code for
But these jars are stripped: no byte code for method
For javadoc, both Eclipse and NB bundles have the ee 6 doc inline embedded.
Use case 1: javadoc lookup
Maven-aware IDEs don't suddenly notice that the dependency I have is JavaEE API
and switch to the right javadoc. This is certainly true for Eclipse and IDEA,
and I suspect it to be the same with NetBeans Maven support.
In those IDEs, if I'm writing my code and wanted to quickly check the javadoc of
those APIs, they need the accompanied source jar to be able to display them.
Ditto for figuring out the default parameter names when implementing/overriding
methods defined in the spec. IDEs don't use the bytecode for this, but instead
they do this by parsing the source files.
Use case 2: step executing inside spec classes
Some of the classes in JavaEE API have methods that are often worth executing.
When the debugger steps into those code, it needs the source files to be able to
display what's being executed. For this purpose, it's OK that javaee-api.jar can
be stripped — the debugger executes actual classes in the app server — but
you do need to have the source files.
The whole point of providing source jars is so that the necessary association
happens automatically. It's true that the user can get the complete GlassFish
source bundle and tell their IDEs to do the right thing, but the reason Maven
users use Maven is so that those grunt work can be handled by a program, instead
of using precious human time.
To assist developers to do what?
The corresponding JARs are stripped (no bytecode for methods) and are meant to
be used only for compilation. IDEs like NB or Eclipse bundle a zip for the javadoc.
What other use case do you need to get the src? Debugging? In this case, these
jars are not used for execution so also not for debugging. In the case of
debugging, I think there is a complete GF src somewhere to step into the real
code you execute from the real non stripped gf jars.