Re: [cross-project-issues-dev] Open Software without Free Trade.

[Dennis Hübner]

I'm agree with Andrey.

I also have relatives and friends in both countries. At the moment my job and 
especially eclipse
is almost the last place where I can take a break of all the political insane 
that happens everywhere
around. 

If one need to send a signal, to whom ever, it can still be done by attending 
demonstrations or donate money. 


Viele Grüße,
Dennis

> Am 02.03.2022 um 09:16 schrieb Andrey Loskutov :
> 
> I appreciate your political engagement Jörg, but I believe the software is 
> not the right place to express any political statements, independently how 
> important they are. 
> 
> There are many other ways to publicly express any political opinions one may 
> have, and surely Eclipse Foundation can issue a statement regarding current 
> situation. 
> 
> I personally don't want to be reminded about war (or any other bad things 
> like hunger, AIDS, global warming) while waiting on the software to start.
> 
> The splash screen hurts me personally *a lot*, because I have relatives and 
> friends in *both* countries. 
> 
> I'm very sad about the war, seeing this splash again and again is like an 
> open wound that reminds me about pain. 
> I would appreciate if we consider not to add any reminder about the war to 
> Eclipse software.
> 
> 
> Am 1. März 2022 19:30:59 MEZ schrieb "Jörg Kubitz"  >:
>> So here is my proposal:  Splash screen for 4.23 (2022-03) "Make software
>> not War"
>> 
>> https://git.eclipse.org/r/c/platform/eclipse.platform/+/191325/1/platform/org.eclipse.platform/splash.png
>> 
 
 What about changing the splash screen (bug 575781) to a message (for
 example Ukraine flag blue + yellow).
 
>>> Perhaps. But ultimately that is a project decision.
>>> 
> 
> --
> Kind regards,
> Andrey Loskutov
> 
> https://www.eclipse.org/user/aloskutov 
> 
> Спасение утопающих - дело рук самих утопающих
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> 
> To 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 unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Unable to Contribute EMF 2.14 and Xcore 1.6.0M2 to Photon

[Dennis Hübner]

> Am 20.09.2017 um 10:32 schrieb Ed Willink <e...@willink.me.uk>:
> 
> Hi
> 
> Surely a no-brainer. EMF 2.14 is an entirely predictable advance to which all 
> downstream projects must adapt or be disabled.
> 
> But EMF is a +1 (early) contribution. Why is this problem occurring at +3 
> after OCL at +1 (late) has been contributed?
> 
> 
Because I was in vacation on +1 day and managed to build EMF + Xcore only today.

ECP will provide a fresh build for Photon M2. Thanks to the ECP team!

> Regards
> 
> Ed Willink
> 
> On 20/09/2017 09:16, Dennis Hübner wrote:
>> Hi,
>> 
>> I can’t add EMF 2.14 milestone to Photon.
>> The cause is that the ECP emfforms feature require an older emf databinding 
>> version.
>> We will need to either disable ECP or keep the EMF 2.13 in Photon M2. 
>> (eclipse runtime was build
>> against the newer EMF 2.14 version)
>> 
>> Best regards,
>> Dennis.
>> 
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: "Hudson CI (Code Review)" <ger...@eclipse.org 
>>> <mailto:ger...@eclipse.org>>
>>> Betreff: Change 105457 in simrel/org.eclipse.simrel.build[master]: 
>>> [xcore,emf] EMF 2.14, Xcore 1.6.0M2 Contribution for Photon
>>> Datum: 20. September 2017 um 09:24:27 MESZ
>>> An: Dennis Huebner <dennis.hueb...@gmail.com 
>>> <mailto:dennis.hueb...@gmail.com>>
>>> 
>>> Hudson CI has posted comments on this change. ( 
>>> https://git.eclipse.org/r/105457 <https://git.eclipse.org/r/105457> )
>>> 
>>> Change subject: [xcore,emf] EMF 2.14, Xcore 1.6.0M2 Contribution for Photon
>>> ..
>>> 
>>> 
>>> Patch Set 1: Verified-1
>>> 
>>> Build Failed
>>> 
>>> https://ci.eclipse.org/simrel/job/simrel.test.maven-gerrit/650/ 
>>> <https://ci.eclipse.org/simrel/job/simrel.test.maven-gerrit/650/> : FAILURE
>>> 
>>> https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/48/
>>>  
>>> <https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/48/>
>>>  : FAILURE
>>> 
>>> --
>>> To view, visit https://git.eclipse.org/r/105457 
>>> <https://git.eclipse.org/r/105457>
>>> To unsubscribe, visit https://git.eclipse.org/r/settings 
>>> <https://git.eclipse.org/r/settings>
>>> 
>>> Gerrit-MessageType: comment
>>> Gerrit-Change-Id: I0a2aff2aceb0b2b8321becc8ce23532003747ca1
>>> Gerrit-PatchSet: 1
>>> Gerrit-Project: simrel/org.eclipse.simrel.build
>>> Gerrit-Branch: master
>>> Gerrit-Owner: Dennis Huebner <dennis.hueb...@gmail.com 
>>> <mailto:dennis.hueb...@gmail.com>>
>>> Gerrit-Reviewer: Hudson CI
>>> Gerrit-HasComments: No
>> 
>> Dennis Hübner
>> 
>> TypeFox GmbH
>> Am Germaniahafen 1
>> 24143 Kiel
>> 
>> Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385
>> Managing Directors: Sven Efftinge, Moritz Eysholdt, Dr. Jan Köhnlein
>> 
>> 
>> 
>> 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/mailman/listinfo/cross-project-issues-dev 
>> <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> 
>  
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Viele Grüße,
Dennis Hübner



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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Unable to Contribute EMF 2.14 and Xcore 1.6.0M2 to Photon

[Dennis Hübner]

Hi,

I can’t add EMF 2.14 milestone to Photon.
The cause is that the ECP emfforms feature require an older emf databinding 
version.
We will need to either disable ECP or keep the EMF 2.13 in Photon M2. (eclipse 
runtime was build
against the newer EMF 2.14 version)

Best regards,
Dennis.


> Anfang der weitergeleiteten Nachricht:
> 
> Von: "Hudson CI (Code Review)" <ger...@eclipse.org 
> <mailto:ger...@eclipse.org>>
> Betreff: Change 105457 in simrel/org.eclipse.simrel.build[master]: 
> [xcore,emf] EMF 2.14, Xcore 1.6.0M2 Contribution for Photon
> Datum: 20. September 2017 um 09:24:27 MESZ
> An: Dennis Huebner <dennis.hueb...@gmail.com 
> <mailto:dennis.hueb...@gmail.com>>
> 
> Hudson CI has posted comments on this change. ( 
> https://git.eclipse.org/r/105457 <https://git.eclipse.org/r/105457> )
> 
> Change subject: [xcore,emf] EMF 2.14, Xcore 1.6.0M2 Contribution for Photon
> ..
> 
> 
> Patch Set 1: Verified-1
> 
> Build Failed
> 
> https://ci.eclipse.org/simrel/job/simrel.test.maven-gerrit/650/ 
> <https://ci.eclipse.org/simrel/job/simrel.test.maven-gerrit/650/> : FAILURE
> 
> https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/48/
>  
> <https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/48/>
>  : FAILURE
> 
> --
> To view, visit https://git.eclipse.org/r/105457 
> <https://git.eclipse.org/r/105457>
> To unsubscribe, visit https://git.eclipse.org/r/settings 
> <https://git.eclipse.org/r/settings>
> 
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I0a2aff2aceb0b2b8321becc8ce23532003747ca1
> Gerrit-PatchSet: 1
> Gerrit-Project: simrel/org.eclipse.simrel.build
> Gerrit-Branch: master
> Gerrit-Owner: Dennis Huebner <dennis.hueb...@gmail.com 
> <mailto:dennis.hueb...@gmail.com>>
> Gerrit-Reviewer: Hudson CI
> Gerrit-HasComments: No

Dennis Hübner

TypeFox GmbH
Am Germaniahafen 1
24143 Kiel

Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385
Managing Directors: Sven Efftinge, Moritz Eysholdt, Dr. Jan Köhnlein



Viele Grüße,
Dennis Hübner



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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Dennis Hübner]

Hi Michael,

is it possible to identify such an inconsistent state and provide a better 
error message?
The current error message is very misleading. I got this error when running the 
b3 aggregation tests
from the b3 editor before pushing to gerrit.
And I spend half an hour to find out what is wrong with my repository.

Regards,
Dennis.


> Am 24.05.2017 um 09:46 schrieb Mickael Istria <mist...@redhat.com>:
> 
> Hi Krum,
> 
> As far as I understand, the "legacy update site" issue may just be the way 
> aggragation failed because of the update, but not the cause of the failure. 
> We can imagine the during the aggregation process, your repo was updated 
> (update of repo during aggregation isn't supported by the aggregation 
> process), so it put aggregation in an inconsistent state and the aggregator 
> wrongly reported that the cause is usage of legacy update site.
> With last message from Alexander saying everything is working now, I think we 
> can assume everything is back to work and stop worrying about it.
> 
> HTH
> ___
> 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

Viele Grüße,
Dennis Hübner



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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] LSP4E participation to Oxygen

[Dennis Hübner]

Mickael,

AFAIK, incubating project may not start with major 1.
We (LSP4J) plan to start with 0.1.0 and hopefully provide 0.3.0 for the Oxygen 
release.

Kind regards,
Dennis.

> Am 06.12.2016 um 19:14 schrieb Mickael Istria <mist...@redhat.com>:
> 
> The LSP4E project would like to participate to the Oxygen simultaneous 
> release.
> 
> The goal of the project is to make the Eclipse IDE possible to consume 
> Language Servers conforming to the Language Server Protocol. Although it's 
> more to be perceived as a framework to very easily create support for new 
> languages in the Eclipse IDE, with most of the language logic separated and 
> reused/reusable as a language server, it also provides a way for end-users to 
> dynamically define a language server and take advantage of it in the IDE 
> without installing new plugins.
> (we'll probably reuse this blurb in the description)
> As the project is new and currently incubating, it's not yet know which 
> version will be suitable for Oxygen. Depending on the adoption by some other 
> projects, it may be 0.2.0, 0.N.0 or even 1.0.0, 1.0.1 or 1.1.0... This also 
> depends on the releases of the LSP4J project (LSP4E will most likely create a 
> new milestone release whenever LSP4J releases).
> 
> How should we handle this? Should we start by defining a 0.1.0 and a 0.2.0 
> milestone releases and announce 0.2.0 as candidate for Oxygen, with the high 
> priority of a version change?
> Thanks in advance
> -- 
> Mickael Istria
> Eclipse developer for Red Hat Developers <http://developers.redhat.com/>
> My blog <http://mickaelistria.wordpress.com/> - My Tweets 
> <http://twitter.com/mickaelistria>___
> 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

Viele Grüße,
Dennis Hübner

___
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] Announcing my changing job status

[Dennis Hübner]

David,
thank you for your support and the the great job you did (and do) as EP releng!

Kind regards,
Dennis.


> Am 10.08.2016 um 23:22 schrieb David M Williams <david_willi...@us.ibm.com>:
> 
> Some of you may have noticed from reading other lists that I have resigned 
> two Project Lead positions and announced I would no longer be working for IBM 
> after 8/16.  While many committers at Eclipse change jobs, employers, or 
> retire, most do not make a public announcement about it -- after all, it does 
> not affect one's status as a committer.  But, I thought I should say 
> something to this list since
> a. I won't be able to do near as much work I have been doing while employed 
> by IBM,
> b. my departure will impact several projects
> c. but I will not stop doing software engineering and,
> d. most importantly, I will NOT be ending my involvement in the Simultaneous 
> Release -- well, at least, not immediately.
> 
> The Eclipse Foundation and I have agreed I will work (part-time) under 
> contract to them through December to be sure Neon (.1 and .2) and Oxygen M4 
> are all released with minimal churn. Also, there are some things to simplify, 
> document, and put in place in CBI -- all so that my successor(s) can take 
> over more smoothly. [BTW, Mike and the Planning Council have known this was 
> coming for several months ... but I asked them not to mention it publically 
> until I did, and it has taken me that long to write a note this short. :) ]
> 
> As for some of my other roles:
> My role in Eclipse Platform Releng is transitioning gracefully to Sravan 
> Lakkimsetti. (Thanks, Sravan!)
> My role in Orbit is transitioning gracefully to Roland Grunberg (Thanks, 
> Roland!)
> 
> I do not know what projects I will work on in the future. But, I do know that 
> my immediate plans (other than a little more Sim. Release work) are to rest, 
> play, and contemplate the state of the universe -- at least for several 
> months -- before making any long term decisions.  I'd love to stay involved 
> in Eclipse if things happened to work out that way, but, there are a lot of 
> open source projects out there in the world (and related opportunities), and 
> I have never had time to look at them nearly as much as I would like to.  I 
> am grateful to have been able to work full time "in Eclipse" since 2004 when 
> WTP started. And while I am not exactly saying "goodbye," I will miss working 
> as closely and intensely as I have been with many of you and other 
> individuals and teams in Eclipse.
> 
> If anyone needs to contact me (outside the dev lists or bugzilla) --  
> especially after 8/16 -- best for now to use my personal email, which is 
> daddav...@gmail.com.
> 
> Thanks for reading,
> 
> ___
> 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

Viele Grüße,
Dennis Hübner



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

[Dennis Hübner]

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 <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
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Viele Grüße,
Dennis Hübner



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 of Mars repo report results

[Dennis Hübner]

 Am 01.06.2015 um 09:12 schrieb David M Williams david_willi...@us.ibm.com:
 
 And it is for a new bundle from Orbit,
 org.mozilla.javascript_1.7.5.v201504281450.jar
 (And, yes, I checked Orbit, and it is correct in that repository).
 See  
 https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.CLEAN_BUILD/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/verifydiroutput/errors8.txtJars
  that fail to verify (if any) 
 https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.CLEAN_BUILD/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/verifydiroutput/errors8.txt
 (which does not have much information, actually, but I documented in the bug 
 how to see more.
 I have opened Bug 467449 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=467449  to track this issue.


@David
An another output logged the following error cause (SHA-256 digest error):
   org.mozilla.javascript_1.7.5.v201504281450.jar:  Error: 1 was returned from 
command: /opt/public/common/jdk1.8.0_40.x64/jre/../bin/jarsigner -verify 
/home/data/httpd/download.eclipse.org/releases/staging/plugins/org.mozilla.javascript_1.7.5.v201504281450.jarjarsigner:
 java.lang.SecurityException: SHA-256 digest error for 
org/mozilla/classfile/ClassFileWriter$StackMapTable.class

See 
https://hudson.eclipse.org/simrel/view/All/job/simrel.build.repoReportsAndTests/lastSuccessfulBuild/artifact/test-report/reports-staging/reporeports/reports/signing.txt
 
https://hudson.eclipse.org/simrel/view/All/job/simrel.build.repoReportsAndTests/lastSuccessfulBuild/artifact/test-report/reports-staging/reporeports/reports/signing.txt



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



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] Luna SR2 RC3 staging (maintenance) repository and EPP packages are complete

[Dennis Hübner]

+1 for DSL Package (macosx 64)

Best regards,
Dennis.


 Am 13.02.2015 um 16:39 schrieb Markus Knauer mkna...@eclipsesource.com:
 
 Hi Developers,
 
 another week, another release. Luna SR2 RC3 is now available for testing from 
 the maintenance p2 repository.
 
 The EPP packages are available from the 'Developer Builds' tab on the 
 download page. Packages are listed as soon as they receive their mandatory +1 
 from their package maintainer, most of them are already available:
 
   https://www.eclipse.org/downloads/index-developer.php?release=luna 
 https://www.eclipse.org/downloads/index-developer.php?release=luna
 
 Very important are update tests from earlier Luna releases (R, SR1, SR1a). 
 For those tests you'll need to add the following two p2 repository URLs to 
 your Eclipse:
 
   http://download.eclipse.org/releases/maintenance/ 
 http://download.eclipse.org/releases/maintenance/
   http://download.eclipse.org/technology/epp/packages/luna/SR2-RC3/ 
 http://download.eclipse.org/technology/epp/packages/luna/SR2-RC3/
 
 /releases/maintenance with the Luna SR2 RC3 content will stay as is for 
 testing until Monday.
 
 Next week we are going to build RC4 which is the last build for Luna SR2 and 
 will be released after 'Quiet Week' on Friday 27th.
 
 Thanks for testing!
 
 Regards,
 Markus
 
  
 ___
 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

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/ 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
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] Who has pushed emf 2.10.1.v20140901-1043 to repo.eclipse.org

[Dennis Hübner]

 Am 30.01.2015 um 10:00 schrieb Tom Schindl tom.schi...@bestsolution.at:
 
 Hi,
 
 Projects using the xtend maven plugin as part of their build have seen
 build failures since yesterday night!
 
 I think the reason is a mismatch between the version scheme used by this
 unknown person who uses
 
 2.10.1.v20140901-1043 vs the artifacts at maven central use
 2.10.1-v20140901-1043
 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=458748
 
 Beside causing trouble to many projects the bigger question is whether
 we need a strict policy who is allowed to push stuff to nexus on behalf
 of e.g. the emf project.
 
 /me thinks that if you are not the project owner and you need artifacts
 not published by your favorite project you better do that in your own
 group-id.
Thats a good point!
I also don’t understand the reason to provide a copy of artifacts already 
released in maven central.
If there are some issues contact the emf-dev team to get them solved.

FYI: Martin Taal (@MartinTaal) is working now on 2.10.2 and pre 2.11.0 maven 
central releases.

Best regards,
Dennis.


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

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



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] Still disabled features/repositories for Mars M2?

[Dennis Hübner]

Hi Markus,
we have a test Job running for emf-rap 
https://hudson.eclipse.org/xtext/view/EMF/job/emf-rap-tests/
The initial test env. setup is provided by Maximilian Koegel (See CC) 
Target platform definition [1] uses rt/rap/nightly/runtime/ and latest emf 
build.
So I would say, emf and rap in Mars should be compatible.

[1] 
https://hudson.eclipse.org/xtext/view/EMF/job/emf-rap-tests/ws/git-repo/releng/org.eclipse.emf.releng.buckminster/target-platforms/developer-rap.target/*view*/

Best regards,
Dennis.

Am 01.10.2014 um 19:42 schrieb Markus Knauer mkna...@eclipsesource.com:

 Hi Dennis,
 
 I disabled the emf-emf-rap contribution for Mars M1 because EMF wasn't RAP 
 compatible at that time. I don't know the current state of EMF, but it would 
 be great if this contribution can be re-enabled for M2:
 
 On Wed, Oct 1, 2014 at 6:17 PM, David M Williams david_willi...@us.ibm.com 
 wrote:
 emf-emf-rap.b3aggrcon - org.eclipse.simrel.build
 
 Thanks,
 Markus

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



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] Can't access to any HIPP (404)

[Dennis Hübner]

We have the same problem.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=439975

Best regards,
Dennis.

Am 21.07.2014 um 09:35 schrieb Mikaël Barbero mikael.barb...@gmail.com:

 I can’t access to any HIPP (I get a 404).
 
 https://hudson.eclipse.org/p2/
 https://hudson.eclipse.org/oomph/
 https://hudson.eclipse.org/emfcompare/
 https://hudson.eclipse.org/egit/
 
 I tried to restart my HIPP (emfcompare), but it did not changed anything.
 
 Best regards,
 
 -- 
 Mikaël Barbero
 ___
 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

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



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] Remove CVS from Eclipse packages?

[Dennis Hübner]

Good idea!

Am 26.06.2014 um 11:12 schrieb Jürgen Rose juergen.r...@ibh-systems.com:

 +1
 
 On 26.06.2014 10:24, Mickael Istria wrote:
 Hi all,
 
 Now that CVS is only used by 3.7% of people according to latest Eclipse 
 survey, wouldn't it make sense to kick it out of default Eclipse packages to 
 avoid showing the useless CVS entries (in show view or import for example) 
 to the remaining 96.3% of Eclipse users? Instead, we could think of 
 providing CVS on marketplace.
 
 What do you think about it?
 -- 
 Mickael Istria
 Eclipse developer at JBoss, by Red Hat
 My blog - My Tweets
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 -- 
 IBH SYSTEMS GmbH
 D 85235 Pfaffenhofen an der Glonn
 Läutenring 43
 Geschäftsführer / CEO: Dr. Thomas Heitzig
 
 Amtsgericht München
 Handelsregister Nummer  HRB 197959
 USt ID: DE267945175
 
 Office Munich
 D 80992 München
 Agnes-Pockels-Bogen 1
 T +49 89 18 9 17 49 0
 
 The information transmitted is intended only for the person or entity
 to which it is addressed and may contain confidential and/or pivileged
 material. Any review, retransmission, dissemination or other use of,
 or taking of any action in reliance upon, this information by persons
 or entities other than the intended recipient is prohibited. If you
 received this in error, please contact the sender and delete the
 material from any computer.
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



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] External Buckminster update site restored

[Dennis Hübner]

Thats cool! Thanks a lot :)

Am 25.06.2014 um 23:00 schrieb Thomas Hallgren tho...@tada.se:

 The Buckminster update site that contains headless non EPL'ed additions 
 (subversion clients and emma code coverage) is now fully operational again 
 and can be accessed using the following URL's:
 
 http://download.cloudsmith.com/buckminster/external-4.4 (Luna)
 http://download.cloudsmith.com/buckminster/external-4.3 (Kepler)
 http://download.cloudsmith.com/buckminster/external-4.2 (Juno)
 
 Regards,
 Thomas Hallgren
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



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] Missing legal files

[Dennis Hübner]

Hello Wayne,
our four jars contains about.html named about_bundle.name.html.

Missing about.html in file: org.eclipse.xtend.lib.source_2.6.0.v201405210727.jar
Missing about.html in file: org.eclipse.xtend.lib_2.6.0.v201405210727.jar
Missing about.html in file: 
org.eclipse.xtext.xbase.lib.source_2.6.0.v201405210727.jar
Missing about.html in file: org.eclipse.xtext.xbase.lib_2.6.0.v201405210727.jar

Different naming is due to a limitation of same named resources in different 
jars, when running on android platform.
I already proposed a fix for the reports script to David. Hopefully we can 
merge the changes after Luna.

Kind regards,
Dennis Hübner.

Am 04.06.2014 um 17:45 schrieb Wayne Beaton wa...@eclipse.org:

 Some projects are missing required legal files in downloads.
 
 The master list is here:
 
 http://build.eclipse.org/simrel/luna/reporeports/reports/layoutCheck.txt
 
 I've contacted representatives from each project separately. This needs to be 
 addressed.
 
 Thanks for your attention in this matter.
 
 PMC-approved review materials are due today.
 
 Wayne
 -- 
 Wayne Beaton
 Director of Open Source Projects, The Eclipse Foundation
 Learn about Eclipse Projects
 eclipsecon-480x60.jpg
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



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] Change in the default java on build.eclipse.org

[Dennis Hübner]

Hi all,
I had the same problem with build.eclipse.org last week.
After trying around with combination of different processors and ant versions
I gave up and switched to the /usr/lib64/jvm/java-1_6_0-ibm-1.6.0
We really need a better JVM default, for HIPPs and build.eclipse.org.

Best regards,
Dennis.

Am 17.12.2013 um 22:38 schrieb Ed Willink e...@willink.me.uk:

 Hi Laurent
 
 A long time ago GNU Java was the almost unuseable default for vanilla Unix 
 systems.
 
 Have you perhaps just switched to a new unconfigured platform such as a HIPP 
 where the defaults are different?
 
  Regards
 
 Ed Willink
 
  
  
 On 17.12.2013 10:33, Laurent Goubet wrote:
 
 Hi,
 
 With Luna M4, we've begun to see strange failures in our ant promoters :
 javax.xml.transform.TransformerConfigurationException: no xsl:version 
 attribute on literal result node
 This happened for us on the ant promoters for EMF Compare and Acceleo, and 
 we also had a random failure on one of our builds : 
 https://hudson.eclipse.org/hudson/job/emf-ecoretools-1.1.0/51/console
 
 It seems like this same failure also happened for EMF : 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=420481
 
 I ultimately tracked this down to our JAVA_HOME pointing to a 1.5.0 gcj 
 version of the jre on build.eclipse.org :
 
  $JAVA_HOME/bin/java -version 
 java version 1.5.0 
 gij (GNU libgcj) version 4.3.4 [gcc-4_3-branch revision 152973] 
 
 Strangely enough, this isn't the version used in our PATH :
 
  java -version
 java version 1.6.0_27
 Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
 Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
 
 after exporting a more appropriate version, ours promoters started to work 
 anew :
 
  export JAVA_HOME=/shared/common/jdk-1.6.x86_64 
  export JAVA_ROOT=/shared/common/jdk-1.6.x86_64 
  export JAVA_BINDIR=/shared/common/jdk-1.6.x86_64/bin 
 
 Likewise, changing our failing hudson job's configuration from (Default) 
 to an explicit Java 6 R 30, the build worked like a charm.
 
 Was this change to java 1.5.0-gcj announced somewhere, or is that an 
 unexpected change?
 
 Laurent Goubet
 Obeo
  
  
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



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] Wrong push on Kepler SR2

[Dennis Hübner]

Hi Laurent,
our changes are still there (emf,xtext). So there is nothing to revert I think.

Regards,
Dennis.

Am 03.09.2013 um 17:00 schrieb Laurent Goubet:

 In fact ... I think the issue is just that I've used the default EGit's 
 pull instead of a pull rebase, so probably nothing to revert?
 
 Laurent Goubet
 Obeo
 
 On 03/09/2013 16:53, Laurent Goubet wrote:
 Hi all, 
 
 I just did something I don't really understand on the aggregation 
 repository, and pushed a merging commit ( 
 http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Kepler_maintenanceid=0caf9d67fc9d0d0bdcc18485fbb3f1181387d565
  ) along with my real commit, as a result I think I broke a number of other 
 projects (emf, xtext, koneki...). 
 
 I will revert these changes and hope that the merge didn't break anything 
 else. 
 
 Sorry about that. 
 
 Laurent Goubet 
 Obeo 
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 laurent_goubet.vcf___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



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] Ready for Luna (M1) aggregation ... and SR1 reminders

[Dennis Hübner]

Hi David,
Am 14.08.2013 um 18:55 schrieb David M Williams:

 need to be stable, before the rest of EMF is (you know, we have one of the 
 special relationships where we depend on them, and they depend on us :) ... 
 yet we are +0 and they are +1, as a whole. 
 For examples, see 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=414969 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=414968 

it would be nice to have a -2 calendar entry for emf-base build :)

Best reagrds,
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



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] Ready for Luna (M1) aggregation ... and SR1 reminders

[Dennis Hübner]

Am 15.08.2013 um 12:01 schrieb David M Williams:

  don't forget you can always have your own calendar

Really!? Thats cool


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



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] 6 month release cycle

[Dennis Hübner]

Am 09.07.2013 um 11:41 schrieb Mickael Istria:

 On 07/08/2013 09:49 PM, Konstantin Komissarchik wrote:
 
 1. New contributions are piled on, aggregation happens, problems are found 
 and need to be sorted out manually. Meanwhile, aggregation is broken and 
 more contributions pile on. The solution is to remove direct access to 
 aggregation metadata and process one contribution at a time. When a 
 contribution request is made, aggregation is performed. If it fails, the 
 contribution is rejected and the contributing project gets to figure out 
 what’s wrong without affecting anyone else.
 
 Seems like using Gerrit to process contributions into aggregator would help. 
 However, it means that someone has to review and merge this contributions 
 manually; but if this Gerrit review also triggers a Jenkins build that 
 validates the aggregation (without publishing it), it wouldn't be too 
 difficult to maintain as it would spot some errors early and automatically.


A lot of failed builds were caused by missing (suddenly deleted/disappeared) 
artifacts not by incoming model changes.
So autovalidation by Jenkins will probably prevent maintainers to submit a 
patch which fixes, but depends on the broken master state.
So IMHO gerrit would not eliminate the problem in the whole, but can probably 
make the maintenance not that easy


Best 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

Re: [cross-project-issues-dev] 6 month release cycle

[Dennis Hübner]

 All projects contribute the latest finished release they have, dependencies 
 are reconciled, some cross-testing happens and it’s out. Every month, there 
 is a repo with versions of all participating projects that are known to work 
 together. Users are happy because they only need to check for updates from 
 the aggregate repository that delivers new stuff to them frequently. Projects 
 are happy because they can set schedules that make sense for their needs and 
 if they miss one deadline, the next opportunity is not that far away.

Finally a good idea!
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) 
valuable.

Best 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

Re: [cross-project-issues-dev] What is a maintenance release

[Dennis Hübner]

Hi Martin,

the main point is, that Xtext was released with Juno in version 2.3.x and had a 
dependency
to Juno's EMF version 2.8. Now we have Kepler Stream where Xtext 2.4 and EMF 
2.9 is included. IMHO, if one tries to install
Xtext from Kepler in her/his Juno SRx, she/he should not wonder that this Xtext 
version will probably require some other bundles
from the Kepler common repository e.g. EMF 2.9 or eclipse platform 4.3 instead 
of 4.2. 

My opinion to the version numbering: if projects would increment their version 
each time their dependencies do, or if one the dependency
includes a performance change, some of eclipse projects would/should have a 
three digit major version now. I'm not quite sure, that changing the version 
4-5 times every year, helps adopters, and which is more important, I'm sure it 
would not reduce user's confusion.

Kind regards,
Dennis.



Am 27.06.2013 um 21:41 schrieb Oberhuber, Martin:

 Hi John,
  
 I agree with you in principle, but in this case Kosta does have a point.
  
 The Version Numbering document that you cite in [1] says
 “The minor segment number must be incremented when a plug-in changes in an 
 externally visible way. Examples […] include […]significant performance 
 changes”
  
 When XText decided to require EMF 2.9 in order to benefit from its 
 significant performance improvements, it would have made sense to release it 
 as XText 2.5 with a minor version increment; those Version Numbering 
 Guidelines should be followed to avoid adopter confusion.
  
 Now this hasn’t been done for Kepler, I’m not sure why it hasn’t been 
 detected earlier, and I’m not sure what the immediate implications are (other 
 than EdW having to stick to XText 2.4.1 and not being able to upgrade yet). 
 To me it sounds that Ed Merks’ proposal of making sure that EMF 2.9 is a 
 fully working drop-in replacement for EMF 2.8 in all cases is the right 
 approach moving forward.
  
 Thanks,
 Martin
 --
 Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
 direct +43.662.457915.85  fax +43.662.457915.6
  
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John 
 Arthorne
 Sent: Thursday, June 27, 2013 9:22 PM
 To: Cross project issues
 Subject: Re: [cross-project-issues-dev] What is a maintenance release
  
 I realize this was a rhetorical question, but the requirement is that 
 projects are capable of working with the version of their dependencies that 
 is shipped in the same simultaneous release. In this case the Kepler version 
 of XText requires the Kepler version of EMF. This is quite reasonable, and 
 although some projects support multiple older versions of their dependencies, 
 there is no requirement to do so that I'm aware of. 
 
 In both Eclipse versioning [1] and the more widely cited semantic versioning 
 [2], version increases don't have transitive effect (unless dependencies are 
 re-exported). I.e., just because the major or minor version of something I 
 require changes, doesn't mean my version has to increase by the same 
 magnitude. More concretely, the fact that EMF's minor version increased does 
 not imply that XText's minor version must increase. If you follow such a 
 transitive policy to its logical conclusion you will see the version numbers 
 of individual components become meaningless, impossible to manage, and 
 everyone would end up needing to increase their major version number just 
 about every release. 
 
 [1] http://wiki.eclipse.org/Version_Numbering 
 [2] http://semver.org/ 
 
 John 
 
 
 
 
 From:Ed Willink e...@willink.me.uk 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:06/27/2013 02:51 PM 
 Subject:Re: [cross-project-issues-dev] What is a maintenance release 
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 Hi Ed
 
 I am trying to understand what if any release rigour exists in the 
 Eclipse release policies; indeed if there are any policies at all.
 
 There is clearly a large discrepancy between my expectation and what I 
 observe in practice.
 
 Regards
 
 Ed Willink
 
 On 27/06/2013 18:50, Ed Merks wrote:
  You've also had ample opportunity to notice the bounds on Xtext's 
  contributions to the release train, so it's not clear what you're 
  hoping to achieve after the fact by involving a broader audience.
 
 ___
 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

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

Re: [cross-project-issues-dev] Xtext RC4

[Dennis Hübner]

Hi all,
Xtext RC4a was contributed to the simrel aggregator.
The changes should be available with the next  simrel.kepler.runaggregator 
build.

Best regards,
Dennis.

Am 12.06.2013 um 11:00 schrieb Sven Efftinge:

 Hi all,
 
 I just wanted to inform you that we are building an RC4a today (now).
 It contains an important bug fix, which won't affect any downstream projects, 
 but is important for end users.
 
 Regards,
 Sven
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] RC3 and Final Daze ...

[Dennis Hübner]

Hi David,
could you also adjust the script so that the special kind of about.html like 
about_bundle_id.html is detected?

Please see:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=401273
Missing about.html in file: org.eclipse.xtend.lib.source_2.4.2.v201306040922.jar
Missing about.html in file: org.eclipse.xtend.lib_2.4.2.v201306040922.jar
Missing about.html in file: 
org.eclipse.xtext.xbase.lib.source_2.4.2.v201306040922.jar
Missing about.html in file: org.eclipse.xtext.xbase.lib_2.4.2.v201306040922.jar
Best regards,
Dennis Hübner.

Am 05.06.2013 um 21:44 schrieb David M Williams:

  David, can you please plan to re-run the script on Friday?
 
 Yes, it is ran each time staging is updated ... and while staging will be 
 closed tonight and Thursday (to get RC3 EPP done) on Friday I will turn the 
 job back on, and promote new builds to staging whenever there is something 
 new to promote. (I will be out Friday afternoon, but will check in morning, 
 and again in evening). 
 
 Thanks, 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] EMF Repositories

[Dennis Hübner]

Hi Adolfo,
thanks for pointing to the outdated /interim link. I changed it right now.
This four composite repositories are pretty new and were created to keep
build scripts  simpler to maintain. So you can still the common name convention.
So it's like Kenn said we will keep the /2.9* repository layout and the others 
(nightly, interim, etc.) are just
redirects. 

Best regards,
Dennis.

Am 31.01.2013 um 19:20 schrieb Kenn Hussey:

 Adolfo,
 
 All that changed, AFAICT, is /nightly was added. I don't think the /2.9* 
 repositories are obsolete (they'd better not be!). The /interim repository 
 should certainly compose /2.9-I-builds if it doesn't currently.
 
 Kenn
 
 On Thu, Jan 31, 2013 at 12:27 PM, Adolfo Sanchez-Barbudo Herrera 
 adolfo...@gmail.com wrote:
 Hi Denis, Ed
 
 Xproject-ing since there could be other relengs interested.
 
 I've noticed that the EMF(core) p2 repositories layout has changed. Since 
 I've not found any information WRT this issue, could you confirm that:
 
 a) /2.9* are obsolete.
 b) The repositories to find the proper artefacts for the different kind of 
 build you have are:
 N-build - /nightly
 I-build - /interim
 S-build - /milestones
 R-build - /releases
 
 If so, please not that:
 
 /interim currently points to /2.8-I-builds
 /milestones currently points to /2.9-milestones
 
 Cheers,
 Adolfo.
 ___
 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

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

Re: [cross-project-issues-dev] Unnecessary build load on hudson.eclipse.org

[Dennis Hübner]

Denis,
pre-release tests and milestone build/-s (+2) are running.
So Xtext and Xtend are in a normal flow. 

Regards,
Dennis.


Am 18.12.2012 um 14:38 schrieb Denis Roy:

 I've noticed the same thing about Papyrus and Xtend / Xtext.  They seem to 
 always be building.
 
 And I thought we had moved from Continuous Integration to Continually 
 Integrating.
 
 I'll see if there is any tweaking we can do on our side.
 
 Denis
 
 
 
 
 On 12/18/2012 07:40 AM, Markus Tiede wrote:
 Hello,
 
 I noticed that there is an unnecessary build / job load on 
 hudson.eclipse.org being triggered due to an invalid / wrongly determined 
 SCM change in the jobs swtbot-e36 and swtbot-e37 [1].
 
 Those jobs seem to have run round about 18 x times during the last five 
 months as they check for an SCM change every minute (which seems to trigger 
 the build) though there is none.
 
 @SWTBot-Team: Could you please verify and resolve this issue?
 @Webmasters: Is there any way of sanity checking the execution frequency of 
 hudson jobs (aka hudson build time / job execution 
 time-/-amount-/-quota-report ;-) )?
 
 With best regards,
 MarkusT
 
 [1] https://hudson.eclipse.org/hudson/view/SWTBot/
 
 
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Kepler Aggregator cannot start

[Dennis Hübner]

It's the Faslane node only issue. 
If one could switch to e.g. slave1 build  would work.

Regards,
Dennis.

Am 02.10.2012 um 14:38 schrieb Tsvetkov, Krum:

 Hi,
  
 sorry for the spam if this problem was reported already in some form.
 The last two builds of the Kepler aggregator failed with the following 
 exception:
  
 Building remotely on Fastlane
 Checkout:simrel.kepler.runaggregator / 
 /opt/users/hudsonbuild/workspace/simrel.kepler.runaggregator - 
 hudson.remoting.Channel@115ed9ec:Fastlane
 Using strategy: Default
 Last Built Revision: Revision 021937fb7740edb6a70852dfbe338e4f4dee6d53 
 (origin/master)
 FATAL: cannot assign instance of hudson.EnvVars to field 
 hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in 
 instance of hudson.plugins.git.GitSCM$3
 java.lang.ClassCastException: cannot assign instance of hudson.EnvVars to 
 field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in 
 instance of hudson.plugins.git.GitSCM$3
 at 
 java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032)
 at 
 java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212)
 at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953)
 at 
 java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
 at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
 at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
 at 
 java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
 at 
 java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
 at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
 at 
 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
 at 
 java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at 
 hudson.remoting.UserRequest.deserialize(UserRequest.java:178)
 at hudson.remoting.UserRequest.perform(UserRequest.java:98)
 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
 at hudson.remoting.Request$2.run(Request.java:283)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)
  
 https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/136/console
  
 Any  idea how to overcome this? I just wanted to check that my contribution 
 doesn’t break the build J
  
 Krum
 ___
 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

Re: [cross-project-issues-dev] Hudson sandbox upgrade.

[Dennis Hübner]

Hello Matt,
is it somehow possible to copy some of the regular
hudson jobs to the sandbox instance, to have a test drive?
Or maybe even auto copy once a week or so.

Best 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

Am 24.09.2012 um 16:17 schrieb Webmaster(Matt Ward):

 Hi Folks,
 
  I just wanted to let you know that I'm planning to upgrade the version of 
 Hudson running on the sandbox to 3.0 on Wednesday Sept 26th.
 
 -Matt.
 ___
 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

Re: [cross-project-issues-dev] Status and Outlook for Juno!

[Dennis Hübner]

Am 13.06.2012 um 16:13 schrieb Ralf Sternberg:

 For the duplicate org.eclipse.rap.* bundles, 1.5.0.20120612-1458 our
 RC4 contribution, 20120605-1606 is RC3. I guess someone depending on
 the rap runtime has not picked up the RC4 yet, could that be EMF?
We include any rap bundles or features, therefore we have any prefect match 
dependencies to rap.
Just filter the latest rap version and look which project fails to validate (b3 
editor). Or grep for 
Provided Capabilities org.eclipse.rap* in b3aggr files.

Regards,
Dennis.

 
 The duplicate org.eclipse.jetty.xml bundles come from the rap tools.
 For some reason, they contain the RC3 version of these bundles. I will
 re-build the rap tools and contribute them to the aggregator. But
 since no one depends on them, this should not affect any other
 project.
 
 Thanks for pointing out these problems!
 
 Ralf
 
 
 On Wed, Jun 13, 2012 at 3:45 PM, John Arthorne john_artho...@ca.ibm.com 
 wrote:
 David Williams wrote on 06/12/2012 05:15:26 PM:
 
 I appreciate everyone keeping the build green and making progress
 on the sim rel reports [1], though there are a few serious issues
 left there.
 
 [1] http://build.eclipse.org/juno/simrel/reporeports/
 
 I looked through these, and at this point I think most of them are not
 blocking the release. Just to save people some time digging through them,
 these are the remaining issues that I believe are important for Juno (see
 above report for details):
 
 1) 10 bundles with missing about.html. Six bundles from emf.query2, four
 from Gemini.
 
 2) 10 features with no license (in particular their license is the string
 %license). 1 from Virgo, 9 from Gemini. The most common cause of this is
 missing key in feature.properties file, or the feature.properties file
 itself is not included in the bin.includes list in the feature's
 build.properties file.
 
 3) Multiple copies of bundles from eclipse.org projects. These might not be
 a problem if they are known or understood, but it might mean another project
 is including old, unreleased versions of another project's bundles. The
 core.commands dependency seems to be coming from Sapphire, and the remaining
 dependencies look like they come from RAP.
 
 org.eclipse.jetty.xml
 8.1.3.v20120522
 8.1.3.v20120416
 org.eclipse.core.commands
 3.6.1.v20120521-2332
 3.6.1.v20120521-2329
 org.eclipse.rap.jface
 1.5.0.20120612-1458
 1.5.0.20120605-1606
 org.eclipse.jetty.webapp
 8.1.3.v20120522
 8.1.3.v20120416
 org.eclipse.rap.rwt.osgi
 1.5.0.20120612-1458
 1.5.0.20120605-1606
 org.eclipse.rap.rwt
 1.5.0.20120612-1458
 1.5.0.20120605-1606
 
 John
 ___
 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

Re: [cross-project-issues-dev] Status and outlook for RC3

[Dennis Hübner]

Works well for me too. Saves a lot of time.
Looking forward for a SimRel Test hudson plugin on hudson.eclipse.org!
It should be configurable of cause, so one can disable some tests ;)

Regards,
Dennis.

Am 02.06.2012 um 20:39 schrieb Benjamin Cabé:

 It works like a charm, thanks Dave!
 
 
 De : David M Williams david_willi...@us.ibm.com
 Répondre à : Cross project issues cross-project-issues-dev@eclipse.org
 À : Cross project issues cross-project-issues-dev@eclipse.org
 Objet : Re: [cross-project-issues-dev] Status and outlook for RC3
 
 Yes, you can run the tests locally (against a local repository). I've made 
 some improvements over the past months to make the tests a little more 
 flexible and bullet proof, though since not many people have ran them locally 
 or in their own builds, the chances are good you can get in on the ground 
 floor and help improve them or the instructions. Instructions? Yes, I just 
 wrote some! See 
 http://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_Running_Locally
 Let us know how it goes. 
 
 Thanks, 
 
 
 
 
 From:Benjamin Cabé bc...@sierrawireless.com
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 Date:06/02/2012 08:03 AM
 Subject:Re: [cross-project-issues-dev] Status and outlook for RC3
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
  And the reports at http://build.eclipse.org/juno/simrel/reporeports/
  are looking much better than the last time I sent a nag note ... but, still 
  a lot of work to do for 5 or so projects to hit the minimum. 
 
 Is there a way to run the reports locally? I am pretty much sure I fixed all 
 the problems for the upcoming RC3 contribution of Koneki, but I'd be 
 interested in testing that locally before actually releasing an contributing.
 
 Thanks! 
 Benjamin. 
 
 
 
 
 De : David M Williams david_willi...@us.ibm.com
 Répondre à : Cross project issues cross-project-issues-dev@eclipse.org
 À : cross-project-issues-dev@eclipse.org 
 cross-project-issues-dev@eclipse.org
 Objet : [cross-project-issues-dev] Status and outlook for RC3 
 
 As we begin RC3, week, I wanted to report the good news that Virgo got their 
 problem figured out so everyone is currently in, and I've updated staging 
 (which would be sort of an RC2 Plus). 
 
 And the reports at 
 http://build.eclipse.org/juno/simrel/reporeports/
 are looking much better than the last time I sent a nag note ... but, still a 
 lot of work to do for 5 or so projects to hit the minimum. 
 
 I know everyone is busy fixing their own bugs, but things like missing 
 about.html are blocking bugs, and some of the other reports can indicate 
 serious problems, so I hope you find them useful. 
 
 I will be updating the Eclipse Project's contribution to RC3 level soon, 
 which will require RAP Runtime (and by ripple effect, Scout) to be disabled, 
 but I hope projects are winding down, making fewer changes, and perhaps we 
 will have an easy week for RC3? ... well ... most of us? 
 
 Good luck, and thanks to all! 
 
 ___
 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

[cross-project-issues-dev] Git polling is broken

[Dennis Hübner]

Hi all,
after the hudson restart yesterday, I noticed that some of my jobs were
building without any SCM changes. The git poll log says:
Last build was not on tied node, forcing rebuild.

After changing to an another node all worked fine. 
Hudson nodes are currently full,  because some jobs are rebuilding again and 
again.  (e.g. https://hudson.eclipse.org/hudson/job/hudson-core/scmPollLog/)
So please check if your project/job is also affected. 

Best regards,
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

___
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] More on greediness attribute

[Dennis Hübner]

Thank you for your briefly response, David.
 
 Obligatory. To be in common repo. From
 http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#OSGi_bundle_format
 
 quote
 Clarification on 02/01/2012: the repositories produced and contributed must 
 use p2 publishers that produce greedy='false', by default, in the content 
 metadata. See bug 247099 and the p2 Publisher wiki for some history and 
 details on this issue of greedy vs. non-greedy requirements. 
 /quote
 

Means, using the new p2 publisher is obligatory and greedy=false is not 
obligatory.
quoteIf the old behaviour is desired, i.e. an optional dependency shall be 
satisfied during installation whenever possible, the dependency can be 
annotated with an additional 
directive:resolution:=optional;x-installation:=greedy.
/quote
I use the new p2 publisher and x-installation directive. So it's ok. Still 
friends? :)

 
   I'd like that people accept, that this is a valid combination and don't 
  nag on projects, who use it.
 
 I've obviously not done a good job of education, but its not a valid 
 combination. Its been that way for years, wrongly, and so many people 
 complained about it something had to be done. (Not literally just because of 
 complaints, but conceptually ... people were convinced it is a bad idea to 
 automatically infer install behavior based on (optional) runtime requirements 
 ... and this repo-metadata-attribute solution was thought to be the least of 
 all evils, say as opposed to changing p2's behavior itself). 
 
Yes… We all have our horrors and our demons to fight. 

Thanks for your commitment.

 
 So we are trying to improve the yearly Release and its common repo. Yes, its 
 a change from previous years. And, now, the reason its a requirement to be in 
 common repo, is its something we must do consistently for it to work. 
 Otherwise, one project would be forcing their preferences on all other 
 participants. Or, worse, causing the install behavior to be undefined and 
 indeterminint. 
 
 I am going to try to improve the report. 
 
 Bug 380571 - greediness report needs work 
 
 Martin's pointed out what may be one bug. Maybe there's others. Plus, while I 
 was hoping to avoid spending so much of my time on this, I will see if I can 
 add back tracking to the report, so we'll know who has the conflicting 
 specifications. 
 
 If anyone knows now that they wants _all_ their optional runtime dependencies 
 to be installed greedily, then they should probably not be in the common 
 repo, and suggest they just have their own, where they can do what they want 
 with their metadata and not conflict with other participants.  I'm open to 
 discussion, but don't see how the conflicting specifications could ever work. 
 
  it's not as bad as missing about.html files or unsigned jars, isn't it?
 
 Right, not as bad as missing about.html files ... and, I don't know ... 
 almost as bad as unsigned jars :) 
 
 Thanks to all, 
 
 
 
 graycol.gifOberhuber, Martin ---05/24/2012 09:59:53 AM---Hmm,  I thought 
 we had been through all that discussion on bugzilla already (I can't find the 
 ref ri
 
 From: Oberhuber, Martin martin.oberhu...@windriver.com
 To:   Cross project issues cross-project-issues-dev@eclipse.org, 
 Date: 05/24/2012 09:59 AM
 Subject:  Re: [cross-project-issues-dev] Yet another nag note ... and, I 
 mean it this time!
 Sent by:  cross-project-issues-dev-boun...@eclipse.org
 
 
 
 Hmm, 
 
 I thought we had been through all that discussion on bugzilla already (I 
 can't find the ref right now since bugzilla is down).
 
 In a nutshell,
 
 - Optional greedy is bad since it can cause side-effects : 
  When I install A and optional greedy B,C happen to be available they get 
 installed even when I don't ask for them, causing unexpected side-effects.
 
 - Yes Optional non-greedy has no effect on the installer;
   But, the p2 metadata also serves as documenting the OSGi/runtime 
 dependencies from all MANIFEST.MF in a repo so having it in there is extra 
 information that may help some and doesn't hurt.
 
 Martin
 
 
 
 -Original Message-
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas 
 Hallgren
 Sent: Thursday, May 24, 2012 3:37 PM
 To: Cross project issues
 Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean 
 it this time!
 
 On 05/24/2012 03:13 PM, Gunnar Wagenknecht wrote:
  Am 24.05.2012 14:57, schrieb Thomas Hallgren:
  One could very well argue that an optional non-greedy dependency is 
  completely useless and doesn't fulfill any other purpose but documentation.
  We have a bunch of bundles in place that have optional non-greedy 
  dependencies to allow flexibility at runtime. For example, Logback can 
  be configured via API, XML or Groovy. Groovy as well as XML 
  configuration require additional dependencies. Imaging all those 
  dependencies were greedy.
 Then they would be installed of 

Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time!

[Dennis Hübner]

Hello Gunnar,

Am 24.05.2012 um 12:18 schrieb Gunnar Wagenknecht:

 Am 24.05.2012 11:33, schrieb Dennis Hübner:
 You say must, is the last year default deprecated?
 
 I think it's not explicitly deprecated. But it's legacy. ;)
@David It's not obligatory! So don't nag on project who use this optional 
greedy combination. :p 
 
 However we have over 250 optional dependency entries in 53
 bundles, instead of creating 53 p2.inf files I used the x-installation
 instruction:
 ;resolution:=optional;x-installation:=greedy,
 
 Yes, that works as well. It's a much easier way. However, I'm wondering
 if the report should have detected those as explicit and not as old
 default. Are you using the new publisher?
We use the latest buckminster so, yes we do.
 
 I tried to make our product behaves exactly the same as before the new
 default.
 
 I don't know your product well enough. Are those optional dependencies
 necessary for the product or the bundle as well? You may not need to
 explicitly set the greedy setting everywhere. Sometimes the new default
 is also ok.
 
Yes, it's true. We are going to reduce the count of optional greedy 
dependencies.
 IMHO a bundle uses 'resolution:=optional' to indicate either that a
 dependency is only necessary when additional functionality is wanted (a)
 or that additional functionality is available when the dependency is
 available (b).
 
 I see (b) purely as a user driven use case. For example, if Mylyn is
 available then integrate with Mylyn but do not install Mylyn when my
 bundle is installed. This use case should not use the greedy setting.
 
 A packager might want to provide a my feature + Mylyn package. That
 can be achieved by creating a feature (or product) which combines both.
 But then greedy also isn't necessary because the feature.xml makes an
 explicit reference.
I see one more constellation. A user installs tool X and you know that tool Y
is also very useful if one use tool X, so if a tool Y repository is 
available/active
it should be installed for better user experience. optional greedy case.

 
 For (a) some downstream consumer (another bundle) may require the
 dependency because it knows that it calls some extended API that
 requires the optional dependency. I think in this case the downstream
 consumer should define a non-optional dependency anyway so greedy isn't
 technical necessary.
Unfortunately, we reexport some of our optional dependencies it's very 
important for,
our downstream projects that this dependencies remain greedy.

Regards,
Dennis.

 
 HTH,
 Gunnar
 
 ___
 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

Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time!

[Dennis Hübner]

Hi David,

Am 24.05.2012 um 10:05 schrieb David M Williams:

  it often just intended by projects
 
 So, you think its right as it is? Great! 
 
Probably, and if not, it's not as bad as missing about.html files or unsigned 
jars, isn't it?
 
 If everyone is using the new publishers, then I'd still like to understand 
 why such vast numbers decided to use greedy=true (implicitly).
 
So it's a Use the new publisher thing… Is it obligatory for all eclipse 
projects? Or is it just a good practice.

Adopters can still decide if an optional dependency should be installed or not, 
by filtering it from the build target platform and Eclipse user can 
filter/deactivate the corresponding repository and so use a subset of project 
p2 repositories.
However, I don't want to convince you, that optional greedy make sense or not 
(by the way it was a default for years), I'd like that people accept, that this 
is a valid combination and don't nag on projects, who use it. :p
 Thanks, 
 
You are welcome.

  
 
 
 
 
 
 graycol.gifDennis Hübner ---05/24/2012 03:19:56 AM---Hi David,  Still 
 scores of projects that have not bothered to move to a current repo publisher 
 so t
 
 From: Dennis Hübner dennis.hueb...@itemis.de
 To:   Cross project issues cross-project-issues-dev@eclipse.org, 
 Date: 05/24/2012 03:19 AM
 Subject:  Re: [cross-project-issues-dev] Yet another nag note ... and,
 I mean it this time!
 Sent by:  cross-project-issues-dev-boun...@eclipse.org
 
 
 
 Hi David,
 Still scores of projects that have not bothered to move to a current repo 
 publisher so there are hundreds of incorrect greediness attributes.
 
 Sure there are greedy optional dependencies in the repository, because it 
 often just intended by projects. I don't understand, why are you talking 
 about incorrect greediness? Not a default it not the same as wrong.
 IMHO this [1] report  is only useful for statistic purpose.
 
 Regards,
 Dennis Hübner
 
 [1]  
 http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html
 
 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 24.05.2012 um 06:40 schrieb David M Williams:
 
 ___
 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

Re: [cross-project-issues-dev] Hudson change

[Dennis Hübner]

Am 07.12.11 14:09, schrieb Denis Roy:
 Well, then we have a problem.

 /shared is a NFS-mounted filesystem which is shared amongst all the
 build/hudson servers.  The NFS mount is problematic since you can't
 clean your workspace.

 So we *moved /shared/jobs* to a locally-mounted filesystem, which is
 *not shared*.  As far as I understand it, the new location shouldn't
 matter as you can use the https:// links to refer to the build
 artifacts.  Right?
No, that not right. Hudson access over https is fragile and slow.

 You will need to update your build/promote scripts to no longer refer to
 /shared/jobs.
It's not just a URL that have to be changed. We talk about protocol
change from file: to http/-s: !?
As you maybe know there are a lot of tools that can't deal with http:
content locations.

 BTW:

 file:/opt/users/hudsonbuild/

 shouldn't that be: file:///opt/users/hudsonbuild... ?
No it's file:/opt



 Denis


 On 12/07/2011 07:17 AM, Sven Efftinge wrote:
 Xtext and MWE are going to have a release today.
 But the problems Dennis mentioned are holding us back.

 Sven

 On Dec 7, 2011, at 11:23 AM, Dennis Hübner wrote:

 Hudson links aka
 file:/opt/users/hudsonbuild/.hudson/jobs/MWE-nightly-HEAD/lastSuccessful/archive/mwe.p2.repository/
 doesn't work either
 Means we can't fetch latest artifacts from jobs we depend on.

 Regards,
 Dennis.

 Am 07.12.11 10:58, schrieb Dennis Hübner:
 Hello Matt,
 I'm not quite sure that my issue is related to the latest changes, but
 I just noticed that our lastSuccessful/lastStable file system links a
 not up to date.
 Hudson web link
 https://hudson.eclipse.org/hudson/job/MWE-nightly-HEAD/lastStableBuild/
 points to 07.12.2011 build
 and file system link under /shared/jobs/MWE-nightly-HEAD/ still points
 to the old stable:
 lrwxrwxrwx   1 hudsonBuild callisto-dev26  2. Dez 13:11 lastStable
 - builds/2011-12-02_13-04-30

 Our promote scripts are using file system URL
 /shared/jobs/MWE-nightly-HEAD/ so right now I can't promote!

 Regards,
 Dennis.

 Am 06.12.11 17:46, schrieb Webmaster(Matt Ward):
 Hi Folks,

 As some of you know we've been having some issues recently with
 Hudson not letting go of files which causes issues when people try to
 clean up their workspace.  Denis and I have come up with a potential
 fix that will allow us to bypass NFS by mounting a disk image locally
 on the master that will contain the 'workspace' data.  However I need
 to copy the current data over and then restart Hudson.

 While short notice my plan is to do this today starting at 3pm.  I
 expect Hudson will be offline for about 20 minutes while the data
 syncs and I re-configure the master.

 if you absolutely must get your M build done and this will prevent
 that, please let me know ASAP.

 -Matt.

 -- 
 Dennis Hübner

 Softwareentwickler

 Mobil:   0151 173 96 707

 http://www.itemis.de/

 itemis AG
 Am Germaniahafen 1
 24143 Kiel

 Rechtlicher Hinweis:
 Amtsgericht Dortmund, HRB 20621
 Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
 Aufsichtsrat: Prof. 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


-- 
Dennis Hübner

Softwareentwickler

Mobil:   0151 173 96 707

http://www.itemis.de/

itemis AG
Am Germaniahafen 1
24143 Kiel

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
Aufsichtsrat: Prof. 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 change

[Dennis Hübner]

Am 07.12.11 14:32, schrieb Denis Roy:
 I guess that's worse than Hudson over NFS, which is fragile but fast? :-)
It's pretty stable in getting artifacts without Bad Gateway 503 errors
(or sometimes just 0byte jars ^^, bad checksums etc.)
 I understand... But what are the options? A shared filesystem isn't exactly 
 working right now.
Promoting artefacts produced on Hudson is complicated and annoying
enough e.g because
Hudson can't write to our project downloads location and now we can't
even browse Hudson jobs folder...
I think there are any other options, we need a read only file system
access on build.eclipse.org that points to Hudson's jobs/ folder.

  BTW:
 
  file:/opt/users/hudsonbuild/
 
  shouldn't that be:file:///opt/users/hudsonbuild... ?
  No it's file:/opt
 /opt/users/hudsonbuild... is the local working directory for each 
 master/slave 
 node. That directory has never been shared, so if you refer to files in that 
 path, your script may break if the job runs elsewhere.

 Unless I am mistaken, the most reliable way to refer to build artifacts, 
 regardless of which slave/master you're using is http/s. Please correct me if 
 I 
 am wrong. As I understand it, most Hudson installs employ slaves which do not 
 have a shared (amongst themselves) filesystem.
I use
-Dmwe.p2.repository=file:/opt/users/hudsonbuild/.hudson/jobs/MWE-nightly-HEAD/lastSuccessful/archive/mwe.p2.repository/
in buckminster build to fetch latest mwe artifacts. And it worked like a
charm..


 Denis

 
 
  Denis
 
 
  On 12/07/2011 07:17 AM, Sven Efftinge wrote:
  Xtext and MWE are going to have a release today.
  But the problems Dennis mentioned are holding us back.
 
  Sven
 
  On Dec 7, 2011, at 11:23 AM, Dennis Hübner wrote:
 
  Hudson links aka
  file:/opt/users/hudsonbuild/.hudson/jobs/MWE-nightly-HEAD/lastSuccessful/archive/mwe.p2.repository/
  doesn't work either
  Means we can't fetch latest artifacts from jobs we depend on.
 
  Regards,
  Dennis.
 
  Am 07.12.11 10:58, schrieb Dennis Hübner:
  Hello Matt,
  I'm not quite sure that my issue is related to the latest changes, but
  I just noticed that our lastSuccessful/lastStable file system links a
  not up to date.
  Hudson web link
  https://hudson.eclipse.org/hudson/job/MWE-nightly-HEAD/lastStableBuild/
  points to 07.12.2011 build
  and file system link under /shared/jobs/MWE-nightly-HEAD/ still points
  to the old stable:
  lrwxrwxrwx   1 hudsonBuild callisto-dev26  2. Dez 13:11 lastStable
  -  builds/2011-12-02_13-04-30
 
  Our promote scripts are using file system URL
  /shared/jobs/MWE-nightly-HEAD/ so right now I can't promote!
 
  Regards,
  Dennis.
 
  Am 06.12.11 17:46, schrieb Webmaster(Matt Ward):
  Hi Folks,
 
  As some of you know we've been having some issues recently with
  Hudson not letting go of files which causes issues when people try to
  clean up their workspace.  Denis and I have come up with a potential
  fix that will allow us to bypass NFS by mounting a disk image locally
  on the master that will contain the 'workspace' data.  However I need
  to copy the current data over and then restart Hudson.
 
  While short notice my plan is to do this today starting at 3pm.  I
  expect Hudson will be offline for about 20 minutes while the data
  syncs and I re-configure the master.
 
  if you absolutely must get your M build done and this will prevent
  that, please let me know ASAP.
 
  -Matt.
 
  -- 
  Dennis Hübner
 
  Softwareentwickler
 
  Mobil:   0151 173 96 707
 
  http://www.itemis.de/
 
  itemis AG
  Am Germaniahafen 1
  24143 Kiel
 
  Rechtlicher Hinweis:
  Amtsgericht Dortmund, HRB 20621
  Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
  Aufsichtsrat: Prof. 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
 
 
  -- 
  Dennis Hübner
 
  Softwareentwickler
 
  Mobil:   0151 173 96 707
 
  http://www.itemis.de/
 
  itemis AG
  Am Germaniahafen 1
  24143 Kiel
 
  Rechtlicher Hinweis:
  Amtsgericht Dortmund, HRB 20621
  Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
  Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael 
  Neuhaus

 -- 
 *Denis Roy*
 Director, IT Services
 Eclipse Foundation, Inc. -- http://www.eclipse.org/
 Office: 613.224.9461 x224 (Eastern time)
 denis@eclipse.org

 EclipseCon 2012 http://www.eclipsecon.org/2012


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


-- 
Dennis Hübner

Softwareentwickler

Mobil:   0151 173 96 707

http://www.itemis.de/

itemis AG
Am Germaniahafen 1
24143 Kiel

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Wolfgang