[releng] MDT/OCL 3.0.0M5 does not use EMF 2.6.0M5

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 302036 | | Status | CLOSED WONTFIX | | Importance | P3 normal | | Reported | Feb 06, 2010 06:32 EDT | | Modified | May 27, 2011 02:54 EDT | | Version | 3.0.0 | | Reporter | Ed Willink |

Description

The M5 build depends on emf-xsd-SDK-I201001101746.zip which depends on eclipse-SDK-I20100105-1537-linux-gtk.tar.gz which is significantly earlier than drops/S-3.6M5-201001291300/eclipse-SDK-3.6M5-linux-gtk.tar.gz.

This may explain my problem building QVTd on platform M5 rather than M4.

bug 302031 reports an "The copies of profile SDKProfile are not in sync" problem.\ Perhaps the two different platform dependenjcies cause two different SDKProfiles.

I think we should spin a 3.0.0M5a anyway.

[eclipse-ocl-bot]

By Alexander Igdalov on Feb 08, 2010 08:22

Hi Ed,

As I see it, you have run an OCL N-build with a dependency to EMF M5. Did it help? If not, I am not inclined to respin OCL M5: the problem is that OCL has a dependency on UML2 while both have a dependency on EMF. Both OCL M5 and UML2 M5 depend on EMF I201001101746 (because at the time of building there was no EMF M5 available). Thus, in order to be completely correct about the dependencies we will need to respin UML2 as well.

-----\ There are sometimes very odd problems with the releng. It could be that you were just unlucky on Feb 5 (because of some weird build anomalies) and, afterwards, the situation improved the next day. Besides, QVTO has similar dependencies (i.e. OCL M5 and EMF M5) - and their build was successful on Feb 2. Could you respin the QVTd build with all M5s today and see what happens?

Regards,

• Alex.

[eclipse-ocl-bot]

By Ed Willink on Feb 08, 2010 15:02

The N-build didn't help me because I couldn't promote it so that a QVTd build can access it.

It would be really helpful if you can tell me precisely what to do to promote it, then I can see if it fixes QVTd, and may be do a similar promotion for QVTd and set about debugging problems with the spelling of the QVTd project name in the Downloads domain.

[eclipse-ocl-bot]

By Alexander Igdalov on Feb 08, 2010 16:02

(In reply to comment #2)

Ed,

The N-build didn't help me because I couldn't promote it so that a QVTd build can access it.

I think you do not need to promote an OCL build to access it from your QVTd releng. It is available at https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-mdt-ocl-3.0/117/artifact/build/N201002060655/mdt-ocl-SDK-N201002060655.zip which is what you can write in build.properties. IMO it is not worth promoting an identical M5a unless it actually helps you resolve the QVTd problem.

It would be really helpful if you can tell me precisely what to do to promote it,

I must mention that it is impossible to promote an N-build, you can promote an I-build only.

then I can see if it fixes QVTd, and may be do a similar promotion for QVTd

Before you make an I-build you should verify that you have correctly tagged the latest changes and included them into ocl.map so that they appear the build.\ After you successfully run the build you should ssh to build.eclipse.org and logon to it with your CVS user credentials (ewillink/your_password).\ After that you can explore my folder: /home/data/users/aigdalov/scripts

promote_ocl_3_0_0_I.sh is a tiny script which promotes an I-build\ promote_ocl_3_0_0_S.sh is a tiny script which promotes an S-build

Please inform me if you cannot access my user directory - I have just changed user permissions so that members of modeling.mdt.ocl should have rights to read and execute files from it.

and set about debugging problems with the spelling of the QVTd project name in the Downloads domain.

You should have access to www/modeling/m2m/downloads/index.php where you configure artifacts for QVTd. It seems it has not been done yet. As regards the "Relational QVT" name on the M2M downloads page I think it must be fixed somewhere in the adjacent files.

[eclipse-ocl-bot]

By Ed Willink on Feb 09, 2010 02:31

Thanks for the URL to the N-build. Didn't help. Since QVTo works, I just ran a build with IMP runtime and associated SVN repo access excluded. Build went much further; no out of sync SDKProfiles. The QVTd problem is therefore not associated with OCL M5 not depending on EMF M5.

Thanks for the script access and useful www pointers; they answer many of my QVTd uncertainties.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:54

Closing