Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Obscure org.eclipse.platform dependencies? Where are they?

Dunno about buckminster and rmaps etc but the feature that includes the SWT fragments uses platform filters.  So we could have all manner of fragments referenced from the feature and those implementations may or may not exist.  That fact is only relevant if you are trying to build/assemble some configuration for that platform.  So perhaps Buckminster is complaining about a problem that is/should not really be a problem?

Jeff

On 2010-11-18, at 8:08 PM, Miles Parker wrote:


Hi guys,

Whew, thanks to both of you for your responses. While the explanation itself is opaque to me -- why does platform have a dependency that isn't supported, or if it doesn't where did it sneak in from? ;-) I made the change that Paul suggested and it worked. I had copied the milestone reference for Eclipse from "another project" which just goes to show the perils and pitfalls of trying to assemble a working build from a set of other attempts.

In general, we have *got* to come up with ways to make these things more transparent/consistent/maintainable if nothing else for the benefit of others who haven't faced the trauma yet so they don't have to go through every possible failure mode too. One thought is to have some common shared rmap redirects for builds. We could have one for Helios baseline, Indigo, Modeling, Modeling + XText. etc.. In fact, we could even think about projects maintaining consumer rmaps in the same way that we now maintain our update sites and build rmaps. For example, I'd love to be able to just do a redirect to Indigo M2T/TMF/MWE and not have to worry about changes that might happen when a build dependency or update site location changes. I *don't* want to copy their rmap because I'm looking for a somewhat more stable (say I rather than N) build and I don't need their 

One issue with this is that you have to specify the pattern for the redirects and there is no failure pass through. This means that you couldn't combine rmaps that have the same search patterns to create a sort of catch all and this would prevent consumer rmap providers from dealing with special cases such as TMF's use of com.google.. Thomas, has the Buckminster team thought about supporting some kind of "includes" style functionality?

-Miles

On Nov 17, 2010, at 11:21 PM, Thomas Hallgren wrote:

Hi Miles, Paul,

IIRC, swt.photon.qnx.x86 isn't one of the platforms that Helios currently supports. This means the needed fragments are missing in the Helios meta-data. In order for Buckminster to find them you will need to include the http://download.eclipse.org/eclipse/updates/3.6 site explicitly in your rmap.

HTH,
Thomas Hallgren

On 11/18/2010 02:04 AM, Paul Webster wrote:
That bundle is in the 3.6 composite update site (which should be available from the helios repo)

http://download.eclipse.org/eclipse/updates/3.6
- R-3.6.1-201009090800/plugins/org.eclipse.swt.photon.qnx.x86_3.6.1.v3655c.jar



I notice you're going from helios to a milestone site which won't have the final version in it:
/home/data/httpd/download.eclipse.org/eclipse/updates/3.6milestones


--
Paul Webster
Hi floor.  Make me a sammich! - GIR
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top