Re: [cross-project-issues-dev] DTP major version bump for Neon

On 28/10/2015 13:13, Konstantin Komissarchik wrote: I have no specific plans re ODA’s Java API. So absolutely no justification for a change then. There is no need for all plugins to bump together. It is cosmetically nice to see all plugins with the same version, but it just isn't tenable

Re: [cross-project-issues-dev] DTP major version bump for Neon

> Inflicting a major change on clients is not a bit of a pain, it is a major pain, particularly for those clients that are stable and consequently have minimal maintenance teams. > In some cases useful but unmaintained tools, such as UML2 Tools, are killed by the major version change. +1 Dani

Re: [cross-project-issues-dev] DTP major version bump for Neon

All DTP bundles received a major version bump, including the three that you’ve listed. As I’ve already explained, I consider the BREE bump to Java 8 a breaking API change on it’s own and all bundles received this change. Another likely-breaking change is that all DTP bundles now receive

Re: [cross-project-issues-dev] DTP major version bump for Neon

I gave the justification several times. You are choosing to disregard it. Java API is not bundle’s sole API. I don’t consider a restriction in requirements a compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 and the version numbering truthfully communicates that fact.

Re: [cross-project-issues-dev] DTP major version bump for Neon

+1 Am 28.10.15, 15:22 schrieb "cross-project-issues-dev-boun...@eclipse.org on behalf of Aleksandar Kurtakov" unter : >- Original Message - >> From: "Konstantin Komissarchik"

Re: [cross-project-issues-dev] DTP major version bump for Neon

> potentially no impact on most consumers of your API And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into question why

Re: [cross-project-issues-dev] DTP major version bump for Neon

Hi Perhaps you can just follow the community experience. You don't have to change your BREE at all, but you will still impose a Java 8 BREE on your Neon customers, since the platform already has a Job component that requires Java 8. I am not aware of anyone suggesting that this BREE change

Re: [cross-project-issues-dev] DTP major version bump for Neon

- Original Message - > From: "Konstantin Komissarchik" > To: "Ed Willink" , cross-project-issues-dev@eclipse.org > Sent: Wednesday, 28 October, 2015 3:44:54 PM > Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon

Re: [cross-project-issues-dev] DTP major version bump for Neon

Konstantin, In not sure how this plan affects the following specific bundles: org.eclipse.datatools.connectivity.oda.design.ui org.eclipse.datatools.connectivity.oda org.eclipse.datatools.connectivity.oda.profile If they increment their major version, EMF's ODA adapter support

Re: [cross-project-issues-dev] DTP major version bump for Neon

Can we take this discussion into a bugreport and remove it from crossproject and then everyone interested in seeing you hitting Konstantin can subscribe…. christian Von: > on behalf of John

Re: [cross-project-issues-dev] Announcing JDK 9 support for Eclipse Neon

Tom, I don't see a conflict between Jay's and your observations: Yes, users will be able to create / compile / package modules. No, users will not create Jimage files. Whether or not it is a module is a conceptual question. It needs a module-info.java / module-info.class and there you are. The

[cross-project-issues-dev] Disk usage report for Hudson/Build

Compiled 2015-10-28T12:07 build.eclipse.org -> Usage exceeding 1GB for: Hudson master jobs and workspace (2015-10-28T10:00) 7.6G emf-cdo-maintenance 2.8G papyrus-trunk-nightly 1.7G papyrus-trunk-extra-nightly 1.7G emf-cdo-integration -> Usage exceeding 1GB for: /shared

[cross-project-issues-dev] Linux Tools will participate in Neon

This is to confirm that Linux Tools will participate in Neon with major release 5.0.0 and offset +3. -- Jeff Johnston (Linux Tools Project) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options,

Re: [cross-project-issues-dev] DTP major version bump for Neon

>And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a >consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into >question why we even bother having a versioning convention. By

Re: [cross-project-issues-dev] Announcing JDK 9 support for EclipseNeon

I guess my question, after reading "proprietary" (non-spec'd, available only through APIs) is how that works with projects like "OpenJDK"? (vs. Oracle, and others). Is it that kind of "proprietary"? That they will have to come up with their own "format" that works with the APIs? I am just

Re: [cross-project-issues-dev] Announcing JDK 9 support for EclipseNeon

I don't think I am the right person to answer your questions, but if it helps, here's a snippet from the JEP 220: "we propose to define a new URL scheme, jrt, for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the

Re: [cross-project-issues-dev] DTP major version bump for Neon

> So in this case Konstantin (and rest of the active DTP committers) should get > our full support I agree with Alexander. Kudos from my side to Konstantin for working on the (almost) dead DTP components. Content-wise I also think only the minor version needs increasement with this change but

[cross-project-issues-dev] BIRT will participate in Neon

BIRT will participate in Neon with +2 offset and with version 4.6.0. Thanks, Wei Yan ___ 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,

Re: [cross-project-issues-dev] Announcing JDK 9 support for Eclipse Neon

I just spoke directly with Mark Reinhold. It is absolutely an expected use case that users/organizations will build jimages that include their own code, third-party modules, and JDK modules. There is a lot of perceived value in being able to ship a single image file rather than a bunch of