OK, uncle. I have responsibility for org.eclipse.emf.java issue. Basically, I need to consume this at runtime, and it has only been available at end-user build-time, so I've needed to provision it.
David, there are four things I can do at this point:
1. Add back in that damn about.html file. I have no idea why it disappeared.
2. Modify my rmaps so they point to the Eclipse hosted
3. Modify my plugin to remove the *one* class that depends on it, removing that functionality.
4. Give up and try again next year.
I reconstructed the history on this one a bit. First, the dependency itself is actually pre-Eclipse, that is before AMP joined the Eclipse platform, 2007. So naturally having the dependency wouldn't have been discussed by PMC at that time and I had no choice but to provision it myself. Second, for builds I initially had had the dependency on the EMF CVS but I changed that on 7/28/09:
"Added dependency on org.eclipse.emf.java to amp to maintain consistency and for ease of client build."
As this was about the time I was trying to get the CBI builds going, my guess is that I had trouble somehow with collecting from the modeling CVS build. Or I may have thought that I "should" be maintaining it in my dependencies just as we are required to for Orbit dependencies. God knows, and she doesn't care.
There may have also been an extremely subtle issue that effected why I needed to maintain it separately. I know that there were some class loading issues that I was trying to solve at some point. I may have not wanted ecore reexported as that seems to be only difference between the two.
org.eclipse.emf.ecore;visibility:=reexport,
The only other difference is in -- of course -- the about.html files. I actually removed that reference. I have *no* idea why except perhaps for (a stray mouse-click during maintenance?)
So, let me know the best course of action at this point.
-Miles
On Jun 9, 2011, at 7:29 AM, Kenn Hussey wrote:
We actually build the bundles in question as part of the EMF build but don't intended for them to be installed from a repository (instead, their source is embedded in the examples installer, to be extracted as projects into a user's workspace). The bundles are in fact available in the EMF repository, so I'm not sure why they couldn't be consumed from there by AMP.
The about.html files have been in place in the EMF codebase all along. The reason they didn't appear in the aggregated bundles must have to do with a difference in the AMP build. There are other subtle differences with the way these bundles are built by EMF and AMP (e.g., the way the qualifiers are generated) which suggests another potential concern with code being redistributed by another project...
Kenn
On Thu, Jun 9, 2011 at 9:25 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
This isn't explicitly covered by the EDP. In practice, however, this
is generally considered acceptable.
If the project is copying the code from another project's repository
into their own repository, then a fork has occurred, and the IP team
needs to be informed (primarily for tracking purposes). In a general
sense, projects are permitted to take the output from other projects
and include it in their own distributions. If the project they are
consuming is in the incubation phase (does not apply here), then
they are obligated to include incubation branding in their own
downloads.
FWIW, almost every project distributes something from another
project at some level or another.
There is no formal requirement to call this out in release review
documentation. But that would definitely be nice to see.
As for responsibilities, I respectfully suggest that AMP and EMF
share responsibility to resolve the issues. I include AMP in this
because they have taken on code with no implicit warranty (this is
based on assumptions stemming from the statement that "it wasn't
available from EMF"). I include EMF because, well, it's their code.
It seems to me that a patch submitted to EMF by the AMP team should
clear an "about files" problem up pretty quickly.
Hopefully this doesn't turn into one of those hard lessons. If,
ultimately, EMF cannot provide the necessary assistance to resolve
issues, AMP is left with the responsibility. A project not shipping
pieces of their code is a huge red flag for consumers. Early and
ongoing communication is important in this sort of situation.
In terms of detection, there's only so much that we can do. We
depend very heavily on committers and project leads to do the right
thing (and provide assistance where we can).
HTH,
Wayne
On 06/09/2011 08:44 AM, David M Williams wrote:
I find something disconcerting about one
project releasing another project's (otherwise unreleased) code.
Beside
these e4 cases, Miles recently explained AMP is releasing
o.e.emf.java.
" We use..emf.java
to do Java->AMF M2M mapping because it provides a good working
ecore
model for arbitrary Java. (We should probably move to MoDisco or
something at some point.) We needed to build it because it wasn't
available
from EMF. "
Don't get me wrong ... on one level
it's "cool". Good to see code being (re) used. But it does seem
to raise some questions. How's this covered by EDP? How is it
called out
in Release Review documentation? Who is "responsible" for the
code, doing the CQ/IP work? ... for example, this case of missing
"about.html"
files is normally a stop ship problem ... who's to fix it now?
What kind
of project-to-project communication should go on? Must go on?
Sounds
like there was none (until just now) for these two cases. Plus,
these two
cases came to our attention because there were some routine, "easy
to spot" issues. I wonder .... how much does this go on and its
just
never really known about? How would we normally "detect" it?
I'm not saying there is a problem that
has to be solved right now. But seems long term there should be
some guidelines
created to improve communication and be explicit about
expectations. Some
of this might covered in this process bug?
Bug 331397 - EDP should say more about project
namespaces
Or, maybe its just me that's surprised
by this and all the right people already do know what's going on
... in
which case, never mind me.
Le 09/06/2011 12:33, Paul Webster a écrit :
On Thu, Jun 9, 2011 at 3:39 AM, David M Williams <
david_williams@xxxxxxxxxx >
wrote: Missing about.html in file:
org.eclipse.e4.xwt.pde_0.9.1.v20101119-0800.jar
Missing about.html in file:
org.eclipse.e4.xwt_0.9.1.v20101119-0800.jar
I've opened a bug for these, but we don't plan to look at it until
Juno.
I'm not even sure why they're in the release repo as e4 and XWT
are not
in the release train.
