Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Status of Helios M1


All,

Paul and I have have discovered the buid file had an incorrect version number ( the dependecies of the components seems perfectly fine ).
I had updated this manually and chose 200908131135 as opposed to 200908131100.
The fix has been committed.

Regards,
- James.



Paul Elder/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

08/17/2009 09:04 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] Status of Helios M1






All:


Based on the build error logs I received from David, there is a problem with the UML2 build and its tight version dependencies on the EMF importer/exporter plug-ins.


Any projects with UML2 dependencies are automatic members of David's M1 rejects lists :-)


James Bruck and I are starting to investigate.



Paul Elder
Development Lead, Model-to-Text languages and tools
IBM Rational software
ph: +1 613 270 4560



From: David M Williams <david_williams@xxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx
Date: 16/08/2009 06:26 PM
Subject: [cross-project-issues-dev] Status of Helios M1






We are half way through the M1 window, and amazingly enough, I was able to
produce a common discovery site this weekend, at

http://download.eclipse.org/releases/staging/
(Subject to the same cautionary note as for maintenance site, the download
servers are intermittent at the moment, so installs from there probably
won't work, right now)

This common site contains contributions from 32 projects. As you might
guess ... I don't know if they actually _work_ ... I really just mean the
build worked to mirror them there and verify them as the current
aggregater does.

To be able to accomplish this "successful build", I used the
tried-and-true advanced programming technique of "if code does not work,
just remove it".

Iterating with that technique resulted in the blind removal of the
following 14 contributions:

mdt-ocl.build
emf-transaction.build
m2t-acceleo.build
m2t-jet.build
mdt-uml2.build
m2m-qvtoml.build
gmf.build
mdt-uml2tools.build
emft-ecoretools.build
m2t-xpand.build
tmf-xtext.build
dsdp-mtj.build
stp.build
riena.build

Many of these have previously warned us of delays, so no surprise there,
and we'll see how many can get back in by the end of this week. Hopefully
all. Some of these were "direct" failures, but then others, I'm sure, only
failed since I removed some of the others.

This might be a good time for effected projects to take a step back and
look at your dependancies ... can any be simplified? Made optional? Made
more resilient to change? I say this in the sense that one of the frequent
complaints of Eclipse adopters is that it is very hard to move up from one
release to another ... and I think this "fragile chain" effect is one of
those reasons. So, are we experiencing what our adopters experience? Of
course, I'm not sure what the cause of these above failures are ... they
might all be quite minor and quite reasonable given this was our "first
build". But still, the ideal is a smooth transition for everyone. We'll
see how smooth the rest of the week goes.

At any rate, removed projects can add yourself back in when ready. I think
re-builds will happen automatically, but you can keep your eye on the
build page at

https://build.eclipse.org/hudson/view/Repository%20Aggregation/
and just kick off a build when you are ready. Let me know if you need help
or have questions.

Thanks,




_______________________________________________
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


Back to the top