[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] M6 in danger
- From: Eike Stepper <stepper@xxxxxxxxxx>
- Date: Wed, 12 Mar 2014 07:50:39 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
I just found the cause of the problem and could work around it. Please expect my M6 build early today. Because of the
API breakage in EMF Compare it might be necessary to coordinate my contribution with Laurent. I already pinged him
The original problem is very odd, though, and my work-around is not a permanent solution. Here's the short summary:
Buckminster is always one release behind ;-(
For example when we build for Luna there's only a Kepler Buckminster available and that "works best" with a Kepler
That would still be acceptable but:
A) Our build also uses two self-made tools for extended version management and API report generation. These tools are
installed from our own integration p2 repository which was built previously against Luna.
B) This (our) p2 repo also contains a p2 feature. Not that I'm happy about that, but we build p2-based products and with
a feature-based product build I see no way to exclude these dependencies from our own repo.
In effect my Buckminster installation "sees" p2 in three different locations:
1) The Buckminster headless repo (4.3)
2) The Platform repo (must be 4.3, because there's no Bucky 4.4)
3) Our own repo (here we have a p2 4.4!!!)
My current work-around is to disable all our own tools during the build (and not install them), so that the Buckminster
installation can use only Kepler repos.
I'm not sure if anyone could follow til here but I see two options for the future:
1) I continue NOT to use my own tools in my build (although Ed and I have spent weeks to develop them).
2) Buckminster starts to produce builds for the CURRENT release train (whether contributed to it or not).
Needless to say that I favor option 2, but maybe someone else sees more options?
Am 11.03.2014 20:00, schrieb Eike Stepper:
Our Buckminster-based build keeps failing with varying errors that all seem to be caused by mismatches between/within
Buckminster and p2. And maybe because the http://download.eclipse.org/tools/buckminster/headless-4.3 repo contains old
versions of p2. But this is all guessing. In the end I have no clue what's going on.
Here's a new error that seems to indicate a problem between different parts of p2 (publisher and core):
[java] Caused by: java.lang.NoSuchMethodError:
[java] at org.eclipse.equinox.p2.publisher.AdviceFileAdvice.loadAdviceMap(AdviceFileAdvice.java:118)
[java] at org.eclipse.equinox.p2.publisher.AdviceFileAdvice.<init>(AdviceFileAdvice.java:71)
[java] at org.eclipse.equinox.p2.publisher.eclipse.FeaturesAction.createAdviceFileAdvice(FeaturesAction.java:166)
[java] at org.eclipse.equinox.p2.publisher.eclipse.FeaturesAction.generateFeatureIUs(FeaturesAction.java:407)
[java] at org.eclipse.buckminster.pde.tasks.FeaturesAction.generateFeatureIUs(FeaturesAction.java:274)
I can't spend more time on this tonight. I'm aware that EMF Compare seems to push me to contribute an M6 that uses their
new APIs. But at this point I can not guarantee that my M5 will be replaced tomorrow.
All ideas are welcome!