Re: [cbi-dev] Bug 385967 org.eclipse.help.webapp compiles JSPs using cus

[Thanh Ha <thanh.ha@xxxxxxxxxxx>]

One thing I just noticed, inside of the org.eclipse.help.base/target I 
see the files below. Specifically I noticed in additiona to 
/target/classes there's also a /target/org which has the same contents 
as /target/classes.

 % ls org/eclipse/help/internal/workingset/
AdaptableHelpResource.class
AdaptableSelectedToc.class
AdaptableSelectedTopic.class
AdaptableToc.class
AdaptableTocsArray.class
AdaptableTopic.class
IHelpWorkingSetManager.class
WorkingSet.class
WorkingSetComparator.class
WorkingSetManager.class


Dir list of /target:
about.html
about.ini
about.mappings
about.properties
ant_tasks
classes
doc
@dot.xml
eclipse32.gif
eclipse32.png
generated-sources
local-artifacts.properties
MANIFEST.MF
maven-archiver
META-INF
org
org.eclipse.help.base-4.0.0-SNAPSHOT.jar
org.eclipse.help.base-4.0.0-SNAPSHOT-sources.jar
p2artifacts.xml
p2content.xml
plugin.properties
plugin.xml
preferences.ini
sourcebundle-l10n-gen


On 15/01/13 12:59 PM, Thanh Ha wrote:
> Hi Jan,
>
> I created Bug 398215 in Tycho and added Maven debug logs with -X -e.
>
> From what I can tell org.eclipse.help.internal.workingset.WorkingSet 
> is not a nested-jar. Tycho creates a jar 
> org.eclipse.help.base-4.0.0-SNAPSHOT.jar which includes the class and 
> the class also exists in /target/classes inside of the 
> org.eclipse.help.base project.
>
> % ls classes/org/eclipse/help/internal/workingset/
>
> AdaptableHelpResource.class
> AdaptableSelectedToc.class
> AdaptableSelectedTopic.class
> AdaptableToc.class
> AdaptableTocsArray.class
> AdaptableTopic.class
> IHelpWorkingSetManager.class
> WorkingSet.class
> WorkingSetComparator.class
> WorkingSetManager.class
>
>
> Thanh
>
>
> On 15/01/13 03:39 AM, Sievers, Jan wrote:
> > this is how it should work:
> >
> > for interop with other maven plugins, tycho injects dependencies 
> > resolved by p2 back into the maven model which normal (non-OSGi 
> > aware) maven plugins (in this case the jetty plugin) use e.g. for 
> > compilation.
> >
> > In a full build, intra-reactor dependencies are  mapped to the 
> > target/classes/ folder of the corresponding module.
> > In a partial (re)build, the dependencies are mapped to jars installed 
> > by a previous build into the local maven repo.
> >
> > If it doesn't work, open a bug with _full_ maven debug log (-X -e) 
> > attached and steps to reproduce
> >
> > My suspicion here is this could be due to limitation with nested jars.
> > In this case you would have multiple output folders e.g. 
> > target/classes-jar1/ and target/classes-jar2/ but the maven classpath 
> > model only supports one output folder target/classes so we can't map 
> > that back into the maven model. See [1] for what is supported.
> >
> > Can you check if class 
> > org.eclipse.help.internal.workingset.WorkingSet is in a nested jar?
> >
> > Regards
> > Jan
> >
> > [1] 
> > https://issues.sonatype.org/browse/TYCHO-483?focusedCommentId=125868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-125868
> >
> > From: cbi-dev-bounces@xxxxxxxxxxx 
> > [mailto:cbi-dev-bounces@xxxxxxxxxxx] On Behalf Of Thanh Ha
> > Sent: Montag, 14. Januar 2013 22:51
> > To: Common-build Developers discussion
> > Subject: [cbi-dev] Bug 385967 org.eclipse.help.webapp compiles JSPs 
> > using customBuildCallbacks
> >
> > Hi Everyone,
> >
> > I'm working on Bug 385967 and trying to use the 
> > jetty-jspc-maven-plugin to compile the JSPs. Unfortunately I'm 
> > running into a strange problem.
> >
> > Building the module by itself works fine and products the jar as 
> > expected. However if I build it as part of the complete platform 
> > build. It fails with the error:
> >
> > [ERROR] cannot access org.eclipse.help.internal.workingset.WorkingSet
> > [ERROR] class file for 
> > org.eclipse.help.internal.workingset.WorkingSet not found
> >
> > When I enabled debug mode I noticed the classpaths maven calculates 
> > are vastly different depending on if I build the module by itself vs 
> > running a full platform build. My findings:
> >      https://bugs.eclipse.org/bugs/show_bug.cgi?id=385967#c20
> >
> > Specifically the running a full build seems to be missing the 
> > following jars in the produced classpath:
> >
> > org.eclipse.core.contenttype-3.4.200-SNAPSHOT.jar
> > org.eclipse.equinox.preferences-3.5.0-SNAPSHOT.jar
> > org.eclipse.equinox.registry-3.5.300-SNAPSHOT.jar
> > org.eclipse.equinox.common-3.6.100-SNAPSHOT.jar
> > org.eclipse.core.expressions-3.4.500-SNAPSHOT.jar
> > org.eclipse.core.runtime-3.9.0-SNAPSHOT.jar
> > org.eclipse.core.jobs-3.5.300-SNAPSHOT.jar
> > org.eclipse.equinox.app-1.3.100-SNAPSHOT.jar
> > org.eclipse.equinox.http.registry-1.1.200-SNAPSHOT.jar
> > org.eclipse.equinox.jsp.jasper-1.0.400-SNAPSHOT.jar
> > org.eclipse.equinox.jsp.jasper.registry-1.0.300-SNAPSHOT.jar
> > org.eclipse.help-3.6.0-SNAPSHOT.jar
> > org.eclipse.help.base-4.0.0-SNAPSHOT.jar
> >
> >
> > I suspect this may be because those jars are produced during the 
> > build when running a full build whereas when I build 
> > org.eclipse.help.webapp by itself those jars are found from the maven 
> > local repo.
> >
> > Does anyone know anyway around this? could this be a limitation of 
> > the jetty-jspc-maven-plugin?
> >
> > Thanks,
> >
> >
> > Thanh
> > _______________________________________________
> > cbi-dev mailing list
> > cbi-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cbi-dev
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev