Community
Participate
Working Groups
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.
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?
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"?
Adding Andrew to the CC list in case he can provide insight.
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,
