Eclipse Community Forums: Buckminster » Target platform materialization

Home » Archived » Buckminster » Target platform materialization

Target platform materialization [message #658397]

Tue, 08 March 2011 06:13

Eclipse User

I'm trying to materialize a target platform during a buckminster build using p2 from the official Eclipse update sites.

For that I created the needed files: .mspec, .rmap and .cquery

Basically there are two issues:
- platform specific fragments are not fetched into the target platform, e.g. swt win32 bundles, this leads to compile errors later on
- features are not fetched into the target platform, the features in the target paltform are referenced as requirements of the feature that I want to build with buckminster, this also leads to errors later on the build

Things I already tried are:
- Setting an explicit target platform location: setpreference targetPlatformPath=${user.dir}/tp
- Various settings for the target.* properties

Are there any known issues with the p2 materializer? Is this the intended behaviour of the p2 materializer?

Re: Target platform materialization [message #658404 is a reply to message #658397]

Tue, 08 March 2011 06:21

Eclipse User

On 2011-03-08 12:14, Christian K. wrote:
> I'm trying to materialize a target platform during a buckminster build using p2 from the official Eclipse update sites.
>
> For that I created the needed files: .mspec, .rmap and .cquery
>
> Basically there are two issues:
> - platform specific fragments are not fetched into the target platform, e.g. swt win32 bundles, this leads to compile
> errors later on

You should try adding:

target.os=*
target.ws=*
target.arch=*

to your CQUERY. Or alternatively pass them in as system properties.

> - features are not fetched into the target platform, the features in the target paltform are referenced as requirements
> of the feature that I want to build with buckminster, this also leads to errors later on the build
>
Feature requirements are not generated as Buckminster dependencies. Only feature includes. So either try that, or
complement your feature with a buckminster.cspex where the requirements are listed as dependencies.

> Things I already tried are:
> - Setting an explicit target platform location: setpreference targetPlatformPath=${user.dir}/tp

That is always a good idea since it keeps your TP separate from your runtime.

> - Various settings for the target.* properties
>
> Are there any known issues with the p2 materializer? Is this the intended behaviour of the p2 materializer?

Try what I just described and see if that solves your problems. No software is perfect but there are no known issues in
the p2 materializer that would give the symptoms that you describe here.

HTH,
- thomas

Re: Target platform materialization [message #658417 is a reply to message #658397]

Tue, 08 March 2011 08:04

Eclipse User

I tried creating a buckminster.cspex for my feature that is referencing the target platform features. This results in errors that the feature/component cannot be resolved anymore at all. Further investigation shows that there are problems with parsing the .cspex file:
Problem during meta-data refresh: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element <dependency> encountered in tag <alterDependencies>: file:///.../core/features/org.ecli pse.sphinx.sdk-feature/buckminster.cspex at line: 22 column: 76
org.eclipse.core.runtime.CoreException: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element <dependency> encountered in tag <alterDependencies>: file:///.../core/features/org.ecli pse.sphinx.sdk-feature/buckminster.cspex at line: 22 column: 76
at org.eclipse.buckminster.runtime.BuckminsterException.fromMes sage(BuckminsterException.java:57)
at org.eclipse.buckminster.runtime.BuckminsterException.wrap(Bu ckminsterException.java:123)
at org.eclipse.buckminster.core.parser.AbstractParser.parseInpu t(AbstractParser.java:240)
at org.eclipse.buckminster.core.cspecext.parser.AlterCSpecParse r.parse(AlterCSpecParser.java:42)
at org.eclipse.buckminster.core.cspecext.parser.AlterCSpecParse r.parse(AlterCSpecParser.java:1)
at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder $1.consumeStream(AbstractResolutionBuilder.java:116)
at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder $1.consumeStream(AbstractResolutionBuilder.java:1)
at org.eclipse.buckminster.core.reader.URLCatalogReader.innerRe adFile(URLCatalogReader.java:188)
at org.eclipse.buckminster.core.reader.AbstractCatalogReader.re adFile(AbstractCatalogReader.java:161)
at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder .applyExtensions(AbstractResolutionBuilder.java:108)
at org.eclipse.buckminster.pde.cspecgen.PDEBuilder.build(PDEBui lder.java:73)
at org.eclipse.buckminster.core.ctype.AbstractComponentType.get Resolution(AbstractComponentType.java:316)
at org.eclipse.buckminster.core.ctype.AbstractComponentType.get Resolution(AbstractComponentType.java:201)
at org.eclipse.buckminster.core.resolver.LocalResolver.fromPath (LocalResolver.java:164)
at org.eclipse.buckminster.core.resolver.LocalResolver.fromPath (LocalResolver.java:185)
at org.eclipse.buckminster.core.metadata.MetadataSynchronizer.r efreshProject(MetadataSynchronizer.java:295)
at org.eclipse.buckminster.core.metadata.MetadataSynchronizer.w orkspaceCatchUp(MetadataSynchronizer.java:394)
at org.eclipse.buckminster.core.metadata.MetadataSynchronizer$W orkspaceCatchUpJob.run(MetadataSynchronizer.java:185)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element <dependency> encountered in tag <alterDependencies>
at org.eclipse.buckminster.sax.ChildHandler.createHandler(Child Handler.java:56)
at org.eclipse.buckminster.core.cspecext.parser.AlterDependenci esHandler.createHandler(AlterDependenciesHandler.java:50)
at org.eclipse.buckminster.sax.ChildHandler.startElement(ChildH andler.java:154)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocume ntParser.emptyElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidato r.emptyElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScanner Impl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScanner Impl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown Source)
at org.eclipse.buckminster.core.parser.AbstractParser.parseInpu t(AbstractParser.java:237)
... 16 more

It seems like that the XSD wants a "dependency" element inside the "alterDepencies" element but the parser expects an "component" element. At least that's what it looks like in the code at:
AlterDependenciesHandler.java:50
There the element name is compared against ComponentRequestHandler.TAG=ComponentRequest.TAG="component "

There is also another question: Will the platform specific bundles be resolved once the feature references are fixed?

[Updated on: Tue, 08 March 2011 08:05] by Moderator

Re: Target platform materialization [message #658420 is a reply to message #658397]

Tue, 08 March 2011 08:19

Eclipse User

BTW, thanks for your quick reply. I am currently so deep in these releng things that I forgot to mention that.

Another thing that I'm wondering about is what will happen once the feature depencies are fixed. Will this result in the situation that these features will also show up in the resulting update site? To me it looks like that the cspec is not able to distinguish between requirements and inclusions as it is possible inside a feature.xml. This would be my preferred method to control what wil be part of the resulting update site.

Re: Target platform materialization [message #658424 is a reply to message #658417]

Tue, 08 March 2011 08:36

Eclipse User

You're not supposed to alter any existent dependency. Just use a normal <dependencies> element to add more dependencies
and not <alterDependencies>.

- thomas

On 2011-03-08 14:04, Christian K. wrote:
> I tried creating a buckminster.cspex for my feature that is referencing the target platform features. This results in
> errors that the feature/component cannot be resolved anymore at all. Further investigation shows that there are problems
> with parsing the .cspex file:
> Problem during meta-data refresh: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element
> <dependency> encountered in tag <alterDependencies>:
> file:///M:/CK_Projekte/artop-sphinx-2/core/features/org.ecli pse.sphinx.sdk-feature/buckminster.cspex at line: 22 column: 76
> org.eclipse.core.runtime.CoreException: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element
> <dependency> encountered in tag <alterDependencies>:
> file:///M:/CK_Projekte/artop-sphinx-2/core/features/org.ecli pse.sphinx.sdk-feature/buckminster.cspex at line: 22 column: 76
> at org.eclipse.buckminster.runtime.BuckminsterException.fromMes sage(BuckminsterException.java:57)
> at org.eclipse.buckminster.runtime.BuckminsterException.wrap(Bu ckminsterException.java:123)
> at org.eclipse.buckminster.core.parser.AbstractParser.parseInpu t(AbstractParser.java:240)
> at org.eclipse.buckminster.core.cspecext.parser.AlterCSpecParse r.parse(AlterCSpecParser.java:42)
> at org.eclipse.buckminster.core.cspecext.parser.AlterCSpecParse r.parse(AlterCSpecParser.java:1)
> at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder $1.consumeStream(AbstractResolutionBuilder.java:116)
> at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder $1.consumeStream(AbstractResolutionBuilder.java:1)
> at org.eclipse.buckminster.core.reader.URLCatalogReader.innerRe adFile(URLCatalogReader.java:188)
> at org.eclipse.buckminster.core.reader.AbstractCatalogReader.re adFile(AbstractCatalogReader.java:161)
> at org.eclipse.buckminster.core.cspec.AbstractResolutionBuilder .applyExtensions(AbstractResolutionBuilder.java:108)
> at org.eclipse.buckminster.pde.cspecgen.PDEBuilder.build(PDEBui lder.java:73)
> at org.eclipse.buckminster.core.ctype.AbstractComponentType.get Resolution(AbstractComponentType.java:316)
> at org.eclipse.buckminster.core.ctype.AbstractComponentType.get Resolution(AbstractComponentType.java:201)
> at org.eclipse.buckminster.core.resolver.LocalResolver.fromPath (LocalResolver.java:164)
> at org.eclipse.buckminster.core.resolver.LocalResolver.fromPath (LocalResolver.java:185)
> at org.eclipse.buckminster.core.metadata.MetadataSynchronizer.r efreshProject(MetadataSynchronizer.java:295)
> at org.eclipse.buckminster.core.metadata.MetadataSynchronizer.w orkspaceCatchUp(MetadataSynchronizer.java:394)
> at org.eclipse.buckminster.core.metadata.MetadataSynchronizer$W orkspaceCatchUpJob.run(MetadataSynchronizer.java:185)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.eclipse.buckminster.sax.UnrecognizedElementException: Unrecognized element <dependency> encountered in
> tag <alterDependencies>
> at org.eclipse.buckminster.sax.ChildHandler.createHandler(Child Handler.java:56)
> at org.eclipse.buckminster.core.cspecext.parser.AlterDependenci esHandler.createHandler(AlterDependenciesHandler.java:50)
> at org.eclipse.buckminster.sax.ChildHandler.startElement(ChildH andler.java:154)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocume ntParser.emptyElement(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidato r.emptyElement(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScanner Impl.scanStartElement(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScanner Impl.next(Unknown Source)
> at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown Source)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown Source)
> at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown Source)
> at org.eclipse.buckminster.core.parser.AbstractParser.parseInpu t(AbstractParser.java:237)
> ... 16 more
>
> It seems like that the XSD wants a "dependency" element inside the "alterDepencies" element but the parser expects an
> "component" element. At least that's what it looks like in the code at:
> AlterDependenciesHandler.java:50
> There the element name is compared against ComponentRequestHandler.TAG=ComponentRequest.TAG="component "
>
> There is also another question: Will the platform specific bundles be resolved once the feature references are fixed?

Re: Target platform materialization [message #658425 is a reply to message #658420]

Tue, 08 March 2011 08:38

Eclipse User

On 2011-03-08 14:19, Christian K. wrote:
> BTW, thanks for your quick reply. I am currently so deep in these releng things that I forgot to mention that.
>
> Another thing that I'm wondering about is what will happen once the feature depencies are fixed. Will this result in the
> situation that these features will also show up in the resulting update site?

No. If you want them to show up, you need to include the dependencies.

> To me it looks like that the cspec is not
> able to distinguish between requirements and inclusions as it is possible inside a feature.xml. This would be my
> preferred method to control what wil be part of the resulting update site.

Another way is to have a specific feature that actually describes the site. Such a feature will normally not be part of
the site in itself.

- thomas

Re: Target platform materialization [message #658478 is a reply to message #658397]

Tue, 08 March 2011 11:35

Eclipse User

Ok, so now Buckminster is actually looking for the platform specific bundles and fragments, but somehow it says "No component match was found" even though the update site contains the respective bundle.

For example the bundle "org.eclipse.core.filesystem.hpux.ia64_32" cannot be found in http://download.eclipse.org/releases/galileo.

Here's the corresponding rmap snippet:

<searchPath name="target.platform">
<provider componentTypes="eclipse.feature,osgi.bundle" readerType="p2" source="false" mutable="false">
<uri format="http://download.eclipse.org/releases/galileo"/>
</provider>
<provider componentTypes="osgi.bundle" readerType="p2" source="false" mutable="false">
<uri format=" http://download.eclipse.org/tools/orbit/downloads/drops/R201 00519200754/repository"/>
</provider>
<provider componentTypes="eclipse.feature,osgi.bundle" readerType="eclipse.import" source="false" mutable="false">
<uri format=" http://download.eclipse.org/releases/galileo?importType=bina ry"/>
</provider>
</searchPath>

Re: Target platform materialization [message #658492 is a reply to message #658397]

Tue, 08 March 2011 12:57

Eclipse User

Ok, it seems like a reference to just:
http://download.eclipse.org/releases/galileo

is not sufficient, you also need to create a p2 provider that points to:
http://download.eclipse.org/eclipse/updates/3.5/

[Updated on: Tue, 15 March 2011 07:17] by Moderator

Re: Target platform materialization [message #658698 is a reply to message #658397]

Wed, 09 March 2011 08:59

Eclipse User

One more note regarding my previous problem:
When you want to build against a Galileo target platform, which is probably pretty rare these days it might also be necessary to reference an older Orbit repository:
http://download.eclipse.org/tools/orbit/downloads/drops/R200 90529135407/updateSite
(Make sure you are getting the different suffix /updateSite instead of /repository)

Related to the field target platform materialization, after I was actually able to accomplish that, I now have another question:
For us target platform download/materialization/resolution is quite "expensive" and the target platform rarely changes. Therefore it might make sense to just re-use a target platform that has been created earlier and that still exists on the local file system. Is there a best practice how this can be done?

I already tried to setup resolutionFilter's on the respective providers in the rmap, but this isn't really working. This results in "Attempt to use an unresolved node" errors. I've tried this in combination with "setpreference targetPlatformPath=${user.dir}/tp".

[Updated on: Wed, 09 March 2011 09:04] by Moderator

Re: Target platform materialization [message #658750 is a reply to message #658397]

Wed, 09 March 2011 11:43

Eclipse User

The "Attempt to use an unresolved node" errors are actually caused by an inconsistent source feature reference in the GMF Galileo version (org.eclipse.gmf.runtime.thirdparty.source).

If I revert to using just the runtime version of GMF (not SDK) without sources, then the errors don't occur anymore.

This also means that for us the conditional target platform materialization based on resolutionFilter's works.

Re: Target platform materialization [message #659729 is a reply to message #658397]

Tue, 15 March 2011 07:29

Eclipse User

We now setup a job on the Eclipse Hudson instance for our build. Unfortunately when running the build on the Eclipse Hudson instance an StackOverflowError occurs during import. See https://hudson.eclipse.org/hudson/job/buckminster-sphinx-0.7 -helios/28/console for details.

I cannot reproduce the StackOverflowError when running the build on my local machine.

Also I'm not able to show more details about the StackOverflowError. I already tried using --loglevel debug and --displaystacktraces but neither the console output nor the workspace log will show a stacktrace.

Re: Target platform materialization [message #659730 is a reply to message #659729]

Tue, 15 March 2011 07:35

Eclipse User

My guess would be that you have some kind of circular dependencies. Buckminster should normally trap that though, so I'm
not sure. But it's something to check for.

- thomas

On 2011-03-15 12:29, Christian K. wrote:
> We now setup a job on the Eclipse Hudson instance for our build. Unfortunately when running the build on the Eclipse
> Hudson instance an StackOverflowError occurs during import. See
> https://hudson.eclipse.org/hudson/job/buckminster-sphinx-0.7 -helios/28/console for details.
>
> I cannot reproduce the StackOverflowError when running the build on my local machine.
>
> Also I'm not able to show more details about the StackOverflowError. I already tried using --loglevel debug and
> --displaystacktraces but neither the console output nor the workspace log will show a stacktrace.

Re: Target platform materialization [message #659741 is a reply to message #658397]

Tue, 15 March 2011 09:04

Eclipse User

Do you have any suggestions on how I could check if there are circular dependencies? Our target paltform is quite large and checking this manually would be a major effort.

Additionally I think a circular dependency problem is unlikely since this should also be reproducable on my local machine.

Also another quation do you a suggestion how I could print the stack trace for the StackOverflowError?

Re: Target platform materialization [message #660062 is a reply to message #658397]

Wed, 16 March 2011 13:38

Eclipse User

I was just able to obtain a stack trace of the StackOverflowError by doing a remote debug of the build:
[java] java.lang.StackOverflowError
[java] at java.util.HashMap.get(HashMap.java:300)
[java] at org.eclipse.buckminster.core.helpers.MapUnion.get(MapUnion.j ava:211)
[java] at org.eclipse.buckminster.core.helpers.MapUnion.get(MapUnion.j ava:201)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:304)
[java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:175)
[java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:161)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.checkedExpand(ExpandingProperties.java:144)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.expand(ExpandingProperties.java:91)
[java] at org.eclipse.buckminster.core.common.model.Constant.checkedGe tValue(Constant.java:70)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:305)
[java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:175)
[java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:161)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.checkedExpand(ExpandingProperties.java:144)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.expand(ExpandingProperties.java:91)
[java] at org.eclipse.buckminster.core.common.model.Constant.checkedGe tValue(Constant.java:70)
[java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:305)

Now it will be interesting to further investigate what is causing this.

Re: Target platform materialization [message #660076 is a reply to message #660062]

Wed, 16 March 2011 14:04

Eclipse User

Looks like you have a property expansion construct (i.e. a ${some.property}) that when expanded somehow expands to a
string containing the same property expansion.

- thomas

On 2011-03-16 18:38, Christian K. wrote:
> I was just able to obtain a stack trace of the StackOverflowError by doing a remote debug of the build:
> [java] java.lang.StackOverflowError
> [java] at java.util.HashMap.get(HashMap.java:300)
> [java] at org.eclipse.buckminster.core.helpers.MapUnion.get(MapUnion.j ava:211)
> [java] at org.eclipse.buckminster.core.helpers.MapUnion.get(MapUnion.j ava:201)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:304)
> [java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:175)
> [java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:161)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.checkedExpand(ExpandingProperties.java:144)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.expand(ExpandingProperties.java:91)
> [java] at org.eclipse.buckminster.core.common.model.Constant.checkedGe tValue(Constant.java:70)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:305)
> [java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:175)
> [java] at org.eclipse.buckminster.core.helpers.UnmodifiableMapUnion.ge t(UnmodifiableMapUnion.java:161)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.checkedExpand(ExpandingProperties.java:144)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.expand(ExpandingProperties.java:91)
> [java] at org.eclipse.buckminster.core.common.model.Constant.checkedGe tValue(Constant.java:70)
> [java] at org.eclipse.buckminster.core.common.model.ExpandingPropertie s.get(ExpandingProperties.java:305)
>
>
>
> Now it will be interesting to further investigate what is causing this.

Re: Target platform materialization [message #660082 is a reply to message #658397]

Wed, 16 March 2011 14:23

Eclipse User

Ok, I also arrived at your conclusion Thomas. The problem was caused by the following entry in our build.xml that invokes buckminster headless:
<sysproperty key="svn.password" value="${svn.password}"/>

The password is not set on the Eclipse Hudson instance but it is set on my local machine. That also explains why this couldn't be reproduced locally.

Previous Topic:	Annotation generated files not included with site.p2 however they are included in bundle.jar
Next Topic:	EclipseCon 2011 talks, BoF?

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 20 08:03:55 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter