[cross-project-issues-dev] Published 2022-06 maven artifacts break people using jdt.core

[Tom Schindl via cross-project-issues-dev]

Hi,

Unforunately the maven artifacts published to maven-central as part of 
th 2022-06 release breaks everyone using:


org.eclipse.jdt:org.eclipse.jdt.core

in their maven builds because via the transitive paths it tries to 
resolve to (via org.eclipse.equinox.preferences):


org.osgi.service:org.osgi.service.prefs

who does not exists an maven central (at least).

My wild guess is that it is meant to reference

org.osgi:org.osgi.service.prefs

The worst is because of the use of version ranges this breaks almost all 
published jdt-core artifacts :-(


Tom
___
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] Simultaneous Release Participation

[Tom Schindl]

Hi,

I would strongly advise to use 3.5.0 release who is available since
yesterday!

Only this releases eg supports Java-11 and JavaFX-11 but in the end it
is up to you what you include.

You should never ship 3.3.0 because it will make Eclipse IDE crash when
running on Java-11!

Tom

On 01.03.19 14:10, Matthias Wienand wrote:
> Hi,
> 
> I added an entry for the required e(fx)clipse feature to the
> category.xml as follows:
> 
>    url="features/org.eclipse.fx.runtime.min.feature_2.4.0.201605100504.jar"
> id="org.eclipse.fx.runtime.min.feature" version="2.4.0.201605100504“/>
> 
> Since the corresponding build was running with NEON.target, I used the
> associated version of e(fx)clipse, however, I will probably update this
> to 3.3.0 in the future.
> 
> I believe the removal of e(fx)clipse and the addition at GEF need to
> happen in quick succession, for example, I could update the GEF
> contribution after removal of e(fx)clipse.
> 
> How do we proceed?
> 
> Best regards,
> Matthias
> --
> 
> Matthias Wienand
> B.Sc. Softwaretechnik
> Software Engineer
> 
> Telefon: +49 231 9860 202
> Telefax: +49 231 9860 211
> Mobil:   +49 152 26802283
> 
> 
> matthias.wien...@itemis.de <mailto:matthias.wien...@itemis.de>
> http://www.xing.com/profile/Matthias_Wienand2
> http://www.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
> 
>> Am 28.02.2019 um 19:14 schrieb Frederic Gurr
>> > <mailto:frederic.g...@eclipse-foundation.org>>:
>>
>> Hi Matthias,
>>
>> Did you have a chance to look at the required changes for GEF?
>>
>> We can't remove the e(fx)clipse contribution without those changes.
>>
>> Regards,
>>
>> Fred
>>
>> On 19.02.19 16:47, Matthias Wienand wrote:
>>> OK,
>>>
>>> I will try to resolve this at the start of next week and report back.
>>>
>>> Best regards,
>>> Matthias
>>> --
>>>
>>> Matthias Wienand
>>> B.Sc. Softwaretechnik
>>> Software Engineer
>>>
>>> Telefon: +49 231 9860 202
>>> Telefax: +49 231 9860 211
>>> Mobil:   +49 152 26802283
>>>
>>>
>>> matthias.wien...@itemis.de
>>> <mailto:matthias.wien...@itemis.de> <mailto:matthias.wien...@itemis.de>
>>> http://www.xing.com/profile/Matthias_Wienand2
>>> http://www.itemis.de <http://www.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
>>>
>>>> Am 19.02.2019 um 16:44 schrieb Aleksandar Kurtakov
>>>> >>> <mailto:akurt...@redhat.com> <mailto:akurt...@redhat.com>>:
>>>>
>>>>
>>>>
>>>> On Tue, Feb 19, 2019 at 5:41 PM Matthias Wienand
>>>> >>> <mailto:matthias.wien...@itemis.de> <mailto:matthias.wien...@itemis.de>>
>>>> wrote:
>>>>
>>>>    Hi,
>>>>
>>>>    it is not yet clear to me how to proceed. I could imagine that a
>>>>    version is made available via Orbit. 
>>>>
>>>>
>>>> Orbit is not meant for eclipse.org
>>>> <http://eclipse.org/> <http://eclipse.org/> projects.
>>>>  
>>>>
>>>>    Otherwise, I believe we would need to include what is needed in
>>>>    GEF directly.
>>>>
>>>>
>>>> Most probably this is what you would need to do. When Jetty dropped
>>>> from the release train whatever Eclipse Platform needed from it was
>>>> included in Platform's p2 repository.
>>>>  
>>>>
>>>>
>>>>    What do you think?
>>>>
>>>>    Best regards,
>>>>    Matthias
>>>>    --
>>>>
>>>>    Matthias Wienand
>>>>    B.Sc. Softwaretechnik
>>>>    Software Engineer
>>>>
>>>>    Telefon: +49 231 9860 202
>>>>    Telefax: +49 231 9860 211
>>&g

Re: [cross-project-issues-dev] Simultaneous Release Participation

[Tom Schindl]

Hi,

Yes - i know I'm behind schedule. We are still droping from the release
as announced earlier. Feel free to remove/deactivate us.

Tom

On 19.02.19 16:15, Wayne Beaton wrote:
> I'm a little overdue updating the participation page. I'm trying to get
> that sorted out today.
> 
> Let this serve as your notice that the RC1 date (March 8) is coming
> quickly. Dani updated the page to note that this is the "API and feature
> freeze" date. If you need to engage in a release review, then we also
> need your review materials by this date.
> 
> In the meantime, I've noticed that despite a notice that Eclipse
> e(fx)clipse would drop from the simultaneous release, I still still its
> enabled aggrcon file. What is the status of this project's participation?
> 
> After some churn, Eclipse Code Recommenders ended up in 2018-12, but is
> now marked as disabled. What is the participation status for this
> project in 2019-03?
> 
> It looks like we still have aggrcon files for Eclipse Amalgam and
> Eclipse Sphinx. I'm pretty sure that these projects dropped out a few
> iterations ago, so--unless there is some pushback--I'm going to push a
> Gerrit review to remove them.
> 
> Wayne
> 
> -- 
> 
> Wayne Beaton
> 
> Director of Open Source Projects | Eclipse Foundation, Inc.
> 
> 
> ___
> 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
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] e(fx)clipse intends to drop from 2019-03

[Tom Schindl]

Hi,

e(fx)clipse will drop from the release train. Our problem is exactly as
described as described by Wayne in "Preparing for 2019-03M2..."

We simply don't have the cycles to test our IDE-Contribution good enough
 causing trouble and casting a damning light on the Eclipse IDE.

People will be able to install our IDE integration using the Market-Place.

I don't know what this removal means for projects depending on our core
modules but I hope they can resolve them somehow.

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Java 11 (OpenJDK 11): javax.xml.bind package removed

[Tom Schindl]

Hi,

e(fx)clipse is affected by this as well but the bundle in Orbit quite
old. It's been on my list to bring the the latest javax.xml.bind version
to orbit.

Tom

On 17.10.18 17:57, Roland Grunberg wrote:
> On Wed, 2018-10-17 at 11:41 -0400, Keith Chong wrote:
>> Are other teams affected by the removal of the javax.xml.bind package from 
>> Java 11? 
>>
>> Web Tools Platform (WTP) Web services has 'unresolved' references when 
>> running with Java 11. See 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=539771.
>>
>> The solution would simply be to pull the javax.xml.bind package into WTP 
>> (from orbit), but, it was originally pulled out of WTP because of 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=446080
>> due to OSGi wiring issues. If we proceed with this solution, we might 
>> re-introduce the wiring issues when using a Java level (non-Java 11) that 
>> contains the deprecated packages. 
>>
>> The info in the two bugzillas indicate that other teams might be impacted by 
>> this. Dali (eg. eclipselink packages) and MyLyn. Thoughts?
> 
> Orbit is affected by this in the sense that there are packages that
> depend on javax.xml.bind (versionless) that we ship. In 
> http://eclip.se/539515 I've converted all the ones shipped in orbit-
> recipes (this is in our M1 contribution) so they'll resolve against our
> javax.xml.bind bundle but there's still a few more to fix.
> 
> Cheers,
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Tom Schindl]

Frankly I think you can just push what was there in 58.2 - as I outlined
there's no need to provide 62.1 as this is not required by any of the
projects we are talking about here.

Tom

On 04.10.18 18:26, Roland Grunberg wrote:
> Ok, so it's settled. This should be provided given that there's enough
> demand for it.
> 
> Now we just need com.ibm.icu.base 62.1 binary and source jar, which in
> the past was provided by IBM [1] or instructions on how to reproduce
> the base bundle.
> 
> Without that, my best guess is just compare 58.2 base/full bundles to
> see what should be included.
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

[cross-project-issues-dev] Major Bug when installing e(fx)clipse and running on Java-11

[Tom Schindl]

Hi,

Unfortunately there's a major bug in the e(fx)clipse version contributed
to 2018-09 release.

If one install e(fx)clipse and tries to run Eclipse on Java-11, Eclipse
refuses to launch!

The issue has been reported last week [1] and we shipped an 3.4.1 patch
release yesterday but naturally this is not going to be included in the
general update-site pre-installed in 2018-09 repository.

Tom

[1]https://github.com/eclipse/efxclipse-eclipse/issues/42

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Tom Schindl]

Hi,

In the bug you reference I don't see that the platform has lifted any of
its version range so one can happily run the complete codebase on the
old icu.base version.

In the end the right thing for the future is to get rid of ibm.icu from
the core platform (anything defining an e4 application) is the right way
forward.

I understand that for a IDE it does not make a big difference if your
download is 12MB larger but for a small RCP application it can be.

Anyways I'm packaging it into our target now so e(fx)clipse users are
not affected because they anyways point to our self-contained p2 repository.

Tom

On 03.10.18 17:25, Roland Grunberg wrote:
> On Wed, 2018-10-03 at 15:44 +0200, Tom Schindl wrote:
>> I'm late to this but while trying to bring our products up to 2018-09 I
>> found the removal of "com.ibm.icu.base" disturbing.
>>
>> The Mail from "Roland" says one should substitute "com.ibm.icu.base"
>> with "com.ibm.icu" which I think is a bad idea.
>>
>> The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
>> jar if you don't need any of the extra functionality "com.ibm.icu" provides.
> 
> Hey Tom,
> 
> If people would like to have corresponding com.ibm.icu.base for any
> version of com.ibm.icu, that's fine. It would just be a matter of
> ensuring the "base" version is available for the latest one in use as
> I'd rather not accumulate many older versions. This is a similar
> situation to things like Batik or Lucene, where platform handles the
> set of bundles it cares about, but anyone wanting more has to do the
> extra work.
> 
> The discussion for Platform to move to plain icu4j (from maven) was in 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 (comments 11-17)
> so it made sense to have everyone using the same thing, but maybe other
> projects outside SimRel may still want a smaller version so I'm not
> opposing this. For those projects, there is also the Photon Orbit repo
> which has the older versions (containing icu.base) as well.
> 
> Cheers,
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Tom Schindl]

Hi,

I'm late to this but while trying to bring our products up to 2018-09 I
found the removal of "com.ibm.icu.base" disturbing.

The Mail from "Roland" says one should substitute "com.ibm.icu.base"
with "com.ibm.icu" which I think is a bad idea.

The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
jar if you don't need any of the extra functionality "com.ibm.icu" provides.

Tom

On 01.08.18 22:01, Nick Boldt wrote:
> Possible impacts:
> 
> org.eclipse.recommenders.injection 2.5.3.v20180609-1554 requires
> com.google.guava 15.0. Unsure if a newer version exists which works w/
> Guava 21..
> 
> Not sure about the com.ibm.icu stuff -- is 62 compatible with 58? 
> 
> The rest - the apache felix and ant stuff - should hopefully be fine.
> 
> As to Lucene removals:
> 
> * org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5
> 
> * o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
> 
> * org.eclipse.datatools.sqltools.result (DTP) and
> org.eclipse.m2e.wtp.jpa.feature (WTP) both
> require org.apache.lucene.queryparser 6.1.0.v20161115-1612, which
> doesn't exist in 7.1 (Lucene loves to add and drop bundles will-nilly,
> don't they?)
> 
> So... either those bundles / features need updating to use lucene 7.1+
> or else they'll have to build against old Orbit... and Simrel will end
> up having multiple versions of these IUs peppered in the mix.
> 
> What version of HttpComponents are you thinking would be
> included/dropped? Currently I'm using httpcore 4.4.6 and httpclient
> 4.5.2, but I think I saw a thread about Platform moving to newer
> versions? cc: @Aleksandar Kurtakov <mailto:akurt...@redhat.com>  
> 
> Nick
> 
> 
> On Wed, Aug 1, 2018 at 3:10 PM Roland Grunberg  <mailto:rgrun...@redhat.com>> wrote:
> 
> Hey all,
> 
> I just wanted to give a heads-up that the following bundles (and
> corresponding source bundles) are expected to be removed from the Orbit
> build towards 2018-09, for M3 [1].
> 
> com.ibm.icu 56.1.0, 58.2.0 (use 62.0.0)
> com.ibm.icu.base 56.1.0, 58.2.0 (use com.ibm.icu 62.0.0)
> org.apache.felix.gogo.runtime 1.0.6 (use 1.1.0)
> org.apache.felix.gogo.shell 1.0.0 (use 1.1.0)
> org.apache.felix.scr 2.0.8, 2.0.10, 2.0.12 (use 2.0.14)
> com.google.guava 15.0.0, 18.0.0 (use 21.0.0)
> org.apache.ant 1.9.6, 1.10.3 (use 1.10.5, will be in soon)
> 
> There may be some additional bundles but they would be announced later
> on (possibly older Lucene, tukaani.xz, ASM, HttpComponents).
> 
> If any projects are unable to update for some reason, or there's a good
> reason not to remove one of these that I've missed, It would be good to
> know ahead of time, though there is always the option to reference an
> older build (eg. Photon) that would still contain them as well.
> 
> Thank-you,
> Roland Grunberg
> 
> [1]
> https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan#Schedule
> 
> 
> ___
> 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
> 
> 
> 
> -- 
> 
> Nick Boldt
> 
> Principal Software Engineer, RHCSA
> 
> Productization Lead :: JBoss Tools & Dev Studio
> 
> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
> 
> <https://red.ht/sig>  
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> 
> @ @redhatnews <https://twitter.com/redhatnews> Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.facebook.com/RedHatInc>
> 
> 
> “The Only Thing That Is Constant Is Change” - Heraclitus
> 
> 
> ___
> 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
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

[cross-project-issues-dev] e(fx)clipse will participate in 2018-09 Release

[Tom Schindl]

Hi,

e(fx)clipse will join the 2018-09 Release with version 3.4.0 and support
for OpenJFX-11 on Java-11!

The offset is +2

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
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

Re: [cross-project-issues-dev] Some projects have not yet declared their intention to participate in Photon

[Tom Schindl]

Hi,

I've been thinking a lot about this because the parts of e(fx)clipse who
are contributed to the SimRel-Repository are not the main working areas
in our company today.

Still I think the JavaFX-Tooling is a valuable component for Eclipse
users hence I declare that e(fx)clipse will join the Photon
Release-Train at least with our current Release 3.1.0!

Tom

On 08.01.18 22:53, Wayne Beaton wrote:
> I do not have any record of opt-in by any of the following projects:
> 
>   * Eclipse e(fx)clipse
>   * Eclipse Sphinx
>   * Eclipse Target Management
>   * Eclipse Communication Framework
>   * Eclipse XWT
>   * Eclipse PMF
>   * Eclipse Orion
>   * Eclipse Accessibility Tools Framework
> 
> If your project is included on this list in error, please accept my
> humble apologies and send me a note. If you have an interest in any of
> these projects being a part of the Photon Simultaneous Release, please
> engage with the corresponding project team.
> 
> I have been informed by the following projects that they do not intend
> to participate in the release. In some cases, this is a resourcing
> issue; if you feel strongly that one of these projects should be in the
> release and have the resources to make that happen, please contact me.
> 
>   * Eclipse EGerrit
>   * Eclipse Subversive SVN Team Provider
> 
> I'm working with some community members to get Eclipse Data Tools up to
> speed for this release. I'll make sure that we update this channel when
> information is available.
> 
> We're getting very close to the next milestone build. Fred and I are
> going to have to start the process of disabling the aggregation scripts
> for those projects that have not opted in very soon.
> 
> Strictly speaking, at this point project teams that have not already
> opted-in need to engage with their PMCs to petition the Eclipse Planning
> Council to approve an exception to participate. I will beg indulgence
> from the Planning Council to allow late comers to opt-in by the end of
> the week without working through the exception process.
> 
> Thanks,
> 
> Wayne
> 
> -- 
> Wayne Beaton
> Director of Open Source Projects
> 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

Re: [cross-project-issues-dev] Anyone else having failing hudson builds because mirroring problems of p2 repos?

[Tom Schindl]

It's been me (or better an old setting in my hudson config to use the
pack200 from jdk6)

Tom

On 31.05.17 00:53, Matthias Sohn wrote:
> On Tue, May 30, 2017 at 9:23 PM, Tom Schindl
> <tom.schi...@bestsolution.at <mailto:tom.schi...@bestsolution.at>> wrote:
> 
> Hi,
> 
> Our hudson builds started to fail since some days. They succeed locally
> without problems.
> 
> I already tried to restart our hipp instance but this didn't not help.
> Anyone has an idea how to debug what's going wrong?
> 
> Here an example build failure:
> https://hudson.eclipse.org/efxclipse/job/tmp-copy/2/consoleFull
> <https://hudson.eclipse.org/efxclipse/job/tmp-copy/2/consoleFull>
> 
> You see it looks like a the files downloaded are invalid. Do hudson
> builds go through a special proxy who provides invalid files?
> 
> 
> did you try to clean the Hudson workspace and rerun the build job ? 
> 
> 
> ___
> 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

Re: [cross-project-issues-dev] Anyone else having failing hudson builds because mirroring problems of p2 repos?

[Tom Schindl]

Hi,

Yes and I even created a complete new job (tmp-copy) to make sure it's
not a problem of the workspace in the job.

Tom

On 31.05.17 00:53, Matthias Sohn wrote:
> On Tue, May 30, 2017 at 9:23 PM, Tom Schindl
> <tom.schi...@bestsolution.at <mailto:tom.schi...@bestsolution.at>> wrote:
> 
> Hi,
> 
> Our hudson builds started to fail since some days. They succeed locally
> without problems.
> 
> I already tried to restart our hipp instance but this didn't not help.
> Anyone has an idea how to debug what's going wrong?
> 
> Here an example build failure:
> https://hudson.eclipse.org/efxclipse/job/tmp-copy/2/consoleFull
> <https://hudson.eclipse.org/efxclipse/job/tmp-copy/2/consoleFull>
> 
> You see it looks like a the files downloaded are invalid. Do hudson
> builds go through a special proxy who provides invalid files?
> 
> 
> did you try to clean the Hudson workspace and rerun the build job ? 
> 
> 
> ___
> 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

[cross-project-issues-dev] Anyone else having failing hudson builds because mirroring problems of p2 repos?

[Tom Schindl]

Hi,

Our hudson builds started to fail since some days. They succeed locally
without problems.

I already tried to restart our hipp instance but this didn't not help.
Anyone has an idea how to debug what's going wrong?

Here an example build failure:
https://hudson.eclipse.org/efxclipse/job/tmp-copy/2/consoleFull

You see it looks like a the files downloaded are invalid. Do hudson
builds go through a special proxy who provides invalid files?

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

Re: [cross-project-issues-dev] jdeps Results on M7 Repo

[Tom Schindl]

Hi Dani,

In 3.0 stream (not in your checked repo but we just contributed that on
Monday to SimRel) most of those are gone.

There's only one of those left
(org.eclipse.fx.ui.controls.vectorgraphics.PathUtils) where we don't
have any replacement in 9 to implement this feature.

Tom

On 24.05.17 16:59, Daniel Megert wrote:
> Here is a list of Eclipse projects that violate internal access rules
> regarding jdeps:
> 
> org.eclipse.actf.visualization.engines.lowvision
> org.eclipse.fx.ui.controls
> org.eclipse.fx.ui.panes
> org.eclipse.jubula.rc.javafx
> org.eclipse.wst.jsdt.core
> org.eclipse.wst.wsi
> 
> There are also violations in third party plug-ins. You can see the full
> report here:
> https://hudson.eclipse.org/releng/job/Generate_jdeps_report/8/artifact/jepsReport.txt
> 
> HTH
> Dani
> 
> 
> ___
> 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

Re: [cross-project-issues-dev] Hitting traivs rate limits

[Tom Schindl]

Hi,

e(fx)clipse is also using Travis the reason is that this is IMHO the
standard way for GitHub-Projects so it feels very natural to all
contributors.

Tom

On 29.03.17 19:48, Gorkem Ercan wrote:
> 
> What is the reason for not using JIPP instances for builds?
> Instead of Travis? We have moved our Travis to Eclipse JIPP when
> we moved eclipse.jdt.ls to foundation and it works pretty OK for us?
> 
> -- 
> Gorkem
> 
> On 29 Mar 2017, at 11:34, Jonah Graham wrote:
> 
>> At the moment my build has been waiting for quite a while to build (>
>> 1 hour)[1]
>>
>> As the 5 job limit means that if a repo has a matrix with 5 jobs, one
>> commit on that repo uses the whole limit. For example, at the moment
>> Eclipse OMR has 4 jobs running for a single commit[2]. (Not to pick on
>> omr, it just happens to be running right now, other projects as
>> expected also have build matrixes).
>>
>>>  Should we as Eclipse-projects-at-GitHub-community come up with some
>>> sort of recommendations? :)
>>
>> Yes. Any opening ideas?
>>
>> Jonah
>>
>>
>>
>> [1] https://travis-ci.org/eclipse/january/builds/216372647
>> [2] https://travis-ci.org/eclipse/omr/builds/216340391
>> ~~~
>> Jonah Graham
>> Kichwa Coders Ltd.
>> www.kichwacoders.com
>>
>>
>> On 29 March 2017 at 12:03, Oliver Kopp  wrote:
>>> Hi,
>>>
>>> 2017-03-29 9:37 GMT+02:00 Jonah Graham :
>>>
 I should be able to see all the eclipse builds that are currently
 running.
>>>
>>> This would be interesting.
>>>
>>> Maybe, my solution is to move away from Travis to CircleCI or some
>>> other CI provider even though I like travis. I am afraid of the
>>> introduced heterogeneity somehow. Should we as
>>> Eclipse-projects-at-GitHub-community come up with some sort of
>>> recommendations? :)
>>>
>>> Cheers,
>>>
>>> Oliver
>>> ___
>>> 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


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

Re: [cross-project-issues-dev] Java 9 Readiness

[Tom Schindl]

Hi,

Is there a chance that we get maven-tycho snapshots who use the java9
branch of jdt? This would help us to find problems when new code is
added who violates eg module-access rules.

Tom

On 13.03.17 21:06, Daniel Megert wrote:
> Hi Ed
> 
> It depends whether you want to run the tests from the command line or
> out of the IDE. From the command line you only need a Java 9 VM (e.g.
> the one installed on Hudson). From the IDE you need to install the Java
> 9 support as indicated in 'Running Eclipse with Java 9 Support (BETA)'.
> 
> Dani
> 
> 
> 
> From:Ed Willink 
> To:cross-project-issues-dev@eclipse.org
> Date:13.03.2017 20:40
> Subject:Re: [cross-project-issues-dev] Java 9 Readiness
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> 
> Hi
> 
> I'm confused again.
> 
> You previously replied that it was necessary to install a special JDT so
> that a Java 9 JDK was available within Eclipse. I see no mention of this
> in the wiki. Without doing this how can tests be run using Java 9?
> 
> Regards
> 
> Ed Willink
> 
> 
> On 13/03/2017 19:05, Daniel Megert wrote:
> I assume many of you already heard that Java 9 is _scheduled for GA on
> July 27, 2017_ . The Planning
> Council did not yet decided how we will ship the Java 9 support for
> Eclipse but requires all release train projects to assess their
> readiness regarding Java 9. We have created the following wiki page to
> capture this: _https://wiki.eclipse.org/Java_9_Readiness_. That wiki
> page also explains how you can check your project and how you can launch
> Eclipse with a Java 9 VM.
> 
> Dani
> 
> 
> 
> ___
> 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_
> 
> 
> 
> 
>  This email has been checked for
> viruses by Avast antivirus software. _
> __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://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

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

[Tom Schindl]

Well API-Tooling is correct! There is a method added to an interface who
was NOT marked @noimplement, so this is a source breaking change (binary
is ok!).

In general I think we should (re)instruct all our committers to think
twice before upgrading the major version of a bundle and get in touch
with their project leads, as breaking changes should only happen very
very rarely.

Tom

On 13.03.17 15:40, Brian de Alwis wrote:
> I don't understand why the API tooling recommended a major increment
> since there was no breaking change — they were all API additions.
> 
> Given that it's been in place for 10 days, my vote is to recover from
> the mistake and fix the version number.
> 
> Brian.
> 
> 
>> On 13-Mar-2017, at 6:07 AM, Simon Scholz <simon.sch...@vogella.com
>> <mailto:simon.sch...@vogella.com>> wrote:
>>
>> Hello,
>>
>> from my side I´ve just been following the checks of the API Base Line
>> tooling accroding to the changes in the generated code of the
>> MUiFactory class.
>> So at least we should add the noimplement flag to the MUiFactory to
>> avoid further major version increments due to the missing noimplement
>> flag.
>> But for now I think we should stick to the version increment to avoid
>> breaking clients who might have implemented MUiFactory, which anyways
>> is unlikely.
>>
>> Regards,
>>
>> Simon
>>
>> On Sat, Mar 11, 2017 at 6:09 PM, Ed Willink <e...@willink.me.uk
>> <mailto:e...@willink.me.uk>> wrote:
>>
>> Hi
>>
>> Chaotic major versions seem undesirable, so since the major
>> version has not yet made it to +4 on any milestone it seems
>> appropriate to revert it; preferably for M6, but certainly for M7.
>>
>> We aggregate to find inconsistencies. We found one, the platform
>> was wrong, the platform should correct, not everyone else.
>>
>> Note that if the platform fails to revert, downstream projects
>> that offer multi-release compatibility must forever remember to
>> specify an irregular 1.0.0,3.0.0 range for this plugin.
>>
>> Note also that if PDE requires a major version change it usually
>> means you should revise your code to avoid the major version, not
>> just throw a major version to make the irritating error go away.
>>
>> Note also again that major version chnages should be announced so
>> that consumers and experts have an opportunity to comment in a
>> more timely fashion.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 11/03/2017 16:52, Daniel Megert wrote:
>>> Thanks Tom!  That was my thinking too. So, that class should be
>>> marked as @noimplement in the model, because next time, PDE Tools
>>> will again ask the developer to increment the major version.
>>>
>>> Unfortunately, at this point, reverting the major version
>>> increase seems to do more harm than having a few bundles adjust
>>> their dependency. If someone disagrees, please let us know asap.
>>>
>>> Dani
>>>
>>>
>>>
>>> From:Tom Schindl <tom.schi...@bestsolution.at>
>>> <mailto:tom.schi...@bestsolution.at>
>>> To:Cross project issues
>>> <cross-project-issues-dev@eclipse.org>
>>> <mailto:cross-project-issues-dev@eclipse.org>
>>> Date:11.03.2017 17:35
>>> Subject:Re: [cross-project-issues-dev] Problems with
>>> Simrel contributionre: org.eclipse.e4.ui.model.workbench
>>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>>> <mailto:cross-project-issues-dev-boun...@eclipse.org>
>>> 
>>>
>>>
>>>
>>> Under NO cricumstance this API is/has/should be implemented by
>>> clients! IIRC it should be called at by none e4 internals. So
>>> this version increase is just plain wrong!
>>>
>>> Tom (guy who was in charge of the model)
>>>
>>> Von meinem iPhone gesendet
>>>
>>> Am 11.03.2017 um 16:22 schrieb Daniel Megert
>>> <_daniel_meg...@ch.ibm.com_ <mailto:daniel_meg...@ch.ibm.com>>:
>>>
>>> You're right Ed. At least in the SDK there's no re-export of that
>>> bundle.
>>>
>>> Dani
>>>
>>>
>>>
>>> From:Ed Willink <

Re: [cross-project-issues-dev] Problems with Simrel contribution re: org.eclipse.e4.ui.model.workbench

[Tom Schindl]

Under NO cricumstance this API is/has/should be implemented by clients! IIRC it 
should be called at by none e4 internals. So this version increase is just 
plain wrong!

Tom (guy who was in charge of the model)

Von meinem iPhone gesendet

> Am 11.03.2017 um 16:22 schrieb Daniel Megert :
> 
> You're right Ed. At least in the SDK there's no re-export of that bundle.
> 
> Dani
> 
> 
> 
> From:Ed Willink 
> To:cross-project-issues-dev@eclipse.org
> Date:11.03.2017 11:01
> Subject:Re: [cross-project-issues-dev] Problems with Simrel 
> contribution
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> Hi
> 
> Correction. I misread the icons in the Plugin dependency view. Nothing 
> in my workspace re-exports org.eclipse.e4.ui.model.workbench, so a major 
> version change should be a simple MANIFEST.MF update for consumers.
> 
> Regards
> 
> Ed Willink
> 
> On 11/03/2017 08:58, Ed Willink wrote:
> > Hi
> >
> > On the one hand, this looks like the normal excitement that occurs 
> > when a plugin has a major version increase; every consumer must follow 
> > suit on its dependency bounds. However it is surprising that no 
> > announcement has been made, particularly so close to M6.
> >
> > On the other hand, there are many plugins that re-export 
> > org.eclipse.e4.ui.model.workbench and so they too must also incur a 
> > major version increment. org.eclipse.ui.ide is one of them and I doubt 
> > we want a major version increment there.
> >
> > Presumably a typo then. I suggest nobody apart from the platform team 
> > reacts.
> >
> > Regards
> >
> > Ed Willink
> >
> > On 11/03/2017 08:19, Eike Stepper wrote:
> >> Hi,
> >>
> >> It appears that https://git.eclipse.org/r/#/c/88492/incremented the 
> >> major version of the org.eclipse.e4.ui.model.workbench plugin. There 
> >> are some other commits in the context of 
> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=484398but none of them 
> >> seems to justify a major version increment. Maybe I overlooked 
> >> something historic that justifies it. Is it justifiable that the 
> >> major version of this plugin was incremented, and if so, what is the 
> >> justification?
> >>
> >> At this point it looks as if clients just need to increment their 
> >> upper bound.
> >>
> >> Cheers
> >> /Eike
> >>
> >> 
> >> http://www.esc-net.de
> >> http://thegordian.blogspot.com
> >> http://twitter.com/eikestepper
> >>
> >>
> >>
> >> Am 11.03.2017 um 03:24 schrieb Evgeny Mandrikov:
> >>> Hello,
> >>>
> >>> I'm forwarding the following thread of discussion since seems that 
> >>> previous messages were not delivered to the list - "being held until 
> >>> the list moderator can review it for approval. The reason it is 
> >>> being held: Too many recipients to the message"
> >>>
> >>> And an update on subject:
> >>> EclEmma has been re-enabled to unblock work of Andreas Sewe on 
> >>> https://git.eclipse.org/r/#/c/84521/
> >>> Papyrus really seems to be a cause of a problem, because after 
> >>> re-enablement all builds are still green.
> >>>
> >>> Regards,
> >>> Evgeny
> >>>
> >>> -- Forwarded message -
> >>> From: Evgeny Mandrikov  >>> >
> >>> Date: Fri, Mar 10, 2017 at 1:46 PM
> >>> Subject: Re: Problems with Simrel contribution
> >>> To: Grégoire DUPE  >>> >, Sravan K Lakkimsetti 
> >>> >, 
> >>> jfalterme...@eclipsesource.com 
> >>>  
> >>>  >>> >, emuel...@eclipsesource.com 
> >>>   >>> >, step...@esc-net.de 
> >>>   >>> >, cedric.b...@obeo.fr 
> >>>   >>> >, laurent.gou...@obeo.fr 
> >>>   >>> >, lorenzo.bett...@gmail.com 
> >>>   >>> >, vincenzo.case...@rcp-vision.com 
> >>>  
> >>>  >>> >, 
> >>> francesco.guidi...@gmail.com  
> >>>  >>> >, francois.le-fe...@cea.fr 
> >>>   >>> >, quentin.leme...@cea.fr 
> >>>   >>> >, 

[cross-project-issues-dev] https://repo.eclipse.org/ is dead

[Tom Schindl]

Hi,

My build gets a "Connection to https://repo.eclipse.org refused" when
trying to access "https://repo.eclipse.org/content/groups/cbi/;, ...

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

Re: [cross-project-issues-dev] Upgrading HIPPs to SLES12 (Part 2 - reloaded)

[Tom Schindl]

Any idea when the e(fx)clipse one is up again? It's now offline for > 3
days and I really want to run nightlies ASAP.

Tom

On 22.10.16 02:12, Frederic Gurr wrote:
> Hi,
> 
> I've managed to get the following HIPPs back online (with a temporary
> workaround):
> * andmore
> * ecf
> * egit
> * gyrex
> * hudson
> * swtbot
> 
> Regards,
> 
> Fred
> 
> 
> On 22.10.2016 00:09, Frederic Gurr wrote:
>> Hi,
>>
>> Unfortunately we're experiencing some problems after upgrading hipp1 to
>> SLES12. Therefore the HIPPs mentioned below can currently not be
>> reached. We will try to bring them back online as soon as possible.
>>
>> Sorry for the inconvenience.
>>
>> Regards,
>>
>> Fred
>>
>> On 19.10.2016 18:06, Frederic Gurr wrote:
>>> Hi,
>>>
>>> After a hiatus, we will start again to upgrade HIPPs to SLES12.
>>>
>>> Next up are the following HIPPs:
>>>
>>> * andmore
>>> * ecf
>>> * eclipsescada
>>> * efxclipse
>>> * egit
>>> * gyrex
>>> * hudson
>>> * linuxtools
>>> * orion
>>> * osee
>>> * recommenders
>>> * sapphire
>>> * swtbot
>>>
>>> The upgrade is scheduled for this Friday, October 21st, 10am EDT.
>>>
>>> Downtime will be a few hours.
>>>
>>>
>>> Please let me know if you have any concerns.
>>>
>>> Regards,
>>>
>>> Fred
>>>
>>>
>>> P.S.: Upcoming HIPP upgrades: November 8th and November 10th
>>> ___
>>> 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
> 


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

Re: [cross-project-issues-dev] How to provide HDPI icons in yourplug-in

[Tom Schindl]

Font icons are only useable in a flat design because you only have a solid 
background

Tom

Von meinem iPhone gesendet

> Am 21.09.2016 um 20:58 schrieb Antoine THOMAS :
> 
> Thanks Camille.
> 
> Simple question: how text (font) is rendered in Eclipse? I guess the text is 
> not rendered as bitmap? So if we use a font icon set, like Font Awesome, it 
> should work and be light.
> 
> 
> 
> __
> Antoine THOMAS aka ttoine
> Product Manager
> Eclipse Foundation
> antoine.tho...@eclipse.org
> +33663137906
> @ttoine
> 
>> On 21 September 2016 at 20:43, Camille Letavernier 
>>  wrote:
>> Hi,
>> 
>> Papyrus provides support for SVG (via Batik), but this is not the main 
>> approach, and it scales poorly. Most of the rendering is done with Draw2d 
>> and a custom CSS interpreter based on E4 CSS. A few SVG images are used on 
>> top of this.
>> 
>> We never managed to get satisfying SVG rendering, with issues in both 
>> performances and end result (some SVG images can't be rendered, or are 
>> incorrectly rendered)
>> 
>> So, not so much to learn from here I'm afraid (at least nothing too positive 
>> :) )
>> 
>> Camille
>> 
>> 
>> Le 21 sept. 2016 20:02, "Andrey Loskutov"  a écrit :
>>> Yes, this is the key. Version control SVG files, generate icons on build 
>>> and deploy generated stuff.
>>> 
 Am 21.09.2016 um 19:58 schrieb Torkild Ulvøy Resheim:
 Agreed, I’m also -1000 on rendering SVG icons on the fly. I’ve actually 
 tried something like this, with some simple icons rendered in Graphiti 
 using Batik. It was just way too slow. So we ended up writing some code 
 that rendered the icons as PNG during the build process.
 
 I’m not saying it cannot be done. But then I think we need something way 
 more powerful than Batik. Also I think some serious work on icon handling 
 is required. Adding support for @2x icons took quite a bit of effort. Is 
 it really worth it?
 
 Best regards,
 Torkild
> 21. sep. 2016 kl. 18.41 skrev Daniel Megert :
> 
> Since existing startup time *is* already a user concern, I'm -1000 for 
> this,
> 
> Dani
> 
> 
> 
> From:Stefan Xenos 
> To:Cross project issues 
> Date:21.09.2016 18:26
> Subject:Re: [cross-project-issues-dev] How to provide HDPI icons 
> in yourplug-in
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> What if we bundled SVG files with Eclipse, then on first startup with a 
> given resolution we lazily render them to PNGs with the appropriate 
> detail. When Eclipse launches, it would use the .PNGs from the cache.
> 
> It could take a really long time for the first launch, but subsequent 
> restarts should be fairly quick since it would just be loading .PNGs from 
> then on.
> 
>   - Stefan
> 
> On Wed, Sep 21, 2016 at 9:15 AM Mickael Istria  wrote:
> On 09/21/2016 06:09 PM, Antoine THOMAS wrote:
> Other questions:
> - Why render svg files in bitmap?
> - Why not use svg icons in platform? This way the icons are always 
> beautiful, no matter the resolution of the screen
> it would mean that the IDE would have to "render" SVG to bitmaps at 
> runtime (whereas we currently do it at dev-time). Given the number of 
> icons in Eclipse IDE, there are risks that this consume a lot of CPU (in 
> the UI Thread moreover...) and creates lags.
> But it's just a guess, I'm not aware of any actual experiment of 
> theorical metrics about the impact of displaying SVGs in Eclipse.
> 
> --
> Mickael Istria
> Eclipse developer for Red Hat Developers
> My blog - My Tweets
> ___
> 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 

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

[Tom Schindl]

Hi Alexander,

I've enabled the e(fx)clipse runtime contribution from Neon.0. The
tooling contribution stays disabled until WTP is enabled as we use their
XML-Editors.

Tom

On 09.08.16 15:38, Alexander Nyßen wrote:
> 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 > >:
>>
>> 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 
>>>  on
>>> behalf of Ed Willink 
>>> *Sent:* Tuesday, August 9, 2016 3:20:07 PM
>>> *To:* 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 highlighted.
>>>
>>> AFAIAA all OCL's dependencies have declared intent so OCL can be
>>> enabled and that is what I have done.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 09/08/2016 13:09, Kaloyan Raev wrote:
 Hi folks,

 I don't want to break the party, but your recent changes, pushed
 directly to master, broke the validation build. Thus, everyone else
 who follow the clean process of contributing via Gerrit is blocked
 at the moment.

 I am going to revert the last changes one by one until I get a clean
 validation build.

 Please contribute your next changes via Gerrit.

 Thanks,
 Kaloyan
 
 *From:* cross-project-issues-dev-boun...@eclipse.org 
  on
 behalf of Ed Willink 
 *Sent:* Monday, August 8, 2016 8:39:57 PM
 *To:* cross-project-issues-dev@eclipse.org
 *Subject:* Re: [cross-project-issues-dev] GEF Oxygen M1 contribution
 only partially today
  
 Hi
 XText has declared intent. XText releases asynchronously, so it is
 very likely that Xtext 2.10 crosses the boundary.
 It seems unhelpful that you have inhibited aggregation contributions
 just because the XText releng has not realized how much trouble your
 enabled=false is causing.
 I'll enable OCL so that things improve as soon as XText and friends
 appear.
 Regards
 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 

[cross-project-issues-dev] e(fx)clipse will participate in Oxygen

[Tom Schindl]

Hi,

e(fx)clipse will participate in Oxygen:
- Runtime at offset +1
- Tooling at offset +3

I'll create the release records later this week.

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

[cross-project-issues-dev] e(fx)clipse in Neon

[Tom Schindl]

Hi,

The project plan https://projects.eclipse.org/releases/neon mentions
e(fx)clipse 3.0.0 but we'll only contribute 2.4.0.

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

Re: [cross-project-issues-dev] access to lib/ext

[Tom Schindl]

Oh and there's 

C) a equinox specific Manifest header need to look that up but if you query for 
it there should be a thread on equinox dev where Tom Watson mention the header 
name

In your case c is the best option

Tom

Von meinem iPhone gesendet

> Am 03.03.2016 um 19:31 schrieb Tom Schindl <tom.schi...@bestsolution.at>:
> 
> Equinox by default skips the extension classloader when build your bundle 
> classloader.
> 
> You have 2 options:
> A) instruct equinox to delegate to the ext loader which can only be done via 
> commadline params => not an option for an IDE plugin
> B) ship an adaptor hook => this way eg efxclipse provides access to javafx 
> who is also on the ext classpath
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
>> Am 03.03.2016 um 19:18 schrieb Gorkem Ercan <gorkem.er...@gmail.com>:
>> 
>> 
>> Hi,
>> On JSDT project we are trying to utilize nashorn as runtime for javascript 
>> based tool.
>> Nashorn is part of JDK8 and is shipped as nashorn.jar on lib/ext folder of 
>> jdk.
>> 
>> At the moment, it looks like Eclipse does not have access to the jar files 
>> on the lib/ext folder
>> of the JDK. Is this by design? Is there a way for a bundle to get Eclipse 
>> runtime give access to
>> lib/ext jars?
>> 
>> Thanks,
>> —
>> Gorkem
>> ___
>> 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

Re: [cross-project-issues-dev] access to lib/ext

[Tom Schindl]

Equinox by default skips the extension classloader when build your bundle 
classloader.

You have 2 options:
A) instruct equinox to delegate to the ext loader which can only be done via 
commadline params => not an option for an IDE plugin
B) ship an adaptor hook => this way eg efxclipse provides access to javafx who 
is also on the ext classpath

Tom

Von meinem iPhone gesendet

> Am 03.03.2016 um 19:18 schrieb Gorkem Ercan :
> 
> 
> Hi,
> On JSDT project we are trying to utilize nashorn as runtime for javascript 
> based tool.
> Nashorn is part of JDK8 and is shipped as nashorn.jar on lib/ext folder of 
> jdk.
> 
> At the moment, it looks like Eclipse does not have access to the jar files on 
> the lib/ext folder
> of the JDK. Is this by design? Is there a way for a bundle to get Eclipse 
> runtime give access to
> lib/ext jars?
> 
> Thanks,
> —
> Gorkem
> ___
> 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] Anybody else having trouble with the signing service?

[Tom Schindl]

Hi,

Our efxclipse builds have started failing with

> Caused by: org.apache.http.conn.HttpHostConnectException: Connect to 
> build.eclipse.org:31338 [build.eclipse.org/172.25.25.57] failed: Connection 
> refused

since friday, Anybody else experiencing this?

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

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

[Tom Schindl]

Hi Wayne,

Thanks for running jdeps I've fixed most of the none public API useages
and we are working with the OpenJFX-Team to make the other necessary
APIs public in Java9 as well and will reside to reflection to switch
between Java8 and Java9 APIs.

The biggest problem although is the JavaFX-SWT-Bridge which is going to
be a nightmare. I'm not sure we as the e(fx)clipse team have the
resources to fix the problems like we did it for all of you in Java8
where you don't have to worry about all the mess.

For those not familiar with it: FXCanvas allows to embed JavaFX into an
SWT application (similar to the SWT_AWT-Bridge). It is shipped as part
of the JRE/JDK but is *NOT* on the classpath because FXCanvas itself is
a subclass of SWT-Canvas.

In Java7/8 e(fx)clipse simply creates an URLClassLoader who has the
SWT-Bundleclassloader as its parent and making FXCanvas available to you
through AdapterHooks.

Now in a Java9 world we have the situation that we have a Java9-Module
who has a dependency on SWT which runs in the unnamed module.

I've created a bug [1] but as of today I'm clueless how to address this
chicken and egg problem and as said above I currently don't have cycles
to look into this in my spare time.

I've talked to the OpenJFX-Team at JavaOne and they see the problem with
FXCanvas (in an OSGi-Env) and want things to work as smooth in Java9 as
it does in Java7/8 but require my help.

What worries me is that we have to work with Oracle on the API but
without having the time to investigate the whole situation we are lost
and time is ticking.

Anyone relying on FXCanvas should be worried as well. If FXCanvas is not
available in Java9 e(fx)clipse will loose some of its advanced features
(like automatic preview of FXML-Files, Gradient-Dialogs) which is bad
but does not break our neck but other projects might be useless without
it (GEF4 if not mistaken!).

As our runtime does not require SWT at all the missing FXCanvas is not a
problem for the area BestSolution is putting its resources on.

Tom

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428

On 16.11.15 22:24, Wayne Beaton wrote:
> Greetings folks!
> 
> I just posted a blog entry [0] regarding my initial experiences using
> JDK 9 Early Access with Project Jigsaw [1] with Neon.
> 
> By way of background, Jigsaw is the project that's bringing modularity
> to Java. The modularity implementation imposes restrictions on
> visibility that have a direct impact on code that uses internal code. In
> the past you may have had to deal with severe scolding over the use of
> internal packages, but with the current EA bits, this sort of use
> results in runtime exceptions.
> 
> The download comes with a handy tool named jdeps that--among other handy
> services--will scan Java code for soon-to-be illegal access of JDK
> internals.
> 
> The good news is that both the Mars and Neon repositories show that we
> have very few violations in Eclipse project code.
> 
> The very good news is that the Neon M2 and M3 builds both seems to run
> just fine on the current JDK 9 + Jigsaw builds. Unless you use the
> SWT_AWT bridge, that is... Unfortunately, jdeps only noticed a problem
> that I think shouldn't really a problem, but in the process of
> investigating, I noticed that SWT_AWT does a Class.forName(...) lookup
> that results in what the Jigsaw team will regard as a legitimate violation.
> 
> My initial investigations suggest that e(fx)clipse and Scout are taking
> the biggest hit. I don't know enough about JavaFX to make a particuarly
> intelligent assessment, but it looks to me like what should be the
> entire public API is showing up as inaccessible. Riena gets an
> honourable mention with one test case that uses an internal API. I've
> attached the reports generated from the Mars and Neon repositories.
> 
> 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 
> 
> 
> ___
> 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, 

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

[Tom Schindl]

>From the j1 session(s) - I attended I can not share this! They've been
talking about making modules out of libraries jars.

Jars on the classpath get automatically wrapped into 1 virtual module at
runtime. My understanding was that all you need to to do is to call a
command line app to make a module from a jar (which although
autogenerates the module-info.java).

There are chances although that I completely screwed this up. There's
been a ton of informations on all this stuff and without at least having
had a hands on it's really easy to mix things up.

Tom

On 27.10.15 19:35, Jayaprakash Arthanareeswaran wrote:
> My understanding (from JEP 220) is that these run-time images are
> created specifically for the JDK/JRE and the IDE is only expected to
> read these.
> User defined modules will either be in source form or JAR form. One of
> the goals of the JEP 220 is this:
> 
> "Restructure the JDK and JRE run-time images to draw a clear distinction
> between files that developers, deployers, and end-users can rely upon
> and, when appropriate, modify, in contrast to files that are internal to
> the implementation and subject to change without notice. "
> 
> The way I see it, a Jimage is purely meant to be part of a JDK and
> nowhere else.
> 
> Regards,
> Jay
> 
> Inactive hide details for Mike Milinkovich ---10/28/2015 02:49:43
> AM---On 27/10/2015 5:18 PM, Daniel Megert wrote: > > "InsteadMike
> Milinkovich ---10/28/2015 02:49:43 AM---On 27/10/2015 5:18 PM, Daniel
> Megert wrote: > > "Instead, API is provided for reading the content of
> 
> From: Mike Milinkovich 
> To: Daniel Megert , Cross project issues
> 
> Date: 10/28/2015 02:49 AM
> Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for
> Eclipse Neon
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> 
> 
> On 27/10/2015 5:18 PM, Daniel Megert wrote:
> 
> > "Instead, API is provided for reading the content of such image." 
> 
> ==> The format is not specified but APIs allow to read the content.
> 
> 
> Maybe I am wrong, but since we are a Java IDE don't we also have to
> *write* the content of such files?
> 
> -- 
> Mike Milinkovich_
> __mike.milinkovich@eclipse.org_ 
> +1.613.220.3223 (mobile)
> _
> _EclipseCon Europe 2015
> ___
> 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

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

[Tom Schindl]

On 21.08.15 18:41, David M Williams wrote:
 I do not in principle have any objection, but think you should detail a
 little more about what's new, that caused the minor increase.

The problem is that e(fx)clipse has a dual life. We have a runtime and a
tooling part and the runtime part. We are only contributing the tooling
part and a very small tiny bit (in fact 2 bundles of the runtime) to the
Simultaneous release.

 
 Just a few new API? That are fully backwards compatible? Or some wildly
 new features? Did a lot of your bundles/packages increase their minor
 version? Or just a few? Or, were new bundles simply added?

We introduced a new Xtext DSL in 2.1 so we have 2 new bundles at get
shipped and the only project at Eclipse I know of using having a
dependency on e(fx)clipse is GEF4.

 
 Also, I think knowing just how much of a leaf this is would help. Is
 there any projects in Simultaneous release repo that make use of it? If
 so, I think it would be helpful to know, in parallel, if that version
 currently aggregates ok. You can determine this either directly in b3
 aggregator editor (via validation) or use a Gerrit job to validate,
 without checking in the contribution yet. To explain, the risk in cases
 like this, even when new API is backwards compatible, is if someone was
 using something internal and had a narrow range specification, such as
 [2.0.0, 2.1.0) since if they did, those projects or adopters would then
 have to change their code ... at least the version range.

The only internal dependency eclipse dependency I know of is GEF4. I'll
push a gerrit review to see if things aggregate OK and post the
gerrit-review and wait for feedback before mergeing.

 
 Also, has this been announced on your 'dev list'? Are the changes
 something requested by adopters? Any bug numbers that explain the
 minor increase?

One of the external parties who has requested an update [1] is the
Spring Tool Suite.

 
 I am asking these questions, partially, to make it clear that while we
 want rapid improvements we don't want to foster a wild west culture
 where projects do what they want, even if harmful to others.  I
 suspect in your case there's nothing (or, little risk) of doing anything
 harmful, but answers to the questions above would help all of us be able
 to assess that better.
 

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.

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=472045


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

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

[Tom Schindl]

On 24.08.15 11:35, Alexander Nyßen wrote:
 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.
 
 importfeature=org.eclipse.fx.runtime.min.featureversion=2.0.0match=greaterOrEqual“/
 
 Of course we will still have to test compatibility though...

To only change [1] for the min feature was that we now expose
netscape.javascript which is needed for people interfacing with
WebView and JavaScript.

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=472045

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

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

[Tom Schindl]

Hi David,

I've pushed now the changes to [1] but the verfication job is failing
[2]. I'm quite sure that it's not me who makes it fail right?

---
...
getModelFromGit:
04:53:37   [echo] execute git checkout
83a6dcdb181eaebe429ae3ca51aa87e2a4457467 in
/home/hudson/genie.simrel/.hudson/jobs/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build
04:53:38   [exec] fatal: reference is not a tree:
83a6dcdb181eaebe429ae3ca51aa87e2a4457467
04:53:38
04:53:38  BUILD FAILED
04:53:38
/jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:395:
The following error occurred while executing this line:
04:53:38
/jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:359:
exec returned: 128
04:53:38
04:53:38  Total time: 7 seconds
04:53:38  Email was triggered for: Failure
04:53:38  Email was triggered for: Still Failing
04:53:38  Trigger Failure was overridden by another trigger and will not
send an email.
04:53:38  Sending email for trigger: Still Failing
04:53:38  Sending email to: david_willi...@us.ibm.com
04:53:40  Finished: FAILURE
---


[1]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

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

[Tom Schindl]

Hi,

I ran the validation locally and it succeeded, so I'm quite sure its not
my commit who makes it fail. So I think GEF4 is OK with upgrading our
version to 2.1.

Tom

On 24.08.15 10:58, Tom Schindl wrote:
 Hi David,
 
 I've pushed now the changes to [1] but the verfication job is failing
 [2]. I'm quite sure that it's not me who makes it fail right?
 
 ---
 ...
 getModelFromGit:
 04:53:37   [echo] execute git checkout
 83a6dcdb181eaebe429ae3ca51aa87e2a4457467 in
 /home/hudson/genie.simrel/.hudson/jobs/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build
 04:53:38   [exec] fatal: reference is not a tree:
 83a6dcdb181eaebe429ae3ca51aa87e2a4457467
 04:53:38
 04:53:38  BUILD FAILED
 04:53:38
 /jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:395:
 The following error occurred while executing this line:
 04:53:38
 /jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:359:
 exec returned: 128
 04:53:38
 04:53:38  Total time: 7 seconds
 04:53:38  Email was triggered for: Failure
 04:53:38  Email was triggered for: Still Failing
 04:53:38  Trigger Failure was overridden by another trigger and will not
 send an email.
 04:53:38  Sending email for trigger: Still Failing
 04:53:38  Sending email to: david_willi...@us.ibm.com
 04:53:40  Finished: FAILURE
 ---
 
 
 [1]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

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

[Tom Schindl]

Hi David,

I'm unable to merge https://git.eclipse.org/r/#/c/54379/2 not sure
what's going on there.

Tom

On 24.08.15 14:29, David M Williams wrote:
 Yes, that is not you making it fail. That's me fixing it. (I would
 open a bug, since still not sure it's fixed ... but, bugzilla seems
 down, at the moment).
 
 More to the point, I appreciate your care, in both checking and
 documenting the issues, and all sounds well, to me.
 
 Thanks again,
 
 
 
 
 From:Tom Schindl tom.schi...@bestsolution.at
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:08/24/2015 04:57 AM
 Subject:[cross-project-issues-dev] e(fx)clipse 2.1.0 for Mars.1
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 Hi David,
 
 I've pushed now the changes to [1] but the verfication job is failing
 [2]. I'm quite sure that it's not me who makes it fail right?
 
 ---
 ...
 getModelFromGit:
 04:53:37   [echo] execute git checkout
 83a6dcdb181eaebe429ae3ca51aa87e2a4457467 in
 /home/hudson/genie.simrel/.hudson/jobs/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build
 04:53:38   [exec] fatal: reference is not a tree:
 83a6dcdb181eaebe429ae3ca51aa87e2a4457467
 04:53:38
 04:53:38  BUILD FAILED
 04:53:38
 /jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:395:
 The following error occurred while executing this line:
 04:53:38
 /jobs/genie.simrel/simrel.neon.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.tools/build.xml:359:
 exec returned: 128
 04:53:38
 04:53:38  Total time: 7 seconds
 04:53:38  Email was triggered for: Failure
 04:53:38  Email was triggered for: Still Failing
 04:53:38  Trigger Failure was overridden by another trigger and will not
 send an email.
 04:53:38  Sending email for trigger: Still Failing
 04:53:38  Sending email to: david_willi...@us.ibm.com
 04:53:40  Finished: FAILURE
 ---
 
 
 [1]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
 
 
 
 
 
 ___
 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

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

[Tom Schindl]

Hi,

On 25.08.15 00:54, David M Williams wrote:
 I don't know what's wrong either ... but, have opened bug 475748 for the
 Gerrit build problems.
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=475748
 
 In the mean time, it seemed you committed that for 'master' (not
 Mars_maintenance) but I went ahead and submitted to master, which
 should cause the old fashioned build to run ... and if it breaks we can
 do an old fashioned revert.

Thanks for catching this. It looks like i had selected the wrong
Gerrit-Branch.

I've pushed another gerrit review [1] with the changes currently already
in master (which also adds e(fx)clipse to a category!).

Tom

[1]https://git.eclipse.org/r/#/c/54440/

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

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

[Tom Schindl]

[...]

 For maintenance, we do not have another place to put RC candidates, but
 will wait until official release to move to ../releases/mars. In the
 mean time, please test directly from .../releases/maintenance.

Because I did not have any feedback from my PMC I did not contribute the
2.1.0 version of e(fx)clipse to the maintenance release.

Is it still possible to contribute to 2.1.0 for RC2. The release has
been scheduled by Wayne now for Sep. 2nd.

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

[cross-project-issues-dev] What are the rules for Mars SR1 contributions

[Tom Schindl]

Hi,

Are there any rules regarding what version a project can contribute to SR1.

In SR0 e(fx)clipse contributed 2.0.0 and now we'd like to contribute
2.1.0 to SR1. Is this allowed?

Another thing I'd like to change for SR1 is that in SR0 e(fx)clipse
missed to define a category so we are *not* showing up in the default
tree mode. Is this allowed?

Tom Schindl

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

Re: [cross-project-issues-dev] What are the rules for Mars.1 [nee Mars SR1] contributions

[Tom Schindl]

Hi,

On 13.08.15 14:43, David M Williams wrote:
 Yes, and Yes.
 
 As long as nothing breaks.
 
 And, as soon as you learn to call it Mars.1 :)
 
 2.1 sounds like a minor release, so that's fine. (Nothing should break
 in a minor release  though does need a release review, as far as I
 know).  
 
 I think adding things to a category should work ok, so, give it a try
 ... soon! (please)

Ok I pushed https://git.eclipse.org/r/#/c/53733/ let's see if the build
succeeds.

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

[cross-project-issues-dev] e(fx)clipse would like to recontribute to RC4

[Tom Schindl]

Hi,

Sorry but it looks like I've forgot to push our RC4 build to the
aggregator!

Is it still possible to contribute? There are 2 important bug fixes in
the build:
* platform:.plugin.org.eclipse.pde.ui.icons.etool16.newpprj_wiz.gif not
  available any = use .png
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469024


* Stackoverflow when doing autocomplete for visibility
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469708

Both of them are highly visible to users (the 1. already if e(fx)clipse
is only installed and one opens the New Project Wizard!)

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

Re: [cross-project-issues-dev] e(fx)clipse would like to recontribute to RC4

[Tom Schindl]

Hi David,

I've pushed https://git.eclipse.org/r/#/c/50044/ but the validator is
failing! I have no idea why!

Tom

On 11.06.15 19:28, David M Williams wrote:
 Tim,
 
 Ordinarily I would say no, it is too late (and encourage you to make
 fixes available from your own update site) ... but, since we are
 rebuilding for WindowBuilder anyway ... I think it would safe enough.
 
 Let me know once you are ready (or, if you change b3aggrcon file, I will
 see that).
 
 Thanks,
 
 
 
 
 From:Tom Schindl tom.schi...@bestsolution.at
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 10:52 AM
 Subject:[cross-project-issues-dev] e(fx)clipse would like to
 recontributeto RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 Hi,
 
 Sorry but it looks like I've forgot to push our RC4 build to the
 aggregator!
 
 Is it still possible to contribute? There are 2 important bug fixes in
 the build:
 * platform:.plugin.org.eclipse.pde.ui.icons.etool16.newpprj_wiz.gif not
  available any = use .png
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469024
 
 
 * Stackoverflow when doing autocomplete for visibility
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469708
 
 Both of them are highly visible to users (the 1. already if e(fx)clipse
 is only installed and one opens the New Project Wizard!)
 
 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
 
 
 
 
 ___
 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

Re: [cross-project-issues-dev] e(fx)clipse would like to recontribute to RC4

[Tom Schindl]

Should I merge in the change, in any case?

Tom

On 11.06.15 19:30, Tom Schindl wrote:
 Hi David,
 
 I've pushed https://git.eclipse.org/r/#/c/50044/ but the validator is
 failing! I have no idea why!
 
 Tom
 
 On 11.06.15 19:28, David M Williams wrote:
 Tim,

 Ordinarily I would say no, it is too late (and encourage you to make
 fixes available from your own update site) ... but, since we are
 rebuilding for WindowBuilder anyway ... I think it would safe enough.

 Let me know once you are ready (or, if you change b3aggrcon file, I will
 see that).

 Thanks,




 From:Tom Schindl tom.schi...@bestsolution.at
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 10:52 AM
 Subject:[cross-project-issues-dev] e(fx)clipse would like to
 recontributeto RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 



 Hi,

 Sorry but it looks like I've forgot to push our RC4 build to the
 aggregator!

 Is it still possible to contribute? There are 2 important bug fixes in
 the build:
 * platform:.plugin.org.eclipse.pde.ui.icons.etool16.newpprj_wiz.gif not
  available any = use .png
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469024


 * Stackoverflow when doing autocomplete for visibility
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469708

 Both of them are highly visible to users (the 1. already if e(fx)clipse
 is only installed and one opens the New Project Wizard!)

 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




 ___
 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

Re: [cross-project-issues-dev] e(fx)clipse would like to recontribute to RC4

[Tom Schindl]

Hi,

Yes - Previously it was in no category and so it didn't show up unless
one unchecked the grouping - so would not be found by anyone.

Tom

On 11.06.15 19:42, David M Williams wrote:
 Not yet. It appears you changed which features are in which categories?
 
   The opposite features 'categories' of
 'org.eclipse.b3.aggregator.impl.FeatureImpl@6eaecd51{file:/home/hudson/genie.simrel/.hudson/jobs/simrel.mars.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build/efxclipse.b3aggrcon#//@repositories.1/@features.0}'
 and 'features' of
 'org.eclipse.b3.aggregator.impl.CustomCategoryImpl@487c9b46{file:/home/hudson/genie.simrel/.hudson/jobs/simrel.mars.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build/simrel.b3aggr#//@customCategories[identifier='General%20Purpose%20Tools']}'
 do not refer to each other
 
 
 
 
 
 From:Tom Schindl tom.schi...@bestsolution.at
 To:cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 01:39 PM
 Subject:Re: [cross-project-issues-dev] e(fx)clipse would like to
 recontribute to RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 Should I merge in the change, in any case?
 
 Tom
 
 On 11.06.15 19:30, Tom Schindl wrote:
 Hi David,

 I've pushed https://git.eclipse.org/r/#/c/50044/but the validator is
 failing! I have no idea why!

 Tom

 On 11.06.15 19:28, David M Williams wrote:
 Tim,

 Ordinarily I would say no, it is too late (and encourage you to make
 fixes available from your own update site) ... but, since we are
 rebuilding for WindowBuilder anyway ... I think it would safe enough.

 Let me know once you are ready (or, if you change b3aggrcon file, I will
 see that).

 Thanks,




 From:Tom Schindl tom.schi...@bestsolution.at
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 10:52 AM
 Subject:[cross-project-issues-dev] e(fx)clipse would like to
 recontributeto RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 



 Hi,

 Sorry but it looks like I've forgot to push our RC4 build to the
 aggregator!

 Is it still possible to contribute? There are 2 important bug fixes in
 the build:
 * platform:.plugin.org.eclipse.pde.ui.icons.etool16.newpprj_wiz.gif not
  available any = use .png
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469024


 * Stackoverflow when doing autocomplete for visibility
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469708

 Both of them are highly visible to users (the 1. already if e(fx)clipse
 is only installed and one opens the New Project Wizard!)

 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




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

Re: [cross-project-issues-dev] e(fx)clipse would like to recontribute to RC4

[Tom Schindl]

I pushed a new changeset without the category changes.

Tom

On 11.06.15 19:53, David M Williams wrote:
 Please revert that part (if not obvious). That was not one of the bugs
 you listed ... and, not the right time to be making that sort of change.
 Next time (perhaps even for SR1) I suggest you test earlier, and propose
 such change in a cross-project bug.
 
 Thanks,
 
 
 
 From:Tom Schindl tom.schi...@bestsolution.at
 To:cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 01:45 PM
 Subject:Re: [cross-project-issues-dev] e(fx)clipse would like to
 recontribute to RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 Hi,
 
 Yes - Previously it was in no category and so it didn't show up unless
 one unchecked the grouping - so would not be found by anyone.
 
 Tom
 
 On 11.06.15 19:42, David M Williams wrote:
 Not yet. It appears you changed which features are in which categories?

   The opposite features 'categories' of

 'org.eclipse.b3.aggregator.impl.FeatureImpl@6eaecd51{file:/home/hudson/genie.simrel/.hudson/jobs/simrel.mars.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build/efxclipse.b3aggrcon#//@repositories.1/@features.0}'
 and 'features' of

 'org.eclipse.b3.aggregator.impl.CustomCategoryImpl@487c9b46{file:/home/hudson/genie.simrel/.hudson/jobs/simrel.mars.runaggregator.VALIDATE.gerrit/workspace/org.eclipse.simrel.build/simrel.b3aggr#//@customCategories[identifier='General%20Purpose%20Tools']}'
 do not refer to each other





 From:Tom Schindl tom.schi...@bestsolution.at
 To:cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 01:39 PM
 Subject:Re: [cross-project-issues-dev] e(fx)clipse would like to
 recontribute to RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 



 Should I merge in the change, in any case?

 Tom

 On 11.06.15 19:30, Tom Schindl wrote:
 Hi David,

 I've pushed https://git.eclipse.org/r/#/c/50044/butthe validator is
 failing! I have no idea why!

 Tom

 On 11.06.15 19:28, David M Williams wrote:
 Tim,

 Ordinarily I would say no, it is too late (and encourage you to make
 fixes available from your own update site) ... but, since we are
 rebuilding for WindowBuilder anyway ... I think it would safe enough.

 Let me know once you are ready (or, if you change b3aggrcon file, I will
 see that).

 Thanks,




 From:Tom Schindl tom.schi...@bestsolution.at
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:06/11/2015 10:52 AM
 Subject:[cross-project-issues-dev] e(fx)clipse would like to
 recontributeto RC4
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 



 Hi,

 Sorry but it looks like I've forgot to push our RC4 build to the
 aggregator!

 Is it still possible to contribute? There are 2 important bug fixes in
 the build:
 * platform:.plugin.org.eclipse.pde.ui.icons.etool16.newpprj_wiz.gif not
  available any = use .png
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469024


 * Stackoverflow when doing autocomplete for visibility
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=469708

 Both of them are highly visible to users (the 1. already if e(fx)clipse
 is only installed and one opens the New Project Wizard!)

 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




 ___
 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




 ___
 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

Re: [cross-project-issues-dev] Fw: Proposed schedule for JDK 9

[Tom Schindl]

Hi,

I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=466683 to track
problems like the one of org.w3c.dom.** where things are now found on
the extension classloader which causes Equinox to not finding them anymore.

Tom

On 07.05.15 08:47, Tom Schindl wrote:
 Equinox is still fine on latest builds but Eclipse 4.5 as an IDE won't
 start unless you modify classloader delegation to take the
 extclassloader into account. 
 
 So as it looks today Eclipse 4.5 won't work on preview builds b61
 
 Tom
 
 Von meinem iPhone gesendet
 
 Am 07.05.2015 um 05:52 schrieb Wayne Beaton wa...@eclipse.org
 mailto:wa...@eclipse.org:
 
 I'm pretty sure that the Equinox team are the experts.

 AFAICT, Equinox/OSGi runs fine on Java 9. Or rather it did until very
 recently.

 http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-May/002174.html

 Equinox is engaged:

 https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08212.html

 Wayne

 On 06/05/15 03:58 PM, Scott Lewis wrote:
 Mike,

 Could you or someone comment on Java 9 modularity (jsr 376) and it's
 compatibility with OSGi?  Wayne appears to be on the experts group so
 maybe he knows what's happening there?

 Thanks,

 Scott

 [1] https://jcp.org/en/jsr/detail?id=376

 On 5/5/2015 2:51 PM, Mike Milinkovich wrote:
 ICYMI, Java 9 is now releasing September 2016.

 Mike Milinkovich
 mike.milinkov...@eclipse.org
 +1.613.220.3223
Original Message
 From: mark.reinh...@oracle.com
 Sent: Tuesday, May 5, 2015 12:22 PM
 To: jdk9-...@openjdk.java.net
 Subject: Proposed schedule for JDK 9

 Here is a proposed schedule for JDK 9:

 2015-12-10 Feature Complete
 2016-02-04 All Tests Run
 2016-02-25 Rampdown Start
 2016-04-21 Zero Bug Bounce
 2016-06-16 Rampdown Phase 2
 2016-07-21 Final Release Candidate
 2016-09-22 General Availability

 The dates here are meant to leave sufficient time for broad review and
 testing of the significant features of the release, in particular the
 introduction of a module system and the modularization of the platform,
 while maintaining the cadence of shipping a major release about every
 two years.

 The milestone definitions are the same as those for JDK 8 [1].

 Comments from JDK 9 Committers are welcome, as are reasoned objections.
 If no such objections are raised by 23:00 UTC next Tuesday, 12 May, or
 if they're raised and then satisfactorily answered, then per the JEP
 2.0
 process proposal [2] this will be adopted as the schedule for JDK 9.

 (This information is also available on the JDK 9 Project Page [3]).

 - Mark


 [1] http://openjdk.java.net/projects/jdk8/milestones#definitions
 [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
 [3] http://openjdk.java.net/projects/jdk9/
 ___
 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

 -- 
 Wayne Beaton
 @waynebeaton
 The Eclipse Foundation
 EclipseCon France 2015 http://www.eclipsecon.org/france2015
 ___
 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
 
 
 ___
 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

Re: [cross-project-issues-dev] Fw: Proposed schedule for JDK 9

[Tom Schindl]

Equinox is still fine on latest builds but Eclipse 4.5 as an IDE won't start 
unless you modify classloader delegation to take the extclassloader into 
account. 

So as it looks today Eclipse 4.5 won't work on preview builds b61

Tom

Von meinem iPhone gesendet

 Am 07.05.2015 um 05:52 schrieb Wayne Beaton wa...@eclipse.org:
 
 I'm pretty sure that the Equinox team are the experts.
 
 AFAICT, Equinox/OSGi runs fine on Java 9. Or rather it did until very 
 recently.
 
 http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-May/002174.html
 
 Equinox is engaged:
 
 https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08212.html
 
 Wayne
 
 On 06/05/15 03:58 PM, Scott Lewis wrote:
 Mike, 
 
 Could you or someone comment on Java 9 modularity (jsr 376) and it's 
 compatibility with OSGi?  Wayne appears to be on the experts group so maybe 
 he knows what's happening there? 
 
 Thanks, 
 
 Scott 
 
 [1] https://jcp.org/en/jsr/detail?id=376 
 
 On 5/5/2015 2:51 PM, Mike Milinkovich wrote: 
 ICYMI, Java 9 is now releasing September 2016. 
 
 Mike Milinkovich 
 mike.milinkov...@eclipse.org 
 +1.613.220.3223 
Original Message 
 From: mark.reinh...@oracle.com 
 Sent: Tuesday, May 5, 2015 12:22 PM 
 To: jdk9-...@openjdk.java.net 
 Subject: Proposed schedule for JDK 9 
 
 Here is a proposed schedule for JDK 9: 
 
 2015-12-10 Feature Complete 
 2016-02-04 All Tests Run 
 2016-02-25 Rampdown Start 
 2016-04-21 Zero Bug Bounce 
 2016-06-16 Rampdown Phase 2 
 2016-07-21 Final Release Candidate 
 2016-09-22 General Availability 
 
 The dates here are meant to leave sufficient time for broad review and 
 testing of the significant features of the release, in particular the 
 introduction of a module system and the modularization of the platform, 
 while maintaining the cadence of shipping a major release about every 
 two years. 
 
 The milestone definitions are the same as those for JDK 8 [1]. 
 
 Comments from JDK 9 Committers are welcome, as are reasoned objections. 
 If no such objections are raised by 23:00 UTC next Tuesday, 12 May, or 
 if they're raised and then satisfactorily answered, then per the JEP 2.0 
 process proposal [2] this will be adopted as the schedule for JDK 9. 
 
 (This information is also available on the JDK 9 Project Page [3]). 
 
 - Mark 
 
 
 [1] http://openjdk.java.net/projects/jdk8/milestones#definitions 
 [2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html 
 [3] http://openjdk.java.net/projects/jdk9/ 
 ___ 
 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 
 
 -- 
 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

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

[Tom Schindl]

Hi,

I see my build failing and succeeding at will because of pack200
problems. So I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=465527

Tom

On 24.04.15 16:26, David M Williams wrote:
 Might be related.  I can't look much now, need to be offline a few
 hours, but suggest anyone having trouble with signing or packing to open
 a cross-project bug, and I'll try to look at this afternoon.
 
 Be sure to specify what builder and which VM version all parties use.
 
 Thanks,
 
 
 
 
 
 
 From:Wim Jongman wim.jong...@gmail.com
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:04/24/2015 09:21 AM
 Subject:Re: [cross-project-issues-dev] Notice of change to batch
 signing service - reverted
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 David, Nebula got a report from a user that his build no longer works
 [2]. Does this relate to the changes of the signing service?
 
 I have added the eclipse.inf file but that did not make a difference [1]
 
 [1] 
 Thanks for investigatio but the build is still broken - sorry to say.
 Ist there a chance to sign with SHA-1 instead of SHA-256?
 
 Caused by: java.lang.RuntimeException: Messages while trying children
 repositories.: [: [Problems downloading artifact:
 osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504221032.:
 [Error reading signed
 content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6052487094287027653.jar]]]
 
 
 
 
 [2] *
 
 I'm using nebula gallery widget and get follwowing errors since April, 15th.
 
 It seems that signing has changed between version 0.6.0.201504080923 and
 0.6.0.201504150758 from SHA1-Digest to SHA-256-Digest.
 
 What are the consequences and implications for users? How can I get my
 project compiling again?
 
 Thanks in advance
 
 Maven-Output
 
 [INFO] Downloading org.eclipse.nebula.widgets.
 gallery
 [INFO] Fetching
 org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (0B of
 114,42kB at 0B/s) from
 _http://download.eclipse.org/technology/nebula/snapshot/plugins/_
 [INFO] 1 operation remaining.
 [INFO] Fetching
 org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (4kB of
 114,42kB at 0B/s) from
 _http://download.eclipse.org/technology/nebula/snapshot/plugins/_
 [ERROR] Internal error: java.lang.RuntimeException: Messages while
 trying children repositories.: [: [Problems downloading artifact:
 osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200
 907.: [Error reading signed
 content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar]]]
 - [Help 1]
 org.apache.maven.InternalErrorException: Internal error:
 java.lang.RuntimeException: Messages while trying children
 repositories.: [: [Problems downloading artifact:
 osgi.bundle,org.eclipse.nebul
 a.widgets.gallery,0.6.0.201504200907.: [Error reading signed
 content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar]]]
 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: Messages while trying children
 repositories.: [: [Problems downloading artifact:
 osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200907.: [Erro
 r reading signed
 content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar]]]
 at
 org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.downloadArtifacts(ResolutionContextImpl.java:515)
 at
 org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:105)
 at
 org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:69)
 at
 org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:342)
 at
 org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:162)
 at
 

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

[Tom Schindl]

Hi,

On 16.04.15 08:32, David M Williams wrote:
 I assume javax.annotation.jreis a bundle you sign? (And, you don't
 re-sign it, right?) We're learning that does not work reliably.
 And you have rebuild/resigned say, today, to make sure al the Java 6
 transitions were back in place.

javax.annotation.jre is a custom bundle no resigning, ... .

http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/javax.annotation.jre_1.2.0.201504160629.jar

(don't worry that it is empty - that's expected)

 
 I assume you use Tycho to build with? If not using Tycho, it could be
 several other things, but Tycho does very well. (IMHO).

Yes the build is done with tycho (i attach the relevant definition at
the end)

 
 Besides your local maven repo do you put your tmp directory in your
 workspace, so it is cleaned (deleted) also? (Currently, its that tmp
 directory where p2 leaves stuff (be default).

Have not set that yet - I'll try that one one as well.

 
 Given none of those are issues, sound like a case that it just can not
 be packed. Not ever bundle can be. And easiest to add that eclipse.inf
 to the META-INF directory with
 jarprocessor.exclude.pack=true
 So, it's signed .. just not packed.
 
 

It used to work for weeks and now it suddenly broke. The only maybe
interesting fact is that the bundle is empty (has no .class-Files)

Tycho config:

   profile
   idbuild-server/id
   build
 plugins
   plugin
 groupIdorg.eclipse.tycho/groupId
 artifactIdtarget-platform-configuration/artifactId
 version${tycho-version}/version
 configuration
   includePackedArtifactsfalse/includePackedArtifacts
 /configuration
   /plugin
   plugin
 groupIdorg.eclipse.tycho.extras/groupId
 artifactIdtycho-pack200a-plugin/artifactId
 version${tycho-extras.version}/version
 executions
   execution
 idpack200-normalize/id
 goals
   goalnormalize/goal
 /goals
 phaseverify/phase
   /execution
 /executions
   /plugin
   plugin
 groupIdorg.eclipse.cbi.maven.plugins/groupId
 artifactIdeclipse-jarsigner-plugin/artifactId
 version${cbi-plugins.version}/version
 executions
   execution
 idsign/id
 goals
   goalsign/goal
 /goals
 phaseverify/phase
   /execution
 /executions
   /plugin
   plugin
 groupIdorg.eclipse.tycho.extras/groupId
 artifactIdtycho-pack200b-plugin/artifactId
 version${tycho-extras.version}/version
 executions
   execution
 idpack200-pack/id
 goals
   goalpack/goal
 /goals
 phaseverify/phase
   /execution
 /executions
   /plugin
   plugin
 groupIdorg.eclipse.tycho/groupId
 artifactIdtycho-p2-plugin/artifactId
 version${tycho-version}/version
 executions
   execution
 idp2-metadata/id
 goals
   goalp2-metadata/goal
 /goals
 phaseverify/phase
   /execution
 /executions
 configuration
   defaultP2Metadatafalse/defaultP2Metadata
 /configuration
   /plugin
 /plugins
   /build
 /profile




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

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

[Tom Schindl]

a) I'm using a workspace local .m2-repo
b) I've enabled Clean workspace before build

Things are still broken.

Tom

On 15.04.15 21:15, Wim Jongman wrote:
 Tom did you remove your local maven repo?
 
 On Wed, Apr 15, 2015 at 12:44 PM, Tom Schindl
 tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote:
 
 Hi,
 
 I added that to both builds but this didn't change anything! I also
 doubt that this should have changed something because the problem is
 related to signing and not pack200.
 
 Tom
 
 On 15.04.15 11:46, Alexander Nyßen wrote:
  Did you try to specify
  
 '-Dorg.eclipse.update.jarprocessor.pack200=/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘
 
 
 on your runtime build to ensure it packs with Java6?
 
  Cheers Alexander
 
  Am 15.04.2015 um 11:23 schrieb Tom Schindl
  tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at
  mailto:tom.schi...@bestsolution.at
 mailto:tom.schi...@bestsolution.at:
 
  Hi,
 
  I cleaned everything I can in my HIPP but things still fail. My
  problem is not any orbit stuff but a bundle coming from my own
  runtime build.
 
  Tom
 
  On 15.04.15 10:30, Ed Willink wrote:
  Hi
 
  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
 
  It looks as if some inconsistently hashed/signed bundles are
  working their way through magic caches. Try a maximal clean.
 
  Regards
 
  Ed Willink
 
  On 15/04/2015 08:58, Tom Schindl wrote:
  Hi,
 
  And now the build is completely broken.
 
  I have 2 builds: 1. runtime build (producing a p2 repo) 2.
  tooling build use the p2 repo from 1 and other repos
 
  The 2nd build now fails with:
 
  [INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar
  from
 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 
 
 (0B of 64.52kB at 0B/s)
  [INFO] Fetching
  org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 
 
 (0B of 15.54kB at 0B/s)
  [INFO] Resolving class path of MavenProject:
  org.eclipse.fx.ide:org.eclipse.fx.ide.jdt.core:2.0.0-SNAPSHOT
  @
 
 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml
 
 
 
 [INFO] Computing target platform for MavenProject:
  org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @
 
 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
 
 
 
 [INFO] Resolving dependencies of MavenProject:
  org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @
 
 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml
 
 
 
 [INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 
 
 (0B of 4.81kB at 0B/s)
  [ERROR] An error occurred while transferring artifact
  canonical:
  osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
  repository
  http://download.eclipse.org/efxclipse/runtime-nightly/site:
 
 
 [ERROR]Problems downloading artifact:
  osgi.bundle,javax.annotation.jre,1.2.0.201504150739.:
  [ERROR]   Error reading signed
  content:/tmp/signatureFile5309382464664284679.jar [INFO]
  o.h.m.e.h.MavenExecutionResultHandler - Build failed with
  exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
  [1] org.apache.maven.InternalErrorException: Internal
  error:
 
 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 
 
 Could not mirror artifact
  osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
  the local Maven repository.See log output for details.
  [DEBUG] Closing connection to remote [ERROR] Internal
  error:
 
 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 
 
 Could not mirror artifact
  osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
  the local Maven repository.See log output for details. An
  error occurred while processing the signatures for the
  file: /tmp/signatureFile5309382464664284679.jar: Error
  occurs parsing the .SF file to find out the digest
  algorithm in this bundle:
  /tmp/signatureFile5309382464664284679.jar - [Help 1]
  org.apache.maven.InternalErrorException: Internal error:
 
 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 
 
 Could not mirror artifact
  osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
  the local Maven repository.See log output for details

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

[Tom Schindl]

 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
 tom.schi...@bestsolution.at 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
 


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

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

[Tom Schindl]

Hi,

No I have not set that for runtime nor the for tooling build. So I
would guess they both use the same?

My impression was also that the complete signing change was rolled
back to java6 so something is definately different than it was a few
days back.

I'll try to set that option it could not get worse than failing.

Tom

On 15.04.15 11:46, Alexander Nyßen wrote:
 Did you try to specify 
 '-Dorg.eclipse.update.jarprocessor.pack200=/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘

 
on your runtime build to ensure it packs with Java6?
 
 Cheers Alexander
 
 Am 15.04.2015 um 11:23 schrieb Tom Schindl 
 tom.schi...@bestsolution.at
 mailto:tom.schi...@bestsolution.at:
 
 Hi,
 
 I cleaned everything I can in my HIPP but things still fail. My
 problem is not any orbit stuff but a bundle coming from my own
 runtime build.
 
 Tom
 
 On 15.04.15 10:30, Ed Willink wrote:
 Hi
 
 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
 
 It looks as if some inconsistently hashed/signed bundles are
 working their way through magic caches. Try a maximal clean.
 
 Regards
 
 Ed Willink
 
 On 15/04/2015 08:58, Tom Schindl wrote:
 Hi,
 
 And now the build is completely broken.
 
 I have 2 builds: 1. runtime build (producing a p2 repo) 2.
 tooling build use the p2 repo from 1 and other repos
 
 The 2nd build now fails with:
 
 [INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar
 from 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 64.52kB at 0B/s)
 [INFO] Fetching
 org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 15.54kB at 0B/s)
 [INFO] Resolving class path of MavenProject: 
 org.eclipse.fx.ide:org.eclipse.fx.ide.jdt.core:2.0.0-SNAPSHOT
 @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml


 
[INFO] Computing target platform for MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml


 
[INFO] Resolving dependencies of MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml


 
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 4.81kB at 0B/s)
 [ERROR] An error occurred while transferring artifact
 canonical: 
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
 repository 
 http://download.eclipse.org/efxclipse/runtime-nightly/site:

 
[ERROR]Problems downloading artifact:
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739.: 
 [ERROR]   Error reading signed 
 content:/tmp/signatureFile5309382464664284679.jar [INFO]
 o.h.m.e.h.MavenExecutionResultHandler - Build failed with 
 exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
 [1] org.apache.maven.InternalErrorException: Internal
 error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. 
 [DEBUG] Closing connection to remote [ERROR] Internal
 error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. An
 error occurred while processing the signatures for the
 file: /tmp/signatureFile5309382464664284679.jar: Error
 occurs parsing the .SF file to find out the digest
 algorithm in this bundle: 
 /tmp/signatureFile5309382464664284679.jar - [Help 1] 
 org.apache.maven.InternalErrorException: Internal error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. 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:62)


 
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


 
at java.lang.reflect.Method.invoke(Method.java:497)
 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

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

[Tom Schindl]

Hi,

I added that to both builds but this didn't change anything! I also
doubt that this should have changed something because the problem is
related to signing and not pack200.

Tom

On 15.04.15 11:46, Alexander Nyßen wrote:
 Did you try to specify 
 '-Dorg.eclipse.update.jarprocessor.pack200=/shared/common/sun-jdk1.6.0_21_x64/jre/bin“‘

 
on your runtime build to ensure it packs with Java6?
 
 Cheers Alexander
 
 Am 15.04.2015 um 11:23 schrieb Tom Schindl 
 tom.schi...@bestsolution.at
 mailto:tom.schi...@bestsolution.at:
 
 Hi,
 
 I cleaned everything I can in my HIPP but things still fail. My
 problem is not any orbit stuff but a bundle coming from my own
 runtime build.
 
 Tom
 
 On 15.04.15 10:30, Ed Willink wrote:
 Hi
 
 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
 
 It looks as if some inconsistently hashed/signed bundles are
 working their way through magic caches. Try a maximal clean.
 
 Regards
 
 Ed Willink
 
 On 15/04/2015 08:58, Tom Schindl wrote:
 Hi,
 
 And now the build is completely broken.
 
 I have 2 builds: 1. runtime build (producing a p2 repo) 2.
 tooling build use the p2 repo from 1 and other repos
 
 The 2nd build now fails with:
 
 [INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar
 from 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 64.52kB at 0B/s)
 [INFO] Fetching
 org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from 
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 15.54kB at 0B/s)
 [INFO] Resolving class path of MavenProject: 
 org.eclipse.fx.ide:org.eclipse.fx.ide.jdt.core:2.0.0-SNAPSHOT
 @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml


 
[INFO] Computing target platform for MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml


 
[INFO] Resolving dependencies of MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @ 
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml


 
[INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/

 
(0B of 4.81kB at 0B/s)
 [ERROR] An error occurred while transferring artifact
 canonical: 
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from
 repository 
 http://download.eclipse.org/efxclipse/runtime-nightly/site:

 
[ERROR]Problems downloading artifact:
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739.: 
 [ERROR]   Error reading signed 
 content:/tmp/signatureFile5309382464664284679.jar [INFO]
 o.h.m.e.h.MavenExecutionResultHandler - Build failed with 
 exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler -
 [1] org.apache.maven.InternalErrorException: Internal
 error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. 
 [DEBUG] Closing connection to remote [ERROR] Internal
 error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. An
 error occurred while processing the signatures for the
 file: /tmp/signatureFile5309382464664284679.jar: Error
 occurs parsing the .SF file to find out the digest
 algorithm in this bundle: 
 /tmp/signatureFile5309382464664284679.jar - [Help 1] 
 org.apache.maven.InternalErrorException: Internal error: 
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into
 the local Maven repository.See log output for details. 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:62)


 
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


 
at java.lang.reflect.Method.invoke(Method.java:497)
 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:
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:

 
Could not mirror artifact
 osgi.bundle

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

[Tom Schindl]

Hi,

I cleaned everything I can in my HIPP but things still fail. My problem
is not any orbit stuff but a bundle coming from my own runtime build.

Tom

On 15.04.15 10:30, Ed Willink wrote:
 Hi
 
 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464594
 
 It looks as if some inconsistently hashed/signed bundles are working
 their way through magic caches. Try a maximal clean.
 
 Regards
 
 Ed Willink
 
 On 15/04/2015 08:58, Tom Schindl wrote:
 Hi,

 And now the build is completely broken.

 I have 2 builds:
 1. runtime build (producing a p2 repo)
 2. tooling build use the p2 repo from 1 and other repos

 The 2nd build now fails with:

 [INFO] Fetching org.eclipse.fx.core_2.0.0.201504150739.jar from
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 (0B of 64.52kB at 0B/s)
 [INFO] Fetching org.eclipse.fx.osgi.util_2.0.0.201504150739.jar from
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 (0B of 15.54kB at 0B/s)
 [INFO] Resolving class path of MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.jdt.core:2.0.0-SNAPSHOT @
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.jdt.core/pom.xml

 [INFO] Computing target platform for MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml

 [INFO] Resolving dependencies of MavenProject:
 org.eclipse.fx.ide:org.eclipse.fx.ide.ui:2.0.0-SNAPSHOT @
 /jobs/genie.efxclipse/efxclipse_ide/workspace/bundles/tooling/org.eclipse.fx.ide.ui/pom.xml

 [INFO] Fetching javax.annotation.jre_1.2.0.201504150739.jar from
 http://download.eclipse.org/efxclipse/runtime-nightly/site/plugins/
 (0B of 4.81kB at 0B/s)
 [ERROR] An error occurred while transferring artifact canonical:
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 from repository
 http://download.eclipse.org/efxclipse/runtime-nightly/site:
 [ERROR]Problems downloading artifact:
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739.:
 [ERROR]   Error reading signed
 content:/tmp/signatureFile5309382464664284679.jar
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with
 exception(s)
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1]
 org.apache.maven.InternalErrorException: Internal error:
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
 Maven repository.See log output for details.
 [DEBUG] Closing connection to remote
 [ERROR] Internal error:
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
 Maven repository.See log output for details. An error occurred while
 processing the signatures for the file:
 /tmp/signatureFile5309382464664284679.jar: Error occurs parsing the
 .SF file to find out the digest algorithm in this bundle:
 /tmp/signatureFile5309382464664284679.jar - [Help 1]
 org.apache.maven.InternalErrorException: Internal error:
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
 Maven repository.See log output for details.
 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:62)

 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

 at java.lang.reflect.Method.invoke(Method.java:497)
 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:
 org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException:
 Could not mirror artifact
 osgi.bundle,javax.annotation.jre,1.2.0.201504150739 into the local
 Maven repository.See log output for details.
 at
 org.eclipse.tycho.repository.local.MirroringArtifactProvider.downloadArtifact(MirroringArtifactProvider.java:218)

 at
 org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeOneFormatLocallyAvailable(MirroringArtifactProvider.java:203)

 at
 org.eclipse.tycho.repository.local.MirroringArtifactProvider.makeLocallyAvailable(MirroringArtifactProvider.java:174

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

[Tom Schindl]

Hi,

Not sure this is related but I've now seen my build failing because of
pack200 and on the next run succeeding.

The last failure was:
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack 
 (pack200-pack) on project org.eclipse.fx.core.guice: Execution pack200-pack 
 of goal org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: 
 MALFORMED
 [DEBUG] Closing connection to remote
 [ERROR] Failed to execute goal 
 org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack (pack200-pack) on 
 project org.eclipse.fx.core.guice: Execution pack200-pack of goal 
 org.eclipse.tycho.extras:tycho-pack200b-plugin:0.21.0:pack failed: MALFORMED 
 - [Help 1]
 [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/PluginExecutionException
 [ERROR] 
 [ERROR] After correcting the problems, you can resume the build with the 
 command
 [ERROR]   mvn goals -rf :org.eclipse.fx.core.guice
 [DEBUG] Waiting for process to finish
 [DEBUG] Result: 1
 Sending e-mails to: tom.schi...@bestsolution.at

I've never seen these failures so I'm not sure they are related to the
change mentioned?

Tom

On 11.04.15 08:48, David M Williams wrote:
 I wanted to let everyone know that we are changing the version of
 Java's pack200 at the infrastructure service I call batch signer.
  (*_Bug 463510_* https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510)
 It was using Java 6 level of pack200, and we have moved to the Java 8
 level of pack200.
 
 This command is described at
 https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
 
 
 This does not directly impact Tycho users or Buckminster users (which do
 their own re-pack and pack, based on the VM the build is running, I
 assume) but might effect PDE users, which traditionally have used this
 service to re-pack (condition) and sign jars -- and, then at some
 short later time are packed.  At that some later time, it is the
 release engineers responsibility to use the same version to 'pack' as
 was used to 'repack'.
 
 While no direct impact to Tycho or Buckminster builders, the principles
 and consequences of moving from one level (Java 6) to another (Java 8)
 apply with any builder, so the following points may be useful
 information to all.
 
 If you have old byte codes, or, even new ones, compiled at the Java 4,
 Java 5, or Java 6 level, you *might* find some of those bytes codes no
 longer survive the re-pack, sign, and pack process (where as maybe
 the would survived, when using Java 6 to run your build (and hence your
 repack/pack). That is, if user tries to download the pack.gz file, and
 unpack into a normal jar, it may be reported to have in invalid
 signature or in some other way broken.
 
 In my experience, with Orbit jars, the error rate is about 1.7%.
 Others, for some unknown reason, see higher rates (such as 20-30%?) .
 Some of these cases *might* be bugs in the pack/unpack programs, but
 it's just as likely that there are bugs (fringe cases) where the byte
 codes for lower levels of Java are not quite right.  All I know for
 sure: it has never been perfect.
 
 But, luckily, easy to solve.
 All three builders (PDE, Tycho, and Buckminster) allow you to specify an
 'eclipse.inf' file in the META-INF directory, with a directive (line)
 that is:
   jarprocessor.exclude.pack*=true*
 
 Thus, that one problematic jar is not packed, but is still signed.
 
 So important point 1: be sure you pack200 with the same version you
 used to do repack (if the builder doesn't do it for you automatically).
 Important point 2: I wouldn't recommend studying the byte codes and
 trying to find a pattern of code that is the cause (unless you just
 happen to love byte codes), ... just slap in an eclipse.inf file and
 move on to more important things.
 Important point 3: You should not, ever never, re-sign and certainly
 not re-pack or pack200 a jar that has already been signed or processed
 by pack200. That pretty much guarantees the jar will be broken. In more
 ways than one. (*_Bug 461669_*
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669)  
 
 The reason for making this move, now, is that it is best to keep up
 with what our users are using, and, with versions of Java that are
 expected to stay in service for a while ... otherwise, we might have to
 monkey around with this during a service release, which is less than ideal.
 
 * Bonus, for reading this far in my wordy note: Why jump two levels,
 from 6 to 8, why not move to Java 7 

Re: [cross-project-issues-dev] Caution about using Platform I-build I20150407-0800

[Tom Schindl]

Hi,

Sorry for troubles - looks like EMF generates invalid MANIFEST.MFs but
I'm not yet sure how I managed to make it generated a wrong one but once
I do I'll file a bug against EMF.

Tom

On 08.04.15 16:32, David M Williams wrote:
 This I-build,  I20150407-0800, has a bad bug that has effected some
 early adopters, so it's recommended not to use it (especially as a basis
 for doing builds against).
 
 We are re-spinning another iwth the bug fixed. It will be available this
 (Wednesday) afternoon, approximately 2 PM (Eastern).
 
 For more details, see
 
 *_Bug 464121_* https://bugs.eclipse.org/bugs/show_bug.cgi?id=464121-
 Circular dependency in e4.ui.model.workbench
 
 Much thanks to those early adopters to help us find such bugs, and
 apologies for the extra work it has caused them.
 
 
 
 
 ___
 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

Re: [cross-project-issues-dev] Your friendly error reports bot is suspended

[Tom Schindl]

Do I = e(fx)clipse have to opt-in explictly if i want to go with option 2?

Tom

Von meinem iPhone gesendet

 Am 09.01.2015 um 08:04 schrieb Marcel Bruch marcel.br...@codetrails.com:
 
 I see three valuable ways:
 
 1. Only report issues into the separate system and let committers review 
 these items from time to time manually.
 2. Report issues into the separate system and send daily reports to 
 committers or project lists that there are new incoming problems.
 3. Report issues into the separate system AND directly into the project’s 
 bugzilla product/component.
 
 Options 1. and 2. are on my todo list for M5. Your option 3 seems viable to 
 me as well. 
 My proposal: Projects that wish to receive error reports directly in 
 bugzilla, should say so (e.g. by a decision on the mailing list) and specify 
 the bugzilla component to assign these reports with. I’ll add an UI for that.
 
 What do you/others think?
 
 Best,
 Marcel
 
 On 09 Jan 2015, at 05:04, Lars Vogel lars.vo...@gmail.com wrote:
 
 Hi Marcel,
 
 thanks for the information.
 
 From the platform.ui side I'm not sure that we will be able to adapt yet 
 another system for looking at bug reports. IIRC the update of Bugzilla 
 worked fine for us, with the only issue that the duplicate bug dedection has 
 marking not the main bug and therefore created a long dependency chain. But 
 I think this has been fixed.
 
 Would it be possible to configure your intermediate system per comment to 
 continue to create automatic Bugzilla entries? If yes, every project could 
 vote to use your new system or continue to work only in Bugzilla. 
 
 Best regards, Lars
 
 2015-01-08 8:55 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com:
 Hi Lars,
 
 no, there is no bug for this. But an interim system is live and receives 
 errors. 
 
 The UI also offers basic search capabilities now. See [1] for an overview 
 and [2] for an example of a concrete query. It also offers a set of 
 predefined per-project queries (see below for a comprehensive list).
 
 
 Plans are to have it operational by M5 (end of January). Until M5 the 
 proposed workflow is as follows:
 
 1. Committers can review the 'project problem listings' (given below) once 
 per day
 2. For every new problem that (you think) needs a closer look, move it to 
 Bugzilla. Convenient support for this will be added tomorrow.
 
 
 Some notes about the interim system:
 1. Even if possible, please do not make any changes in ui except creating 
 bugs from there; they might get lost during system updates.
 2. Bugzilla is the only stable reference you have. Thus, move errors to 
 Eclipse’ Bugzilla if you think they are bugs and start working on them 
 there.
 3. Once a bug was created in bugzilla, don’t look back or try to keep the 
 error reporting system in-sync. Eventually we’ll do that automatically.
 4. Problem statistics and duplicate detection results may look suspicious 
 at times. It's more challenging than it may look on a first sight to detect 
 duplicates in large, moving code bases. 
 
 Having said this, I’m happy to receive feature requests and suggestions by 
 email (probably better off this list) or, preferably, via bugzilla.
 
 Best,
 Marcel
 
 
 Unconfirmed problems by project Quickstarter Queries
 
 Acceleo
 Ant
 C/C++ Development Tools
 Code Recommenders
 Eclipse Debug
 Eclipse Platform
 EGit / JGit
 EMF Client Platform
 Epsilon
 Graphical Modeling Framework
 Graphical Modeling Tools
 Help
 Java Debug Interface
 Java Development Tools
 Machine 2 Machine
 Marketplace Client
 Maven 2 Eclipse
 Modisco
 Mylyn
 Object Teams
 OCL
 Oomph
 P2
 Papyrus
 Plugin Development Environment
 Webtools Project
 Windowbuilder
 Xtend
 Xtext
 
 
 
 
 
 [1] https://dev.eclipse.org/recommenders/committers/confess/#/
 [2] 
 https://dev.eclipse.org/recommenders/committers/confess/#/problems/search?projects=platformkinds=NORMALkinds=FREEZEcategories=UNCONFIRMEDpage=0size=10sort=createdOn,desc
 
 
 
 On 07 Jan 2015, at 11:30, Lars Vogel lars.vo...@gmail.com wrote:
 
 Hi Marcel,
  I’ve been asked to shutdown the collector to keep the annoyance low 
  until this is fixed, which I do hereby.
 
 Do you have the bug number for the pending fix in the error reporting bot?
 
 Best regards, Lars 
 
 2014-12-19 7:35 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com:
 Hi,
 
 in Bug 455361 Konstantin expressed his annoyance about another comment  
 on his bug.
 I’ve been asked to shutdown the collector to keep the annoyance low until 
 this is fixed, which I do hereby.
 
 The collector will continue to receive errors but will not send 
 notifications to anyone or create comments in bugzilla.
 
 
 Happy Christmas Season
 Marcel
 ___
 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] Provider and feature names

[Tom Schindl]

Hi,

a) I don't see any conflict. I didn't say that putting the project name
   in front of the feature name allows you to be lazy and not have a
   descriptive 2nd part. BTW even if the sorting would be better the
   next thing I could talk about is searching.

b) You are right we are making a decision because of an UI but you can
   not set out a rule to change things if you know there are problems
   who are not yet solved. It's like people deprecating APIs and don't
   provide a full replacement

Tom

On 18.11.14 07:53, Gunnar Wagenknecht wrote:
 Tom,
 
 Am 17.11.2014 um 22:26 schrieb Tom Schindl tom.schi...@bestsolution.at:
 I disagree with you on that. I think it has value that the project name
 is in the feature name and the reason it simple: Better grouping on the
 p2-Update-UI!
 
 
 Those points seems valid … but isn’t it insane how we constrain ourselves to 
 drive a decision because of some broken UI? I actually prefer more 
 descriptive feature names and stopped repeating the project name in features.
 
 -Gunnar
 
 


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

Re: [cross-project-issues-dev] Provider and feature names

[Tom Schindl]

[...]

 What I have down for the feature name may be a bit more controversial.
 I'm thinking of this from the consumer's point of view: the project name
 isn't generally interesting (unless you've mounted a serious
 brand-recognition campaign); it is the functionality provided by the
 feature that needs to be related.
 
 IMHO, the EGit project does a decent job of this. The feature name is
 Git Team Provider and the provider name is Eclipse EGit. Other
 features include Task focused interface for Eclipse Git Team Provider.
 It's immediately clear what these features provide. They even provide
 some helpful information in the description of the feature.

I disagree with you on that. I think it has value that the project name
is in the feature name and the reason it simple: Better grouping on the
p2-Update-UI!

Uncheck the Group itemy by category and discover that you'd never have
found that Task focused ... but now imagine you know Mylyn or EGit and
it would have been found next to all other mylyn/egit entries you'd had
a much easier life!

So I'm -1 on the proposal to drop the project name!

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

Re: [cross-project-issues-dev] Limiting GTK versions supported by SWT or SWT call for help

[Tom Schindl]

hi,

dropping Gtk2 means:
* swing embed is broken when the Gtk-Theme is used because it links
  against Gtk2
* javafx embed is broken because it links against Gtk2

So clearly openjdk/oraclejdk (even the latest builds) links against
Gtk2, or am I wrong in this regard?

I can also prove what Andrey said: We have turned of Gtk3 on *all* our
linux desktops because there are too many problems with it.

Tom

On 08.10.14 16:18, Aleksandar Kurtakov wrote:
 - Original Message -
 From: Andrey Loskutov losku...@gmx.de
 To: Cross project issues cross-project-issues-dev@eclipse.org, 
 Aleksandar Kurtakov akurt...@redhat.com
 Sent: Wednesday, October 8, 2014 5:11:53 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions supported by 
 SWT   or SWT call for help

 BTW we at Advantest are still using RHEL 5.8, even because RHEL has crazy
 long support times :o)

 Limiting to GTK3 only and drop GTK2 ports for *new* Eclipse releases would be
 good idea but AFAK GTK3 SWT port is still problematic (I'm on *latest*
 Ubuntu and must turn it off).

 In general I would also prefer to have always *one* (smallest possible from
 latest GTK on major distros) SWT port for latest Eclipse release but that
 port must be 99% usable.

 I won't hijack the thread, but the best long term solution for SWT Linux
 ports and Eclipse UI toolkit in general would be to move away from SWT to
 Java FX or better Qt (I know Qt LGPL license is a showstopper, but this *is*
 technically viable alternative). Without the man power of IBM (which
 originally allowed SWT to be developped for so many different plattforms)
 SWT as we have it today has no feature.
 
 Options are endless. But let's try to limit the discussion towards Mars and 
 Mars+1 for now. In this timeframe I don't think a new option will pop up and 
 I'm trying to solve our daily issues first so we can try to look a bit 
 further.
 
 
 Alexander Kurtakov
 Red Hat Eclipse team
 


 Am 8. Oktober 2014 16:44:30 OESZ, schrieb Aleksandar Kurtakov
 akurt...@redhat.com:
 - Original Message -
 From: Mat Booth mat.bo...@redhat.com
 To: Cross project issues cross-project-issues-dev@eclipse.org
 Sent: Wednesday, October 8, 2014 4:27:25 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions
 supported by SWTor SWT call for help

 - Original Message -
 From: Igor Fedorenko i...@ifedorenko.com
 To: cross-project-issues-dev@eclipse.org
 Sent: Wednesday, 8 October, 2014 12:38:10 PM
 Subject: Re: [cross-project-issues-dev] Limiting GTK versions
 supported by
 SWT   or SWT call for help

 What major distribution still stuck with GTK2? Aren't they all on
 GTK3
 already?

 --
 Regards,
 Igor


 RHEL 6/CentOS 6 only has GTK 2.20, IIRC


 --
 Kind regards,
 Andrey Loskutov

 http://google.com/+AndreyLoskutov

 ___
 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] Publishing Javadoc - How To?

[Tom Schindl]

In efxclipse we are using the tycho-document-bundle-plugin plugin to
publish javadoc.

See
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/releng/org.eclipse.fx.runtime.doc/pom.xml
- I don't know if this is the best way to do it but at least it works
for us.

Tom

On 26.09.14 14:05, Matthias Sohn wrote:
 On Fri, Sep 26, 2014 at 11:56 AM, Jeremie Bresson
 jeremie.bres...@bsiag.com mailto:jeremie.bres...@bsiag.com wrote:
 
 Hi Everybody,
 
 __ __
 
 Since a very long time people are asking us to publish the Javadoc
 of the Eclipse Scout Project as HTML page [Bug 408052 - #1].
 
 __ __
 
 I wonder what the best practice is. I have seen that some project
 have decided to publish it under:
 
 * help.eclipse.org http://help.eclipse.org (for example the SWT
 project [#2])
 
 * download.eclipse.org http://download.eclipse.org (for example
 the EMF project [#3])
 
 __ __
 
 Personally I like the second approach. Is there an official
 recommended approach?
 
 __ __
 
 Could you also indicate how to achieve this during a CBI build? 
 
 We are using maven tycho. I imagine there are examples in the
 projects that are already publishing Javadoc. I would really
 appreciate a pointer to know how to start.
 
 __ __
 
 Thank you in advance,
 
 Jérémie
 
 [#1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=408052
 
 [#2]
 
 http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/package-summary.html
 
 
 [#3] http://download.eclipse.org/modeling/emf/emf/javadoc/2.9.0/
 
 
 I just implemented the second approach for JGit using maven-site-plugin,
 the changes implementing
 that are here:
 https://git.eclipse.org/r/#/c/33891/
 https://git.eclipse.org/r/#/c/33892/
 and the first result is here (javadoc is under project reports)
 http://download.eclipse.org/jgit/site/3.5.0-SNAPSHOT/ 
 
 --
 Matthias
 
 
 ___
 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

[Tom Schindl]

Hi Wayne,

I create a release entry, we'll fill it with content (release plan) in
the days to come.

Tom

[1]https://projects.eclipse.org/projects/technology.efxclipse/releases/2.0.0

On 20.08.14 16:20, Wayne Beaton wrote:
 You need to create a release record in the PMI:
 
 https://projects.eclipse.org/projects/technology.efxclipse/create-release
 
 Wayne
 
 On 20/08/14 04:46 AM, 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.

 Tom
 ___
 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
 EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014
 
 
 ___
 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

[Tom Schindl]

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)clipse into a plain Eclipse SDK (+some WST, m2e, ...), p2
is clever enough to understand that there's an AdapterHook bundle is
about to be installed and corrects the config.ini.

c) On repackaging + Equinox classloader loading ext
---
It is a bad idea to rebundle anything from JDK because e.g. FXCanvas
calls out to *internal* JavaFX APIs so while your application will work
with JDK8u20 nobody on the world guarantees that it will still work with
JDK8u40 unless you use the the jar that resides in your JDK.

You can do that with Equinox-Specific MANIFEST-Entries but that still
leaves you with the heavy change of modifying the Equinox Classloader
Hierarchy - I hoped Tom Watson fixes that Equinox specific thing with
the Equinox rewrite but apparently it was not done.

Tom

On 21.08.14 16:11, Doug Schaefer wrote:
 I guess this raises another question. What about the other way. e(fx)clipse 
 doesn't get in the way, but does it help either? i.e. With e(fx)clipse on the 
 release train, would it be possible to have an Eclipse EPP package use JavaFX?
 
 All the magic required to get this actually running really confirms what many 
 people are telling me, that JavaFX is ready for prime time. I love the 
 direction, but there are a lot of hurdles to actually use it in product. In 
 our testing at QNX we did change the classloader hierarchy to include ext, 
 and we bundle-ified the swt-javafx jar. Worked but not sure we can do that in 
 the Eclipse context.
 
 Thanks,
 Doug.
 
 From: cross-project-issues-dev-boun...@eclipse.org 
 [cross-project-issues-dev-boun...@eclipse.org] on behalf of Tom Schindl 
 [tom.schi...@bestsolution.at]
 Sent: Thursday, August 21, 2014 3:37 AM
 To: cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] e(fx)clipse participating in Mars 
 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

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

[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 ed.me...@gmail.com
 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 unit id='a.jre where you'll see how it defines all
 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)clipse into a plain Eclipse SDK (+some WST, m2e, ...), p2
 is clever enough to understand that there's an AdapterHook bundle is
 about to be installed and corrects the config.ini.

 c) On repackaging + Equinox classloader loading ext
 ---
 It is a bad idea to rebundle anything from JDK because e.g. FXCanvas
 calls out to *internal* JavaFX APIs so while your application will work
 with JDK8u20 nobody on the world guarantees that it will still work with
 JDK8u40 unless you use the the jar that resides in your JDK.

 You can do that with Equinox-Specific MANIFEST-Entries but that still
 leaves you with the heavy change of modifying the Equinox Classloader
 Hierarchy - I hoped Tom Watson fixes that Equinox specific thing with
 the Equinox rewrite but apparently it was not done.

 Tom

 On 21.08.14 16:11, Doug Schaefer wrote:
 I guess this raises another question. What about the other way.
 e(fx)clipse doesn't get in the way, but does it help either? i.e.
 With e(fx)clipse on the release train, would it be possible to have
 an Eclipse EPP package use JavaFX?

 All the magic required to get this actually running really confirms
 what many people are telling me, that JavaFX is ready for prime
 time. I love the direction, but there are a lot of hurdles to
 actually use it in product. In our testing at QNX we did change the
 classloader hierarchy to include ext, and we bundle-ified the
 swt-javafx jar. Worked but not sure we

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

[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.

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

Yep you are wrong.

Tom

___
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

[Tom Schindl]

You are right in that it is an install time problem as well - i think
from a p2 point of view tp-resolution  install a fairly equal - i think
it is the same p2-API-call!

The problem at runtime is:
a) javafx is not part of any EE so if you have a package import of
   javafx OSGi will not wire your bundle because nobody at runtime
   exposes a javafx-package, for javax the EE does that

b) javafx is part of the ExtClasspath but Equinox does NOT look up
   classes from there so in case you think you can get away with out
   doing any package impports, Equinox will tell you that no javafx
   classes are available

So why fixing the runtime and tp/install problem differently (if you can
find a solution) if one - the current one - fixes all of them?

Tom

On 21.08.14 22:20, Ed Merks wrote:
 Tom,
 
 It is my impression that this is also an install time resolution issue,
 not just a TP resolution issue.  Of course there is also the runtime
 resolution issue: at that time there is a real JRE that must provide
 resolutions to be able to load actual classes.  So yes, that's
 definitely a third and fundamental  issue not to be mixed up with the
 other two.  At install time, you don't really know which JRE will be
 available, so some fake units are (apparently) needed. When resolving
 the TP, one ought to know which JRE is available, because there are JREs
 registered with JDT that have such information (and there's even a
 default), but (apparently) fake JREs are needed for that too.  In any
 case, at runtime, it better all just work with classpath magic because
 there is definitely exactly one JRE available and it better be able to
 load real classes that really work.  Indeed it's easy to mix all these
 things up, because each of these things better work in some consistent
 and coherent sensible way.  After all, if it works at runtime, but you
 can't install the unit, or can't provision a target platform to develop
 it, you'll never get to the stage of actually running it...
 
 Cheers,
 Ed
 
 On 21/08/2014 9:43 PM, Tom Schindl wrote:
 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 ed.me...@gmail.com
 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 unit id='a.jre where you'll see how it defines all
 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

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

[Tom Schindl]

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.

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

[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
 alexander.nys...@itemis.de 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
 alexander.nys...@itemis.de 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
 tom.schi...@bestsolution.at 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
 david_willi...@us.ibm.com 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 alexander.nys...@itemis.de
 mailto:alexander.nys...@itemis.de
 To:Cross project issues
 cross-project-issues-dev@eclipse.org
 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-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_ http://www.itemis.de/_
 __alexander.nyssen@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: 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
 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
 ___
 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
 ___
 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

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

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

[Tom Schindl]

We have not announced but we will :-) if allowed join Mars!

An official request will follow in soon!

Tom

Von meinem iPhone gesendet

 Am 18.08.2014 um 18:57 schrieb Alexander Nyßen alexander.nys...@itemis.de:
 
 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
___
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?

[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 wa...@eclipse.org:
 
 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
 ECE Friends 480x60.png
 ___
 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] What policy w.r.t. javafx package imports?

[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 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 alexander.nys...@itemis.de 
 To:Cross project issues cross-project-issues-dev@eclipse.org, 
 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

Re: [cross-project-issues-dev] Forum login not possible

[Tom Schindl]

Hi had the same problems when using Firefox, with Chrome it worked for me.

Tom

On 12.08.14 11:46, Wim Jongman wrote:
 Hi,
 
 I cannot login to the forum already for some time. 
 
 When I click on a discussion that I receive by mail it takes me to that
 discussion but when I press login from that page, it takes me to a login
 screen and the returns me in the main page of the forum. 
 
 In addition, I am not logged in. Clicking again on Login just does
 something in the background without any visual clues.
 
 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

Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project

[Tom Schindl]

Right all API in JavaFX is generified - and yes you simply have to take
the most basic type you have but like outlined already by Lars' one
often is able to find a base type (e.g. think about a File-Tree-Viewer
where the base class is always a File-Instance).

What worries me more how to deal with Object[] in the viewers which you
made generic but I'm uncertain this is legal from an API point of view
because some dumb man could have written code like this:

 public class TestMe {
   public interface BE {
   public E[] test();
   }
   
   public static class C implements BString {
   @Override
   public String[] test() {
   return new String[1];
   }
   }
   
   public static void main(String[] args) {
   B t = new C();
   Object[] v = t.test();
   v[0] = new Object();
   }
 }

which would break at the very moment someone adds generics

 public class TestMe {
   public interface BE {
   public E[] test();
   }
   
   public static class C implements BString {
   @Override
   public String[] test() {
   return new String[1];
   }
   }
   
   public static void main(String[] args) {
   B t = new C();
   Object[] v = t.test();
   v[0] = new Object(); // BAM BAM BAM ArrayStoreException!
   }
 }

It is highly unlikely that someone did something like that with
JFace-Viewers but the really bad thing is that no compiler can ever
catch this problem.

Tom

On 30.07.14 13:03, Erdal Karaca wrote:
 I am no JavaFX expert, but it has Views (for example, TreeView) whose
 Items are aware of a root generic type: for example,
 TreeView#setRoot(TreeItemT)...
 If the viewer input has no base class for all of its elements, then the
 API user would have to use Object again.
 I wonder how the JavaFX devs/community solved this issue... 
 
 
 
 2014-07-30 12:44 GMT+02:00 Lars Vogel lars.vo...@gmail.com
 mailto:lars.vo...@gmail.com:
 
 - Some stuff just doesn't make sense to be generified because it
 often contains various kinds of objects, e.g. (tree)  viewers. See
 also 
 _http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html_. 
 
 We need to investigate that,  for example in the e4 tools project
 our tree is based on MApplicationElement hence for us it would make
 sense to have a generified TreeViewer. 
 
 
 2014-07-30 11:42 GMT+02:00 Daniel Megert daniel_meg...@ch.ibm.com
 mailto:daniel_meg...@ch.ibm.com:
 
 Just for the records, here are some constraints that I required
 in order to agree to continue that work:
 
 - Some stuff just doesn't make sense to be generified because it
 often contains various kinds of objects, e.g. (tree)  viewers.
 See also
 _http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html_.
 
 - If generified types cannot be plugged together unless
 everything is again just Object or Class, it's not worth to
 generify those types.
 - The generified code must be in a shape so that clients can
 start to fix their code by invoking Refactor  Infer Generic
 Type Arguments... This needs to be validate on existing Platform
 UI code.
 
 Dani
 
 
 
 From:Lars Vogel lars.vo...@gmail.com
 mailto:lars.vo...@gmail.com
 To:cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org, Jeanderson
 Candido jeanderso...@gmail.com
 mailto:jeanderso...@gmail.com, Hendrik Still
 gamm...@gmail.com mailto:gamm...@gmail.com
 Date:30.07.2014 11:23
 Subject:[cross-project-issues-dev] Information about the
 Generifing JFaceviewers project
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 mailto:cross-project-issues-dev-boun...@eclipse.org
 
 
 
 
 
 Hi,
 
 as some of you probably remember, the platform.ui team started a
 GSoC project last year to generify the JFace viewer framework.
 We (platform.ui team together with John Arthone and Dani Megert)
 decided that it is worth to finish this project and started a
 new GSoC project.
 
 Jeanderson Barros Candido (cc) is working on this project with
 Hendrik Still (cc) (GSoC student from last year) and me as mentor.
 
 I personally think the work looks already very good and plan to
 integrated it soon into the master. We are trying to learn from
 the experience from last year, therefore:
 
 -  We plan to integrate it as a whole, not piece wise so people
 can fix warning messages created by this change
 

Re: [cross-project-issues-dev] Home dir disk full on build.eclipse.org

[Tom Schindl]

Looks like your cleanup at least allows one to post to mailing-lists.

See what I received today
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437644

Tom

On 18.06.14 10:33, John Arthorne wrote:
 I discovered I could not create a file in my home directory on
 build.eclipse.org this morning. I cleaned up most of my home to free
 some space, but please take a look at your home directory and see if you
 can free more space:
 
 nfsmaster:/home/data   1.7T  1.6T   41M 100%
 /home/data
 
 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

Re: [cross-project-issues-dev] Bugzilla email notification down?

[Tom Schindl]

I've been missing some bugzilla mails also in the last few weeks - e.g.
just today I saw that I missed e.g. the mail to this bug [1].

Tom

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=437327

On 16.06.14 22:05, Sven Efftinge wrote:
 Ok, thanks. Than that seems to be a problem with our mail server.
 
 Sven
 
 On 16 Jun 2014, at 19:22, Denis Roy denis@eclipse.org wrote:
 
 Sven, my logs show at least 53 emails sent to you in the last 13 hours and 
 20 minutes, all of which were successfully received by the remote mail 
 server.  Are you really expecting more than that (really!) or could it be 
 that you are not receiving them?

 Denis


 On 06/16/2014 11:57 AM, Sven Efftinge wrote:
 I’m definitely missing lots of mails.

 Sven

 On 16 Jun 2014, at 17:16, Webmaster(Matt Ward) webmas...@eclipse.org 
 wrote:

 I restarted the bugzilla job queue a while ago and notices seem to be fine.

 -Matt.

 On 06/16/2014 08:33 AM, Jan Koehnlein wrote:
 Hi,

 it seems like  Bugzilla no longer sends emails. Anybody else experiencing 
 this?

 Cheers
 Jan


 ___
 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 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] Bugzilla email notification down?

[Tom Schindl]

right - I also did not receive my comment on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437327 which i made
15minutes ago nor the ones on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437541

Tom

On 17.06.14 10:29, Jan Koehnlein wrote:
 Still no notifications here.
 
 Am 17.06.2014 um 10:15 schrieb Tom Schindl tom.schi...@bestsolution.at:
 
 I've been missing some bugzilla mails also in the last few weeks - e.g.
 just today I saw that I missed e.g. the mail to this bug [1].

 Tom

 [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=437327

 On 16.06.14 22:05, Sven Efftinge wrote:
 Ok, thanks. Than that seems to be a problem with our mail server.

 Sven

 On 16 Jun 2014, at 19:22, Denis Roy denis@eclipse.org wrote:

 Sven, my logs show at least 53 emails sent to you in the last 13 hours and 
 20 minutes, all of which were successfully received by the remote mail 
 server.  Are you really expecting more than that (really!) or could it be 
 that you are not receiving them?

 Denis


 On 06/16/2014 11:57 AM, Sven Efftinge wrote:
 I’m definitely missing lots of mails.

 Sven

 On 16 Jun 2014, at 17:16, Webmaster(Matt Ward) webmas...@eclipse.org 
 wrote:

 I restarted the bugzilla job queue a while ago and notices seem to be 
 fine.

 -Matt.

 On 06/16/2014 08:33 AM, Jan Koehnlein wrote:
 Hi,

 it seems like  Bugzilla no longer sends emails. Anybody else 
 experiencing this?

 Cheers
 Jan


 ___
 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 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. Jan Köhnlein
 Senior Software Architekt
 
 Mobile: +49 (0) 151 / 17396687
 Telefon: +49 (0) 431 / 99026870
 Fax: +49 (0) 431 / 99026872
 
 http://www.itemis.de
 jan.koehnl...@itemis.de
 
 
 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
 

___
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] Luna RC3 repository is available

[Tom Schindl]

Hi,

It looks like the RC3 repo is missing com.google.inject.source. I know
that i can not generally assume source-bundles are there but it has been
there since always but started missing today.

I have no problem fetching it from the orbit repo if you think it is OK
that it is missing.

Tom

On 06.06.14 16:03, David M Williams wrote:
 I've made the RC3 repository visible under the build-in repository at
 
 http://download.eclipse.org/releases/luna/
 
 The EPP packages will be available soon, if not already, from
 
 http://www.eclipse.org/downloads/index-developer.php
 
 Happy testing!
 
 
 
 ___
 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] Kepler SR3 for Java 8?

[Tom Schindl]

Why do you see this as a major regression?

There's no problem beside that using  java7 as compile target when you
use JRE8 in the project.

Tom

On 27.03.14 08:38, Mickael Istria wrote:
 On 03/27/2014 08:32 AM, Mickael Istria wrote:
 On 03/20/2014 03:50 PM, Konstantin Komissarchik wrote:

 I am wondering if we should do a limited SR release to pickup Java 8
 patches. As it stands, Eclipse users interested in Java 8 would have
 to hunt for and install at least two patches, which doesn’t paint
 Eclipse in a good light.

 This bug https://issues.jboss.org/browse/JBIDE-16902 makes that Java 8
 support introduces something that will be felt as a major regression
 for most users. So I'm -1 for making Java 8 support part of a
 generally available SR3 until it contains this bug.
 Sorry, bad link, the bug is
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=390889
 -- 
 Mickael Istria
 Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
 My blog http://mickaelistria.wordpress.com - My Tweets
 http://twitter.com/mickaelistria
 
 
 ___
 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] Is SSH access to Git down?

[Tom Schindl]

Reply i had the same problem - the password is stored in the Preferences
 General  Security  Secure Storage

I deleted the preference there, restarted and was asked for a password
the next time i tried to push and could enter my new password.

Tom

On 12.03.14 17:16, Konstantin Komissarchik wrote:
 To close the loop... see the bug that I opened on EGit and be careful
 with eclipse.org password changes and EGit until this issue is resolved.
 
  
 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=430210
 
  
 
 Thanks,
 
  
 
 - Konstantin
 
  
 
  
 
 *From:*cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of
 *Denis Roy
 *Sent:* Wednesday, March 12, 2014 7:59 AM
 *To:* cross-project-issues-dev@eclipse.org
 *Subject:* Re: [cross-project-issues-dev] Is SSH access to Git down?
 
  
 
 You triggered our firewalls for too many password authentication failures.
 
 They usually clear after a couple of minutes, but the blackout period
 extends if the auth failures persist.  I've checked, and at this time
 they seem to be cleared, but please let us know if the issues persist.
 
 Denis
 
 On 03/12/2014 10:46 AM, Konstantin Komissarchik wrote:
 
 I am getting connection timeout issues this morning when trying to push.
 
  
 
 - Konstantin
 
 
 
 
 ___
 
 cross-project-issues-dev mailing list
 
 cross-project-issues-dev@eclipse.org 
 mailto: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] Freemarker

[Tom Schindl]

Hi,

In e(fx)clipse we use Xtend to as a template language. One of the
strengths is that Xtends multi-line and indent support so it is made for
code generation (and much more).

Take a look at our Xtend templates:
-
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.pde.ui.e4/src/org/eclipse/fx/ide/pde/ui/e4/project/template
-
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.jdt.ui/src/org/eclipse/fx/ide/jdt/ui/internal/wizard/templates

You talked about wizards, project creation, ... so what we at
e(fx)clipse have is a language we call rrobot which is a DSL to specify
eclipse project creations e.g. this is our e4 project creation process
expressed in it:
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.pde.ui.e4/generator-tasks/e4App.rtask

We don't have an C/C++ support ;-)

Before going Jet or Freemarker I'd look at Xtend, it has the best
tooling with it you can get for a template language.

Tom


On 22.10.13 16:28, Doug Schaefer wrote:
 I got misled by it's web page: http://www.eclipse.org/xtend/. Java 10
 apparently :)
 
 I'll take another look for Jet. Thanks Paul.
 
 Doug
 
 From: Ed Willink e...@willink.me.uk mailto:e...@willink.me.uk
 Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org
 Date: Tuesday, 22 October, 2013 10:23 AM
 To: Cross project issues cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] Freemarker
 
 Hi Doug
 
 Xtend is many things, and so it is easy to get misled by today's hype.
 
 Xtend is not a Java language extension; it has many similarities but
 significant differences too; beauty is in the eye of the beholder.
 
 One of Xtend's really useful features is its triple quote operator that
 allows you to embed a text template within Java-ish code. Within the
 templates you can use guilemets to have inner control, so overall Xtend
 supports control within text within control; very powerful, and the
 whitespace tooling in the editor is good too.
 
 For text-intensive code I can strongly recommend Xtend. However you may
 choose to follow my example of keeping all non-text functionality in
 Java base classes so that you only use Xtend as a template language and
 plain Java for all other things.
 
 Regards
 
 Ed Willink
 
 On 22/10/2013 14:50, Doug Schaefer wrote:
 Xtend is a Java language extension, no? I'm talking about a template
 engine that we use in the new project wizard to instantiate code
 templates based on various user selectable options.

 I was originally thinking of Jet, but I can't seem to find it anymore.
 Whatever happened to it?

 Doug.

 From: Henrik Rentz-Reichert h...@protos.de mailto:h...@protos.de
 Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org
 Date: Tuesday, 22 October, 2013 2:43 AM
 To: Cross project issues cross-project-issues-dev@eclipse.org
 mailto:cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] Freemarker

 Doug,

 have you considered using Xtend?

 -Henrik

 Am 21.10.2013 21:47, schrieb Doug Schaefer:
 Has anyone tried to get Freemarker into Orbit? Or is there a better
 template engine that people are using. CDT has it's own but I'd like
 to use something more standard (and better).

 Thanks,
 Doug.



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



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


 No virus found in this message.
 Checked by AVG - www.avg.com http://www.avg.com
 Version: 2014.0.4158 / Virus Database: 3614/6769 - Release Date: 10/21/13

 
 
 
 ___
 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] Hudson is unable to publish builds

[Tom Schindl]

Hi,

Our nightly build started failing this night while publishing the
update-site because of whatever reason it is not possible for hudson to
delete the previous published file.

 [INFO] 
 
 [INFO] Total time: 4:15.118s
 [INFO] Finished at: Fri Sep 27 02:34:09 EDT 2013
 [INFO] Final Memory: 113M/1510M
 [INFO] 
 
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project 
 org.eclipse.fx.updatesite: An Ant BuildException has occured: Unable to 
 delete file 
 /home/data/httpd/download.eclipse.org/efxclipse/runtime-nightly/site.zip
 [DEBUG] Closing connection to remote
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project 
 org.eclipse.fx.updatesite: An Ant BuildException has occured: Unable to 
 delete file 
 /home/data/httpd/download.eclipse.org/efxclipse/runtime-nightly/site.zip - 
 [Help 1]
 [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/MojoExecutionException
 [ERROR] 
 [ERROR] After correcting the problems, you can resume the build with the 
 command
 [ERROR]   mvn goals -rf :org.eclipse.fx.updatesite
 [DEBUG] Waiting for process to finish
 [DEBUG] Result: 1

To me the permission look correct.

 drwxrwsr-x 3 tschindltechnology.efxclipse 4096 26. Sep 02:05 .
 drwxrwsr-x 5 tschindltechnology.efxclipse 4096 26. Sep 03:13 ..
 drwxrwsr-x 4 hudsonBuild technology.efxclipse 4096 26. Sep 02:05 site
 -rw-rw-r-- 1 hudsonBuild technology.efxclipse 47319294 26. Sep 02:05 
 site_assembly.zip
 -rw-rw-r-- 1 hudsonBuild technology.efxclipse  334 26. Sep 02:05 site.zip
 tschindl@build:~/downloads/efxclipse/runtime-nightly 

Anybody else having trouble publishing builds since last night?

Tom
___
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 is unable to publish builds

[Tom Schindl]

Hi,

But did something changed lately? This has been working for weeks and
started failing just this night? It's working again, thanks.

Tom

On 27.09.13 15:03, Denis Roy wrote:
 To be able to delete a file, the hudsonBuild user needs to have w
 permissions on own the parent directory (rm'ing a file is effectively
 changing the contents of the directory).  I've made hudsonBuild the
 owner of your downloads area since it's not as nasty as rwxrwxrwx
 permissions.
 
 Denis
 
 
 On 09/27/2013 02:41 AM, Tom Schindl wrote:
 Hi,

 Our nightly build started failing this night while publishing the
 update-site because of whatever reason it is not possible for hudson to
 delete the previous published file.

 [INFO] 
 
 [INFO] Total time: 4:15.118s
 [INFO] Finished at: Fri Sep 27 02:34:09 EDT 2013
 [INFO] Final Memory: 113M/1510M
 [INFO] 
 
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with 
 exception(s)
 [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on 
 project org.eclipse.fx.updatesite: An Ant BuildException has occured: 
 Unable to delete file 
 /home/data/httpd/download.eclipse.org/efxclipse/runtime-nightly/site.zip
 [DEBUG] Closing connection to remote
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-antrun-plugin:1.3:run (deploy) on project 
 org.eclipse.fx.updatesite: An Ant BuildException has occured: Unable to 
 delete file 
 /home/data/httpd/download.eclipse.org/efxclipse/runtime-nightly/site.zip - 
 [Help 1]
 [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/MojoExecutionException
 [ERROR] 
 [ERROR] After correcting the problems, you can resume the build with the 
 command
 [ERROR]   mvn goals -rf :org.eclipse.fx.updatesite
 [DEBUG] Waiting for process to finish
 [DEBUG] Result: 1
 To me the permission look correct.

 drwxrwsr-x 3 tschindltechnology.efxclipse 4096 26. Sep 02:05 .
 drwxrwsr-x 5 tschindltechnology.efxclipse 4096 26. Sep 03:13 ..
 drwxrwsr-x 4 hudsonBuild technology.efxclipse 4096 26. Sep 02:05 site
 -rw-rw-r-- 1 hudsonBuild technology.efxclipse 47319294 26. Sep 02:05 
 site_assembly.zip
 -rw-rw-r-- 1 hudsonBuild technology.efxclipse  334 26. Sep 02:05 
 site.zip
 tschindl@build:~/downloads/efxclipse/runtime-nightly 
 Anybody else having trouble publishing builds since last night?

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

 
 -- 
 *Denis Roy*
 Director, IT Services
 Eclipse Foundation, Inc. -- http://www.eclipse.org/
 Office: 613.224.9461 x224 (Eastern time)
 denis@eclipse.org
 @droy_eclipse
 
 
 ___
 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] Build.eclipse.org back online

[Tom Schindl]

e(fx)clipse build fails as well when publishing because the download dir does 
not exist!

Tom

Von meinem iPhone gesendet

Am 07.09.2013 um 19:51 schrieb Eike Stepper step...@esc-net.de:

 Am 07.09.2013 17:40, schrieb Denis Roy:
 The upgrades to build.eclipse.org have been completed.  You may need to 
 restart any jobs that were running at the time
 of the shutdown.
 
 Where are the downloads gone?
 
 estepper@build:/home/data/httpd/download.eclipse.org ll
 total 0
 
 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
___
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] Anyone beside me seeing hudson-slave2 failing since yesterday night with

[Tom Schindl]

 Started by timer
 Building remotely on hudson-slave2
 Checkout:efxclipse-runtime-1.x-nightly / 
 /opt/buildhomes/hudsonBuild/workspace/efxclipse-runtime-1.x-nightly - 
 hudson.remoting.Channel@51fe358a:hudson-slave2
 Using strategy: Default
 Last Built Revision: Revision b4f1a14c19a7a61bf1ce00ee2f4f4d46f17e60d7 
 (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)

___
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] [nebula-dev] Nebula Grid is available from Kepler update site

[Tom Schindl]

2. Nebula apparently has not produced a 1.0 release despite a successful
1.0 release and graduation review almost a year ago (2012-09-12). The
dashboard lists the 1.0 release on 2012-09-21. Could someone from Nebula
address what happened? This is hardly the proper way for a project
deserving of the mature label to behave.


We didn't do a 1.0.0 release. We did a restructuring as outlined in 
http://wiki.eclipse.org/Nebula/restructure#Nebula_Project_Restructuring_Proposal 
which is linked from 
http://projects.eclipse.org/content/1.0.0-release-review-28.


I really don't know why this is marked as a Release 1.0.0. So I think 
the problematic information is coming from the Eclipse.org Database and 
we (Nebula) are unable to fix this ourselves.


Tom

___
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] [nebula-dev] Nebula Grid is available from Kepler update site

[Tom Schindl]

We have not yet done any release at nebula! We have split the project, into an 
incubator and to-be-released components but did not yet finish it!

Tom

Von meinem iPhone gesendet

Am 28.06.2013 um 23:53 schrieb Konstantin Komissarchik 
konstantin.komissarc...@oracle.com:

 An official release (as defined by EDP) of an incubating project can be 
 contributed, such as a 0.7 of something, but not a pre-release build.
  
 Note that this distinction doesn’t apply to Nebula Grid, since Nebula has 
 graduated from incubation status and made a 1.0 release back in 2012, so the 
 only question is whether the bundles actually correspond to Nebula’s 1.0 
 release.
  
 - Konstantin
  
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
 Christian
 Sent: Friday, June 28, 2013 2:19 PM
 To: Cross project issues
 Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
 from Kepler update site
  
 to my knowledge a project can also contribute components that are still in 
 incubator and havnt done a release yet. I am sure we asked that in the past. 
 (EMO)
  
 We also distributed Nebula CompositeTable in the past for a number of years 
 and now we include the Nebula Grid.
  
 So I disagree with there should not be any pre-release bundle in the release 
 train repo.  
  
 christian
  
 Von: Konstantin Komissarchik konstantin.komissarc...@oracle.com
 Antworten an: Cross issues cross-project-issues-dev@eclipse.org
 Datum: Freitag, 28. Juni 2013 22:58
 An: Cross issues cross-project-issues-dev@eclipse.org
 Cc: 'Nebula Dev' nebula-...@eclipse.org
 Betreff: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
 from Kepler update site
  
 Does the version of nebular.widgets.grid in Kepler correspond to a Nebula 
 release (not a pre-release build)?
  
 If it does corresponds to a release, there is nothing wrong here. A project 
 can contribute its dependencies to the release train aggregation even if 
 those dependencies aren’t part of the release train.
  
 If it doesn’t correspond to a release, then there is a serious problem as 
 there shouldn’t be any pre-release bundles in Kepler.
  
 I notice that Nebula is using 1.0.0.HEAD versioning for the bundle and it 
 seems that the version doesn’t change from build to build. This is very wrong 
 and may make answering the above question rather difficult. Nebula should 
 work to fix the build ASAP.
  
 Thanks,
  
 - Konstantin
  
  
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
 Christian
 Sent: Friday, June 28, 2013 1:43 PM
 To: Cross project issues
 Cc: Nebula Dev; Cross project issues
 Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
 from Kepler update site
  
 Hi,
  
 Yes riena uses the nebula gid widget and because of that we distribute it in 
 our p2 repo. 
  
 Whats wrong with that ?
 
 Gruesse
  
 Christian
 
 Am 28.06.2013 um 15:25 schrieb Oberhuber, Martin 
 martin.oberhu...@windriver.com:
 
 Hi Tom,
  
 I can confirm it’s riena:
  
 $ ssh build.eclipse.org
 $ cd /home/data/httpd/download.eclipse.org/releases/kepler/201306260900
 $ unzip -p content.jar | grep -B 50 'require.*nebula.widgets.grid' | egrep 
 'unit|nebula.widgets.grid'
  
 unit id='org.eclipse.riena.ui.ridgets.swt.optional' 
 version='5.0.0.v20130605_5_0_0_0'
 required namespace='osgi.bundle' 
 name='org.eclipse.nebula.widgets.grid' range='1.0.0'/
 /unit
 unit id='org.eclipse.riena.tests' version='5.0.0.v20130605_5_0_0_0'
 required namespace='osgi.bundle' 
 name='org.eclipse.nebula.widgets.grid' range='0.0.0'/
 required namespace='org.eclipse.equinox.p2.iu' name='org.junit' 
 range='[4.10.0.v20120426-0900,4.10.0.v20120426-0900]'/
 required namespace='org.eclipse.equinox.p2.iu' 
 name='org.eclipse.nebula.widgets.grid' range='[1.0.0.HEAD,1.0.0.HEAD]'/
 /unit
 unit id='org.eclipse.riena.example.client.optional' 
 version='5.0.0.v20130605_5_0_0_0'
 required namespace='osgi.bundle' 
 name='org.eclipse.nebula.widgets.grid' range='1.0.0'/
  
 I don’t know from what repository riena (or the aggregator) pulls in the odd 
 version.
  
 Thanks,
 Martin
 --
 Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
 direct +43.662.457915.85  fax +43.662.457915.6
  
  
 -Original Message-
 From: cross-project-issues-dev-boun...@eclipse.org 
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Tom Schindl
 Sent: Friday, June 28, 2013 3:08 PM
 To: Nebula Dev
 Cc: Cross project issues
 Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
 from Kepler update site
  
 Wild guess is that one of the release train projects uses it - IIRC riena 
 used to use it.
  
 Tom
  
 On 28.06.13 13:51, Wim Jongman wrote:
  Hi,
  
  Apparently the Nebula Grid widget is available from

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

[Tom Schindl]

Wild guess is that one of the release train projects uses it - IIRC 
riena used to use it.


Tom

On 28.06.13 13:51, Wim Jongman wrote:

Hi,

Apparently the Nebula Grid widget is available from the Kepler Update
site. This should not be the case.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=411867

Regards,

Wim


___
nebula-dev mailing list
nebula-...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/nebula-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] Kepler is GO!

[Tom Schindl]

Now this repo misses at least 
org.eclipse.ecf.provider.filetransfer.httpclient which was in the repo 
at this location at least until yesterday!


Tom

On 26.06.13 15:08, David M Williams wrote:

I have turned on the common release update site, at

http://download.eclipse.org/releases/kepler/

Thanks to all committers, contributors, and users who made this release
possible ... and a special thanks to all the expert support from the
Eclipse Foundation staff for helping us at every step of the way.





From: Denis Roy denis@eclipse.org
To: cross-project-issues-dev@eclipse.org,
Date: 06/26/2013 09:01 AM
Subject: [cross-project-issues-dev] Kepler is GO!
Sent by: cross-project-issues-dev-boun...@eclipse.org




Greetings,

I've checked my list twice... looks like mirrors are all populated with
the packages.  We've got an extra 500 Mbps of bandwidth on tap.  We're
GO for Kepler!

Please feel free to make your bits available to your eagerly awaiting
users.  The main Downloads page will be updated shortly.
_
__http://wiki.eclipse.org/Kepler/Final_Daze#08:30_EDT_

Congratulations to all!  For those in Ottawa, we'll see you at the Big
Rig at 1:00pm!

Denis
___
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] Kepler is GO!

[Tom Schindl]

Hi David,

I'm just an ordinary plugin/rcp developer and run my builds against the 
p2 repo ;-)


Like you said one can get around this problem by simply adding the 
ecf-p2 repo. I justed wanted to give a short notice that something is 
missing.


In the end I think we need to investigate why some ecf stuff is missing 
from time to time


Tom

On 26.06.13 16:11, David M Williams wrote:

Tsk. Tsk. Tsk.  sounds like you didn't test 'staging'.  Until today,
/releases/kepler was a composite with 3 RCs, but not RC4, which was only
at /releases/staging. Which is what people were asked to test against.
  And now /releases/kepler is just one repo (RC4 aka staging). The other
RCs have been disconnected from composite and will be removed soon.

Sincerely sorry for the last minute change in an earlier RC, but ... I
know others who missed it being at ../releases/staging and they were
able to adjust. If you need help recovering, open a cross-project bug
and I'll give what advise I can. You likely just have to get from ECF
repo, if you can't move to httpclient4. (And, FYI, this is why we
suggest that projects include what you need, don't count on someone
else providing it coincidentally). I'm not sure if you are talking from
the point of view a release-train participant, or someone who just
happened to be using it as a convenient source of everything?

Thanks,




From: Tom Schindl tom.schi...@bestsolution.at
To: cross-project-issues-dev@eclipse.org, ecf-...@eclipse.org,
Date: 06/26/2013 09:54 AM
Subject: Re: [cross-project-issues-dev] Kepler is GO!
Sent by: cross-project-issues-dev-boun...@eclipse.org




Now this repo misses at least
org.eclipse.ecf.provider.filetransfer.httpclient which was in the repo
at this location at least until yesterday!

Tom

On 26.06.13 15:08, David M Williams wrote:
  I have turned on the common release update site, at
 
  http://download.eclipse.org/releases/kepler/
 
  Thanks to all committers, contributors, and users who made this release
  possible ... and a special thanks to all the expert support from the
  Eclipse Foundation staff for helping us at every step of the way.
 
 
 
 
 
  From: Denis Roy denis@eclipse.org
  To: cross-project-issues-dev@eclipse.org,
  Date: 06/26/2013 09:01 AM
  Subject: [cross-project-issues-dev] Kepler is GO!
  Sent by: cross-project-issues-dev-boun...@eclipse.org
  
 
 
 
  Greetings,
 
  I've checked my list twice... looks like mirrors are all populated with
  the packages.  We've got an extra 500 Mbps of bandwidth on tap.  We're
  GO for Kepler!
 
  Please feel free to make your bits available to your eagerly awaiting
  users.  The main Downloads page will be updated shortly.
  _
  __http://wiki.eclipse.org/Kepler/Final_Daze#08:30_EDT_
 
  Congratulations to all!  For those in Ottawa, we'll see you at the Big
  Rig at 1:00pm!
 
  Denis
  ___
  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 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