Hi all,
SWTBot contributors would like to integrate SWTBot to Luna aggregator,
and to PDE EPP package. Cf discussion
https://dev.eclipse.org/mhonarc/lists/swtbot-dev/msg00618.html
The initial contribution is SWTBot 2.2.1, which was released 4 months
ago:
Hi,
The e4 tools project is still in incubation and we currently have no one
working on changing that.
If I open the Luna update site I see lots of incubation projects included
in this update site.
What is requirement to be included in the Mars update site?
Best regards, Lars
Hi,
as some of you probably remember, the platform.ui team started a GSoC
project last year to generify the JFace viewer framework. We (platform.ui
team together with John Arthone and Dani Megert) decided that it is worth
to finish this project and started a new GSoC project.
Jeanderson Barros
Just for the records, here are some constraints that I required in order
to agree to continue that work:
- Some stuff just doesn't make sense to be generified because it often
contains various kinds of objects, e.g. (tree) viewers. See also
- Some stuff just doesn't make sense to be generified because it often
contains various kinds of objects, e.g. (tree) viewers. See also
*http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html*
http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html.
We need to investigate
I am no JavaFX expert, but it has Views (for example, TreeView) whose
Items are aware of a root generic type: for example,
TreeView#setRoot(TreeItemT)...
If the viewer input has no base class for all of its elements, then the API
user would have to use Object again.
I wonder how the JavaFX
Right all API in JavaFX is generified - and yes you simply have to take
the most basic type you have but like outlined already by Lars' one
often is able to find a base type (e.g. think about a File-Tree-Viewer
where the base class is always a File-Instance).
What worries me more how to deal with
Once you're confident that the work is complete, please put it into a
branch on git.eclipse.org. Then inform clients and ask for final
validation (open a bug for clients to give their go). Clients need at
least 3 weeks of time to do their integration testing. Only put it into
master after you
Dani,
As I've made pretty clear in the past, I'm a huge non-fan of this
effort. I find it ironic that the platform is rife with raw types
(List), and rather than investing an effort to eliminate those, effort
will be invested on generifying things that just aren't screaming to be
Hi
On 30/07/2014 15:46, Ed Merks wrote:
I find it ironic that the platform is rife with raw types (List), and
rather than investing an effort to eliminate those
Indeed, it would seem obvious that the generified code will have strong
JDT warnings enabled so that for instance there will be no
I think the JFace API is sufficiently cool as-is and does not need to be
made cooler by utilizing generics.
2014-07-30 16:46 GMT+02:00 Ed Merks ed.me...@gmail.com:
Dani,
As I've made pretty clear in the past, I'm a huge non-fan of this
effort. I find it ironic that the platform is rife
Compiled 2014-07-30T12:07
build.eclipse.org
- Usage exceeding 1GB for: Hudson master jobs and workspace (2014-07-30T10:00)
5.7G papyrus-trunk-nightly-tests
3.1G gef4-master
2.4G papyrus-trunk-nightly
2.1G osee-dev
2.0G papyrus-trunk-extra-nightly-tests
2.0G
Can I assume that you mean Mars? ;-)
I've started assembling the list of projects/releases that will join
Mars [0]. I'll put you down for 2.2.1 for now; if you do decide to
include a different release with Mars, then let us know on this list
(before the M4 deadline) and I'll update the
On 07/30/2014 06:47 PM, Wayne Beaton wrote:
Can I assume that you mean Mars? ;-)
Sure, you can assume that ;)
I've started assembling the list of projects/releases that will join
Mars [0]. I'll put you down for 2.2.1 for now
Thanks.
if you do decide to include a different release with Mars,
Hi Ed
Thanks for this excellent write-up of https://bugs.eclipse.org/416189 !
Yes, the proposed changes will be scrutinized, and it's very well possible
that the outcome is again WONTFIX.
Side-note about java.util.Collection's T T[] toArray(T[] a): That method
looks type-safe, but it's not.
Hi,
Regarding the ArrayContentProvider, something like this seems to compile just
fine:
interface IStructuredContentProviderT {
default @Deprecated Object[] getElements(Object inputElement) {
return elements(inputElement).toArray();
}
ArrayListT elements(Object inputElement);
}
A quick addendum to the disk usage below:
/shared is at 56% usage.
3.2T 1.7T 1.4T 56% /opt/public
The downloads/archives hit the 70% threshold today.
3.9T 2.6T 1.2T 70% /home/data/httpd/download.eclipse.org
3.9T 2.6T 1.2T 70% /home/data/httpd/archive.eclipse.org
Please don't forget
Hi all,
the RAP project will deliver two 3.x releases until Mars in 2015, a
complete overview of our currently planned releases is available from our
mailing list [1].
Up to and including Mars M4, we are going to contribute RAP 3.0 milestone
builds to Mars: Plan is available at [2].
From 2015 on
Next one...
EPP is planning to provide download packages based on the aggregated Mars
p2 repository; build time is +EPP (i.e. after +3) usually on Thursdays. See
[1] for a plan with the dates that will be adjusted according to the
Simultaneous Release dates. Other plan items will be added during
Hi Mickael,
about RCP package inclusion: The rcp-package component in Bugzilla would be
the best place to open a bug and discuss if/how/... this can be included in
the RCP/RAP package:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPPcomponent=rcp-package
By coincidence I'm the maintainer
I have not seen any actual enforcement of the m4 rule in past simrel.
Largely, that's because it doesn't make much sense for projects that release
more frequently than once a year. Say the project has a release 5.2
scheduled to wrap up during m4 time frame. The next release is of unknown
length at
I think that this is what I said.
Wayne
On 07/30/2014 03:48 PM, Konstantin Komissarchik wrote:
Simrel process should not require projects to declare a particular
release version. Rather, the process should focus on the type of
changes being contributed at a particular date. For instance, you
Timo,
Comments below.
On 30/07/2014 7:19 PM, Timo Kinnunen wrote:
Hi,
Regarding the ArrayContentProvider, something like this seems to
compile just fine:
interface IStructuredContentProviderT {
default @Deprecated Object[] getElements(Object inputElement) {
return
23 matches
Mail list logo
