Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] 3.1.0 N-builds

Agreed... except I'm not sure that the MDT composite is needed anymore. I think we'd like to eliminate the "middle man" here...

Kenn

On Wed, Aug 18, 2010 at 2:03 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Adolfo

I think Kenn's and my preferences are the same.

A modeling update site aggregates
An MDT update site that aggregates
An MDT/OCL update site that aggregates
An MDT/OCL specific version update site

Are we all agreed?

If so, let's put the aggregations in place to reference moved old files and update project meta-data.

    Ed


On 16/08/2010 23:56, Kenn Hussey wrote:
I personally prefer to not have the release-specific sites (the ones with the version numbers) appear in the list of software sites unless a user has added it manually. Ideally/eventually, we would have only the one composite Modeling site, or one for each project at the very most.

My vote is to set things up the same way that EMF has been set up, i.e., with composite sites for the project which reference sites for each release (and for each type of build) which in turn reference sites for individual builds.

Kenn

2010/8/16 Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>
Ed,

El 16/08/2010 11:27, Willink, Ed escribió:
Hi Adolfo

I'm afraid that I'm behind the Thales firewall at the moment so cannot
explore with Putty.

I would tend to emulate EMF (Core) else UML2 else GEF else ... so please
check that what you're doing is consistent with EMF and/or GEF; UML2 has not
had much releng done recently so it may not set a good precedent. Xtext
gives yet another view and while Xtext is 1.0.0, it uses the same releng as
many itemis projects.
  

EMF (Core) organization doesn't like me. I'll show you the organization of some projects:

EMF (Core)

modeling/emf/emf/updates/2.6 (the release one, I think)
modeling/emf/emf/updates/2.6-I-builds (updatesite for integration builds)
        Ixxxxxx -> update site of an I-build
        Iyyyyyy -> update site of another I-build
modeling/emf/emf/updates/2.6milestones  
        Sxxxxxx ->  update site of a milestone build
        Syyyyyy -> update site of another milestone build
        ....

MDT/Modisco
modeling/mdt/modisco/integration (integration builds)
                0.8.1 -> update site of the last integration build of 0.8.1 ?
                0.9.0 -> update site of the last inegration build of 0.9.0 ?
modeling/mdt/modisco/updates/milestone (updatesite for the last milestone build)
modeling/mdt/modisco/updates/nigthly (update site for the last nighly build)
modeling/mdt/modisco/updates/release (releases builds)
                0.7.1 -> update site of the 0.7.1 release ?
                0.8.0 -> udpate site of the 0.8.0 release ?
modeling/mdt/modisco/updates/staging (?¿?¿?¿)
                helios -> ?¿?
                indigo -> ¿?¿

GEF
tools/gef/updates/interim (update site for the last integration build ?)
tools/gef/updates/milestone (update site for the last milestone build?)
tools/gef/updates/releases (update site for the last release build ?)


I would certainly expect to see '3.1' since most downloads I've browsed have
it.
  

Well, looking at the update sites from my Helios installation: Windows-> Preferences-> Install/update -> AvailableSoftwareSites

A lot of them have a version, a lot of them doesn't have.... so maybe with a third opinion such Kenn's one could decide this.

Meanwhile, I think that the updatesite we need for the milestones shouldn't require any version specification (the milestones orrespond to the last development stream), so in principle it would be something like this:

http://download.eclipse.org/modeling/mdt/ocl/updates/milestones

Let me know if this is OK to you, or  if you prefer the 3.1 at the end, otherwise.  As said, I'll point Kenn to this discussion to have a third opinion about this.


I see that the I-build is now green although javadoc fails. IIRC javadoc is
something that should be provided by the Java environment, so probably the
Java config is inadequate. The error message about it not existing in
ocl.doc is just the failure from the last alternative search location.
  

Great, it seems that it finally works. Next steps:
- I want to try the promotion of the integration build.
- I'll try to find out what is happening with the javadoc error.
- I'll launch a new integration build using the branch. I'll have to switch to the proper PPC Eclipse version and check that it now works (3.0.1 SR RC2 is in two weeks time, anyway).
- I'll be paying attention to EMF and UML2 builds to make our Indigo M1 build ;).

Cheers,
Adolfo.
--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3075 - Release Date: 08/16/10 07:35:00


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev



Back to the top