Folks, please see:
Guidance? Begin forwarded message: Date: June 9, 2011 12:18:04 PM PDT
Subject: Re: [cross-project-issues-dev] org.eclipse.emf.java Re: Projects releasing other projects unreleased code .... ?
Sounds like the safest course of action
... the path of "minimal change", minimal risk ... is to add
back the about.html.
But ... up to you, and the "EMF
Project" ... whoever "owns" that o.e.e.java bundle.
Good luck.
From:
Miles Parker <milesparker@xxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:
06/09/2011 03:07 PM
Subject:
[cross-project-issues-dev]
org.eclipse.emf.java Re: Projects releasing
other projects unreleased code .... ?
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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.
From: Mariot Chauvin <mariot.chauvin@xxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx
Date: 06/09/2011 08:12 AM
Subject: Re: [cross-project-issues-dev] aggregation
builds have been turned off
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
They are redistributed by papyrus, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=347239#c10
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.
Bug
348742 - Missing about.html
--
Paul Webster
Hi floor. Make me a sammich! - GIR
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
