Re: [cross-project-issues-dev] Making SimRel Great Again

[Alexander Nyßen]

Hi,

I upgraded the GEF contribution to Orbit bundles from the respective I-build: 
https://git.eclipse.org/r/#/c/153406/ .

Please let me know if that does not properly resolve the problems reported here.

Regards,
Alexander

> Am 22.11.2019 um 17:21 schrieb Frederic Gurr 
> :
> 
> Hi,
> 
> Sorry, for the late reply. +1 for more validation as part of the SimRel
> (Gerrit) build. I'm planning to set aside some time for this over the
> next weeks to add checks and fail builds for important issues like
> missing or bad licenses (and other checks that can be agreed upon to be
> essential).
> 
> Regards,
> 
> Fred
> 
> On 18.11.19 17:20, Ed Merks wrote:
>> Greg,
>> 
>> Yes, the Planning Council has been discussing stronger enforcement.  One
>> major problem is that removing one project can have a cascade effect on
>> others, and this effect is not well understood; we don't have a Report
>> on the dependency tree of the contributions.  But in the end, only leaf
>> projects could be easily removed.  I know for example that if USSSDK is
>> removed, MPC and  Oomph use that.  If DTP is removed, parts of EMF (ODA)
>> extend that framework, and so on; this feature of EMF could be
>> excluded.  As such, tracking the impact of removals is currently a
>> time-consuming challenge.
>> 
>> Yes, the requirements page could be more clear and the "new reporting
>> process" of course ought to align with the requirements but what I've
>> done so far is intended to align with the existing requirements.  And
>> I've focused "error reporting" problems primarily on things the user
>> will notice immediately when she installs. Using a proper license is a
>> basic requirement for any project distributing Eclipse content, so no
>> license or a bad copy of the license is just never acceptable.   As for
>> Orbit "requirements," it's not a requirement to use a specific version
>> of Orbit, but if we did all use a specific version we'd have fewer
>> duplicates (a very nice to have and avoids what sometimes leads to a
>> major runtime wiring problem), and we'd have more recently signed
>> content (no that Orbit has addressed some outliers).
>> 
>> Karsten,
>> 
>> In the long term, we'd of course like more validation to be doing during
>> the commit of new content.  But some folks (I know who you are), are
>> pointing a dynamically changing content...
>> 
>> Regards,
>> Ed
>> 
>> 
>> On 18.11.2019 15:30, Greg Watson wrote:
>>> Voluntary is good up to a point, and by all means give projects the
>>> chance to fix the issues before taking action. However if projects are
>>> not complying, then at some point you need to say that the quality of
>>> the release is more important. Now that the release cycle is more
>>> frequent, there could be a limit of N releases (e.g. N=2) for
>>> non-conforming projects, then they are excluded.
>>> 
>>> Regards,
>>> Greg
>>> 
 On Nov 18, 2019, at 9:18 AM, Karsten Thoms >>> >> wrote:
 
 I don’t think that excluding these projects would be a wise choice.
 Then immediately a large set of project had to leave SimRel, and
 clients are used to find many of them in the SimRel.
 Of course the projects that are failing to fulfil the required
 constraints should know that they have to do something to do. For me
 the right point would be the SimRel aggregation validation build. If
 there could be more checks performed there the contributing projects
 will immediately recognise a task when they can’t get a successful
 build when contributing to SimRel. These restrictions could be added
 one by one, starting with most urgent ones, e.g. invalid license,
 missing signing.
 
 ~Karsten
 
> Am 18.11.2019 um 15:02 schrieb Greg Watson  
> >>:
> 
> Hi Ed,
> 
> Thanks for your effort to try to improve the quality of the simrel.
> I was wondering why we don’t simply exclude all non conforming
> projects from the simrel until these issues have been corrected?
> This would seem to be particularly important for projects
> contributing content that is signed with expired certificates. Also,
> as far as I can see, the Simultaneous Release Requirements page [1]
> does not go to the level of detail that your email is suggesting, so
> it would be good to update this with more specific requirements,
> such as with version of Orbit projects should be building with.
> Ideally however, these requirements would be checked automatically
> and the project excluded if non conforming.
> 
> Regards,
> Greg
> 
> [1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements 
> 
> 
>> On Nov 18, 2019, at 4:57 AM, Ed Merks > <

[cross-project-issues-dev] GEF participation in 2019-9

[Alexander Nyßen]

Hi Wayne,

let me state that GEF intents to join the 2019-9 simrel. Matthias, our 
appointed project lead, is currently on vacation. He has unfortunately not 
notified us that he has not contributed a milestone yet and I will not be able 
to carry that out now (which would not make a difference anyway, as M2 seems to 
be complete). Please consider our participation, I will take care of updating 
the aggrcon file for M3.

Regards,
Alexander


signature.asc
Description: Message signed with OpenPGP
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problems running Xtext and Buildship together

[Alexander Nyßen]

Yes, there it is: 
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/lastSuccessfulBuild/artifact/target/repository/final/buildInfo/reporeports/reports/nonUniqueVersions.txt
 
<https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/lastSuccessfulBuild/artifact/target/repository/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>


> Am 06.08.2019 um 09:14 schrieb Christian Dietrich 
> :
> 
> i can find only this one: 
> https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/lastSuccessfulBuild/artifact/target/repository/final/buildInfo/reporeports/index.html
>  
> <https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/lastSuccessfulBuild/artifact/target/repository/final/buildInfo/reporeports/index.html>
> Am 06.08.19 um 09:09 schrieb Alexander Nyßen:
>> Well, it reported which plugins were provided in multiple versions. This way 
>> we could check that only one Guava version was able to satisfy all 
>> dependencies.
>> 
>> Cheers
>> Alexander
>> 
>> 
>>> Am 06.08.2019 um 09:08 schrieb Christian Dietrich 
>>> mailto:christian.dietr...@itemis.de>>:
>>> 
>>> this wont help if its not a explicit singleton but a implicit one only 
>>> (classloaders are not completely isolated)
>>> 
>>> Am 06.08.19 um 09:07 schrieb Alexander Nyßen:
>>>> I remember we had a simrel report pointing out such duplicate singletons 
>>>> in the repo. Is that no longer available?
>>>> 
>>>> Cheers,
>>>> Alexander
>>>> 
>>>>> Am 06.08.2019 um 09:04 schrieb Christian Dietrich 
>>>>> mailto:christian.dietr...@itemis.de>>:
>>>>> 
>>>>> i used that product and it actually found 2 more problematic candidates
>>>>> 
>>>>> gef dot - regarding guava
>>>>> and mylyn trac regarding gson
>>>>> 
>>>>> Am 06.08.19 um 08:59 schrieb Ed Willink:
>>>>>> Hi
>>>>>> 
>>>>>> The OOMPH integration is unlikely to help; it checks installability.
>>>>>> 
>>>>>> With a conflicting singleton such as Guava
>>>>>> - the 'left-hand' subsystem successfully installs using version X
>>>>>> - the 'right-hand' subsystem successfully installs using version Y
>>>>>> 
>>>>>> At run-time, any class passed in the 'API' between left and right 
>>>>>> subsystems gets a bad class version. This probably happens as an 
>>>>>> integrating system's class loader must 'choose' whether it uses 'left' 
>>>>>> or 'right' hand class versions.
>>>>>> 
>>>>>> If the 'API' is clean enough, e.g. no Optional, it can work.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Ed Willink
>>>>>> 
>>>>>> On 06/08/2019 07:43, Christian Dietrich wrote:
>>>>>>> @Michael do you mean this one (see screenshot)
>>>>>>> 
>>>>>>> Am 05.08.19 um 20:51 schrieb Michael Keppler:
>>>>>>>> Am 05.08.2019 um 17:43 schrieb Ed Willink:
>>>>>>>>> But no. Sorry deep integrators must suffer.
>>>>>>>> Unfortunately there is no cross-project integration testing. But I
>>>>>>>> vaguely remember Eike or Ed has shown an Oomph setup called "egg-laying
>>>>>>>> wool-milk-pig" containing everything from a release train at one of the
>>>>>>>> early Oomph presentations. Maybe one could do at least some manual
>>>>>>>> integration testing using that Oomph setup? However, I don't find any
>>>>>>>> link to that anymore.
>>>>>>>> 
>>>>>>>> Ciao, Michael
>>>>>>>> 
>>>>>>>> ___
>>>>>>>> cross-project-issues-dev mailing list
>>>>>>>> cross-project-issues-dev@eclipse.org 
>>>>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>>>>> To change your delivery options, retrieve your password, or
>>>>>>>> unsubscribe from this list, visit
>>>>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>

Re: [cross-project-issues-dev] Problems running Xtext and Buildship together

[Alexander Nyßen]

Well, it reported which plugins were provided in multiple versions. This way we 
could check that only one Guava version was able to satisfy all dependencies.

Cheers
Alexander


> Am 06.08.2019 um 09:08 schrieb Christian Dietrich 
> :
> 
> this wont help if its not a explicit singleton but a implicit one only 
> (classloaders are not completely isolated)
> 
> Am 06.08.19 um 09:07 schrieb Alexander Nyßen:
>> I remember we had a simrel report pointing out such duplicate singletons in 
>> the repo. Is that no longer available?
>> 
>> Cheers,
>> Alexander
>> 
>>> Am 06.08.2019 um 09:04 schrieb Christian Dietrich 
>>> mailto:christian.dietr...@itemis.de>>:
>>> 
>>> i used that product and it actually found 2 more problematic candidates
>>> 
>>> gef dot - regarding guava
>>> and mylyn trac regarding gson
>>> 
>>> Am 06.08.19 um 08:59 schrieb Ed Willink:
>>>> Hi
>>>> 
>>>> The OOMPH integration is unlikely to help; it checks installability.
>>>> 
>>>> With a conflicting singleton such as Guava
>>>> - the 'left-hand' subsystem successfully installs using version X
>>>> - the 'right-hand' subsystem successfully installs using version Y
>>>> 
>>>> At run-time, any class passed in the 'API' between left and right 
>>>> subsystems gets a bad class version. This probably happens as an 
>>>> integrating system's class loader must 'choose' whether it uses 'left' or 
>>>> 'right' hand class versions.
>>>> 
>>>> If the 'API' is clean enough, e.g. no Optional, it can work.
>>>> 
>>>> Regards
>>>> 
>>>> Ed Willink
>>>> 
>>>> On 06/08/2019 07:43, Christian Dietrich wrote:
>>>>> @Michael do you mean this one (see screenshot)
>>>>> 
>>>>> Am 05.08.19 um 20:51 schrieb Michael Keppler:
>>>>>> Am 05.08.2019 um 17:43 schrieb Ed Willink:
>>>>>>> But no. Sorry deep integrators must suffer.
>>>>>> Unfortunately there is no cross-project integration testing. But I
>>>>>> vaguely remember Eike or Ed has shown an Oomph setup called "egg-laying
>>>>>> wool-milk-pig" containing everything from a release train at one of the
>>>>>> early Oomph presentations. Maybe one could do at least some manual
>>>>>> integration testing using that Oomph setup? However, I don't find any
>>>>>> link to that anymore.
>>>>>> 
>>>>>> Ciao, Michael
>>>>>> 
>>>>>> ___
>>>>>> cross-project-issues-dev mailing list
>>>>>> cross-project-issues-dev@eclipse.org 
>>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>>> To change your delivery options, retrieve your password, or
>>>>>> unsubscribe from this list, visit
>>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>>>> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> cross-project-issues-dev mailing list
>>>>>> cross-project-issues-dev@eclipse.org 
>>>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>>>> from this list, visit
>>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
>>>>>> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>>  
>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>  Virus-free. 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 
>>>> <mailto:cross-project-issues-dev@eclipse.org>
>>>> To change your delivery options, retrieve your password, or unsubscribe 
>>>&

Re: [cross-project-issues-dev] Problems running Xtext and Buildship together

[Alexander Nyßen]

I remember we had a simrel report pointing out such duplicate singletons in the 
repo. Is that no longer available?

Cheers,
Alexander

> Am 06.08.2019 um 09:04 schrieb Christian Dietrich 
> :
> 
> i used that product and it actually found 2 more problematic candidates
> 
> gef dot - regarding guava
> and mylyn trac regarding gson
> 
> Am 06.08.19 um 08:59 schrieb Ed Willink:
>> Hi
>> 
>> The OOMPH integration is unlikely to help; it checks installability.
>> 
>> With a conflicting singleton such as Guava
>> - the 'left-hand' subsystem successfully installs using version X
>> - the 'right-hand' subsystem successfully installs using version Y
>> 
>> At run-time, any class passed in the 'API' between left and right subsystems 
>> gets a bad class version. This probably happens as an integrating system's 
>> class loader must 'choose' whether it uses 'left' or 'right' hand class 
>> versions.
>> 
>> If the 'API' is clean enough, e.g. no Optional, it can work.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 06/08/2019 07:43, Christian Dietrich wrote:
>>> @Michael do you mean this one (see screenshot)
>>> 
>>> Am 05.08.19 um 20:51 schrieb Michael Keppler:
 Am 05.08.2019 um 17:43 schrieb Ed Willink:
> But no. Sorry deep integrators must suffer.
 Unfortunately there is no cross-project integration testing. But I
 vaguely remember Eike or Ed has shown an Oomph setup called "egg-laying
 wool-milk-pig" containing everything from a release train at one of the
 early Oomph presentations. Maybe one could do at least some manual
 integration testing using that Oomph setup? However, I don't find any
 link to that anymore.
 
 Ciao, Michael
 
 ___
 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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
 
>>  
>> 
>>Virus-free. www.avast.com 
>> 
>>  
>> 
>> ___
>> 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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



signature.asc
Description: Message signed with OpenPGP
___
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] GEF participation in Photon

[Alexander Nyßen]

GEF will participate in photon with an offset of +1: 
https://projects.eclipse.org/projects/tools.gef/releases/5.1.0-photon 
<https://projects.eclipse.org/projects/tools.gef/releases/5.1.0-photon>.

Best Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Validating Aggregator fails because of legacy update site -> MAT

[Alexander Nyßen]

It’s strange, but it now looks like a false alarm. I locally re-enabled both, 
and now the validation succeeds. Strange, unless the referenced update-sites 
themselves have been touched in the mean-time…

Regards,
Alexander

> Am 23.05.2017 um 21:47 schrieb David Williams :
> 
> On 05/23/2017 01:47 PM, Alexander Nyßen wrote:
>> Hi all,
>> 
>> when validating the Oxygen aggregator on my machine, the validation fails 
>> because of an unsupported legacy update site. It seems this was introduced 
>> by updating MAT. If I disable MAT and Andmore (which depends on it), the 
>> validation succeeds on my local machine.
>> 
> I will also add, in case not obvious, that "legacy update sites" are 
> explicitly dis-allowed in the Sim. Rel. aggregation. The aggregator itself 
> should still allow it, if someone was building their own site and set the 
> property "Allow Legacy Sites" to "true".
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Validating Aggregator fails because of legacy update site -> MAT

[Alexander Nyßen]

Hi all,

when validating the Oxygen aggregator on my machine, the validation fails 
because of an unsupported legacy update site. It seems this was introduced by 
updating MAT. If I disable MAT and Andmore (which depends on it), the 
validation succeeds on my local machine.

Best Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Promoted gef-master #4353 as our preliminary RC1 contribution

[Alexander Nyßen]

Hi all,

now that the GEF HIPP is back again, I promoted gef-master #4353 as our 
preliminary RC1 contribution. We will probably update it later today, but do 
not expect larger changes.

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF HIPP still down - No Oxygen RC1 contribution today

[Alexander Nyßen]

I am sorry, but our GEF HIPP is still down, so I am not able to produce a 
contribution. We unfortunately have to postpone that until tomorrow...

Best Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF Oxygen RC1 will be late (our HIPP is down)

[Alexander Nyßen]

Hi all,

our RC1 contribution will be late. Our HIPP is currently not accessible, so we 
are not able to promote the milestone. The webmaster has been notified 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=517091).

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Alexander Nyßen]

Let's enforce that then. Looks like that would solve a lot of problems...

Cheers,
Alexander

> Am 31.03.2017 um 08:30 schrieb Mickael Istria :
> 
> The general rule would be "don't include in your feature what's not your 
> project". It's a rule that works great, but there's nothing in our processes, 
> UI nor build tools that enforces or even recommends it.

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Alexander Nyßen]

I have asked that several times already, but why do we allow individual 
projects to contribute Orbit bundles to simrel anyway? If the simrel aggregator 
would pull in the required Orbit bundles alone, it would have full control over 
which versions are bundled. Projects might yet bundle them in their own 
repositories (in dedicated features that are not promoted to the simrel 
aggregator), but IMHO even that could be avoided if the pointed to a respective 
simrel repository, from which to pull in third-party dependencies.

Cheers,
Alexander

> Am 31.03.2017 um 05:38 schrieb David Williams :
> 
> On 03/30/2017 02:45 PM, Gunnar Wagenknecht wrote:
>>> On 30. Mar 2017, at 19:10, Daniel Megert  wrote:
>>> I have never seen an announcement from Orbit that service release builds 
>>> for Orbit got dropped, but that seems to be the current reality, see 
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19.
>> I'm not entirely sure we ever officially had a maintenance/service build 
>> story in Orbit. Shouldn't the retention policy keep old bundles in place so 
>> that projects referencing those would still consume them during the Neon 
>> series?
>> 
>> FWIW, I recall that David did create a "maintenance" branch for a Mars SR 
>> back in the days but that was more of an "ad-hoc" thing. I never remember 
>> using a maintenance branch in Orbit.
> 
> We always had a maintenance build in Orbit when it was required. And we 
> deliberately kept it to as few changes as possible (i.e. only those that were 
> required and requested by a participant in the Sim. Release 
> maintenance/update release.
>> I think there is also another thing to consider. IMHO projects should stop 
>> hard-pinning specific 3rd party versions in the feature.xml -
> 
> This makes builds and installs non-deterministic. That seems like a lot to 
> give up. This isn't just a theoretical nicety. Especially with third party 
> jars (when we do not always know what versioning or API rules they follow). 
> It implies one set of tests on installs/updates using the "project's 
> repository" and another set of tests on installs/updates from the "Sim. 
> Release repository" (times the number of prereq repositories, in theory). And 
> THEN anyone doing long term maintenance addressing (possibly paying 
> customer's) issues has to wade through the possibly numerous versions of a 
> "release" that slightly differ based simply on which repositories were used 
> to not only create the products, but also which ones their customers used to 
> do updates (times the number of derivative products which might use other 
> sets of repositories).
> 
> And, don't forget, the looser you make the constraints the more you are 
> leaving it up to p2 to decide the "optimal solution" -- which is not always 
> what you would expect and not always the same, from one run to the next.
> 
> Gee, wouldn't it be nice just to build one big application instead of all 
> these pesky components. :)
> 
> 
> 
> _______
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] GEF(4) Neon.1 RC3 promotion will be late

[Alexander Nyßen]

The GEF(4) Neon.1 RC3 contribution is now in. Sorry for the delay.

Best Regards,
Alexander

> Am 05.09.2016 um 19:13 schrieb Alexander Nyßen :
> 
> As we are currently facing problems with our HIPP (the CentOS slave, which is 
> required for GEF4 builds is currently offline; the webmaster is already 
> notified), our (GEF4) Neon.1 contribution will be late. I will try to update 
> it as soon as these problems have been resolved (but probably not before 
> tomorrow).
> 
> Best Regards
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> 

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF(4) Neon.1 RC3 promotion will be late

[Alexander Nyßen]

As we are currently facing problems with our HIPP (the CentOS slave, which is 
required for GEF4 builds is currently offline; the webmaster is already 
notified), our (GEF4) Neon.1 contribution will be late. I will try to update it 
as soon as these problems have been resolved (but probably not before tomorrow).

Best Regards
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

[Alexander Nyßen]

Hi guys,

thanks to Tom and Dennis, GEF could now be fully enabled.

Cheers,
Alexander

> Am 10.08.2016 um 11:16 schrieb Ed Willink :
> 
> Hi Michael
> 
> EMFq, EMFt, EMFv have all been on minimal maintenance for the last five 
> years. Last year there was just M4, M7, RC3. The existing code is therefore 
> very stable.
> 
> The sole very part-time releng is generally busy with other priorities so you 
> could wait a long time unless you use your initiative.
> 
> Regards
> 
> Ed Willink
> 
> 
> On 10/08/2016 10:08, Wenz, Michael wrote:
>> Hi,
>> 
>> Ed, thanks for enabling EMF Validation, that brings me one step closer to 
>> being able to enable Graphiti as well.
>> 
>> Can anybody shed any light on the status of EMF Transaction? That is my last 
>> dependendency that is missing by now…
>> 
>> Thanks,
>> Michael
>> 
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>> [mailto:cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org>] On Behalf Of Ed 
>> Willink
>> Sent: Mittwoch, 10. August 2016 10:40
>> To: cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>> partially today
>> 
>> Hi
>> 
>> I had to use my initiative to enable EMF Validation. Aggregation build now 
>> looks promising. With EMF, EMFv, GEF, OCL, UML2, Xpand, Xtext contributed, 
>> perhaps the worst dependency cycles are now broken.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> 
>> On 10/08/2016 09:23, Ed Willink wrote:
>> HI
>> 
>> I have authority to enable UML2 with its Neon.0 contribution, so UML2 is now 
>> enabled. OCL coming as soon as the aggreagtion build status clarifies.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 10/08/2016 08:42, Dennis Hübner wrote:
>> Hello Alex,
>> I’ve enabled EMF, Xpand and Xtext in Oxyden. There are still some 
>> dependencies missing:
>> 
>> - ODA is missing for EMF
>> - UML2 is missing for Xpand
>> 
>> … but I think it should not block you.
>> 
>> Best regards,
>> Dennis.
>> 
>> Am 08.08.2016 um 17:34 schrieb Alexander Nyßen > <mailto:nys...@itemis.de>>:
>> 
>> Hi all,
>> 
>> I have just re-enabled the GEF repository for Oxygen and made available the 
>> Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to 
>> enable downstream projects that depend on it. The GEF (formerly known as 
>> GEF4) contribution to M1 is already prepared as well, but I had to disable 
>> it for now because it depends on downstream projects (namely e(fx)clipse and 
>> Xtext) that have not updated their contributions yet. GEF will thus not be 
>> available today but on Wednesday.
>> 
>> Regards,
>> Alexander
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Principal Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-202
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de <http://www.itemis.de/>
>> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
>> 
>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
>> Fiorentino
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto: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 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>> 
>> Viele Grüße,
>> Dennis Hübner
>> 
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.eclipse.org/mail

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

[Alexander Nyßen]

Hi Kaloyan,

Am 09.08.2016 um 15:55 schrieb Kaloyan Raev :
> 
> I really miss the root cause of the issue…
> 
> I don't understand how does it help breaking the SimRel build now and hoping 
> everything will be fine by the end of tomorrow.

I also do not think that breaking the build to enforce downstream contributions 
is the way to go, as it blocks all contributions via Gerrit.

> 
> As far as I understand, there are a few projects that depend on each other. 
> Is there any cycle in the dependency graph?

Even if there is no cycle (which could well be on the level of projects), there 
are several downstream dependencies (Ed and I have already pointed out two).

> 
> We are not building the Oxygen SimRel from scratch. It is based on the Neon 
> state.

No, it isn’t. The Neon contributions are all disabled by default.

> What have changed so significantly during Oxygen M1 so these project cannot 
> stage their contributions incrementally?

Nothing. Because of the downstream dependencies that exist, there is a lot of 
bootstrapping required for M1. As the Neon contributions are disabled, enabling 
a feature can only be performed after all prerequisites have been contributed 
to M1. This is the root cause...

> 
> Kaloyan

Regards,
Alexander

> 
> From: cross-project-issues-dev-boun...@eclipse.org 
>  on behalf of Alexander Nyßen 
> 
> Sent: Tuesday, August 9, 2016 4:38:00 PM
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
> partially today
> 
> I also fear that without enabling the Neon contributions the bootstrapping is 
> not to be done. We are virtually postponing it all to Wednesday, when we will 
> have to perform a piece-by-piece integration (probably on the level of 
> individual features), hoping that all projects actually contribute something. 
> GEF for instance depends on e(fx)clipse and Xtext, which - if I recollect 
> correctly - have not even stated their intention to participate in Oxygen. I 
> am keeping my fingers crossed...
> 
> Regards
> Alexander
> 
>> Am 09.08.2016 um 14:36 schrieb Ed Willink > <mailto:e...@willink.me.uk>>:
>> 
>> Hi
>> 
>> Co-ordination would be good, but we have a new policy whose consequences do 
>> not seem to have been appreciated.
>> 
>> Indeed it is +2, and I see no successful +1 contributions. Just GEF that 
>> enabled a Neon contribution to reduce its small contribution to the overall 
>> deadlock.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 09/08/2016 13:27, Kaloyan Raev wrote:
>>> Hi Ed,
>>> 
>>> Can't all these projects coordinate and make the necessary contributions 
>>> within a short time frame without leaving master broken for a long time?
>>> 
>>> It's already M1 +2 date and the rest of the projects should be able to do 
>>> their contributions.
>>> 
>>> Kaloyan
>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> 
>>>  
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed 
>>> Willink  <mailto:e...@willink.me.uk>
>>> Sent: Tuesday, August 9, 2016 3:20:07 PM
>>> To: cross-project-issues-dev@eclipse.org 
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> Subject: Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only 
>>> partially today
>>> 
>>> Hi
>>> 
>>> Feel free, but we have a policy problem.
>>> 
>>> The earlier discussion was on Xtext dependencies.
>>> 
>>> The build is currently failing because OCL depends on UML2 which is missing.
>>> 
>>> Once UML2 is fixed, OCL and/or UML2 will fail because EMF and/or Xtext is 
>>> missing.
>>> 
>>> We therefore have three choices.
>>> 
>>> Green all the way: No contribution is enabled till ALL prerequisites are 
>>> enabled. This will be very slow because of the recursive dependencies, 
>>> because relengs are not super-responsive, because it is August, because 
>>> some projects never contribute at M1, and because M1 used to be two rather 
>>> than one weeks long.
>>> 
>>> Red till green: contribute as normal, so that the validator identifies the 
>>> missing contributions.
>>> 
>>> The old way. Neon contributions are enabled by default.
>>> 
>>> I think the old way was better, but given that we are improving, I see 
>>> contribution enabling as appropriate so that the missing contributions are 

Re: [cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

[Alexander Nyßen]

> Ed Willink
>>> On 08/08/2016 18:27, David M Williams wrote:
>>>> > Can we have the Neon contributions available as in previous years?
>>>> 
>>>> Projects can do that, if they want -- as long as it is still "fits in".
>>>> But it is up to the project. They need to "declare intent" and provide a 
>>>> release record, AND THEN re-enable what every contribution they want to 
>>>> make.
>>>> 
>>>> Thanks,
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From:Ed Willink  <mailto:e...@willink.me.uk>
>>>> To:cross-project-issues-dev@eclipse.org 
>>>> <mailto:cross-project-issues-dev@eclipse.org>,
>>>> Date:08/08/2016 12:13 PM
>>>> Subject:Re: [cross-project-issues-dev] GEF Oxygen M1 contribution 
>>>> only partially today
>>>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>>>> <mailto:cross-project-issues-dev-boun...@eclipse.org>
>>>> 
>>>> 
>>>> 
>>>> Hi
>>>> OCL too cannot be enabled until Xtext is enabled.
>>>> I feel that this attempt to bootstrap from nothing is going to make for 
>>>> some very tight late coordination.
>>>> Can we have the Neon contributions available as in previous years?
>>>> If enabled="false" is required to enforce announced participation, surely 
>>>> it would be better to apply it just after M2 to all projects that have 
>>>> made no SimRel commit since Neon?
>>>> Regards
>>>> Ed Willink
>>>> 
>>>> On 08/08/2016 16:34, Alexander Nyßen wrote:
>>>> Hi all,
>>>> 
>>>> I have just re-enabled the GEF repository for Oxygen and made available 
>>>> the Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to 
>>>> enable downstream projects that depend on it. The GEF (formerly known as 
>>>> GEF4) contribution to M1 is already prepared as well, but I had to disable 
>>>> it for now because it depends on downstream projects (namely e(fx)clipse 
>>>> and Xtext) that have not updated their contributions yet. GEF will thus 
>>>> not be available today but on Wednesday.
>>>> 
>>>> Regards,
>>>> Alexander
>>>> --
>>>> Dr. Alexander Nyßen
>>>> Dipl.-Inform.
>>>> Principal Engineer
>>>> 
>>>> Telefon: +49 (0) 231 / 98 60-202
>>>> Telefax: +49 (0) 231 / 98 60-211
>>>> Mobil: +49 (0) 151 /  17396743
>>>> 
>>>> http://www.itemis.de <http://www.itemis.de/>
>>>> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
>>>> 
>>>> itemis AG
>>>> Am Brambusch 15-24
>>>> 44536 Lünen
>>>> 
>>>> Rechtlicher Hinweis:
>>>> 
>>>> Amtsgericht Dortmund, HRB 20621
>>>> 
>>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
>>>> 
>>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
>>>> Fiorentino
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org 
>>>> <mailto: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 
>>>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> 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 
>>>> <mailto: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-issu

[cross-project-issues-dev] GEF Oxygen M1 contribution only partially today

[Alexander Nyßen]

Hi all,

I have just re-enabled the GEF repository for Oxygen and made available the 
Neon release version of GEF-legacy (Draw2d/GEF (MVC) 3.x, Zest 1.x) to enable 
downstream projects that depend on it. The GEF (formerly known as GEF4) 
contribution to M1 is already prepared as well, but I had to disable it for now 
because it depends on downstream projects (namely e(fx)clipse and Xtext) that 
have not updated their contributions yet. GEF will thus not be available today 
but on Wednesday.

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF participating in Oxygen

[Alexander Nyßen]

Hi,

GEF will participate in Oxygen. Offset is +1 (as usual).

http://projects.eclipse.org/projects/tools.gef/releases/5.0.0-oxygen

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Signing issues related to fragment bundles

[Alexander Nyßen]

Hi all,

I am facing some strange signing issues in case of 4 fragment bundles we 
provide on our local update site 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=494334). Interestingly, only 
these four fragments seem to be problematic, and I wonder what is so special 
about them. If anyone could give me a hint on what could be going wrong I would 
highly appreciate that.

Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF4 contribution for RC1 updated

[Alexander Nyßen]

Hi David,

as the webmasters were able to revive the HIPP slave, the GEF4 contribution is 
now updated.

Cheers,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Update GEF contribution for RC1

[Alexander Nyßen]

Hi David,

I intend to update our GEF Neon RC1 contribution to include an important fix, 
which we do not want to postpone to RC2.

Unfortunately, three hours ago the connection between our GEF HIPP and the 
required centos slave went offline before the build with the required changes 
could complete (it was aborted two minutes early). I have notified the 
webmasters and will update our contribution as soon as possible, but I wanted 
to let you know that it may be late.

Cheers,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Some Neon Reminders

[Alexander Nyßen]

Hi Wayne,

I do not know whether this is a killer feature, but we will release GEF4 1.0.0 
(i.e. GEF 4.0.0) with Neon. Maybe that’s worth a notification.

Cheers
Alexander

> Am 27.04.2016 um 18:56 schrieb Wayne Beaton :
> 
> Hey folks. We're getting close. Please remember:
> 
> May 26/2016 - IP Log submission deadline
> June 2/2016 - Review materials due
> 
> If you want your project featured in the aggregated new and noteworthy 
> document [1], you need to set the New & Noteworthy URL field in the Review 
> section of your project's Neon release record [2].
> 
> When it comes to marketing the release, it's really all about the end user 
> IDE features. If you have any killer new features, please let me know ASAP.
> 
> Thanks,
> 
> Wayne
> 
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=485299 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=485299>
> [2] https://projects.eclipse.org/releases/neon 
> <https://projects.eclipse.org/releases/neon>
> 
> --
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
>  
> <http://www.eclipsecon.org/france2016>___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] On the issue of building with thelatest Orbit repository

[Alexander Nyßen]

What about the following policy?

1) Ensure that none of the features contributed to simrel include any Orbit 
bundles, but only refer to them via dependencies (and ensure that proper 
version constraints are used in addition).
2) Use specific all-in-one features that include the required Orbit bundles 
(and the features deployed to simrel), but only use them to produce 
self-contained local drop files (zip).
3) Do not publish all-in-one features on your local update sites either, but 
rather have your local update-sites refer to the simrel update-site via an 
associate-site entry (so Orbit dependencies get pulled in from there).

With 1) we would have a single authority that controls which Orbit bundles are 
actually provided in a release, namely the simrel aggregator. 2) would cover 
your use case, Ed. 3) would ensure that newer Orbit bundles (added in a 
maintenance release) would also get picked up when installing from a local 
update-site.

Cheers
Alexander

> Am 05.02.2016 um 20:22 schrieb Ed Willink :
> 
> Hi Konstantin
> 
> I have no idea how a download ZIP can easily mirror something.
> 
> But I presume what you really mean is that we should produce two 
> ZIPs/categories.
> 
> - A contribution ZIP/category that replicates the features contributed to 
> SimRel.
> - An All-in-One ZIP/category that additionally bundles Orbit facilities 
> avoiding the need for users to learn how to include Orbit in the available 
> sites.
> 
> Regards
> 
> Ed Willink
> 
> On 05/02/2016 17:33, Konstantin Komissarchik wrote:
>> I would advise strongly against using the feature includes directive for 
>> Orbit bundles. While doing so provides a cheap way to mirror the Orbit 
>> bundle into the produced project repository, it also locks you down to using 
>> that one version of the bundle and we end up with multiple versions of 
>> various bundles in the install, often for no good reason. It’s easy enough 
>> to mirror the required Orbit bundles using a separate step at the end of the 
>> project build and be free to require the bundle via whatever version range 
>> is most appropriate.
>> 
>> If everyone did this and simrel aggregation included the latest Orbit 
>> repository, the result of aggregation would contain fewer duplicate Orbit 
>> bundles without requiring projects to issue a new release just to move to a 
>> newer version of an Orbit bundle.
>> 
>> Thanks,
>> 
>> - Konstantin
>> 
>> 
>> From: Ed Willink <mailto:e...@willink.me.uk>
>> Sent: Thursday, February 4, 2016 11:11 PM
>> To: cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] On the issue of building with 
>> thelatest Orbit repository
>> 
>> Hi David
>> 
>> Interesting if you're right. I thought projects needed to bundle what wasn't 
>> bundled upstream. Thus OCL bundles LPG since no one else does. OCL includes 
>> ASM, Guava that someone else bundles.
>> 
>> You suggest that OCL could stop bundling LPG since LPG would appear in the 
>> SimRel repo automatically.
>> 
>> However OCL still needs to bundle LPG in order for the install from ZIPs to 
>> work offline. AFAIK there is no SimRel ZIP distribution. If there was, it 
>> would probably be so big that few would use it. However if there was a 
>> used-in-SimRel-Orbit ZIP distribution that could be useful and could help 
>> you enforce limited usage.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 04/02/2016 21:35, David M Williams wrote:
>> Off the top of my head, I think features are suppose to 'include' them, 
>> since that is the only way to have a reproducible build or install. If it 
>> was left up to "requires" then who knows what you would get.
>> Granted, there should not be anything breaking, if you simply took a what 
>> ever was there, within some specified range, but especially with third party 
>> bundles, you never know. Some are real good at following good versioning 
>> practices, some are not.  Plus, keep in mind, the "aggregated repository" is 
>> supposed to be a simple grouping of a subset of what ever is in the project 
>> repositories. We do not want a situation where if someone installs directly 
>> from "your" repository, they get one set of things, and if they install from 
>> the Sim. Release repository they get another set of things. Maintenance 
>> would be very difficult, then. To repeat, that's off the top of my head. 
>> Maybe you meant something else.
>> 
>> 
>> 
>> 
>

Re: [cross-project-issues-dev] On the issue of building with the latest Orbit repository

[Alexander Nyßen]

cross-project-issues-dev-boun...@eclipse.org 
>> <mailto:cross-project-issues-dev-boun...@eclipse.org>
>> 
>> 
>> 
>> Hi David
>> 
>> On 03/02/2016 22:29, David M Williams wrote:
>> - Every contribution file has changed since Mars.1. Also good. (i.e. no 
>> projects are just sleeping and forgot to update :)
>> 
>> You might want to review your query. qvtd.b3aggrcon was last changed by me 
>> on 26 June, and by you on 14 July.
>> 
>> We are certainly not sleeping, and did not forget to update. Just working 
>> very hard to support the functionality required for graduation to 1.0.0.
>> And ... worst of all, IMHO, some "old" third party jars are still being 
>> used, which implies to me someone is not using the latest version of Orbit 
>> (R20151221205849).
>> But if a project has no maintenance to contribute, I thought no 
>> rebuild/contribution was required and so of course an old Orbit would be in 
>> use. (I don't think that QVTd imposes tight bounds on Orbit contributions.)
>> 
>> Regards
>> 
>> Ed Willink___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto: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 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto: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 
>> <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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Ready for Mars.2 ?

[Alexander Nyßen]

Hi David,

I was wondering about your first statement also, as GEF is not contributing 
something new to Mars.2 either (we are fully concentrating on our 4.0.0 release 
for Neon). Our contribution to Mars.2 should be the same as that to Mars, and 
as far as I can see that is indeed the case.

Regards
Alexander

> Am 04.02.2016 um 07:08 schrieb Ed Willink :
> 
> Hi David
> 
> On 03/02/2016 22:29, David M Williams wrote:
>> - Every contribution file has changed since Mars.1. Also good. (i.e. no 
>> projects are just sleeping and forgot to update :)
>> 
> You might want to review your query. qvtd.b3aggrcon was last changed by me on 
> 26 June, and by you on 14 July.
> 
> We are certainly not sleeping, and did not forget to update. Just working 
> very hard to support the functionality required for graduation to 1.0.0.
>> And ... worst of all, IMHO, some "old" third party jars are still being 
>> used, which implies to me someone is not using the latest version of Orbit 
>> (R20151221205849).
> But if a project has no maintenance to contribute, I thought no 
> rebuild/contribution was required and so of course an old Orbit would be in 
> use. (I don't think that QVTd imposes tight bounds on Orbit contributions.)
> 
> Regards
> 
> Ed Willink
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF4 Neon M5 final contribution is in.

[Alexander Nyßen]

Hi all,

I have just added our final GEF4 contribution to Neon M5. Apologies for the 
delay.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF4 contribution to Neon M5 will be late (build problems because signing service seems to be down)

[Alexander Nyßen]

Hi all,

I have promoted our GEF 3.x contribution to Neon M5, as well as a preliminary 
GEF4 contribution. We intend to update the latter as soon as the build problems 
we currently face (signing seems to be down) are resolved (if that happens in 
time). I will post here when the final contribution is available.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] JDK 9 Early Access with Project Jigsaw

[Alexander Nyßen]

>> 
>> Pay heed to my comment about Class.forName(...) above. You may have to
>> test your code directly. You should probably do that anyway.
>> 
>> Wayne
>> 
>> [0]
>> https://waynebeaton.wordpress.com/2015/11/16/eclipse-ide-on-jdk-9-early-access-with-project-jigsaw/
>> [1] https://jdk9.java.net/jigsaw/
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=482318
>> --
>> Wayne Beaton
>> @waynebeaton
>> The Eclipse Foundation
>> EclipseCon Europe 2015 <http://www.eclipsecon.org/europe2015>
>> 
>> 
>> ___
>> 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
>> 
> 
> 
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] GEF participation in Neon

[Alexander Nyßen]

Hi David, please find my comments below.

> Am 24.08.2015 um 14:49 schrieb David M Williams :
> 
> Thanks Alexander, for letting us know. I myself won't object to your "M5" 
> timing, and since is for GEF4 (not GEF in general) I suspect all is fine, 
> either way.
> 
> But, I wanted to remind you, and the whole "extended team", that it is best 
> to settle these issues as soon as possible. The reason is that some (many?) 
> projects like  (or need) to support running on more than one version of 
> Eclipse (such as current -1, or a few even do current -2).  For those 
> projects, if they used GEF 4, they *might* need to do something special to 
> handle such a change  ... so ... for them, the earlier they know, the better 
> they can react OR, perhaps, even change their plans (and then they have to 
> let their adopters know too, etc.)

As stated, we want to take that decision with M5 at the latest, which is well 
before API and feature freeze. There are a couple of themes we want to address 
(see 
https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon/plan 
<https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon/plan>),
 and the decision will be mostly based on the progress and results achieved 
there.

> 
> Would your change from "0" to "1" reflect "breaking API" (such as, would you 
> be renaming packages from "provisional" or "internal" to be true "API 
> packages"? Or, does the versioning just reflect whether or not you've 
> graduated?

GEF4 is not in incubating state, its not even a sub-project of GEF. Technically 
speaking, all GEF4 components are pure provisional API of the GEF project (i.e. 
all exported GEF4 packages are currently guarded by x-internals or x-friends). 
We have decided to use the 0.x versions for the GEF4 bundles and features only 
to indicate that there is no public API yet (and that breaking changes of the 
provisional API might occur between minor revisions, which already happened 
between 0.1.0 and 0.2.0). For Neon, we will break (provisional) API in either 
case, even if we decide to only publish 0.3.0. The step from „0“ to „1“ would 
basically mean that we decide to turn some or all of our provisional API into 
public API (i.e. remove the x-internals).

> 
> Again, for your case, I doubt it would matter (too much :), but I thought 
> best to explicitly document how "major" increases can impact others in ways 
> that some might not be aware of. Not everyone is concerned with "just the 
> current release".
> 
> I personally think "graduation" is not too related to the "state of your 
> code", but more to your ability to demonstrate you are a self running 
> project, with some adopters, involved with community, etc. So, for example, 
> even if you publish "1.x" with what ever you have, if you decide to make 
> breaking API changes after that  then you'd just go to "2.x". Make sense? 
> But, I am aware that others might think differently, and I can see pros and 
> cons with both methods.

With the long history of GEF and the stability its API has had in the last ten 
years, flipping the bit from „0“ to „1“ for GEF4 will be a „statement" to our 
community. That’s the reason why my team wants to postpone the decision until 
we are sure that this stability is reached. Technically speaking, I would 
rather sooner than later switch to 1.0.0 because that would mean we could 
properly employ API tooling and rely on OSGi versions to indicate compatibility.

> 
> Thanks again, good luck!

Thanks!

> 
> 
> 
> 
> 
> 
> 
> From:Alexander Nyßen 
> To:Cross project issues ,
> Date:08/23/2015 07:07 AM
> Subject:[cross-project-issues-dev] GEF participations in Neon
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> GEF will participate in Neon and will contribute either a minor (3.11.0) or a 
> major (4.0.0) release: 
> https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon 
> <https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon>. 
> The decision depends on whether GEF4 is to be graduated to 1.0.0 (or a minor 
> 0.3.0 revision is published instead). The team has decided to leave this 
> decision open up to M5. We will start with contributing GEF4 in version 0.3.0 
> to M2.
> 
> The offset will stay at +1.
> 
> Cheers
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemi

Re: [cross-project-issues-dev] e(fx)clipse 2.1.0 for Mars.1

[Alexander Nyßen]

GEF4 has dependencies to org.eclipse.fx.runtime.min.feature only, not on the 
tooling. We specify it as follows, so 2.1.0 should indeed be no problem from a 
composition viewpoint.

https://git.eclipse.org/r/#/c/54379/
>> [2]https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE.gerrit/55/
>> 
> 
> 
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Staging repos are complete for Mars.1 RC1 and Neon M1

[Alexander Nyßen]

> Like I said. We are to other Eclipse Projects a leaf project where the
> only known Eclipse dependency is GEF4 who is itself in incubation.

Just to clarify: GEF4 is not incubation. Its provisional API of GEF.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF participations in Neon

[Alexander Nyßen]

GEF will participate in Neon and will contribute either a minor (3.11.0) or a 
major (4.0.0) release: 
https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon 
<https://projects.eclipse.org/projects/tools.gef/releases/3.11.04.0.0-neon>. 
The decision depends on whether GEF4 is to be graduated to 1.0.0 (or a minor 
0.3.0 revision is published instead). The team has decided to leave this 
decision open up to M5. We will start with contributing GEF4 in version 0.3.0 
to M2.

The offset will stay at +1.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Removing non related projects when triaging AERI issues

[Alexander Nyßen]

Because GEF is contained in pretty much all the stack traces of its adopters 
(GMF, Sirius, Papyrus and others) I find myself triaging several issues that 
are actually not related to problems in GEF. That’s fine, I don’t want to 
lament that GEF has a lot of adopters and of course I want to support them all. 
However, I recently ran into cases were issues were indeed already triaged 
(i.e. a bugzilla was created for a specific project), but the list of projects 
was not adjusted. In order to reduce overhead, it would IMHO be a good policy 
to remove other projects from an AERI issue in case triaging leads to a 
bugzilla for a specific project (the projects list can easily be edited during 
triaging, and non-related projects can simply be removed from it).

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Project owning 'org.eclipse.event.recorder'

[Alexander Nyßen]

I am not so sure about Google really saying so (at least I can’t find a hit 
with the exact package name), but it seems to be a local bundle (the list of 
active bundles lists it with 1.0.0.qualifier). Maybe its not related to an 
Eclipse project at all, but the anonymous reporter has simply (mis-)used an 
Eclipse namespace for some local bundle.

Cheers
Alexander

> Am 01.06.2015 um 20:48 schrieb Wim Jongman :
> 
> Google says TPTP ;)
> 
> https://www.google.com/search?q=org.eclipse.event.recorder.listeners&ie=utf-8&oe=utf-8
>  
> <https://www.google.com/search?q=org.eclipse.event.recorder.listeners&ie=utf-8&oe=utf-8>
> 
> On Mon, Jun 1, 2015 at 7:25 PM, Alexander Nyßen  <mailto:nys...@itemis.de>> wrote:
> When triaging 
> https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details
>  
> <https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details>
>  I ran across the package name ‚org.eclipse.event.recorder.listeners‘. Can 
> anybody tell which project owns it?
> 
> Cheers
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202 
> 
> Telefax: +49 (0) 231 / 98 60-211 
> 
> Mobil: +49 (0) 151 /  17396743 
> 
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto: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 
> <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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Project owning 'org.eclipse.event.recorder'

[Alexander Nyßen]

When triaging 
https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details
 
<https://dev.eclipse.org/recommenders/committers/confess/#/problems/55144304e4b0b71121dae2c4/details>
 I ran across the package name ‚org.eclipse.event.recorder.listeners‘. Can 
anybody tell which project owns it?

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Trigger simrel.mars.runaggregator.VALIDATE when pushing directly to repo

[Alexander Nyßen]

You are right, I am actually able to manually trigger the VALIDATE build (after 
having logged in). I probably looked into it now without having logged in and 
had a look into a different build (when having been logged in) before. Sorry 
for that.

However, the Git changes do not seem to be recognized properly. I raised 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=468866 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=468866> to keep track of it.

Cheers
Alexander

> Am 29.05.2015 um 21:51 schrieb David M Williams :
> 
> You should be able to trigger a build. You have to log-in, of course. But if 
> you can commit to org.eclipse.simrel.build repo, you should be able to build. 
> (that job, not others) ... at least I set it up that way, with that group 
> having the 'build" checkbox "on". And it is set up to check for Git changes, 
> once every 15 minutes. And, the Git polling log looks normal. (below).
> 
> If anyone sees anything other than the above intended behavior, please open a 
> cross-project bug and I'll investigate.
> 
> = = = = = =
> 
> Started on May 29, 2015 3:46:01 PM
> Using strategy: Default
> [poll] Last Build : #317
> [poll] Last Built Revision: Revision da42bbcecff928795ace19e0a1d76524355798bc 
> (origin1/master)
> Fetching changes from the remote Git repositories
> Fetching upstream changes from 
> git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build
> Seen branch in repository origin/Juno_maintenance
> Seen branch in repository origin/Juno_maintenance_A
> Seen branch in repository origin/KeplerPostRC4_branch
> Seen branch in repository origin/Kepler_maintenance
> Seen branch in repository origin/Luna_maintenance
> Seen branch in repository origin/Luna_maintenance_limited
> Seen branch in repository origin/david_williams/testMultiSets
> Seen branch in repository origin/david_williams/testnewbuild
> Seen branch in repository origin/master
> Fetching changes from the remote Git repositories
> Fetching upstream changes from 
> git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.tools
> Seen branch in repository origin1/Kepler_maintenance
> Seen branch in repository origin1/david_williams/testTests
> Seen branch in repository origin1/david_williams/testnewbuild
> Seen branch in repository origin1/master
> Fetching changes from the remote Git repositories
> Fetching upstream changes from 
> git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.tests
> Seen branch in repository origin2/Kepler_maintenance
> Seen branch in repository origin2/david_williams/testTests
> Seen branch in repository origin2/david_williams/testnewbuild
> Seen branch in repository origin2/dhubner/junit
> Seen branch in repository origin2/master
> Done. Took 1 sec
> No changes
> 
> 
> 
> 
> From:Alexander Nyßen 
> To:Cross project issues ,
> Date:05/29/2015 03:26 PM
> Subject:[cross-project-issues-dev] Trigger
> simrel.mars.runaggregator.VALIDATE when pushing directly to repo
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> Is there a way to trigger simrel.mars.runaggregator.VALIDATE after having 
> pushed directly to the repo (i.e. not via Gerrit)?
> 
> To me it seems the build is neither configured to watch Git for changes nor 
> does it allow committers to manually trigger a build. If pushing to the repo 
> directly is an option, there should IMHO also be a way to trigger a build 
> afterwards.
> 
> Cheers
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
> ___
> 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 
> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev

[cross-project-issues-dev] Trigger simrel.mars.runaggregator.VALIDATE when pushing directly to repo

[Alexander Nyßen]

Is there a way to trigger simrel.mars.runaggregator.VALIDATE after having 
pushed directly to the repo (i.e. not via Gerrit)?

To me it seems the build is neither configured to watch Git for changes nor 
does it allow committers to manually trigger a build. If pushing to the repo 
directly is an option, there should IMHO also be a way to trigger a build 
afterwards.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Is it time to update to Guava 18?

[Alexander Nyßen]

Should we raise a bug against RCPTT then? As we know from past experience, 
mixing different Guava versions might be harmful. 

Cheers 
Alexander

Von meinem iPhone gesendet

> Am 07.05.2015 um 12:35 schrieb Pierre-Charles David 
> :
> 
> Le 07/05/2015 09:16, Alexander Nyßen a écrit :
>> Hi,
>> 
>> I am not sure if this actually is a problem, but it might be something to 
>> watch: If I interpret the latest unique version repo reports 
>> (http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/nonUniqueVersions.txt)
>>  correctly, they seem to indicate that some projects are still pulling in 
>> Guava 12:
>> 
>> com.google.guava
>>12.0.0.v201212092141
>>15.0.0.v201403281430
> 
> It looks like Guava 12 comes from 
> http://download.eclipse.org/rcptt/milestone/2.0.0/M4/repository:
> 
> From the SimRel build's log:
> 
> [exec] Mirroring artifacts from 
> file:///home/data/httpd/download.eclipse.org/rcptt/milestone/2.0.0/M4/repository
> [...]
> [exec] - mirroring artifact osgi.bundle,com.google.guava,12.0.0.v201212092141
> 
> 
> ___
> 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

Re: [cross-project-issues-dev] Is it time to update to Guava 18?

[Alexander Nyßen]

*anyone*
>>>> may supply another Guava bundle.
>>>> 
>>> Yes. That could work, but not for Mars because it imposes a new
>>> requirement on all SimRel products that integrate multiple Guava users.
>>> But it severely undermines Eclipse as a useful integration platform.
>> I don't quite understand. What do you mean by "SimRel products". IMHO,
>> the burden is solely with bundles C which depend on multiple bundles A
>> and B that expose Guava in their API. If the developers of C do their
>> homework, then the maintainer of a "SimRel product" (I assume you mean
>> something like ann EPP package) does not have to worry about multiple
>> Guava's being shipped as part of that product.
>> 
>>> IMHO, and I think 'uses' does this, then if A and B announce what they
>>> use, then the class loader for the integrator chooses a jointly
>>> compatible Guava.
>> I thought so, too, but (as Thomas Watson explained [1]) with Equinox
>> this is unfortunately not always the case. Here's the scenario:
>> 
>>  - Bundle A requires either Guava version X or Y
>>  - Bundle B requires Guava version Y
>>  - C requires both A and B.
>> 
>> All bundles have correct uses constraints.
>> 
>>  - A is installed first (causing version X to be installed)
>>  - Equinox wires A to X
>>  - B is installed second (causing version Y to be installed)
>>  - Equinox wires B to Y
>>  - C is installed
>>  - Equinox cannot wire C to A and B *without* requiring A to Y
>> 
>> As Equinox (without "-clean") won't rewire existing bundles, C cannot be
>> resolved, even though a solution exists.
>> 
>> A similar situation arises if C = B, i.e., C both requires Guava itself
>> and a bundle A that exposes Guava in its API. But with three bundles
>> things are easier to explain, even though the two-bundle scenario is
>> probably more common.
>> 
>>> If this fails, most commonly this will be a compile
>>> time version failure because A  and B have no overlap; an integrator's
>>> bug. Rarely it may occur at run-time if no Guava version from the
>>> overlap is available, a user's bug. Both are sensible, diagnosable and
>>> fixable leaving Eclipse as a good flexible integration platform.
>> Sorry, I don't understand what you are saying here. Can you please
>> reword and possibly expand your explanation?
>> 
>> Best wishes,
>> 
>> Andreas
>> 
>> [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=438453#c13>
>> 
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Ramp-down policy for Mars

[Alexander Nyßen]

That’s (i.e. one per top-level project) what I actually meant. I will then 
continue to annoy the Tools PMC…

Cheers
Alexander

> Am 04.05.2015 um 16:04 schrieb Daniel Megert :
> 
> > Nevertheless I wonder on what basis statements like "PMC must approve all 
> > feature work and API changes.“ are made. Is there a 
> > top-level-project-specific ramp down plan that covers this kind of things?
> 
> No. Each (top-level) project has its own rules. Some still allow feature work 
> during ramp-down without approvals.
> 
> Dani
> 
> 
> 
> From:Alexander Nyßen 
> To:Cross project issues 
> Date:04.05.2015 16:00
> Subject:Re: [cross-project-issues-dev] Ramp-down policy for Mars
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> Thanks Dani,
> 
> indeed that helps.
> 
> Nevertheless I wonder on what basis statements like "PMC must approve all 
> feature work and API changes.“ are made. Is there a 
> top-level-project-specific ramp down plan that covers this kind of things?
> 
> Cheers
> Alexander
> 
> Am 04.05.2015 um 15:25 schrieb Daniel Megert  <mailto:daniel_meg...@ch.ibm.com>>:
> 
> Hi Alexander
> 
> There is no cross-project ramp-down plan. If it helps, here is the endgame 
> plan that the Eclipse top-level project follows:
> https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_5.php 
> <https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_5.php>
> 
> Dani
> 
> 
> 
> From:Alexander Nyßen mailto:nys...@itemis.de>>
> To:Cross project issues  <mailto:cross-project-issues-dev@eclipse.org>>
> Date:04.05.2015 15:19
> Subject:[cross-project-issues-dev] Ramp-down policy for Mars
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> <mailto:cross-project-issues-dev-boun...@eclipse.org>
> 
> 
> 
> As we are passing M7, I was wondering whether there is an official ramp-down 
> policy all projects should follow (i.e. from when on changes will have to be 
> reviewed by the project lead, PMC, etc.). I ran across these kinds of 
> statements in old release plans but cannot find an up-to-date statement 
> concerning it. Where would I have to look?
> 
> Cheers
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> [attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto: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 
> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto: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 
> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> [attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] 
> ___
> cross-project-is

Re: [cross-project-issues-dev] Ramp-down policy for Mars

[Alexander Nyßen]

Thanks Dani,

indeed that helps.

Nevertheless I wonder on what basis statements like "PMC must approve all 
feature work and API changes.“ are made. Is there a top-level-project-specific 
ramp down plan that covers this kind of things?

Cheers
Alexander

> Am 04.05.2015 um 15:25 schrieb Daniel Megert :
> 
> Hi Alexander
> 
> There is no cross-project ramp-down plan. If it helps, here is the endgame 
> plan that the Eclipse top-level project follows:
> https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_5.php 
> <https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_5.php>
> 
> Dani
> 
> 
> 
> From:Alexander Nyßen 
> To:Cross project issues 
> Date:04.05.2015 15:19
> Subject:[cross-project-issues-dev] Ramp-down policy for Mars
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> As we are passing M7, I was wondering whether there is an official ramp-down 
> policy all projects should follow (i.e. from when on changes will have to be 
> reviewed by the project lead, PMC, etc.). I ran across these kinds of 
> statements in old release plans but cannot find an up-to-date statement 
> concerning it. Where would I have to look?
> 
> Cheers
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
> 
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de <http://www.itemis.de/>
> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
> Fiorentino
> 
> 
> [attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM] 
> ___
> 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 
> <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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Ramp-down policy for Mars

[Alexander Nyßen]

As we are passing M7, I was wondering whether there is an official ramp-down 
policy all projects should follow (i.e. from when on changes will have to be 
reviewed by the project lead, PMC, etc.). I ran across these kinds of 
statements in old release plans but cannot find an up-to-date statement 
concerning it. Where would I have to look?

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Notice of change to batch "signing service"

[Alexander Nyßen]

a:83)
>>>> 
>>>>at
>>>> org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus(SimpleArtifactRepository.java:1184)
>>>> 
>>>>at
>>>> org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:591)
>>>> 
>>>>at
>>>> org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:724)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromOneMirror(RepositoryArtifactProvider.java:209)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyMirror(RepositoryArtifactProvider.java:192)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.access$1(RepositoryArtifactProvider.java:187)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider$1.perform(RepositoryArtifactProvider.java:167)
>>>> 
>>>>at
>>>> org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:708)
>>>> 
>>>>at
>>>> org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifacts(SimpleArtifactRepository.java:779)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyChildRepository(RepositoryArtifactProvider.java:179)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnyFormatAvailableInRepository(RepositoryArtifactProvider.java:149)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.repository.RepositoryArtifactProvider.getArtifactFromAnySource(RepositoryArtifactProvider.java:135)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.p2base.artifact.provider.CompositeArtifactProviderBaseImpl.getArtifact(CompositeArtifactProviderBaseImpl.java:50)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadCanonicalArtifact(MirroringArtifactProvider.java:236)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadMostSpecificNeededFormatOfArtifact(MirroringArtifactProvider.java:229)
>>>> 
>>>>at
>>>> org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:214)
>>>> 
>>>>... 26 more
>>>> Caused by: java.security.SignatureException: Error occurs parsing the
>>>> .SF file to find out the digest algorithm in this bundle:
>>>> /tmp/signatureFile5309382464664284679.jar
>>>>at
>>>> org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner(SignatureBlockProcessor.java:101)
>>>> 
>>>>at
>>>> org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process(SignatureBlockProcessor.java:61)
>>>> 
>>>>at
>>>> org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent(SignedBundleFile.java:44)
>>>> 
>>>>at
>>>> org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent(SignedBundleHook.java:215)
>>>> 
>>>>... 47 more
>>>> [ERROR]
>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>>> the -e switch.
>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>> [ERROR]
>>>> [ERROR] For more information about the errors and possible solutions,
>>>> please read the following articles:
>>>> [ERROR] [Help 1]
>>>> http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
>>>> [DEBUG] Waiting for process to finish
>>>> [DEBUG] Result: 1
>>>> Sending e-mails to: tom.schi...@bestsolution.at
>>>> Finished: FAILURE
>>> I'm not sure what I should learn from that but something is seriously
>>> broken now!
>>> 
>>> Tom
>>> 
>>> On 15.04.15 09:24, Wim Jongman wrote:
>>>> 
>>>> On Tue, Apr 14, 2015 at 7:10 PM, Tom Schindl
>>>> mailto:tom.schi...@bestsolution.at>>
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Not sure this is related but I've now seen my build failing
>>>> because of
>>>> pack200 and on the next run succeeding.
>>>> 
>>>> 
>>>> I have seen the same in the Nebula Gerrit build. First a pack problem
>>>> and then a normal build.
>>>> 
>>>> Cheers,
>>>> 
>>>> Wim
>>>> 
>>>> 
>>>> ___
>>>> 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
> 
> 
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Notice of change to batch "signing service"

[Alexander Nyßen]

 
> But, the advantage is, in some service release, there might be a new version 
> and we'd pick it up automatically, as long as we use 
> /shared/common/jdk1.8.0_x86-latest consistently.  Double bonus: remember that 
> pack200 and unpack200 have little to do with Java source code they are 
> stand-alone executables, written in C-code, that simply manipulate byte 
> codes. Which is how p2 can let you specify any version of pack200 you want 
> <https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no mater 
> which version of Java you are using.
> 
> Naturally, feel free to comment in Bug 463510 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510> if any questions or 
> concrete problems known.
> 
> 
> 
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Problem with http://download.eclipse.org/eclipse/updates/4.5?

[Alexander Nyßen]

Ed,

thanks for having pointing that out. I used to be aware about the fact that 
there’s a specific update site for the platform milestones, but it seems I 
forgot and now got irritated by the fact that 
http://download.eclipse.org/releases/mars 
<http://download.eclipse.org/releases/mars> is populated while  
http://download.eclipse.org/eclipse/updates/4.5/ 
<http://download.eclipse.org/eclipse/updates/4.5/> is not.

Cheers
Alexander

> Am 29.03.2015 um 17:30 schrieb Ed Merks :
> 
> Alexander,
> 
> Yes, that site is mostly empty, and I think that's intentional.  I believe 
> you'll want to use http://download.eclipse.org/eclipse/updates/4.5milestones 
> <http://download.eclipse.org/eclipse/updates/4.5milestones> until 4.5 is 
> actually released.
> 
> Cheers,
> Ed
> 
> On 29/03/2015 5:21 PM, Alexander Nyßen wrote:
>> When trying to install API tools execution environment descriptions from 
>> http://download.eclipse.org/eclipse/updates/4.5 
>> <http://download.eclipse.org/eclipse/updates/4.5> I failed as no contents 
>> seems to be resolvable. Can it be that the site is not properly populated?
>> 
>> Cheers
>> Alexander
>> 
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Principal Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-202
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de <http://www.itemis.de/>
>> alexander.nys...@itemis.de <mailto:alexander.nys...@itemis.de>
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
>> Fiorentino
>> 
>> 
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto: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 
>> <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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Problem with http://download.eclipse.org/eclipse/updates/4.5?

[Alexander Nyßen]

When trying to install API tools execution environment descriptions from 
http://download.eclipse.org/eclipse/updates/4.5 
<http://download.eclipse.org/eclipse/updates/4.5> I failed as no contents seems 
to be resolvable. Can it be that the site is not properly populated?

Cheers
Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF contribution for M5 updated (only GEF4)

[Alexander Nyßen]

To include two important bug fixes, I re-promoted the GEF4 features for Mars 
M5. The promotion now points to gef4-master #2172, the simrel aggregator file 
was updated accordingly. Sorry for any inconvenience that might (have) cause(d).

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de
alexander.nys...@itemis.de

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer 
Fiorentino





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Mars M3: Wiring problems with HttpClient/Core 4.2.x and 4.3.x both present

[Alexander Nyßen]

Hi Andreas, 

that looks similar to what we have been discussing at: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107.

Cheers
Alexander

Am 10.11.2014 um 12:03 schrieb Andreas Sewe :

> Hi,
> 
> we at Eclipse Code Recommenders recently got a bug report [1] about a
> bundle resolution failure in Mars M3.
> 
> Apparently, the fact that Mars M3 ships Apache HttpClient/Core 4.3.x
> rather than 4.2.x causes Eclipse Aether (which Code Recommenders uses
> internally) to not resolve properly:
> 
>>  org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
>> Unable to resolve resource org.eclipse.aether.transport.http [osgi.identity; 
>> osgi.identity="org.eclipse.aether.transport.http"; type="osgi.bundle"; 
>> version:Version="1.0.0.v20140518"] because it is exposed to package 
>> 'org.apache.http.entity' from resources org.apache.httpcomponents.httpcore 
>> [osgi.identity; osgi.identity="org.apache.httpcomponents.httpcore"; 
>> type="osgi.bundle"; version:Version="4.2.5.v201311072007"] and 
>> org.apache.httpcomponents.httpcore [osgi.identity; 
>> osgi.identity="org.apache.httpcomponents.httpcore"; type="osgi.bundle"; 
>> version:Version="4.3.2.v201409180530"] via two dependency chains.
>> 
>> Chain 1:
>>  org.eclipse.aether.transport.http [osgi.identity; 
>> osgi.identity="org.eclipse.aether.transport.http"; type="osgi.bundle"; 
>> version:Version="1.0.0.v20140518"]
>>import: 
>> (&(osgi.wiring.package=org.apache.http.entity)(&(version>=4.2.1)(!(version>=4.3.0
>> |
>>export: osgi.wiring.package: org.apache.http.entity
>>  org.apache.httpcomponents.httpcore [osgi.identity; 
>> osgi.identity="org.apache.httpcomponents.httpcore"; type="osgi.bundle"; 
>> version:Version="4.2.5.v201311072007"]
>> 
>> Chain 2:
>>  org.eclipse.aether.transport.http [osgi.identity; 
>> osgi.identity="org.eclipse.aether.transport.http"; type="osgi.bundle"; 
>> version:Version="1.0.0.v20140518"]
>>import: 
>> (&(osgi.wiring.package=org.apache.http.conn.ssl)(&(version>=4.2.1)(!(version>=4.3.0
>> |
>>export: osgi.wiring.package=org.apache.http.conn.ssl; 
>> uses:=org.apache.http.entity
>>  org.apache.httpcomponents.httpclient [osgi.identity; 
>> osgi.identity="org.apache.httpcomponents.httpclient"; type="osgi.bundle"; 
>> version:Version="4.2.6.v201311072007"]
>>import: (&(osgi.wiring.package=org.apache.http.entity)(version>=4.2.5))
>> |
>>export: osgi.wiring.package: org.apache.http.entity
>>  org.apache.httpcomponents.httpcore [osgi.identity; 
>> osgi.identity="org.apache.httpcomponents.httpcore"; type="osgi.bundle"; 
>> version:Version="4.3.2.v201409180530"]
> 
> This wiring problem may affect other projects beyond Eclipse Aether as
> well (hence the cross-post to cross-project-issues), if they import a
> specific *minor* version of Apache HttpClient/Core (Aether requires 4.2.x).
> 
> What I don't quite understand is why the bundles are wired as they are,
> though, as a solution to the uses constraint problem seems to exist:
> Wire org.apache.httpcomponents.httpclient 4.2.6 to
> org.apache.httpcomponents.httpcore 4.2.5 rather than 4.3.2. Is it
> because of the open-ended Import-Package of [4.2.5,) in
> org.apache.httpcomponents.httpclient 4.2.6? (FWIW, 4.3.2 doesn't use
> open-ended Import-Packages anymore. :-)
> 
> Any advice in how to best proceed with this issue? Should
> org.eclipse.aether.transport.http use a broader Import-Package range
> including 4.3.x (provided that there were no breaking API changes
> between 4.2.x and 4.3.x)?
> 
> Best wishes,
> 
> Andreas
> 
> [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=450738>
> 
> -- 
> Codetrails GmbH
> The knowledge transfer company
> 
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-170-811-3791
> http://www.codetrails.com/
> 
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0)

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

What can I do to bring this discussion forward? Should I open a bug against 
JDT, PDT, or cross-projects?

It seems that up to now GEF is the only JavaFX consumer at Eclipse (or at least 
in the release train), which explains why there does not seem to be a lot of 
interest (yet). Nevertheless, an accepted convention on how to properly deal 
with JavaFX dependencies (package imports vs. BREE) and additional tool support 
that (augmenting what e(fx)clipse already provides) would allow clients to 
version-constrain their JavaFX dependencies (and to validate that their 
implementation obeys these constraints), would probably be very much valued by 
all who want to use JavaFX in an OSGi/Eclipse setting...

Cheers
Alexander

Am 09.09.2014 um 18:33 schrieb Alexander Nyßen :

> As already said, I also got the impression that the bundle's BREE could be 
> the way to go. Having considered the ExecutionEnvironment guidelines at 
> http://wiki.eclipse.org/Execution_Environments, and especially the section on 
> 'XML and other optional JRE pieces', I think it pretty much burns down to the 
> question of whether we want to/are able to regard JavaFX as an "optional JRE 
> piece" or not. 
> 
> That is, the way we currently access JavaFX trough e(fx)clipse pretty much 
> resembles what the ExecutionEnvironment guide describes as the recommended 
> handling of an "optional JRE piece". However, as already laid out, I have the 
> impression that the special constraints that hold for the org.eclipse.javafx 
> bundle (which does not bundle any classes itself but only serves as a 
> placeholder) will probably require some different handling compared to the 
> org.w3c.dom bundle that is named as an example in the guide. In addition, 
> only a client bundle's BREE will probably be able to capture its exact JavaFX 
> version requirements, as the different JavaFX versions cannot be 
> differentiated on the level of packages alone (even if the org.eclipse.javafx 
> bundle would not use the version constraints on its package-exports like it 
> currently does). On the other hand, as JavaFX is not JSRed (as indicated by 
> Tom), we will probably end up with quite a few new EEs to handle that 
> properly... 
> 
> Cheers
> Alexander
> 
> Am 08.09.2014 um 18:31 schrieb Doug Schaefer :
> 
>> I think I keep asking this question, but isn't there a way to define a new 
>> execution environment to describe the environment that enables JavaFX on 
>> Java 8? I thought that's what they were for.
>> 
>> Sent from my BlackBerry 10 smartphone on the Rogers network.
>> Original Message
>> From: Tom Schindl
>> Sent: Monday, September 8, 2014 4:09 AM
>> To: cross-project-issues-dev@eclipse.org
>> Reply To: Cross project issues
>> Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars 
>> release
>> 
>> 
>> Hi,
>> 
>> From a e(fx)clipse point of view we will load the javafx libraries from
>> the JRE you are running on and JavaFX is a singleton like anything you
>> get from the JRE as well (you can not load multiple version of javafx at
>> once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you
>> run on JRE 1.8 you get JavaFX8 classes.
>> 
>> If you require Java8 features you need *your* bundle to require a an EE
>> for JavaSE-1.8 (in reality this might not be enough because what you'd
>> really want to spec is that you want OpenJDK/OracleJDK 1.8!).
>> 
>> Our fake bundle will never define an EE itself.
>> 
>> Please also note that because JavaFX is NOT JSRed they are adding
>> methods and features inside Java8 releases as well so an EE (e.g. in
>> 8u40 you get a Dialog-API, ...).
>> 
>> The versioned package exports only tell you in which JavaFX release the
>> package was exposed the first time - I know this is not proper use of
>> OSGi-Versions and maybe we should have omitted them completely but that
>> would be a breaking change for anyone out there having versioned package
>> imports on the other had simply updateing them to javafx 8.0 seems
>> invalid as well.
>> 
>> In case there's consensus from people here that our version package
>> exports are so wrong that this blocks integration I'm willing to break
>> people and require them to update their applications to use unversion
>> package imports.
>> 
>> Tom
>> 
>> On 07.09.14 11:57, Alexander Nyßen wrote:
>>> Let me add another question to this discussion: As JavaFX 8 is now
>>> around (in addition to JavaFX 2.2), what will be the strategy to deal
>>> with the different JavaFX versions?
>>> 
>>>

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

As already said, I also got the impression that the bundle's BREE could be the 
way to go. Having considered the ExecutionEnvironment guidelines at 
http://wiki.eclipse.org/Execution_Environments, and especially the section on 
'XML and other optional JRE pieces', I think it pretty much burns down to the 
question of whether we want to/are able to regard JavaFX as an "optional JRE 
piece" or not. 

That is, the way we currently access JavaFX trough e(fx)clipse pretty much 
resembles what the ExecutionEnvironment guide describes as the recommended 
handling of an "optional JRE piece". However, as already laid out, I have the 
impression that the special constraints that hold for the org.eclipse.javafx 
bundle (which does not bundle any classes itself but only serves as a 
placeholder) will probably require some different handling compared to the 
org.w3c.dom bundle that is named as an example in the guide. In addition, only 
a client bundle's BREE will probably be able to capture its exact JavaFX 
version requirements, as the different JavaFX versions cannot be differentiated 
on the level of packages alone (even if the org.eclipse.javafx bundle would not 
use the version constraints on its package-exports like it currently does). On 
the other hand, as JavaFX is not JSRed (as indicated by Tom), we will probably 
end up with quite a few new EEs to handle that properly... 

Cheers
Alexander

Am 08.09.2014 um 18:31 schrieb Doug Schaefer :

> I think I keep asking this question, but isn't there a way to define a new 
> execution environment to describe the environment that enables JavaFX on Java 
> 8? I thought that's what they were for.
> 
> Sent from my BlackBerry 10 smartphone on the Rogers network.
>  Original Message
> From: Tom Schindl
> Sent: Monday, September 8, 2014 4:09 AM
> To: cross-project-issues-dev@eclipse.org
> Reply To: Cross project issues
> Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars 
> release
> 
> 
> Hi,
> 
> From a e(fx)clipse point of view we will load the javafx libraries from
> the JRE you are running on and JavaFX is a singleton like anything you
> get from the JRE as well (you can not load multiple version of javafx at
> once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you
> run on JRE 1.8 you get JavaFX8 classes.
> 
> If you require Java8 features you need *your* bundle to require a an EE
> for JavaSE-1.8 (in reality this might not be enough because what you'd
> really want to spec is that you want OpenJDK/OracleJDK 1.8!).
> 
> Our fake bundle will never define an EE itself.
> 
> Please also note that because JavaFX is NOT JSRed they are adding
> methods and features inside Java8 releases as well so an EE (e.g. in
> 8u40 you get a Dialog-API, ...).
> 
> The versioned package exports only tell you in which JavaFX release the
> package was exposed the first time - I know this is not proper use of
> OSGi-Versions and maybe we should have omitted them completely but that
> would be a breaking change for anyone out there having versioned package
> imports on the other had simply updateing them to javafx 8.0 seems
> invalid as well.
> 
> In case there's consensus from people here that our version package
> exports are so wrong that this blocks integration I'm willing to break
> people and require them to update their applications to use unversion
> package imports.
> 
> Tom
> 
> On 07.09.14 11:57, Alexander Nyßen wrote:
>> Let me add another question to this discussion: As JavaFX 8 is now
>> around (in addition to JavaFX 2.2), what will be the strategy to deal
>> with the different JavaFX versions?
>> 
>> Up to now it seems the org.eclipse.javafx bundle exports the javafx
>> packages with version constraints. As its a singleton, there will only
>> be one org.eclipse.javafx bundle in an Eclipse installation, and for
>> clients (with package imports) the available JavaFX version will thus
>> depend on that bundle's package exports. However, org.eclipse.javafx is
>> just a dummy bundle, so the version of the actually loaded JavaFX
>> classes will IMHO depend on the JRE that was used to start the
>> application (or whatever strategy the org.eclipse.fx.osgi fragment uses
>> to locate them).
>> 
>> How can you ensure that stays consistent? Doesn't it mean you will have
>> to remove the version constraints from the org.eclipse.javafx bundle as
>> soon as you are going to support multiple JavaFX versions (so the
>> version will be decided at runtime when org.eclipse.fx.osgi loads the
>> classes)? And wouldn't that imply that clients could also not specify
>> version constraints on their package imports, because t

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

Hi Tom,

Am 08.09.2014 um 10:09 schrieb Tom Schindl :

> Hi,
> 
> From a e(fx)clipse point of view we will load the javafx libraries from
> the JRE you are running on and JavaFX is a singleton like anything you
> get from the JRE as well (you can not load multiple version of javafx at
> once!), if you are running on JRE 1.7 you get JavaFX 2.2 classes if you
> run on JRE 1.8 you get JavaFX8 classes.

I was not challenging the fact its a singleton (I also think it has to be one), 
I was just wondering how that is related to the version constraints specified 
in the package exports (see comments below).

> 
> If you require Java8 features you need *your* bundle to require a an EE
> for JavaSE-1.8 (in reality this might not be enough because what you'd
> really want to spec is that you want OpenJDK/OracleJDK 1.8!).
> 
> Our fake bundle will never define an EE itself.
> 
> Please also note that because JavaFX is NOT JSRed they are adding
> methods and features inside Java8 releases as well so an EE (e.g. in
> 8u40 you get a Dialog-API, ...).

That was what I meant with 'would not the bundle's BREE be the right indicator 
for its required JavaFX version'. I agree, the fact that its not JSRed will 
obviously not make it a 100% fit either, but neither will version constraints 
on the package imports (if they only indicate when a package was made available 
first). The more I think about it, the more I get the impression that a proper 
solution would probably require something like a BREE definition for JavaFX (or 
an extension of the current BREEs to this extend). 

Anyway, what will definitely be needed is something like we now have in terms 
of Execution Environment Descriptors, so one can confirm that the code base 
only makes use of those JavaFX features it is actually intended to do.

> 
> The versioned package exports only tell you in which JavaFX release the
> package was exposed the first time - I know this is not proper use of
> OSGi-Versions and maybe we should have omitted them completely but that
> would be a breaking change for anyone out there having versioned package
> imports on the other had simply updateing them to javafx 8.0 seems
> invalid as well.

I assumed a different usage of the version constraints and thus could not 
understand how consistency is ensured, but now that got clear. Actually, I 
don't have a strong opinion on that (yet). I just saw that a couple of problems 
occurred from something similar in the context of the javax.annotation orbit 
bundle (which also exports packages with a version constraint; thus preventing 
clients to be resolved against the respective packages now provided by a the 
JRE itself; see https://bugs.eclipse.org/bugs/show_bug.cgi?id=424274), but I 
assume we will not run into similar problems here unless JavaFX is placed on 
any of the default classpaths.

> 
> In case there's consensus from people here that our version package
> exports are so wrong that this blocks integration I'm willing to break
> people and require them to update their applications to use unversion
> package imports.
> 
> Tom

Cheers
Alexander

> 
> On 07.09.14 11:57, Alexander Nyßen wrote:
>> Let me add another question to this discussion: As JavaFX 8 is now
>> around (in addition to JavaFX 2.2), what will be the strategy to deal
>> with the different JavaFX versions? 
>> 
>> Up to now it seems the org.eclipse.javafx bundle exports the javafx
>> packages with version constraints. As its a singleton, there will only
>> be one org.eclipse.javafx bundle in an Eclipse installation, and for
>> clients (with package imports) the available JavaFX version will thus
>> depend on that bundle's package exports. However, org.eclipse.javafx is
>> just a dummy bundle, so the version of the actually loaded JavaFX
>> classes will IMHO depend on the JRE that was used to start the
>> application (or whatever strategy the org.eclipse.fx.osgi fragment uses
>> to locate them). 
>> 
>> How can you ensure that stays consistent? Doesn't it mean you will have
>> to remove the version constraints from the org.eclipse.javafx bundle as
>> soon as you are going to support multiple JavaFX versions (so the
>> version will be decided at runtime when org.eclipse.fx.osgi loads the
>> classes)? And wouldn't that imply that clients could also not specify
>> version constraints on their package imports, because these could
>> otherwise not be resolved? If this was the case, then would not the
>> bundle's BREE be the right  indicator for its required JavaFX version
>> (as its done for all other JRE provided classes; of course implicating
>> some support for JavaFX within the Execution Environment Descriptors)?
>> Or do

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

Let me add another question to this discussion: As JavaFX 8 is now around (in 
addition to JavaFX 2.2), what will be the strategy to deal with the different 
JavaFX versions? 

Up to now it seems the org.eclipse.javafx bundle exports the javafx packages 
with version constraints. As its a singleton, there will only be one 
org.eclipse.javafx bundle in an Eclipse installation, and for clients (with 
package imports) the available JavaFX version will thus depend on that bundle's 
package exports. However, org.eclipse.javafx is just a dummy bundle, so the 
version of the actually loaded JavaFX classes will IMHO depend on the JRE that 
was used to start the application (or whatever strategy the org.eclipse.fx.osgi 
fragment uses to locate them). 

How can you ensure that stays consistent? Doesn't it mean you will have to 
remove the version constraints from the org.eclipse.javafx bundle as soon as 
you are going to support multiple JavaFX versions (so the version will be 
decided at runtime when org.eclipse.fx.osgi loads the classes)? And wouldn't 
that imply that clients could also not specify version constraints on their 
package imports, because these could otherwise not be resolved? If this was the 
case, then would not the bundle's BREE be the right  indicator for its required 
JavaFX version (as its done for all other JRE provided classes; of course 
implicating some support for JavaFX within the Execution Environment 
Descriptors)? Or does it mean for Mars there will only be an org.eclipse.javafx 
bundle that is bound to BREE 1.8 and exposes JavaFX 8 only (and there will be 
no support for JavaFX 2.2 and BREE 1.7)? 

Cheers
Alexander

Am 22.08.2014 um 09:17 schrieb Alexander Nyßen :

> Tom, 
> 
>> 
>>> I suppose all this means that no bundle with javafx dependencies can
>>> resolve or run without this specific org.eclipse.fx.javafx bundle being
>>> present.  Again, it's none of my personal business, but if this is
>>> indeed the only solution, would Orbit be a better host for such a thing?
>> 
>> org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.
> 
> what I infer from your detailed elaboration (thanks for bringing light into 
> the darkness) is that it would make no sense at all to separate 
> org.eclipse.fx.javafx from org.eclipse.fx.osgi, because without the 
> org.eclipse.fx.osgi fragment the org.eclipse.javafx bundle would be useless 
> at runtime. 
> 
> Nevertheless, couldn't it be an option to have both within Orbit? From a 
> (simrel) participant client's perspective this could make things easier (but 
> probably only if these bundle would then also be provided by some +0 
> component). 
> 
>> 
>> Tom
> 
> Cheers
> Alexander 
> 
>> 
>> [1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
>> ___
>> 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
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nys...@itemis.de 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> 
> _______
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

Tom, 

> 
>> I suppose all this means that no bundle with javafx dependencies can
>> resolve or run without this specific org.eclipse.fx.javafx bundle being
>> present.  Again, it's none of my personal business, but if this is
>> indeed the only solution, would Orbit be a better host for such a thing?
> 
> org.eclipse.fx.javafx and org.eclipse.fx.osgi have to be in your runtime.

what I infer from your detailed elaboration (thanks for bringing light into the 
darkness) is that it would make no sense at all to separate 
org.eclipse.fx.javafx from org.eclipse.fx.osgi, because without the 
org.eclipse.fx.osgi fragment the org.eclipse.javafx bundle would be useless at 
runtime. 

Nevertheless, couldn't it be an option to have both within Orbit? From a 
(simrel) participant client's perspective this could make things easier (but 
probably only if these bundle would then also be provided by some +0 
component). 

> 
> Tom

Cheers
Alexander 

> 
> [1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

Tom,

Von meinem iPhone gesendet

>> Am 21.08.2014 um 22:32 schrieb Tom Schindl :
>> 
>> On 21.08.14 22:18, Alexander Nyßen wrote:
>> Hi Tom,
>> 
>> I was only referring to the org.eclipse.javafx bundle of e(fx)clipse,
>> which - as far as I understood - is basically there to deal with the
>> target resolving, while the org.eclipse.fx.osgi seems to perform the
>> runtime resolving, right? I am no expert, but as far as the target
> 
> No this is wrong org.eclipse.javafx is there so that:
> a) the target platform resolves
> b) at runtime bundles who do an import-package of javafx get physically
>  wired to org.eclipse.javafx
> c) the classloader constructed for org.eclipse.javafx is provided by
>  the org.eclipse.fx.osgi adapter hook.

that's actually what I understood and was referring to (maybe that didn't get 
clear). 

If I try to relate this to what Ed said, a) and b) seem to be about 1) target 
and 2) installation resolving (which I falsely subsumed under just target 
resolving), while b) as well as c) seem to be related to 3) runtime resolving. 

Maybe the jre dummy bundle mechanism works different then I expect it to work, 
but with respect to 1) and 2), the org.eclipse.javafx bundle seemed to play a 
similar role, so that's where I saw the analogy. I was not referring to the 
role it plays in 3), which seems to make the difference.

> 
>> resolving is concerned, there seemed to be an analogy. Maybe I'm wrong,
>> I'm no expert on this...
> 
> Yep you are wrong.
> 
> Tom

Cheers
Alexander

> 
> ___
> 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

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

Hi Tom,

I was only referring to the org.eclipse.javafx bundle of e(fx)clipse, which - 
as far as I understood - is basically there to deal with the target resolving, 
while the org.eclipse.fx.osgi seems to perform the runtime resolving, right? I 
am no expert, but as far as the target resolving is concerned, there seemed to 
be an analogy. Maybe I'm wrong, I'm no expert on this...

Cheers
Alexander

Am 21.08.2014 um 21:43 schrieb Tom Schindl :
>  Hi,
> 
> You guys are mixing things!
> 
> What Ed describes is only there for p2 so that it can resolve target
> platforms who are NOT mapped against a JRE but can only be used when a
> final EE (e.g. JavaSE-1.7 EE) exposes the package at runtime - this is
> true for javax stuff which is part of the Boot-Classpath & JSRed and so
> exported by the System bundle!
> 
> For javafx this is NOT the case:
> a) it is not part of an EE defined by OSGi because it is not JSRed
> b) it is not found on the Boot-Classpath hence it will never by loaded
>   by Equinox in a default config
> 
> The bundles provided by e(fx)clipse satisfies both p2 & runtime OSGi if
> someone thinks there's a better solution which fixes all the problem of
> integrating JavaFX in Equinox-OSGi (without causing trouble for any
> other bundle) I'm happy to learn.
> 
> So please don't mix target-platform dev time resolution and runtime
> resolution in Equinox and even resolving does not help you still have
> the classpath problem.
> 
> Tom
> 
> On 21.08.14 21:08, Alexander Nyßen wrote:
>> Hi Ed, 
>> 
>> I was not aware of the existence of such a mechanism. Actually, the
>> org.eclipse.javafx bundle provided by e(fx)clipse is nothing more than
>> such a fake bundle, which provides exactly the javafx packages (so
>> others can resolve against it). 
>> 
>> While I do not want to deny e(fx)clipse any responsibility, maybe it
>> would be a good idea to think about how we could handle these kind of
>> things in a more common way. 
>> 
>> Cheers
>> Alexander
>> 
>> Am 21.08.2014 um 18:49 schrieb Ed Merks > <mailto:ed.me...@gmail.com>>:
>> 
>>> Guys,
>>> 
>>> Isn't it a fundamental problem that the fake "a.jre" and "a.jre.se
>>> <http://a.jre.se>" units in the repo are only for Java 1.6?  I.e.,
>>> should there be units for 1.7 and 1.8?  After all, how do javax
>>> packages new to 1.7 or 1.8 (if there are any) become visible for
>>> package imports in bundles?
>>> 
>>> I've never understood where these fake units come from and in which
>>> repos they should exist.  For example, in
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=431259 it's clear that
>>> orbit doesn't contain these units so you can't provision a target
>>> platform purely from the Orbit repo even if you only need things form
>>> Orbit in your TP.
>>> 
>>> If you're curious, look in
>>> download.eclipse.org/releases/luna/201406250900/content.jar
>>> <http://download.eclipse.org/releases/luna/201406250900/content.jar>
>>> and search for ">> the javax packages.
>>> 
>>> Perhaps the problem is even more complex and that even with such fake
>>> units, the packages still wouldn't be available on the classpath, but
>>> I don't understand how this is supposed to work unless there is a fake
>>> "a.jre" unit that explicitly lists "javafx"...
>>> 
>>> Regards,
>>> Ed
>>> 
>>> On 21/08/2014 6:03 PM, Tom Schindl wrote:
>>>> a) Does it Help
>>>> ---
>>>> Yes it does help IMHO.
>>>> 
>>>> Take for example the GEF4 people they have never ever thought about how
>>>> JavaFX gets on the classpath they just use it like they use any other
>>>> thing that is part of the JDK, with the small difference that they
>>>> import javafx-packages in their MANIFEST.MF.
>>>> 
>>>> And there's more to JavaFX-SWT embedding than just getting FXCanvas on
>>>> the classpath? e.g. I guess most people embedding JavaFX into SWT with
>>>> the help of e(fx)clipse don't know that they need to call
>>>> Platform.setImplicitExit(false)
>>>> 
>>>> b) Can an EPP package use JavaFX
>>>> 
>>>> Sure it can. I'm building an EPP like distro at
>>>> http://efxclipse.bestsolution.at/install.html using the p2-director to
>>>> install e(fx

Re: [cross-project-issues-dev] e(fx)clipse participating in Mars release

[Alexander Nyßen]

t;>> release
>>> 
>>> We are still using OSGi-AdapterHooks but so do others on the release
>>> train as well but we are not modify any classpath nor do we modify the
>>> classloader strategy of Equinox so I can't see how we can affect others
>>> inside the IDE.
>>> 
>>> As far as I can tell there's no other option than Adapter-Hooks to get
>>> JavaFX embedded in the Eclipse IDE because the swt-javafx bridge is not
>>> on ANY classpath.
>>> 
>>> For JavaFX8 in OSGi without adapter-hooks you'd have to modify the
>>> Equinox-Classloader hierarchy to include the extension-classpath which
>>> most likely breaks many other things and would still not fix your
>>> swt-javafx embedding.
>>> 
>>> Other IDEs built on top of Eclipse (e.g. STS) have already adopted our
>>> AdapterHook and so do others like GEF4 and hopefully many others as well.
>>> 
>>> To sum up, I can't see how having e(fx)clipse on the release train (and
>>> maybe in a download package) can affect others using JavaFX beside
>>> takeing the burden to understand how much such an integration has to
>>> work in every detail.
>>> 
>>> Tom
>>> 
>>> On 21.08.14 09:23, Max Rydahl Andersen wrote:
>>>> On 20 Aug 2014, at 10:46, Tom Schindl wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> e(fx)clipse would like to join the Mars release as a +3 component
>>>>> because we depend on Xtext who is +2.
>>>>> 
>>>>> Our current plan is to contribute e(fx)clipse 2.0 because this is the
>>>>> first time we are joining (I need to make myself familiar with the
>>>>> process) I'm not sure we manage to contribute to M1 in time.
>>>> I'm curious - Did you find a way to use javafx without doing tweaks on
>>>> the classpath/eclipse.ini
>>>> that potentially affect others using javafx ?
>>>> 
>>>> /max
>>>> http://about.me/maxandersen
>>>> ___
>>>> 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
>>> ___
>>> 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
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Status and outlook for Mars M1 and Luna SR1 RC1

[Alexander Nyßen]

I just re-enabled those GEF4 features that only depend on EMF/Xtext but not on 
JavaFX. In case the e(fx)clipse contribution is yet added to the aggregation, I 
assume you might safely re-enable the remaining 6 GEF4 features as well.

Cheers
Alexander

Am 20.08.2014 um 21:08 schrieb David M Williams :

> Been a busy few days! 
> 
> I think we are on the verge of getting some "green" builds again, but wanted 
> to be sure to mention some "hacks" I had to make: 
> 
> For Luna 
> I disabled 
>   mylyn-docs-intent.b3aggrcon 
>   (I also removed "eclipselink" which I hope doesn't surprise them, as they 
> were not participants in the Sim. Release! ... definitely need to tighten up 
> our process! ) 
> 
> For Mars, more changes. In addition to the above two changes, the following 
> contain some repo or feature disabled. The first one in the list (and the 
> last) are the only ones I made ... 
> but thought it'd be good to call attention to the others in case anyone is 
> surprised. 
> I also had to adjust the "feature ranges" of emf.transaction and gmf.runtime. 
> emf-transaction I'm pretty sure was a "typo", 
> but the latter I'm not so sure. I changed (increased) feature ranges so it 
> would "match" what was in the repo it was pointing at, but as far as I know 
> it might have been pointing at the wrong repo?   
> 
> soa-bpmn2-modeler.b3aggrcon 
> emf-emf-rap.b3aggrcon 
> gef.b3aggrcon 
> mft.b3aggrcon 
> scout-rap.b3aggrcon 
> swtbot.b3aggrcon 
> mylyn-docs-intent.b3aggrcon 
> 
> 
> Still a few hours left, if anyone can safely make changes to fix up things to 
> be included, or accurate. 
> 
> The good news is I think the "warm up" RC has been effective in getting Luna 
> close to "lined up" ... the next RC's, in a few weeks, will have little time 
> for major changes, so I hope this preliminary step avoids problems for those 
> that should be "real" release candidates. Also, more good news, I think this 
> is the most "M1 participants" we've ever had! ... I am glad everyone is 
> getting a good early start on Mars, as it should be.   
> 
> Thanks! 
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

I added the following efxclipse.b3aggrcon to my local simrel build for testing 
purposes and validated that with the e(fx)clipse runtime feature in place, 
those GEF4 features depending on JavaFX could now indeed be resolved (i.e. the 
aggregation could be validated). 


http://www.omg.org/XMI"; 
xmlns:aggregator="http://www.eclipse.org/b3/2011/aggregator/1.1.0"; 
description="JavaFX Tooling for Eclipse" label="e(fx)clipse">
  http://download.eclipse.org/efxclipse/runtime-released/1.0.0/site";>

  

  


As such, the presence of the e(fx)clipse runtime feature would be sufficient to 
resolve all javafx package import problems. Nevertheless, if e(fx)clipse joins 
as a +3 component, GEF as a +1 component would have 9 out of 14 features 
depending (directly or indirectly) on a +3 component, only because we specify 
some javafx package imports. While +3 probably is a good choice for e(fx)clipse 
from an IDE tooling perspective, I somehow have the impression that this is not 
appropriate for its runtime, which only makes the javafx classes available on 
the osgi classpath.

Cheers
Alexander

Am 20.08.2014 um 10:48 schrieb Tom Schindl :

> Hi,
> 
> We'll join as +3 but I can not promise we manage to contribute to M1
> already because I need to make myself familiar with the process, ... .
> 
> Tom
> 
> On 20.08.14 10:28, Alexander Nyßen wrote:
>> Tom, 
>> 
>> at what offset can we expect the e(fx)clipse contribution? Will you
>> contribute something to M1?
>> 
>> Cheers 
>> Alexander
>> 
>> Am 18.08.2014 um 21:59 schrieb Alexander Nyßen
>> mailto:alexander.nys...@itemis.de>>:
>> 
>>> I temporarily disabled all GEF4 features that (directly or indirectly)
>>> depend on JavaFX. I do not know what is the intended offset of
>>> e(fx)clipse, but unless we find out how to provide these dependencies
>>> (i.e. jfxrt.jar in case of Java7, jfxswt.jar in case of Java8) to B3
>>> directly (i.e. jfxrt.jar in case of Java7, jfxswt.jar in case of
>>> Java8) we will have to re-enable them after e(fx)clipse has joined
>>> (and potentially update our contribution). 
>>> 
>>> Cheers
>>> Alexander
>>> 
>>> Am 18.08.2014 um 21:43 schrieb Alexander Nyßen
>>> mailto:alexander.nys...@itemis.de>>:
>>> 
>>>> Would that mean I have to specify dependencies to e(fx)clipse or
>>>> would b3 resolve this implicitly? Up to now, my bundles only specify
>>>> javafx package imports (including imports to javafx.embed.swt)...
>>>> 
>>>> Cheers
>>>> Alexander
>>>> 
>>>> Am 18.08.2014 um 21:40 schrieb Tom Schindl
>>>> mailto:tom.schi...@bestsolution.at>>:
>>>> 
>>>>> a) e(fx)clipse just released 1.0
>>>>> b) the bundles required only depend on equinox >= Luna
>>>>> 
>>>>> So no matter if we (efxclipse) are on the Mars release GEF4 should
>>>>> be fine!
>>>>> 
>>>>> Tom
>>>>> 
>>>>> Von meinem iPhone gesendet
>>>>> 
>>>>> Am 18.08.2014 um 21:22 schrieb David M Williams
>>>>> mailto:david_willi...@us.ibm.com>>:
>>>>> 
>>>>>> And, in the mean time, it seems your current contribution won't
>>>>>> "aggregate" (and mentions missing things somehow related to "fx".
>>>>>> Can you disable those features for now?
>>>>>> 
>>>>>> For the record, if the "required project" did not participate, you
>>>>>> can "include" their features in yours, but, only from their latest
>>>>>> released version (if there is one ... and if there is not a
>>>>>> released version, then you could not do it).
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> From:Alexander Nyßen >>>>> <mailto:alexander.nys...@itemis.de>>
>>>>>> To:Cross project issues
>>>>>> >>>>> <mailto:cross-project-issues-dev@eclipse.org>>,
>>>>>> Date:08/18/2014 12:58 PM
>>>>>> Subject:[cross-project-issues-dev] What policy w.r.t.
>>>>>> javafx packageimports?
>>>>>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>>>>>> <mailto:cross-project-issues-dev-bou

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

Tom, 

at what offset can we expect the e(fx)clipse contribution? Will you contribute 
something to M1?

Cheers 
Alexander

Am 18.08.2014 um 21:59 schrieb Alexander Nyßen :

> I temporarily disabled all GEF4 features that (directly or indirectly) depend 
> on JavaFX. I do not know what is the intended offset of e(fx)clipse, but 
> unless we find out how to provide these dependencies (i.e. jfxrt.jar in case 
> of Java7, jfxswt.jar in case of Java8) to B3 directly (i.e. jfxrt.jar in case 
> of Java7, jfxswt.jar in case of Java8) we will have to re-enable them after 
> e(fx)clipse has joined (and potentially update our contribution). 
> 
> Cheers
> Alexander
> 
> Am 18.08.2014 um 21:43 schrieb Alexander Nyßen :
> 
>> Would that mean I have to specify dependencies to e(fx)clipse or would b3 
>> resolve this implicitly? Up to now, my bundles only specify javafx package 
>> imports (including imports to javafx.embed.swt)...
>> 
>> Cheers
>> Alexander
>> 
>> Am 18.08.2014 um 21:40 schrieb Tom Schindl :
>> 
>>> a) e(fx)clipse just released 1.0
>>> b) the bundles required only depend on equinox >= Luna
>>> 
>>> So no matter if we (efxclipse) are on the Mars release GEF4 should be fine!
>>> 
>>> Tom
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>> Am 18.08.2014 um 21:22 schrieb David M Williams :
>>> 
>>>> And, in the mean time, it seems your current contribution won't 
>>>> "aggregate" (and mentions missing things somehow related to "fx". Can you 
>>>> disable those features for now? 
>>>> 
>>>> For the record, if the "required project" did not participate, you can 
>>>> "include" their features in yours, but, only from their latest released 
>>>> version (if there is one ... and if there is not a released version, then 
>>>> you could not do it). 
>>>> 
>>>> Thanks, 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From:Alexander Nyßen  
>>>> To:Cross project issues , 
>>>> Date:08/18/2014 12:58 PM 
>>>> Subject:[cross-project-issues-dev] What policy w.r.t. javafx 
>>>> packageimports? 
>>>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>>>> 
>>>> 
>>>> 
>>>> Hi all, 
>>>> 
>>>> as some of the new GEF4 bundles we want to include with Mars specify 
>>>> javafx package imports (so far without version constraints), I was 
>>>> wondering what general policy we want to follow to ensure such kind of 
>>>> bundles can be properly resolved. Should we rely on the e(fx)clipse 
>>>> runtime bundles/fragments (org.eclipse.javafx and org.eclipse.fx.osgi), 
>>>> i.e. re-bundle them in our features or specify feature-dependencies to the 
>>>> enclosing e(fx)clipse runtime feature, or is there another intended way 
>>>> (it seems, e(fx)clipse has not announced its participation)? 
>>>> 
>>>> Cheers 
>>>> Alexander 
>>>> --
>>>> Dr. Alexander Nyßen
>>>> Dipl.-Inform.
>>>> Software-Engineer
>>>> 
>>>> Telefon: +49 (0) 231 / 98 60-210
>>>> Telefax: +49 (0) 231 / 98 60-211
>>>> Mobil: +49 (0) 151 /  17396743
>>>> 
>>>> http://www.itemis.de 
>>>> alexander.nys...@itemis.de 
>>>> 
>>>> itemis AG
>>>> Am Brambusch 15-24
>>>> 44536 Lünen
>>>> 
>>>> Rechtlicher Hinweis:
>>>> 
>>>> Amtsgericht Dortmund, HRB 20621
>>>> 
>>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>>>> Trompeter, Sebastian Neus
>>>> 
>>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>>>> 
>>>> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
>>>> ___
>>>> 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

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

I temporarily disabled all GEF4 features that (directly or indirectly) depend 
on JavaFX. I do not know what is the intended offset of e(fx)clipse, but unless 
we find out how to provide these dependencies (i.e. jfxrt.jar in case of Java7, 
jfxswt.jar in case of Java8) to B3 directly (i.e. jfxrt.jar in case of Java7, 
jfxswt.jar in case of Java8) we will have to re-enable them after e(fx)clipse 
has joined (and potentially update our contribution). 

Cheers
Alexander

Am 18.08.2014 um 21:43 schrieb Alexander Nyßen :

> Would that mean I have to specify dependencies to e(fx)clipse or would b3 
> resolve this implicitly? Up to now, my bundles only specify javafx package 
> imports (including imports to javafx.embed.swt)...
> 
> Cheers
> Alexander
> 
> Am 18.08.2014 um 21:40 schrieb Tom Schindl :
> 
>> a) e(fx)clipse just released 1.0
>> b) the bundles required only depend on equinox >= Luna
>> 
>> So no matter if we (efxclipse) are on the Mars release GEF4 should be fine!
>> 
>> Tom
>> 
>> Von meinem iPhone gesendet
>> 
>> Am 18.08.2014 um 21:22 schrieb David M Williams :
>> 
>>> And, in the mean time, it seems your current contribution won't "aggregate" 
>>> (and mentions missing things somehow related to "fx". Can you disable those 
>>> features for now? 
>>> 
>>> For the record, if the "required project" did not participate, you can 
>>> "include" their features in yours, but, only from their latest released 
>>> version (if there is one ... and if there is not a released version, then 
>>> you could not do it). 
>>> 
>>> Thanks, 
>>> 
>>> 
>>> 
>>> 
>>> From:Alexander Nyßen  
>>> To:Cross project issues , 
>>> Date:08/18/2014 12:58 PM 
>>> Subject:[cross-project-issues-dev] What policy w.r.t. javafx 
>>> packageimports? 
>>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>>> 
>>> 
>>> 
>>> Hi all, 
>>> 
>>> as some of the new GEF4 bundles we want to include with Mars specify javafx 
>>> package imports (so far without version constraints), I was wondering what 
>>> general policy we want to follow to ensure such kind of bundles can be 
>>> properly resolved. Should we rely on the e(fx)clipse runtime 
>>> bundles/fragments (org.eclipse.javafx and org.eclipse.fx.osgi), i.e. 
>>> re-bundle them in our features or specify feature-dependencies to the 
>>> enclosing e(fx)clipse runtime feature, or is there another intended way (it 
>>> seems, e(fx)clipse has not announced its participation)? 
>>> 
>>> Cheers 
>>> Alexander 
>>> --
>>> Dr. Alexander Nyßen
>>> Dipl.-Inform.
>>> Software-Engineer
>>> 
>>> Telefon: +49 (0) 231 / 98 60-210
>>> Telefax: +49 (0) 231 / 98 60-211
>>> Mobil: +49 (0) 151 /  17396743
>>> 
>>> http://www.itemis.de 
>>> alexander.nys...@itemis.de 
>>> 
>>> itemis AG
>>> Am Brambusch 15-24
>>> 44536 Lünen
>>> 
>>> Rechtlicher Hinweis:
>>> 
>>> Amtsgericht Dortmund, HRB 20621
>>> 
>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>>> Trompeter, Sebastian Neus
>>> 
>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>>> 
>>> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
>>> ___
>>> 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
>> ___
>> 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
> 
> --
> Dr. Alexander Nyßen
> Dipl.-In

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

Would that mean I have to specify dependencies to e(fx)clipse or would b3 
resolve this implicitly? Up to now, my bundles only specify javafx package 
imports (including imports to javafx.embed.swt)...

Cheers
Alexander

Am 18.08.2014 um 21:40 schrieb Tom Schindl :

> a) e(fx)clipse just released 1.0
> b) the bundles required only depend on equinox >= Luna
> 
> So no matter if we (efxclipse) are on the Mars release GEF4 should be fine!
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 18.08.2014 um 21:22 schrieb David M Williams :
> 
>> And, in the mean time, it seems your current contribution won't "aggregate" 
>> (and mentions missing things somehow related to "fx". Can you disable those 
>> features for now? 
>> 
>> For the record, if the "required project" did not participate, you can 
>> "include" their features in yours, but, only from their latest released 
>> version (if there is one ... and if there is not a released version, then 
>> you could not do it). 
>> 
>> Thanks, 
>> 
>> 
>> 
>> 
>> From:Alexander Nyßen  
>> To:Cross project issues , 
>> Date:08/18/2014 12:58 PM 
>> Subject:[cross-project-issues-dev] What policy w.r.t. javafx package 
>>imports? 
>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> Hi all, 
>> 
>> as some of the new GEF4 bundles we want to include with Mars specify javafx 
>> package imports (so far without version constraints), I was wondering what 
>> general policy we want to follow to ensure such kind of bundles can be 
>> properly resolved. Should we rely on the e(fx)clipse runtime 
>> bundles/fragments (org.eclipse.javafx and org.eclipse.fx.osgi), i.e. 
>> re-bundle them in our features or specify feature-dependencies to the 
>> enclosing e(fx)clipse runtime feature, or is there another intended way (it 
>> seems, e(fx)clipse has not announced its participation)? 
>> 
>> Cheers 
>> Alexander 
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de 
>> alexander.nys...@itemis.de 
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
>> ___
>> 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
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

Where can you observe this? At 
https://hudson.eclipse.org/hudson/job/simrel.mars.runaggregator/ build #26 I 
can only see that the Papyrus contribution cannot be resolved...

Cheers
Alexander

Am 18.08.2014 um 21:22 schrieb David M Williams :

> And, in the mean time, it seems your current contribution won't "aggregate" 
> (and mentions missing things somehow related to "fx". Can you disable those 
> features for now? 
> 
> For the record, if the "required project" did not participate, you can 
> "include" their features in yours, but, only from their latest released 
> version (if there is one ... and if there is not a released version, then you 
> could not do it). 
> 
> Thanks, 
> 
> 
> 
> 
> From:Alexander Nyßen  
> To:Cross project issues , 
> Date:08/18/2014 12:58 PM 
> Subject:[cross-project-issues-dev] What policy w.r.t. javafx package  
>   imports? 
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> 
> 
> 
> Hi all, 
> 
> as some of the new GEF4 bundles we want to include with Mars specify javafx 
> package imports (so far without version constraints), I was wondering what 
> general policy we want to follow to ensure such kind of bundles can be 
> properly resolved. Should we rely on the e(fx)clipse runtime 
> bundles/fragments (org.eclipse.javafx and org.eclipse.fx.osgi), i.e. 
> re-bundle them in our features or specify feature-dependencies to the 
> enclosing e(fx)clipse runtime feature, or is there another intended way (it 
> seems, e(fx)clipse has not announced its participation)? 
> 
> Cheers 
> Alexander 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nys...@itemis.de 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

Let me add that the 'nasty' thing about it is that in case of Java7, all of it 
(jfxrt.jar) is by default invisible to the bundle classloader, while for Java8 
this is the case for the JavaFX-SWT-integration (jfxswt.jar), which is required 
by GEF4 as well. 

Cheers
Alexander
 
Am 18.08.2014 um 20:50 schrieb Tom Schindl :

> Part of oraclejdk/openjdk 7u8 on all platforms. JavaFX2 for win32 was an 
> extra download but anyone really doing fx uses at least jdk7 or even jdk8.
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
> Am 18.08.2014 um 20:42 schrieb Wayne Beaton :
> 
>> Naive question...
>> 
>> How is JavaFX distributed? Is it a separate download, or is it included as 
>> part of a JRE?
>> 
>> Wayne
>> 
>> On 18/08/14 12:57 PM, Alexander Nyßen wrote:
>>> Hi all,
>>> 
>>> as some of the new GEF4 bundles we want to include with Mars specify javafx 
>>> package imports (so far without version constraints), I was wondering what 
>>> general policy we want to follow to ensure such kind of bundles can be 
>>> properly resolved. Should we rely on the e(fx)clipse runtime 
>>> bundles/fragments (org.eclipse.javafx and org.eclipse.fx.osgi), i.e. 
>>> re-bundle them in our features or specify feature-dependencies to the 
>>> enclosing e(fx)clipse runtime feature, or is there another intended way (it 
>>> seems, e(fx)clipse has not announced its participation)?
>>> 
>>> Cheers
>>> Alexander
>>> --
>>> Dr. Alexander Nyßen
>>> Dipl.-Inform.
>>> Software-Engineer
>>> 
>>> Telefon: +49 (0) 231 / 98 60-210
>>> Telefax: +49 (0) 231 / 98 60-211
>>> Mobil: +49 (0) 151 /  17396743
>>> 
>>> http://www.itemis.de 
>>> alexander.nys...@itemis.de 
>>> 
>>> itemis AG
>>> Am Brambusch 15-24
>>> 44536 Lünen
>>> 
>>> Rechtlicher Hinweis:
>>> 
>>> Amtsgericht Dortmund, HRB 20621
>>> 
>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>>> Trompeter, Sebastian Neus
>>> 
>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
>> 
>> -- 
>> Wayne Beaton
>> @waynebeaton
>> The Eclipse Foundation
>> 
>> ___
>> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] What policy w.r.t. javafx package imports?

[Alexander Nyßen]

Hi all,

as some of the new GEF4 bundles we want to include with Mars specify javafx 
package imports (so far without version constraints), I was wondering what 
general policy we want to follow to ensure such kind of bundles can be properly 
resolved. Should we rely on the e(fx)clipse runtime bundles/fragments 
(org.eclipse.javafx and org.eclipse.fx.osgi), i.e. re-bundle them in our 
features or specify feature-dependencies to the enclosing e(fx)clipse runtime 
feature, or is there another intended way (it seems, e(fx)clipse has not 
announced its participation)?

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [cross-project-issues-dev] Sphinx participation in Mars release

[Alexander Nyßen]

Hi Wayne,

I think you lost GEF: 
https://www.mail-archive.com/cross-project-issues-dev@eclipse.org/msg04087.html

Cheers
Alexander

Am 12.08.2014 um 19:06 schrieb Wayne Beaton :

> Updated.
> 
> When you report your project's participation, please also tell the group your 
> offset.
> 
> I've assumed the same +3 from Luna for Sphinx.
> 
> Thanks,
> 
> Wayne
> 
> On 12/08/14 09:45 AM, Stephan Eberle wrote:
>> This is to let you know that Sphinx plans to participate in the Mars 
>> simultaneous release.
>> 
>> The release record can be found at 
>> https://projects.eclipse.org/projects/modeling.sphinx/releases/0.9.0.
>> 
>> Cheers,
>> 
>> Stephan
>> 
>> 
>> ___
>> 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
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> 
> ___
> 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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF participation in the Mars relea

[Alexander Nyßen]

The SimRel requirements ask to 'state intent' about participation early, so let 
me state that GEF is planning to participate in the Mars release:

The release record can be found at 
https://projects.eclipse.org/projects/tools.gef/releases/3.10.0-mars.

We are planning to include a first snapshot (with yet provisional API) of the 
new GEF4 components for Mars. And while GEF has always been a +1 component, 
there is one new GEF4 component, namely GEF4 DOT, which introduces dependencies 
to EMF and Xtext (all other GEF4 components are true +1 components, while GEF4 
Graph may introduce further EMF dependencies). I am not completely sure about 
the implications this will have, but I assume GEF needs to remain a +1 
component nevertheless (because there are +2 projects depending on it). Advice 
on how to properly handle this would nevertheless be welcome!

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] GEF 3.9.100.201405050205 promoted as Luna M7 contribution

[Alexander Nyßen]

I just promoted GEF 3.9.100.201405050205, the intended contribution to Luna M7, 
to the GEF milestones update-site and updated the gef.b3aggrcon of the simrel 
accordingly. As we had published 3.10.0 (up to M5) and 3.9.2 (for M6) 
contributions before (which are still contained on the releases site), please 
make sure you update your dependencies to refer to (3.9.100.201405050205, 
3.10.0] to consume the M7 contribution.

Best Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Correct bundle versioning for GEF 3.9.2 Luna release?

[Alexander Nyßen]

in a project where you 
> tend to apply a lot of other changes to avoid frequent full builds. Ideally 
> you choose either a dedicated project or a feature project that you rarely 
> change.
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
>> I'm sure it will be less wordy about it. :) 
>> 
>> 
>> 
>> 
>> 
>> 
>> From:Alexander Nyßen  
>> To:Cross project issues , 
>> Date:03/23/2014 09:39 PM 
>> Subject:[cross-project-issues-dev] Correct bundle versioning for GEF 
>> 3.9.2Luna release? 
>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> I am not sure whether this is the right location to ask, but I have a 
>> question w.r.t. to the correct versioning of our bundles for the Luna 3.9.2 
>> release of GEF:
>> 
>> For Kepler SR1 we have shipped GEF 3.9.1 (feature-version), which contained 
>> org.eclipse.draw2d 3.9.0 (which actually remained unchanged from 3.9.0 
>> release) and org.eclipse.gef.3.9.0 (which should actually have been 3.9.1, 
>> because there was a service level change from 3.9.0, but which was not 
>> updated either). Both bundles have changed again since the GEF 3.9.1 release 
>> (while again only service-level bugfixes). As GEF 3.9.2 (feature-version) is 
>> developed on the master branch (Luna stream), while GEF 3.9.1 
>> (feature-version) was developed on the Kepler maintenance stream, should we 
>> rather increase the versions of both bundles to 3.9.100 now to indicate we 
>> are on a new development stream, or rather to 3.9.1 (or in case of 
>> org.eclipse.gef to a more appropriate 3.9.2 because 3.9.1 should already 
>> have been included in GEF 3.9.1)?
>> 
>> Best Regards
>> Alexander
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de 
>> alexander.nys...@itemis.de 
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> 
>> [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Correct bundle versioning for GEF 3.9.2 Luna release?

[Alexander Nyßen]

Thanks Eike, 

I will definitely take a look into it. 

Cheers
Alexander

Am 24.03.2014 um 03:20 schrieb Eike Stepper :

> Hi Alexander,
> 
> With respect to forgetting to increase the micro versions properly I'd like 
> to point you to the "Version Management" Builder that Ed and I have 
> developed. It automatically creates and maintains a binary baseline (simple 
> files release.xml and release.digest). According to this baseline and your 
> changes it suggests micro version increments of +1 or +100 (depends on the 
> stream configuration in a release.properties file). The builder optionally 
> manages all version segments of features depending on their transitive 
> contents. If you're interested install the tool from 
> http://download.eclipse.org/modeling/emf/cdo/updates/integration and try it 
> out. I don't want to miss it anymore ;-)
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> 
> Am 24.03.2014 02:38, schrieb Alexander Nyßen:
>> I am not sure whether this is the right location to ask, but I have a 
>> question w.r.t. to the correct versioning of our bundles for the Luna 3.9.2 
>> release of GEF:
>> 
>> For Kepler SR1 we have shipped GEF 3.9.1 (feature-version), which contained 
>> org.eclipse.draw2d 3.9.0 (which actually remained unchanged from 3.9.0 
>> release) and org.eclipse.gef.3.9.0 (which should actually have been 3.9.1, 
>> because there was a service level change from 3.9.0, but which was not 
>> updated either). Both bundles have changed again since the GEF 3.9.1 release 
>> (while again only service-level bugfixes). As GEF 3.9.2 (feature-version) is 
>> developed on the master branch (Luna stream), while GEF 3.9.1 
>> (feature-version) was developed on the Kepler maintenance stream, should we 
>> rather increase the versions of both bundles to 3.9.100 now to indicate we 
>> are on a new development stream, or rather to 3.9.1 (or in case of 
>> org.eclipse.gef to a more appropriate 3.9.2 because 3.9.1 should already 
>> have been included in GEF 3.9.1)?
>> 
>> Best Regards
>> Alexander
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de
>> alexander.nys...@itemis.de
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> 
>> 
>> 
>> _______
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Correct bundle versioning for GEF 3.9.2 Luna release?

[Alexander Nyßen]

I am not sure whether this is the right location to ask, but I have a question 
w.r.t. to the correct versioning of our bundles for the Luna 3.9.2 release of 
GEF:

For Kepler SR1 we have shipped GEF 3.9.1 (feature-version), which contained 
org.eclipse.draw2d 3.9.0 (which actually remained unchanged from 3.9.0 release) 
and org.eclipse.gef.3.9.0 (which should actually have been 3.9.1, because there 
was a service level change from 3.9.0, but which was not updated either). Both 
bundles have changed again since the GEF 3.9.1 release (while again only 
service-level bugfixes). As GEF 3.9.2 (feature-version) is developed on the 
master branch (Luna stream), while GEF 3.9.1 (feature-version) was developed on 
the Kepler maintenance stream, should we rather increase the versions of both 
bundles to 3.9.100 now to indicate we are on a new development stream, or 
rather to 3.9.1 (or in case of org.eclipse.gef to a more appropriate 3.9.2 
because 3.9.1 should already have been included in GEF 3.9.1)?

Best Regards
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Fwd: [lunaAggregation] Failed for build 2014-03-10_04-16-08

[Alexander Nyßen]

Actually, this was the cross-projects post I was referring to: 
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10334.html.

Cheers,
Alexander

Am 10.03.2014 um 09:25 schrieb Alexander Nyßen :

> Hi all,
> 
> as I have already announced earlier 
> (http://eclipse.1072660.n5.nabble.com/3-9-2-service-release-instead-of-3-10-0-minor-release-for-Luna-td165773.html),
>  I have published a Draw2d/GEF 3.9.2M6 / Zest 1.5.2M6 contribution this 
> morning, replacing all prior 3.10.0/1.6.0 contributions we have provided for 
> Luna so far. I have also removed all 3.10.0/1.6.0 related drop files from the 
> GEF downloads area and cleared the old contents of our milestone list, so 
> nobody consumes the M1-M5 versions any more. As indicated below, it seems 
> that at least GMF Runtime will have to update its version constraints to 
> point to GEF SDK [3.9.2.201403090306,3.10.0). I apologize for any 
> inconveniences that causes to upstream projects. 
> 
> Cheers
> Alexander
> 
> Anfang der weitergeleiteten Nachricht:
> 
>> Von: David Williams 
>> Betreff: [lunaAggregation] Failed for build 2014-03-10_04-16-08
>> Datum: 10. März 2014 09:16:44 MEZ
>> An: Ian Bull , Anthony Hunter 
>> , Alex Boyko , Alexander Nyssen 
>> 
>> Kopie: David Williams 
>> 
>> The following errors occured when building Luna:
>> 
>> Software being installed: validationSet_main 1.0.0
>> 
>> Missing requirement: org.eclipse.gmf.runtime.sdk.feature.group 
>> 1.8.0.201401272007 requires 'org.eclipse.gef.sdk.feature.group 3.10.0' but 
>> it could not be found
>> 
>> Cannot satisfy dependency: 
>> mappedRepo_home_data_httpd_download.eclipse.org_modeling_gmp_gmf-runtime_updates_milestones
>>  1.0.0 depends on: org.eclipse.gmf.runtime.sdk.feature.group 
>> [1.8.0.201401272007,1.9.0]
>> 
>> Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
>> mappedRepo_home_data_httpd_download.eclipse.org_modeling_gmp_gmf-runtime_updates_milestones
>>  [1.0.0]
>> 
>> Check the log file for more information: 
>> https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.luna.runaggregator/355/console
>> 
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nys...@itemis.de 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fwd: [lunaAggregation] Failed for build 2014-03-10_04-16-08

[Alexander Nyßen]

Hi all,

as I have already announced earlier 
(http://eclipse.1072660.n5.nabble.com/3-9-2-service-release-instead-of-3-10-0-minor-release-for-Luna-td165773.html),
 I have published a Draw2d/GEF 3.9.2M6 / Zest 1.5.2M6 contribution this 
morning, replacing all prior 3.10.0/1.6.0 contributions we have provided for 
Luna so far. I have also removed all 3.10.0/1.6.0 related drop files from the 
GEF downloads area and cleared the old contents of our milestone list, so 
nobody consumes the M1-M5 versions any more. As indicated below, it seems that 
at least GMF Runtime will have to update its version constraints to point to 
GEF SDK [3.9.2.201403090306,3.10.0). I apologize for any inconveniences that 
causes to upstream projects. 

Cheers
Alexander

Anfang der weitergeleiteten Nachricht:

> Von: David Williams 
> Betreff: [lunaAggregation] Failed for build 2014-03-10_04-16-08
> Datum: 10. März 2014 09:16:44 MEZ
> An: Ian Bull , Anthony Hunter 
> , Alex Boyko , Alexander Nyssen 
> 
> Kopie: David Williams 
> 
> The following errors occured when building Luna:
> 
> Software being installed: validationSet_main 1.0.0
> 
> Missing requirement: org.eclipse.gmf.runtime.sdk.feature.group 
> 1.8.0.201401272007 requires 'org.eclipse.gef.sdk.feature.group 3.10.0' but it 
> could not be found
> 
> Cannot satisfy dependency: 
> mappedRepo_home_data_httpd_download.eclipse.org_modeling_gmp_gmf-runtime_updates_milestones
>  1.0.0 depends on: org.eclipse.gmf.runtime.sdk.feature.group 
> [1.8.0.201401272007,1.9.0]
> 
> Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
> mappedRepo_home_data_httpd_download.eclipse.org_modeling_gmp_gmf-runtime_updates_milestones
>  [1.0.0]
> 
> Check the log file for more information: 
> https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.luna.runaggregator/355/console
> 

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Intention to provide GEF 3.9.2 maintenance release instead of 3.10.0 minor release for Luna

[Alexander Nyßen]

Hi all,

as we are currently spending all our work on the new GEF4 components (which are 
not included into Luna yet), there have only been two code-related changes to 
the GEF 3.x code base as part of the Luna release stream so far, namely:

- [424943] Fix creation of resize command by copy ignores some properties.
- [417188] Ensure SelectionSynchronizer only selects selectable EditParts.

These changes are on the maintenance level, i.e. they do not justify a minor 
version increment, all other changes we have applied so far do not affect our 
code base (there is one change, namely [418350] Reexport 
org.eclipse.core.runtime to fix error in IDE, which affects a plug-in manifest, 
but all other bugfixes are related to our releng infrastructure and/or 
documentation. As we do not expect additional changes that would require our 
API to change before M6, we would like to contribute a GEF 3.9.2 service 
release rather than a 3.10.0 minor release to Luna. 

As we have so far shipped 3.10.0 versions (up to M5), the consequence would be 
that we would have to decrease the version numbers of all our features to 3.9.2 
from M6 onwards. As all fixes that are currently incorporated into 3.10.0 will 
be included in 3.9.2 as well, this should not have a large impact to adopters 
(it may however be that they would have to change their minimal version 
dependencies from 3.10.0 to 3.9.2). To prevent adopters to run into problems, 
could we ensure that all 3.10.0 features published so far could be removed from 
the aggregated sim-rel repo after M6? Are there any objections to this change?

Best Regards
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Reuse GEF Kepler SR1 contribution for SR2

[Alexander Nyßen]

As there haven't been any changes to the GEF 3.9 maintenance branch since our 
3.9.1 (Kepler SR1) release, I would actually like to reuse that 3.9.1 release 
as part of the Kepler SR2 (if nothing comes up during the RC phase). Is there 
anything special to consider?

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] GEF participation in Luna release

[Alexander Nyßen]

Hi,

GEF will participate in the Luna release 
(https://projects.eclipse.org/projects/tools.gef/releases/3.10.0) with an 
offset of +1.

Regards,
Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF Version Numbers

[Alexander Nyßen]

> The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect 
> to bundles

I meant 3.8.1 of course.

Cheers
Alexander

> 
> Am 23.02.2013 um 08:06 schrieb Ed Willink :
> 
>> Hi
>> 
>> Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that 
>> must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for 
>> Kepler.
>> 
>> [When this is all over, can we have a clearer policy on maintenance releases 
>> being maintenance releases, with some aggrcon tooling that diagnoses
>> maintenance version consistency? Seems like this could have avoided both the 
>> EGIT and GEF problems.]
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 22/02/2013 23:41, Konstantin Komissarchik wrote:
>>> Alexander Nyßen wrote:
>>>  
>>> > GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I 
>>> > remember - still
>>> > contained the 3.8.1 bundles, only the feature versions were incremented 
>>> > at that time)
>>>  
>>> [snip]
>>>  
>>> > 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 
>>> > 3.9.0 bundles)
>>>  
>>> The situation in SR2 is far more severe than what happened in SR1. If SR2 
>>> respin is done to pick up the correct GEF 3.8.2 release, then users with 
>>> GEF installed from SR1 repo will not be able to upgrade GEF, but at least 
>>> no one will be running with pre-release code. Pick your poison.
>>>  
>>> - Konstantin
>>>  
>>>  
>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug 
>>> Schaefer
>>> Sent: Friday, February 22, 2013 3:32 PM
>>> To: cross-project-issues-dev@eclipse.org; 'Cross project issues'
>>> Subject: Re: [cross-project-issues-dev] GEF Version Numbers
>>>  
>>> If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that 
>>> seams, that ship already sailed.
>>> Sent from my BlackBerry 10 smartphone.
>>> 
>>> From: Konstantin Komissarchik
>>> Sent: Friday, February 22, 2013 5:55 PM
>>> To: 'Cross project issues'
>>> Reply To: Cross project issues
>>> Subject: Re: [cross-project-issues-dev] GEF Version Numbers
>>>  
>>> Frankly it’s rather scary that SR2 will run on a milestone build of GEF. 
>>> How much testing was there on this milestone to assure fitness for SR2?
>>>  
>>> I know that I, along with others how build upon GEF, would rest easier if 
>>> the GEF issue was also resolved in the respin. This is the last Juno 
>>> service release. Let’s get this right, even if it takes a bit longer.
>>>  
>>> - Konstantin
>>>  
>>>  
>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull
>>> Sent: Friday, February 22, 2013 2:50 PM
>>> To: Cross project issues
>>> Subject: [cross-project-issues-dev] GEF Version Numbers
>>>  
>>> If GEF is (or has) released a feature with the version 3.9 and there is a 
>>> new GEF release that contains additional API, then it should (must?) 
>>> increment it's minor version to 3.10. If there is no new API between what's 
>>> been released and Kepler, then I supposed that keeping 3.9 is ok, but 
>>> really a increment in the service number should be included. (3.9.1?).
>>>  
>>> I'm not sure how this affects all future releases? It means
>>>  
>>> Juno SR0: GEF 3.8.0
>>> Juno SR1: GEF 3.9.0
>>> Juno SR1: GEF 3.9.0 (different qualifier)
>>> Kepler SR0: GEF 3.10.0
>>> Kepler SR1: GEF 3.10.1
>>>  
>>> It's a little odd, but it allows adopters to target their dependencies. 
>>> Otherwise, if we release 3.9.0 again with Kepler, adopters will have a hard 
>>> time specifying if they want GEF Juno or GEF Kepler.
>>>  
>>> Cheers,
>>> Ian
>>>  
>>> On Fri, Feb 22, 2013 at 1:58 PM, Alexander Nyßen 
>>>  wrote:
>>>  
>>> The GEF and M2E bugs were also discussed. The M2E bug was perceived as a 
>>> bug that could be addressed by the project's own update repo and "hot fix" 
>>> process. The GEF issue is more complicated, can not be fixed by their own 
>>> update site, exactly, since part of the damage already exists in S

Re: [cross-project-issues-dev] GEF Version Numbers

[Alexander Nyßen]

The 3.9.0M1 being included in SR1 seems to be an unchanged 3.8.0 with respect 
to bundles (I assume the branches had not diverged at this point), and only the 
feature versions increased to 3.9.0 (I will cross-check that again, but the 
bundles should just have different qualifiers w.r.t. the 3.8.1 versions). 
3.9.0M5 actually does not contain many changes either. I intended to address a 
couple of issues for M6, but I did not have the chance to contribute much to it 
up to now (Matthias and I have spent work on GEF4), so there is actually just 
three changes involved:

1) https://bugs.eclipse.org/bugs/show_bug.cgi?id=388697 Changed the visibility 
of a member
2) https://bugs.eclipse.org/bugs/show_bug.cgi?id=394137 Introduced a new doc 
bundle for Zest
3) https://bugs.eclipse.org/bugs/show_bug.cgi?id=395872 Fixed the ICU 
dependencies

Fear about using untested bundles therefore is rather baseless. However, it 
would be nice if we can get this right in the final SR2 repo, as this will 
remain in place. Is  there no chance we can remove GEF 3.9.0M1 from the 
composite repo and include the intended 3.8.2 now into a respinned SR2? The 
3.8.1 has been released on our project releases site, so clients could still 
consume it from there. Of course this would mean a one-time adoption, but after 
that things would be ok.

Cheers
Alexander

Am 23.02.2013 um 08:06 schrieb Ed Willink :

> Hi
> 
> Surely we must lose GEF 3.9.0 M5, so we must respin to pick up 3.8.2 that 
> must be reversioned as 3.9.0 to succeed 3.9.0M1 in SR1? Then 3.10.0 for 
> Kepler.
> 
> [When this is all over, can we have a clearer policy on maintenance releases 
> being maintenance releases, with some aggrcon tooling that diagnoses
> maintenance version consistency? Seems like this could have avoided both the 
> EGIT and GEF problems.]
> 
> Regards
> 
> Ed Willink
> 
> On 22/02/2013 23:41, Konstantin Komissarchik wrote:
>> Alexander Nyßen wrote:
>>  
>> > GEF 3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I 
>> > remember - still
>> > contained the 3.8.1 bundles, only the feature versions were incremented at 
>> > that time)
>>  
>> [snip]
>>  
>> > 3.9.0 M5 is now used instead of 3.8.2 in the SR2 (which actually contains 
>> > 3.9.0 bundles)
>>  
>> The situation in SR2 is far more severe than what happened in SR1. If SR2 
>> respin is done to pick up the correct GEF 3.8.2 release, then users with GEF 
>> installed from SR1 repo will not be able to upgrade GEF, but at least no one 
>> will be running with pre-release code. Pick your poison.
>>  
>> - Konstantin
>>  
>>  
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug 
>> Schaefer
>> Sent: Friday, February 22, 2013 3:32 PM
>> To: cross-project-issues-dev@eclipse.org; 'Cross project issues'
>> Subject: Re: [cross-project-issues-dev] GEF Version Numbers
>>  
>> If Ian is correct then SR1 already shipped a 3.9 milestone. Bizarre as that 
>> seams, that ship already sailed.
>> Sent from my BlackBerry 10 smartphone.
>> 
>> From: Konstantin Komissarchik
>> Sent: Friday, February 22, 2013 5:55 PM
>> To: 'Cross project issues'
>> Reply To: Cross project issues
>> Subject: Re: [cross-project-issues-dev] GEF Version Numbers
>>  
>> Frankly it’s rather scary that SR2 will run on a milestone build of GEF. How 
>> much testing was there on this milestone to assure fitness for SR2?
>>  
>> I know that I, along with others how build upon GEF, would rest easier if 
>> the GEF issue was also resolved in the respin. This is the last Juno service 
>> release. Let’s get this right, even if it takes a bit longer.
>>  
>> - Konstantin
>>  
>>  
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull
>> Sent: Friday, February 22, 2013 2:50 PM
>> To: Cross project issues
>> Subject: [cross-project-issues-dev] GEF Version Numbers
>>  
>> If GEF is (or has) released a feature with the version 3.9 and there is a 
>> new GEF release that contains additional API, then it should (must?) 
>> increment it's minor version to 3.10. If there is no new API between what's 
>> been released and Kepler, then I supposed that keeping 3.9 is ok, but really 
>> a increment in the service number should be included. (3.9.1?).
>>  
>> I'm not sure how this affects all future releases? It means
>>  
>> Juno SR0: GEF 3.8.0
>> Juno SR1: GEF 3.9.0
>> Juno SR1: GEF 3.9.0 

Re: [cross-project-issues-dev] Wait ... don't release yet! ... delay one week, Friday 3/1

[Alexander Nyßen]

> 
> The GEF and M2E bugs were also discussed. The M2E bug was perceived as a bug 
> that could be addressed by the project's own update repo and "hot fix" 
> process. The GEF issue is more complicated, can not be fixed by their own 
> update site, exactly, since part of the damage already exists in SR1. We 
> recommend to them to make their Kepler version be GEF 3.10, since various 
> Juno versions will have some 3.9 and some 3.8; the differences in code are 
> relatively minor, as I understand it, with the version change being the 
> worst, and some adopters will have to work-around that, but it is feasible to 
> live with it. 

Hmm, I am not sure whether I like that "recommendation". GEF's release policy 
has always been easily traceable for all our clients, and with respect to our 
own update sites there is indeed no problem involved: we have released 3.8.0 
and 3.8.1 on the GEF's releases update site properly and we intended do the 
same with 3.8.2 (which is the intended release for Juno SR2). Because of a 
missing upper version limit in the gef.b3aggrcon file it happened that GEF 
3.9.0 M1 was included in SR1 instead of 3.8.1 (which - as far as I remember - 
still contained the 3.8.1 bundles, only the feature versions were incremented 
at that time) and accordingly 3.9.0 M5 is now used instead of 3.8.2 in the SR2 
(which actually contains 3.9.0 bundles). Leaving 3.9.0M5 within the SR2 release 
repo is one thing (I can understand the councils decision, even if I would have 
liked it to be otherwise), but I don't like that this is going to affect all 
our future releases as well. Having said so, I would propose that with Kepler 
we will continue exactly as planned, i.e. ship our intended 3.9.0 release. All 
our bundles and features are properly equipped with qualifiers, so there should 
be no problem if the 3.9.0M5 in Juno SR2 is succeeded by the actual 3.9.0 
release in Kepler. This way, the Juno SR1 and SR2 aggregator repos would be the 
only places that reflect the above mentioned inconsistency and from Kepler on, 
everything would be fine again (and we will not have to explain, where we lost 
our 3.9.0 release). Concerning the GEF releases site, I would like to go for 
the intended 3.8.2 release there, so clients can consume it from there if they 
want to, while the 3.9.0M5 is also available from our milestones site.

Cheers 
Alexander

Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Wait ... don't release yet!

[Alexander Nyßen]

As already documented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477, 
I did the same for gef yesterday, so when re-running the aggregator, gef 3.8.2 
should now be properly included as well.

Cheers
Alexander

Am 22.02.2013 um 15:57 schrieb Matthias Sohn :

> 2013/2/22 Matthias Sohn 
> 2013/2/22 David M Williams 
> I'm obviously a little late with my "Wait" message, but given the "data 
> damaging" bug reported by EGit, We need to think this through and come up 
> with an alternative plan. 
> 
> All those plans would involve not releasing today. 
> 
> I'll call for an "Emergency meeting" of the Planning Council today at 1:00 PM 
> Eastern to discuss possible approaches, solutions, and actions required. 
> 
> Off hand, a complete respin cycle would take at least a week, maybe two, but 
> there might be ways to simply remove EGit, putting it back at its SR1 level, 
> producing that better known quantity, and letting EGit follow their own 
> release schedule, as they have been. 
> 
> Sorry for the late "Wait" notice. 
> 
> SR1 is EGit 2.1 
> 
> EGit candidates we could include:
> 2.3.1 which contains the bugfix for the data damaging bug
> 2.2.0 released in Dec 
> 2.1.0 released with Juno SR1 
> 
> I am on standby to update the EGit contribution to whatever version you 
> decide on.
> 
> I have prepared a commit to update the EGit SR2 contribution to 2.3.1, b3 
> validation looks fine.
> 
> It contains the following fixes on top of 2.3.0:
> - JGit Fixes: Bug: 401249 (that's fixing the data damaging bug), Bug: 400818 
> (minor fix for handling of ChangeIds in staging view)
> - EGit Fixes: Bug: 400662 (minor fix to fix rendering of commit message 
> editor on Windows)
> 
> If planning council decides for a respin I am ready to push this change.
> 
> --
> Matthias 
> _______
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Reminders for Juno SR2 final steps

[Alexander Nyßen]

This would also help us to properly deal with: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401477

Cheers
Alexander

Am 22.02.2013 um 11:55 schrieb Gunnar Wagenknecht :

> When it's really too late for SR2, the plan should be made for a SR2a.

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Build.eclipse.org Down

[Alexander Nyßen]

Denis, 

when trying to run my promotion script (in order to prepare the GEF 3.8.2 
release), I run into the problem that file permissions do not seem to be 
properly restored on /shared, i.e. I am for instance not allowed to access 
/shared/jobs/gef-maintenance.

Cheers
Alexander

Am 21.02.2013 um 22:21 schrieb Alexander Nyßen :

> I still can't access hudson.eclipse.org... 
> 
> Cheers
> Alexander
> 
> Am 21.02.2013 um 20:17 schrieb Denis Roy :
> 
>> build.eclipse.org is back online, and /shared is being restored.
>> 
>> Apologies for the long delay.
>> 
>> Denis
>> 
>> 
>> On 02/21/2013 01:50 PM, Dennis Hübner wrote:
>>> 
>>> Am 21.02.2013 um 17:45 schrieb Denis Roy:
>>> 
>>>> FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece 
>>>> that has been taking a beating 24/7.  Quality iron right there, folks.
>>> 
>>> Sounds like binford 3000 hard drive. hr hr hr hr.
>>> :)
>>> 
>>> 
>>> Regards,
>>> Dennis Hübner
>>> 
>>> Xtext Commiter / Build Engineer
>>> 
>>> 
>>> Mobile: +49 (0) 151 / 17 39 67 07
>>> Telefon: +49 (0) 431 / 990 268 70
>>> Fax: +49 (0) 431 / 990 268 72
>>> 
>>> itemis AG
>>> Niederlassung Kiel
>>> Am Germaniahafen 1
>>> 24143 Kiel
>>> http://www.itemis.de/
>>> 
>>> Rechtlicher Hinweis:
>>> 
>>> Amtsgericht Dortmund, HRB 20621
>>> 
>>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>>> Trompeter, Sebastian Neus
>>> 
>>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>>> 
>>> 
>>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> --  
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nys...@itemis.de 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Build.eclipse.org Down

[Alexander Nyßen]

I still can't access hudson.eclipse.org... 

Cheers
Alexander

Am 21.02.2013 um 20:17 schrieb Denis Roy :

> build.eclipse.org is back online, and /shared is being restored.
> 
> Apologies for the long delay.
> 
> Denis
> 
> 
> On 02/21/2013 01:50 PM, Dennis Hübner wrote:
>> 
>> Am 21.02.2013 um 17:45 schrieb Denis Roy:
>> 
>>> FWIW, the failed hard drive in /shared is an almost 9-year-old IBM piece 
>>> that has been taking a beating 24/7.  Quality iron right there, folks.
>> 
>> Sounds like binford 3000 hard drive. hr hr hr hr.
>> :)
>> 
>> 
>> Regards,
>> Dennis Hübner
>> 
>> Xtext Commiter / Build Engineer
>> 
>> 
>> Mobile: +49 (0) 151 / 17 39 67 07
>> Telefon: +49 (0) 431 / 990 268 70
>> Fax: +49 (0) 431 / 990 268 72
>> 
>> itemis AG
>> Niederlassung Kiel
>> Am Germaniahafen 1
>> 24143 Kiel
>> http://www.itemis.de/
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> 
>> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Is GEF late for Kepler M5

[Alexander Nyßen]

Hi guys,

sorry for the inconvenience, but my planning council calendar data seems to 
have been outdated (I was not aware there is a Kepler M5 as well this week; I 
was only aware of Juno RC3). Nevertheless, as there haven't been any changes to 
GEF since 3.9.0 M4, we may simply reuse the M4 build as M5, so the simultaneous 
release will not be affected.

Cheers
Alexander
 
Am 06.02.2013 um 19:31 schrieb "Konstantin Komissarchik" 
:

> I have not seen a notice message. Is GEF late for Kepler M5? I am not seeing 
> an M5 build listed on the downloads page.
>  
> http://www.eclipse.org/gef/downloads/index.php
>  
> Thanks,
>  
> - Konstantin
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] EMF Validation has not been enabled for Kepler

[Alexander Nyßen]

Hi all, 

just an additional comment: this does not hold for GEF (where Anthony is 
project lead as well), which I have already enabled for Kepler, because GEF is 
already based on Git/Tycho.

Cheers
Alexander

Am 16.08.2012 um 16:41 schrieb Anthony Hunter:

> Hi Team, 
> 
> I received a bunch of emails about several projects I own on the simultaneous 
> release train, none of which are enabled for Kepler. EMF Validation is the 
> lowest dependency that seems to affect the most projects, GMF Notation, GMF 
> Runtime and EMF Transaction are also on the list. 
> 
> These projects need to move to a new build and Git. Moving to a new build 
> means moving to the CBI / long term support build. The CBI is making good 
> progress but nothing is really documented yet. 
> 
> I have made the decision that I am not enabling these projects for Kepler 
> until the Git migration and the new build is complete. I do not want to 
> enable now, have things fall apart in a few months and then have to remove 
> projects from Kepler again. 
> 
> Sorry for the inconvenience. 
> 
> Cheers...
> Anthony
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Problems with tampered Maven Dash Repo

[Alexander Nyßen]

Hi all,

as regularly as the sun rises, my gef builds start to fail because of problems 
with the Eclipse Signing Plugin (see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=382238). I don't know what's the 
final reason behind this (disk space probably), but it is really getting 
annoying. Has been broken again for 4 days already, and I am not able to 
produce a single build if I leave singing in place. Isn't there anything we can 
do against it?

Cheers
Alexander

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Testing p2.mirrorsURL

[Alexander Nyßen]

Then I would like to forward the question to the p2 experts. Does p2.mirrorsURL 
work in combination with .blobstore?

Cheers
Alexander

Am 20.06.2012 um 17:46 schrieb Denis Roy:

> .blobstore directories are being mirrored:
> 
> http://ftp.osuosl.org/pub/eclipse/egf/updates/helios/0.6.0_old/.blobstore/
> http://www.gtlib.gatech.edu/pub/eclipse/egf/updates/indigo/1.0.0RC2/.blobstore/
> 
> Denis
> 
> 
> On 06/20/2012 11:36 AM, David M Williams wrote:
>> I find this "interesting" for a couple of reasons. 
>> 
>> It sounds like we do not mirror .blobstore directories? Denis, can you 
>> confirm rsync rules? It would kind of make sense not to by default, since 
>> "dot directory" ... but, seems ".blobstore" should be an exception. 
>> 
>> I'm not sure of all the ins and outs (a p2 expert could speak to this) but 
>> sometimes "publishing a repo" puts all the jar.pack.gz files in .blobstore 
>> directory instead of as peers to their corresponding jars. 
>> 
>> Second, if we "must not" use .blobstore for eclipse foundation mirrored 
>> repos, I am not sure we have ever documented that or provided any "how to". 
>> And, if I recall, the "how to" isn't obvious ... not too hard once you know 
>> the trick ... but, I do not recall the trick right off (I believe it has to 
>> do with "copying properties from existing repo" that does not use 
>> .blobstore, but I don't recall how to "get" that original repo?). 
>> 
>> Sounds like you solved this recently, Alexander, ... perhaps you could add a 
>> note to 
>> http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL 
>> if/when Denis confirms "can not" (or, "should not", or "must not") mirror 
>> .blobstore directories? 
>> 
>> [And, I should apologize in advance if this is actually documented/discussed 
>> somewhere already ... sometimes I forget what I don't know :) ] 
>> 
>> Thank you both! 
>> 
>> 
>> 
>> 
>> 
>> From:Denis Roy  
>> To:cross-project-issues-dev@eclipse.org, 
>> Date:06/20/2012 09:08 AM 
>> Subject:Re: [cross-project-issues-dev] Testing p2.mirrorsURL 
>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> Alexander,
>> 
>> Thanks for testing that.
>> 
>> I hope other projects are also testing their repos for mirror
>> functionality...  I will accept criticism that download.eclipse.org is
>> slow due to our bandwidth limitations, but if mirrors are not being
>> used, that makes matters much worse.
>> 
>> Thanks,
>> 
>> Denis
>> 
>> 
>> On 06/20/2012 12:45 AM, Alexander Nyßen wrote:
>> > Just in case somebody might be interested: it seems that the mirror 
>> > problem was caused by having the update-site in a format that included a 
>> > .blobstore for the pack.gz files. Having converted the update-site to a 
>> > form, where pack.gz files are located next to the related bundles, I could 
>> > observe a different output this morning (after there are now a couple of 
>> > mirrors that have updated themselves to the changes).
>> >
>> > Cheers,
>> > Alexander
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Testing p2.mirrorsURL

[Alexander Nyßen]

Hi David,

yeah, if Denis confirms that this was indeed the case for my mirror problems, I 
will update the wiki pages with a section on that, explaining also how to 
convert the repo (the trick is to create a fake artifacts.xml which provides a 
publishPackFilesAsSiblings property and use this as format in the p2.mirror 
task)...

Cheers
Alexander

Am 20.06.2012 um 17:36 schrieb David M Williams:

> I find this "interesting" for a couple of reasons. 
> 
> It sounds like we do not mirror .blobstore directories? Denis, can you 
> confirm rsync rules? It would kind of make sense not to by default, since 
> "dot directory" ... but, seems ".blobstore" should be an exception. 
> 
> I'm not sure of all the ins and outs (a p2 expert could speak to this) but 
> sometimes "publishing a repo" puts all the jar.pack.gz files in .blobstore 
> directory instead of as peers to their corresponding jars. 
> 
> Second, if we "must not" use .blobstore for eclipse foundation mirrored 
> repos, I am not sure we have ever documented that or provided any "how to". 
> And, if I recall, the "how to" isn't obvious ... not too hard once you know 
> the trick ... but, I do not recall the trick right off (I believe it has to 
> do with "copying properties from existing repo" that does not use .blobstore, 
> but I don't recall how to "get" that original repo?). 
> 
> Sounds like you solved this recently, Alexander, ... perhaps you could add a 
> note to 
> http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL 
> if/when Denis confirms "can not" (or, "should not", or "must not") mirror 
> .blobstore directories? 
> 
> [And, I should apologize in advance if this is actually documented/discussed 
> somewhere already ... sometimes I forget what I don't know :) ] 
> 
> Thank you both! 
> 
> 
> 
> 
> 
> From:Denis Roy  
> To:cross-project-issues-dev@eclipse.org, 
> Date:06/20/2012 09:08 AM 
> Subject:Re: [cross-project-issues-dev] Testing p2.mirrorsURL 
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> 
> 
> 
> Alexander,
> 
> Thanks for testing that.
> 
> I hope other projects are also testing their repos for mirror
> functionality...  I will accept criticism that download.eclipse.org is
> slow due to our bandwidth limitations, but if mirrors are not being
> used, that makes matters much worse.
> 
> Thanks,
> 
> Denis
> 
> 
> On 06/20/2012 12:45 AM, Alexander Nyßen wrote:
> > Just in case somebody might be interested: it seems that the mirror problem 
> > was caused by having the update-site in a format that included a .blobstore 
> > for the pack.gz files. Having converted the update-site to a form, where 
> > pack.gz files are located next to the related bundles, I could observe a 
> > different output this morning (after there are now a couple of mirrors that 
> > have updated themselves to the changes).
> >
> > Cheers,
> > Alexander
> >
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Testing p2.mirrorsURL

[Alexander Nyßen]

 2012 - [main] Unsaved preferences when shutting 
down 
org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager


Am 19.06.2012 um 20:24 schrieb Alexander Nyßen:

> Hi again,
> 
> to validate that the p2.mirrorsURL is properly configured within the GEF 
> releases update-site (after I have updated the artifacts.jar accordingly), I 
> used a p2.director with debug output, as described in 
> http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL. As it says there, the 
> mirror information should only be logged to console if the p2.mirrorsURL 
> property is properly configured. This is the case for me (see log output 
> below). I just wonder why the only mirror that seems to be selected is 
> download.eclipse.org. Is there anything wrong with the p2.mirrorsURL or is 
> the site just not mirrored (when browsing to the provided mirrorsURL, which 
> is 
> http://www.eclipse.org/downloads/download.php?format=xml&file=/tools/gef/updates/releases,
>  I can see quite a large list)?
> 
> Cheers,
> Alexander
> 
> BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=de_DE
> Framework arguments:  -application org.eclipse.equinox.p2.director 
> -repository http://download.eclipse.org/tools/gef/updates/releases -installIU 
> org.eclipse.gef.all.feature.group
> Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -consoleLog -debug 
> /Users/nyssen/Workspaces/GEF/p2.options -application 
> org.eclipse.equinox.p2.director -repository 
> http://download.eclipse.org/tools/gef/updates/releases -installIU 
> org.eclipse.gef.all.feature.group
> 
> !ENTRY org.eclipse.core.net 1 0 2012-06-19 20:18:42.657
> !MESSAGE System property http.nonProxyHosts has been set to 
> local|*.local|169.254/16|*.169.254/16 by an external source. This value will 
> be overwritten using the values from the preferences
> Installing org.eclipse.gef.all.feature.group 
> 3.7.2.v20110927-2020-787G37PhW7N_Hp6y4tTASvJ0EGpz.
> [p2] Tue Jun 19 20:18:46 CEST 2012 - [Worker-1] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/features/org.eclipse.draw2d.sdk_3.7.2.v20110927-2020-7A7I38yF6F19G9K5A7H558C58x42.jar:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,-1)
> [p2] Tue Jun 19 20:18:46 CEST 2012 - [Worker-3] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/features/org.eclipse.draw2d.source_3.7.2.v20110927-2020-4617w3122212803131.jar:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,-1)
> [p2] Tue Jun 19 20:18:46 CEST 2012 - [Worker-0] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/features/org.eclipse.draw2d_3.7.2.v20110927-2020-4617w3122212803131.jar:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,-1)
> [p2] Tue Jun 19 20:18:46 CEST 2012 - [Worker-2] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/.blobstore/4a/d06ae39d33410011176597eaff957b3f:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,-1)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-1] Updated mirror 
> Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,110712)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-3] Updated mirror 
> Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,107202)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-1] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/features/org.eclipse.gef.examples_3.7.2.v20110928-2020-7G7Y3BgJ9EBCXDS4J9S9.jar:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,107202)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-3] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/features/org.eclipse.gef.all_3.7.2.v20110927-2020-787G37PhW7N_Hp6y4tTASvJ0EGpz.jar:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,107202)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-0] Updated mirror 
> Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,101727)
> [p2] Tue Jun 19 20:18:47 CEST 2012 - [Worker-0] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/.blobstore/5d/20dc5c9a33410011176597eaff957b3f:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,101727)
> [p2] Tue Jun 19 20:18:48 CEST 2012 - [Worker-3] Updated mirror 
> Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,90613)
> [p2] Tue Jun 19 20:18:48 CEST 2012 - [Worker-3] Selected mirror for artifact 
> http://download.eclipse.org/tools/gef/updates/releases/.blobstore/21/7095a09d33410011176597eaff957b3f:
>  Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,90613)
> [p2] Tue Jun 19 20:18:49 CEST 2012 - [Worker-1] Updated mirr

[cross-project-issues-dev] Testing p2.mirrorsURL

[Alexander Nyßen]

er-2] Updated mirror 
Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,93277)
[p2] Tue Jun 19 20:18:55 CEST 2012 - [Worker-1] Updated mirror 
Mirror(http://download.eclipse.org/tools/gef/updates/releases/,0,93360)
Operation completed in 15104 ms.
[p2] Tue Jun 19 20:18:57 CEST 2012 - [main] Unsaved preferences when shutting 
down 
org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager
MacNyssen-2:eclipse-4.2RC4 nyssen$ 

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] How serious are we about hiding our releases?

[Alexander Nyßen]

Ok, so I will have to promote to the update site but leave the old 
artifacts.jar and contents.jar there until the final release date (so the new 
release artifacts remain invisible until then but the mirrors can do their 
job), right? Well, this means that in order to assure correct handling of the 
p2.mirrorsURL property in my publish script I will have to tweak the existing 
artifacts.jar of our current releases update-site manually (as no other repo is 
mirrored) and perform the tests with it (i.e. using the 3.7.2 release 
artifacts). And then let's hope that my publish script (which uses the WTP 
addRepoProperties application) behaves the same

Cheers
Alexander

Am 19.06.2012 um 15:53 schrieb Denis Roy:

> On 06/19/2012 08:18 AM, Alexander Nyßen wrote:
>> 
>> Will it do any harm if I publish the release (which is anyhow promoted as 
>> RC4 on the milestones update-site) to the releases update-site in advance?
> 
> I can only speak from the infrastructure perspective.
> 
> As I type this, 18 mirrors (our configured limit) are connected and pulling 
> in the final bits for some projects.  As you can suspect, these mirrors draw 
> a noticeable amount of bandwidth.  As more projects move their files in their 
> final locations, our 50-or-so mirrors will be picking up the changes, and 
> we'll be under some strain for the rest of the week.  That's why we call this 
> "quiet week".
> 
> If some projects start publishing actual release bits, then we must also deal 
> with the added pain of supporting these user downloads.  Since the mirrors 
> are not fully caught up, download.eclipse.org will be the only server 
> available.  This will lead to congestion and grumpy users.
> 
> Don't underestimate the amount of users who "Check for updates" just out of 
> curiosity.  It's also no secret that Eclipse has a big release "sometime 
> towards the end of June" so as the days go by, anxious users get increasingly 
> click-happy.
> 
> Back in the old days we didn't have a sync period, and releases where quite 
> chaotic.
> 
> Denis
> 
> 
> 
>> 
>> Cheers,
>> Alexander
>> --
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de 
>> alexander.nys...@itemis.de 
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
>> Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> 
>> 
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] How serious are we about hiding our releases?

[Alexander Nyßen]

Hi,

I want to prepare the final GEF 3.8 release by promoting it to our releases 
update-site (mainly because I have recently built-in support for p2.mirrorsURL 
in our promotion script and I want to test it thoroughly). While I can hide all 
the drop files of the release (by masking them out with a hidden.txt) there is 
just have a single releases update-site (we do not maintain one per release), 
so I see no chance in hiding the release there, once I have mirrored it into? 
So, how serious do we take the off-line preparation policy? Will it do any harm 
if I publish the release (which is anyhow promoted as RC4 on the milestones 
update-site) to the releases update-site in advance?

Cheers,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Hudson seems to be restarting for quite a while...

[Alexander Nyßen]

Doesn't seem to help (as I said I had already cleaned my local workspace). I 
raised bug# 382238 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=382238) to 
keep track of it and reduce noise here...

Cheers,
Alexander

Am 11.06.2012 um 15:30 schrieb Denis Roy:

> Since Hudson maintains a local workspace on each slave, I'm not sure if 
> cleaning the workspace forcibly cleans all the workspaces on each Hudson node.
> 
> Anyway, I clicked the "wipe out workspace" on your job, and the file is now 
> gone.
> 
> Denis
> 
> On 06/11/2012 09:21 AM, Alexander Nyßen wrote:
>> 
>> Hmm, as I said I already cleaned the workspace (what should have included 
>> the .maven directory). Can it be a problem with the eclipse-dash maven 
>> repository?
>> 
>> Cheers,
>> Alexander
>> 
>> Am 11.06.2012 um 15:19 schrieb Denis Roy:
>> 
>>> The file below:
>>> 
>>>  
>>> /opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar
>>> 
>>> ...is zero bytes in size.
>>> 
>>> Denis
>>> 
>>> 
>>> On 06/11/2012 09:14 AM, Alexander Nyßen wrote:
>>>> 
>>>> After Hudson is back online, both my builds (gef and gef4) now fail with 
>>>> the following exception (cleaning the workspace didn't help):
>>>> 
>>>>  [ERROR] Internal error: java.lang.RuntimeException: 
>>>> org.apache.maven.MavenExecutionException: Could not setup plugin 
>>>> ClassRealm: Failed to parse plugin descriptor for 
>>>> org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5 
>>>> (/opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar):
>>>>  error in opening zip file -> [Help 1]
>>>> org.apache.maven.InternalErrorException: Internal error: 
>>>> java.lang.RuntimeException: org.apache.maven.MavenExecutionException: 
>>>> Could not setup plugin ClassRealm
>>>>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
>>>>at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>>>>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>>>>at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>at 
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>at 
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>at java.lang.reflect.Method.invoke(Method.java:597)
>>>>at 
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>>>>at 
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>>>>at 
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>>>>at 
>>>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
>>>> Caused by: java.lang.RuntimeException: 
>>>> org.apache.maven.MavenExecutionException: Could not setup plugin ClassRealm
>>>>at 
>>>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:178)
>>>>at 
>>>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.setupProjects(P2TargetPlatformResolver.java:140)
>>>>at 
>>>> org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.setupProject(DefaultTychoDependencyResolver.java:76)
>>>>at 
>>>> org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:56)
>>>>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273)
>>>>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>>>>... 11 more
>>>> Caused by: org.apache.maven.MavenExecutionException: Could not setup 
>>>> plugin ClassRealm
>>>>at 
>>>> org.eclipse.tycho.core.maven.utils.PluginRealmHelper.newMavenExecutionException(PluginRealmHelper.java:134)
>>>>at 
>>>> org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:125)
>>>>at 
>>>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetada

Re: [cross-project-issues-dev] Hudson seems to be restarting for quite a while...

[Alexander Nyßen]

Hmm, as I said I already cleaned the workspace (what should have included the 
.maven directory). Can it be a problem with the eclipse-dash maven repository?

Cheers,
Alexander

Am 11.06.2012 um 15:19 schrieb Denis Roy:

> The file below:
> 
>  
> /opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar
> 
> ...is zero bytes in size.
> 
> Denis
> 
> 
> On 06/11/2012 09:14 AM, Alexander Nyßen wrote:
>> 
>> After Hudson is back online, both my builds (gef and gef4) now fail with the 
>> following exception (cleaning the workspace didn't help):
>> 
>>  [ERROR] Internal error: java.lang.RuntimeException: 
>> org.apache.maven.MavenExecutionException: Could not setup plugin ClassRealm: 
>> Failed to parse plugin descriptor for 
>> org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5 
>> (/opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar):
>>  error in opening zip file -> [Help 1]
>> org.apache.maven.InternalErrorException: Internal error: 
>> java.lang.RuntimeException: org.apache.maven.MavenExecutionException: Could 
>> not setup plugin ClassRealm
>>  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
>>  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>>  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>>  at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>  at java.lang.reflect.Method.invoke(Method.java:597)
>>  at 
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>>  at 
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>>  at 
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>>  at 
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
>> Caused by: java.lang.RuntimeException: 
>> org.apache.maven.MavenExecutionException: Could not setup plugin ClassRealm
>>  at 
>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:178)
>>  at 
>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.setupProjects(P2TargetPlatformResolver.java:140)
>>  at 
>> org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.setupProject(DefaultTychoDependencyResolver.java:76)
>>  at 
>> org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:56)
>>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273)
>>  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>>  ... 11 more
>> Caused by: org.apache.maven.MavenExecutionException: Could not setup plugin 
>> ClassRealm
>>  at 
>> org.eclipse.tycho.core.maven.utils.PluginRealmHelper.newMavenExecutionException(PluginRealmHelper.java:134)
>>  at 
>> org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:125)
>>  at 
>> org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:158)
>>  ... 16 more
>> Caused by: org.apache.maven.plugin.PluginDescriptorParsingException: Failed 
>> to parse plugin descriptor for 
>> org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5 
>> (/opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar):
>>  error in opening zip file
>>  at 
>> org.apache.maven.plugin.internal.DefaultMavenPluginManager.extractPluginDescriptor(DefaultMavenPluginManager.java:212)
>>  at 
>> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:147)
>>  at 
>> org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:86)
>>  ... 17 more
>> Caused by: java.util.zip.ZipException: error in opening zip file
>>  at java.util.zip.ZipFile.open(Native Method)
>>  at java.util.zip.ZipFile.(ZipFile.java:114)
>>  at java.util.jar.JarFile.(JarFile.java:135)
>>  at java.u

Re: [cross-project-issues-dev] Hudson seems to be restarting for quite a while...

[Alexander Nyßen]

After Hudson is back online, both my builds (gef and gef4) now fail with the 
following exception (cleaning the workspace didn't help):

[ERROR] Internal error: java.lang.RuntimeException: 
org.apache.maven.MavenExecutionException: Could not setup plugin ClassRealm: 
Failed to parse plugin descriptor for 
org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5 
(/opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar):
 error in opening zip file -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: 
java.lang.RuntimeException: org.apache.maven.MavenExecutionException: Could not 
setup plugin ClassRealm
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: 
org.apache.maven.MavenExecutionException: Could not setup plugin ClassRealm
at 
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:178)
at 
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.setupProjects(P2TargetPlatformResolver.java:140)
at 
org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.setupProject(DefaultTychoDependencyResolver.java:76)
at 
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:56)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
... 11 more
Caused by: org.apache.maven.MavenExecutionException: Could not setup plugin 
ClassRealm
at 
org.eclipse.tycho.core.maven.utils.PluginRealmHelper.newMavenExecutionException(PluginRealmHelper.java:134)
at 
org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:125)
at 
org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.getDependencyMetadata(P2TargetPlatformResolver.java:158)
... 16 more
Caused by: org.apache.maven.plugin.PluginDescriptorParsingException: Failed to 
parse plugin descriptor for 
org.eclipse.dash.maven:eclipse-signing-maven-plugin:1.0.5 
(/opt/buildhomes/hudsonBuild/workspace/gef-nightly-tycho/.maven/repo/org/eclipse/dash/maven/eclipse-signing-maven-plugin/1.0.5/eclipse-signing-maven-plugin-1.0.5.jar):
 error in opening zip file
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.extractPluginDescriptor(DefaultMavenPluginManager.java:212)
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:147)
at 
org.eclipse.tycho.core.maven.utils.PluginRealmHelper.execute(PluginRealmHelper.java:86)
... 17 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:135)
at java.util.jar.JarFile.(JarFile.java:114)
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.extractPluginDescriptor(DefaultMavenPluginManager.java:170)
... 19 more

Any ideas?

Cheers,
Alexander

Am 11.06.2012 um 13:07 schrieb Dennis Hübner:

> Ed already opened a bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=382192
> 
> Dennis Hübner
> 
> Xtext Commiter / Build Engineer
> 
> Mobile: +49 (0) 151 / 17396687
> Telefon: +49 (0) 431 / 99026870
> Fax: +49 (0) 431 / 99026872
> 
> itemis AG
> Niederlassung Kiel
> Am Germaniahafen 1
> 24143 Kiel
> http://www.itemis.de/
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
> Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> Am 11.06.2012 um 12:52 schrieb Alexander Nyßen:
> 
>> Hi guys,
>> 
>> it seems Hudson has some trouble in restarting (I am 

Re: [cross-project-issues-dev] Javadoc generation / package-list

[Alexander Nyßen]

Hi Eike,

I think the easiest way will probably be to download and unzip the latest 
org.eclipse.platform.doc.isv bundle (the one in your target) during build and 
to have the javadoc tool link offline to it. I have built-in the same for 
Draw2d and GEF (where the doc plug-ins specify an optional dependency to the 
org.eclipse.platform.doc.isv bundle so the maven dependency plug-in can be used 
to make it available during build-time). We don't use Ant's javadoc task but 
invoke the javadoc tool directly (from ant), but you may take a look at the 
options we use for linking to the platform doc: 
http://git.eclipse.org/c/gef/org.eclipse.gef.git/tree/org.eclipse.draw2d.doc.isv/javadocOptions.txt

Cheers,
Alexander

Am 10.06.2012 um 19:46 schrieb Eike Stepper:

> Hi Ed,
> 
> Thanks for your answer but I don't understand how the javadoc tool in my Ant 
> build can resolve such a link to the package-list file in the Platform docs 
> ;-(
> 
> Is it possible that you're talking about links that you *manually* write into 
> your own docs? The ones I'm talking about are created by the javadoc tool and 
> that requires access to the package-list files.
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> 
> 
> Am 10.06.2012 19:15, schrieb Ed Willink:
>> Hi Eike
>> 
>> I use /help/topic/plugin-name...
>> 
>> Regards
>> 
>> Ed Willink
>> 
>> On 10/06/2012 17:45, Eike Stepper wrote:
>>> Hi,
>>> 
>>> Our Java code uses many Platform interfaces and classes and when we would 
>>> like to have hrefs to the Platform Javadocs
>>> in our generated Javadocs. The Ant script we're using contains this:
>>> 
>>> 
>>> ...
>>> 
>>> >> href="http://help.eclipse.org/topic//org.eclipse.platform.doc.isv/reference/api";
>>>  />
>>> 
>>> 
>>> 
>>> Unfortunately no clickable links end up in our docs. I have the feeling 
>>> this is because the help center servlet
>>> renders a full frameset when  requests the package-list file 
>>> (instead of returning just the file contents).
>>> 
>>> Is there a way to properly link with other doc plugins in the shared help 
>>> center?
>>> 
>>> Cheers
>>> /Eike
>>> 
>>> 
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>> 
>>> 
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>> 
>>> 
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.2178 / Virus Database: 2433/5060 - Release Date: 06/10/12
>>> 
>>> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Eclipse Juno Help

[Alexander Nyßen]

Hi all, 

as Juno is coming nearer, I would like to ask when it is intended to put up a 
(preliminary) Juno help page under http://help.eclipse.org. The issue I 
currently have is that I want to link GEF's javadoc against the proper Juno 
platform JavaDoc, if not now then at least when producing our final release 
(currently I am linking against the Indigo help pages). IMHO this will not be 
possible if there is nothing online in advance. Are there any concrete plans?

Cheers,
Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Linking to platform javadocs

[Alexander Nyßen]

Hi all,

I am currently struggling with how to properly link the javadocs of our 
plug-ins (org.eclipse.draw2d.doc.isv and org.eclipse.gef.doc.isv) agains those 
of the platform (i.e. org.eclipse.platform.doc.isv) and I thought I could find 
help here.

Currently, we have a javadoc.options file within each of our doc.isv plug-ins, 
which contain link statements of the form:

-link http://docs.oracle.com/javase/1.4.2/docs/api/
-link 
http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/

That seems to work in principle, but of course has the disadvantage that it 
links our javadocs to an outdated platform javadoc (namely that of the last 
release). I would rather like to link it to the current platform documentation 
instead, i.e. 4.2 for the Juno. Unfortunately no Juno help pages seem to be 
online yet.

When linking from org.eclipse.gef.doc.isv to org.eclipse.draw2d.doc.isv, I 
further have the problem that there is no Javadoc for Draw2d contained on 
help.eclipse.org/indigo currently, so I may not even link to an outdated 
version (we had problems in producing javadoc with the old build system, so 
javadoc was not published properly for the indigo releases) and will have to 
wait for the help.eclipse.org/juno being first populated.

How is that usually handled? Is the help.eclipse.org/Juno populated initially 
before the final release? Is there a way to provide a stable URL to point to 
the eclipse help of the latest release in such cases?

Cheers,
Alexander

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] GEF-Update-3.8.0M5.zip has extra directory level

[Alexander Nyßen]

As stated on the bug, I have re-created the .zip file accordingly (and adopted 
the publish scripts). It may however take some time until this is propagated to 
the download mirrors.

Cheers
Alexander

Am 31.01.2012 um 03:34 schrieb Konstantin Komissarchik:

> The GEF-Update-3.8.0M5.zip file has an extra directory level at the root of 
> the archive. That is, the repository metadata isn't at the root of the 
> archive. This is a departure from how this zip was packaged for 3.7.x and 
> earlier and not correct packaging for archived repositories.
>  
> This change breaks Sapphire project's build and jeopardizes our ability to 
> participate in Juno M5. Any chance this could be addressed this week so that 
> we don’t have to scramble to find a workaround? Perhaps a manual fix of the 
> M5 zip with fix in the build script handled in M6?
>  
> GEF-Update-3.8.0M5.zip has extra directory level
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=370179
>  
> Thanks,
>  
> - Konstantin
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--  
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nys...@itemis.de 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens 
Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev