[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cbi-dev] Bug 385967 org.eclipse.help.webapp compiles JSPs using customBuildCallbacks
|
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