Re: [cross-project-issues-dev] Uhm, where did all the git repositories go?
And, the are back! Thanks! - thomas On 2015-04-09 16:35, Thomas Hallgren wrote: I'm looking at http://git.eclipse.org (which redirects to http://git.eclipse.org/c) and there's a No repositories found message in red. What's going on? - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Uhm, where did all the git repositories go?
I'm looking at http://git.eclipse.org (which redirects to http://git.eclipse.org/c) and there's a No repositories found message in red. What's going on? - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Your friendly error reports bot?
Hi, A b3 issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=332266 that was fixed 3 years ago hast started to repeated comments from error-reports-in...@eclipse.org with the following text: To date this log entry was reported 50 times. Your friendly error reports bot Does anyone know where this comes from? - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.
On 2014-11-04 09:27, Aleksandar Kurtakov wrote: - Original Message - What we have now is the worst case of all. Virtually no integration testing and when bugs are found, no immediate new release. I totally agree with you that this is worst case. The only thing I would like to clarify is that this is not the problem, it's the result from very few people contributing to the lower/common/shared bits we all rely on. Until this changes the situation will stay the same as no matter what we think/discuss and etc. at the end of the day someone have to step in and do it, which sadly doesn't happen in many cases for stuff discussed. First step must be to agree on what to do. If we can get a consensus to have a more relaxed and higher paced release procedure, then that's a major step forward in my opinion. Alternatively, perhaps we can agree that it's OK to keep the current service releases but accept that some fixes must bypass that and cause an immediate rebuild. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.
Hi David, I think it's fairly evident that the testing that was made prior to SR1 was insufficient and I can understand why. Projects have limited resources nowadays and unfortunately rigorous testing is one of the first things that gets a cutback. With lowered quality as a natural consequence. The way I see it, that problem can be attacked in one of two ways: 1. See to that the service releases really get tested rigorously which means that organizations must put up the resources needed to do so. The release train must be subject to integration testing. 2. Let the Eclipse users take the hit (like we already do now) and make sure that any problems that are discovered are remedied more or less immediately (i.e. push a new build of the release train or platform without delay). In essence, this would remove the need for service releases. What we have now is the worst case of all. Virtually no integration testing and when bugs are found, no immediate new release. I wasn't referring to feature patches with my remark about p2 (I'm not much fond of them either). I was referring to p2's ability to deliver updates in a safe and controlled manner. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in 4.4 repository.
+1 I would really like to see p2 leveraged (the way it was designed to) to make it really easy to push fixes like this out to the community in a controlled but swift manner. - thomas On 2014-11-02 11:07, Max Rydahl Andersen wrote: On 31 Oct 2014, at 19:56, David M Williams wrote: I am not sure if this bug was discussed directly on this list, or, just some of its predecessors, but, we have an official fix available for anyone impacted by Really appreciate the work for fixing this nasty subtle bug. But can we have a chat about why the Eclipse release train does not seem to have a *good* way to release updates for this ? By Good I mean one that just gets available via Check For Updates rather that one that does not require users to aware of having to install a specific feature patch ? I think Eclipse survived this far because we haven't really had any big all impacting stop ship bugs, but lately they are starting to crop up - this issue with System properties being the worst one (that I know of). Can someone remind me why we can't in these cases do an update that fixes this bug ? Is it technical because the release train is to hardly coupled and we have feature's using exact versions and that p2 won't let you update the plugins on their own ? ...or is there also some political agenda on how we provide these updates ? In any case - I think it would be worth finding a way to update these technical and political limitations to make it easier to do timely stop-ship bug updates? wdyt ? /max http://about.me/maxandersen ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Luna is inconsistent. Features are referencing non-existent fragments!
What I didn't understand when this happened the last time and still don't, is why the references were added but not the targets that they reference. That's like saying - let's deliberately break all builds that try to resolve the references that are there. Why not just add all of it or not add it at all? - thomas On 2014-09-28 10:30, David M Williams wrote: Sort of a re-incarnation of those bugs ... but, this time it was a conscious decision, and we tried to spread the word via this list: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11040.html https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11042.html But of course, that doesn't help anyone not part of the Sim. Release and would therefore would not be reading this list on a regular basis. [To summarize, the Platform team wanted to add this early access platform to their own Luna repository, but not the Sim. Release repository for Luna Service release. In Mars, it is part of the Sim. Release repo. We knew this could complicate other's builds ... having to filter it out in Luna, but not in Mars ... but, it was felt the least worst alternative given the timing.] Apologies for the inconvenience. Please help spread the word. From: Thomas Hallgren tho...@tada.se To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 09/28/2014 02:41 AM Subject: Re: [cross-project-issues-dev] Luna is inconsistent. Features arereferencing non-existent fragments! Sent by: cross-project-issues-dev-boun...@eclipse.org This bug is probably a reincarnation of https://bugs.eclipse.org/bugs/show_bug.cgi?id=337026and https://bugs.eclipse.org/bugs/show_bug.cgi?id=213437 - thomas On 2014-09-28 08:31, Thomas Hallgren wrote: Our builds for the b3.aggregator has started failing. Seems the org.eclipse.e4.rcp feature now references fragments for ppc64le but those fragments cannot be found in Luna. Feature org.eclipse.platform:eclipse.feature$4.4.0.v20140925-0400 references: org.eclipse.core.filesystem.linux.ppc64le:osgi.bundle/[1.4.0.v20140808-1353,1.4.0.v20140808-1353] Feature org.eclipse.e4.rcp:eclipse.feature$1.3.100.v20140909-1633 references: org.eclipse.swt.gtk.linux.ppc64le:osgi.bundle/[3.103.1.v20140903-1936,3.103.1.v20140903-1936] org.eclipse.equinox.launcher.gtk.linux.ppc64le:osgi.bundle/[1.0.200.v20140409-1208,1.0.200.v20140409-1208] This problem is very likely to affect other Buckminster builds. Are these bundles available from somewhere else? If not, then please remove the references to them ASAP. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Luna is inconsistent. Features are referencing non-existent fragments!
On 2014-09-28 22:57, David M Williams wrote: Granted, given enough time and resource, the Eclipse project releng team could have made one deliverable for their own repository, and another deliverable for the Sim. Release repository I'm still missing something. I don't see any problems in the releng team adding early-access features to their own repository that references plug-ins present in their own repository. That's a contained and well planned deliverable. What I don't understand is why this meant adding features to the Sim repository that references targets not present in the Sim repository. That's a deliverable and a half. I had hoped that we reached some kind of consensus when this debacle happened the last time, saying that the Sim should be self contained without dangling references. Apparently that was a mistake on my part. Anyway, all things considered, it's a minor problem that I'm able to work around so I won't continue arguing about it. Thanks David for your attempts to explain the reasons (even if I'm not completely clear on them yet :) ) - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
On 2014-06-25 12:57, Stephan Herrmann wrote: Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. The reference to 3.9.2 was introduced when I tried to fix the problem and appointed the wrong platform site. My error. Please disregard that. The real problem occurs when I'm using releases/staging (i.e. RC4) from my Buckminster build. I'm currently circumventing it by redirecting all requests for org.eclipse.jdt.* directly to the 4.4milestones platform repository. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
My guess is that the reason it gets selected by p2 is that the version 3.10.0.v_OTDT_r230_201406101339 is lexically greater than 3.10.0.v20140604-1726 since '_' (0x5f) is greater than '2' (0x32) - thomas On 2014-06-25 12:57, Stephan Herrmann wrote: On 06/25/2014 12:09 AM, Thomas Hallgren wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? One thing, exactly, has changed in Object Teams in this regard: I followed Pascal's advice for avoiding unintended updates from the original to the OTDT variant. On 06/25/2014 09:13 AM, Sievers, Jan wrote: looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 That's the exact reference to our best effort to improve this. I double checked and from all I can see the meta data looks exactly as advised: - the OTDT variant of org.eclipse.jdt.core has a non-greedy dependency on our patch feature (since Juno) - cannot be installed without explicitly selecting that patch feature. - the patch feature is marked as a patch for the *bundle* org.eclipse.jdt.core, not for the jdt feature (new in Luna). - patch feature is not regarded as an update of the jdt feature. Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
Correction. Should say selected by Buckminster, not selected by p2 since this isn't a build-time best-effort resolution and not a full p2 resolution. I guess the same can be said about the Tycho resolution. - thomas On 2014-06-25 14:17, Thomas Hallgren wrote: My guess is that the reason it gets selected by p2 is that the version 3.10.0.v_OTDT_r230_201406101339 is lexically greater than 3.10.0.v20140604-1726 since '_' (0x5f) is greater than '2' (0x32) - thomas On 2014-06-25 12:57, Stephan Herrmann wrote: On 06/25/2014 12:09 AM, Thomas Hallgren wrote: I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? One thing, exactly, has changed in Object Teams in this regard: I followed Pascal's advice for avoiding unintended updates from the original to the OTDT variant. On 06/25/2014 09:13 AM, Sievers, Jan wrote: looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=350133 That's the exact reference to our best effort to improve this. I double checked and from all I can see the meta data looks exactly as advised: - the OTDT variant of org.eclipse.jdt.core has a non-greedy dependency on our patch feature (since Juno) - cannot be installed without explicitly selecting that patch feature. - the patch feature is marked as a patch for the *bundle* org.eclipse.jdt.core, not for the jdt feature (new in Luna). - patch feature is not regarded as an update of the jdt feature. Can you share a setup for reproduction? The reference to 3.9.2... looks fishy, indeed. regards, Stephan ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ 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] External Buckminster update site restored
The Buckminster update site that contains headless non EPL'ed additions (subversion clients and emma code coverage) is now fully operational again and can be accessed using the following URL's: http://download.cloudsmith.com/buckminster/external-4.4 (Luna) http://download.cloudsmith.com/buckminster/external-4.3 (Kepler) http://download.cloudsmith.com/buckminster/external-4.2 (Juno) Regards, Thomas Hallgren ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] org.eclipse.jdt.core from objectteams gets selected due to higher version
I just encountered a build failure when using the platform repository in conjunction with the luna staging one. The failure was caused by p2 preferring the objectteams patch for org.eclipse.jdt.core in favor of the original. Seems the patch has a higher version (3.10.0.v_OTDT_r230_201406101339) than the one found in the platform repo (3.9.2.v20140114-1555). I don't recall having seen this problem before so something must be different. Anyone have a clue as to what might be causing this? - thomas ___ 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] Alert regarding Apache commons-compress 1.6
Hi, I just encountered a really nasty bug in the Apache commons-compress TarAchiveInputStream that makes it silently ignore large parts of an archive during unpack. The bug was fixed in version 1.7. Here's the JIRA ticket: https://issues.apache.org/jira/browse/COMPRESS-249 I'm posting this here because in Eclipse Orbit, the 1.6 version seems to be the most recent one. That is the version that is affected by this critical bug and really needs to get updated to at least 1.7 or even better, to the latest release (1.8 it seems). - thomas ___ 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] M6 in danger
Hi Eike, I don't know what's up with your build. I tried to build a full site using our headless-4.3 repository and had no problems doing so. I even rebuilt both our update site and headless site and verified again. I'm unable to find any problems with the Buckminster sites. When did your problems start? Could it be that your buckminster installation is somehow corrupted so that it doesn't update itself properly? The p2 version that Buckminster uses (the one that is present at our headless site) is from Kepler SR2. Judging from your attached stacktrace, that's not the case with the one used in your build. These are the relevant bundles that what ought to be there: org.eclipse.equinox.p2.publisher_1.3.0.v20140129-1405.jar org.eclipse.equinox.p2.publisher.eclipse_1.1.200.v20130516-1953.jar Could it be that you have tried with Luna stuff and then have stuff lingering? - thomas On 2014-03-11 20:00, Eike Stepper wrote: Hi all, Our Buckminster-based build keeps failing with varying errors that all seem to be caused by mismatches between/within Buckminster and p2. And maybe because the http://download.eclipse.org/tools/buckminster/headless-4.3 repo contains old versions of p2. But this is all guessing. In the end I have no clue what's going on. Here's a new error that seems to indicate a problem between different parts of p2 (publisher and core): [java] org.eclipse.equinox.internal.p2.core.helpers.CollectionUtils.emptyMap()Ljava/util/Map; [java] Caused by: java.lang.NoSuchMethodError: org.eclipse.equinox.internal.p2.core.helpers.CollectionUtils.emptyMap()Ljava/util/Map; [java] at org.eclipse.equinox.p2.publisher.AdviceFileAdvice.loadAdviceMap(AdviceFileAdvice.java:118) [java] at org.eclipse.equinox.p2.publisher.AdviceFileAdvice.init(AdviceFileAdvice.java:71) [java] at org.eclipse.equinox.p2.publisher.eclipse.FeaturesAction.createAdviceFileAdvice(FeaturesAction.java:166) [java] at org.eclipse.equinox.p2.publisher.eclipse.FeaturesAction.generateFeatureIUs(FeaturesAction.java:407) [java] at org.eclipse.buckminster.pde.tasks.FeaturesAction.generateFeatureIUs(FeaturesAction.java:274) I can't spend more time on this tonight. I'm aware that EMF Compare seems to push me to contribute an M6 that uses their new APIs. But at this point I can not guarantee that my M5 will be replaced tomorrow. All ideas are welcome! 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
Re: [cross-project-issues-dev] Unexpected issues with our M6 build. Buckminster change ?
Hi Adolfo, We're trying to figure out why the shared Buckminster installation is causing various problems. I discovered that the Buckminster installation was no longer read-only which doesn't seem like a good idea, so as a first step, I made it read-only and that's probably what's causing your current problem. I'm not sure why that is though, as our own builds continue to run fine from Hudson. We're in progress of finding this out, so please be patient. I'll get back to this list with more info. - thomas On 2013-03-18 17:02, Adolfo Sanchez-Barbudo Herrera wrote: Hi All, Today, I'm having some issues to complete our M6 build. I've tried several configurations (build types, nodes in which run the job) and all fail with the same cause: INFO: The SSL proxy is enabled in the preferences but disabled in the system settings java.lang.IllegalStateException: Shared profile Buckminster not found. Terminating xvnc. Archiving artifacts Recording test results Further investigation tells me the following drwxr-sr-x 4 thallgren common 4096 2013-03-18 10:34 buckminster-4.2 Which looks like a 30 minutes ago change. Could I get some information about these changes in the buckminster4-2 eclipse installation ? I'm not sure if I asked this question some time ago... apologises if it has been answered before... Is there any way to get informed about when these changes in the building tools take place ? Cheers, Adolfo. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Unexpected issues with our M6 build. Buckminster change ?
Builds are running OK again now. The shared Buckminster installation is still read-only (and should remain so). Please let me know if you have any more issues. - thomas On 2013-03-18 17:26, Adolfo Sanchez-Barbudo Herrera wrote: Hi Thommas, Thank you very much for the info. I'll keep an eye on this list for your signal ;) note: any related bugzilla is also welcome. Cheers, Adolfo. On 18/03/2013 16:16, Thomas Hallgren wrote: Hi Adolfo, We're trying to figure out why the shared Buckminster installation is causing various problems. I discovered that the Buckminster installation was no longer read-only which doesn't seem like a good idea, so as a first step, I made it read-only and that's probably what's causing your current problem. I'm not sure why that is though, as our own builds continue to run fine from Hudson. We're in progress of finding this out, so please be patient. I'll get back to this list with more info. - thomas On 2013-03-18 17:02, Adolfo Sanchez-Barbudo Herrera wrote: Hi All, Today, I'm having some issues to complete our M6 build. I've tried several configurations (build types, nodes in which run the job) and all fail with the same cause: INFO: The SSL proxy is enabled in the preferences but disabled in the system settings java.lang.IllegalStateException: Shared profile Buckminster not found. Terminating xvnc. Archiving artifacts Recording test results Further investigation tells me the following drwxr-sr-x 4 thallgren common 4096 2013-03-18 10:34 buckminster-4.2 Which looks like a 30 minutes ago change. Could I get some information about these changes in the buckminster4-2 eclipse installation ? I'm not sure if I asked this question some time ago... apologises if it has been answered before... Is there any way to get informed about when these changes in the building tools take place ? Cheers, Adolfo. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ 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] Future of Buckminster
The team behind Buckminster has every intention of keeping the tool stable and supported. - thomas On 2013-02-27 15:44, Pascal Rapicault wrote: I don't think this is the right reasoning to have. If Buckminster satisfies all your needs (stable, supported, etc), then you should keep it, especially considering that the switch of technology can be quite time consuming (we believe it took more a one-man year to do the whole conversion of the platform), and that there are features in Buckminster that are more powerful than those found in Maven/Tycho. The platform had to move to Tycho/CBI to enable the LTS and Polarsys initiatives. I think that if it had not been for those reasons, the move to Tycho may have never occurred (or at a much slower pace). After all PDE Build still works well and has been stable for quite some time now. *From:*cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Ed Willink *Sent:* February-27-13 5:05 AM *To:* Cross project issues *Subject:* [cross-project-issues-dev] Future of Buckminster (was: An important change, and transition period, for Eclipse Platform Builds) Hi Is this a strong indication that Buckminster is doomed as in in-house technology, and that all projects that migrated to Buckminster should start to plan for a migration to Tycho? Regards Ed Willink On 25/02/2013 06:54, David M Williams wrote: I think most are aware that we in the Platform (with help from many others) have been working to move our builds to use Tycho and Maven (instead of PDE Batch Builds) to build our deliverables. This is part of the CBI efforts and more specifically motivated by the Eclipse Foundation's LTS program. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Performance, 3.8 versus 4.2
On 2012-09-06 07:57, Ian Bull wrote: Maybe this is the wake-up call we all needed, or maybe it's simply another yeah, things need to improve and someone else better do it. :-| Nobody needs to improve anything with 3.8 to make it completely superior to 4.2. Introducing a new platform undoubtedly consumes a lot of resources. Doing that anyway (and as the only viable alternative), well aware that those resources were scarce and that the new platform had inferior performance, and then blame the community for not helping, that doesn't fly well with me. - thomas ___ 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
On 2012-09-06 13:25, Aleksandar Kurtakov wrote: The only truth is Someone must do the job, if there isn't anyone it will never be done. Doing do the job in this case means deliver a high quality IDE. With respect to 3.8, someone has already done that job. That job may have started with 4.2 but it's far from complete, a that fact wasn't acknowledged when the decision was made to deprecate 3.x. That's another truth. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] More on greedy install attribute ...
On 05/29/2012 09:35 AM, Laurent Goubet wrote:
Hi,
Some bundles from Acceleo (org.eclipse.acceleo.*) appear in this
list. For example :
org.eclipse.core.filesystem
Number of IUs using optional, but greedy for this case: 2
org.eclipse.acceleo.common
Acceleo is developped as an Eclipse plugin, yet it is also meant
to be useable in a standalone environment. When installed in
Eclipse, we depend on org.eclipse.core.* bundles to provide
additional functionality and integration. However, none of these
dependencies are mandatory when using it as a standalone
generation tool. So yes, we are indeed greedy (but in fact, it
should be quite difficult to _not_ have o.e.c.filesystem
installed before us right? org.eclipse.core.runtime and
org.eclipse.core.resources should probably be ignored too by
this report), _and_ optional since the dependency is not really
needed in other environments.
I believe that these cases should be exceptions to the "greedy"
report. How could we document/track these? Or is my
understanding wrong here?
No, you're not wrong. This is exactly the kind of scenario that the
greedy attribute was supposed to cover.
Kind Regards,
Thomas Hallgren
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time!
On 05/24/2012 12:58 PM, Dennis Hübner wrote: So it's a Use the new publisher thing… Is it obligatory for all eclipse projects? Or is it just a good practice. Adopters can still decide if an optional dependency should be installed or not, by filtering it from the build target platform and Eclipse user can filter/deactivate the corresponding repository and so use a subset of project p2 repositories. However, I don't want to convince you, that optional greedy make sense or not (by the way it was a default for years), I'd like that people accept, that this is a valid combination and don't nag on projects, who use it. :p One could very well argue that an optional non-greedy dependency is completely useless and doesn't fulfill any other purpose but documentation. The dependency will not be installed, it is not required, and if it's already there and conflicting, the conflict will be suppressed by the optional status. So why is the dependency there in the first place? - thomas ___ 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!
On 05/24/2012 03:13 PM, Gunnar Wagenknecht wrote: Am 24.05.2012 14:57, schrieb Thomas Hallgren: One could very well argue that an optional non-greedy dependency is completely useless and doesn't fulfill any other purpose but documentation. We have a bunch of bundles in place that have optional non-greedy dependencies to allow flexibility at runtime. For example, Logback can be configured via API, XML or Groovy. Groovy as well as XML configuration require additional dependencies. Imaging all those dependencies were greedy. Then they would be installed of course. Now they are not installed and the dependencies have no purpose aside from what I mentioned earlier, documentation. BTW, they need to be optional for the bundles to properly resolve if the dependencies aren't there. They need to be declared to allow the bundle class loader to load them if they are available. To my knowledge, the bundle class loader is using the MANIFEST.MF, not the p2 meta-data. So my argument still stands. - thomas ___ 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!
On 05/24/2012 03:57 PM, Oberhuber, Martin wrote: - Yes Optional non-greedy has no effect on the installer; But, the p2 metadata also serves as documenting the OSGi/runtime dependencies from all MANIFEST.MF in a repo so having it in there is extra information that may help some and doesn't hurt. Which just about summarizes what I first wrote. One might argue that this documentation is less useful than the optional greedy dependencies that Dennis is using. After all, they do have an (in this case desired) effect on the installer. - thomas Martin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Thomas Hallgren Sent: Thursday, May 24, 2012 3:37 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Yet another nag note ... and, I mean it this time! On 05/24/2012 03:13 PM, Gunnar Wagenknecht wrote: Am 24.05.2012 14:57, schrieb Thomas Hallgren: One could very well argue that an optional non-greedy dependency is completely useless and doesn't fulfill any other purpose but documentation. We have a bunch of bundles in place that have optional non-greedy dependencies to allow flexibility at runtime. For example, Logback can be configured via API, XML or Groovy. Groovy as well as XML configuration require additional dependencies. Imaging all those dependencies were greedy. Then they would be installed of course. Now they are not installed and the dependencies have no purpose aside from what I mentioned earlier, documentation. BTW, they need to be optional for the bundles to properly resolve if the dependencies aren't there. They need to be declared to allow the bundle class loader to load them if they are available. To my knowledge, the bundle class loader is using the MANIFEST.MF, not the p2 meta-data. So my argument still stands. - thomas ___ 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] Hudson is broken
I just entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=373636 - thomas ___ 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 M6 is not far away ... are you still greedy?
Hi Adolfo, I entered a bugzilla for that this morning that you can track: https://bugs.eclipse.org/bugs/show_bug.cgi?id=373320 Regards, Thomas Hallgren On 03/06/2012 02:09 PM, Adolfo Snchez-Barbudo Herrera wrote: Thommas, Thanks for the new release. For those builds (like Eclipse OCL ones) who use the buckminster commands from hudson UI would require the option to use the new 4.2 buckminster intallation. Please, could give us an approximate date in which such an option will be available ? Is there any bugzilla to which I could CC ? Cheers, Adolfo. El 06/03/2012 12:09, Thomas Hallgren escribi: On 03/06/2012 11:39 AM, Eike Stepper wrote: I can't reproduce your problem installing into the IDE though. Are you using a 3.8 or 4.2 IDE? 3.8 My guess is that it's a 3.8M4 or older? P2 went from 2.1 to 2.2 between M4 and M5. That's the likely cause of your problem. - thomas ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Adolfo Snchez-Barbudo Herrera adolfosbh(at)opencanarias(dot)com C/Elas Ramos Gonzlez, 4, ofc. 304 38001 SANTA CRUZ DE TENERIFE Tel.: +34 922 240231 ___ 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] help with Buckminster problem needed
Hi Henrik, It seems the bundle is found in a p2 repository. Then, for some reason, you're using 'eclipse.import' reader type which makes an attempt to import the binary bundle into the workspace. A couple of suggestions: 1. Use 'p2' instead of 'eclipse.import' 2. Make sure binary bundles go to your target platform instead of into your workspace. The latter is probably a case of using source="false" in the provider for binaries. - thomas On 2011-12-15 15:18, Henrik Rentz-Reichert wrote: thanks Thomas and Dennis, here is the console output of a failed import with --loglevel DEBUG: https://hudson.eclipse.org/hudson/job/mdt-etrice-nightly/143/console I've also allowed workspace access for anonymous. -Henrik Am 15.12.2011 13:17, schrieb Dennis Hbner: Allow others to browse your job workspace formdt-etrice-nightly. So we can also look into your rmap and cquery. Regards, Dennis. Am 15.12.2011 um 12:41 schrieb Thomas Hallgren: Please try running with --loglevel DEBUG and then provide a link to the complete build output. ___ 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
