Home » Eclipse Projects » Eclipse Platform » headless (feature) build obscurities
|
| Re: headless (feature) build obscurities [message #331841 is a reply to message #331832] |
Wed, 24 September 2008 18:47   |
 Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
Daniel,
When it comes right down to compile time, we are simply compiling java
code. If it helps, take a look at the generated build.xml files for
your bundles and see the javac ant task and the classpath it is using.
Fundamentally, the issue is that the java compiler does not support
nested jars on the classpath. Something like
C:/eclipse/plugins/org.eclipse.foo_1.0.0.jar/library.jar
is not a valid classpath entry.
However, folders are valid entries, the compiler expects the package
folders and class files to be on disk immediately under that folder.
This means that yes, plugins in folder shape with '.' as a
Bundle-Classpath should work, ie:
C:/eclipse/plugins/org.foo_1.0.0/org/foo/bar.class
/org/foo/internal/zot.class
If things are not compiling, I can only suggest looking at the generated
build.xml and the classpath that is being used to see if it contains
what you expect.
-Andrew
Daniel Krügler wrote:
> I stumbled across some unexpected problems during a headless
> feature build of our product as described in the thread,
> "Curiosities in headless feature build" (eclipse.platform.rcp)
> which partly depend on the existing bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=157375
>
> Just to be sure about that problem I switched the flag "unpack"
> from the feature.xml to true for *all* our plugins of the
> primary build product. Unfortunately, the headless feature build
> of the depending feature (basing on the standard target as well
> as on the pre-builds of the primary product) *still* fails because
> it cannot resolve the referred packages and class names in
> the to-be-build plugins.
>
> Question: I did not change anything else except this flag, *so*
> could it be true, that plugins build in an unpacked form are
> *required* to change the dot-style (to refer to their own library
> contents) to the named library style to allow depending headless
> builds to resolve the names properly???
>
> If not: Is anyone aware of other reasons for such a failure?
>
> I can exclude the following obvious ones:
>
> 1) The target plugins/features as well as the plugins/features of
> the primary build are available in *one* common directory with
> proper layout as described in the Eclipse help. This directory
> is referred to in the build.properties file as the property
> "baseLocation". This also means that all Require-Bundle entries
> of the single to-be-build plugin (I removed all other ones to
> get the first feeling of success...) do really exist in this
> base location.
>
> 2) I selected a *very* short path away from the disk root directory
> to prevent any possible problems due to path lengths limitations
> of the underlying OS (Windows XP).
>
> 3) The to-be-build feature does *not* mention any concrete
> plugin or feature versions of it's dependencies (value=0 as
> per default assigned).
>
> 4) Our normal product build, which *only* depends on the "native"
> targets (thus without any pre-builds from us) does run smoothly
> since years.
>
> Near to black despair I thank you in advance for any help,
>
> Daniel Krügler
|
|
|
| Re: headless (feature) build obscurities [message #331854 is a reply to message #331841] |
Thu, 25 September 2008 12:18 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Andrew Niefer wrote:
> Daniel,
> When it comes right down to compile time, we are simply compiling java
> code. If it helps, take a look at the generated build.xml files for
> your bundles and see the javac ant task and the classpath it is using.
>
> Fundamentally, the issue is that the java compiler does not support
> nested jars on the classpath. Something like
> C:/eclipse/plugins/org.eclipse.foo_1.0.0.jar/library.jar
> is not a valid classpath entry.
>
> However, folders are valid entries, the compiler expects the package
> folders and class files to be on disk immediately under that folder.
> This means that yes, plugins in folder shape with '.' as a
> Bundle-Classpath should work, ie:
> C:/eclipse/plugins/org.foo_1.0.0/org/foo/bar.class
> /org/foo/internal/zot.class
>
> If things are not compiling, I can only suggest looking at the generated
> build.xml and the classpath that is being used to see if it contains
> what you expect.
>
> -Andrew
Thanks for your interest, Andrew! I spend the complete day understanding
this problem. I could not see anything suspicious in the build.xml.
Finally I decided to try something out: I replaced in the first plugin,
whose classes could not be resolved, the standard dot-library to a named
one ("gaga.jar") - and it worked for this guy!
Could anyone explain to me this phenomenon, please???
Since *years* we are using the recommended jar'ed plugin packaging
style including the also recommended dot(.) reference name and
could live without any problems. Nearly all of our plugins
contain thirdparty-library code as inner jars - no problem with
the osgi runtime at all.
Now it was the first time that I tried to *reuse* an already build
product as part of the base-location (additional to the Eclipse
plugins and features) and must now recognize the follwing:
1) Inner jars in jar'ed plugins are not resolved. Workaround: Use
unpacked plugins.
2) The standard dot-naming of the plugin library also causes that
dependent plugins cannot resolve these names. Workaround: Use an
arbitrary named plugin library name.
Can this really be true???
Thanks for any help,
Daniel
|
|
|
| Re: headless (feature) build obscurities [message #331872 is a reply to message #331854] |
Thu, 25 September 2008 20:23 |
Andrew Niefer
Messages: 990
Registered: July 2009 |
Senior Member |
|
|
The only thing that comes to mind is, are your Bundle-Classpath entries
in the manifests correct?
If no Bundle-Classpath is specified, then the default value is '.'
But if you've changed things and added entries to the Bundle-Classpath
and didn't add '.' as well, then root of the bundle will not be
considered for the classpath.
Daniel Krügler wrote:
> Andrew Niefer wrote:
>> Daniel,
>> When it comes right down to compile time, we are simply compiling java
>> code. If it helps, take a look at the generated build.xml files for
>> your bundles and see the javac ant task and the classpath it is using.
>>
>> Fundamentally, the issue is that the java compiler does not support
>> nested jars on the classpath. Something like
>> C:/eclipse/plugins/org.eclipse.foo_1.0.0.jar/library.jar
>> is not a valid classpath entry.
>>
>> However, folders are valid entries, the compiler expects the package
>> folders and class files to be on disk immediately under that folder.
>> This means that yes, plugins in folder shape with '.' as a
>> Bundle-Classpath should work, ie:
>> C:/eclipse/plugins/org.foo_1.0.0/org/foo/bar.class
>> /org/foo/internal/zot.class
>>
>> If things are not compiling, I can only suggest looking at the
>> generated build.xml and the classpath that is being used to see if it
>> contains what you expect.
>>
>> -Andrew
>
> Thanks for your interest, Andrew! I spend the complete day understanding
> this problem. I could not see anything suspicious in the build.xml.
> Finally I decided to try something out: I replaced in the first plugin,
> whose classes could not be resolved, the standard dot-library to a named
> one ("gaga.jar") - and it worked for this guy!
>
> Could anyone explain to me this phenomenon, please???
>
> Since *years* we are using the recommended jar'ed plugin packaging
> style including the also recommended dot(.) reference name and
> could live without any problems. Nearly all of our plugins
> contain thirdparty-library code as inner jars - no problem with
> the osgi runtime at all.
>
> Now it was the first time that I tried to *reuse* an already build
> product as part of the base-location (additional to the Eclipse
> plugins and features) and must now recognize the follwing:
>
> 1) Inner jars in jar'ed plugins are not resolved. Workaround: Use
> unpacked plugins.
> 2) The standard dot-naming of the plugin library also causes that
> dependent plugins cannot resolve these names. Workaround: Use an
> arbitrary named plugin library name.
>
> Can this really be true???
>
> Thanks for any help,
>
> Daniel
>
>
|
|
|
| Re: headless (feature) build obscurities [message #331876 is a reply to message #331872] |
Fri, 26 September 2008 07:04 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Andrew Niefer wrote:
> The only thing that comes to mind is, are your Bundle-Classpath entries
> in the manifests correct?
>
> If no Bundle-Classpath is specified, then the default value is '.'
> But if you've changed things and added entries to the Bundle-Classpath
> and didn't add '.' as well, then root of the bundle will not be
> considered for the classpath.
Thanks for your help, Andrew! I'm 100% sure that our bundle-classpath
entries are correct. They originally (that is, before I changed to the
named jar version) used the recommended ("canonical") style:
Bundle-ClassPath: .,
a.jar,
b.jar,
c.jar,
d.jar
where a.jar-d.jar are the hosted third-party libraries. I also ensured
that the "Export-Package:" section properly exported all public
available packages of . and of the jars. These kinds of plugins were
originally deployed in the recommended "packed" form as part of our
product-build.
As explained in the related thread, the fact that a.jar-d.jar were
effectively inner jars of the finally build plugin caused the very
first build problem, when these plugins were used as new 'target'
files in a build step of a depending feature.
After recognizing this part of the problem, the first workaround
was to modify *only* the feature of the primary product-build,
changing all unpack=false entries to unpack=true. This still lead
to no success and I could - up to now - only succeed by modifying
nearly all plugins of the primary product to use the "named"
library approach, that is I changed to
Bundle-ClassPath: some_hopefully_unique_name.jar,
a.jar,
b.jar,
c.jar,
d.jar
including corresponding changes in the build.properties file of these
plugins (Replacing "source.." and "output..", resp. by
"source.some_hopefully_unique_name.jar" and
"output.some_hopefully_unique_name.jar", resp.)
Any ideas why this needs to be done or whether another less intrusive
workaround exists?
This second workaround makes the whole thing *really* bad, because it
seems that I'm now supposed to modify 20+ plugins, which are actually
stable implementations and part of an already released product. This
only, because of the limitations of the *pde-build-process*, *not* of
the osgi-runtime.
Thanks again,
Daniel
> Daniel Krügler wrote:
>> Andrew Niefer wrote:
>>> Daniel,
>>> When it comes right down to compile time, we are simply compiling
>>> java code. If it helps, take a look at the generated build.xml files
>>> for your bundles and see the javac ant task and the classpath it is
>>> using.
>>>
>>> Fundamentally, the issue is that the java compiler does not support
>>> nested jars on the classpath. Something like
>>> C:/eclipse/plugins/org.eclipse.foo_1.0.0.jar/library.jar
>>> is not a valid classpath entry.
>>>
>>> However, folders are valid entries, the compiler expects the package
>>> folders and class files to be on disk immediately under that folder.
>>> This means that yes, plugins in folder shape with '.' as a
>>> Bundle-Classpath should work, ie:
>>> C:/eclipse/plugins/org.foo_1.0.0/org/foo/bar.class
>>> /org/foo/internal/zot.class
>>>
>>> If things are not compiling, I can only suggest looking at the
>>> generated build.xml and the classpath that is being used to see if it
>>> contains what you expect.
>>>
>>> -Andrew
>>
>> Thanks for your interest, Andrew! I spend the complete day understanding
>> this problem. I could not see anything suspicious in the build.xml.
>> Finally I decided to try something out: I replaced in the first
>> plugin, whose classes could not be resolved, the standard dot-library
>> to a named one ("gaga.jar") - and it worked for this guy!
>>
>> Could anyone explain to me this phenomenon, please???
>>
>> Since *years* we are using the recommended jar'ed plugin packaging
>> style including the also recommended dot(.) reference name and
>> could live without any problems. Nearly all of our plugins
>> contain thirdparty-library code as inner jars - no problem with
>> the osgi runtime at all.
>>
>> Now it was the first time that I tried to *reuse* an already build
>> product as part of the base-location (additional to the Eclipse
>> plugins and features) and must now recognize the follwing:
>>
>> 1) Inner jars in jar'ed plugins are not resolved. Workaround: Use
>> unpacked plugins.
>> 2) The standard dot-naming of the plugin library also causes that
>> dependent plugins cannot resolve these names. Workaround: Use an
>> arbitrary named plugin library name.
>>
>> Can this really be true???
>>
>> Thanks for any help,
>>
>> Daniel
>>
>>
|
|
| |
| Re: headless (feature) build obscurities [message #331916 is a reply to message #331894] |
Mon, 29 September 2008 10:39 |
Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
Andrew Niefer wrote:
> Daniel Krügler wrote:
>> Thanks for your interest, Andrew! I spend the complete day understanding
>> this problem. I could not see anything suspicious in the build.xml.
>> Finally I decided to try something out: I replaced in the first
>> plugin, whose classes could not be resolved, the standard dot-library
>> to a named one ("gaga.jar") - and it worked for this guy!
>
>
>> 2) The standard dot-naming of the plugin library also causes that
>> dependent plugins cannot resolve these names. Workaround: Use an
>> arbitrary named plugin library name.
>>
>> Can this really be true???
>
>
> Daniel,
> I did not believe that it should be necessary be necessary to replace
> the . with a library when the bundle is folder shaped. So I made a
> small example which did fail to compile.
>
> Looking at the build.xml for the plug-in that depends on the folder
> shaped bundle and is failing to compile, we see something like this:
> <path id="@dot.classpath">
> <pathelement path="../plugins/A_1.0.0/@dot"/>
> <pathelement path="../plugins/A_1.0.0/library.jar"/>
> <pathelement path="../plugins/org.eclipse.osgi_3.5.0.v20080922.jar"/>
> </path>
>
> The problem is that the first classpath entry should be
> <pathelement path="../plugins/A_1.0.0"/>
>
> I have raised bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=248767.
>
> When you said you did not see anything wrong with the build.xml, I took
> that to imply the classpath was ok. So I did not really have any idea
> why it wouldn't work for you.
I apologize for this misunderstanding. For me the "path"
<pathelement path="../plugins/A_1.0.0/@dot"/>
it looked ok, because my assumption was that @dot gets a special
interpretation, which would finally end up in
<pathelement path="../plugins/A_1.0.0"/>
Thanks for looking into it,
Daniel
|
|
|
Goto Forum:
Current Time: Sat Aug 17 06:17:26 GMT 2024
Powered by FUDForum. Page generated in 0.03629 seconds |
] 
Search
Help
Register
Login
Home
