[cross-project-issues-dev] status of the help center

[Stephan Herrmann via cross-project-issues-dev]

Will https://help.eclipse.org be updated with content for 2024-03?

If so, also https://www.eclipse.org/documentation/ needs a refresh (already one 
release behind).


Also I'd like to know the schedule of such update, because a N entry of mine 
(web version) wants to link into javadoc that should eventually be available 
from the help center. This means it would be nice, if the link can be set 
*before* the release.


Bonus question: I seem to recall that there was generic syntax so that the same 
content works within help in the IDE as well as in the web version. Anyone know? 
Or am I dreaming? :)


thanks
Stephan
___
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] CVS support plugin discontinuation - SimRel build changes needed

[Stephan Herrmann]

I don't think the major-minor discussion (interesting as it may be) is of any 
relevance here, because:

* The only grace period I could find concerns API removal and that is
  not controlled by number of releases but by number of years [1]
* The code change in question didn't touch any true API.

Just for the sake of entertainment:
* The broken client is not by some alien author but by the Eclipse
  Project itself, so when the Eclipse Project justifies the breakage
  by saying: "they should never have referred to this internal class",
  this blame ("they") points to the Eclipse Project itself :)

Perhaps the following observation is more relevant:
* The "breaking" code change did not fix an existing problem [2]
  (Still anybody believing in "risk-free" changes?)

just saying,
Stephan


[1] 
https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#api-removal-process


[2] 
https://github.com/eclipse-platform/eclipse.platform.team/issues/29#issuecomment-1370147771


Am 03.01.23 um 15:56 schrieb Alexander Fedorov:

Hello,

Great discussion.

 > Removal in January 2022 for upcoming 4.23, 2 major releases later
 > Breakage found January 2023 on 4.26, 3 major releases later

Formally, the 4.x releases on the page 
https://projects.eclipse.org/projects/eclipse are all marked as "Minor Release".
How did they become "major"? If they are "major" without incrementing "major" 
segment, then who are "minor"? What about PDE API tools?


Regards,
AF

1/3/2023 5:45 PM, Andrey Loskutov пишет:

Ed,
you still can use CVS plugins with 4.25 platform.
For the rest: there is no "free beer" anymore in platform.
"Спасение утопающих - дело рук самих утопающих".
If you (or anyone else) want / need CVS (or XYZ) being supported by platform, 
please consider to contribute to the CVS (XYZ) plugin maintenance.
Eclipse platform is open source project and everyone can spend time or money 
to improve on some aspect of it.
But one can't expect from the platform project to support every released piece 
of software "for free" forever.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Dienstag, 03. Januar 2023 um 15:32 Uhr
*Von:* "Ed Willink" 
*An:* "Cross project issues" 
*Betreff:* Re: [cross-project-issues-dev] CVS support plugin discontinuation - 
SimRel build changes needed


Hi

4.21 to 4.23 is two minor releases and only six months; nothing in terms of a 
transition period.


It takes a change to 6.x to be two major releases.

    Regards

        Ed Willink

On 03/01/2023 14:24, Mickael Istria wrote:

On Tue, Jan 3, 2023 at 3:12 PM Ed Willink  wrote:

I thought that Open Source was friendly; not a facilitator for a
proprietary business case.

Well, sometimes allowing contributors to make money from their work is
actually one way to try being friendly.
But indeed, if one wants to do that work for free, that's even friendlier.

My understanding of the disciplined deprecation was that two major
releases were required after an announcement, but since e6 is impossibly
distant the platform has taken to breakage in minor versions.
Nonetheless I would expect two releases on the yearly cadence so
breakage within 18 months seems very wrong and to merit a regression 
fix.

Deprecation announced in September 2021 (4.21)
Removal in January 2022 for upcoming 4.23, 2 major releases later
Breakage found January 2023 on 4.26, 3 major releases later
The cadence is described at https://projects.eclipse.org/projects/eclipse
Ultimately, there is a clear law of software development: unmaintained
software that no-one builds or updates against newer version of its
dependencies will die; only software that someone maintains actively
survives. It's not a matter of process here, but a matter of interest in
maintaining it. If some money can be found to boost interest from someone
in maintaining here, then we all win.

___ cross-project-issues-dev 
mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this 
list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
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] Sorry, entering a bug into the product JDT has been disabled.,

[Stephan Herrmann]

On 17.04.22 12:46, Ed Merks wrote:

The message could be improved by redirecting here:

https://github.com/eclipse-jdt#reporting-issues

It sounds like the PMI needs attention too...


see https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1186

Anybody with a bookmark on bugs.eclipse.org or even 
https://bugs.eclipse.org/bugs/enter_bug.cgi will simply learn that JDT is no 
longer accepting bug reports. End of story. I thought open source development is 
all about communication. Never too old to learn better. I'm glad I no longer 
feel responsible for any of this, otherwise I'd have trouble avoiding any bad 
words ...


Stephan




On 17.04.2022 12:43, Ed Willink wrote:

Hi

The PMI form for JDT at

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT

is no longer able to report a bug. It reports "Sorry, entering a bug into the 
product JDT has been disabled.,,Please press Back and try again."


Does this mean that JDT is now perfect and will never have any bugs ever again?

    Regards

        Ed Willink



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Stephan Herrmann]

Let me add a general word of caution:

Your intentions to show solidarity with Ukraine totally make sense - from a 
German point of view, from a western point of view.


I'd much hope this would be the unamimous position, but we shouldn't presume so 
in our global community.


In our community we do have members with Russian background. While I hope to 
have them on "our" side, we shouldn't take it for granted.


Moreover, I just learned [1] that India is among the countries trying to remain 
neutral in this conflict. With the central role particularly of the 
Bangalore-based team, we shouldn't be too sure about any consensus. Not without 
speaking to them.


This is a discussion to be had right now, and we should be grateful for having 
these contacts into many parts of the world. But I don't think, that a public 
mailing list is the best channel for this. The issue is probably too complex to 
be settled on this list and within a short time frame.


Maybe I'm over-cautious, but we should be mindful with our colleagues and 
friends in our global community.


best regards,
Stephan

[1] 
https://en.wikipedia.org/wiki/2022_Russian_invasion_of_Ukraine#United_Nations

On 01.03.22 13:28, jkubitz-ecli...@gmx.de wrote:

Dear fellow eclipse contributors,

Russian invaded Ukraine. As a response international sanctions taken place.

Sanctions are not only done by governments but also by sports, business 
corporations and individuals. I ask eclipse foundation to join sanctions:


Please assist all efforts to stop that war by supporting the export control of 
key technologies.


In special Russia and China are trying to get independent from foreign computers 
by developing domestic hardware platforms “Elbrus” [1] and “LongArch” [2]. Those 
would bypassing hardware export control [3]. But hardware is not enough. They 
also need software. And that is where eclipse comes into play. Unless we 
explicitly support such hardware platform our software won’t run on domestic 
hardware [4].


I do not like that the world is getting separated. It should be free and united. 
We need to send a signal that open software is not used to suppress people.


Jörg Kubitz

[1] https://en.wikipedia.org/wiki/Elbrus_2000 



[2] https://en.wikipedia.org/wiki/Loongson 


[3] 
https://www.reuters.com/technology/taiwans-tsmc-says-comply-with-export-control-rules-russia-2022-02-25/ 



[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=578951 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] git rollback?

[Stephan Herrmann]

I think affected teams should now safe guard all clones on individual 
machines, and wait until the IT team signals that systems are back to 
stable, really.


At that time we may need to re-push lost commits from our local clones. 
Perhaps even some lost tags are available from local clones.


For that task of re-pushing, teams may need to coordinate, which commits 
in which order need to be re-played. A good indicator is the "Tested-by" 
line in commit messages, which signals a commit that has once gone 
through the gerrit exercise and thus should be seen as part of the 
"official" history. A bugzilla query for recently resolved bugs would be 
helpful - if bugzilla queries are reliable again.


For now, waiting and not pushing anything seems to be the best strategy, 
right?


Stephan

On 04.08.21 08:38, Ed Willink wrote:


Hi Sravan

In the absence of any clues from the IT team can you please identify 
the time to which GIT / downloads have been rolled back so that we can 
all be aware of what is, at least currently, lost at the EF.


    Regards

        Ed Willink

On 04/08/2021 06:36, Sravan K Lakkimsetti wrote:


Platform I-build from July 31(last successful build for platform) has 
gone missing 
https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/ 
<https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/> also 
related git tags gone missing from the repository.


Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, C Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India

Inactive hide details for "Ed Willink" ---04-08-2021 10:00:35---Hi 
Same for OCL."Ed Willink" ---04-08-2021 10:00:35---Hi Same for OCL.


From: "Ed Willink" 
To: cross-project-issues-dev@eclipse.org
Date: 04-08-2021 10:00
Subject: [EXTERNAL] Re: [cross-project-issues-dev] git rollback?
Sent by: "cross-project-issues-dev" 







Hi

Same for OCL.

I pushed a branch commit that successfully refreshed everything on 
the branch with the result that the IT team now need to resolve a 
merge of the rolled back copy, the incremental backed up history and 
the post 'no-outage' changes.


    Regards

        Ed Willink

On 04/08/2021 02:34, Jonah Graham wrote:


On Tue, 3 Aug 2021 at 18:25, Stephan Herrmann
<_stephan.herrmann@berlin.de_
<mailto:stephan.herrm...@berlin.de>> wrote:
Has the jdt.core git been rolled back? 
I don't know - it certainly looks like it. AFAIK the git URL

links you posted are mirrors of the gerrit repos. The gerrit
repos are the primary IIUC. In gerrit the referenced review is
still active -
_https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569_
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569> - so
it looks like gerrit took a step backwards, rather than just git
by itself. For the latter commit, the gerrit entry is "broken"
_https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573_
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573>
Locally pulling doesn't provide anything newer than 2021-07-26. 
Same for me.


Is this an effect of the recent incident? 
Probably, but I don't know. @Webmaster will have to comment.


Any other project seeing similar effects? 
Yes. CDT has at least one gerrit from July 31st that has lost a

patchset and associated comments. I have them in my email, but
they are missing from gerrit:

_https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568_
<https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568>

The metadata in the email is below, and there is no such comment
in the gerrit:

Gerrit-Project: cdt/org.eclipse.cdt
Gerrit-Branch: master
Gerrit-Change-Id: I96589e86bee561aa200a4a4487549305765d6409
Gerrit-Change-Number: 183568
Gerrit-PatchSet: 4
Gerrit-Owner: Mat Booth <_mat.booth@gmail.com_
<mailto:mat.bo...@gmail.com>>
Gerrit-Reviewer: CDT Bot <_cdt-bot@eclipse.org_
<mailto:cdt-...@eclipse.org>>
Gerrit-Comment-Date: Sat, 31 Jul 2021 20:04:45 +

You can also see evidence of the mismatch in CDT's build jobs.

_https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/_
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/> 
and
_https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/_
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/> 
both
built PS4, but 3450 built the now lost patchset, so the sha1 for
the same ref is different:

image.png


HTH,
Jonah


Stephan
___
cross-project-issues-dev mailing lis

[cross-project-issues-dev] git rollback?

[Stephan Herrmann]

Has the jdt.core git been rolled back?

On https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/log/ I see master at
https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=0bfd2bfeaa2c2165c0cebe570d6bfdb416aff602 
(from 2021-07-26).


But at least two bugs have commits later than that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=574803
-> 
https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=bb441d25c94b5c0cef092b72a93035296af4aff9

https://bugs.eclipse.org/bugs/show_bug.cgi?id=574882
-> 
https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=17232d45e7813c57f73ef1df28a519815a01a17a


I noticed this when submitting a change failed, where the new change was based 
on what was master on 2021-07-31. If that master is gone, we're in trouble.


Locally pulling doesn't provide anything newer than 2021-07-26.

Is this an effect of the recent incident?

Any other project seeing similar effects?

Stephan
___
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] [cbi-dev] Building SimRel with Tycho for 2021-03

[Stephan Herrmann]

I won't comment on the case of SimRel, as I no longer have any stakes in it, but 
let me remind you:


If the goal is to retire the CBI aggregator, then the migration is not done 
before also the tool chain for publishing Eclipse artifacts to Maven Central is 
re-written, too.


Just saying,
Stephan

On 26.11.20 20:57, Frederic Gurr wrote:

Hi,

Thanks Mickael for pushing this and sorry for the late reply!

I've started to look at your changes and have a few questions:

* is there a good reason why the pom.xml has been moved to a module
instead of keeping it in the root pom.xml/directory?

* can you give some insight what "remove-xz" and "add-aliens" do or why
they are necessary?

* how did you create the category.xml file? (side note: I opened the
category.xml file with the category.xml-editor and the opening alone
re-wrote/re-formated the whole file.)

* According to the comment, the list of repositories in the pom.xml file
was generated with the CBI aggregator tool. Was that only necessary for
the initial list? What would a new project need to add and where? Only
add bundle/feature to the category.xml and add the repository to the
pom.xml?

* is there still a way to only validate changes like the "validate" profile?

If we want to switch to Tycho for the 2020-03 release, we will need to
put some documentation in place for existing and new users what needs to
be changed and done.

Regards,

Fred

On 10.11.20 16:43, Mickael Istria wrote:

Hi all,

With a recent patch, Tycho has achieved a major milestone that allows it
to be a viable replacement to build SimRel repo in place of the very
specific CBI aggregator. Specifically, Tycho now can validate a build
plan without downloading all artifacts, so it can allow the Gerrit
patch/CI feedback short feedback loop.

The principle and benefits of this change consists in getting rid of CBI
aggregator specific files, models, builders... which no-one beyond a few
privileged (?) ones know how to deal with. By moving it to more
mainstream and better known Maven+Tycho+category.xml stack, we allow
more people to participate in the maintenance of the SimRel aggregation;
and we also get rid of one brick to maintain (CBI aggregator) in favor
of a well maintained and active one (Tycho). This will overall result in
some resources saving and SimRel entry-barrier being much lowered.
Of course, there are some features of CBI aggregator that don't have
equivalent in Tycho, and the other way round; sending emails for example
wouldn't be available anymore. But times have changed since the
introduction of CBI aggregator (called b3 back then): CI rose, Code
Review rose, all this DevOps things basically matured and has brought
solutions for the use-case that were directly supported by b3. Not so
objectively, I don't know of any feature of CBI aggregator for SimRel
build that we would really miss when moving to Tycho. I don't the
replacement this will either increase difficulty of contributing to
SimRel or to maintain it.

This Gerrit patch shows it in action
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553 .
You see it adds 1 category.xml file with the content of SimRel, and the
list of p2 repositories in the pom.xml.

I think all that stack is mature enough, and the value/savings in
changing to Tycho is compelling enough to consider this migration for
2021-03.

Cheers,
--
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 

___
cbi-dev mailing list
cbi-...@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cbi-dev





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Simultaneous Release Page 2020-09

[Stephan Herrmann]

Object Teams will no longer participate in Simrel, but release on its own 
schedule moving forward.


I have already removed objectteams.aggrcon early in the cycle [1].

Please remove it from your list.

thanks,
Stephan

[1] 
https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=2f15768281d0f2b9f96ceea9fc351b48549c6e4f


On 27.08.20 20:50, Wayne Beaton wrote:
I've created the tracking page for 2020-09 
. Please have a look to ensure 
that I've correctly recorded your project's participation correctly.


In particular, please make sure that I have the version right. If I've made a 
mistake... please first make sure that you've created a release record for the 
right version and then let me know to update the tracking page to point to that 
version.


If you are contributing a new major or minor release and have not engaged in a 
release review since September 16/2019, then you need to submit your IP Log and 
connect with EMO ASAP to initiate the release review process. Note that you only 
need to submit your IP Log for review if you are required to engage in a release 
review. There's more information in the handbook 
.


Based on messages on this list, both Eclipse Corrosion, Eclipse EMFStore, and 
Eclipse Tools for Cloud Foundry (CFT) have dropped out, so they've been removed 
from the list.


*AFAICT, the corrosion.aggrcon file still exists and is not disabled.* Also, 
since CFT has dropped out, its aggrcon file should also be removed (not just 
disabled). Can somebody take care of that, please?


Thanks for all your efforts.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - 
October 20-22



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Commits Fail to Find ECA

[Stephan Herrmann]

My ECA seems to be gone, too (according to accounts.eclipse.org).

Stephan

On 22.08.20 13:16, Matthias Sohn wrote:
On Sat, Aug 22, 2020 at 10:04 AM Ed Merks > wrote:


I have this failure trying to commit:

Repository ssh://eme...@git.eclipse.org:29418/emf/org.eclipse.emf


commit fb27b26: An Eclipse Contributor Agreement is required.
Processing changes: refs: 1
Processing changes: refs: 1, done
commit fb27b26: --
commit fb27b26: Reviewing commit: fb27b260
commit fb27b26: Authored by: Ed Merks mailto:ed.me...@gmail.com>>
commit fb27b26:
ERROR: commit fb27b26: The author does not have a current Eclipse
Contributor Agreement (ECA) on file.
If there are multiple commits, please ensure that each author has
a ECA.
commit fb27b26:
commit fb27b26: Please see http://wiki.eclipse.org/ECA

So perhaps the bugzilla problem is more widespread and ECAs are not
found in general.


checking your ECA via the ECA validation in the portal also fails.
For myself the ECA validation succeeds.



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org

To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
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] 2020-06 Release

[Stephan Herrmann]

Object Teams will ship the service release 2.8.1:
https://projects.eclipse.org/projects/tools.objectteams/releases/2.8.1-2020-06

thanks,
Stephan

On 20.05.20 17:59, Wayne Beaton wrote:

Hey folks!

I've created the record for the 2020-06 Simultaneous Release 
. As usual, I've used the 
information that I have available to make my best guess at which version you're 
releasing. If I've got something wrong, please first make sure that you've 
created a release record with the right date and then let me know to update the 
corresponding entry on the release page.


I noticed that several of the contributions are more than one year old (some of 
them significantly more). I don't believe that it's necessarily wrong to 
contribute stable content, but would like to make sure that somebody is 
periodically testing configurations that include these contributions to mitigate 
the risk that we ship broken content.


Eclipse Tools for Cloud Foundry (2018)
Eclipse BIRT (2017)
Eclipse Mylyn (2018)
Eclipse WindowBuilder (early 2019)
Eclipse Xpand (2016)
Eclipse Remote Systems Explorer (2018)
Eclipse EMFStore (2017)
Eclipse BPMN2 Model (2018)
Eclipse BPEL Designer (2018)
Eclipse ACTF (2017)

Wayne





--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - 
October 20-22



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] simrel.runaggregator.pipeline disabled

[Stephan Herrmann]

I see the pipeline [1] disabled.
Is this on purpose?

Stephan

[1] https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] weird MPC versions causing grief

[Stephan Herrmann]

We've been getting some desperate bug reports about failing installations, all 
mentioning that mpc artifacts cannot be found. This already happened with 
version 1.7.7 but today I found some weirdness regarding version 1.8.1:


Eclipse fails to update saying:
No repository found containing: 
osgi.bundle,org.eclipse.epp.mpc.core,1.8.1.v20191107-0507
No repository found containing: 
osgi.bundle,org.eclipse.epp.mpc.ui,1.8.1.v20191119-1757
No repository found containing: 
org.eclipse.update.feature,org.eclipse.epp.mpc,1.8.1.v20191119-1757


but the published version is actually 1.8.1.v20191106-1317 for all of the above.

How did the above versions leak to users, and what can they do to fix their 
updating?


Stephan

https://bugs.eclipse.org/bugs/show_bug.cgi?id=548197
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551641
https://bugs.eclipse.org/bugs/show_bug.cgi?id=560062
https://bugs.eclipse.org/bugs/show_bug.cgi?id=560006 (with duplicate)
___
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] [WARNING] SimRel Headed Off the Tracks

[Stephan Herrmann]

On 30.01.20 13:58, Ed Merks wrote:

On 30.01.2020 11:53, Aleksandar Kurtakov wrote:
Well, focus on "what" is quite important as I still haven't seen anywhere 
written what exactly is needed for the "who" decides to take EPP. There won't 
be any "who" until "what" is clearly defined.


That is indeed a good point.  :-)

Markus didn't announce here despite being prompted, and while I'm sure he's 
documented what exactly he does, even I don't know exactly what that is.  I 
don't expect it's all that onerous.  In any case, in this thread you can see 
that he's offered to walk someone through the steps:


   https://www.eclipse.org/lists/epp-dev/msg05676.html


Looking from a distance I wonder:

* Is building "the packages" an effort X multiplied by the number of packages?

* What's the difference between downloading a package and installing the
  equivalent software via the installer?
  - After installation, are there any user-observable differences?
  - What is the effort of maintaining the corresponding Oomph setups?
  - What exactly would we loose if installer would be the only download option?

Stephan


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Stephan Herrmann]

Thanks, Ed, for raising these concerns.

The thread is already at a volume which makes it hard to digest, I can only hope 
I got the essence of what everybody is thinking.



One way I could interpret the situation is: It takes a very small number of 
qualified people to herd the train - full-time, and then the immediate issue is 
resolved. There are member companies for whom it should not be a problem to fund 
the one appointed train master - perhaps via the foundation. I'd love to see 
Ed's efforts to be compensated in a way which would allow him to give us a long 
term perspective. I don't represent a member company so I can't comment on 
whether and how this simple idea could be put to action.



I assume all of us subscribed to cross-projects have a shared interest in 
providing to our users plenty of options of which software they want to install, 
in various combinations, and all in the latest and greatest version. Without bad 
surprises on their way.
Please, those who want to do away with SimRel: tell me, what efforts are 
incurred by SimRel that or not essential for this original goal? If SimRel 
incurs non-essential efforts, produces accidental complexity, shouldn't we just 
name these, so we can fix things (process? automation?). (Disclaimer: I don't 
care about packages because a simrel repo + various oomph setups are all I need 
to get the Eclipses I want, or to push the same to colleagues in the company). 
(Disclaimer 2: I don't hate the cbi aggregator, I prefer to fix it when there's 
a problem).



For a thought experiment wrt the release cadence: is it possible our cadence is 
still too slow? Imagine a truly continuous SimRel. Perhaps, SimRel contributions 
should happen *always*, i.e., whenever a project has any code changes, or 
buffered to once per day. Some contributions will break downstream projects, 
which have the option to react, or drop out after 3 build failures. If your 
dependency drops out, you will notice immediately. Some version bumps, 
dependency changes will need coordination, here on cross-projects, but they will 
just happen at their own timing, not driven by release dates. In a world where 
so many tasks can be automated, isn't the continues flow of all seeing each 
others HEAD the simplest model of all?


In this model, SimRel (or should we call it SimFlow) would concentrate on 
ensuring that our components stay on track wrt compatibility with each other. 
The other concern about more regressions due to shorter cycles and no 
maintenance branch would still need to be discussed but that's probably a 
different discussion. That discussion could well suggest a much slower cadence, 
but perhaps that is even possibly *on top* of a continues SimFlow.



Just brain storming ...

Stephan


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] LSP4E: A Problem Waiting to Happen?

[Stephan Herrmann]

thanks for nagging :)

While we are at it, is anybody using validation from the aggregation editor??
Reason for asking: whenever I try that, it aborts with this message:

Unable to load repository 
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository
Unable to load repository 
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/
Build failed! Exception was org.eclipse.core.runtime.CoreException: Unable to 
load repository 
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/



yes, my browser can see that repository. Is p2 not ready to read from 
archive.e.o? Is the repo broken by any terms?


anybody else seeing this?
Stephan

On 08.12.19 10:23, Ed Merks wrote:

Hi,

It's me the nagger again. I know many of you are editing your *.aggrcon 
manually.  This is mildly annoying.  When I edit using the editor and save my 
changes, all the files being edited manually change.


I can and do revert all these, but it's annoying.

Unfortunately this approach also makes it easy (and likely) to overlook problems 
in the consistency of the overall simrel.aggr resource.


In addition, the recommended process for contributing is to point your 
contribution at a specific update site:


https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#The_best_format_and_process_for_contributing_to_Sim._Release

When you don't do this, your contribution will potentially change dynamically, 
which might be convenient for you, but it is problematic from an overall 
consistency point of view.  It's also less than idea if your specific site 
updates its content dynamically...


Why do I harp about this?  I'm quite sure that lsp4e intends to contribute the 
0.13.0 release for 2019-12:


https://projects.eclipse.org/projects/technology.lsp4e/releases/0.13.0

But look closely at what the editor tells us:


While the "dynamically changing" repo (I can only assume that this is the case) 
does contain version 1.30.0, this is *not *what's contributed to the the 2019-12 
release train.  Somewhere (and I have no clue from where) the 0.12.0 version is 
found and that's what's on the train:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-12/http___download.eclipse.org_releases_2019-12_201912061000/org.eclipse.lsp4e_0.12.0.201909270706.html

I'm quite sure this is not the intent so I've opened this Bugzilla:

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

Regards,
Ed


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] The Eclipse IDE 2019-06 release is available now!

[Stephan Herrmann]

On 19.06.19 16:11, Ed Merks wrote:

Fred,

I was successful installing the Eclipse IDE for Java product with the latest 
installer, the latest repos, and the latest product catalog.


I'm not having success installing via Oomph. Is it just me, is it Oomph or a 
problem in the repo?


Oomph is not finding the release version of the package (tried Java IDE & 
committers). Even tried disabling mirrors in Oomph.


Is something still using compositeArtifacts.jar??

Here's oomph's log:

Executing bootstrap tasks
Renamed existing configuration folder to 
/home/eclipse/otdt-2019-06/eclipse/configuration.1561064244575

Java(TM) SE Runtime Environment 9.0.4+11
Product org.eclipse.products.epp.package.java.2019-06
Bundle org.eclipse.oomph.setup 1.13.0.v20190530-1228, build=4030, 
branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697
Bundle org.eclipse.oomph.setup.core 1.13.0.v20190531-1228, build=4030, 
branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697
Bundle org.eclipse.oomph.setup.installer 1.13.0.v20190530-1228, build=4030, 
branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697
Bundle org.eclipse.oomph.setup.p2 1.11.0.v20190530-1228, build=4030, 
branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697

Performing P2 Director (Eclipse IDE for Java Developers (2019-06))
Offline = false
Mirrors = true
Resolving 21 requirements from 3 repositories to 
/home/eclipse/otdt-2019-06/eclipse
Requirement epp.package.java [4.12.0,5.0.0)
Requirement org.eclipse.buildship.feature.group
Requirement org.eclipse.eclemma.feature.feature.group
Requirement org.eclipse.egit.feature.group
Requirement org.eclipse.egit.mylyn.feature.group
Requirement org.eclipse.epp.mpc.feature.group
Requirement org.eclipse.jdt.feature.group
Requirement org.eclipse.jgit.feature.group
Requirement org.eclipse.m2e.feature.feature.group
Requirement org.eclipse.m2e.logback.feature.feature.group
Requirement org.eclipse.mylyn.bugzilla_feature.feature.group
Requirement org.eclipse.mylyn.context_feature.feature.group
Requirement org.eclipse.mylyn.git.feature.group
Requirement org.eclipse.mylyn.hudson.feature.group
Requirement org.eclipse.mylyn.ide_feature.feature.group
Requirement org.eclipse.mylyn.java_feature.feature.group
Requirement org.eclipse.mylyn.wikitext_feature.feature.group
Requirement org.eclipse.mylyn_feature.feature.group
Requirement org.eclipse.tips.feature.feature.group
Requirement org.eclipse.wst.xml_ui.feature.feature.group
Requirement org.eclipse.oomph.setup.feature.group
Repository http://download.eclipse.org/technology/epp/packages/2019-06
Repository http://download.eclipse.org/releases/2019-06/201906191000
Repository http://download.eclipse.org/oomph/updates/milestone/latest
Adding repository http://download.eclipse.org/technology/epp/packages/2019-06
Adding repository http://download.eclipse.org/releases/2019-06/201906191000
Adding repository http://download.eclipse.org/oomph/updates/milestone/latest
Calculating requirements and dependencies.
Cannot complete the request.  Generating details.
ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the install 
because one or more required items could not be found.

  at org.eclipse.oomph.util.OomphPlugin.coreException(OomphPlugin.java:280)
  at 
org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.resolve(ProfileTransactionImpl.java:425)
  at 
org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:337)

  at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:751)
  at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3824)
  at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3752)
  at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3733)
  at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3626)

  at 
org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:575)
  at 
org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:701)

  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
  ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: 
artificial_root 1.0.0.v1561064246470
  ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Eclipse 
IDE for Java Developers 4.12.0.20190509-1619 (epp.package.java 
4.12.0.20190509-1619) requires 'org.eclipse.equinox.p2.iu; 
org.eclipse.platform.feature.group 
[4.12.0.v20190501-2033,4.12.0.v20190501-2033]' but it could not be found
  ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Eclipse 
IDE for Java Developers 4.12.0.20190529-1916 (epp.package.java 
4.12.0.20190529-1916) requires 'org.eclipse.equinox.p2.iu; 
org.eclipse.platform.feature.group 
[4.12.0.v20190522-1800,4.12.0.v20190522-1800]' but it could not be found
  ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Eclipse 
IDE 

Re: [cross-project-issues-dev] Projects participating in 2019-06

[Stephan Herrmann]

Object Teams is contributing version 2.7.4
(https://projects.eclipse.org/projects/tools.objectteams/releases/2.7.4-2019-06)

thanks,
Stephan

On 03.06.19 20:34, Wayne Beaton wrote:
I've updated the project participation 
 list to reflect what I believe 
that I see in the aggregate repository. Please let me know if I've gotten 
something wrong.


ACTF is not in the repository and I don't know why. Their aggrcon file looks 
fine. Have I missed something important?


Note that RC1 is on June 7/2019. If you're pushing new versions/features, please 
update your contribution before this date.


A handful of projects did not signal their intent to participate using the 
described method (nor did they respond to my attempts to use this channel to 
connect). I intend to recommend to the Planning Council that they prune out 
those projects that are clearly not contributing to the process.


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



___
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] Eclipse and Equinox M2

[Stephan Herrmann]

Yes, that's intended. The Eclipse project contributed a build that has not 
undergone the full milestone procedure (AFAIK this rule applies to all M2 since 
the switch to the new cadence).


Retention of milestone builds is a separate issue, but since the bits are 
contained in the simrel repo there's probably no need to keep the contributed 
build via the project's download page.


Finally, M3 is about to be contributed this Friday.

Stephan

On 22.05.19 22:24, Patrick Tasse wrote:

Hi,

Is it normal that the Eclipse Project Downloads page only lists an update site 
for 4.12M1 and not for 4.12M2?


https://download.eclipse.org/eclipse/downloads/

The equinox.aggrcon file points to 
http://download.eclipse.org/eclipse/updates/4.12-I-builds/I20190501-1800/ but 
even this version is not visible in the "4.12 Integration Builds" table.


Thanks,
Patrick


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Simrel Version issue - Object Teams

[Stephan Herrmann]

Thanks for the heads-up

The Object Teams contribution has been updated and re-enabled.

Since nothing related has changed in the Object Teams build for a long time, and 
since failures also started occurring during the Object Teams build just now, I 
have the feeling that p2 resolution / constraint evaluation has been changed 
recently.
I will await the next milestone to see if a fundamental change is (again) 
required in Object Teams due to platform changes. Until then please don't 
hesitate to disable again if the next Platform/JDT contribution triggers the 
same issue again.


best,
Stephan

On 12.04.19 09:20, Manoj Palat wrote:

Hi Stephan,
Simrel for 4.12 M1 is failing as Object Teams contribution requires 3.17 version 
of JDT Core while 4.12 M1 Eclipse platform has increased its version to 3.18. I 
am disabling Object Teams contribution for now. Please re-enable after the 
problem is fixed.


Regards,
Manoj



___
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] imRel 2019-03 Release Candidate 1 (RC1) is available

[Stephan Herrmann]

The NumberFormatException looks like https://bugs.eclipse.org/544860 which is 
verified fixed in RC2


best,
Stephan

On 09.03.19 18:22, Eike Stepper wrote:

Hi,

As Patrick found out earlier there's definitely a typo in 
compositeArtifacts.jar. I've asked someone to call up Fred.


I could work around this problem with a RedirectionTask in my Oomph user.setup:


http://www.omg.org/XMI;
     xmlns:setup="http://www.eclipse.org/oomph/setup/1.0;
     sourceURL="http://download.eclipse.org/releases/2019-03;
targetURL="http://download.eclipse.org/releases/2019-03/201903081000"/>

But then I noticed that my workspace could not be built anymore. A dialog popped 
up for each project and said:


Errors running builder 'Java Builder' on project 'xyz'.

java.lang.NumberFormatException: For input string: "B/"
     at java.lang.NumberFormatException.forInputString(Unknown Source)
     at java.lang.Integer.parseInt(Unknown Source)
     at 
org.eclipse.jdt.internal.core.builder.ClasspathJrtWithReleaseOption.isJRE12Plus(ClasspathJrtWithReleaseOption.java:97) 

     at 
org.eclipse.jdt.internal.core.builder.ClasspathJrtWithReleaseOption.initialize(ClasspathJrtWithReleaseOption.java:138) 

     at 
org.eclipse.jdt.internal.core.builder.ClasspathJrtWithReleaseOption.(ClasspathJrtWithReleaseOption.java:73) 

     at 
org.eclipse.jdt.internal.core.builder.ClasspathLocation.forJrtSystem(ClasspathLocation.java:147) 

     at 
org.eclipse.jdt.internal.core.builder.NameEnvironment.computeClasspathLocations(NameEnvironment.java:312) 

     at 
org.eclipse.jdt.internal.core.builder.NameEnvironment.(NameEnvironment.java:62) 

     at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.initializeBuilder(JavaBuilder.java:629) 

     at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:174)

     at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:833)
     at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
     at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)
     at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263)

     at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316)
     at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
     at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319)
     at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371)

     at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392)
     at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:154)

     at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:244)
     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

I haven't investigated any further for lack of time. Redirecting to the previous 
(201903011000) build resolved the problem for me.


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 08.03.2019 um 16:09 schrieb Frederic Gurr:

Hi,

The 2019-03 RC1 update repository is available from:

=> http://download.eclipse.org/releases/2019-03/

The EPP Packages will be available soon here:

=> https://www.eclipse.org/downloads/packages/release/2019-03/rc1

Thanks everyone for participating!


Regards,

Fred




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] User-friendly Eclipse platform for evolving Java

[Stephan Herrmann]

I agree with Ed that there is much room for improvement, or: opportunity to
help our users.

I suggest to separate 2 discussions for now:

(1) How can Eclipse itself be made more stable to be runnable on more versions 
of
Java without hiccups like experienced by Code Recommenders, Mylyn etc?

(2) Can JDT hide Java "eccentricities" from user projects, e.g., can we conjure
a "java.xml" rabbit out of the hat, even if JRE 11 doesn't provide it any more?


Discussion (1) is urgent right now, it is essential for the 2018-12 release.
Some alternatives have been discussed for months. If those discussions have
not yet converged on a solution that works on Java 10- like 11+ then we seem
to need improved mechanisms of conditional installation (like: add a bundle
from Orbit IFF java.version >= 11) - not only during "install new software"
but also during installing a zipped / tarred package.


I'm open to discussing (2) in a JDT bug, although I should add, we are more than
busy just providing support for each new Java version. Implementing additional
non-strict modes obviously requires additional efforts, just saying.

best,
Stephan


On 16.12.18 16:19, Ed Willink wrote:

Hi

The recent "Errors when running 2018-12 RC2 on Java 11" thread is just one of 
many 'new'-Java problems.

The instability of Java is clearly a major PITA, so that each of Java 8, 9, 10, 11 has resulted in significant breakages that have 
gradually been ameliorated.


As a user I see Eclipse as a nice platform that has for many years hidden the Windows/Linux/MacOS eccentricities. Less obviously, 
the platform now nodes to hide the Java 7/8/9/10/11 eccentricities, so that for the most part an Eclipse application just works. We 
should not depend on each project rebuilding with latest-Java workarounds.


Currently each new Java eccentricity seems to be accommodated by dubious workarounds that do not hide the problem from the user. 
e.g. I now have to import javax.annotation into each of my test plugins.


It seems that we need to offer two options.

a) a default Eclipse that maximally hides the Java eccentricities to give a good user experience. This may require a 
're-modularizer' to counteract Java's incessant migrations.


b) -strict Eclipse for those who want to be precisely in tune with a Java 
eccentricity.

     Regards

         Ed Willink



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Incompatible / incomplete update of tycho 1.3.0-SNAPSHOT?

[Stephan Herrmann]

Turns out, all JDT/Core tycho builds are affected, even after many retries.
And I assume many other builds will be, too.
I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=539733

Stephan

On 02.10.2018 18:35, Mickael Istria wrote:

Hi Stephan,

On Tue, Oct 2, 2018 at 6:21 PM Stephan Herrmann mailto:stephan.herrm...@berlin.de>> wrote:

18:11:08 Exception in thread "main" java.lang.NoSuchMethodError:

org.eclipse.tycho.p2.metadata.DependencyMetadataGenerator.generateMetadata(Lorg/eclipse/tycho/p2/metadata/IArtifactFacade;Ljava/util/List;Lorg/eclipse/tycho/core/resolver/shared/OptionalResolutionAction;)Lorg/eclipse/tycho/p2/metadata/IDependencyMetadata;


Those specific Tycho issue would better be sent to the tycho-user mailing-list 
and/or on Tycho bugzilla component.

Could this be a SNAPSHOT deployment still in progress / aborted half way?


The extensive test suite in Tycho reports no issue, so I hope Tycho is fine.
This could very well be that your build took place at the same time as https://ci.eclipse.org/tycho/job/tycho-build/904/ so you get 
different versions of dependent jars resulting in such incompatibility.


I suggest you just try again, making sure you get the last version of the snapshots. Since the job is configured to delete workspace 
on startup, it should fetch the latest jars in anycase.

If after a retry you see the same failure, please report it as a bug in Tycho.

HTH



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
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] Incompatible / incomplete update of tycho 1.3.0-SNAPSHOT?

[Stephan Herrmann]

Just now I started seeing the following exception in builds:

18:11:08 Exception in thread "main" java.lang.NoSuchMethodError: 
org.eclipse.tycho.p2.metadata.DependencyMetadataGenerator.generateMetadata(Lorg/eclipse/tycho/p2/metadata/IArtifactFacade;Ljava/util/List;Lorg/eclipse/tycho/core/resolver/shared/OptionalResolutionAction;)Lorg/eclipse/tycho/p2/metadata/IDependencyMetadata;
18:11:08 	at 
org.eclipse.tycho.extras.custombundle.CustomBundleP2MetadataProvider.getDependencyMetadata(CustomBundleP2MetadataProvider.java:62)

18:11:08at 
org.eclipse.tycho.p2.resolver.P2DependencyResolver$1.run(P2DependencyResolver.java:158)

details can be found at
https://hudson.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-11/6/console

Could this be a SNAPSHOT deployment still in progress / aborted half way?
I do see slight variance in qualifiers:

https://repo.eclipse.org/content/repositories/tycho-snapshots/org/eclipse/tycho/tycho/1.3.0-SNAPSHOT/tycho-1.3.0-20181002.151915-12.pom
https://repo.eclipse.org/content/repositories/tycho-snapshots/org/eclipse/tycho/tycho-core/1.3.0-SNAPSHOT/tycho-core-1.3.0-20181002.152319-12.pom

Has anybody else seen this?

Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Object Teams participation in SimRel 2018-09

[Stephan Herrmann]

Object Teams will participate in SimRel 2018-09
with a 2.7.1 bugfix release [1] at it's usual +2 offset.

best,
Stephan

[1] https://projects.eclipse.org/projects/tools.objectteams/releases/2.7.1
___
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] Gerrit Builds fail with Unknown host download.eclipse.org

[stephan . herrmann]

The SecurityException is the same symptom as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536445 and
https://github.com/eclipse/xtext/issues/1231 

Stephan 

Am 2018-06-29 16:35, schrieb Mollik, Ralf:

> Hi all,
> 
> the name resolution is working again - now I get
> 
> [WARNING] Error injecting: org.eclipse.xtend.maven.XtendCompile
> com.google.inject.ProvisionException: Guice provision errors:
> 
> 1) Error injecting constructor, 
> com.google.inject.internal.util.$ComputationException: 
> com.google.inject.internal.util.$ComputationException: 
> java.lang.SecurityException: class 
> "org.eclipse.core.runtime.OperationCanceledException"'s signer information 
> does not match signer information of other classes in the same package
> at org.eclipse.xtend.maven.XtendCompile.(Unknown Source)
> while locating org.eclipse.xtend.maven.XtendCompile
> 
> as well as on the Eclipse Jenkins instance as on my instance here in the 
> company. Any idea?
> 
> Mit freundlichen Grüßen / Cordialement / Best Regards
> 
> ppa. / p.p. Ralf Mollik
> Bereichsleiter Entwicklung / Director Development OS.bee
> 
> -Ursprüngliche Nachricht-
> Von: cross-project-issues-dev-boun...@eclipse.org 
> [mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Becker, 
> Matthias
> Gesendet: Freitag, 29. Juni 2018 14:05
> An: Cross project issues
> Betreff: [cross-project-issues-dev] Gerrit Builds fail with Unknown host 
> download.eclipse.org
> 
> Hi everbody,
> 
> Currently my gerrit builds are all failing with „Unknown host 
> download.eclipse.org". See 
> https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/15338/console
> This seems to be an infrastructure issue.
> Is anybody aware of it?
> 
> Regards,
> Matthias
> 
> Matthias Becker
> Development, PI Tech Core ABAP Server (SE)
> SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
> 
> T +49 6227 7-60223, M +49 151 53858523, E ma.bec...@sap.com
> 
> Pflichtangaben/Mandatory Disclosure Statement:
> http://www.sap.com/company/legal/impressum.epx/
> 
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige 
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine 
> Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte 
> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
> 
> This e-mail may contain trade secrets or privileged, undisclosed, or 
> otherwise confidential information. If you have received this e-mail in 
> error, you are hereby notified that any review, copying, or distribution of 
> it is strictly prohibited. Please inform us immediately and destroy the 
> original transmittal. Thank you for your cooperation.
> 
> ___
> 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] Which version of pack200 to avoid "Unable to unpack artifact ..."?

[Stephan Herrmann]

Nevermind, just some fallout from my (involuntary) attempts to switch
to the jar signing web server ...

On 15.05.2018 23:02, Stephan Herrmann wrote:

The Object Teams contribution for M7 currently fails the aggregation
with errors like:

  [exec] - mirroring artifact 
osgi.bundle,org.eclipse.objectteams.otdt.ui,2.7.0.201805151219
  [exec] doing copy of optimized artifact
  [exec] unpacking optimized artifact
  [exec] Unable to unpack artifact osgi.bundle,org.eclipse.objectteams.otdt.ui,2.7.0.201805151219 in repository 
file:/home/hudson/genie.simrel/.jenkins/jobs/simrel.photon.runaggregator.BUILD_CACHED/workspace/aggregation/final/aggregate: 
Unpacking fails because intermediate file is empty: 
/home/hudson/genie.simrel/.jenkins/jobs/simrel.photon.runaggregator.BUILD_CACHED/workspace/tmp/work356960850472058849/p2.optimizers.incoming1017866611377793502.jar 



 From previous bugs this sounds like an incompatibility between
the versions of pack200 and unpack200 used.

So, which version should be used for simrel contributions?

When I download any of those failing artifacts I can cleanly
unpack200 them with all versions greater than 1.5.

Other ideas, how to analyse the root cause of this?

best,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
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] Which version of pack200 to avoid "Unable to unpack artifact ..."?

[Stephan Herrmann]

The Object Teams contribution for M7 currently fails the aggregation
with errors like:

 [exec] - mirroring artifact 
osgi.bundle,org.eclipse.objectteams.otdt.ui,2.7.0.201805151219
 [exec] doing copy of optimized artifact
 [exec] unpacking optimized artifact
 [exec] Unable to unpack artifact osgi.bundle,org.eclipse.objectteams.otdt.ui,2.7.0.201805151219 in repository 
file:/home/hudson/genie.simrel/.jenkins/jobs/simrel.photon.runaggregator.BUILD_CACHED/workspace/aggregation/final/aggregate: 
Unpacking fails because intermediate file is empty: 
/home/hudson/genie.simrel/.jenkins/jobs/simrel.photon.runaggregator.BUILD_CACHED/workspace/tmp/work356960850472058849/p2.optimizers.incoming1017866611377793502.jar


From previous bugs this sounds like an incompatibility between
the versions of pack200 and unpack200 used.

So, which version should be used for simrel contributions?

When I download any of those failing artifacts I can cleanly
unpack200 them with all versions greater than 1.5.

Other ideas, how to analyse the root cause of this?

best,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Simrel branch for 4.7.3a

[Stephan Herrmann]

On 29.03.2018 08:31, Matthias Sohn wrote:

On Thu, Mar 29, 2018 at 6:00 AM, Evgeny Mandrikov <mandri...@gmail.com 
<mailto:mandri...@gmail.com>> wrote:



On Thu, Mar 29, 2018 at 12:05 AM Stephan Herrmann <stephan.herrm...@berlin.de 
<mailto:stephan.herrm...@berlin.de>> wrote:

To avoid incompatibilities with the Object Teams Patch feature
I tried to contribute a version synced with 4.7.3aRC1 from JDT,
but found that my gerrit[1] is not picked up by any jenkins job,
nor do I see *any* job working from that branch.
Am I missing anything?

It's not that I want to unduly push Object Teams, it's just to avoid
the risk of people installing from 3a a variant that does not support
Java 10.


Seems that job for branch Oxygen.3a_JDK10 is indeed missing.
Did full build of this branch locally in order to verify contribution of 
EclEmma with Java 10 support -
https://git.eclipse.org/r/#/c/120396/ 
<https://git.eclipse.org/r/#/c/120396/>


the job is here and enabled
https://ci.eclipse.org/simrel/job/simrel.oxygen.runaggregator.VALIDATE.gerrit/
but it seems it stopped reacting to Gerrit events. I lack permissions to check
the job configuration.


Well, but we can see the console output which states "-DGERRIT_BRANCH=Oxygen_update 
",
which is not the branch from which 4.7.3a is supposed to be built 
("Oxygen.3a_JDK10"), right?

Stephan



-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] Simrel branch for 4.7.3a

[Stephan Herrmann]

To avoid incompatibilities with the Object Teams Patch feature
I tried to contribute a version synced with 4.7.3aRC1 from JDT,
but found that my gerrit[1] is not picked up by any jenkins job,
nor do I see *any* job working from that branch.
Am I missing anything?

It's not that I want to unduly push Object Teams, it's just to avoid
the risk of people installing from 3a a variant that does not support
Java 10.

regards,
Stephan

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

On 23.03.2018 15:42, Sravan K Lakkimsetti wrote:

Thanks Fred for the information. I will add eclipse and equinox contribution 
tomorrow

Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858

-Original Message-
From: Frederic Gurr [mailto:frederic.g...@eclipse-foundation.org]
Sent: Friday, March 23, 2018 7:19 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Simrel branch for 4.7.3a

Hi Sravan,

I've created a branch for Oxygen.3a called:

=> Oxygen.3a_JDK10

Regards,

Fred


--
Frederic Gurr

Release Engineer
Eclipse Foundation


On 23.03.2018 11:40, Sravan K Lakkimsetti wrote:
 > Hi,
 >
 >
 >
 > Do we have a separate branch for 4.7.3a or use Oxygen_update branch
 >
 >
 >
 > Thanks and Regards,
 >
 > Sravan
 >
 >
 >
 > Sravan Kumar Lakkimsetti
 >
 > IBM India Pvt Ltd,
 >
 > Embassy Golf Links Business Park, D Block,
 >
 > Off Indiranagar-Kormangla Inner Ring Road,
 >
 > Bangalore - 560071, India
 >
 > Phone: 91-80-41776858
 >
 >
 >
 >
 >
 >
 > ___
 > 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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_m
 > ailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwIF-g=jf_iaSHvJObT
 > bx-siA1ZOg=BbJ1i82pNJnkXoEbqK7sZDkJsrJ7wkY_no7y0H4rMzE=RB6m1XVbtTD
 > YfkDOkFZVDPkrWNraGUJaKMsRM-bSTqo=Rhyu3-S0vypSKn3vqYVbttBi5hRrD3IV93K
 > EtsZBS5w=
 >
___
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=BbJ1i82pNJnkXoEbqK7sZDkJsrJ7wkY_no7y0H4rMzE=RB6m1XVbtTDYfkDOkFZVDPkrWNraGUJaKMsRM-bSTqo=Rhyu3-S0vypSKn3vqYVbttBi5hRrD3IV93KEtsZBS5w=





___
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] [epp-dev] Photon M6 is available now

[Stephan Herrmann]

Have you seen https://bugs.eclipse.org/bugs/show_bug.cgi?id=532625 ?
I don't know if this explains all symptoms you are observing,
in particular why *expected* updates were *not* proposed.

Anyway, I think it would be good to remove M4 from the composite sooner,
rather than later, to effectively test if all problems are indeed resolved in 
M6.
Any objections?

Stephan

On 20.03.2018 09:35, Wim Jongman wrote:

Hi,

For people also struggling with the upgrade from M5 to M6 with [1]. I resolved 
my issues by _*removing all update sites*_ except:

Photon - http://download.eclipse.org/releases/photon/ 

Photon Staging - http://download.eclipse.org/staging/photon/ 

The Eclipse Project Updates - http://download.eclipse.org/eclipse/updates/4.8 


Then restart and check for updates finally gave me something else besides "objects 
team patch for jdt/core"

It was probably me and could be a stale cache or something else, but in case 
you face the same issue you could try what worked for me.

Cheers,

Wim


[1] https://wiki.eclipse.org/FAQ_How_do_I_upgrade_Eclipse_IDE%3F#Beta-testing_milestones_and_release_candidates 





On Sat, Mar 17, 2018 at 9:20 AM, Markus Knauer > wrote:

That was a minor error and has been corrected now.

Thanks,
Markus

On 16 March 2018 at 22:50, Mickael Istria > wrote:

Hi,

EPP site that's composited in SimRel repo ( 
http://download.eclipse.org/technology/epp/packages/photon/
 ) seems to 
miss reference to the M6 release so the "Check for
updates" doesn't work going from M5 to M6.
Is this expected?

Cheers

___
epp-dev mailing list
epp-...@eclipse.org 
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev 





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org 

To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] simrel.photon.runaggregator.VALIDATE.gerrit job is broken

[Stephan Herrmann]

Quick comment on removing version ranges:
It's recommended to indeed specify the exact version which you are contributing,
see 
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Simple_repo.2C_and_specify.2C_exact_versions

Stephan

On 22.02.2018 21:08, Nick Boldt wrote:

Yeah, I later realized the fault was mine, and my not understanding how b3 
works w.r.t. its internal model consistency.

Also helps that I figured out I can just *remove* the version ranges. \o/

Apologies for the spam,

Nick

On Thu, Feb 22, 2018 at 2:57 PM, Stephan Herrmann <stephan.herrm...@berlin.de 
<mailto:stephan.herrm...@berlin.de>> wrote:

To me this looks like p2 reporting a fairly normal error:

Cannot complete the install because one or more required items could not be 
found.
Software being installed: validationSet_main 1.0.0 Missing requirement:
         
mappedRepo_home_data_httpd_download.eclipse.org_datatools_updates_1.14.100-SNAPSHOT_repository
 1.0.0
            requires 
'org.eclipse.datatools.enablement.sdk.feature.feature.group 
[1.14.100.201801242337]'
            but it could not be found
         Cannot satisfy dependency: validationSet_main 1.0.0 depends on:
            
mappedRepo_home_data_httpd_download.eclipse.org_datatools_updates_1.14.100-SNAPSHOT_repository

When I look into that respository 
(http://download.eclipse.org/datatools/updates/1.14.100-SNAPSHOT/respository

<http://download.eclipse.org/datatools/updates/1.14.100-SNAPSHOT/respository>)
I see it containing a wrong version of 
org.eclipse.datatools.enablement.sdk.feature
         expected:       1.14.100.201801242337
         but contains:   1.14.100.201802061819

HTH,
Stephan

On 22.02.2018 18 <tel:22.02.2018%2018>:44, Nick Boldt wrote:

After several failed attempts to make changes to the dtp.aggrcon file, 
which caused the gerrit build to fail, I submitted
this no-op change, which simply adds a space to the end of a line.

https://git.eclipse.org/r/#/c/117970/1/dtp.aggrcon 
<https://git.eclipse.org/r/#/c/117970/1/dtp.aggrcon>

The gerrit job failed:


https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/196/

<https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/196/>

Can someone with more knowledge about how to actually build these files 
take a look and retrigger the change, so we can get
green balls for aggregator validation builds again? I would but the 
magic underlying b3 aggregation is a black box to me. :(

Thanks!


-- 


Nick Boldt

Senior 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 
<https://twitter.com/redhatnews>>    Red Hat
<https://www.facebook.com/RedHatInc 
<https://www.facebook.com/RedHatInc>>
<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 
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org 
<mailto:cross-project-issues-dev@eclipse.org>
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>




--
Nick Boldt :: http://nick.divbyzero.com :: FB, IG, Twitter, G+, LinkedIn, 
Freenode: @nickboldt
“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



___
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] p2 <-> aggregator sync.

[Stephan Herrmann]

I pulled the plug on Object Teams.

hope to be back early during M6
Stephan

On 29.01.2018 23:26, Stephan Herrmann wrote:

Meanwhile I could reproduce David's observation after getting me a
fresh simrel workbench via Oomph.

As requested by Todor, I filed https://bugs.eclipse.org/530470
which also has some details about the requirements causing the failure.

Contrary to Ed's guess, the repo in question was indeed produced
by the exact version of p2 as contributed to M5. (My builds always
start with: download latest SDK milestone and use that to drive
the build).

If p2 @ M5 is not ready for prime time (as Ed's reluctance suggests)
then I may have no other chance but to pull Object Teams out of simrel
for now.

Is everybody else still using Oxygen's p2 to create their contribution?
But then: when and how will the latest p2 be tested in real-life scenarios?

BTW: did anyone find out how to get more meaningful logs from
failed gerrit builds / aggregations?

Stephan

PS: Todor, I understand that your current task is far from trivial
and legacy weighs heavy on you.

On 29.01.2018 11:04, Todor Boev wrote:

Please open a bug for this.

The issue seems to come from:
org.eclipse.equinox.internal.p2.metadata.repository.io.MetadataWriter#writeRequirement(IRequirement)

The expression in the repository is *not* a generic requirement. It is the internal representation of a *standard* "namespace; 
name; version-range". Both standard and generic requirements have similar internal representations with a complex match 
expressions like this. The p2 read/write code always had this hack to guess if the requirement it is about to write is standard or 
general. The guess is inherently unreliable. To that hack I added one more guess for a properties match requirement.


I am not sure how but the guessing code for standard requirements failed in 
this instance.

P2 would have been much better off if it just wrote it's requirements in their normal expression language form. Instead it first 
introduces a very general expression language that is opaque to external readers (because it is so general) and then tries to hack 
itself by guessing what kind of expression this is.


-
My impression was that the latest design idea was to not serialize the
more general "match" requirements in a form that older runtimes would
even read them, so they would not be represented as an
RequiredCapability at all and not be serialized in a form that older
runtimes would even loaded, so would be invisible in order runtimes.
But perhaps this repo was produced with an M4 version of p2 and not
the current version that's in the 4.8IBuilds.


On 29.01.2018 08:37, David Williams wrote:

On 01/28/2018 12:48 PM, Stephan Herrmann wrote:

Result [2]:
Unable to load repository
p2:file:///home/data/httpd/download.eclipse.org/objectteams/updates/ot2.7/staging 
<http://download.eclipse.org/objectteams/updates/ot2.7/staging>

While I don't see the actual root error, this appears to be the case
were the aggregator cannot handle current format of p2 meta data.
(Any chance to access any details of this failure?)

Did you try the aggregator editor?
I can see some detail in the console log, when using the aggregator editor.
This is with Oxygen.2 and aggregator 4.7 installed.
The log says "can not load repository" (as does pop up dialog), but
then the log continues with
!MESSAGE Unable to load repository
http://download.eclipse.org/objectteams/updates/ot2.7/staging 
<http://download.eclipse.org/objectteams/updates/ot2.7/staging>
!STACK 0
java.lang.IllegalArgumentException
     at 
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.assertValid(RequiredCapability.java:271)
     at 
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.extractRange(RequiredCapability.java:250)
     at 
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.getRange(RequiredCapability.java:164)
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:458)
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:342)
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:280)
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:402)
     at 
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:120)
     at 
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60)

And, from looking at the code, there is something about (p2's)
"getVersion" that p2 considers invalid -- that is, while processing
your version in your required capability data. Only in the Oxygen
stream, that I see.

In my dev. environment where Photon M5 is installed, and the
aggregator built from master branch, (i.e. installed from
...cbi/updates/aggregator/ide/4.8/
then there is no exception, and no problem. But, I do not know if it
pr

[cross-project-issues-dev] p2 <-> aggregator sync.

[Stephan Herrmann]

I've been observing conflicts between recent changes in p2
and the CBI aggregator for some weeks [1].

Today, I triggered a gerrit test with latest from Object Teams,
which is provided as a repo created by latest from p2 (as of M5).

Result [2]:
Unable to load repository 
p2:file:///home/data/httpd/download.eclipse.org/objectteams/updates/ot2.7/staging
While I don't see the actual root error, this appears to be the case
were the aggregator cannot handle current format of p2 meta data.
(Any chance to access any details of this failure?)

When I locally install the latest CBI aggregator from
  http://download.eclipse.org/cbi/updates/aggregator/ide/4.8/
I can successfully validate and build the aggregation.
Smoke tests of installing from that locally built repo show
no problems.

How do folks feel about either of
 A upgrading to latest from CBI aggregator?
 B ensuring that no project in simrel uses p2 > Photon M3 for their 
contribution?
   B.1: how long can be "freeze" p2 at Oxygen level??

We have no plan C for M5.

BTW, kudos to David Williams for doing the necessary maintenance
to keep the aggregator alive [3].

A fine point: I found no way to upgrade the Oomph-based SimRel
workbench to latest from p2 and aggregator, because we'd need versions
from M5 of which no EPP exists at this point. Chicken-and-egg?

best,
Stephan


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=528798
[2] 
https://hudson.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/137/console
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=528872
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?

[Stephan Herrmann]

Another option could be: even "inactive" projects could be required,
to perform builds against each SimRel milestone, even when contributing
a previous version. This should ensure that code still works (compiles
and passes tests) against updated dependencies.

I don't think this should be much of a burden on "maintainers".

Stephan

On 16.12.2017 17:43, Konstantin Komissarchik wrote:

Dani,


DTD did participate in Oxygen, but DTP is in maintenance mode with no one actively working on it. The only time a new build or 
release is made is when a critical need arises. Such event happened in Oxygen M4 with Lucene changes, so DTP produced a 1.14 build 
at that point and went dormant again. In particular, it was not rebuilt with the following milestones.



In my opinion, the deprecate and announce policy of API removal isn't effective for projects like DTP. There is a huge code base. 
Only a small part is going to be examined and only when something breaks. There is no one to notice the deprecation warnings. 
Similarly, when the announcement comes, it relies on someone either (a) recognizing that their project depends on that API, or (b) 
proactively searching through the code base for references. Neither of these is very likely to happen for a maintenance mode 
project. What would have helped is strict adherence to OSGi versioning convention (major version bump) as that would have broken DTP 
aggregation and triggered a need for a rebuild, so problematic references would have been caught and fixed.



Thanks,


- Konstantin





*From:* cross-project-issues-dev-boun...@eclipse.org  on behalf of Daniel Megert 


*Sent:* Saturday, December 16, 2017 9:25 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
Hi Konstantin

Did DTP not participate in Oxygen in June? There the class was already deleted, 
so, DTP should have run into this in June already.

Note that we announced the deletion on this mailing list.

Dani



From: Konstantin Komissarchik 
To: Cross project issues 
Date: 15.12.2017 17:46
Subject: Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
Sent by: cross-project-issues-dev-boun...@eclipse.org



Dani,

It wasn’t an internal. It was a deprecated class that was removed. Since DTP isn’t actively being developed, no one saw the 
deprecation warnings. A major version bump would have allowed the removal to be caught earlier…


org.eclipse.jface.util.ListenerList (removed)

org.eclipse.core.runtime.ListenerList (replacement)


Thanks,

- Konstantin

*From: *_Daniel Megert_ *
Sent: *Friday, December 15, 2017 3:17 AM*
To: *_Cross project issues_ *
Subject: *Re: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?


 platform made an API change after that which broke some of the DTP 
functionality


Do you have a bug report for that? The platform usually doesn't break APIs. Did 
DTP maybe use internals?

Dani



From: Konstantin Komissarchik 
To: "cross-project-issues-dev@eclipse.org" 

Date: 14.12.2017 22:11
Subject: [cross-project-issues-dev] Can DTP join EGit in Oxygen.2 respin?
Sent by: cross-project-issues-dev-boun...@eclipse.org

Could someone forward this to the Planning Council, please?

I am currently working with Nick Boldt to transition DTP releng responsibility. In the meantime, the version of DTP in Oxygen.2 has 
compatibility issues. It was last build with Oxygen.0.M4 and platform made an API change after that which broke some of the DTP 
functionality. The 1.14.1 release that contains the fix is ready to go. Since EGit has initiated a respin, would it be possible for 
DTP to join. The change is low risk. Basically changing package names for a class that now must be found in a different plugin and 
corresponding version updates.


Thanks,

- Konstantin


___
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=MMH7LYZwjbox0bC45973M-gJrSog1mXSz-ZAj-pQA5o=zClipTo-omiP3JZ6zQMGb9SCOYmx8UlKgF9USHmCOl8=_ 

Re: [cross-project-issues-dev] Latest FeaturesAndBundlesPublisher from p2 incompatible with CBI aggregator?

[Stephan Herrmann]

Let's connect the dots: since M3, p2 generates metadata
that breaks Oomph Targlets, the CBI aggregator and possibly more.

See https://bugs.eclipse.org/313553

M2 is the last "good" build in this regard.

Stephan

PS: Thanks Ed for looking into this!

On 10.12.2017 21:22, Stephan Herrmann wrote:

Anybody else having trouble validating an aggregation
if a p2 repo was created using the latest from p2?

See https://bugs.eclipse.org/528387


Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
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] Latest FeaturesAndBundlesPublisher from p2 incompatible with CBI aggregator?

[Stephan Herrmann]

Anybody else having trouble validating an aggregation
if a p2 repo was created using the latest from p2?

See https://bugs.eclipse.org/528387


Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Object Teams participation in Photon

[Stephan Herrmann]

Hi,

Re-joining at M4, Object Teams participates in the Photon simultaneous release 
train.

Offset: +2

Version: 2.7.0

Release record: 
https://projects.eclipse.org/projects/tools.objectteams/releases/2.7.0

Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Possible SPAM BOT

[Stephan Herrmann]

Perhaps related: https://www.eclipse.org/forums/index.php/sp/218037/

some answers copy bits and pieces from previous answers in the same thread.
I wouldn't think of a bot, though, more likely someone trying to look smart?

Stephan


On 27.11.2017 14:13, Ed Willink wrote:

Hi

Beware that we have a new form of intelligent SPAM. Someone/thing is seemingly trying to auto-answer our questions by cutting and 
pasting from related web hits.


https://www.eclipse.org/forums/index.php?t=msg=1087159=1771660

Re: [cross-project-issues-dev] unable to push to gerrit - "session is down"

[Stephan Herrmann]

Thanks heaps, indeed!
With latest EGit/JGit from nightly I'm back on stage.
You saved my day :)

Stephan

On 28.11.2017 19:03, Thomas Wolf wrote:



On 28 Nov 2017, at 17:49 , Stephan Herrmann <stephan.herrm...@berlin.de 
<mailto:stephan.herrm...@berlin.de>> wrote:

when trying to push to Oxygen_update of org.eclipse.simrel.build.git
I get this error:

Can't connect to any repository: ssh://sherrm...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git 
(ssh://sherrm...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git: session is down)


anyone seen this?



Are you using EGit/JGit 4.9.0? Then that’s 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=526867 :-(

The bug is in Jsch.

JGit has a work-around, but AFAIK no 4.9.1 including the fix has been published 
yet. It should be
the EGit/JGit nightly build from 
http://download.eclipse.org/egit/updates-nightly/.

Otherwise, the manual interim work-around would be to comment out 
ServerAliveInterval in your
~/.ssh/config.

Cheers,

   Thomas



___
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] unable to push to gerrit - "session is down"

[Stephan Herrmann]

when trying to push to Oxygen_update of org.eclipse.simrel.build.git
I get this error:

Can't connect to any repository: ssh://sherrm...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git 
(ssh://sherrm...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git: session is down)


anyone seen this?

I have no issues pulling and at 4.7.1RC1 I was still able to push using the 
same configuration.

Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Oxygen.1a is broken when installed on top of the BETA Patch feature

[Stephan Herrmann]

Interesting idea, let's hope we still have the bits to perform the necessary 
experiments,
see https://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg28664.html

Stephan

On 14.10.2017 02:08, David Williams wrote:
I have not looked at this in detail, but one solution would be to produce a new "Beta Java-9 patch" even though it is no longer 
needed with Oxygen.1.


Its purpose would be to simply make sure the latest JDT was installed (instead 
of the patched parts of JDT).

The idea is that if someone has the beta patch installed already, then "check for 
updates" would effectively pull in Oxygen 1a.



___
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] Oxygen.1a is broken when installed on top of the BETA Patch feature

[Stephan Herrmann]

On day 2 after the Oxygen.1a there was quite a disastrous report on SO:

https://stackoverflow.com/questions/46731161/jdk-9-wont-let-me-use-strings-java-lang-string-is-ambiguous

It turned out to be a "simple" installation problem, and I'm afraid
that many users will run into this, too:

Installing Oxygen.1a on top of the BETA Patch feature does not
effectively install the released version of JDT plug-ins.

I believe this needs to be communicated immediately to all those
who previously installed the patch feature.

Which channel?
I don't know, "check for updates" doesn't have a web page ...

Stephan

PS: needless to say, that the RC2a respin is also without effect in this 
setting.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse-pmc] Fw: Xtext is broken in Oxygen 1a

[Stephan Herrmann]

In case the PMC decides positively (which I don't know as of now),
I created a gerrit [1].

I don't want to play a blame game, but still I would like to understand
why this problem was not detected during the .1a RC1 cycle.

Stephan

[1] https://git.eclipse.org/r/106393

On 06.10.2017 14:15, Daniel Megert wrote:

Dear Eclipse PMC

Should we consider to bring back the internal method and ask for a respin? We could provide a fix earlier than Wednesday, but it can 
also be risky to respin the Platform/JDT at this point,.


Dani

- Forwarded by Daniel Megert/Zurich/IBM on 06.10.2017 14:11 -

From: Sven Efftinge 
To: Cross project issues 
Date: 06.10.2017 13:59
Subject: [cross-project-issues-dev] Xtext is broken in Oxygen 1a
Sent by: cross-project-issues-dev-boun...@eclipse.org




Hi all,

Xtext is broken in Oxygen 1a, due to a signature change in an internal API of JDT [1][2]. It is a real blocker for Xtext and any 
downstream projects. Xtext will release a new version 2.13 with a fix on October 20.


We could also create a bugfix release for Oxygen 1a, given we decide this is important enough to do a respin. We could provide it by 
Wednesday.


Regards,
Sven

[1] - _https://github.com/eclipse/xtext-eclipse/issues/393_ 

[2] - _https://bugs.eclipse.org/bugs/show_bug.cgi?id=525462_ 



--
Sven Efftinge

TypeFox GmbH
Am Germaniahafen 1
24143 Kiel

Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385
Managing Directors: Sven Efftinge, Moritz Eysholdt, Dr. Jan 
Köhnlein___
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=_xjYWLkqX6J0VN-uMpnmC15-iZH4bZE-uyC5O4uesB8=Bf6rr6RlsSxmzemmUU16GsrmA2iVPB9YIxwpcX0JnFs=



___
eclipse-pmc mailing list
eclipse-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc



___
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] Eclipse plug-ins as automatic modules in Java 9?

[Stephan Herrmann]

Hi,

I just noticed by chance that none of the artifacts we are producing
are consumable as "automatic modules" in Java 9 speak.

The reason is: JPMS defines an algorithm how names for automatic modules
are derived from the jar file name. Unfortunately, the spec expects any
version to be separated from the name by "-", whereas our files use "_".

As a result a jar file like
   org.eclipse.equinox.common_3.9.0.v20170207.jar
is interpreted as an automatic module named
   org.eclipse.equinox.common.3.9.0.v20170207
(cutting off the version fails, then "_" is converted to ".").

Since that module name is not a legal Java identifier, the given jar file
cannot be referenced in any "requires" clause of a Java 9 module.

While all this is very unfortunate, Java 9 provides a means for a systematic
solution: adding an Automatic-Module-Name header to MANIFEST.MF.

Hence, I propose to make this a rule for future releases that all bundles
should have this manifest header, where the value should be identical to
the value of Bundle-SymbolicName.

There may not yet be any consumers of Eclipse plug-ins as Java 9 modules,
but as we know that several of our artifacts are being consumed outside OSGi,
I am sure that clients will expect our artifacts to be consumable as Java 9
modules sooner or later. And then a general solution looks cleaner to me
then doing this for selected artifacts only.

best,
Stephan

Reference for naming of automatic modules:
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-
___
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] hipp9 overloaded

[Stephan Herrmann]

Could this be a general issue?
The factor of 4 looks similar to what I see in hipp10 (Object Teams).

Some figures:
Two individual test suites A and B as part of the Object Teams build over time
(from some builds which I happened to keep):

up-to 2016-12-08:
suite A: around 30 min.
suite B: around 30 min.

2017-01-18:
suite A at 47 min.
suite B presumably timed out after 120 min (details no longer available)

2017-01-22:
suite A at 44 min.
suite B completed at 110 min

2017-01-27:
suite A at 60 min.
suite B presumably timed out after 120 min (details no longer available)

2017-02-04:
suite A timed out at 120 min
suite B died at 50 min (not sure if this could possibly be a time out)

Several intermediate builds timed out, providing no useful test results.

To check if this could be a regression in the software being tested, I 
inspected logs from
local test runs over the given period, which, however, show no performance 
regression.

When I looked up the various hipps on this hipp10, I couldn't see much info 
about
build history, in fact only the platform hipp has data in the build history 
view.

The same suite A is actually part of JDT/Core so we can do some comparison of 
the
Object Teams HIPP with eclipse.jdt.core-Gerrit on Platform HIPP (same machine 
hipp10!).
On the latter HIPP we observe alternating time outs but also test runs 
completing
normally at the typical 30 min.


In this situation I have to run each build several times until I happen to get
complete test results. Of course these unnecessary test runs aggravate the 
situation...

Short term work around: stop using hipp for testing, test only locally (saves 
much time)
use hipp only for building / publishing - which will also take some load from 
that machine.

Maybe we should all do this to retain good response times at least for the 
actual
production builds?

best,
Stephan


On 02/02/2017 08:08 AM, Markus Knauer wrote:

I see similar problems on hipp8. Its reported load is between 1 and 2 at the 
moment, sometimes less, i.e. not very high, but the EPP
package builds are extremely slow, much slower than usual. A few months ago in 
October these builds used to take 1:20h [1], now we
are close to 6 hours [2] which is 4 times slower for the same build. In both 
cases, builds were running on a day during Simultaneous
Release week which rules out this as a reason for the increased duration.

Maybe its worth to look at this host, too, as the increased build time doesn't 
seem to be caused by a high load of the CPU.

And I highly appreciate your efforts to distribute CPU resources in a better 
way!

Much thanks,
Markus

[1] https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/448/
[2] https://hudson.eclipse.org/packaging/job/oxygen.epp-tycho-build/183/



On 2 February 2017 at 01:22, Frederic Gurr > wrote:

Hi,

Unfortunately hipp9 has been experiencing a near-constant high load
during work hours. Due to a few projects hogging resources other
projects are severely constrained and have problems running their builds
in a timely manner.

To fix this, I have taken the following near term steps:

- Papyrus HIPP
  - disabled execution of concurrent builds for "Papyrus-Gerrit-Oxygen"
  - limited the number of executors to 2

- EMF Compare HIPP
  - limited the number of executors to 2

I will also move the EMF Compare HIPP to a different hipp machine
tomorrow at 9am EST. Downtime will be less than one hour.

We will also investigate how CPU usage can be limited to ensure a fair
distribution of resources.

Regards,

Fred
___
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] hudson job fail

[Stephan Herrmann]

On 11/17/2016 06:59 PM, Greg Watson wrote:

Hi,

My hudson job is failing with this error. Does anyone have any idea why?

Thanks,
Greg

Nov 17, 2016 12:57:40 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn

> [...]

Caused by: java.lang.UnsupportedClassVersionError: 
org/eclipse/tycho/core/p2/P2ArtifactRepositoryLayout : Unsupported major.minor 
version 52.0


Using a tycho version that's requires Java 8, and running on Java <= 7?

Stephan

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Object Teams participation in Oxygen

[Stephan Herrmann]

Hi,

Object Teams will be participating in the Oxygen Simultaneous Release with an 
offset of +2.
Release Record: 
https://projects.eclipse.org/projects/tools.objectteams/releases/2.6.0

best,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Git servers not working well?

[Stephan Herrmann]

On build.eclipse.org I consistently received git: Connection refused,
but after changing protocol from git: to https: all was fine.

Stephan

On 10/29/2016 08:07 PM, Ed Willink wrote:

Hi

With the OCL HIPP, I can usually (75% success) get one build after restarting 
before the GIT connection fails again.

Regards

Ed Willink


On 29/10/2016 00:04, Matthias Sohn wrote:

EGit HIPP is again broken, restarting it didn't help to regain access to 
git.eclipse.org 
https://hudson.eclipse.org/egit/job/egit-stable.gerrit/908/console

On Fri, Oct 28, 2016 at 10:36 PM, Andrey Loskutov > wrote:

Thank you Frederic!

Am 28. Oktober 2016 22:35:24 MESZ, schrieb Frederic Gurr >:
>I've restarted the platform HIPP and now it works again.
>
>On 28.10.2016 22:16, Andrey Loskutov wrote:
>> Platform UI still has issues:
>>

>https://hudson.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/11059/console


>>
>>
>> Am 28. Oktober 2016 22:14:01 MESZ, schrieb Frederic Gurr
>>:
>>> Matt had to kill some wild running git daemon processes.
>>> And yes, the "connection refused" errors happened during the process
>of
>>> fixing this.
>>> Now Git should work again.
>>>
>>> On 28.10.2016 22:00, Roland Grunberg wrote:
> Yes, I'm seeing the same thing on the linuxtools-gerrit instance.
>In
> fact even cloning from the commandline fails.
>
> I'm no longer seeing 'connection reset by peer' now, but I am
>seeing
>>> :
> 'git.eclipse.org [0: 198.41.30.196]: 
errno=Connection refused'.

 I've done a simple reboot of our HIPP and fetching against
 git.eclipse.org  seems to work. Not sure if 
the reboot had anything
>to
 do with it, or if it was probably in the process of being fixed
 anyways.

 Cheers,

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

>>
>> --
>> Kind regards,
>> Andrey Loskutov
>>
>> http://google.com/+AndreyLoskutov 
>>

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





Avast logo   

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

Re: [cross-project-issues-dev] CodeEnvy continues to use deceptive wording that's harmful to Eclipse

[Stephan Herrmann]

On 06/30/2016 10:27 AM, Eike Stepper wrote:

Hi All,

I have not a very strong opinion on this wording, but it strikes me that their wording is 
unnecessarily biasing. "Next-generation"
does imply that it's a newer and better variant of something that's older and 
less good.


IMHO, "next generation" implies even more: that the "old generation" is no 
longer actively developed.
If that sinks in in people's mind, that would be doing real harm.

BTW: when Orion was new, I remember people like Mike M. making it more than clear that 
Orion is *not* "Eclipse in the browser".

my 2c.
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Stephan Herrmann]

This thread is an awesome proof that the Eclipse community is
alive and kicking.

I appreciate Ian taking steps to help the Eclipse community to
stay relevant. And I appreciate most of the concerns expressed
regarding UUID-based data collection. Little to add.

Just looking at this statement:

On 06/04/2016 05:11 PM, Ian Skerrett wrote:

The starting point has been we can use this data to improve the Eclipse 
community.
I hope that if we can start using real facts based on data, not guesses,
this will be a service for the entire community. Most organization are now 
moving
towards data-driven decision making. I think Eclipse should be moving in this 
direction too.


Let me take a radical position for a second: it's not just privacy
in the traditional sense ("spying out my secrets") that's at stake.
People are starting to be concerned also about big business turning
people into data collection devices. Put bluntly: big organizations
decide how they utilize people for producing the information from
which they will generate their profits.

I'd see it as a big loss, if public perception regards Eclipse
as moving towards the big Big Data Business (speaking only of
perception, not intention).
I personally don't think Eclipse should be moving towards
data-driven decision making (which decisions, btw.?).

What are the risks:

- If Neon is rolled out with UUID enabled this will definitely
  send some message to our user community, which certainly is
  not backed by a consensus and will be hard / impossible to
  retract later.

- If UUID is disabled for Neon, our download statistics will
  remain vague (for now).

To me this sounds like a no-brainer: to pull the plug for Neon,
reschedule for Neon.1 under the precondition we achieve some
kind of consensus by then.

Technical question: is disabling UUID s.t. which EPP can do?

cheers,
Stephan

PS: There is this slight hunch about Europeans being more than
average concerned about a lot of things. I don't have the data
to back this observation :) - sounds like a great topic over
more than one beer. But for this thread "Europe vs. America"
is probably not a helpful question, right?

___
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] Enforce Gerrit for Simrel?

[Stephan Herrmann]

I like gerrit for long-running tests so I can start the next task
while tests are still running on the server.
Running b3 validation in the b3 editor is not what I call a long-running test,
I rather feel it convenient to validate locally, before pushing to the server.
Does the Gerrit validation job perform additional validations that I don't
get in the IDE?

Also my gut feelings says, that if everybody has to go through gerrit,
we will see lots of rebase-jobs piling up, just because during one
validation job s.o. else has merged his changes and hence other changes
cannot be merged before doing a rebase, triggering another validation job etc.
I'm not sure if gerrit is perfect for this many concurrent pushes to the
same repo in such a short time frame.

Stephan


On 01/07/2016 12:55 PM, Mickael Istria wrote:

Hi all,

Gerrit for SimRel has been widely used by many projects and the validation 
checks that come with Simrel have successfully caught a
bunch of issues before the had the opportunity to break the Simultaneous 
Release. Gerrit and Code-Review can have an incredible
effect on software quality, many projects and teams enforce it with success. I 
don't have metrics, but maybe David can say whether
he felt a noticeable improvement in stability/quality since the inception of 
Gerrit a few months ago?

I believe it's the right time to start considering enforcing Gerrit usage for 
SimRel: a first implementation would be to have
committers push to refs/for/master instead of master, and would either be 
reviewed by someone else, or review themselves their
contribution. The Hudson validation job triggers automatically on any 
contribution and gives a vote if the contribution is breaking
the build.

What do you think?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat 
My blog  - My Tweets 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] Object Teams will participate in Neon

[Stephan Herrmann]

I have created the following release record for Object Teams 2.5.0 (Neon):
https://projects.eclipse.org/projects/tools.objectteams/releases/2.5.0

We will contribute to simrel at offset +2.

I will still keep the simrel contribution disabled for M3, because:

As of M2 I had to disable the contribution, because it simply couldn't cope
with class files from Platform that are now compiled at compliance 1.8.
At EclipseCon Europe I gave the first successful demo of a new runtime
environment ("Runtime Specialization ..."), but as of M3 this still has
a number of known bugs which might degrade the general user experience.

I'm confident that issues will be sorted out in time for joining the
aggregation for M4.

Thanks,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Stephan Herrmann]

Tom,

I don't see a conflict between Jay's and your observations:

Yes, users will be able to create / compile / package modules.
No, users will not create Jimage files.

Whether or not it is a module is a conceptual question. It needs
a module-info.java / module-info.class and there you are.

The Jimage format, by contrast is a purely technical question
of how bits and pieces are encoded / packaged.
JDK uses Jimage to ship their libraries, user modules are
shipped as jars.

So when you convert a "legacy" user library into a module,
technically that would be a jar -> jar transformation.

Makes sense?
Stephan


- ursprüngliche Nachricht -

Subject: Re: [cross-project-issues-dev] Announcing JDK 9 support for Eclipse 
Neon
Date: Mi 28 Okt 2015 04:30:11 CET
From: Tom Schindl
To: cross-project-issues-dev@eclipse.org

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


 ursprüngliche Nachricht Ende 
___
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] Git doesn't work with IOException: End of IO Stream Read

[Stephan Herrmann]

Have you seen https://bugs.eclipse.org/478690 ?
It also links to the early thread in this list titled "Git outage?"

HTH,
Stephan

On 10/04/2015 09:59 AM, Alexander Gurov wrote:

Hello everyone,

While Git works fine for some projects (SimRel, for example), for some other it 
fails (at least for our web site project) and I was
unable to find nor the reason, nor the solution to the problem.
So, if there is anyone who knows what to do, any help is much appreciated.

P.S.
In case it is important, I'm using Eclipse Luna SR2 with all updates already 
installed. Also at least it worked just for this
project 10 days ago.

org.eclipse.jgit.api.errors.TransportException: 
ssh://agu...@git.eclipse.org/gitroot/www.eclipse.org/subversive.git:
Session.connect: java.io.IOException: End of IO Stream Read
 at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
 at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:253)
 at org.eclipse.egit.core.op.PullOperation$1.run(PullOperation.java:97)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313)
 at org.eclipse.egit.core.op.PullOperation.execute(PullOperation.java:128)
 at 
org.eclipse.egit.ui.internal.pull.PullOperationUI.execute(PullOperationUI.java:139)
 at 
org.eclipse.egit.ui.internal.pull.PullOperationUI$1.runInWorkspace(PullOperationUI.java:114)
 at 
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.jgit.errors.TransportException: 
ssh://agu...@git.eclipse.org/gitroot/www.eclipse.org/subversive.git:
Session.connect: java.io.IOException: End of IO Stream Read
 at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)
 at 
org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:121)
 at 
org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.(TransportGitSsh.java:248)
 at 
org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
 at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
 at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
 at org.eclipse.jgit.transport.Transport.fetch(Transport.java:)
 at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
 ... 8 more
Caused by: com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: 
End of IO Stream Read
 at com.jcraft.jsch.Session.connect(Session.java:558)
 at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
 ... 15 more



___
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 (still) using BCEL?

[Stephan Herrmann]

Hi,

Object Teams is facing problems after the platform's move to Java 8,
because our traditional bytecode weaver is based on BCEL 5.2, which
cannot handle Java 8 bytecode.

While we have a new ASM-based weaver about ready for prime-time,
I would love to keep the BCEL-based weaver as an option.
(They do have some fundamentally different properties).

Are any other Eclipse projects are (still) using BCEL?
I can see that BCEL has fixed the problem in their code.
While a BCEL 6.0 release is dragging over many months now,
maybe we could adopt their latest release candidate into Orbit?

Anyone to join forces?
Has there been precedent of packaging a non-final release in Orbit?

regards,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Git outage?

[Stephan Herrmann]

I've seen similar exceptions.
I was suspecting a jsch version-problem to be the cause.
After updating a bunch of stuff including EGit I could connect again.

HTH
Stephan

On 09/29/2015 09:25 PM, Konstantin Komissarchik wrote:

I am getting a failure when pushing or pulling from Git this morning. Is anyone 
else seeing this?

org.eclipse.jgit.api.errors.TransportException: 
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git:
Session.connect: java.io.IOException: End of IO Stream Read

 at 
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)

 at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:263)

 at 
org.eclipse.egit.core.op.PullOperation$1.run(PullOperation.java:97)

 at 
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2242)

 at 
org.eclipse.egit.core.op.PullOperation.execute(PullOperation.java:128)

 at 
org.eclipse.egit.ui.internal.pull.PullOperationUI.execute(PullOperationUI.java:140)

 at 
org.eclipse.egit.ui.internal.pull.PullOperationUI$1.runInWorkspace(PullOperationUI.java:115)

 at 
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)

 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Caused by: org.eclipse.jgit.errors.TransportException:
ssh://kkomissarc...@git.eclipse.org/gitroot/sapphire/org.eclipse.sapphire.git: 
Session.connect: java.io.IOException: End of IO
Stream Read

 at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)

 at 
org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:136)

 at 
org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.(TransportGitSsh.java:262)

 at 
org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:161)

 at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)

 at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)

 at 
org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)

 at 
org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)

 ... 8 more

Caused by: com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: 
End of IO Stream Read

 at com.jcraft.jsch.Session.connect(Session.java:558)

 at 
org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)

 ... 15 more



___
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] Maintenance builds (was Announcing a one week slip in the Mars.1 release (from 9/25 to 10/2))

[Stephan Herrmann]

Hi,

I don't see an easy solution but I do share Ed's concerns in this regard.

Is this just a packaging issue or an issue of content?
Aside from the Eclipse project, how many projects are actively
maintaining maintenance branches (no pun intended)?
Meaning: if we'd provide a channel for obtaining maintenance
updates only, what would be the content of the channel,
only platform updates?
Do projects with a lower offset within SimRel perhaps
care more about maintenance than "leaf" projects?

Honestly tell me: Is doing maintenance releases a relic from
the olden days in an ever accelerating world?

Stephan

On 09/24/2015 05:13 PM, Ed Willink wrote:

Hi

That makes sense but shows that we are just shifting the problem.

I see a requirement for
- regular base releases (yearly)
- maintenance releases (four monthly)
- responsive releases (four monthly)

Recognising that maintenance releases were being abused to provide responsive 
releases is probably good, but waving goodbye to
maintenance releases is bad.

IMHO we need all three and so long as we try to make do with two we will be in 
trouble with some user community. It seems wrong that
because some projects have abused the principles of maintenance, users of other 
projects that have observed maintenance discipline
suffer.

 Regards

 Ed Willink

On 24/09/2015 15:35, Ian Bull wrote:

Ed,

The reason for the change from Mars SR1 to Mars 1 is because this is how we've 
been doing it for years. Many people (EGit / JGit,
Mylyn, CDT -- to name a few) had been putting minor releases in the release 
train during the SRs. I ran some numbers last year,
and > 1000 Installable Units had incremented their minor version number between 
SR0 and SR2. This means, assuming people are
following the version guidelines, that up to 1,000 bundles had already been 
adding new API between SR0 and SR2.

Changing the name of the train just means we are acknowledging what was already 
happening.

Cheers,
Ian

On Wed, Sep 23, 2015 at 11:21 PM, Ed Willink > wrote:

HI

Surely this is the inevitable consequence of Mars.1 rather than Mars SR1?

SR1 required each component to be a safe upgrade so that exact release 
timing was irrelevant.

Mars.1 is a new release so users must get to see the co-ordinated new 
release in one go rather than incrementally. If A.1
pulls in B.1, but C uses B, users of C are in a mess until they get C.1.

Regards

Ed Willink



On 24/09/2015 05:26, Gunnar Wagenknecht wrote:

David,

Am 23.09.2015 um 23:37 schrieb David M Williams 
<david_willi...@us.ibm.com>:
If not obvious, this means all participants in "coordinated release 
train" should not make your releases visible on
9/25, but wait until 10/2 10 AM to make them visible, and announce 
your official releases.

This seem unnecessarily restrictive. I don't bother with the 
announcement part. However, I don't recall there is something
in the process that requires project to wait publishing the release 
bits. Not making them visible could have a huge effect
on a project's adopter community.

-Gunnar


___
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




--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | 
http://twitter.com/eclipsesource


___
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


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2015.0.6140 / Virus Database: 4419/10692 - Release Date: 09/24/15





___
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] Unannounced Changes Have Unforeseen Consequences

[Stephan Herrmann]

I like the idea of 5.0 for API removal. To minimize impact on adopters:
why not schedule the jump to 5.0 for Neon+1 as to give projects a chance
to include more removal of deprecated API at once? I believe the currently
discussed API removal could easily wait until Neon+1? Then API cleanup
would be a prominent theme of that release.

Stephan

On 09/14/2015 05:13 PM, Ed Willink wrote:

Hi

Sorry Ian. See https://wiki.eclipse.org/Version_Numbering#Versioning_features

/Increment the feature's major number if any contained plug-in or feature 
increases their major number //
/
It is certainly possible for plugin major version changes to be a creeping 
disease but the feature changes with the first plugin.

If different plugins change every milestone, you maximize difficulties for 
consumers.

Much better to go for 5.x outright and we all take the hit just once.

 Regards

 Ed Willink

On 14/09/2015 16:02, Ian Bull wrote:

I may be wrong, but I don't think that updating a single bundles major version 
requires the product version number to be updated.
Eclipse currently ships with bundles numbered from 1.x (jface.databinding) to 
8.x (jetty) and we've been using 4.x as the product
version for years. I agree that we should follow our semantic version rules for 
bundles & features. Our entire base platform (OSGi
& p2) depend on this.

Does anyone have a link to how the product version relates to the bundles 
contained within the product?

Cheers,
Ian



On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik
<konstantin.komissarc...@oracle.com> 
wrote:

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an
important tool in ensuring that we create valid installations that don’t 
break with class not found or method not found errors.

- Konstantin

*From:*cross-project-issues-dev-boun...@eclipse.org 

[mailto:cross-project-issues-dev-boun...@eclipse.org 
] *On Behalf Of
*John Arthorne
*Sent:* Monday, September 14, 2015 7:27 AM
*To:* cross-project-issues-dev@eclipse.org 

*Subject:* Re: [cross-project-issues-dev] Unannounced Changes Have 
Unforeseen Consequences

Hi everyone,

This has been a great discussion. I have a few points to add:

- It is very important for the Platform (and other projects) to have the 
right to occasionally remove API. In a nutshell,
maintaining API forever generally benefits existing consumers but adds pain 
and cost for those maintaining the API. As the
number of API maintainers has dwindled, the Platform made a deliberate 
choice about 5 years ago to slightly relax its previous
stringent API maintenance practices. There are APIs in Platform none of the 
remaining committers understand or use, and it
creates a large burden on them to maintain it. The huge API surface area of 
the Platform also creates a burden for new
consumers. When there are 5 available ways to do something with the 
Platform API, removing some of the oldest and least
recommended options helps new adopters chose the right path. While this 
depends on your perspective, I think moving the needle
slightly in favor of committers and new adopters is beneficial for the 
future of the Platform, even if there is some impact
for legacy code consumers.

- In this particular case, the Platform API removal process was not 
completely followed [1, 2]. The removal is being reverted
for the next Platform integration build. The API may still be removed in 
the June 2017 simultaneous release, so if you have
already taken steps to adopt the changes, consider yourself ahead of the 
game :) It is important for API removals to be widely
announced, and a justification given to the community who will be impacted 
by it. I apologize for this not being done in this
case.

- On the topic of semantic versioning, there is no easy answer. 
Incrementing the major version number of a bundle in the
Platform is guaranteed to have a massive impact on adopters, even if they 
did not use the particular API that was affected.
Nearly every annual release of the Eclipse Platform has had some very minor 
API breakage, which is always carefully documented
in the migration guide. If we strictly followed Semantic Versioning, the 
major version of much of the Platform would now be
around 12 or so by now, and adopters would have learned to completely 
remove the upper bound from their version ranges to
avoid being constantly broken at the bundle metadata level. What we have 
always done in the Platform is try to have the
version numbers reflect the anticipated overall impact on clients. In most 
release, the API is 99.9% compatible and we don't
let the rare 

Re: [cross-project-issues-dev] When are Gerrit commits automatically applied?

[Stephan Herrmann]

I'm not sure what's the goal here?
Enable submit-to-gerrit-and-leave -
without awaiting the result from hudson? ;P
If you wait for success, what harm is done by having
to do two more clicks?

my 2c.
Stephan

On 05/20/2015 07:44 AM, Eike Stepper wrote:

Hi,

I'm not a Gerrit expert, but a quick search for gerrit auto approve gives a 
number of hints, for example a Gerrit hook script:
http://renier.morales-rodriguez.net/post/49144483266/configuring-gerrit-to-auto-submit-on-patch-ap

Personally I'd also like it if my simrel patch sets would be submitted 
automatically if Hudson gives a +1, but I'm not sure if
that's a security concern.

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 18.05.2015 um 19:24 schrieb Mickael Istria:

On 05/18/2015 06:43 PM, David M Williams wrote:

I don't know the answer to Sven's question ... quoted here ... does anyone else?

 Am I right if committer of the org.eclipse.simrel.build Git repo
 must be manually set them as code reviewer if they want to apply the
 patch to the Git repo? I've hoped that the push is automatically
 done if the Hudson build is successful and a fast forward merge is possible.

I would hope that it would be applied automatically ... but, from my experience 
it doesn't seem to be. But, I've only done it a
few times,
and hope a more Gerrit knowledgeable person can answer authoritatively ... as well as 
make sure the right thing happens, if it
takes a new bug for webmasters or others to change some setting.

Gerrit requires a manual approval from a Simrel committer to merge a commit. 
There is no mechanism to automatically merge a review
if automated tests have succeeded; and since I believe the paradigm of Gerrit 
and code-review is really to involve an additional
human step (in best case a 3rd-party) in the change, automating merge is 
probably not something desirable.
However, as a committer, you can apply your own patch via Gerrit UI, or push 
without using a Gerrit review (and automated tests).
https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simrel_Aggregation_Build#Pushing_your_changes

HTH
--
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
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] When are Gerrit commits automatically applied?

[Stephan Herrmann]

On 05/21/2015 12:11 AM, Konstantin Komissarchik wrote:

[...] but once that
verification has been done, what's the value of waiting for the developer to
click on things?


Maybe encouraging the developer to wait until s/he knows whether the job is 
done or not?
:)

Disclaimer: as much as I like gerrit, for simrel contributions I still
prefer running the validation at home and then push directly ..
Call me I'm old-school, if you like.

Stephan


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Stephan
Herrmann
Sent: Wednesday, May 20, 2015 2:42 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] When are Gerrit commits
automatically applied?

I'm not sure what's the goal here?
Enable submit-to-gerrit-and-leave -
without awaiting the result from hudson? ;P If you wait for success, what
harm is done by having to do two more clicks?

my 2c.
Stephan

On 05/20/2015 07:44 AM, Eike Stepper wrote:

Hi,

I'm not a Gerrit expert, but a quick search for gerrit auto approve

gives a number of hints, for example a Gerrit hook script:

http://renier.morales-rodriguez.net/post/49144483266/configuring-gerri
t-to-auto-submit-on-patch-ap

Personally I'd also like it if my simrel patch sets would be submitted
automatically if Hudson gives a +1, but I'm not sure if that's a security

concern.


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 18.05.2015 um 19:24 schrieb Mickael Istria:

On 05/18/2015 06:43 PM, David M Williams wrote:

I don't know the answer to Sven's question ... quoted here ... does

anyone else?



Am I right if committer of the org.eclipse.simrel.build Git repo
must be manually set them as code reviewer if they want to apply
the patch to the Git repo? I've hoped that the push is
automatically done if the Hudson build is successful and a fast

forward merge is possible.


I would hope that it would be applied automatically ... but, from my
experience it doesn't seem to be. But, I've only done it a few
times, and hope a more Gerrit knowledgeable person can answer
authoritatively ... as well as make sure the right thing happens, if

it takes a new bug for webmasters or others to change some setting.

Gerrit requires a manual approval from a Simrel committer to merge a
commit. There is no mechanism to automatically merge a review if
automated tests have succeeded; and since I believe the paradigm of

Gerrit and code-review is really to involve an additional human step (in
best case a 3rd-party) in the change, automating merge is probably not
something desirable.

However, as a committer, you can apply your own patch via Gerrit UI, or

push without using a Gerrit review (and automated tests).

https://wiki.eclipse.org/index.php?title=Simrel/Contributing_to_Simre
l_Aggregation_Build#Pushing_your_changes

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



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Heads-up: core.expressions has increased to 3.5.0

[Stephan Herrmann]

On 05/01/2015 02:08 PM, Markus Keller wrote:

To those who had a wrong version range like [3.4, 3.5): Please find the bug in 
your process that introduced this too-narrow
dependency in the first place. If a tool generated that dependency, then please 
file a bug for that tool.

https://wiki.eclipse.org/Version_Numbering#How_to_specify_plug-in_requirements


This statement is correct wrt rules  theory.

From practical experience I'd like to add that the problem runs deeper:
I've developed tools that got broken even by micro updates from
other Eclipse projects.

I read Markus' statement as a reminder that for Eclipse SDK bundles,
upper bounds of major+1 *should* be the right thing to do, agreed.

Unfortunately, this doesn't appear to be good advice for all of the
release train.

We could start a discussion about stricter enforcement of semantic
versioning on the release train (incl. an update of what exactly is
compatible API evolution wrt various technologies).

Or we can accept the current state of affairs as reality. This would
imply that letting any tool generate dependencies is insufficient -
it requires human judgment to decide which range is appropriate for
which dependency.

Or maybe both.

cheers,
Stephan

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Automatic Bugzilla updates (Gerrit and Commit references) from Gerrit

[Stephan Herrmann]

thanks for prompt action as usual

On 02/10/2015 02:28 PM, Denis Roy wrote:

Indeed, I've reverted part of that change.

I can support Bug: 12345 and [12345] (with square brackets) quite reliably, but 
not 12345.



On 10/02/15 06:40 AM, Stephan Herrmann wrote:

Denis hit the nail:

Please see all the fresh and wrong comments in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=41503

This is a no-go.

Stephan

On 02/09/2015 05:08 PM, Denis Roy wrote:

The question that comes to my mind is: why not simply adopt Bug: XX as the 
standard?

458123 could be a bug number, a reference to a Gerrit change number, a mailing 
list post or anything.

At some point we have to choose a format.

In any case, if you feel strongly about supporting other formats, please file a 
bug and gather community support for it. We need to
make sure additional formats are supported in Gerrit, in the Gerrit plugin and 
in the cGit code browser.

Denis


___
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] Gerrit down?

[Stephan Herrmann]

On 01/14/2015 11:11 PM, Greg Watson wrote:

Is anyone else seeing “Service Temporarily Unavailable” for Gerrit?


Yep, see 
http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg01030.html

Stephan

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Object Teams participation in Mars

[Stephan Herrmann]

Object Teams will participate in the Mars simultaneous release
with an offset of +2. We plan to contribute release 2.4.0:

https://projects.eclipse.org/projects/tools.objectteams/releases/2.4.0

best,
Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Cannot launch p2 director with Luna SR1 RC2 build

[Stephan Herrmann]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=441377#c3

I true blocker ...

On 09/02/2014 06:17 PM, Konstantin Komissarchik wrote:

I picked up the Luna SR1 RC2 build this morning and I am seeing the following 
failure in Equinox when p2 director is called. The
Eclipse IDE starts up without any apparent issues on the same install. This 
issue wasn’t there in RC1 and I am seeing this on two
different build systems, so I am reasonably sure that this is not an issue on 
my end.

  [java] An error has occurred. See the log 
filejava.lang.NullPointerException

  [java]

  [java] null.

  [java]  at 
org.eclipse.osgi.internal.framework.EquinoxConfiguration.init(EquinoxConfiguration.java:207)

  [java]  at 
org.eclipse.osgi.internal.framework.EquinoxContainer.init(EquinoxContainer.java:69)

  [java]  at org.eclipse.osgi.launch.Equinox.init(Equinox.java:31)

  [java]  at 
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:299)

  [java]  at 
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)

  [java]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  [java]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

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

  [java]  at java.lang.reflect.Method.invoke(Method.java:483)

  [java]  at 
org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)

  [java]  at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)

  [java]  at org.eclipse.equinox.launcher.Main.run(Main.java:1465)

  [java]  at org.eclipse.equinox.launcher.Main.main(Main.java:1438)

  [java]  at org.eclipse.core.launcher.Main.main(Main.java:34)

Here is the launching instructions…

 java classname=org.eclipse.core.launcher.Main fork=true 
failonerror=true

   classpath

 fileset dir=${bootstrap.platform}/plugins

   include name=**/org.eclipse.equinox.launcher_*.jar/

 /fileset

   /classpath

   arg line=-application org.eclipse.equinox.p2.director/

   arg line=-metadataRepository ${.repositories}/

   arg line=-artifactRepository ${.repositories}/

   arg line=-destination @{dest}/

   arg line=-installIU @{extensions}/

   arg line=-vmargs/

   arg line=-Declipse.p2.data.area=@{dest}/p2/

   arg line=-Declipse.p2.unsignedPolicy=allow/

   jvmarg line=-Xmx512m/

 /java



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
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] Cannot launch p2 director with Luna SR1 RC2 build

[Stephan Herrmann]

On 09/02/2014 06:26 PM, Stephan Herrmann wrote:

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=441377#c3

I true blocker ...


In plain words: due to this bug Object Teams will not be able to contribute
to SR1 RC2.

Stephan


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Cannot launch p2 director with Luna SR1 RC2 build

[Stephan Herrmann]

The fix (as of build M20140902-1430) appears to be working fine.

thanks,
Stephan

On 09/02/2014 08:15 PM, Daniel Megert wrote:

We will produce an RC2a once the fix is ready.

Dani



From: Stephan Herrmann stephan.herrm...@berlin.de
To: Cross project issues cross-project-issues-dev@eclipse.org
Date: 02.09.2014 18:28
Subject: Re: [cross-project-issues-dev] Cannot launch p2 director with Luna SR1 
RC2 build
Sent by: cross-project-issues-dev-boun...@eclipse.org




On 09/02/2014 06:26 PM, Stephan Herrmann wrote:
  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=441377#c3
 
  I true blocker ...

In plain words: due to this bug Object Teams will not be able to contribute
to SR1 RC2.

Stephan


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




___
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] org.eclipse.jdt.core from objectteams gets selected due to higher version

[Stephan Herrmann]

On 06/27/2014 05:34 PM, Doug Schaefer wrote:

But I do remember a lot of concern when this came along and Max's question is a 
valid one to ask. We do have two JDT's in the simrel repo. That's pretty scary.

Doug


OK, I had to dig 3+ years into the past to find the original agreement.
Here are the main references for your convenience:


The general case was discussed in this bug:
  https://bugs.eclipse.org/330312
Conclusion: no new rules needed for such a rare situation.
The special case should be handled via a request for exception.

Request for exception was raised via tools PMC:
  http://dev.eclipse.org/mhonarc/lists/tools-pmc/msg01491.html

The result was to make the decision depend on an agreement
between JDT and Object Teams. This reflects the discussion in
both tools PMC and Planning Council.

This agreement has been achieved in a phone call between Dani
and myself. After that call, I brought the request to the
eclipse PMC:
  http://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg01338.html
In that thread you find Dani's confirmation, four +1 votes,
and no 0 or -1 votes.


Aside from formal process, need I assure anybody on this list,
how much I care about the quality and reputation of JDT?

best,
Stephan

___
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] org.eclipse.jdt.core from objectteams gets selected due to higher version

[Stephan Herrmann]

Hi Doug,

On 06/27/2014 06:36 PM, Doug Schaefer wrote:

I guess the real question, is that if someone ends up with the
OTDT version of the JDT, do bad things happen?


JDT has occasionally received a bug report that was actually a bug in OTDT.
The same happens with Groovy as well. From memory I'd say that the latter
is more frequent, but definitely neither source of bugs is relevant to the
overall quality of JDT (Andy's role is quite similar to mine, actually).

 I agree you followed all that was asked of you, but I think we assumed and

I do hope you've accomplished what's best for the community at large.
What were the plans to mitigate these issues?


For the community at large, the p2 related measures, which have been
discussed here and there, should avoid the problem from the outset.
Other than that our main strategy is:

Every Object Teams build runs *all JDT tests*

To be fully open: the Luna build triggered a few failures in
JDT/UI's LeakTestSuite, which could be a hard-to-reproduce bug
in the original JDT/UI or caused by OTDT (*if* caused by OTDT,
its definitely not caused by the o.e.jdt.core variant, hence
not relevant to this thread).
Other than that every release of OTDT passes all JDT tests.

I only see one potential danger: if our variant of o.e.jdt.core
accidentally publishes some additional API in JDT's namespace
this could theoretically cause incompatibility.
Real life combination of OTDT with other plugins consuming JDT
has never revealed any such problem.
Still, during Mars I will give it an extra round of reviewing to
check if there might be any case of not being binary compatible.

I am not saying all consumers should get the OTDT variant :)
but even *if* a few get it by accident, it don't see any harm.

Am I missing any other issues you'd like to see addressed?

best,
Stephan

___
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] org.eclipse.jdt.core from objectteams gets selected due to higher version

[Stephan Herrmann]

On 06/25/2014 12:09 AM, Thomas Hallgren wrote:

I just encountered a build failure when using the platform repository in 
conjunction with the luna staging one. The failure was
caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor 
of the original. Seems the patch has a higher
version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform 
repo (3.9.2.v20140114-1555). I don't recall having seen
this problem before so something must be different. Anyone have a clue as to 
what might be causing this?


One thing, exactly, has changed in Object Teams in this regard:
I followed Pascal's advice for avoiding unintended updates from
the original to the OTDT variant.

On 06/25/2014 09:13 AM, Sievers, Jan wrote:
 looks similar to

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

That's the exact reference to our best effort to improve this.

I double checked and from all I can see the meta data looks
exactly as advised:
- the OTDT variant of org.eclipse.jdt.core has a non-greedy
  dependency on our patch feature (since Juno)
  - cannot be installed without explicitly selecting that
 patch feature.
- the patch feature is marked as a patch for the *bundle*
  org.eclipse.jdt.core, not for the jdt feature (new in Luna).
  - patch feature is not regarded as an update of the
 jdt feature.

Can you share a setup for reproduction?
The reference to 3.9.2... looks fishy, indeed.

regards,
Stephan

___
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] org.eclipse.jdt.core from objectteams gets selected due to higher version

[Stephan Herrmann]

On 06/25/2014 02:17 PM, Thomas Hallgren wrote:

My guess is that the reason it gets selected by p2 is that the version

  3.10.0.v_OTDT_r230_201406101339

is lexically greater than

  3.10.0.v20140604-1726

since '_' (0x5f) is greater than '2' (0x32)


This is intended and required to make the patch feature work.
Please note that this has not changed since Juno.

Is your build including the feature 
org.eclipse.objectteams.otdt.core.patch.feature.group?
If that's not explicitly included and the OTDT variant is still selected,
then someone is preferring a solution with unmet dependencies over another
solution that is good indeed. Could be a bug in p2. I don't know.

regards,
Stephan




___
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] IP Logs for Luna are due tomorrow

[Stephan Herrmann]

On 05/23/2014 08:15 AM, Ed Willink wrote:

On 23/05/2014 01:43, Wayne Beaton wrote:


At the bottom of your project's PMI page,

Which page is that? The main view, or one of the tabs such Edit? For the 
Project or for the Release?


I, too, never saw it because it's well hidden in plain view:
for me (in FF) it doesn't look like part of the page.
In fact it occupies the area that FF uses as its statusline,
so when you hover over any link, the tray is hidden.

HTH,
Stephan
___
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 RC1 staging repo is complete.

[Stephan Herrmann]

I just stumbled upon a feature that doesn't seem to belong here:

  ECF Patch for Eclipse Kepler (4.3). Not needed for Eclipse Luna (4.4).

Not sure if
(a) needed for some technical reasons and hence the nice explanation
in the feature name please don't use me, or
(b) simply forgotten from former times?, or
(c) ... (your explanation here) ...

just looks funny ...

best,
Stephan

___
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] Upgrade of JDK8 on build server

[Stephan Herrmann]

Sorry, Tom,

I didn't even ask myself if this was worth an announcement. My bad.
Of course the previous version is still available, if you use the
exact versioned path.

I don't have plans to further upgrade this.

BTW: when will Eclipse releng adopt JDK8?

best,
Stephan


On 01/07/2014 03:11 PM, Tom Schindl wrote:

Hi,

I notice a failure in my build on the weekend and noticed that the
JDK8beta has been upgraded to build 121 which generally is good but
there was a classpath change which the JavaFX = SWT integration.

Did I miss any annoucement? I was able to fix the problem but would have
preferred to get a short heads up before updating the default mapped JDKs.

Tom
___
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] b3 aggregator can't consume kepler repo?

[Stephan Herrmann]

Here's what I learned:

When aggregating stuff that should work with kepler, 
specifying the kepler repo as a Validation Repository is perfect.
All kepler stuff is found during aggregation, nothing is mirrored.

When aggregating a self-contained repo,
specifying kepler as a Mapped Respository and simply specifying 
just one of the relevant kepler features as a child node of the mapped repo
makes b3 validation happy, 
and enables me to set mirror=true for the kepler repo, 
mirroring only those parts that are needed for my tool.

With these two options it seems I can achieve all my goals,

thanks for your suggestions,
Stephan


- ursprüngliche Nachricht -

Subject: Re: [cross-project-issues-dev] b3 aggregator can't consume kepler repo?
Date: Di 08 Okt 2013 14:02:41 CEST
From: David M Williamsdavid_willi...@us.ibm.com
To: Cross project issuescross-project-issues-dev@eclipse.org

Those are questions that are hard to answer.
My guess would be if you just have a few pre-reqs (such as
just SDK and XML), you'd be better off specifying those specific
features (not even categories). If you have a large number of complicated
pre-reqs, my quess is you'd be better off creating your repo during your
build ... all three of the main ones at use at Eclipse projects (that I
know about) have ways of creating a repository and various
methods of specifying required pre-reqs. Sounds like you have a situation
where there are lots of methods to accomplish what you need, and the hard
part is knowing which is easiest. 



Good luck ... let us know what you learn!










From:  
 Stephan Herrmann stephan.herrm...@berlin.de

To:  
 cross-project-issues-dev@eclipse.org,


Date:  
 10/08/2013 07:22 AM

Subject:
   Re: [cross-project-issues-dev]
b3 aggregator can't consume kepler repo?

Sent by:
   cross-project-issues-dev-boun...@eclipse.org








Thanks, David, for comprehensive hints!



It seems the normal solution will be to specify kepler

as a validation repo rather than as a mapped repo. Good.



In some cases, however, I have the requirement to create

a self contained repo. For that scenario I need to find

a way to specify kepler as a mapped repo with a suitable

filter so I don't get any contradictory requirements.

It seems I have two options:

- positively list contents, e.g., via categories

- define exclusion rules for all non-IDE stuff



Would excluding all of RAP and all target platforms

already do the job in this latter direction, or is

more trial and error to be expected?

Would I need to browse the full meta data for max=0,

e.g.?



thanks,

Stephan





On 10/08/2013 03:34 AM, David M Williams wrote:

 That's not a very good error message, is it.



 But, if I had to guess (your description is pretty high level) I suspect
you are basically telling b3 aggregator to combine all of

 Kepler with your repo ... right so far?  If so, then I
suspect you are running into the (intentional) negative dependencies
that

 are defined for some runtime only features, that are there
to explicitly prevent some features from being installed together
--

 in this case, to prevent some runtime only features, say,
from RAP, from being installed into the IDE.



 As background on these topics, you might want to read



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

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

 https://bugs.eclipse.org/bugs/show_bug.cgi?id=365004#c16

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

 or p2 mailing list,

 http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04698.html



 This advanced technique was introduced in Kepler. Previously,
in Juno, everyone used a fake A.PDE.Target.Platform requirement

 which only the aggregator knew about with respect to particular category.
With the negative requirements now in use, p2 knows about

 it too, and you can specify, for example, as RAP does, install
this feature, or SWT, but never both together (or, something like

 that).



 Now, I could guess at what you are trying to accomplish, and offer
some possible solutions, but then this reply would get really

 long. :)

 But, I'll give some hints ... the answer is probably in

 http://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Mapped_Repository

 or

 http://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Validation_Repository

 or, indirectly, in

 http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata



 If not, you might try a how do I ...  question on the
eclipse.b3 newsgroup/forum.



 HTH











 From: Stephan Herrmann stephan.herrm...@berlin.de

 To: cross-project-issues-dev@eclipse.org,

 Date: 10/07/2013 04:40 PM

 Subject: [cross-project-issues-dev] b3 aggregator can't consume kepler
repo?

 Sent by: cross-project-issues-dev-boun...@eclipse.org

 







 I've had some fights with the b3 aggregator today

Re: [cross-project-issues-dev] b3 aggregator can't consume kepler repo?

[Stephan Herrmann]

Do you mean the SDK repo? Yes I tried, it works, but it doesn't contain the 
stuff I need.
Do you mean in addition to the simrel repo? How would this change anything, 
isn't the simrel repo (supposed to be) self-contained?

If this is not what you suggested, please be more specific,

thanks
Stephan

PS: just as of this writing I succeeded creating a big aggregator file with 
lots of individual repos from the projects that I depend on and with myriads of 
exclusion rules. This validates OK by avoiding the kepler repo, so it seems I 
have an (ugly) workaround. But still there seems to be a severe bug, right?

- ursprüngliche Nachricht -

Subject: Re: [cross-project-issues-dev] b3 aggregator can't consume kepler repo?
Date: Mo 07 Okt 2013 22:42:34 CEST
From: Pascal Rapicaultpascal.rapica...@ericsson.com
To: Cross project issueslt;cross-project-issues-dev@eclipse.orggt;

Did you try adding the platform repo?

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Stephan 
Herrmann
Sent: October-07-13 4:40 PM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] b3 aggregator can't consume kepler repo?

I've had some fights with the b3 aggregator today and it seems to boil down to 
the fact that the aggregator cannot consume the kepler repository, neither 
releases/kepler, nor one of the children 201306260900 or 201309270900.

To witness: I have a toy aggregation (1 feature with one plugin) that validates 
OK, but as soon as I add the kepler repo the aggregator dies with:

org.eclipse.core.runtime.CoreException: Cannot complete the install because 
some dependencies are not satisfiable
at 
org.eclipse.b3.aggregator.engine.ValidationSetVerifier.run(ValidationSetVerifier.java:686)
at 
org.eclipse.b3.aggregator.engine.Builder.runRepositoryVerifier(Builder.java:1704)
at org.eclipse.b3.aggregator.engine.Builder.run(Builder.java:1635)
at 
org.eclipse.b3.aggregator.presentation.AggregatorActionBarContributor$BuildAggregationAction$1.run(AggregatorActionBarContributor.java:292)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

It's the same exception as in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=321756#c11

Adding the juno SR2 repo doesn't have this effect (full juno repo has a 
conflict in a modisco feature).

Has anybody else seen this?
Are those repos broken, or is it just b3?

FWIW I tried 4.2 and 4.3 versions of b3.

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


 ursprüngliche Nachricht Ende 
___
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] Object Teams participation in Luna

[Stephan Herrmann]

The Object Teams Project will be participating in the Luna Simultaneous Release.

Object Teams has an offset of +2.

The release record can be found here:
https://projects.eclipse.org/projects/tools.objectteams/releases/2.3.0

Object Teams missed M1 due to a little bug in p2 [1]
which became a blocker after migration to Equinox Luna.
We'll hopefully have a workaround in place by M2.

best,
Stephan

[1] https://bugs.eclipse.org/253244
___
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] JFace Generics

[Stephan Herrmann]

Coming late to the discussion I don't want to repeat previous
statements, so let me just cast my vote, 2 votes actually:

-1
From all I saw, the most dangerous reasoning, IMHO, is to say:
  This had to be released early in order to make people react.
So a team wants attention from others to get feedback, fine.
But if the only way the team can get the desired attention
is by forcing the change on dependent folks, this is an act
of violence. Violence is not something that will make a lot
of people happy, not to mention glorifying violence.

You may compare this to previous situations: p2, e4, you name
it. There may have been good reasons for pushing stuff hard
to adopters and users, I'm sure I don't know all these reasons.
But I sure remember more anger than happiness in both stories.
Please nobody glorify the negative impact any of these stories
had on dependent people - who have their own business to mind.

+1
Quite the opposite, I consider Lars' behavior very agreeable:
without much ado he accepts responsibility and initiates the
right step in this situation: move the disputable development
to a branch, where it can continue without breaking others
(who have their own problems to solve).
Thanks Lars for responsible behavior!

Stephan

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

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

[Stephan Herrmann]

Object Teams cannot be installed in M1 due to https://bugs.eclipse.org/253244
(which hits us after the rewrite of the equinox framework).
I will enable our contribution just for one aggregation run to see we're
able to contribute and disable it immediately after.

I'm hopeful that the bug can be settled with the p2 team in time for M2.

best,
Stephan


On 08/21/2013 06:00 AM, David M Williams wrote:

Doesn't look good. I'll admit there is one day left, but so far 50 projects have not even 
enabled their contribution to Luna
(pasted below).

Thank you to the 20 of you who have.

Remember, enable your contribution if you plan to participate (remove the 
enabled=false), but disable your repository if you are
simply waiting for pre-reqs to get enabled or fixed (disable by adding 
enabled=false to your repository element(s)).

Please ask if questions. (Or, please say if you have explicitly decided not to 
participate in Luna).

Thanks,

= = = = =

This list are those that have not yet enabled contribution:

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
emf-cdo.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
emf-query.b3aggrcon - org.eclipse.simrel.build
emf-transaction.b3aggrcon - org.eclipse.simrel.build
emf-validation.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jubula.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
linuxtools.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mmt-qvto.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
mylyn.b3aggrcon - org.eclipse.simrel.build
objectteams.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
ptp.b3aggrcon - org.eclipse.simrel.build
sapphire.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build



___
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] Kepler post-mortem: versioning

[Stephan Herrmann]

Posts on this list have shown disagreement on how to label our
versions, despite the general agreement to use semantic versioning.

Where and when will we have the full discussion?
I strongly feel the discussion must be held, I am willing to say
the bad words: its not only about understanding the technical details
of semantic versioning but we do need more *discipline* in this regard
to (re)gain reputation and provide predictability to our valued users.

I see the difficulty that each particular case we may raise
will cause that some people feel offended and such emotions will
stand in our way. But then, how can we learn from mistakes?

I don't think delegating everything to particular bugs helps us
as a community to develop a common understanding.
So, is this list a good place to have the discussion?

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

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

[Stephan Herrmann]

Also the latest M build at
  http://download.eclipse.org/eclipse/downloads/drops4/M20121114-1200/
seems to suffer from the redirect problem?
I can see the directory when logging into build.e.o. but in a browser
I get redirected to granite then 404.
Recently 404 changed to 403.

Stephan

On 11/15/2012 04:30 PM, Laurent Goubet wrote:

The most recent builds I launched are failing because of
granite.eclipse.org too (or so it seems :
https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/400/console
) :

Caused by: java.net.UnknownHostException: granite.eclipse.org


Should I refrain from trying to build atm? :p

Laurent

On 14/11/2012 21:21, Denis Roy wrote:

Sorry Jeff.

I've discontinued that redirect until it catches up.

Denis


On 11/14/2012 03:20 PM, Jeff Johnston wrote:

Linux Tools has a backup M3 offering in place but I wanted to refresh
today.

I am experiencing problems using the b3 aggregator editor.  It claims
it can't find
a number of repositories that have to be there, including the Linux
Tools one used in the previous successful aggregation:
http://download.eclipse.org/linuxtools/update-kepler-m3.  I have
verified the repos exist by logging into build.eclipse.org.

I was able to do so maybe an hour ago, but now it is not working. Has
something changed very recently?

I keep getting redirected to granite.eclipse.org and the repos are
said to not be there.  I want to load
http://download.eclipse.org/linuxtools/update-kepler-m3-b

I could just make my change, but I would prefer to ensure it is loading.

-- Jeff J.

- Original Message -
From: David M Williams david_willi...@us.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Sent: Wednesday, November 14, 2012 2:53:29 PM
Subject: [cross-project-issues-dev] Status and outlook for Kepler M3


We've been without a clean build for past day or so but we just got
one, so I promoted it to staging.

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

I hope that everyone can check/confirm and get any other
contributions made by 5 PM, as today is +3 day of Kepler M3.

Let us know if anyone needs an extra hour or two ... otherwise we'll
assume done at 5 PM (

Looks like we are nearly complete with contributions being enabled
with only three remaining:

emf-query2.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build

But still several others with some features or repositories disabled:

amp.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build (2 matches)
egit.b3aggrcon - org.eclipse.simrel.build
emf-emf.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build (2 matches)
tm.b3aggrcon - org.eclipse.simrel.build
webtools.b3aggrcon - org.eclipse.simrel.build


___
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] Performance, 3.8 versus 4.2

[Stephan Herrmann]

On 09/06/2012 08:23 AM, Thomas Hallgren wrote:

Introducing a new platform undoubtedly consumes a lot of resources.
Doing that anyway (and as the only viable alternative), well aware that
those resources were scarce and that the new platform had inferior
performance, and then blame the community for not helping, that doesn't
fly well with me.


Maybe the problem is, the community isn't quite as homogeneous as
we keep thinking. 3.8 vs. 4.2 is a conflict of interests between
different groups of people.

If you are part of the group that only sees regressions not a single
improvement in 4.2, it's difficult to get motivated helping those
other guys getting their baby up to speed. Of course those who
greatly benefit from the new architecture don't want to get slowed
down by legacy decisions.

Lets call one group the IDE nerds and the other group the e4-RCP folks.
As a thought experiment: are the e4-RCP folks strong enough in resources
to make 4.3 a replacement that will not get into faces of the IDE nerds?

I don't know the answer, but I feel the answer differs depending on
whether you focus on functionality, bugs, performance or usability.

Yes, we are still one community, and I'm not advocating fences and
boundaries, but helping each other seems to work best when cost and
benefits are equally balanced in all regions of this community.



On 09/06/2012 07:06 AM, Pascal Rapicault wrote:
 But more importantly than all this is the meta conclusion that the
 era of being able to take the platform for granted is over and that
 we are all going to have to pay more attention to it, roll up our
 sleeves and contribute.

I'd like to second this. No part of the entire ecosystem can be taken
for granted, not the platform, not jdt, not p2, nor the team providers.
All components need continued care and everybody needs help
(no sarcasm intended, in case anyone wonders).

cheers,
Stephan

PS: Great to see efforts to bring performance tests back! Thanks!

___
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] Performance, 3.8 versus 4.2

[Stephan Herrmann]

On 09/06/2012 01:01 PM, Aleksandar Kurtakov wrote:

As a thought experiment: are the e4-RCP folks strong enough in
resources
to make 4.3 a replacement that will not get into faces of the IDE
nerds?


What about e4-RCP folks outnumber the IDE nerds significantly (amongst active 
contributors) so it's there call.
The one that does the job decides!


That's too easy.

What if the decision of the many e4-RCP folks would make the
work of the few IDE nerds impossible?
What if the product of the few IDE nerds happens to be the
flagship product of this community?

Being active and outnumbering another group isn't enough to
abandon rules of fair play.
The one that does the job decides! cannot be the only rule
in a community of interdependent sub-projects. And I know it
isn't in the Eclipse community!

cheers,
Stephan

___
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] Final bugzilla status

[Stephan Herrmann]

On 05/26/2012 11:31 AM, Wim Jongman wrote:

So what does CLOSED mean? Is it higher in the cycle than VERIFIED or
does it mean something else?


Good question!

I guess CLOSED DUPLICATE is the typical example of CLOSED,
which may be used to mark a duplicate whose original isn't
yet resolved, which implies that also the duplicate isn't
resolved nor verified.

OTOH, e.g., the http://wiki.eclipse.org/JDT_Core_Committer_FAQ
don't even mention state CLOSED, all goes down the road of
RESOLVED - VERIFIED and that's it.

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

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

[Stephan Herrmann]

On 05/24/2012 06:40 AM, David M Williams wrote:

Look at these reports:

http://build.eclipse.org/juno/simrel/reporeports/


Looking at verified.txt I see lots of
  jar verified.  Warning:  This jar contains entries whose signer 
certificate has expired.   Re-run with the -verbose and -certs options 
for more details.


It seems to fix this we'd have to re-build and sign ALL jars that
have been signed before the switch to the new certificate and never
changed since?
Is it good to rebuild just to catch up on the certificate?

Any recommendations?

Stephan
___
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] PDE Extension editor in M6

[Stephan Herrmann]

I just filed this against PDE/UI:

   Bug 374789 - Buttons in extension editor are broken
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=374789

This might be of interest for everybody planning to demo any configuration
of any kind of Plug-in project at EclipseCon.

best,
Stephan
___
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] p2.mirrorsURL property - how do different projects handle this?

[Stephan Herrmann]

On Saturday, February 18, 2012 05:24:11 PM Gunnar Wagenknecht wrote:
 Am 18.02.2012 12:54, schrieb Stephan Herrmann:
  From the p2 documentation I don't see any connection between
  the ant taks you cite and this question. Am I missing anything?
 
 The template artifact.xml contains the mirrorURL with a placeholder and
 is empty. At build time, the placeholder is replaced with the proper
 mirror url coresponding download location. When mirroring the IUs to the
 download location, p2 then includes the mirror url from the template.

Cool, thanks for explaining. From looking at the p2 documentation I just 
couldn't put the pieces together.

FYI, I've pasted your snippets into 
http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL

Feel free to correct / add more pointers :)

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

[cross-project-issues-dev] git?

[Stephan Herrmann]

Hi,

anyone seeing any git repositories currently?

I see EGit answering '/gitroot/jdt/eclipse.jdt.core.git' does not appear to be 
a git repository

Still on the server the files are all there.

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