Ed,
El 06/05/2011 11:01, Ed Willink escribió:
Hi Adolfo
We're after the M7 feature freeze, so it's too late to start
breaking up core/examples features. For Juno, if the examples are
promoted to non-examples, we then need a separate tools build and
clear core/tools test partitioning.
I adjusted the 'pivot' examples plugins to:
- inherit as many dependencies as possible via required bundles
- specify no Eclipse Platform range
- specify typically 2.5 to 3.0 for EMF
- specify 3.0 to 4.0 for UML
- specify 2.0 to 3.0 for Xtext
I don't want to break anything, setting the proper maximum version
range of a plugin dependency which only sets the minimum range
doesn't break anything. If your plugins don't suffer of this, good
;). I'll ensure that other examples plugins don't suffer this
problem, neither. BTW, I was talking about splitting the tests
feature rather than the examples feature itself...
Since Xtext 2.0 runs on Helios, this gives users a chance of
installing the examples editors on Helios too. Not supported, but
might work.
If your editors depended on OCL core stuff, which depends on EMF 2.7
stuff, I don't think that they might work in a pure Helios
installation... actually they couldn't even be installed, could they
?.
P.S: Giving that you prefer I postpone the core/tools jobs
experiments, I'll simply commit the stuff as long as it doesn't
impact the current stuff, for instance, the new build features.
Best Regards,
Adolfo.
Ed
On 06/05/2011 10:43, Adolfo Sánchez-Barbudo Herrera wrote:
Ed,
Adolfo: you might progress relengs, in particular
335459 - plugin dependencies RESOLVED
Concerning this bug. I think that there are discussions still
open:
- Are we providing any backwards compatibility? In principle,
since we are depending on EMF 2.7 stuff, MDT/OCL 3.1.0 can't be
executed in any Helios installation. I guess that the official
answer to this question is "No, we don't provide any backwards
compatibility"
- What do we want to do with our plugin dependencies version
ranges ? I guess that being close to RC1, changing plugin
dependencies is not an option. Perhaps, we could just fix those
plugins (from examples, if there is still any) which only set a
minimum version range so that they also set the maximum version
range. I'll have a look to this...
340758 - plugin dependencies RESOLVED
I'd also like to do some tries to core and tools jobs during
some next week days... If I can't find any stable stuff before
wednesday I'll revert the core job's configuration to use the
current stuff. In principle, I'll commit two new build features:
- org.eclipse.ocl.releng.core.build-feature
- org.eclipse.ocl.releng.tools.build-feature
On the other hand we would need some any extras for the tests.
We would require to split the tests between core and examples
tests
Best,
Regards.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found
in this message.
Checked by AVG - www.avg.com
Version: 10.0.1325 / Virus Database: 1500/3618 - Release Date:
05/05/11
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
