Community
Participate
Working Groups
We, the Jubula team, are currently experience problems when trying to open the help content of "Eclipse for Testers" Juno M6. See bug 377484 for further information. This completely prevents us from showing our user documentation.
Did this work in Juno M6 but not with a current http://download.eclipse.org/eclipse/downloads/drops4/I20120426-0800/ build? How is it supposed to work? Do you do anything, or do you just contribute help docs through an extension point? The log in attachment #214445 [details] seems to indicate that Jasper is mis-configured. Tom, is thing the kind of thing the platform jetty changes could effect? Markus, If you run your eclipse in a console (cmd.exe and eclipsec >log.txt 2>&1 on windows) you might get Jetty logs. PW
(In reply to comment #1) > Did this work in Juno M6 but not with a current > http://download.eclipse.org/eclipse/downloads/drops4/I20120426-0800/ build? > > How is it supposed to work? Do you do anything, or do you just contribute help > docs through an extension point? The log in attachment #214445 [details] seems to > indicate that Jasper is mis-configured. > > Tom, is thing the kind of thing the platform jetty changes could effect? > Yes, the org.eclipse.equinox.jsp.jasper bundle should be setting a system property org.apache.jasper.compiler.disablejsr199=true to convince jasper to use ecj. See http://java.net/jira/browse/JSP-21. Could you try setting that explicitly in your config.ini to see if it helps. > > Markus, If you run your eclipse in a console (cmd.exe and eclipsec >log.txt > 2>&1 on windows) you might get Jetty logs. > > PW
I can confirm that manually setting the system property in the config.ini resolves this issue. Is this still an issue for platform ui user assistance or should we / the EPP package itself resolve it, e.g. by setting the property?
(In reply to comment #3) > I can confirm that manually setting the system property in the config.ini > resolves this issue. > > Is this still an issue for platform ui user assistance or should we / the EPP > package itself resolve it, e.g. by setting the property? Not sure, is it possible something is accessing jasper before help is started? Perhaps the jasper bundle is reading that property too soon before org.eclipse.equinox.jsp.jasper is started and then later when help is invoked it is too late? That would indicate that we should probably set this by default in our config.ini. Another option is for us to modify the copy of org.apache.jasper.glassfish in orbit to disable jsr199 by default. Hughes, do you think that is an option?
We do not explicitly access jasper before help is started - and this issue still occurs in Juno M7. I am not sure what the current status of this issue is - will this be resolved at the platform level or are we supposed / able to do this on our own? For us it's very important that this is working in the upcoming Juno release as we participate in the release train and it completely blocks our user assistance from working.
John, what do you think we should do here? I think the only option at this point is to set the property in the config.ini.
(In reply to comment #3) > I can confirm that manually setting the system property in the config.ini > resolves this issue. I tried this myself and it does not solve the issue for me. > > Is this still an issue for platform ui user assistance or should we / the EPP > package itself resolve it, e.g. by setting the property? Setting this property will not help (at least for the M7 EPP I got of Eclipse for Testers). The issue is that this EPP is not including org.eclipse.jdt.core. But this brings up an overall issue that the help system is requiring org.eclipse.jdt.core.
Unfortunately we may need to add org.eclipse.jdt.core to the platform feature (which includes the help system).
Having the Help system require jdt.core sounds strange. Is it using a function or class within jdt.core that should be moved to some more common location? Also, is this a new dependency as of Juno?
(In reply to comment #9) > Having the Help system require jdt.core sounds strange. Is it using a function > or class within jdt.core that should be moved to some more common location? > Also, is this a new dependency as of Juno? At worst it would need to include ECJ, which is much smaller than the full JDT core. Help pages that include uncompiled JSPs need a java compiler to compile the JSP at runtime. Jasper used to include a copy of ECJ so we were always actually including a part of JDT in the platform in the past (see bundle org.apache.jasper in 3.7 or earlier).
(ECJ = Eclipse Compiler for Java... packaged as bundle org.eclipse.jdt.core.compiler.batch).
I think we are going to have to package ecj into the jasper.glassfish bundle in orbit. I have confirmed this fixes the issue and allows us to remove the following (not really) optional imports from org.apache.jasper.glassfish bundle: org.eclipse.jdt.core.compiler;resolution:=optional, org.eclipse.jdt.internal.compiler;resolution:=optional, org.eclipse.jdt.internal.compiler.classfmt;resolution:=optional, org.eclipse.jdt.internal.compiler.env;resolution:=optional, org.eclipse.jdt.internal.compiler.impl;resolution:=optional, org.eclipse.jdt.internal.compiler.problem;resolution:=optional Now the question is do we just embed all of ecj for Indigo: http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.7.2-201202080800/ecj-3.7.2.jar Or do we somehow try to only include a subset of what is needed. I am for embedding the whole thing since it will take time we don't have to be confident we got the subset correct.
BTW, this is how we shipped jasper in previous releases, see: http://dev.eclipse.org/viewsvn/viewvc.cgi/org.eclipse.orbit/org.apache.jasper/org/eclipse/?root=Tools_Project&pathrev=v5_5_17
John, please review what I did in the v2_2 branch for the org.apache.jasper.glassfish bundle at: http://dev.eclipse.org/viewsvn/viewvc.cgi/org.eclipse.orbit/org.apache.jasper.glassfish/?root=Tools_Project&pathrev=v2_2 All that I did was add ecj from 3.7.2 to the org/eclipse/jdt... folder and removed the optional imports of the jdt packages from the bundle manifest.
CC David Williams since we will need to promote a new orbit build for RC1 and consume it in the eclipse/equinox builds to pull in the new version of org.apache.jasper.glassfish version 2.2.2.
It looks good to me. I verified that help works in an application that does not including JDT or the JDT batch compiler (Orion in my case). One minor note... while reviewing I noticed several minor problems with the about.html in this bundle. While we are spinning a new build might as well fix it. I have entered bug 379468 for that.
I tagged the v2_2 branch with (v201205141649) and I updated the orbit map for the org.apache.jasper.glassfish bundle: plugin@org.apache.jasper.glassfish,2.2.2=v201205141649,:pserver:anonymous@dev.eclipse.org:/cvsroot/tools,,org.eclipse.orbit/org.apache.jasper.glassfish plugin@org.apache.jasper.glassfish.source,2.2.2=v201205141649,:pserver:anonymous@dev.eclipse.org:/cvsroot/tools,,org.eclipse.orbit/org.apache.jasper.glassfish/source-bundle
I've updated the platform's map files to use the latest I build, to pickup glassfish version 2.2.2.v201205150955. You (someone) could confirm build on Wednesday. Will leave open until I send note and update maps to S build.
(In reply to comment #18) > I've updated the platform's map files to use the latest I build, to pickup > glassfish version 2.2.2.v201205150955. Can you point to a commit record on this? I am not seeing it in the latest orbit.map http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/tree/org.eclipse.releng/maps/orbit.map And to be clear, we are waiting for the build tonight (Wednesday) to confirm this change? or were you expecting it to be in the I20120515-2200. I don't see it in the I20120515-2200 build.
> > And to be clear, we are waiting for the build tonight (Wednesday) to confirm > this change? or were you expecting it to be in the I20120515-2200. I don't see > it in the I20120515-2200 build. Apologies, I forgot to "push" my temporary change to orbit maps, so will re-promote Orbit S build this afternoon and make "final fix" for Wednesday night's build, for confirmation on Thursday.
Ok, I have now committed (and pushed!) the fix in orbit maps files for this evenings builds.
