On 09/05/2013 07:22 AM, Ed Willink wrote:
Hi
Nice idea, but isn't the extension point a perfect target for hostile
attacks?
In an extensible framework such as Eclipse, any additional plugin can
contain malicious code. This proposed extension point is no more and no
less dangerous than any exi
Hi
Nice idea, but isn't the extension point a perfect target for hostile
attacks?
I'm pretty sure that I will disable it as vigorously as possible on my
installations.
Regards
Ed Willink
On 05/09/2013 01:14, Igor Fedorenko wrote:
As you may or may not know, p2 can be configur
As you may or may not know, p2 can be configured to report feature or
plugin "download stats" to a remote server [1]. As a side note, this
reporting is done silently, i.e., without telling the user, and both
installations from remote servers and local filesystem are reported.
I would like to prop
The last run of the "run kepler aggregator" job was at 3 or 4 PM (Eastern)
time and I have not seen any changes/activity since (nor notes to this
list) so will assume RC2 is complete.
I will re-enable the job on Friday, after EPP packages are produced.
Remember ... we are not in "warm-up" mod
Compiled 2013-09-04T12:07
build.eclipse.org
-> Usage exceeding 1GB for: Hudson master jobs and workspace (2013-09-04T10:00)
32.8G ep4-unit-lin64
28.0G emf-cdo-integration
3.8G emf-emfclient-integration
2.7G emf-core-maintenance
2.7G stardust-kepler
2.4G emf-emfclient-main
I am not suggesting that all the bundles in the whole Eclipse top-level
project should have the same target. Target decisions are made at the level
of logical components and most of the components are composed of multiple
bundles. Within a component, specifying different targets at bundle-level
mos
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
_
> One might chose to replace its dependency Y with one Y' that has a
> lower BREE. E.g. I might decide to replace the current
> org.eclipse.core.runtime bundle with an older version that still works
> with a lower BREE.
This would assume that the plug-in X does not use any API introduced in
newer
You might still be able to use parts of e.g. 'org.eclipse.ui' with 1.3
(e.g. SWT) but other bundles/functionality will fail to load when actually
used.
The PMC already noticed that the current information in the plan should be
improved but did not yet change it. See bug 377028 for details.
Da
On 09/04/2013 01:54 PM, Lars Vogel wrote:
> It looks to me that some org.eclipse.ui.* plug-ins require an BREE update
> in this case. I think a plug-in cannot require a lower Java version than a
> plug-in which it requires as dependency. SWT is a special case as it has no
> plug-in dependencies.
>
It looks to me that some org.eclipse.ui.* plug-ins require an BREE update
in this case. I think a plug-in cannot require a lower Java version than a
plug-in which it requires as dependency. SWT is a special case as it has no
plug-in dependencies.
For example org.eclipse.ui.view defined a BREE of J
Set branch.autosetuprebase = always in your user settings to prevent this
from happening in new branches:
http://wiki.eclipse.org/Platform-releng/Git_Workflows#Configure_the_workspace
For exisiting local branches, you may have to set
branch..rebase = true
in the repo config.
Markus
From: La
Hi Dennis,
Thanks for the confirmation, I didn't really know why there was an
additional commit on my clone, but I think it was only due to an
unexpected pull --merge from my side, it does not seem like anything
broke/reverted because of it. I'll just curse the default pull strategy :p.
Laur
Hi Laurent,
our changes are still there (emf,xtext). So there is nothing to revert I think.
Regards,
Dennis.
Am 03.09.2013 um 17:00 schrieb Laurent Goubet:
> In fact ... I think the issue is just that I've used the default EGit's
> "pull" instead of a pull rebase, so probably nothing to revert?
> The decisions on what targets to support are rarely made on
bundle-by-bundle basis because a single bundle does not represent a
meaningful usecase. It really does pay to go through all the bundles and
update the requirements when a decision is made to change > these for a
broader component.
15 matches
Mail list logo