[cross-project-issues-dev] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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: https://projects.eclipse.org/projects/technology.swtbot/releases/2.2.1 SWTBot features would be added to the Testing category. Since SWTBot depends on GEF, its offset would be +2. However, this shouldn't have a big impact since SWTBot will not contribute milestones to aggregator, but only approved releases. SWTBot is stable and there is very low risk of breaking change in its main APIs. If SWTBot has to create a new release by May/June 2015, we'll try to synchronize promotion and announcement with the Luna simultaneous release. What else needs to be done? Should I put a Git patch on a bug for cross-project? Still no way to contribute to simultaneous release with Gerrit? :P -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] e4 tools (Incubation) participation in Mars?
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 ___ 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] Information about the Generifing JFace viewers project
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 Candido (cc) is working on this project with Hendrik Still (cc) (GSoC student from last year) and me as mentor. I personally think the work looks already very good and plan to integrated it soon into the master. We are trying to learn from the experience from last year, therefore: - We plan to integrate it as a whole, not piece wise so people can fix warning messages created by this change - We reworking the JFace snippets and tests at the same time to have a first proof-point - We plan to use it for platform views to validate that it works Of course generifying an existing API, will result in certain limitations and some suggested a complete rewrite of the JFace viewer framework but this is currently not the scope of this project. The implementation is currently done at Github: https://github.com/jeandersonbc/eclipse.platform.ui and we do our planning in https://github.com/jeandersonbc/gsoc14-eclipse-planning. If someone wants to test the new implementation and provide feedback, please let us know. Best regards, Lars ___ 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] Information about the Generifing JFace viewers project
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 http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html. - If generified types cannot be plugged together unless everything is again just Object or Class, it's not worth to generify those types. - The generified code must be in a shape so that clients can start to fix their code by invoking Refactor Infer Generic Type Arguments... This needs to be validate on existing Platform UI code. Dani From: Lars Vogel lars.vo...@gmail.com To: cross-project-issues-dev@eclipse.org, Jeanderson Candido jeanderso...@gmail.com, Hendrik Still gamm...@gmail.com Date: 30.07.2014 11:23 Subject:[cross-project-issues-dev] Information about the Generifing JFace viewers project Sent by:cross-project-issues-dev-boun...@eclipse.org 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 Candido (cc) is working on this project with Hendrik Still (cc) (GSoC student from last year) and me as mentor. I personally think the work looks already very good and plan to integrated it soon into the master. We are trying to learn from the experience from last year, therefore: - We plan to integrate it as a whole, not piece wise so people can fix warning messages created by this change - We reworking the JFace snippets and tests at the same time to have a first proof-point - We plan to use it for platform views to validate that it works Of course generifying an existing API, will result in certain limitations and some suggested a complete rewrite of the JFace viewer framework but this is currently not the scope of this project. The implementation is currently done at Github: https://github.com/jeandersonbc/eclipse.platform.ui and we do our planning in https://github.com/jeandersonbc/gsoc14-eclipse-planning. If someone wants to test the new implementation and provide feedback, please let us know. Best regards, Lars___ 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] Information about the Generifing JFace viewers project
- 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 that, for example in the e4 tools project our tree is based on MApplicationElement hence for us it would make sense to have a generified TreeViewer. 2014-07-30 11:42 GMT+02:00 Daniel Megert daniel_meg...@ch.ibm.com: 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 *http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html* http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html. - If generified types cannot be plugged together unless everything is again just Object or Class, it's not worth to generify those types. - The generified code must be in a shape so that clients can start to fix their code by invoking Refactor Infer Generic Type Arguments... This needs to be validate on existing Platform UI code. Dani From:Lars Vogel lars.vo...@gmail.com To:cross-project-issues-dev@eclipse.org, Jeanderson Candido jeanderso...@gmail.com, Hendrik Still gamm...@gmail.com Date:30.07.2014 11:23 Subject:[cross-project-issues-dev] Information about the Generifing JFaceviewers project Sent by:cross-project-issues-dev-boun...@eclipse.org -- 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 Candido (cc) is working on this project with Hendrik Still (cc) (GSoC student from last year) and me as mentor. I personally think the work looks already very good and plan to integrated it soon into the master. We are trying to learn from the experience from last year, therefore: - We plan to integrate it as a whole, not piece wise so people can fix warning messages created by this change - We reworking the JFace snippets and tests at the same time to have a first proof-point - We plan to use it for platform views to validate that it works Of course generifying an existing API, will result in certain limitations and some suggested a complete rewrite of the JFace viewer framework but this is currently not the scope of this project. The implementation is currently done at Github: *https://github.com/jeandersonbc/eclipse.platform.ui* https://github.com/jeandersonbc/eclipse.platform.ui and we do our planning in *https://github.com/jeandersonbc/gsoc14-eclipse-planning* https://github.com/jeandersonbc/gsoc14-eclipse-planning. If someone wants to test the new implementation and provide feedback, please let us know. Best regards, Lars___ 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] Information about the Generifing JFace viewers project
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 devs/community solved this issue... 2014-07-30 12:44 GMT+02:00 Lars Vogel lars.vo...@gmail.com: - 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 that, for example in the e4 tools project our tree is based on MApplicationElement hence for us it would make sense to have a generified TreeViewer. 2014-07-30 11:42 GMT+02:00 Daniel Megert daniel_meg...@ch.ibm.com: 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 *http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html* http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html. - If generified types cannot be plugged together unless everything is again just Object or Class, it's not worth to generify those types. - The generified code must be in a shape so that clients can start to fix their code by invoking Refactor Infer Generic Type Arguments... This needs to be validate on existing Platform UI code. Dani From:Lars Vogel lars.vo...@gmail.com To:cross-project-issues-dev@eclipse.org, Jeanderson Candido jeanderso...@gmail.com, Hendrik Still gamm...@gmail.com Date:30.07.2014 11:23 Subject:[cross-project-issues-dev] Information about the Generifing JFaceviewers project Sent by:cross-project-issues-dev-boun...@eclipse.org -- 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 Candido (cc) is working on this project with Hendrik Still (cc) (GSoC student from last year) and me as mentor. I personally think the work looks already very good and plan to integrated it soon into the master. We are trying to learn from the experience from last year, therefore: - We plan to integrate it as a whole, not piece wise so people can fix warning messages created by this change - We reworking the JFace snippets and tests at the same time to have a first proof-point - We plan to use it for platform views to validate that it works Of course generifying an existing API, will result in certain limitations and some suggested a complete rewrite of the JFace viewer framework but this is currently not the scope of this project. The implementation is currently done at Github: *https://github.com/jeandersonbc/eclipse.platform.ui* https://github.com/jeandersonbc/eclipse.platform.ui and we do our planning in *https://github.com/jeandersonbc/gsoc14-eclipse-planning* https://github.com/jeandersonbc/gsoc14-eclipse-planning. If someone wants to test the new implementation and provide feedback, please let us know. Best regards, Lars___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project
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 Object[] in the viewers which you
made generic but I'm uncertain this is legal from an API point of view
because some dumb man could have written code like this:
public class TestMe {
public interface BE {
public E[] test();
}
public static class C implements BString {
@Override
public String[] test() {
return new String[1];
}
}
public static void main(String[] args) {
B t = new C();
Object[] v = t.test();
v[0] = new Object();
}
}
which would break at the very moment someone adds generics
public class TestMe {
public interface BE {
public E[] test();
}
public static class C implements BString {
@Override
public String[] test() {
return new String[1];
}
}
public static void main(String[] args) {
B t = new C();
Object[] v = t.test();
v[0] = new Object(); // BAM BAM BAM ArrayStoreException!
}
}
It is highly unlikely that someone did something like that with
JFace-Viewers but the really bad thing is that no compiler can ever
catch this problem.
Tom
On 30.07.14 13:03, Erdal Karaca wrote:
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 devs/community solved this issue...
2014-07-30 12:44 GMT+02:00 Lars Vogel lars.vo...@gmail.com
mailto:lars.vo...@gmail.com:
- 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_.
We need to investigate that, for example in the e4 tools project
our tree is based on MApplicationElement hence for us it would make
sense to have a generified TreeViewer.
2014-07-30 11:42 GMT+02:00 Daniel Megert daniel_meg...@ch.ibm.com
mailto:daniel_meg...@ch.ibm.com:
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
_http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html_.
- If generified types cannot be plugged together unless
everything is again just Object or Class, it's not worth to
generify those types.
- The generified code must be in a shape so that clients can
start to fix their code by invoking Refactor Infer Generic
Type Arguments... This needs to be validate on existing Platform
UI code.
Dani
From:Lars Vogel lars.vo...@gmail.com
mailto:lars.vo...@gmail.com
To:cross-project-issues-dev@eclipse.org
mailto:cross-project-issues-dev@eclipse.org, Jeanderson
Candido jeanderso...@gmail.com
mailto:jeanderso...@gmail.com, Hendrik Still
gamm...@gmail.com mailto:gamm...@gmail.com
Date:30.07.2014 11:23
Subject:[cross-project-issues-dev] Information about the
Generifing JFaceviewers project
Sent by:cross-project-issues-dev-boun...@eclipse.org
mailto:cross-project-issues-dev-boun...@eclipse.org
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 Candido (cc) is working on this project with
Hendrik Still (cc) (GSoC student from last year) and me as mentor.
I personally think the work looks already very good and plan to
integrated it soon into the master. We are trying to learn from
the experience from last year, therefore:
- We plan to integrate it as a whole, not piece wise so people
can fix warning messages created by this change
Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project
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 got a good coverage of gos. Thanks, Markus From: Daniel Megert/Zurich/IBM@IBMCH To: Cross project issues cross-project-issues-dev@eclipse.org Cc: Jeanderson Candido jeanderso...@gmail.com, Hendrik Still gamm...@gmail.com Date: 2014-07-30 11:43 Subject:Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project Sent by:cross-project-issues-dev-boun...@eclipse.org 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 http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html. - If generified types cannot be plugged together unless everything is again just Object or Class, it's not worth to generify those types. - The generified code must be in a shape so that clients can start to fix their code by invoking Refactor Infer Generic Type Arguments... This needs to be validate on existing Platform UI code. Dani From:Lars Vogel lars.vo...@gmail.com To:cross-project-issues-dev@eclipse.org, Jeanderson Candido jeanderso...@gmail.com, Hendrik Still gamm...@gmail.com Date:30.07.2014 11:23 Subject:[cross-project-issues-dev] Information about the Generifing JFaceviewers project Sent by:cross-project-issues-dev-boun...@eclipse.org 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 Candido (cc) is working on this project with Hendrik Still (cc) (GSoC student from last year) and me as mentor. I personally think the work looks already very good and plan to integrated it soon into the master. We are trying to learn from the experience from last year, therefore: - We plan to integrate it as a whole, not piece wise so people can fix warning messages created by this change - We reworking the JFace snippets and tests at the same time to have a first proof-point - We plan to use it for platform views to validate that it works Of course generifying an existing API, will result in certain limitations and some suggested a complete rewrite of the JFace viewer framework but this is currently not the scope of this project. The implementation is currently done at Github: https://github.com/jeandersonbc/eclipse.platform.ui and we do our planning in https://github.com/jeandersonbc/gsoc14-eclipse-planning. If someone wants to test the new implementation and provide feedback, please let us know. Best regards, Lars___ 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] Information about the Generifing JFace viewers project
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
generified, and to do so in a context that is heavily dominated by
Object[], which interacts exceedingly poorly with generics. Thought
I've made that argument already, I think it bears repeating...
Anywhere you see something like T[] where T is a type parameter, you
already have to get suspicious. Of course we see this in
java.util.Collection:
T T[] toArray(T[] a);
But note that T is derived from the argument, and argument my not be
null, so even in an erased runtime environment we can determine a
reasonable T from a, so suspicion alleviated and that's why we can
have generic collection implementations...
Note that however nice it would have been that toArray() method looked
like this:
E[] toArray()
rather than
Object[] toArray
because you can't implement this generically, unless you provide some
object with the necessary *runtime *information about E to the
constructor of an implementation class...
So consider this:
public interface IStructuredContentProvider extends IContentProvider {
public Object[] getElements(Object inputElement);
}
there's no relationship between the input element's type and the type of
the array, so if someone proposes
public interface IStructuredContentProviderX, Y extends
IContentProviderX {
public Y[] getElements(X inputElement);
}
I'm going to be very suspicious. What this tells me is there must be
some sensible way of being sure that I'll be getting back a real Y[]
instance and not an Object[] instance. What could that sensible way be?
Of course directly implementing that interface in a sensible way is a
good solution, but what about generic solutions?
Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that
EMF generally has *only *content provider implementations analogous to
this). This existing implementation just don't work. You can just
forget about org.eclipse.jface.viewers.ArrayContentProvider.instance,
you can just deprecate
org.eclipse.jface.viewers.ArrayContentProvider.getInstance(), and you'd
better add a public constructor and deprecate it while your at it,
because this implementation
public Object[] getElements(Object inputElement) {
if (inputElement instanceof Object[]) {
return (Object[]) inputElement;
}
if (inputElement instanceof Collection) {
return ((Collection) inputElement).toArray();
}
return new Object[0];
}
simply doesn't work for collections. You'll need new constructors and
new getInstance methods each of which specify the array type, either as
java.lang.Class or as an array prototype, as in the first form to
toArray above. You'd have to provide that even for the constructor that
takes a collection, just the collection instance will not suffice.
Great, so much for adding generics to JFace being erasure compatible,
counter to what was the case when Java's collection library was
generified. Nothing in the collections library was deprecated and no
new methods were added. In other words, for JFace's changes, you can't
just turn off warnings about raw types, you must deal with the
deprecations and API changes. So if you're trying to maintain something
that works with old versions of Eclipse (i.e., EMF is compatible with
Eclipse 3.5), you're completely hosed. You can't add generics, because
you can't compile against an older target platform that does have it, so
you simply have to live with a sea of raw type warnings (or turn them
all off and lose the value of even having such warnings). Also, you
can't start using the new methods instead of the deprecated ones, so you
have to live with that sea of warning as well, or just turn them off
too. Nor you can you exploit any of it to provide value to clients
(given the premise there is value), because you can't reasonably address
this ArrayContentProvider problem without inflicting the same pain on
the clients (who actually have better things to do, go figure).
Even the premise that this effort has value is questionable. Granted,
someone writing their first content provider might find it useful, if
(and only if) it's one that's concrete and if (and only if) it doesn't
need to deal with several input types that have no common super type
(and even in that case they'll still typically end up with instanceof
tests to return subtype-appropriate results). That's on the argument
side of the getElements. On the return type side, it's of no benefit to
the author; they just pass this content provider into a generic viewer
that doesn't care whether it's Object[] or X[]. So in fact it's just a
burden with which one must conform.
So is
Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project
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 raw types other than a very few fixed by very local @suppressWarnings for rawTypes/uncheckedCast. Since the API is evolving, it would seem to be a good point to also introduce @NonNull/@Nullable. Regards Ed Willink ___ 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] Information about the Generifing JFace viewers project
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 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 generified,
and to do so in a context that is heavily dominated by Object[], which
interacts exceedingly poorly with generics. Thought I've made that
argument already, I think it bears repeating...
Anywhere you see something like T[] where T is a type parameter, you
already have to get suspicious. Of course we see this in
java.util.Collection:
T T[] toArray(T[] a);
But note that T is derived from the argument, and argument my not be null,
so even in an erased runtime environment we can determine a reasonable T
from a, so suspicion alleviated and that's why we can have generic
collection implementations...
Note that however nice it would have been that toArray() method looked
like this:
E[] toArray()
rather than
Object[] toArray
because you can't implement this generically, unless you provide some
object with the necessary *runtime *information about E to the
constructor of an implementation class...
So consider this:
public interface IStructuredContentProvider extends IContentProvider {
public Object[] getElements(Object inputElement);
}
there's no relationship between the input element's type and the type of
the array, so if someone proposes
public interface IStructuredContentProviderX, Y extends
IContentProviderX {
public Y[] getElements(X inputElement);
}
I'm going to be very suspicious. What this tells me is there must be some
sensible way of being sure that I'll be getting back a real Y[] instance
and not an Object[] instance. What could that sensible way be?
Of course directly implementing that interface in a sensible way is a good
solution, but what about generic solutions?
Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that EMF
generally has *only *content provider implementations analogous to
this). This existing implementation just don't work. You can just forget
about org.eclipse.jface.viewers.ArrayContentProvider.instance, you can just
deprecate org.eclipse.jface.viewers.ArrayContentProvider.getInstance(), and
you'd better add a public constructor and deprecate it while your at it,
because this implementation
public Object[] getElements(Object inputElement) {
if (inputElement instanceof Object[]) {
return (Object[]) inputElement;
}
if (inputElement instanceof Collection) {
return ((Collection) inputElement).toArray();
}
return new Object[0];
}
simply doesn't work for collections. You'll need new constructors and
new getInstance methods each of which specify the array type, either as
java.lang.Class or as an array prototype, as in the first form to toArray
above. You'd have to provide that even for the constructor that takes a
collection, just the collection instance will not suffice.
Great, so much for adding generics to JFace being erasure compatible,
counter to what was the case when Java's collection library was
generified. Nothing in the collections library was deprecated and no new
methods were added. In other words, for JFace's changes, you can't just
turn off warnings about raw types, you must deal with the deprecations and
API changes. So if you're trying to maintain something that works with old
versions of Eclipse (i.e., EMF is compatible with Eclipse 3.5), you're
completely hosed. You can't add generics, because you can't compile
against an older target platform that does have it, so you simply have to
live with a sea of raw type warnings (or turn them all off and lose the
value of even having such warnings). Also, you can't start using the new
methods instead of the deprecated ones, so you have to live with that sea
of warning as well, or just turn them off too. Nor you can you exploit any
of it to provide value to clients (given the premise there is value),
because you can't reasonably address this ArrayContentProvider problem
without inflicting the same pain on the clients (who actually have better
things to do, go figure).
Even the premise that this effort has value is questionable. Granted,
someone writing their first content provider might find it useful, if (and
only if) it's one that's concrete and if (and only if) it doesn't need to
deal with several input types that have no common super type (and even in
that case they'll still typically end up with instanceof tests to return
subtype-appropriate results). That's on the argument side of the
getElements. On the return type side, it's of no benefit to
[cross-project-issues-dev] Disk usage report for Hudson/Build
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 papyrus-master-tests-failures 1.6G emf-cdo-maintenance 1.6G emft-featuremodel-editor-xtext 1.4G amp-integration 1.4G emf-cdo-integration 1.4G webtools-vjet-juno 1.2G tycho-gmp.gmf.tooling 1.2G buckminster-voicetools-targetplatform 1.1G nattable-snapshot 1.1G buckminster-egf-indigo 1.1G emf-core-head 1.1G mylyn-release 1.0G buckminster-egf-juno 1.0G buckminster-egf-helios - Usage exceeding 1GB for: /shared (1000G capacity) (2014-07-30T10:00) 224.3G technology 122.7G eclipse 110.0G hipp 84.3G jobs 74.6G rt 28.2G webtools 23.1G SLES 11.3G tools 11.2G common 9.2G simrel 6.7G cbi-ng 5.3G modeling 2.9G orbit 1.6G mylyn 1.4G soa 1.3G cbi - Usage exceeding 1GB for: /shared/modeling 3.1G build - Usage exceeding 1GB for: /shared/tools 4.6G tm 2.6G objectteams 1.4G mtj 1.1G aspectj 1.1G windowbuilder - Usage exceeding 1GB for: /shared/technology 203.2G epp 9.2G sapphire 4.8G stem 2.4G cosmos 1.5G babel 1.3G actf END: build.eclipse.org hudson-slave1.eclipse.org /dev/xvda1158G 89G 69G 57% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) (2014-07-29T21:00) 10.2G mihini-nightly 7.0G tycho-mat-nightly 3.2G koneki-ldt 2.8G koneki-ldt-maintenance 1.9G cdt-nightly 1.6G cdt-maint 1.5G cdt-legacy 1.4G papyrus-0.10-maintenance-extra-nightly 1.4G papyrus-trunk-extra-nightly 1.3G mylyn-context-mft-test 1.3G papyrus-trunk-extra-nightly-tests 1.2G Xtext-nightly-Maintenance 1.2G gef-master 1.2G papyrus-master-tests-failures 1.2G papyrus-0.10-maintenance-nightly-tests 1.2G mylyn-integration 1.0G cdt-nightly-3.8 1.0G mylyn-integration-standalone END: hudson-slave1.eclipse.org hudson-slave2.eclipse.org - Usage exceeding 1GB for: END: hudson-slave2.eclipse.org hudson-slave3.eclipse.org /dev/xvda1 55G 32G 24G 58% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) (2014-07-29T18:00) END: hudson-slave3.eclipse.org ___ 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] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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 record. More generally... participating projects should create a record (if one does not already exist) for the release that they intend to contribute in the PMI and then inform the community via this list. Remember that project plans need to be specified by M4. A minimal plan that includes a description [1] of the release and a list of issues [2] (which we can generate automatically) shouldn't be too onerous, I hope. It would be good if you can capture a theme or two for your plan. Note that I hope to implement some automagic milestones generation based on a suggestion from Ed [3]. Let me know if you require assistance. Wayne [0]https://projects.eclipse.org/releases/mars [1]https://wiki.eclipse.org/Project_Management_Infrastructure/Release_Metadata#Description [2]https://wiki.eclipse.org/Project_Management_Infrastructure/Release_Metadata#Issues [3]https://bugs.eclipse.org/bugs/show_bug.cgi?id=440708 On 07/30/2014 04:42 AM, Mickael Istria wrote: 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: https://projects.eclipse.org/projects/technology.swtbot/releases/2.2.1 SWTBot features would be added to the Testing category. Since SWTBot depends on GEF, its offset would be +2. However, this shouldn't have a big impact since SWTBot will not contribute milestones to aggregator, but only approved releases. SWTBot is stable and there is very low risk of breaking change in its main APIs. If SWTBot has to create a new release by May/June 2015, we'll try to synchronize promotion and announcement with the Luna simultaneous release. What else needs to be done? Should I put a Git patch on a bug for cross-project? Still no way to contribute to simultaneous release with Gerrit? :P -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation http://www.eclipse.org Learn about Eclipse Projects http://www.eclipse.org/projects EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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, then let us know on this list (before the M4 deadline) and I'll update the record. More generally... participating projects should create a record (if one does not already exist) for the release that they intend to contribute in the PMI and then inform the community via this list. Remember that project plans need to be specified by M4. A minimal plan that includes a description [1] of the release and a list of issues [2] (which we can generate automatically) shouldn't be too onerous, I hope. It would be good if you can capture a theme or two for your plan. SWTBot doesn't really have a plan. People come and contribute what they want, and we release when we feel it's worth it. So I'm already thinking about how to hack this contribution process without planning a release. M4 is in December. Between December and June, there can be something like 3 or 4 releases (or 0) that cannot be planned before M4. In the case of SWTBot, we're not much interested about the Simultaneous Release planning, which for a small project such as SWTBot could prevent from frequent releases if necessary. What interest us is more to be included in Mars site and EPP package and making sure we work well with other projects of this same Mars site. Can the Release Train (or in that case the aggregator only) process handle the possibility of an unexpected release after M4 ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project
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. Again, there's no connection between the
Collection's E and the method's T. See its @throws ArrayStoreException
and the example in https://bugs.openjdk.java.net/browse/JDK-7023484
Markus
From: Ed Merks ed.me...@gmail.com
To: cross-project-issues-dev@eclipse.org
Date: 2014-07-30 16:47
Subject:Re: [cross-project-issues-dev] Information about the
Generifing JFace viewers project
Sent by:cross-project-issues-dev-boun...@eclipse.org
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
generified, and to do so in a context that is heavily dominated by
Object[], which interacts exceedingly poorly with generics. Thought I've
made that argument already, I think it bears repeating...
Anywhere you see something like T[] where T is a type parameter, you
already have to get suspicious. Of course we see this in
java.util.Collection:
T T[] toArray(T[] a);
But note that T is derived from the argument, and argument my not be null,
so even in an erased runtime environment we can determine a reasonable T
from a, so suspicion alleviated and that's why we can have generic
collection implementations...
Note that however nice it would have been that toArray() method looked
like this:
E[] toArray()
rather than
Object[] toArray
because you can't implement this generically, unless you provide some
object with the necessary runtime information about E to the constructor
of an implementation class...
So consider this:
public interface IStructuredContentProvider extends IContentProvider {
public Object[] getElements(Object inputElement);
}
there's no relationship between the input element's type and the type of
the array, so if someone proposes
public interface IStructuredContentProviderX, Y extends
IContentProviderX {
public Y[] getElements(X inputElement);
}
I'm going to be very suspicious. What this tells me is there must be some
sensible way of being sure that I'll be getting back a real Y[] instance
and not an Object[] instance. What could that sensible way be?
Of course directly implementing that interface in a sensible way is a good
solution, but what about generic solutions?
Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that EMF
generally has only content provider implementations analogous to this).
This existing implementation just don't work. You can just forget about
org.eclipse.jface.viewers.ArrayContentProvider.instance, you can just
deprecate org.eclipse.jface.viewers.ArrayContentProvider.getInstance(),
and you'd better add a public constructor and deprecate it while your at
it, because this implementation
public Object[] getElements(Object inputElement) {
if (inputElement instanceof Object[]) {
return (Object[]) inputElement;
}
if (inputElement instanceof Collection) {
return ((Collection) inputElement).toArray();
}
return new Object[0];
}
simply doesn't work for collections. You'll need new constructors and
new getInstance methods each of which specify the array type, either as
java.lang.Class or as an array prototype, as in the first form to toArray
above. You'd have to provide that even for the constructor that takes a
collection, just the collection instance will not suffice.
Great, so much for adding generics to JFace being erasure compatible,
counter to what was the case when Java's collection library was
generified. Nothing in the collections library was deprecated and no new
methods were added. In other words, for JFace's changes, you can't just
turn off warnings about raw types, you must deal with the deprecations and
API changes. So if you're trying to maintain something that works with
old versions of Eclipse (i.e., EMF is compatible with Eclipse 3.5), you're
completely hosed. You can't add generics, because you can't compile
against an older target platform that does have it, so you simply have to
live with a sea of raw type warnings (or turn them all off and lose the
value of even having such warnings). Also, you can't start using the new
methods instead of the deprecated ones, so you have to live with that sea
of warning as well, or just turn them off too. Nor you can you exploit
any of it to provide value to clients (given the premise there is value),
because you can't reasonably address this ArrayContentProvider problem
without inflicting the same pain on the
Re: [cross-project-issues-dev] Information about the Generifing JFace viewers project
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);
}
class ArrayContentProviderT implements IStructuredContentProviderT {
private static ArrayContentProvider? instance;
public static T ArrayContentProviderT getInstance() {
synchronized (ArrayContentProvider.class) {
if (instance == null) {
instance = new ArrayContentProvider();
}
@SuppressWarnings(unchecked)
ArrayContentProviderT result = (ArrayContentProviderT) instance;
return result;
}
}
public @Deprecated @Override Object[] getElements(Object inputElement) {
return elements(inputElement).toArray();
}
public @Override ArrayListT elements(Object inputElement) {
if (inputElement instanceof Object[]) {
@SuppressWarnings(unchecked)
ListT list = Arrays.asList((T[]) inputElement);
return new ArrayList(list);
}
if (inputElement instanceof Collection) {
@SuppressWarnings(unchecked)
CollectionT collection = (CollectionT) inputElement;
return new ArrayList(collection);
}
return new ArrayList();
}
}
public class Snippet {
public static void main(String[] args) {
ArrayContentProviderString instance = ArrayContentProvider.getInstance();
ArrayListString elements1 = instance.elements(null);
System.out.println(elements1);
}
}
Yeah, there’s a lot of unchecked casts but at least they are visible and
localized. That’s just the price one has to pay for weak typing.
Otherwise I agree with trying to make Object[] generic not working at all.
Arrays in Java are just too strongly and wrongly typed to work well with
generics. Best just to deprecate them and replace them with proper collections
that are much nicer to work with.
That’s also why I picked ArrayList rather than some other List as the
return type, to make it obvious to the caller that they are free to do anything
and everything with the returned collection.
--
Have a nice day,
Timo.
Sent from Windows Mail
From: Ed Merks
Sent: Wednesday, July 30, 2014 17:46
To: cross-project-issues-dev@eclipse.org
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 generified, and to do so in a context
that is heavily dominated by Object[], which interacts exceedingly poorly with
generics. Thought I've made that argument already, I think it bears
repeating...
Anywhere you see something like T[] where T is a type parameter, you already
have to get suspicious. Of course we see this in java.util.Collection:
T T[] toArray(T[] a);
But note that T is derived from the argument, and argument my not be null, so
even in an erased runtime environment we can determine a reasonable T from a,
so suspicion alleviated and that's why we can have generic collection
implementations...
Note that however nice it would have been that toArray() method looked like
this:
E[] toArray()
rather than
Object[] toArray
because you can't implement this generically, unless you provide some object
with the necessary runtime information about E to the constructor of an
implementation class...
So consider this:
public interface IStructuredContentProvider extends IContentProvider {
public Object[] getElements(Object inputElement);
}
there's no relationship between the input element's type and the type of the
array, so if someone proposes
public interface IStructuredContentProviderX, Y extends IContentProviderX {
public Y[] getElements(X inputElement);
}
I'm going to be very suspicious. What this tells me is there must be some
sensible way of being sure that I'll be getting back a real Y[] instance and
not an Object[] instance. What could that sensible way be?
Of course directly implementing that interface in a sensible way is a good
solution, but what about generic solutions?
Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that EMF
generally has only content provider implementations analogous to this). This
existing implementation just don't work. You can just forget about
org.eclipse.jface.viewers.ArrayContentProvider.instance, you can just deprecate
org.eclipse.jface.viewers.ArrayContentProvider.getInstance(), and you'd better
add a public constructor and deprecate it while your at it, because this
implementation
public Object[] getElements(Object inputElement) {
if (inputElement instanceof Object[]) {
return (Object[]) inputElement;
}
if (inputElement instanceof Collection) {
return ((Collection) inputElement).toArray();
}
return new Object[0];
}
simply
Re: [cross-project-issues-dev] Disk usage report for Hudson/Build
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 to clean up your project's disk space from time to time :) Thanks, Denis On 07/30/2014 12:20 PM, ge...@eclipse.org wrote: 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 papyrus-master-tests-failures 1.6G emf-cdo-maintenance 1.6G emft-featuremodel-editor-xtext 1.4G amp-integration 1.4G emf-cdo-integration 1.4G webtools-vjet-juno 1.2G tycho-gmp.gmf.tooling 1.2G buckminster-voicetools-targetplatform 1.1G nattable-snapshot 1.1G buckminster-egf-indigo 1.1G emf-core-head 1.1G mylyn-release 1.0G buckminster-egf-juno 1.0G buckminster-egf-helios - Usage exceeding 1GB for: /shared (1000G capacity) (2014-07-30T10:00) 224.3G technology 122.7G eclipse 110.0G hipp 84.3G jobs 74.6G rt 28.2G webtools 23.1G SLES 11.3G tools 11.2G common 9.2G simrel 6.7G cbi-ng 5.3G modeling 2.9G orbit 1.6G mylyn 1.4G soa 1.3G cbi - Usage exceeding 1GB for: /shared/modeling 3.1G build - Usage exceeding 1GB for: /shared/tools 4.6G tm 2.6G objectteams 1.4G mtj 1.1G aspectj 1.1G windowbuilder - Usage exceeding 1GB for: /shared/technology 203.2G epp 9.2G sapphire 4.8G stem 2.4G cosmos 1.5G babel 1.3G actf END: build.eclipse.org hudson-slave1.eclipse.org /dev/xvda1158G 89G 69G 57% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) (2014-07-29T21:00) 10.2G mihini-nightly 7.0G tycho-mat-nightly 3.2G koneki-ldt 2.8G koneki-ldt-maintenance 1.9G cdt-nightly 1.6G cdt-maint 1.5G cdt-legacy 1.4G papyrus-0.10-maintenance-extra-nightly 1.4G papyrus-trunk-extra-nightly 1.3G mylyn-context-mft-test 1.3G papyrus-trunk-extra-nightly-tests 1.2G Xtext-nightly-Maintenance 1.2G gef-master 1.2G papyrus-master-tests-failures 1.2G papyrus-0.10-maintenance-nightly-tests 1.2G mylyn-integration 1.0G cdt-nightly-3.8 1.0G mylyn-integration-standalone END: hudson-slave1.eclipse.org hudson-slave2.eclipse.org - Usage exceeding 1GB for: END: hudson-slave2.eclipse.org hudson-slave3.eclipse.org /dev/xvda1 55G 32G 24G 58% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) (2014-07-29T18:00) END: hudson-slave3.eclipse.org ___ 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] RAP 3.x for Mars
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 we will contribute RAP 3.1 builds to Mars [3]. Content is still to be defined, but all the dates are already in the plan document. As always... RAP contributions should be available with +2. Thanks, Markus [1] http://dev.eclipse.org/mhonarc/lists/rap-dev/msg01153.html [2] https://projects.eclipse.org/projects/rt.rap/releases/3.0.0 [3] https://projects.eclipse.org/projects/rt.rap/releases/3.1.0 ___ 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] EPP 4.5 for Mars
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 the first milestones. Thanks, Markus [1] https://projects.eclipse.org/projects/technology.packaging/releases/4.5.0/plan ___ 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] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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 of this package... chances are good that it will be me who responds to the bug report then... ;-) Thanks, Markus On Wed, Jul 30, 2014 at 10:42 AM, Mickael Istria mist...@redhat.com wrote: 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: https://projects.eclipse.org/projects/technology.swtbot/releases/2.2.1 SWTBot features would be added to the Testing category. Since SWTBot depends on GEF, its offset would be +2. However, this shouldn't have a big impact since SWTBot will not contribute milestones to aggregator, but only approved releases. SWTBot is stable and there is very low risk of breaking change in its main APIs. If SWTBot has to create a new release by May/June 2015, we'll try to synchronize promotion and announcement with the Luna simultaneous release. What else needs to be done? Should I put a Git patch on a bug for cross-project? Still no way to contribute to simultaneous release with Gerrit? :P -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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 that time (depends on actual community participation). The project can then either (a) contribute 5.2 to Mars or (b) gamble that by the time Mars GA rolls around, they will be on some version like 5.4 even if there is not even a branch or a plan for that release yet. If the project opts for option (a), we can very well end up in a situation that what ships with the shiny new Mars release is two to three releases out of date. If the project opts for option (b) they may end up in a situation where they have to issue filler releases just to catch up with the declaration or miss the declaration and contribute an earlier version. 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 cannot contribute breaking changes after mX is better than you cannot switch contribution version after mX. - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton Sent: Wednesday, July 30, 2014 12:14 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package The primary intent behind a plan is to give potential contributors some sense of how they can contribute. I have no trouble putting you down for 2.2.1 for now with an expectation that--should you receive contributions that warrant the creation of a new release--you'll create a new release record (say 2.3.0) at a later date. The actual name of your release and whether or not you create a new release record is not nearly as important as making sure that you get proper practice participating in the release and that your bits don't break the aggregation. So declaring a new release before M4 isn't as important to me as making sure that you know what bits you'll actually be contributing early enough in the cycle to do adequate testing. I hope that this makes sense. Wayne On 07/30/2014 01:04 PM, Mickael Istria wrote: 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, then let us know on this list (before the M4 deadline) and I'll update the record. More generally... participating projects should create a record (if one does not already exist) for the release that they intend to contribute in the PMI and then inform the community via this list. Remember that project plans need to be specified by M4. A minimal plan that includes a description [1] of the release and a list of issues [2] (which we can generate automatically) shouldn't be too onerous, I hope. It would be good if you can capture a theme or two for your plan. SWTBot doesn't really have a plan. People come and contribute what they want, and we release when we feel it's worth it. So I'm already thinking about how to hack this contribution process without planning a release. M4 is in December. Between December and June, there can be something like 3 or 4 releases (or 0) that cannot be planned before M4. In the case of SWTBot, we're not much interested about the Simultaneous Release planning, which for a small project such as SWTBot could prevent from frequent releases if necessary. What interest us is more to be included in Mars site and EPP package and making sure we work well with other projects of this same Mars site. Can the Release Train (or in that case the aggregator only) process handle the possibility of an unexpected release after M4 ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools My blog http://mickaelistria.wordpress.com - My Tweets http://twitter.com/mickaelistria ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation http://www.eclipse.org Learn about Eclipse Projects http://www.eclipse.org/projects https://www.eclipsecon.org/europe2014 EclipseCon Europe 2014 ___ 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
Re: [cross-project-issues-dev] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package
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 cannot contribute breaking changes after mX is better than you cannot switch contribution version after mX. -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation http://www.eclipse.org Learn about Eclipse Projects http://www.eclipse.org/projects EclipseCon Europe 2014 https://www.eclipsecon.org/europe2014 ___ 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] Information about the Generifing JFace viewers project
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 elements(inputElement).toArray();
}
So we'd need to all switch to Java 8 and our code would become a sea of
deprecation and raw type warnings.
ArrayListT elements(Object inputElement);
Of course you'd propose Collection? extends T or List? extends T
not ArrayList, right?
}
class ArrayContentProviderT implements IStructuredContentProviderT {
private static ArrayContentProvider? instance;
public static T ArrayContentProviderT getInstance() {
synchronized (ArrayContentProvider.class) {
if (instance == null) {
instance = new ArrayContentProvider();
}
@SuppressWarnings(unchecked)
ArrayContentProviderT result = (ArrayContentProviderT)
instance;
return result;
}
}
public @Deprecated @Override Object[] getElements(Object
inputElement) {
return elements(inputElement).toArray();
}
So you're suggesting that no one should ever use or implement this
method. While that's certainly a way to avoid the whole problem with
generic array, none of this fits with Dani's the problems should go way
just by inferring types.
public @Override ArrayListT elements(Object inputElement) {
if (inputElement instanceof Object[]) {
@SuppressWarnings(unchecked)
ListT list = Arrays.asList((T[]) inputElement);
return new ArrayList(list);
}
if (inputElement instanceof Collection) {
@SuppressWarnings(unchecked)
CollectionT collection = (CollectionT) inputElement;
return new ArrayList(collection);
}
return new ArrayList();
}
}
So do the above look simple than the current code? Was it easier to
write? Did generics provide value or make it more complex without
providing value? It's clear It's not simple and generics actually made
it more complicated.
No only that, but as I've pointed out, the convenience to the author is
generics on the argument side of the equation, not on the return type side.
public class Snippet {
public static void main(String[] args) {
ArrayContentProviderString instance =
ArrayContentProvider.getInstance();
ArrayListString elements1 = instance.elements(null);
System.out.println(elements1);
}
}
Yeah, there's a lot of unchecked casts but at least they are visible
and localized. That's just the price one has to pay for weak typing.
The real question is, was it easier to write? Because in the end, who
are the callers to these APIs? A bunch of generic viewers that are
already written and that we don't generally write ourselves. And they
don't care currently. So the whole things fundamentally has to come
down to what's easiest for the authors to write content providers.
Otherwise I agree with trying to make Object[] generic not working at
all. Arrays in Java are just too strongly and wrongly typed to work
well with generics. Best just to deprecate them and replace them with
proper collections that are much nicer to work with.
Yes, it's certainly far more reasonable to argue getting rid of the
arrays. But that's even more fundamentally disruptive, and requires
Java 8. Note that EMF heavily uses Collection? rather than Object[]
in its platform neutral equivalents of these APIs.
That's also why I picked ArrayList rather than some other List as
the return type, to make it obvious to the caller that they are free
to do anything and everything with the returned collection.
I think that makes no sense. The client must always create a specific
list implementation and the contract allows the caller to add instances
to that collection? Collection? extends T would seem far more
reasonable and convenient. Then one could return just the collection
you already have or use Arrays.asList.
--
Have a nice day,
Timo.
Sent from Windows Mail
*From:* Ed Merks mailto:ed.me...@gmail.com
*Sent:* ?Wednesday?, ?July? ?30?, ?2014 ?17?:?46
*To:* cross-project-issues-dev@eclipse.org
mailto:cross-project-issues-dev@eclipse.org
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 generified, and to do so in a context that is heavily dominated by
Object[], which interacts exceedingly poorly with generics. Thought
I've made that argument already, I think it bears repeating...
Anywhere you see something like T[] where T is a type parameter, you
already have to
