Re: [cross-project-issues-dev] core.jobs dependency on Java 8

[John Arthorne]

The fact that the Eclipse SDK as a whole will require Java 8 doesn't imply that any particular bundle should require Java 8. Since the change requiring Java 8 was cosmetic and there is a significant impact caused by the change, I think it is fair to ask the question and to consider the request. I have entered this bug for further discussion, so please chime in there if you have an opinion:https://bugs.eclipse.org/bugs/show_bug.cgi?id=483803One question for you Ralf, is whether this is the only bundle RAP requires that is blocking you in this way? I thought there were a number of other platform bundles already requiring Java 8 as well.John-cross-project-issues-dev-boun...@eclipse.org wrote: -To: Cross project issues From: Lars Vogel Sent by: cross-project-issues-dev-boun...@eclipse.orgDate: 12/07/2015 04:50AMSubject: Re: [cross-project-issues-dev] core.jobs dependency on Java 8Hi Ralf,Dani announced a while ago that Eclipse Neon will drop support forJava 7. See: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg12177.htmlBest regards, LarsOn Mon, Dec 7, 2015 at 10:41 AM, Ralf Sternberg wrote:> Hi,>> while we all want to use the new features in Java 8, some users of the> RAP project still can't switch to Java 8 because they have to deploy> on application servers that run on a (bundled) non-Java-8 VM. For> example, looking at the IBM WebSphere JDK support list [1], it seems> that for the server side, it's still a bit too early to require Java> 8.>> Since one of the bundles RAP depends on (core.jobs) has recently been> updated to Java 8, we find ourselves faced with the choice of either> locking out those users or shipping RAP 3.1 with an older version of> the platform. The latter would probably mean to abstain from the Neon> simultaneous release.>> I wonder if there is a general consensus that the Eclipse platform> (not the IDE) does not support Java 7 anymore. If this is the case, we> have to live with it, however, I'd appreciate to keep at least the> core Java-7-compatible for one more year. Looking at the respective> change in core.jobs [2], it looks like a refactoring, not an API> change that would require Java 8. Also on the Neon release plan [3],> it's still marked as 1.7. Is there a chance to revert this change or> are more of those going to come?>> Regards,> Ralf>> [1] http://www-01.ibm.com/support/docview.wss?rs=180=swg27005002> [2] http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/bundles/org.eclipse.core.jobs?id=e0c1dc5111c5200d39f4611082b34110d735ac29> [3] https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_6.xml#appendix>> --> Ralf Sternberg> Project Lead, Remote Application Platform (RAP)> EclipseSource>> Tel: +49 721 66 47 33-0>> Innoopract Informationssysteme GmbH> Lammstraße 21, 76133 Karlsruhe, Germany> General Manager: Jochen Krause> Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883> ___> cross-project-issues-dev mailing list> cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev-- Eclipse Platform UI and e4 project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (032) 221739404, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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] Orion participation in Neon

[John Arthorne]

The Eclipse Orion project is planning to participate in the Neon simultaneous release, with an offset of +3. It will be release number 12.https://projects.eclipse.org/projects/ecd.orion/releases/12.0Thanks,John

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] 1000 line limit for contributions

[John Arthorne]

The "allow committers to contribute to other eclipse projects" topic is well underway in the Eclipse Board. There is a problem that some committers have written agreements from their employer that only allows them to participate on a particular project. The Foundation needs to put some automation in place to handle this, but there is a path forward here and progress is being made.John-cross-project-issues-dev-boun...@eclipse.org wrote: -To: Cross project issues From: Lars Vogel Sent by: cross-project-issues-dev-boun...@eclipse.orgDate: 11/20/2015 11:44AMSubject: Re: [cross-project-issues-dev] 1000 line limit for contributionsGreat proposal from Max to skip CQ for Eclipse committers. It does not make sense that I can commit 100 000 lines to PDE but not 1001 to another project I'm not a committer for.Max, can you bring your proposal to the board?Best regards, LarsAm 20.11.2015 9:00 vorm. schrieb "Max Rydahl Andersen" :On 19 Nov 2015, at 11:17, Ed Merks wrote:Recall that this was increased from 250 to 1000 not so long ago.  I wasn't able to push the IP committee beyond that.  People working for an organization that has a corporate representative on the board could ask that representative to raise this issue at a board meeting.  I think that would carry more weight than me personally asking for a further increase.In this case it looks like a broken notification - good it was found and identified.I can personally vouch that the 1000 line limit have directly taken part in why I have stopped contributing to i.e. mylyndoc asciidoc support. Here I spent several weekends and eventually months on getting basic contributions in that was *obviously* not in any danger of having IP conflicts since the code was copied from mylyn.doc itself and 100% written by me - still I had to play the game of splitting up contributions and in the end just stop doing it. (mylyn.doc could fix this by making me a committer or eclipse foundation allow contributions from other eclipse committers without CQ review - but that is just examples of more process dancing)Thus this really is an issue and something I raised to IP and Legal team several time in the pass - issue is that from their perspective they don't get to see the times a committer is asked to split a contribution up; they just see the +1000 lines ones and think they are fast to get it though the system.But If I have to wait 2 weeks between contributions for things that are not on my critical path I just cannot afford spending time on it - especially if I have interest in building on top of these contributions.And I'm actually a believer in doing things right at eclipse - but I can just imagine those coming from the outside just never show up or just leave immediately.But to the point on raising this to the IP committee and the board.If you get caught in similar dead or live-locks in the IP system or see another attempt on having to split up otherwise perfect valid contributions, please consider forwarding me info personally (mande...@redhat.com).I would like to be able to show to IP committee and board how often this is actually hurting us - or on the flip side, be convinced that is not actually that big an issue.Thanks,/maxOn 19/11/2015 11:00 AM, Ed Willink wrote:HiPresumably you put tests in a separate plugin, so splitting off the tests as a separate contribution gets you twice the limit with minimal effort.Perhaps a 1 line limit might be appropriate for non-deliverable code such as tests and build tools.Regards Ed WillinkOn 19/11/2015 09:49, Sievers, Jan wrote:Hi,in the course ofhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=477328we had a contribution that slightly exceeded 1000 lines and thus needed a CQ.It took about one month to review it.I am sure the legal team does its very best to keep up with the load, so the following is in no way a criticism of thepeople who actually do the legal review.Rather take it as food for thought to whoever set up this rule.IMHO the 1000 line rule is effectively setting the wrong incentives for a thriving opensource project.Here is why I think so:The most diligent contributors add a lot of tests to their patch to prove it works.This is a good thing and we actively encourage contributors to thoroughly test.Test code can easily outweigh productive code being tested in terms of LOC.However this means the most diligent contributors, i.e. the ones you want to attract, are more likely to hit the 1000 line limit.Instead of thanking them for their hard work, we effectively punish them with an extra month or more wait time before their patch can be merged.Apart from that, the 1000 line limit seems arbitrary to me because technically you can split up any commit into any numberof smaller commits below the 1000 line limit.Best Regards,Jan___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo 

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

[John Arthorne]

>And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a >consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into >question why we even bother having a versioning convention. By definition, any API change can be >characterized as potentially having no impact.
 
Yes, your approach does guarantee a breaking change for all clients, whereas updating the BREE only impacts consumers that are actually affected by the change. Congratulations on achieving consistency on that :)
 
John
 
 
- Original message -From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>To: John Arthorne/Ottawa/IBM@IBMCA, "cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>Cc:Subject: RE: [cross-project-issues-dev] DTP major version bump for NeonDate: Wed, Oct 28, 2015 11:24 AM 
> potentially no impact on most consumers of your API
 
And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into question why we even bother having a versioning convention. By definition, any API change can be characterized as potentially having no impact.
 
- Konstantin
 
 
From: John ArthorneSent: Wednesday, October 28, 2015 8:07 AMTo: cross-project-issues-dev@eclipse.orgSubject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
> I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.
 
You appear to be the first person to claim that making version numbers reflect changes to runtime dependencies is sound engineering practice. Even Java itself did not update its major version with Java 8 (which is officially version 1.8 at the JVM level). Changes to your dependencies have no direct impact on your API, and potentially no impact on most consumers of your API. A consumer of your bundle may already have a dependency on Java 8 (or whatever the case may be), and therefore could not possibly be impacted by your change. By updating your BREE, you have ensured that your bundle will not even be loaded by OSGi in a runtime using Java 7 or earlier, which is already a strong enough hint to any consumer impacted by this change. Updating the bundle version number as well offers absolutely no benefit.
 
I will agree with Alex, that as the person doing the work you have the right to make these changes, however unjustified. The consumer community will have to react accordingly (by updating manifests, contributing to the project, removing the dependency, forking, etc).
 
John
 
- Original message -From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: Ed Willink <e...@willink.me.uk>, "cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>Cc:Subject: Re: [cross-project-issues-dev] DTP major version bump for NeonDate: Wed, Oct 28, 2015 9:45 AM 
I gave the justification several times. You are choosing to disregard it. Java API is not bundle’s sole API. I don’t consider a restriction in requirements a compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 and the version numbering truthfully communicates that fact.
 
I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.
 
- Konstantin
 
 
From: Ed WillinkSent: Wednesday, October 28, 2015 6:29 AMTo: cross-project-issues-dev@eclipse.orgSubject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
 
On 28/10/2015 13:13, Konstantin Komissarchik wrote:
 
 
I have no specific plans re ODA’s Java API.
 
 
So absolutely no justification for a change then. There is no need for all plugins to bump together. It is cosmetically nice to see all plugins with the same version, but it just isn't tenable long term.For instance many OCL plugins remain at 3.x although those that have been affected by UML major changes have moved to 4.x and 5.x.Inflicting a major change on clients is not a bit of a pain, it is a major pain, particularly for those clients that are stable and consequently have minimal maintenance teams. In some cases useful but unmaintained tools, such as UML2 Tools, are killed by the major version change.    Regards        Ed Willink
 
 
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 
 
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev

Re: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)

[John Arthorne]

I think the issue is that the whole product has to offer an update.. individual features in the product cannot publish updates independently that will be discovered by the update check. This is both a good thing and a bad thing, depending on your perspective.. I don't think there is a silver bullet solution to this (but I would also enjoy hearing proposals :).
 
John
 
- Original message -From: Pascal Rapicault Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: cross-project-issues-dev@eclipse.orgCc:Subject: Re: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)Date: Wed, Sep 23, 2015 3:19 PM 
I was about to ask the same :)On 15-09-23 02:54 PM, Mike Milinkovich wrote:> On 23/09/2015 1:49 PM, Doug Schaefer wrote:>> if we could ever get Check for Updates working properly, this>> wouldn't have been such a big issue.>> Doug (or anyone)>> Is there a written proposal anywhere on how "Check for Updates" should> be modified?>> Is there an existing consensus around such a proposal?>___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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] Observation: Frequent UI freezes when working with files

[John Arthorne]

The IResource/IWorkspace API is backed by a completely in-memory skeleton 
of your file system structure. So any time you can query the resource 
model instead of the file system, you will see orders of magnitude 
performance improvement over direct java.io.File access. The IResource API 
(and EFS) encourage a batch-style interaction for the rare thing that is 
not in memory. For example IResource#getResourceAttributes or 
IFileStore#fetchInfo  returns a struct of all the attributes in a single 
native call, which is vastly more efficient than doing many calls such as 
if (file.exists()  file.isFile()  file.canRead()) {... }. 

For the IResource API and much of the rest of the platform API, the best 
indicator is whether there is an IProgressMonitor in the API method. If 
the method takes a progress monitor, you probably don't want to call it 
from the UI thread. If there is no progress monitor, then for the most 
part you are ok. There are a few embarrassing exceptions to this (e.g.,, 
Job#join), but it's a useful rule of thumb.

John




From:   Lars Vogel lars.vo...@gmail.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date:   12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI 
freezes when working with files
Sent by:cross-project-issues-dev-boun...@eclipse.org



I would guess that java.nio.file.Files.exists() [1] improves this access 
performance. Do you see these freezes cause 
by org.eclipse.core.resources.IResources or by directly using the Java 
File API?

[1] 
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...)
)

2014-12-10 14:53 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com:
Hi,

I just want to share an insight I got from reviewing several ui freezes. 
One common cause for UI freezes are operations that touch the filesystem. 
For instance, File.isFile, File.lastModified, or 
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what 
I read on the internet it seems that some of these methods (e.g. 
getAttributes) may even take up to several seconds to return on windows 
systems.


This has been discussed elsewhere in the internet [1] and seems to be a 
long-standing issue in Java.



With this mail I’d like to make you aware of this (in case you did not 
know this before) and would like to encourage you to actually not execute 
file operations in the ui thread. We may also consider doing some kind of 
caching but such a discussion would by far be over my knowledge, and thus, 
should be left to discuss with the platform team.

For now, I think we would benefit very much if every project that accesses 
files/resources would review their code and think about refactoring some 
part of the FileSystem work (even if it’s only checking a file’s 
attributes) into background processes.

Best,
Marcel


[1] 
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance



--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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] PLEASE HELP: Eclipse asking for username/password for download.eclipse.org

[John Arthorne]

The dialog comes from p2, and it looks like the standard dialog.  Here is 
the source:

http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/dialogs/UserValidationDialog.java

And it is opened from line 174 of this class:

http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.ui/src/org/eclipse/equinox/internal/p2/ui/ValidationDialogServiceUI.java

However this usually comes up when you have a password protected p2 
repository. Typically I wouldn't expect this to be the case for a 
repository at download.eclipse.org. It could also possibly be caused by a 
proxy between the user and eclipse.org that is bouncing him back.

So, it's a bit weird, but doesn't look like an exploit.

John




From:   Denis Roy denis@eclipse.org
To: cross-project-issues-dev@eclipse.org, 
Date:   11/13/2014 02:37 PM
Subject:[cross-project-issues-dev] PLEASE HELP: Eclipse asking for 
username/password for download.eclipse.org
Sent by:cross-project-issues-dev-boun...@eclipse.org



I'm trying to find the source of an Eclipse dialog window that is asking 
for a username and password for download.eclipse.org.

A user is reporting this in the Forums:
https://www.eclipse.org/forums/index.php?t=msgth=854929goto=1472298#msg_1472298


I've attached the screenshot for your convenience.

Does anyone know where this dialog is coming from, and what it's doing? 
From what I can tell, it is not sending those credentials to 
download.eclipse.org.

I'm somewhat concerned by this, and I'm hoping it isn't what I think it 
is.

Thanks,

Denis [attachment password.png deleted by John Arthorne/Ottawa/IBM] 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [equinox-dev] Plans to update to jetty 9 followed by update to the Http Service implementation

[John Arthorne]

Cross-posting to cross-project list for awareness...

John




From:   Thomas Watson tjwat...@us.ibm.com
To: Equinox development mailing list equinox-...@eclipse.org, 
Date:   10/08/2014 11:45 AM
Subject:[equinox-dev] Plans to update to jetty 9 followed by 
update to the Http Service implementation
Sent by:equinox-dev-boun...@eclipse.org



To keep folks informed.  We plan to make an update to use Jetty 9 in the 
coming week [1].  I hope to have this released by the I-Build next week. 
This will require an update to use Servlet 3.1 as well as a requirement on 
Java 7 in order to run Jetty 9.  Equinox bundles themselves will not 
require Java 7, it is only the servlet 3.1 API bundle and the Jetty 9 
bundles that will require Java 7.  Also note that the Equinox Mars release 
will no longer ship support for Jetty 8. 

After that I plan to get Ray's contribution to the update the Equinox 
HttpService to the latest R6 Http Whiteboard service merged into master 
[2]. 

These are two of the major items planned for the Mars release.  It would 
be great for those in the community that have an interest in the Equinox 
Http Service to test out the next Milestones for Mars. 

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=401784 
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=436698 
___
equinox-dev mailing list
equinox-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-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] Several Platform Feature Versions Need to be Increment

[John Arthorne]

Thanks for catching those, Ed. Can you enter a bug report for issues like 
this - it doesn't seem like a cross-project discussion topic to me.

John




From:   Ed Merks ed.me...@gmail.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   08/26/2014 05:02 AM
Subject:[cross-project-issues-dev] Several Platform Feature 
Versions Need   to be Increment
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

For Oomph we generate a product catalog from the EPP repositories.  As 
part of generating an update of that catalog to include Mars, I noticed 
that several key platform features have not incremented their version 
number.  Specifically I see the following features as inconsistent:
1.  The org.eclipse.platform feature is still at version 4.4 even 
though it requires version 4.5.0.v20140704-1057 of 
org.eclipse.platform.doc.user.  
2.  The org.eclipse.pde feature is still at version 3.10 even though 
it requires version 3.11.0.v20140804-1453 of org.eclipse.pde.doc.user.
I believe the minor versions of these features should be incremented to 
reflect the minor version increments of their requirements.

Note that the org.eclipse.jdt feature has already incremented but the 
org.eclipse.rcp feature has not, though in this case that appears correct 
as none of its requirements have incremented, yet.

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://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] Home dir disk full on build.eclipse.org

[John Arthorne]

I discovered I could not create a file in my home directory on 
build.eclipse.org this morning. I cleaned up most of my home to free some 
space, but please take a look at your home directory and see if you can 
free more space:

nfsmaster:/home/data   1.7T  1.6T   41M 100% 
/home/data

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

[cross-project-issues-dev] 3rd party JavaScript libraries in Orbit

[John Arthorne]

We're having a discussion in the following bug about how to handle IP 
cleared third party JavaScript libraries in Orbit. If you are working on 
any Eclipse project that consumes 3rd party JavaScript libraries, please 
chime in there so we can get a sense for how many projects are in this 
situation and what kind of infrastructure makes sense for you. 

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

Thanks,
John___
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

[John Arthorne]

Just to close the loop on this, all the JFace generic changes have been 
reverted in master and will not appear in M2. For anyone interested in 
following or contributing to this work, see this main bug and its 
dependencies:

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

John
___
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] Has Java 5 Platform support been discontinued?

[John Arthorne]

I can't think of any way to be clearer than I already have. The platform 
requires Java 6, and it has required Java 6 for several years. Next time I 
do a plan update I will try to make that even clearer.

John




From:   Ed Willink e...@willink.me.uk
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   09/03/2013 10:47 AM
Subject:Re: [cross-project-issues-dev] Has Java 5   Platform 
support beendiscontinued?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi

I'm sorry John but you are dodging the issue. There is far too much this 
is what we do, and very little of this is what we require.
Most of the Eclipse SDK is pure Java code and has no direct dependence 
on the underlying operating system. The chief dependence is therefore on 
the Java Platform itself. Portions are targeted to specific classes of 
operating environments, requiring their source code to only reference 
facilities available in particular class libraries (e.g. J2ME Foundation 
1.1, J2SE 1.4, Java 5, etc).
In general, the 4.3 release of the Eclipse Project is developed on a mix 
of Java SE 6 and Java SE 7 VMs. As such, the Eclipse SDK as a whole is 
targeted at all modern, desktop Java VMs. Most functionality is available 
for Java SE 6 level development everywhere, and extended development 
capabilities are made available on the VMs that support them.
Yes there have been a few bundles that needed 1.6 for some time, but it 
seems like the critical parts of the platform have been 1.5. The list on 
http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#appendix
still shows very little that needs 1.6, so I see no statement that the 
platform needs 1.6.

I delivered my Indigo, Juno and Kepler releases as Java 5 minimum 
requirement. Clearly the platform and many projects were highly Java 5 
tolerant.

There should perhaps be a separate overall statement at the top that 1.6 
is the minimum requirement (although some bundles may be more tolerant).

Or org.eclipse.core.* needs to change to 1.6

Regards

Ed Willink


On 03/09/2013 14:57, John Arthorne wrote:
I seem to have a knack for definitive statements lately so I'll take a try 
at this. The last Eclipse Platform release to officially support Java 5 
was 3.6/Helios. We have not run our tests against Java 5 for several years 
and can make no claim that it works. Since Platform 3.8 it has certainly 
been impossible to run the complete platform using Java 5 due to Jetty 
dependency on Java 6 (and possibly other bundles). Oracle Java end of life 
was in 2009 (in fact Oracle Java 6 is also past end of life now). Some 
individual bundles may still support older runtimes but at this point they 
are the exception rather than the norm. The list of bundle EE levels is 
updated with each plan revision, but as long as they are within the scope 
of the current list of reference platforms they are not generally 
announced individually. 

John 



From:Ed Willink e...@willink.me.uk 
To:Cross project issues cross-project-issues-dev@eclipse.org, 
Date:09/03/2013 09:24 AM 
Subject:Re: [cross-project-issues-dev] Has Java 5Platform  
 supportbeendiscontinued? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 



Hi

I am doing my best to continue support for existing functionality, so in 
the absence of a clear Eclipse statement that Java 5 support is 
terminated, I feel I have to continue to keep close to 5.

Guava changing to Java 6 was awkward.

OSGI changing to Java 6 is very close to a mandatory downstream 
consequence.

Can we please have a clear policy statement rather than a secretive creep.

I don't mind changing to Java 6, it probably makes life easier. But I hate 
this are we 5 or 6 limbo?

   Regards

   Ed Willink 

On 03/09/2013 13:51, David M Williams wrote: 
I probably should have mentioned, there are several bugs we are still 
trying to work through, where the Tycho/Maven build picks a different 
compiler level than the way PDE used to it ... and not always in the way 
we intend, for example, 

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

I am not sure if this is related to the issue you are seeing ... or if 
merely confirms yet another unannounced change ... but I don't think it 
changes the bottom line: 

If you want things different than they are, open a bug or comment on an 
existing one. If it is merely a matter that you don't really care, but you 
have to change your test scripts, then all I can say is sorry. 





From:Ed Willink e...@willink.me.uk 
To:Cross project issues cross-project-issues-dev@eclipse.org, 
Date:09/03/2013 08:34 AM 
Subject:Re: [cross-project-issues-dev] Has Java 5 Platform support 
   beendiscontinued? 
Sent by:cross-project-issues-dev-boun...@eclipse.org 



Hi Szymon

Your list omits the 'culprit

Re: [cross-project-issues-dev] JFace Generics

[John Arthorne]

I hope everyone realizes I was being a bit provocative just to prove a 
point (I think I learned this from you Doug ;)  Committers are generally 
pretty reasonable and will always try hard to keep adopters satisfied. 
Adopters are obviously very important to any project and their views 
should always be considered. I'm hopeful in this particular case we'll 
find a middle ground that allows progress to be made without further 
unnecessary disruption for consumers. My main goal was refuting the 
assertion that adopters have to be pleased and that committers are not 
permitted to make disruptive changes if adopters don't like it. The final 
decision on direction for any Eclipse project will be made by its own 
contributors.

John




From:   Doug Schaefer dschae...@qnx.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   08/30/2013 01:43 PM
Subject:Re: [cross-project-issues-dev] JFace Generics
Sent by:cross-project-issues-dev-boun...@eclipse.org



John, you are right by the letter of the law. But I think the point is, if 
the contributors want the platform to be successful, they have to be 
sensitive to the needs of adopters. They're who make a platform 
successful. If they aren't then who are they building the platform for? 
(And as much as we don't like to talk about it, I really hate the real 
answer to that question).

For Eclipse to be a successful platform going forward that has to change. 
Or, yeah, we could just fork it. A lot of us who build products on it 
already have. But no one is suggesting that's the right thing to do in the 
long run. Or are we?

Doug.

From: John Arthorne john_artho...@ca.ibm.com
Reply-To: Cross project issues cross-project-issues-dev@eclipse.org
Date: Friday, 30 August, 2013 11:05 AM
To: Cross project issues cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] JFace Generics

Eike Stepper step...@esc-net.de wrote on 08/30/2013 05:59:14 AM:

 The project is it's contributors not it's API.
 
 That sounds a little as if Eclipse projects are only playgrounds for
 the cool kids. I think a project is successful if 
 what it produces (including the APIs) is successful, i.e. widely 
 adopted. The adopters have to be pleased, not the contributors.

You're definitely wrong about this part. Committers and contributors will 
always have the final say. An adopter that is not contributing has 
*absolutely* no say in the direction of the project. This is not my 
opinion - this is clearly defined in the Eclipse charter, by-laws, and dev 
process, and is the same for most other open source projects. The historic 
platform contributors (e.g., IBM), placed extremely high value on 
stability and compatibility. If those committers are gone and a new set of 
committers arrives that values innovation and change over stability and 
compatibility, then that's the direction the project will take. If 
adopters don't like that direction, then they need to get involved to 
influence the direction, fork the project, etc. Even as a PMC member I 
have no right to value the needs of adopters over contributors - quite the 
opposite I have a clearly defined obligation to enable the project's 
contributors to make progress in the direction they want to take.

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

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

Re: [cross-project-issues-dev] JFace Generics

[John Arthorne]

You raise good arguments as always Ed. I will attempt to summarize and 
respond to some of the comments raised in this thread.

Q: Should JFace be generified at all. 

As with most library generifications there are pros and cons that we can 
probably debate all day. I still think on balance it will be a net benefit 
for consumers. Some will not have homogeneous element types and will be 
stuck with Object, and therefore be no better or worse off than before. 
TreeViewer is the worst case, although I think it would be difficult and 
awkward to generify some viewer types but not others. My experience with 
most generification is that 90% of usage is adapted relatively painlessly 
and eliminates a tonne of casting, resulting in cleaner code. There are 
always some rough edges, especially where arrays are found, and 
suppressing warnings is sometimes necessary. There is certainly work 
involved for clients to adopt it, although I don't find that alone a 
compelling argument to do nothing at all. A good place to continue this 
general discussion would be the master bug report: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=402445

Q: Should we release incomplete work to a milestone

I'm torn on this one. Certainly in the past our project adopted a we 
won't accept your contribution until it is perfect approach. There is no 
doubt this benefits consumers, but I think it has strongly discouraged all 
but the most die-hard contributors to the project. Given the number of 
remaining active contributors, I strongly believe we need to find ways to 
make progress using the contributors we have, at the rate they are capable 
of contributing. Undoubtedly this is a slower and bumpier road, but I 
think the risk is better than the alternative of stagnating because there 
are no contributors who can keep up with the old pace expected/demanded by 
the community.  Certainly if there was risk of data loss or severe 
problems with tool usability, we would have avoided releasing in a 
milestone. In this case the worst case is compiler warnings which can be 
disabled if desired. I understand there are some who consider warnings to 
be catastrophically bad, but the community compiling against our 
milestones is a tiny fraction of the overall community. I believe all 
changes released were binary compatible and not changing behaviour.

In the end I admit we got this one wrong. We misjudged the rate of 
progress on the work, and many committers being on holiday bogged down the 
review process. We should have kept the work in a branch and waited until 
at least after M1 to release. Some damage is already done, but we are now 
investigating moving the work into a branch. This will actually introduce 
a much worse problem for any client that had reacted to changes already, 
since it will result in compile errors. We'll send a separate warning note 
about this once we are sure on this path, so it doesn't get lost in this 
long-winded message.

Q: I have some specific technical concerns about the approach taken so 
far.

This is excellent feedback and I'm sure it will be incorporated into the 
work going forward. I wonder if we would have had such feedback if we 
hadn't released anything to master ;)

Q: Your communication sucks.

Yes it does. I think normally we wait until things are closer to 
completion before making big announcements. It is quite often that we have 
feature work in progress appearing in a milestone, that we hold off on 
announcing until a future milestone when it is more polished. In this case 
because the interim state already had significant source level impact this 
should have been communicated more widely.

John





From:   Ed Merks ed.me...@gmail.com
To: cross-project-issues-dev@eclipse.org, 
Date:   08/29/2013 03:52 AM
Subject:Re: [cross-project-issues-dev] JFace Generics
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi,

It's difficult to avoid an emotional outburst at this type of thing.  I'm 
completely shocked that sweeping changes of this nature go unannounced on 
this mailing list. Sorry, a blog doesn't cut it...

It's clear the current state is woefully incomplete.  I.e.,  we have 
IStructuredContentProviderE, I but ITreeContentProvider is still raw. Of 
course it's clear that a tree rarely has uniformly typed children, so what 
is the plan for the completion of JFace's APIs?  I question all this being 
committed to master in incremental stages like this...

EMF is a sea of warnings with these changes, and eliminating those is 
weeks of work; work I can't begin because the changes are incomplete. And 
of course this affects all users of JFace, not just EMF, so the overall 
impact to the community is hard to calculate.  The most disturbing part of 
all this is that I question whether it has even been well thought out. For 
example, the following change is highly disturbing:
public interface IStructuredContentProviderE,I extends 
IContentProviderI {
public E[] 

Re: [cross-project-issues-dev] JFace Generics

[John Arthorne]

 From: Mickael Istria mist...@redhat.com
 I may have missed something, but wouldn't the following 
 implementation be a valid solution?
 
 public E[] getElements(I inputElement) {
return inputElement.toArray(new E[inputElement.size()]);
 }

You can't instantiate arrays of generic type. I think we're digging into 
too low level detail for this list. I have entered this bug for the 
particular issue of generic array return types in JFace:

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

John
___
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] Future of Eclipse IDE

[John Arthorne]

Gunnar Wagenknecht wrote on 07/18/2013 05:01:50 AM:

 Too much of the platform is still 
 dominated and controlled too strictly by that one single company. 
 Contributions got turned away because of the lack of resources 
 argument and associated maintenance costs long term. To some point 
 those arguments aren't completely invalid. I'm at a point of being 
 resigned when it comes to contributing to the platform. 

This statement worries me more than everything else that has been written 
in this thread. It makes sense that there are very few committers who are 
focused on the requirements of the direct Eclipse user base. There are few 
people with the motivation to even gather feedback on the pain points of 
using a free tool, let alone spending significant time addressing them. I 
believe the main focus for most current committers is:

1) Stuff *they* (or their employer) want to focus on
2) Enabling other contributors to help *them* fix the problems they want 
to see fixed

I think this is one of Doug's key points, that working to enable more 
contributors is the only scalable solution. Imagine someone spent the time 
to gather a list of the top 5 most pressing problems/enhancement 
requests. Maybe the current committers can take this list and fix 1 or 2 
of them between their other priorities. Well, next year there will be a 
new list, and more requests, and still no more people to work on them. It 
will not result in a dramatic transformation of the perception or 
trajectory of Eclipse as an IDE.

However Gunnar's comment says we are even failing on enabling 
contributors, which vexes me. I actually thought we had made improvements 
on that in the past couple of years. The Foundation and many committers 
have been working to reduce barriers to contribution in any way possible. 
Switching to Git, moving the build to Maven/Tycho, adopting Gerrit, and 
holding dedicated patch review days are a few of the things committers 
have been doing. From the statistics it looks like we are even starting to 
see results on this. Ohloh metrics have shown a stable or even slight 
upwards trend in the number of Platform contributors in the past couple of 
years [1]. JDT core and SWT, historically the two components with the 
toughest standards for accepting committers, have both seen committers 
from new companies this year. Platform UI, which is in a position to 
address many of the preference problems described here, has THIRTY NINE 
committers. I don't doubt there are still barriers, but it looks like at 
least some people are managing to overcome them and bring their 
contributions into the platform.

Personally most the time I used to spend directly fixing user reported 
problems, I now spend reviewing patches and trying to enable others to 
contribute fixes instead. If successful, this has a multiplier effect that 
grows the base of people capable of contributing and is, I think, the best 
use of the limited committer resources we have available. So don't tell me 
what you want to see fixed. Tell me how I can help you to fix them.

John


[1] https://www.ohloh.net/p/eclipse/factoids#FactoidTeamSizeVeryLarge___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[John Arthorne]

I realize this was a rhetorical question, but the requirement is that 
projects are capable of working with the version of their dependencies 
that is shipped in the same simultaneous release. In this case the Kepler 
version of XText requires the Kepler version of EMF. This is quite 
reasonable, and although some projects support multiple older versions of 
their dependencies, there is no requirement to do so that I'm aware of.

In both Eclipse versioning [1] and the more widely cited semantic 
versioning [2], version increases don't have transitive effect (unless 
dependencies are re-exported). I.e., just because the major or minor 
version of something I require changes, doesn't mean my version has to 
increase by the same magnitude. More concretely, the fact that EMF's minor 
version increased does not imply that XText's minor version must increase. 
If you follow such a transitive policy to its logical conclusion you will 
see the version numbers of individual components become meaningless, 
impossible to manage, and everyone would end up needing to increase their 
major version number just about every release.

[1] http://wiki.eclipse.org/Version_Numbering
[2] http://semver.org/

John




From:   Ed Willink e...@willink.me.uk
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   06/27/2013 02:51 PM
Subject:Re: [cross-project-issues-dev] What is a maintenance 
release
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi Ed

I am trying to understand what if any release rigour exists in the 
Eclipse release policies; indeed if there are any policies at all.

There is clearly a large discrepancy between my expectation and what I 
observe in practice.

 Regards

 Ed Willink

On 27/06/2013 18:50, Ed Merks wrote:
 You've also had ample opportunity to notice the bounds on Xtext's 
 contributions to the release train, so it's not clear what you're 
 hoping to achieve after the fact by involving a broader audience.

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


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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[John Arthorne]

 From: Denis Roy denis@eclipse.org
 
 On which day does last minute begin, as we are 13 days away from 
 the release?  As a casual observer I'm puzzled by the test early, 
 test often, fix nothing mantra.  Does today's RC somehow become 
 null and void if a respin is made and serious problems arise from it?

CDO is a +2 project, so their RC4 deadline was Tuesday. So this is two 
days after their deadline, which is definitely last minute. My 
impression is that the bug is serious and we should fix it in this case, 
but I think it was quite reasonable for David to request that we follow 
the process to make sure that all projects are informed and have an 
opportunity to give their input. 

This particular case was a perfect example of why we need to be cautious 
and have a process for fixing even serious problems at this stage. In this 
situation a fix for a serious problem two days ago introduced a much 
worse regression that has now become a blocker. This is no reflection on 
CDO - every project I have worked on has had cases like this where a 
heavily reviewed and tested last minute fix has introduced a bug more 
serious than the one we were attempting to fix. Sometimes shipping a known 
bug is better than risking introducing a worse bug. As I said in this case 
I gave my +1 but sometimes fix nothing is the right answer.

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

Re: [cross-project-issues-dev] Missing release information for some Kepler projects

[John Arthorne]

I recall the planning council recently decided on a policy that we would 
not allow a new release of a project to appear for the first time after 
RC1. Am I remembering that incorrectly? This is exactly the kind of last 
minute change that caused trouble for the release train in Juno SR2. I 
think at this point they should be contributing the same release that was 
contributed in RC1, which sounds like 4.0.

John



From:   David M Williams david_willi...@us.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   06/07/2013 09:52 AM
Subject:Re: [cross-project-issues-dev] Missing release information 
for some Kepler projects
Sent by:cross-project-issues-dev-boun...@eclipse.org



I agree its not cool. I do not know their reasons for it. I do recall 
them sending a note a month or two ago asking for preferences ... so 
suggest you and DLTK project work out which is best (for you to move to 
5.x or them to revert to 4.x). There should only be one version major 
version in the common repository. 

Good luck, 




From:Benjamin Cabé bc...@sierrawireless.com 
To:Cross project issues cross-project-issues-dev@eclipse.org, 
Date:06/07/2013 09:40 AM 
Subject:Re: [cross-project-issues-dev] Missing release information 
for some Kepler projects 
Sent by:cross-project-issues-dev-boun...@eclipse.org 



Hi, 

Contributing DLTK 5.0 and removing 4.0 at the very last minute (RC3) to 
the Kepler repo with no previous contribution before that would have 
allowed Koneki Lua Development Tools to be tested against it, is not 
really cool to say the least. LDT contribution to Kepler is now broken. 
Any chance to also include DLTK 4.0 into the Kepler repo? 

Thanks. 
Benjamin-- 


De : Alexey Panchenko alex.panche...@gmail.com
Répondre à : Cross project issues cross-project-issues-dev@eclipse.org
Date : jeudi 9 mai 2013 17:49
À : Cross project issues cross-project-issues-dev@eclipse.org
Objet : Re: [cross-project-issues-dev] Missing release information for 
some Kepler projects 

Hi, 

Unfortunately The DLTK team were quite busy this year with other projects. 
Initially the previous (4.0, released 2012) version was added to Kepler, 
with the intent to replace it later with the 5.0 builds from master. So 
far, that did not happen yet, partly because of source control (- git)  
build system (- tycho) changes. 

AFAIK DLTK is used by PDT and Koneki-Lua Development Tools. 
So the question to these projects: what DLTK version would you prefer in 
Kepler? 

Regards, 
Alex 


On Thu, May 9, 2013 at 12:26 AM, Wayne Beaton wa...@eclipse.org wrote: 
I am now only missing the information for the DLTK and Runtime Packaging 
(RTP) project. I have contacted DLTK via their mailing list; Ian has 
contacted the RTP project leaders directly (thanks, Ian).

I noticed that DLTK is contributing their 4.0 release build (from Juno) to 
Kepler, despite there being some apparent activity in the project Git 
repositories. I don't know if there is any specific issue with this, but 
thought that I'd point it out in case any downstream consumers had any 
concerns/issues.

Thanks, 


Wayne

On 04/26/2013 02:38 PM, Wayne Beaton wrote: 
I am missing release information for the following projects that have 
declared intent to participate in Kepler.

C/C++ Development Tools (CDT)
Dynamic Languages Toolkit (DLTK)
Eclipse Modeling Framework (EMF)
Eclipse Communication Framework (ECF)
Runtime Packaging Project (RTP)
EclipseLink
Ecore Tools
Extended Editing Framework (EEF)
Jubula Functional Testing Tool
MDT XSD (XML Schema Definition)
Maven Integration for Web Tools Platform
SCA Tools

In some cases, it may be that I just can't sort out what release you want 
to include, or maybe you're planning to include a release that does not 
occur on the Kepler release date (which I find weird, but is otherwise 
okay). 

If you have not done so already, please visit your project's information 
page and create a release record for Kepler and then please let me know 
either on this list or via direct email so that I can update the Kepler 
release page.

I will not accept review documentation for any release that is not 
recorded in the project metadata.

While you're there, please take a few minutes to update the description 
and plan information for your release. The description should be a  short 
paragraph that concisely describes the high points of the release. Note 
that you can still use the old XML-file based plan format if you like 
using old and painful technology.

You can quickly get access to your project's information page directly 
from the Kepler release page:

https://projects.eclipse.org/releases/kepler

Let me know if you require any assistance.

Wayne 
-- 
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects



 _ __
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org

[cross-project-issues-dev] Recent breaking change to behaviour of Runtime#exec in Oracle JRE

[John Arthorne]

The Platform team just became aware of a very recent change to the 
behaviour of some of the Runtime#exec methods in the Oracle JRE. This 
affects the most recent update of both Java SE 6 and Java SE 7 from 
Oracle. Here are the details provided in the JRE release notes:

http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html#jruntime

I recommend that all projects review their references to all Runtime#exec 
methods that take a single string as first argument. Chances are if you 
use these methods you will now have problems executing applications on 
Windows when the path contains spaces. For reference here is the Platform 
bug where we are tracking changes required in Equinox, Platform, and JDT:

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

We intend to have these addressed for RC3 where appropriate.

John
___
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] M7?

[John Arthorne]

It is currently replicating. There will be an announcement on eclipse-dev 
mailing list when it is available.

John



From:   Ed Willink e...@willink.me.uk
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   05/03/2013 01:32 PM
Subject:[cross-project-issues-dev] M7?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi

Is M7 available for the platform?

The downloads page suggests that it is and that it was built on 
Thursday, so it should now be accessible, but I get a variety of bad 
file and server retries from a selection of alternate OS'.

 Regards

 Ed Willink
___
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] Edit your eclipse.org website

[John Arthorne]

I was about to say that page looks right to me.. but then I see Wayne 
fixed it since you asked the question. Read it again.

John



From:   Mark Russell mrruss...@google.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   03/01/2013 01:32 PM
Subject:[cross-project-issues-dev] Edit your eclipse.org website
Sent by:cross-project-issues-dev-boun...@eclipse.org



This page 
http://wiki.eclipse.org/Configuring_Eclipse_to_Edit_your_eclipse.org_Website
 does not seem to be accurate any more.  Is there a replacement for it? 

Could the old page be deprecated with a link to the new page?

-- 
Mark R Russell
(724) 473-3140
Software Engineer in Test
Google Pittsburgh
___
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] Wait ... don't release yet! ... delay one week, Friday 3/1

[John Arthorne]

Since the new version of EGit was only introduced in RC3, that could only 
happen if someone changed their minimum dependency on EGit in their RC4 
contribution. That seems unlikely but projects should speak up if they 
have that constraint. Markus mentioned the only project downstream from 
EGit was WindowBuilder so it looks like at least for the EPP packages we 
should be fine.

To be clear on what versions of EGit appeared in which Juno build, it 
looks like the following (which doesn't match what we thought in the call 
today):

Juno SR0 - EGit 2.0
Juno SR1 - EGit 2.1
Juno SR2 RC1: - EGit 2.1
Juno SR2 RC2: - EGit 2.1
Juno SR2 RC3: - EGit 2.2
Juno SR2 RC4: - EGit 2.3

Matthias please correct if that's wrong.

John



From:   Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org, 
Date:   02/22/2013 03:26 PM
Subject:Re: [cross-project-issues-dev] Wait ... don't release yet! 
... delay one week, Friday 3/1
Sent by:cross-project-issues-dev-boun...@eclipse.org



I hate to throw a stick in the spokes, but what happens if another project 
in the aggregate repository already has a min dependency on EGit 2.2 or 
even 2.3?
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Matthias 
Sohn
Sent: Friday, February 22, 2013 12:15 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Wait ... don't release yet! ... 
delay one week, Friday 3/1
 
2013/2/22 David M Williams david_willi...@us.ibm.com
After some painful conversation with the Planning Council members, the 
conclusion was to delay the release 1 week, but not do a full respin, to 
only revert the EGit contribution. 

The plan is to redo the common repository and EPP packages, with the EGit 
contribution reverted to what it was in SR1, which I believe is identical 
to what it was in RC3. There are a few technical tricks I can try to 
accomplish this, so all other projects do not have to do any re-work ... 
just wait until Friday 3/1, before making your releases visible.
 
no, SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 
contains EGit 2.1.0
I'd prefer if you could rollback to 2.2.0 but if the planning council 
decided otherwise be it like that.
 
[1] 
https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Juno_maintenanceid=e5209e06bfbe2284a96b1ce357b9fcd1053072d1
 
--
Matthias___
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] Github mirroring seems broken

[John Arthorne]

Yep, maybe someone gave the mirroring script a kick, but I'm now seeing up 
to date content on github too

John




From:   Shawn Pearce s...@google.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Cc: Kevin Sawicki ke...@github.com
Date:   02/19/2013 01:27 PM
Subject:Re: [cross-project-issues-dev] Github mirroring seems 
broken
Sent by:cross-project-issues-dev-boun...@eclipse.org



Looks like https://eclipse.googlesource.com is now current.

https://eclipse.googlesource.com/orion/org.eclipse.orion.client/ shows
commits from 32 hours ago.

https://eclipse.googlesource.com/intent/org.eclipse.mylyn.docs.intent.main/

shows commits from 5 hours ago. Odd that the foundation's index is
telling me its under intent/ and not mylyn, but that's what it told
me.

https://eclipse.googlesource.com/cdo/cdo/ is 4 days old.

:-)

On Tue, Feb 19, 2013 at 8:23 AM, Shawn Pearce s...@google.com wrote:
 Oddly enough the mirror at https://eclipse.googlesource.com is also
 behind by the same amount of time. Looks like mirroring stopped
 working when the Eclipse Foundation moved their servers?



 On Tue, Feb 19, 2013 at 7:15 AM, John Arthorne 
john_artho...@ca.ibm.com wrote:
 Yes there's a noticeable delay on that recently. The most recent commit 
I am
 seeing is from 6 days ago:

 https://github.com/eclipse/orion.client

 John




 From:Alex Lagarde alex.laga...@obeo.fr
 To:Cross project issues cross-project-issues-dev@eclipse.org,
 Date:02/19/2013 09:23 AM
 Subject:[cross-project-issues-dev] Github mirroring seems 
broken
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 



 Hi everyone,

 I noticed that the Github clone of the Mylyn Intent repository
 (https://github.com/eclipse/mylyn.docs.intent.main) does not reflect my
 latest commits (last commit is 14 days old).
 It is also the case for the CDO github clone
 (https://github.com/eclipse/cdo) and the acceleo clone
 (https://github.com/eclipse/acceleo).

 So either all eclipse commiters have stop working the past 2 weeks, or
 there is an issue in the Github mirroring mechanism :)

 Does anyone know how to fix this ?

 Best regards and thanks by advance,
 Alex Lagarde (Morel)
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



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

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


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

Re: [cross-project-issues-dev] Hudson windows slave down

[John Arthorne]

Thanks Matt. The Orion Chrome tests must be the culprit here. I have 
entered this bug to track down and resolve it:

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

John




From:   Webmaster(Matt Ward) webmas...@eclipse.org
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Cc: John Arthorne/Ottawa/IBM@IBMCA
Date:   02/05/2013 09:23 AM
Subject:Re: [cross-project-issues-dev] Hudson windows slave down



On 02/04/2013 05:12 PM, John Arthorne wrote:
I might have just missed a message about this, but the Hudson Windows 
slave is offline. Can someone bring it back to life? 
I've restarted the slave agent after force killing chrome which had a ton 
of tabs open.

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

[cross-project-issues-dev] Eclipse Platform M5a required

[John Arthorne]

The Eclipse platform is planning a rebuild of M5 to address a major key 
binding regression that was introduced last week:

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

The problem is not severe for the Eclipse SDK, but for multi-page text 
editors many key bindings are broken, which severely impacts projects such 
as WTP that make heavy use of multi-page editors. The M5a build should 
occur later today and will only have the fix for that single bug compared 
to M5. If there are no objections here we would like to contribute that 
new build as our Kepler M5 contribution. We are sorry for any convenience 
this caused but we are very happy this was caught in time!

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

[cross-project-issues-dev] Hudson windows slave down

[John Arthorne]

I might have just missed a message about this, but the Hudson Windows 
slave is offline. Can someone bring it back to life?

John
___
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] Moving to a new data centre - Feb. 9, 2013

[John Arthorne]

Later in the month brings us very close to Juno SR2 which risks disrupting 
the release train (either last minute builds or the delivery to end 
users). For Kepler M5, I think we should aim to complete it for Feb 8 as 
usual, but then only announce it on Monday Feb 11 (assuming servers are 
verified up). That might be a good option for RAP too but of course that's 
up to you. Ian Skerrett has often reminded us that announcing a release on 
a Friday afternoon is the worst possible time from a marketing 
perspective, so announcing a release first thing the next week has its 
advantages.

john



From:   Denis Roy denis@eclipse.org
To: cross-project-issues-dev@eclipse.org, 
Date:   01/11/2013 11:52 AM
Subject:Re: [cross-project-issues-dev] Moving to a new data centre 
- Feb. 9, 2013
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi Markus,

We've examined all the dates and have concluded that Feb 9-10 to be the 
best one, which also provides us with a fall-back date of Feb 16-17 should 
there be migration issues or horrendous weather.

It is unfortunate, but please work with your community on a new release 
date.

Thanks,

Denis




On 01/11/2013 11:16 AM, Markus Knauer wrote:
Hi Denis,

we, the RAP project, have scheduled our RAP 2.0 release for the 8th of 
February, the day before your planned data centre move. For us this is a 
very unfortunate timing and we would like to avoid the frustration and 
this kind of first impression of our users trying to download it.

The same applies for the Kepler M5 release. This is scheduled for the same 
Friday and will face the same problems.

As far as I can see, I change of the move by one week would be much better 
according to the different Eclipse calenders that I know. If the date of 
this move is finalized, we must consider re-scheduling the releases.

Thanks,
Markus



On Fri, Jan 11, 2013 at 3:00 PM, Denis Roy denis@eclipse.org wrote:
In case you missed this announcement on the committers list...

On Saturday, February 9 2013 the Eclipse Foundation will be moving its 
servers to a new data centre.  This modern facility will provide improved 
server cooling, substantial increases to our bandwidth, available AC power 
and cabinet (rack) space while reducing our hosting costs.  During the 
move, all eclipse.org services will be offline, including Bugzilla, Wiki, 
Git, Gerrit and our website, www.eclipse.org.  Our plans are to begin the 
move on Saturday morning (Eastern time), February 9 2013 and have all 
services restored by Sunday afternoon, February 10 2013. 

We'd like to apologize in advance for the inconveniences that this move 
will cause.  However, the benefits are compelling and will provide the 
Eclipse Foundation with the infrastructure needed to continue its growth 
for many years to come.

If you have any questions or concerns, please contact me at 
webmas...@eclipse.org

Thanks,

Denis

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

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

Re: [cross-project-issues-dev] Some Juno participants have not signed up for Kepler

[John Arthorne]

I have now marked Orion as participating. Orion releases several times a 
year so we haven't even started thinking about the June release yet ;) 

John



From:   Wayne Beaton wa...@eclipse.org
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   01/08/2013 04:17 PM
Subject:[cross-project-issues-dev] Some Juno participants have not 
signed  up for Kepler
Sent by:cross-project-issues-dev-boun...@eclipse.org



AFAICT, the following Juno participants  have not yet signed up to 
participate in Kepler:

Virgo, Jetty, Xtend, Xtext, Modeling Workflow Engine, Orion, and Data 
Tools Platform

I assume that at least some of these are oversights/errors. Can everybody 
please take a look at the projects you care about?

Thanks,

Wayne
-- 
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

image/png___
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] Cannot find GIT replacement now that Anonymous CVS is broken for Hudson builds

[John Arthorne]

The original discussions of the CVS shutdown did involve leaving a read 
only service intact [1]. Not all code from past releases was migrated, so 
anyone wanting to find the source for an old release, or do long term 
maintenance on old releases, needs access to the CVS data. At the very 
least we need the tarred archives to be made available soon, so we are not 
in a state where source from past releases (or build scripts to produce 
them) is completely unavailable. 

Having said that, the value of a read only CVS service is limited. As 
Konstantin mentioned it can lead to confusion, and anyone wanting to 
reproduce old builds will eventually need a write accessible repository. 
There is a good chance anyone consuming non-Orbit bundles from CVS is 
getting a bad stale copy and should really be moving to the Git 
equivalent. There is evidently a cost to maintaining the read-only CVS 
service so that has to be weighed against the limited value of keeping it 
around.

John

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




From:   Carl Anderson c...@us.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Cc: cross-project-issues-dev@eclipse.org, 
cross-project-issues-dev-boun...@eclipse.org
Date:   01/03/2013 01:28 PM
Subject:Re: [cross-project-issues-dev] Cannot find GIT replacement 
now that Anonymous CVS is broken for Hudson builds
Sent by:cross-project-issues-dev-boun...@eclipse.org



Denis,

Was it really necessary to terminate the anonymous service?  I am just 
worried about the impact that that will have on WTP users who wish to get 
the source for the Juno release (and prior releases).  We went to the 
effort of putting in the appropriate Eclipse-SourceReferences information 
in all of our plugins, and all through the Juno release, these were set up 
for anonymous CVS access to our source.  Now those 
Eclipse-SourceReferences are useless.  Is there really no possibility of 
restoring the read-only anonymous access?  (And I know that WTP is not the 
only project that set up Eclipse-SourceReferences to CVS code- even the 
platform in all of its Indigo releases, has CVS Eclipse-SourceReferences.)

FWIW,

- Carl Anderson
WTP programmer

Denis Roy ---12/29/2012 10:25:54 AM---On 12/29/2012 09:52 AM, Ed Willink 
wrote:  Hi


From:

Denis Roy denis@eclipse.org

To:

cross-project-issues-dev@eclipse.org

Date:

12/29/2012 10:25 AM

Subject:

Re: [cross-project-issues-dev] Cannot find GIT replacement now that 
Anonymous CVS is broken for Hudson builds

Sent by:

cross-project-issues-dev-boun...@eclipse.org



On 12/29/2012 09:52 AM, Ed Willink wrote:
 Hi

 But if CVS only went readonly as announced why does anonymous readonly 
 access fail?

Because we've terminated the anonymous CVS service.



 Unfortunately there is no org.eclipse.test project. It is kind of part 
 of the platform which has about 10 GITs, 5 for releng. Hence the 
 question; is there a broswer/search tool.

You can browse repos here:  http://git.eclipse.org/c

If you can't find it, then you could ask on that project's -dev list  :-)

Denis





 Regards

 Ed Willink


 On 29/12/2012 14:37, Denis Roy wrote:
 You can still access the direct filesystem from Hudson/Build.

 Replace :pserver:anonym...@dev.eclipse.org:/cvsroot/repo with 
 /cvsroot/repo or file:///cvsroot/repo is a URI is required.

 But really, as you know, the underlying CVS repository is no longer 
 being maintained, and switching your build to using the project's Git 
 repo is better.

 To locate the new Git repo , I would navigate to that project's 
 website.  I would expect to see information on the source 
 repositories there.

 Denis





 On 12/29/2012 08:44 AM, Ed Willink wrote:
 Hi

 It seems we are not allowed to use even anonymous CVS access any 
 more; https://bugs.eclipse.org/bugs/show_bug.cgi?id=397237

 This breaks any build that continues to use CVS to load 
 org.eclipse.test.

 Looking for the GIT replacement, I first tried EMF's releng; no 
 EMF's going to break too.

 Then I tried browsing /gitroot; not obvious.

 Then I tried searching wiki; no useful matches for org.eclipse.test 
 and GIT.

 So, how does one locate the GIT repo, P2 repo, for a given 
 org.eclipse plugin?

 Regards

 Ed Willink
 ___


___
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

image/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gif___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org

Re: [cross-project-issues-dev] Cannot find GIT replacement now that Anonymous CVS is broken for Hudson builds

[John Arthorne]

Denis Roy wrote on 01/03/2013 02:53:48 PM:

 Actually, the bug doesn't involve leaving a read only service intact
 at all.  The repos are still in their locations, read-only, but 
 pserver has been shut down.

Yes it depends on your interpretation of read only. If you interpret 
this to mean people with eclipse.org file system access can read it, 
then we're good. If this is interpreted as public read only access, then 
it's not. In any case I see the discussion has now moved into a bug report 
so that's a reasonable place to continue it:

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

John___
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 M4 +3

[John Arthorne]

Eric Gwin eric.g...@oracle.com wrote on 12/20/2012 02:04:11 PM:
 
 No. EclipseLink's M4 was 2.5.0.v20121016-ab08992, it is what was 
 included in the aggregation files. However, Dali is including 
 EclipseLink directly, and they are using M5 (2.5.0.v20121120-
 ec51fcc). So currently both versions are in the aggregation. 
 
 When I released our M5 I thought I had updated the aggregation files
 to reflect the new Milestone. However somehow it never did occur. I 
 probably forgot to push my local change, and later issues caused me 
 to re-clone so the change was lost.

There is clearly still confusion on dates and milestones. Kepler M5 will 
be February 8, 2013. See

http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan#Schedule

John___
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] [wtp-dev] ETA for declaring WTP M4 build?

[John Arthorne]

Wouldn't you just build against the candidate that they have already 
contributed? I don't follow how this prevents a project from contributing 
their own candidate to the aggregation. There are enough circular 
dependencies between projects at the same level in the train that we 
could never produce anything if nobody contributed a candidate until all 
their upstream dependencies are declared themselves completely done. For 
example Platform requires EMF and vice-versa, so we each need to build 
against each other's candidates before either can be done.

John




From:   Konstantin Komissarchik konstantin.komissarc...@oracle.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org, 
'General discussion of project-wide or architectural issues.' 
wtp-...@eclipse.org, 
Date:   12/19/2012 02:56 PM
Subject:Re: [cross-project-issues-dev] [wtp-dev] ETA for declaring 
WTP M4  build?
Sent by:cross-project-issues-dev-boun...@eclipse.org



Just to clarify… Presence in the aggregation build is only one necessary 
aspect. Many projects are waiting on WTP to declare M4, so we know what to 
build against.
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Chuck 
Bridgham
Sent: Wednesday, December 19, 2012 11:10 AM
To: General discussion of project-wide or architectural issues.
Cc: 'Cross project issues'; wtp-dev-boun...@eclipse.org
Subject: Re: [cross-project-issues-dev] [wtp-dev] ETA for declaring WTP M4 
build?
 
We are in the candidate aggregation build, we just delayed the official 
declare because all teams were delayed being down in numbers this time of 
year. 

The declare is coming very soon   -  (Carl is on vacation officially...) 


Thanks - Chuck

Senior Architect, RAD Java EE Tools, WTP PMC Lead
IBM Software Lab - Research Triangle Park, NC 



From:Konstantin Komissarchik konstantin.komissarc...@oracle.com
 
To:'General discussion of project-wide or architectural issues.' 
wtp-...@eclipse.org 
Cc:'Cross project issues' cross-project-issues-dev@eclipse.org 

Date:12/19/2012 12:28 PM 
Subject:[wtp-dev] ETA for declaring WTP M4 build? 
Sent by:wtp-dev-boun...@eclipse.org 




Is there an ETA for declaring WTP M4 build? I see that every project 
besides JSDT and releng have signed off? 
  
http://wiki.eclipse.org/WTP_Smoke_Test_Results_R350_12172012 
  
The lack of WTP M4 build is blocking all of the downstream projects from 
making their M4 contributions. 
  
- Konstantin___
wtp-dev mailing list
wtp-...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

Re: [cross-project-issues-dev] Status and outlook for Kepler M4 at end of +1

[John Arthorne]

Yes, this BIRT dependency is invalid due to the ICU4J version increase in 
Kepler:

org.eclipse.birt.core 4.2.1.v201209121203 depends on: package 
com.ibm.icu.lang [3.4.4,5.0.0)

It looks like there is already a BIRT bug report for this:

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

John




From:   Grégoire Dupé gd...@mia-software.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date:   12/18/2012 02:25 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for 
Kepler M4 at end of +1
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hello,

When I try to build MoDisco, I get the following error :

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: 
org.eclipse.modisco.doc.api.report.eclipsepackage 0.0.0
[ERROR]   Only one of the following can be installed at once: [com.ibm.icu 
4.4.2.v20110823, com.ibm.icu 4.0.1.v20100112, com.ibm.icu 4.2.1.v20100412, 
com.ibm.icu 50.1.0.v20121116-2]
[ERROR]   Cannot satisfy dependency: org.eclipse.birt.chart.engine 
4.2.1.v201209041636 depends on: bundle org.eclipse.birt.core [2.1.0,5.0.0)
[ERROR]   Cannot satisfy dependency: org.eclipse.birt.core 
4.2.1.v201209121203 depends on: package com.ibm.icu.lang [3.4.4,5.0.0)
[ERROR]   Cannot satisfy dependency: org.eclipse.e4.rcp.feature.group 
1.1.0.v20121210-193513-9gFTdGWGGGduU3t_iBdO01nz--4 depends on: com.ibm.icu 
[50.1.0.v20121116-2]
[ERROR]   Cannot satisfy dependency: 
org.eclipse.modisco.doc.api.report.eclipsepackage 0.0.0 depends on: 
org.eclipse.modisco.java.discoverer.benchmark.feature.feature.group 0.0.0
[ERROR]   Cannot satisfy dependency: 
org.eclipse.modisco.doc.api.report.eclipsepackage 0.0.0 depends on: 
org.eclipse.rcp.feature.group 0.0.0
[ERROR]   Cannot satisfy dependency: 
org.eclipse.modisco.java.discoverer.benchmark 0.10.1.qualifier depends on: 
bundle org.eclipse.birt.chart.engine 2.5.1
[ERROR]   Cannot satisfy dependency: 
org.eclipse.modisco.java.discoverer.benchmark.feature.feature.group 
0.10.1.qualifier depends on: org.eclipse.modisco.java.discoverer.benchmark 
0.0.0
[ERROR]   Cannot satisfy dependency: org.eclipse.rcp.feature.group 
4.3.0.v20121212-184727-7IAUA7Bs-QiyWqWVNz0_nT4qjCeP depends on: 
org.eclipse.e4.rcp.feature.group 
[1.1.0.v20121210-193513-9gFTdGWGGGduU3t_iBdO01nz--4]
[ERROR] 
[ERROR] Internal error: java.lang.RuntimeException: No solution found 
because the problem is unsatisfiable.: [Unable to satisfy dependency 
from org.eclipse.acceleo.common 3.3.0.v20120131-0422 to bundle 
com.google.collect 0.0.0., Unable to satisfy dependency from 
org.eclipse.acceleo.engine 3.3.0.v20111213-0806 to bundle 
com.google.collect 1.0.0., Unable to satisfy dependency from 
org.eclipse.acceleo.engine 3.3.0.v20120131-0422 to bundle 
com.google.collect 1.0.0., No solution found because the problem is 
unsatisfiable.] - [Help 1]

I assume that this error is related to the dependency from Birt to 
com.ibm.icu.lang. I'll have to wait the new build of Birt, I may be late 
to deliver MoDisco.

Regards,
Grégoire


- Mail Original -
De: David M Williams david_willi...@us.ibm.com
À: Cross project issues (cross-project-issues-dev@eclipse.org) 
cross-project-issues-dev@eclipse.org
Envoyé: Lundi 17 Décembre 2012 23h20:28 GMT +01:00 Amsterdam / Berlin / 
Berne / Rome / Stockholm / Vienne
Objet: [cross-project-issues-dev] Status and outlook for Kepler M4 at end 
of +1


We finally got a green build! Though, I did have to disable a few things, 
either there was a conflict, such as for ICU4J v50 vs 4.2, and many others 
because something else was disabled. 

There's the current status of enabled flag: 

Whole contribution disabled ... never enabled for Kepler. I'll remove 
these if I don't hear something soon. 

emf-query2.b3aggrcon - org.eclipse.simrel.build 
jwt.b3aggrcon - org.eclipse.simrel.build 


These have a feature or repository disabled, some disabled by owners, 
since they knew they needed some work still, and a few disabled by me, 
based on what I could see using the b3 aggregator editor's validate 
aggregation function. Feel free to re-enable if/when you think ready. 

amp.b3aggrcon - org.eclipse.simrel.build 
birt.b3aggrcon - org.eclipse.simrel.build 
dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) 
egit.b3aggrcon - org.eclipse.simrel.build 
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build (2 matches) 
mat.b3aggrcon - org.eclipse.simrel.build 
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build 
mmt-qvto.b3aggrcon - org.eclipse.simrel.build 
soa-bpel.b3aggrcon - org.eclipse.simrel.build 
webtools.b3aggrcon - org.eclipse.simrel.build 

I've promoted what we had from this first green build to 
.../releases/staging. 

Don't forget to check the reports occasionally: 
http://build.eclipse.org/simrel/kepler/reporeports/ 

Thanks, 

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

[cross-project-issues-dev] Eclipse Platform Juno performance update

[John Arthorne]

The Eclipse Project PMC has prepared a brief update on the state of the 
investigation of performance problems some people are seeing in the Juno 
release. The update includes a short summary of the problems been seeing, 
some analysis, and the plan of action over the coming months. The update 
is captured on a wiki page, with the intent that we can keep this updated 
as we learn more. Some good progress has been made already by the small 
group of active committers, and there has been some great community 
support in the form of problem analysis, profiling, and testing patches. 
Thanks for all the hard work and important community discussions that have 
gone into this over the past few weeks.

http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation

John, on behalf of the Eclipse Project PMC___
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

[John Arthorne]

 2012 15:29:31 +0200, 
cross-project-issues-dev-requ...@eclipse.org wrote:

 Date: Wed, 5 Sep 2012 09:21:10 -0400
 From: John Arthorne john_artho...@ca.ibm.com
 To: Cross project issues cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2
 Message-ID:
 of6b7596fb.b62ef228-on85257a70.0048e946-85257a70.00495...@ca.ibm.com
 Content-Type: text/plain; charset=us-ascii

 I suggest anyone having problems to add constructive details on that 
bug.
 For example profiler output when repeatedly performing a slow operation,
 what plugins are installed, whether it is reproducible with vanilla
 Eclipse SDK, etc. There are some users reporting pervasive slowdowns, 
and
 for many others it is performing well. Something like a listener leak
 could have effects like this in conjunction with particular installed
 plugins. It takes time after any major release to isolate and resolve
 problems like this.

 John

 On Wed, Sep 5, 2012 at 3:08 PM, Thomas Hallgren tho...@tada.se wrote:
 Hi,

 For various reasons I had to switch my development environment from 4.2 
 to
 3.8 today. I was stunned by the performance improvement after the 
switch.
 The 3.8 platform is much MUCH faster. It boots faster, it closes windows
 faster, it shows menus faster, etc. It also seems to consume less memory
 and be less buggy. The way things stand right now, there's just no way
 I'll switch back to 4.2!

 I must say I was very surprised by this. Why is the 4.2 platform what's
 being fronted on the Eclipse download page when it's user experience and
 quality is lagging behind this much? Is it just me who have had this
 experience?

 Regards,
 Thomas Hallgren

 --

 Message: 5
 Date: Wed, 5 Sep 2012 06:29:22 -0700
 From: Konstantin Komissarchik konstantin.komissarc...@oracle.com
 To: 'Cross project issues' cross-project-issues-dev@eclipse.org
 Subject: Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2
 Message-ID: 001201cd8b6a$76b74950$6425dbf0$@komissarc...@oracle.com
 Content-Type: text/plain; charset=utf-8

 Thomas,


 You are certainly not the only one seeing performance issues with 4.2. I 

 go back and forth between 4.2 and 3.8 every day depending on the project 

 I need to work on and the difference is quiet noticeable even on very 
 fast hardware. The part I notice the most is the lengthy close all 
 editors process. After drilling down into some task and opening a few 
 dozen editors, clearing workbench of open editors takes several seconds. 

 I can literally watch tabs disappear one by one. The same operation is 
 practically instantaneous on 3.8.


 For stability, user experience and performance reasons, you will find 
 that many third party distros have stayed on 3.8 for Juno.


 I don?t begrudge 4.x its growing pains. It is a complex technological 
 shift with a lot of promise. What I find most troubling is the decision 
 process that led to the use of 4.2 for Juno distros. When the decision 
 was made, it was plainly evident that 4.2 wasn?t going to match 3.8 on 
 any of the quality metrics. IDE users might have been ok with quality 
 drop if 4.2 delivered compelling new functionality that you couldn?t get 

 in 3.8, yet there is no tangible functional delta. The value of 4.x 
 platform is for RCP developers and to certain limited extent for IDE 
 plugin developers. Certainly not for IDE users. The refreshed 
 look-n-feel has been touted as a big end user feature of 4.2, but the 
 new look-n-feel itself has numerous issues that leave it looking like an 

 unfinished project.


 Sadly, the user reaction that we?ve been seeing over the last several 
 months has been entirely predictable.


 - Konstantin

-- 
Kind regards,
Mit freundlichen Grüßen
Andrey Loskutov

+Andrey: http://plus.google.com/u/0/113794713998126448910
___
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

image/gif___
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] ssh accounts locked

[John Arthorne]

ssh login to build.eclipse.org seems to be denying everyone. Just so 
everyone doesn't report the same bug, here it is:

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

John___
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] EGit / line ending problems with simrel repo

[John Arthorne]

For what it's worth, we settled on the following approach for the Eclipse 
top-level project (always use Unix delimiters and use Eclipse settings to 
control it):

http://wiki.eclipse.org/Platform-releng/Git_Workflows#Dealing_with_line_terminators

Also note you can select an entire project/folder/etc and do File  
Convert Line Delimiters To  Unix to make sure you are in a consistent 
state.

John




Ed Willink e...@willink.me.uk 
Sent by: cross-project-issues-dev-boun...@eclipse.org
08/16/2012 06:32 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
Cross project issues cross-project-issues-dev@eclipse.org
cc

Subject
Re: [cross-project-issues-dev] EGit / line ending problems with simrel 
repo






Hi

After a quick Google it seems GIT does not normalize Windows line 
endings unless autocrlf is set true, which may have other bad effects 
like normalizing binary files too.

So if we use the default autocrlf=false we are left with the bad 
alternative; get all CR-LF producing tools fixed, which is difficult 
since Eclipse's default line-endings on Windows are CR-LF, so CR-LF 
production is correct.

I did a quick scan of my Workspace for CR-LFs; Eclipse locked up with 
over 65000 search matches.

After a kill and restart and a search in a single project, I had two 
rogue files; both manually edited Java files. It seems that once you get 
a CR-LF from somewhere, JDT's indentation preservation also preserves 
line termination and once there are some CR-LFs, JDT thinks you like them.

So until EGIT acquires CVS's binary flag our only solution is to 
regularly manually remove all CR-LFs that have leaked in somehow.

 Regards

 Ed Willink

On 16/08/2012 10:44, Eike Stepper wrote:
 Am 16.08.2012 11:25, schrieb Ed Willink:
 Hi Eike

 Hi

 My suspicion is that the problem is in the comparison tooling.

 The files in the repo seem to be normalized to LF line endings, but 
 some Windows tooling creates CR-LF; some tools can
 be fixed via Bugzillas but it's a losing battle.

 I totally disagree. All these tools have been working fine with all 
 other version control systems.
 We agree. I was just elaborating the bad alternative.

 Good ;-)

 And the false positives in the staging view appear with no 
 comparison tool being involved. And it's impossible to get
 rid of them by means of the tool (EGit) that has created them.
 There is a comparison. EGIT must do a file compare to determine 
 whether the file is changed. If you edit a file and edit
 it back again, the file disappears from the staging view, so EGIT 
 must be using content rather than timestamp to detect
 changes.

 Oh, of course I know that. I *guess* it's done with the SHA1 digests 
 of the files' contents because they're needed anyway.

 Cheers
 /Eike

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


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


 -
 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2012.0.2197 / Virus Database: 2437/5203 - Release Date: 
08/15/12



___
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] HTTP git access

[John Arthorne]

It is working fine for me. I tried both HTTP and SSH connections to git 
repositories at eclipse and they connect just fine.

John




Zeb Ford-Reitz zeb.ford-re...@bredex.de 
Sent by: cross-project-issues-dev-boun...@eclipse.org
07/06/2012 06:24 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
Cross project issues cross-project-issues-dev@eclipse.org
cc

Subject
[cross-project-issues-dev] HTTP git access






Hi everybody,

I'm currently having trouble accessing git at eclipse.org over HTTP (SSH 
is working fine). I'm going to investigate whether there's an internal 
issue with our company's proxy, but I thought I would mention it on the 
mailing list in case eclipse.org's git is having trouble serving up 
content over HTTP. Is anyone else experiencing a similar problem?

Thanks,
Zeb

-- 
BREDEX GmbH
Mauernstr. 33
38100 Braunschweig

Tel.: +49-531-24330-0
Fax:  +49-531-24330-99
http: www.bredex.de

Geschäftsführer: Hans-J. Brede, Achim Lörke, Ulrich Obst
Amtsgericht Braunschweig HRB 2450


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



smime.p7s
Description: Binary data
___
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] List of files on Eclipse Mirror servers

[John Arthorne]

It is available as a plain text file. Try this:

 
http://download.eclipse.org/technology/phoenix/download.eclipse.org-filelist.txt

John





Eike Stepper step...@esc-net.de 
Sent by: cross-project-issues-dev-boun...@eclipse.org
06/21/2012 07:48 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
cross-project-issues-dev@eclipse.org
cc

Subject
Re: [cross-project-issues-dev] List of files on Eclipse Mirror  servers






Thanks for all the hints!

I think I'm going to skip this entire exercise if it requires to install 
new tools for standard tasks. Why has gzip been 
used if gunzip is not available easily on Windows?

Cheers
/Eike


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



Am 21.06.2012 05:43, schrieb Eike Stepper:
 I'm feeling so dumb ;-(

 Both did not work for me:

 I unizpped, then renamed the resulting .txt file to .zip and tried to 
unzip that again. Doesn't work.

 I tried to unzip the original zip twice although that seemed even more 
sillly to me. Doesn't work either.

 Is it a problem that I use WinZip? Why does this has to be so special?

 Cheers
 /Eike

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



 Am 19.06.2012 23:29, schrieb Andrew Overholt:
 I had to gunzip it twice...

 On Tue, Jun 19, 2012 at 5:15 PM, David M Williams
 david_willi...@us.ibm.com wrote:
 Is it just me? I can't seem to unpack this file to see what's in it. I
 download it, then run
 gzip -d download.eclipse.org-filelist.txt.gz

 but the result txt file just looks like a lot of binary gobbledygook 
... do
 I need a windows machine or something? :)





 From: Denis Roydenis@eclipse.org
 To: Cross project issuescross-project-issues-dev@eclipse.org,
 Date: 06/19/2012 10:37 AM
 Subject: [cross-project-issues-dev] List of files on Eclipse Mirror
 servers
 Sent by: cross-project-issues-dev-boun...@eclipse.org
 



 To help you clean up older builds and files from the Eclipse download
 server, I've compiled a list of files that are actually sync'ed to our
 mirrors.

 
http://download.eclipse.org/technology/phoenix/download.eclipse.org-filelist.txt.gz


 I each project to look at the file list, and either remove files that
 are no longer needed, or move older releases[1] to the archives.

 Thanks,

 Denis


 [1] http://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads

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



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


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


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

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

[John Arthorne]

David Williams wrote on 06/12/2012 05:15:26 PM:
 
 I appreciate everyone keeping the build green and making progress 
 on the sim rel reports [1], though there are a few serious issues 
 left there. 
 
 [1] http://build.eclipse.org/juno/simrel/reporeports/ 

I looked through these, and at this point I think most of them are not 
blocking the release. Just to save people some time digging through them, 
these are the remaining issues that I believe are important for Juno (see 
above report for details):

1) 10 bundles with missing about.html. Six bundles from emf.query2, four 
from Gemini.

2) 10 features with no license (in particular their license is the string 
%license). 1 from Virgo, 9 from Gemini. The most common cause of this is 
missing key in feature.properties file, or the feature.properties file 
itself is not included in the bin.includes list in the feature's 
build.properties file.

3) Multiple copies of bundles from eclipse.org projects. These might not 
be a problem if they are known or understood, but it might mean another 
project is including old, unreleased versions of another project's 
bundles. The core.commands dependency seems to be coming from Sapphire, 
and the remaining dependencies look like they come from RAP.

org.eclipse.jetty.xml
8.1.3.v20120522
8.1.3.v20120416
org.eclipse.core.commands
3.6.1.v20120521-2332
3.6.1.v20120521-2329
org.eclipse.rap.jface
1.5.0.20120612-1458
1.5.0.20120605-1606
org.eclipse.jetty.webapp
8.1.3.v20120522
8.1.3.v20120416
org.eclipse.rap.rwt.osgi
1.5.0.20120612-1458
1.5.0.20120605-1606
org.eclipse.rap.rwt
1.5.0.20120612-1458
1.5.0.20120605-1606

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

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

[John Arthorne]

Konstantin Komissarchik wrote on 06/13/2012 10:14:52 AM:
 Re: [cross-project-issues-dev] Status and Outlook for Juno!
 
  It looks like this dependency is coming from RT packaging, not 
Saphire:
 
 That makes more sense. All Sapphire dependencies are written very 
 broadly since the Juno release is actually compatible back to 
 Helios. For org.eclipse.core.commands, our sole dependency is written 
like so:

Yep, sorry for the false alarm. That will teach me for trying to scan a 
32MB XML file in Notepad... Thanks for the correction Paul.

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

[cross-project-issues-dev] Input on platform rebuild decision

[John Arthorne]

The Platform is considering an RC4 rebuild to pick up a new version of 
ECF. We are far past our contribution deadline at this point, so can you 
please chime in on this bug if this affects your project either way. The 
last thing we want to do is further disrupt the release train after the 
weekend Hudson outage. 

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

John___
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] Juno RC2 is complete

[John Arthorne]

Depending on the time of day, Eclipse bandwidth has been completely 
saturated recently, which can make for some very slow downloads. In our 
lab we have measured downloads as slow as 10KB/s and often in the range of 
15-20KBs [1]. The worst time of day seems to be mornings EDT.  The 4MB in 
the two repositories currently in the composite Juno repository would take 
about 6 minutes at 10KB/s so your numbers sound about right. I believe 
when we release these files typically get redirected to somewhere like 
amazon where the throughput is much better. Also we will only have a 
single repository so the number should drop in half from today where we 
have two. As another data point, our repository in Juno is about 10% 
smaller than Indigo SR2 despite having about 100 more IUs, due to 
optimization work in the p2 repository format.

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

John




Konstantin Komissarchik konstantin.komissarc...@oracle.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org
06/01/2012 11:11 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
'Cross project issues' cross-project-issues-dev@eclipse.org
cc

Subject
Re: [cross-project-issues-dev] Juno RC2 is complete






Is a long delay typical when referencing the juno repository. I just 
downloaded the RC2 JEE package and went to try Sapphire install. After 
pointing to the repo [1]. It just sits there in “Pending…” state. Been a 
few minutes like that. I checked and there is nothing wrong with my 
network connection.
 
[1] http://download.eclipse.org/releases/juno/
 
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus 
Knauer
Sent: Friday, June 01, 2012 6:39 AM
To: Cross project issues; EPP Developer Mailing List
Subject: Re: [cross-project-issues-dev] Juno RC2 is complete
 
EPP RC2 packages with a +1 from their package maintainer are available 
from the developer tab on the download page:

  http://www.eclipse.org/downloads/index-developer.php

Users upgrading from RC1 to RC2 should have a look at [1].

Thanks,
Markus


[1] Bug 347455 - Reduce number of child repositories of the EPP p2 
repository


 
On Fri, Jun 1, 2012 at 3:10 PM, David M Williams 
david_willi...@us.ibm.com wrote:
I've promoted and made visible the RC2 content at 

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

Unless someone reports incompatibilities, that repository is a composite 
of RC2 and RC1. 

The EPP packages will be available soon from 

http://www.eclipse.org/downloads/index-developer.php 

Thanks all, 

Test well ... not much time left! 

Don't forget to read and work on http://wiki.eclipse.org/Juno/Final_Daze 


___
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] The PermGen problem

[John Arthorne]

Bug 265525 is about heap space. We did increase the heap space across all 
platforms in 4.2 release (see bug 373679).

However Ed is talking about permgen memory, and in particular he is 
talking about the case of launching a nested Eclipse. This is a very 
difficult problem to solve and there has been investigation on it over the 
past few months. I won't bore this list with the details, but please see 
this bug if you are interested (and ideas are welcome):

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

John

PS - Ed, I agree with you, I don't know why the JDK vendor continues to 
ship the JDK in a form that is not usable out of the box as applications 
get more demanding...





Miles Parker miles.par...@tasktop.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org
05/29/2012 04:22 PM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
Cross project issues cross-project-issues-dev@eclipse.org
cc

Subject
Re: [cross-project-issues-dev] The PermGen problem







Ed,

Perhaps it's time to revisit the default settings with a new enhancement 
request?

Here's mine from a couple of years ago -- after much discussion the 
community arrived at the solution to up the Mac 64 bit settings but not 
other ones, don't know if this has changed subsequently..

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

cheers,

Miles

On 2012-05-29, at 12:47 PM, Ed Willink wrote:

Hi

RC2: Just suffered from launching a nested Eclipse with an inadequate 
PermGen and the usual UI lockouts and need to kill Eclipse.

Why are we still shipping a product that is increasingly unuseable out of 
the box as applications get more demanding?

It irritates me and I know what I'm doing. It's clear from newsgroups that 
users have trouble too. It's just not user friendly.

  Regards

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

__
Miles T. Parker
Senior Solutions Architect
Tasktop
http://tasktop.com
Committer, Eclipse Mylyn and Virgo
Project Lead, Model Focussing Tools and AMP
http://milesparker.blogspot.com




___
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] Juno RC1 repository is ready

[John Arthorne]

Actually this one is for Olivier Thomann, who is currently using 3.8 and 
hunts me down every time it tries to upgrade him to 4.2 ;)

John




David M Williams david_willi...@us.ibm.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org
05/25/2012 01:23 PM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
Cross project issues cross-project-issues-dev@eclipse.org
cc
Cross project issues cross-project-issues-dev@eclipse.org, 
cross-project-issues-dev-boun...@eclipse.org
Subject
Re: [cross-project-issues-dev] Juno RC1 repository is ready






What John wants, John gets :) 

I'll reverse the logic and say if someone needs it, they'll have to speak 
up. For now, I'll remove the M7 tie-in (but leave the sub repo there on 
disk, if someone really needs it). 

Thanks, 



John Arthorne ---05/25/2012 11:48:42 AM---The main problem I am aware of 
is that the M7 build had incorrect p2  metadata causing it to offer u

From: John Arthorne john_artho...@ca.ibm.com
To: Cross project issues cross-project-issues-dev@eclipse.org, 
Date: 05/25/2012 11:48 AM
Subject: Re: [cross-project-issues-dev] Juno RC1 repository is ready
Sent by: cross-project-issues-dev-boun...@eclipse.org



The main problem I am aware of is that the M7 build had incorrect p2 
metadata causing it to offer upgrading from 3.8 to 4.2 M7. This is 
annoying for those with a need to stay on 3.x, some of whom have been 
personally pestering me about fixing it... so from my perspective we could 
remove M7 but if someone has a need for it we can keep it a few more days. 


John 



David M Williams david_willi...@us.ibm.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org 
05/25/2012 09:33 AM 


Please respond to
Cross project issues cross-project-issues-dev@eclipse.org



To
cross-project-issues-dev@eclipse.org 
cc

Subject
[cross-project-issues-dev] Juno RC1 repository is ready








I have flipped the switch for Juno software repository so it now 
contains RC1 content, along with the previous M7 content. 

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

I haven't officially tested RC1 and M7 coexistence compatibility, but am 
assuming its close enough not to cause problems, and should allow testing 
of update and rollback scenarios, so have fun testing early and often. 
(If anyone finds any serious compatibility problems having them both there 
in the composite, please open a bug and we can consider removing M7, if 
its causing more problems than its worth.)

The RC1 EPP packages will be available later today (if not already) from 

http://www.eclipse.org/downloads/index-developer.php

Test well, 

And, Thanks! ___
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

image/gifimage/gifimage/gifimage/gif___
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!

[John Arthorne]

Stephan Herrmann wrote on 05/24/2012 06:30:51 AM:
 
 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?

The signature is fine if the certificate was not expired at the time the 
signing occurred. AFAIK you don't need to rebuild because of this. All of 
the jars from our past releases are in the same boat.

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

[cross-project-issues-dev] Any way to kill rogue process on hudson slave?

[John Arthorne]

I have a rogue process still running on the Hudson windows slave from a 
previous build. This causes all subsequent builds to fail and it prevents 
cleaning up the workspace. Is there any way to forcefully kill a rogue 
test process or otherwise get the slave  back into a good state?

ERROR: Failed to clean the workspace
java.io.IOException: Unable to delete 
c:\hb\workspace\orion-jstest-windows\test\eclipse\configuration\org.eclipse.core.runtime\.manager\.tmp3388515537762068288.instance

John___
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] New PDE error reporting in 4.2m4

[John Arthorne]

I suggest entering a bug against PDE and we can track it down from there. 
According to Curtis the default severity for missing versions is ignore 
and this hasn't changed in Juno. I quickly checked these settings in 
latest 4.2 build and I also see them as ignore. It could be something 
peculiar about your target platform or about how your workspace was 
upgraded.

John




Oberhuber, Martin martin.oberhu...@windriver.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org
01/19/2012 09:36 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
Cross project issues (cross-project-issues-dev@eclipse.org) 
cross-project-issues-dev@eclipse.org
cc

Subject
[cross-project-issues-dev] New PDE error reporting in 4.2m4






Hi all,
 
Updating to 4.2m4 as my SDK for development, I’m finding myself swamped 
with tons of new errors such that I can’t compile my code any more.
 
I do see some value in reporting issues such as version constraints in 
require-bundle, but …
-  Some messages do not seem appropriate to report as errors (eg 
exporting an “internal” package with x-friends should not require 
specifying a version with the package; or, adding additional files to the 
source build should not be an error).
-  And it should be easier to turn them from “error” to “warning” 
(which Preference Page item corresponds to what error?)
 
The effort needed before I can compile my code which has been running fine 
for years seems not acceptable for me.
For instance, I’d expect a quickfix “convert this error into a warning” 
with each of the new reports introduced.
 
Is this already discussed in a bug anywhere ?
What are other projects doing ?
 
Thanks,
Martin___
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] Xtext M4 ?

[John Arthorne]

The general form of this question would be good input for Wayne and his 
project page organization. Currently projects declare with a flag that 
they are participating in the simultaneous release, but there is no record 
that I am aware of indicating which release they will contribute. For 
projects whose own schedule matches the cadence of the release train this 
is fairly obvious. But for other projects with more frequent releases I 
don't think this information is available. To pick a random example, this 
morning I was asking what release of Jetty would be in Juno and the answer 
wasn't so clear. Maybe the juno participation flag should be metadata on 
a release rather than just a generic flag on the project? For downstream 
projects and consumers I expect this information would be really helpful.

John





Adolfo Sanchez Barbudo adolfo...@opencanarias.com 
Sent by: cross-project-issues-dev-boun...@eclipse.org
12/14/2011 10:20 AM
Please respond to
Cross project issues cross-project-issues-dev@eclipse.org


To
cross-project-issues-dev@eclipse.org
cc

Subject
[cross-project-issues-dev] Xtext M4 ?






Hello Folks

I'm wondering if Xtext guys are going to create any kind of milestone for 
M4.

Looking at their milestones repository[1] I only see an old 2.1.0M2.

I don't find any clue in the project plan [2] neither .

Any reason about why there is no an updated milestones repository would be 
appreciated. Take into account that our milestones builds are based on 
milestones repositories for those projects we depend on, so keeping the 
usual (probably planned) milestones releases are important for us.

[1] http://download.eclipse.org/modeling/tmf/xtext/updates/milestones
[2] 
http://www.eclipse.org/projects/project-plan.php?projectid=modeling.tmf.xtext

P.S: I've not checked other itemis projects (xpand, mwe), but I guess we 
will have the same problem with them.

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

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