Hi David
Ironically, the new currently example quality, MDT/OCL code does
eliminate the tight dependencies and satisfies Ed Merks maxim; "do
not extend Ecore" which should be extended to UML as well.
However we must preserve our traditional functionality until we can
call it legacy.
We plan to commit a dependency change to [4,5) shortly that should
allow other downstream projects to build, provided that they too
change to UML [4,5). This should be available perhaps within 12
hours if Hudson and other factors are co-operative.
Changing to [3,5) works for builds, but is unhelpful for users. UML2
4.0.0 is an incompatible release since it supports a different
specification, which is significant for the tight OCL coupling.
We will be disabling API checking for the UML-dependent plugins, and
contributing code that does not pass all our JUnit tests; perhaps
because the UML2 project has not yet provided migration facilities
for old UML files. We may at least get our own code consistent in an
M2'b' contribution by +1..
If you agree that a major version change is necessary and better
sooner, we will endeavour to make that available tomorrow in an
M2'a' contribution. Since many adopters must react to the UML
change, it is probably easier for them to react to the knock on OCL
change too; they may also have to go for major increments.
Projects using MDT/OCL are advised to increase the upper bound to
5.0.0) for M2. They may defer raising the lower bound to 4.0.0 until
M3, if they want to avoid recontributing to M2 when MDT/OCL changes
to 4.0. (NB EMF has platform 3.8 dependencies, so there is no point
in hoping for joint Indigo/Juno builds.)
Regards
Ed Willink
On 22/09/2011 18:52, David M Williams wrote:
> Is it best to have all this pain now for M2 or defer some
more pain
till M3?
This mostly depends on your
adopters
... but, I'd say the earlier the better? probably?
I'm not sure I understand all the
issues
.... but in essence, are you saying the current failure,
Missing requirement:
org.eclipse.ocl.edit.feature.group
3.1.0.v20110815-1500 requires 'org.eclipse.uml2.uml.edit
[3.0.0,4.0.0)'
but it could not be found
should be solved by ocl.edit
changeing
to [4,5) .... or, is there any chance [3,5) would work to avoid
"split
streams"?
And, I really am just asking ...
I do
not know the code well.
But, these sort of large rippling
effects
does remind me, to remind you ... it is a good time to check the
coupling
of all your code ... are there any dependencies that can be
lessened?
Such as, in features, best not to
have
"feature level" require statements, unless you have a specific
need to. Best to let the bundles work it out.
As the bundle level, would
import-package
work, instead of require-bundle? import package, if you have a
small dependency,
is often more immune to version changes.
I know such issues are not easy,
snap
decisions ... but, seems like a good time to ask.
Thanks,
From:
Ed Willink
<ed@xxxxxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
09/22/2011 10:31 AM
Subject:
Re:
[cross-project-issues-dev]
Juno M2 aggregation -- will it be the worst milestone ever?
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi Ed
Unfortunately evolution of the UML model changes a constraint
and so changes
the validate functions visible to client Validators. The UML2
4.0 change
so far has one such change; there will probably be many more for
Indigo.
This makes it very difficult for MDT/OCL to be compatible with
both UML2
3.x and 4.0 and equally difficult for UML2 4.0 to offer a clean
UML 2.4
model while maintaining API compatibility with 3.x.
http://wiki.eclipse.org/Version_Numbering#How_to_specify_versions_when_plug-ins_re-export_other_plug-ins
directs that all plugins exporting a major increment must also
have a major
increment, and http://wiki.eclipse.org/Version_Numbering#How_to_version_packages
directs that all features must also have a major increment.
Somewhere there
is also a direction to keep major versions coherent, so I see no
alternative
to a major increment for MDT/OCL for Juno.
To minimize M2 impact, we can probably just change our UML2
dependencies
to [4.0.0,5.0.0) although that may leave downstream UML clients
in trouble,
but no more than they're already in anyway. This requires that
we disable
the API checking until we make a major increment.
Is it best to have all this pain now for M2 or defer some more
pain till
M3?
Regards
Ed Willink
On 22/09/2011 11:31, Ed Merks wrote:
David,
I'm not sure why so many clients would strictly upper bound
their EMF dependencies
based on minor version increments. I know UML2 does this
because
they extend EMFs GenModel and hence its implementation classes,
but I don't
expect a significant number of clients to be so intimately
dependent on
EMF's minor versions. Of course there could be quite a few
things
downstream from UML2 that are affected...
Ed,
Clients (bundles) interested in UML2's version range can/should
have direct
dependencies on UML2 itself and those dependencies can reflect
the range
restrictions they feel are appropriate. They don't need that
information
to trickle through your versions. Of course if you make API
changes
in response to those of UML2, then you'll want to make version
changes
to reflect that level of change in your latest version.
Cheers,
Ed
On 22/09/2011 2:26 AM, Ed Willink wrote:
Hi David
Thanks for the early prompt. MDT/OCL at +1 will try to
contribute very
soon.
But, just checking our dependencies for a MDT/UML2 M2, I notice
that I
must have missed an announcement of a UML2 major version change,
so as
I understand it, MDT/OCL and all downstream projects must have a
major
version change too.
At present only an I-build exists for MDT/UML2 4.0 so that's
what we must
use for now. An esartly M2 would help Kenn.
Regards
Ed Willink
On 22/09/2011 03:54, David M Williams wrote:
Well, no, probably not ... but,
it will
take a lot of attention to get it done on time.
First greatest thanks to Kenn Hussey for making (or fixing) an
"early"
contribution repository [1] for EMF core (or, "base", I think
they are now calling the platform-shared parts.
This allows Eclipse 4.2 M2 and EMF M2 to both be installed from
repository
sites. (For full issues, and longer term improvements, you can
follow bug
356644).
Now the problem is that the new version of EMF (and maybe
Eclipse M2?),
apparently, breaks numerous other contributions, apparently due
to
increased minor version numbers (combined with narrow ranges?).
To aggregate, at the moment, I would have to disable about 20 of
the b3aggrcon
files in org.eclipse.juno.build.
I can (and may) do some disabling, .... but, thought it would be
a good
time to review the process and timing of making contributions to
an aggregation
build:
you do not have to wait until your +n day to make a
contribution. You can
make a "warm-up" contribution at any time ... especially if it
is needed to allow the aggregation to succeed. In other words,
your +n
day is the last possible day to make a contribution ... not the
first day
you may make one.
Many of the current problems are "ripple effects" from a few
low level, commonly used bundles or features (in modeling
projects, it
appears) so, maybe with only a few fixes we'll be on the right
path again,
but, I ask that teams try to respond as quickly as possible to
fix any
"aggregation errors" they get notified about ... please do not
think you can wait until your final contribution next week ...
and even
if you have not been notified yet, if you use EMF, please "peek
ahead"
with the M2 versions of Eclipse and EMF base and prepare an
early version,
even if you re-contribute your final version during the (final)
window
next week. After all, if we had to do a true "iteration" waiting
for each of 20 project to fix their builds sequentially before
the next
one fixes theirs, then we will not finish in time.
Thanks, for your attention, let us know if questions or issues.
[1] http://download.eclipse.org/modeling/emf/emf/updates/2.8milestones
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=356644
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date:
09/21/11
_______________________________________________
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
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3911 - Release Date:
09/21/11_______________________________________________
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
No virus found in
this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3912 - Release Date:
09/22/11
|