[releng] Major increment to 3.0.0

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 285354 | | Status | CLOSED FIXED | | Importance | P3 major | | Reported | Aug 01, 2009 02:55 EDT | | Modified | May 27, 2011 02:48 EDT | | Version | 1.3.0 | | Reporter | Ed Willink |

Description

Created attachment 143204\ The 3.0.0 increment

Attached enables us to move on and have appropriate @since tags:

Eliminates org.eclipse.emf.ocl in all contexts other than org.eclipse.emf.ocl.examples whose upgrade is a separate activity.

Changes the version to 3.0.0 and the dependency to [3.0.0,4.0.0) throughout.

Updates the API baseline to Eclipse 3.5.

Updates the PSF to exclude org.eclipse.emf.ocl and all UML2 resources.

Standalone JUnit, Plugin Junit, ANT JUnit launches all work.

I'm not sufficiently familiar with releng to more than a best endeavour update.

Alex: please check that the builds continue to work.

:notepad_spiral: OCL3.0.0.patch

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Aug 03, 2009 08:30

Hi all,

The patch seems mostly good. I have some thoughts though:

• we are throwing org.eclipse.emf.ocl away, since it's a deprecated version which has been maintained during the 2 releases (As it is required). That's good.
• I think, that we could do the same with the OCL example instead of upgrading it. Actually, there is an opened bug related to improve the example https://bugs.eclipse.org/259922 (we could also think about including it as part of OCL UI) which removes the old-fashioned org.eclipse.emf.ocl project name.
• I have not checked anything related to releng (basically ignorance about that ;P) . I guess we will have to wait until Alex is back.

[eclipse-ocl-bot]

By Laurent Goubet on Aug 24, 2009 05:15

Hi,

Seems fine to me, but :

1) org.eclipse.ocl.releng/promoteToEclipse.ocl.properties :\ line 81 : "branch = 1.3.0"

I believe we can change this to 3.0.0 for the default build selection.

2) Is there a reason why you didn't update the version of o.e.ocl.standalone.tests?

Other than those two, I believe this is fine. We'll also have to change the build_common.php on org.eclipse so that we can build 3.0.0 | HEAD as well as an 1.4 version. Alexander, you take care of the build pages?

[eclipse-ocl-bot]

By Alexander Igdalov on Aug 25, 2009 15:08

The patch mostly looks good, however, I would add some notes:

1. org.eclipse.ocl.releng\builder\tests\customTargets.xml

refers to org.eclipse.ocl.tests. Is it a new test plugin from some other patch?

2. org.eclipse.ocl.releng\templateFiles\ocl.map.template

refers to org.eclipse.ocl.sdk. But there is no such feature.

3. org.eclipse.ocl.releng\buildAll.xml

includes */org.eclipse.emf.ocl.examples_ which are excluded in the attribute above. Seems to be a wrong inclusion since this is part of build runtime.

4. org.eclipse.ocl.standalone.tests\launches\MDT OCL Tests - Stand-Alone Mode.launch

contains .

Better to remove this tag since it may prevent running the launch on other VMs.

BTW, we will need some more things for 3.0.0 such as updating metamodel URIs.

All in all, I think we should commit the patch the sooner the better since this will give me the ability to:\ a) include 3.0.0. into Helios\ b) check that 3.0.0 has correct releng - in Helios M1 I included only 1.4.0 implementation from OCL_2_0_support branch\ c) check that 3.0.0 and 1.4.0 do not conflict with each other.

In reply to comment #1:

• we are throwing org.eclipse.emf.ocl away, since it's a deprecated version which has been maintained during the 2 releases (As it is required). That's good.
• I think, that we could do the same with the OCL example instead of upgrading it.

Regardless of what we invent in 3.0.0 I would leave the interpreter console in 1.4.0 in its current state (maybe just changing labels a little to reflect that it is aimed for OCL 2.0 implementation only). For me it this example is a good instrument for evaluation of OCL expressions. IMO we shouldn't ship 1.4.0 without this feature.

In reply to comment #2:

We'll also have to change the build_common.php on org.eclipse so that we can build 3.0.0 | HEAD as well as an 1.4 version. Alexander, you take care of the build pages?

I will switch both OCL implementations to Athena. If build_common.php needs to be updated for that - so shall it be;-)

[eclipse-ocl-bot]

By Ed Willink on Aug 25, 2009 15:57

In reply to #2 1. I don't understand releng properly. You're probably right.

In reply to #2 2. This tests the deprecated and obsoleted code.

In reply to #1,#3. The interpreter depends on ocl.ecore not emf.ocl, so it remains the best we have until we upgrade it. No point renaming it. Let's keep it as-is until we have something better.

In reply to #3 1; org.eclipse.ocl.tests is my next tests contribution starting to provide shared functionality for Ecore and UML bindings.

In reply to #3 2; probably agree.

In reply to #3 3; the examples have a ZIP that is built at releng time. This may be why it seems odd.

In reply to #3 4; yes. it's a very painful debug.

We may well update the CST URIs. I doubt we update the AST URIs; Ecore hasn't changed for years; - see mdt-oct-dev thread.

I will endeavour to commit the patch as-is promptly. Seems there are only releng subtleties to resolve.

Whoever's (Alex?) is tidying up releng can surely do minor bug fixing directly; no need for bugzillas and +1's.

[eclipse-ocl-bot]

By Ed Willink on Aug 25, 2009 16:54

Created attachment 145594 Residual releng patch

Non-releng patches committed to head.

New patch obsoletes the releng bits only. It should incorporate #2 and #3 observations and merge CVS changes.

Of course there is no need for +1's opn releng since only Alex has write access.

:notepad_spiral: OCLreleng3.0.0.patch

[eclipse-ocl-bot]

By Ed Willink on Dec 12, 2009 07:08

We are well and truly on 3.0.0 now.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:48

Closing after over 18 months in resolved state.