Community
Participate
Working Groups
Most cases are pretty clear, as to how .build files correspond Project's short names from Portal meta-data. But, I think it would be in improvement to name exactly the same. For example, equinox.build would become rt.equinox.build. If nothing else, it would help in alpha sorted lists to group projects that "went together" but long term, if or when things become more automated, it'd make "string matches" easier.
So: emf-transaction.build would become modeling.emf.transaction.build. mdt-uml2.build would become modeling.mdt.uml2.build. Correct?
Created attachment 154917 [details] listing of proposed new names Yes. I've attached a list of current .build file names, with what I think they should be based on Project's portal short name. I'm guessing in some cases, so proof read and don't take my word for it, if something seems off. It would be best if Project releng changed their own .build file names, as they are ready. I realize this could effect teams releng scripts so care is needed to make coordinated changes.
With the new "announce" policy, as described in http://waynebeaton.wordpress.com/2013/09/09/eclipse-luna-whos-in/ and recorded in https://projects.eclipse.org/releases/luna It will be possible, eventually, to automate a little better "who has announced" and "who is or is not" in the aggregation files. Its my understanding that for one "announcement", there should be one line in https://projects.eclipse.org/releases/luna and then also one *.b3aggrcon file. The "automation" though depends on having some "data" that is reliably "matched" between one source and another. The easiest way to do this is to have the b3aggrcon files named exactly what a projects "database name" is. The attached file is pretty old (being for previous "aggregation system") but the principle's still the same. Only now, I think its a good time to make the change. After M2, but before M3 (and before Kepler SR2). I'll do the "work" in org.eclipse.simrel.build but this will effect (some/most) projects in that the file you edit may change names. If people "edit by hand", should be a easy enough to find your file! But, if anyone has any automated scripts, there might be more impact, and our changes would have to be "coordinated". So, if you have such automated scripts, please make a note here in this bug, and we'll work out a more exact time to make the change for your project. For other projects, I'll assume I can make the change "at will" with no real impact. Before I change anything, I'll attach a current list of project "key" names and current file names, so projects can tell me if I've gotten any of my assumptions wrong.
mdt-ocl-3-0.build ==> modeling.mdt.ocl.build +1 to whatever makes your life easier, but I'm puzzled. Where is "mdt-ocl-3-0.build"? I see "mdt-ocl.b3aggrcon" and given the general EMO enthusiasm for flattening would expect progress to move to "ocl.b3aggrcon".
(In reply to Ed Willink from comment #4) > mdt-ocl-3-0.build ==> modeling.mdt.ocl.build > > +1 to whatever makes your life easier, but I'm puzzled. Where is > "mdt-ocl-3-0.build"? I see "mdt-ocl.b3aggrcon" and given the general EMO > enthusiasm for flattening would expect progress to move to "ocl.b3aggrcon". those existing *.build files (in attachment) were done years and years ago. (before your time, I guess :) I'll update with *.b3aggrcon files within a week or so. I get your point about "flattening", but ... just fear that makes "matching" in database names harder if if not more error prone. (You know, what if we had "mdt-ocl" project and a "webtools-ocl" project (just to make up something)).
I think this is outdated.
Outdated in regards to .b3aggrcon, but now applicable to *.aggrcon. Currently mdt-uml2.aggrcon should be uml2.aggrcon. Some projects have decontainerised, others haven't.
