Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313403

Summary:

consider unsetting baselocation

Product:

[Tools] Orbit

Reporter:

David Williams <david_williams>

Component:

releng

Assignee:

Project Inbox <orbit.releng-inbox>

Status:

RESOLVED WONTFIX

QA Contact:

Project Inbox <orbit.releng-inbox>

Severity:

normal

Priority:

CC:

aniefer, dj.houghton

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
test build output showing unresolved imports, etc.,	none

Description David Williams

2010-05-18 13:24:52 EDT

recently, some "wrong" bundles were picked up from "base builder" install, due to a combination of errors. 

While debugging that, it was observed we probably do not need to set baselocation in our scripts, since we are not compiling against the eclipse platform. 

It might be good to "fix" this, to allow less interaction between our builds, and exact version of basebuilder used. 

But, 1) if we so pick up something from basebuilder, something else is probably wrong, and 2) I'd want to do a careful "before and after" to make sure nothing (else) changes.

Comment 1 David Williams

2011-01-20 00:21:19 EST

So ... if we do this ... where to the bundles go? In our 'fetch' task, we use baseLocation ... 

<eclipse.fetch
            elements="feature@${featureToBuild}"
            buildDirectory="${buildDirectory}"
            directory="${buildDirectory}/directory.txt"
            configInfo="${configs}"
            baseLocation="${baseLocation}"
            recursiveGeneration="false"
            children="false"/>

So do you mean we do not need it at all? Or that it needs to point somewhere besides the 'eclipse' directory of the baseBuilder?

Comment 2 David Williams

2011-01-21 18:39:07 EST

Created attachment 187346 [details]
test build output showing unresolved imports, etc.,

I tried a test build (on my local machine) just leaving base.location unspecified, but there were errors that prevented the pde build from working, as attached. 

I think some of the "Missing ..." message would not be fatal, but did seem to be some in the end: 

Bundle 
org.mortbay.jetty_5.1.11.v200806031610 failed to resolve.:
[orbit-set1] 	Unsatisfied import package javax.net.ssl_0.0.0.
[orbit-set1] 	Unsatisfied import package javax.security.cert_0.0.0.


So, not sure if there's some setting to change ... some other way to specify base.location ... or, if maybe to make this change would just take too much work, and should be closed as "won't fix"?

Comment 3 DJ Houghton

2011-01-24 13:45:58 EST

Adding Andrew to the CC list in case he can provide insight.

Comment 4 David Williams

2011-01-30 15:57:47 EST

I'm marking as "won't fix" for now. If Andrew (or anyone) has any insights to make this feasible, please reopen. 

My thought is that even though "we are not compiling against the eclipse
platform" we do _resolve_ against the eclipse platform. While we would never need the whole platform (probably) we probably would always need some portion of an OSGi platform (for example, some of our 3rd party bundles have "require system bundle" added to their manifest.mf files). 

So, I'm sure there are ways to lesson the chance of conflict with existing bundles in the eclipse platform, but I suspect it is more work than its worth, since doesn't come up very often. 

Thanks,