Actually, I believe PTP depends on CDT for other plugins.
So we have a dependency loop at the project level, although
everything works at the feature/plugin level.
I'm leaning towards pushing the CDT enabled contribution to SimRel
even though it currently fails.
Opinions?
------------------------------------------------------------------------
*From:* cross-project-issues-dev-boun...@eclipse.org
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Marc
Khouzam [marc.khou...@ericsson.com]
*Sent:* August 10, 2016 9:12 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
> 3. I disabled the DLTK integration with RSE. The validation failed
because Linux Tools was disabled.
> 4. I noticed in Gerrit that the Linux Tools team was trying to
enable its contribution, but the validation failed because CDT was
disabled.
CDT is ready but dependent of org.eclipse.remote.core which is part
of PTP (although only hosted, I believe).
Marc
------------------------------------------------------------------------
*From:* cross-project-issues-dev-boun...@eclipse.org
[cross-project-issues-dev-boun...@eclipse.org] on behalf of Kaloyan
Raev [kaloya...@zend.com]
*Sent:* August 9, 2016 1:49 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
Hi again,
I want to describe the effort I have spent in the last hours for
trying to enable the DLTK project - a project with rather small
number of dependencies.
1. I tried to enable the whole DLTK contribution. The validation
failed because Mylyn was disabled.
2. I disabled the DLTK integration with Mylyn. The validation failed
because RSE was disabled.
3. I disabled the DLTK integration with RSE. The validation failed
because Linux Tools was disabled.
4. I noticed in Gerrit that the Linux Tools team was trying to
enable its contribution, but the validation failed because CDT was
disabled.
5. I disabled the ShellEd feature of DLTK. The validation failed
because EMF was disabled.
6. I disabled the Tcl features of DLTK. Finally, I got a successful
validation.
7. I partially enabled the DLTK contribution with just the DLTK Core
and Ruby features.
8. I tried to enable the TM/RSE contribution (I am committer there
too). The validation failed because TM Terminal depends on
org.eclipse.remote, which is disabled.
9. I disabled the TM Terminal features. I got a successful validation.
10. I enabled just the RSE feature of the TM contribution.
11. I enabled the DLTK RSE feature. Still there DLTK feature that
cannot be enabled.
I've spend quite some effort to achieve the above. I am not sure
what is the return of this effort. And I am still not done with
enabling DLTK. I cannot imagine what it would take to enable a more
complex project like Andmore. Building meaningful EPP package would
be another interesting challenge.
Kaloyan
------------------------------------------------------------------------
*From:* cross-project-issues-dev-boun...@eclipse.org
<cross-project-issues-dev-boun...@eclipse.org> on behalf of Lorenzo
Bettini <lorenzo.bett...@gmail.com>
*Sent:* Tuesday, August 9, 2016 8:02:16 PM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
only partially today
Hi
We (EMF Parsley) depend on Xtext as well (besides EMF). It's not clear
to me what we should do... add our p2 site to the simrel and push for
review and that will fail? Or something else?
thanks in advance
Lorenzo
On 09/08/2016 18:10, Ed Willink wrote:
> Hi
>
> What if e.g. UML went AWOL?
>
> This is exactly what happened a few years ago when OCL went
> committer-less. So many projects depended and wanted to help that
> someone had to get the rule book out and decide that since Eclipse
is a
> meritocracy, that the active Bugzilla contributors took precedence
over
> panicking companies.
>
> The same would happen again for any +1 and probably +2 project.
>
> Clients have three options:
>
> - just occasionally a dependency can be eliminated
>
> - just occasionally a dependency can be rewritten, but it may take
many
> man years of effort
>
> - much more practically a dependency gets rescued and put on minimal
> maintenance (e.g. EMFq, EMFt, EMFv).
>
> So by pretending that we must wait for +1/+2 dependencies, we waste a
> lot of time for those who are trying to contribute. It is just not
real.
> +1/+2's should carry over automatically.
>
> You suggest that we should notify dependencies that we are
waiting. Are
> you joking? Why should I waste my time and EMF's time by
suggesting that
> it is about time for them to contribute. EMF is a -1/+1
contribution. Of
> course it should know that it should contribute.
>
> Regards
>
> Ed Willink
>
> On 09/08/2016 16:10, David M Williams wrote:
>> I am sure improvements can be made, but the key -- from my point of
>> view -- is that projects smooth out their processes and dependencies,
>> rather than "the big guy in the sky" blindly makes everything work
>> just fine for everyone by making a lot of assumptions that may or may
>> not be accurate. To force something positive out of this difficult
>> period of time, it does give projects an opportunity to think through
>> your dependencies and if you really want or have to depend on them.
>> For one, completely made up example, what would you do if "UML
>> Project" decided not to participate any more? What if it was
>> "terminated"? What is your contingency plan? Does something need
to be
>> refactored? Made optional? Or, perhaps even move to some other
project?
>
>
>
>
------------------------------------------------------------------------
> Avast logo
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com>
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
