Community
Participate
Working Groups
This is going to be controversial and probably can't happen until at least after 3.4, but eclipse keeps saying it is a platform. However, since JDT and PDE are in the Eclipse project, eclipse is still considered to be a Java IDE. To help make the distinction it might be time to graduate JDT and PDE over to the Tooling project to make the distinction. This would treat JDT and PDE no different than DLTK, PDT, CDT, etc. As tooling built on top of the main Eclipse platform and Equinox projects. Feel free to move this to the appropriate discussion forum.
Just say no to special status! What will the platform do if you install it without these though?
You get a basic IDE that doesn't have anything beyond simple functionality. A perferct platform to allow custom IDEs to be built on. I typically start my customization with a platform build and then add in the other items. I add JDT as a separate plugin already (because I have one plugin that requires it), other than that it gives you a clean slate to start with.
Ed: Basically, you'd have The Platform Runtime Binary or SDK, eg: http://download.eclipse.org/eclipse/downloads/drops/S-3.4M4-200712131700/index.php#PlatformRuntime Given the eclipsebuilder already builds this, the only big change here would be marketing/branding (like when XSD "moved" to MDT). ;-)
As much as I don't like moving projects (personally moving them, I mean. :)) I do like this idea. :)
I agree that if we were going to start Eclipse today, JDT would likely fit under Tools. But historically, when it all started, the Eclipse project was formed of a Platform, a JDT and a PDE; to which later on Equinox got added. Now, the Eclipse project should not be confused with the Eclipse platform though; it simply maps to the SDK we use to develop Eclipse plug-ins. As said already, if all you are looking for is a vanilla platform, then there is already a distribution for it with no JDT etc... Adding to the controversy <g>, the bare minimum being Equinox, would you also ask to fork Equinox in a different project as well ?
My understanding was that there are in fact plans to move Equinox to a new runtime project so that weakens your argument for JDT's and PDE's privileged status considerably if it's meant to strengthen it. :-P Of course I don't really see how moving these makes any real substantive difference since obviously I, and most folks, will still want to get a download exactly like what I get today. I think the key point is that issues like https://bugs.eclipse.org/bugs/show_bug.cgi?id=155323 will perhaps get to be less contentious when the platform isn't perceived so much as a sacred monolith for which one has to fight to have extremely useful utilities added. It will help to make the platform appear to be more open to the community. Remember what happened to the privileged monarchs in many countries when the peasants became displeased. Hehehe... Of course provisioning promises to solve all these issues of which box contains what...
(In reply to comment #5) > I agree that if we were going to start Eclipse today, JDT would likely fit > under Tools. But historically, when it all started, the Eclipse project was > formed of a Platform, a JDT and a PDE; to which later on Equinox got added. > > Now, the Eclipse project should not be confused with the Eclipse platform > though; it simply maps to the SDK we use to develop Eclipse plug-ins. > > As said already, if all you are looking for is a vanilla platform, then there > is already a distribution for it with no JDT etc... > > Adding to the controversy <g>, the bare minimum being Equinox, would you also > ask to fork Equinox in a different project as well ? > 1. Yeah, Equinox probably should be it's own project...but the platform and equinox are tied closely together. 2. However, JDT and PDE rely on the other two, and Eclipse Platform and Equinox can live just fine without them. 3. Marketing and perception. We want Eclipse now to be known as a Platform for general applications, not known as a Java IDE. With JDT included in the main Eclipse project, it is still very easy to say that is it's main focus. 4. It brings JDT and PDE into the same level as other language projects like CDT, DLTK, Cobol, etc, and it's in a common place for these types of Tools. 5. It potentially allows JDT and more specifically PDE a bit more flexibility in being able to use components and tools from other projects. At the moment there is a lot of re-invention going on at PDE that other projects already have more enhanced and better support for. One such case, WST's XML editor could be used by PDE to allow for a better XML editing experience. Plus with exsd, being brought into XSD spec compliance, this would allow possible leveraging of the XSD editor as well. Imagine what they could both do if they could leverage EMF in their development? So two big goals, clearly make that distinction that Eclipse is truely a Platform, and give some more freedom to JDT and PDE to use other projects components.
Dave, the point about PDE and JDT being able to use other projects is a very good one! For example, GEF and Zest would be very useful for the PDE to display dependency graphs... There's always been this odd type of circular argument that if the platform doesn't use it, it shouldn't be in the platform. And of course the platform can't use it if it's not already in the platform, so it logically follows that anything not already in the platform can't be added to the platform. Of course one asks how is it then that data binding was added to the platform there's a bit of chuckling and shrugging... :-P We live in a world more often driven by vague perceptions than by logical facts so something to enhance the perception that Eclipse is indeed a platform for anything rather than primarily a Java IDE definitely seems like goodness...
If we are using this bug to record wild-eyed pie-in-the-sky brainstorming ideas .... it's sort of like we should have an IDE top level project, in addition (or instead of) the Platform Project. While in theory it shouldn't matter, it seems Eclipse is like other Corporations, in that the management structure effects the technology structure (and vice versa).
Re: comment 6 Ed, when referring to bug 155323, I think the argument there was that not everybody was needing an image viewer. The fact Tod mentionned JDT was accidental, and he could have picked any name. Relocating JDT to a different project would change this fact.
Oops. Embarrassing typo. "Relocating JDT to a different project would change this fact." should have read "Relocating JDT to a different project would NOT change this fact."
Philip, I still haven't heard a good reason why JDT and PDE can't be moved. The only thing I've heard is that it's always been that way. Which to me is never a good reason.
> Dave, the point about PDE and JDT being able to use other projects is a very > good one! For example, GEF and Zest would be very useful for the PDE to display > dependency graphs... There's always been this odd type of circular argument > that if the platform doesn't use it, it shouldn't be in the platform. And of > course the platform can't use it if it's not already in the platform, so it > logically follows that anything not already in the platform can't be added to > the platform. There is actually no rule that bundles in the Eclipse project can't consume or depend on bundles from other projects. There are of course many dependencies on the Orbit project, and in Equinox p2 we are consuming pieces from ECF today, and are considering consuming pieces from other projects as well. And of course, if Equinox moved into a different project, the platform project would depend on that as well.
(In reply to comment #13) > There is actually no rule that bundles in the Eclipse project can't consume or > depend on bundles from other projects. There are of course many dependencies > on the Orbit project, and in Equinox p2 we are consuming pieces from ECF today, > and are considering consuming pieces from other projects as well. And of > course, if Equinox moved into a different project, the platform project would > depend on that as well. Well there may not be a publicly stated rule or written down, but from my conversations with several PDE members, it seems that there is a preception that they can't use other tools from other projects, because they are under grouped with the other base platform project and tooling. Again, perceptionally moving would help eliminate this perception.
As Ed said, Equinox is going to move to a new Runtime project; this is to better collocate Equinox OSGi runtime with other Equinox aspects (closer linkage is better). Now for moving JDT/PDE, this has been a question for years; and the only true explanation is the historical one. It certainly doesn't mean we couldn't change this, but we need to look at what it would buy us. When it comes to introducing dependencies, we always want to be careful, but as JohnA said, the Eclipse project is not trying to self sustain. What we want to avoid is to force the product chain into swallowing unneeded dependencies which we might have introduced. I believe that once EPP and P2 are in use, the project boundaries are somewhat blurred; i.e. what really matters is what the product package looks like.
> While in theory it shouldn't matter, it seems Eclipse is like other > Corporations, in that the management structure effects the technology structure > (and vice versa). This raises a good point. Eclipse projects are not *purely* technology structures. If viewed purely as technology trees, there are a hundred different equally valid ways you can slice up the software produced at eclipse.org. One could equally argue that it's inconsistent for tooling for J2ME, J2SE, and J2EE to be split across three top level projects (DSDP, Eclipse, and WTP respectively), since they're all Java tooling. Or, that the Graphical Editor Framework and Graphical Modeling Framework belong together, etc. In practice, Eclipse projects are not merely category boxes. Each project has its own charter, project management committee, rules, conventions, culture, build systems, etc. Ideally, they are united by a common purpose that these social structures facilitate achieving. Admittedly the common purpose of the Eclipse top level project (produce the Eclipse SDK) is circular, but it helps to avoid the bloat that would inevitably worsen if there was no such scope. How else do you determine what should or should not be added to a "platform for anything and nothing in particular"? One of the platform's greatest challenges is to avoid becoming a common dumping ground.
(In reply to comment #16) > > While in theory it shouldn't matter, it seems Eclipse is like other > > Corporations, in that the management structure effects the technology structure > > (and vice versa). > In practice, > Eclipse projects are not merely category boxes. Each project has its own > charter, project management committee, rules, conventions, culture, build > systems, etc. Ideally, they are united by a common purpose that these social > structures facilitate achieving. Admittedly the common purpose of the Eclipse > top level project (produce the Eclipse SDK) is circular, but it helps to avoid > the bloat that would inevitably worsen if there was no such scope. How else do > you determine what should or should not be added to a "platform for anything > and nothing in particular"? One of the platform's greatest challenges is to > avoid becoming a common dumping ground. This still doesn't justify JDT/PDE having special status. How does having JDT/PDE being in the Eclipse project add strength the to what gets included and excluded from the platform? To me, the following is what should be in the Eclipse project: Equinox Platform RCP Those three projects are the basis for all other projects to work from. Whether it's dictated by Corporate Structure or Technological structure doesn't matter, those can change as well. Still haven't heard a critical reason that would stop either of these from moving to another project. My reason still is one of perception and marketing. Having them treated as any other tooling project, would mean that their requests for specific platform features would be treated just like any requests coming from the other development tools. Open a bug, and let the community decide what gets included into the base platform code and what doesn't. I don't see it having a negative effect on the general community of users either. The JDT community would still follow them to the JDT Tooling project, the PDE Community would follow them to there as well. The vast majority of users as soon as you mention Eclipse, they still think Java IDE. It doesn't help to have JDT under the Eclipse project in this regards.
Historical or not, the main / most important output of the Eclipse Project is *not* the platform. It is the _Eclipse_SDK_, which is the minimal -- although it's hard to call anything that's 140Meg minimal -- tooling that is required to produce Java-based Eclipse plug-ins. I can certainly imagine moving the requirement to deliver that somewhere else at Eclipse.org (the Eclipse Packaging Project, for example), but until we do, I'm comfortable leaving JDT and PDE where they are. As to JDT and PDE having special status, that isn't because they are part of the Eclipse Project, but rather because we *all* depend on them to implement the code we work on, so we do everything we can to help make them work well for us. Moving them to another project would not change that.
Mike, Yes, movement is mostly just window dressing but windows and their dressings are important in transparent organizations. It's hard to argue for example that data binding is needed to ship JDT and PDE tools. Don't get me wrong, I think that stuff is great, but it wasn't strictly needed for producing a minimal Java IDE for developing Eclipse applications. Of course *you* are comfortable with JDT and PDE where they are. If you weren't you'd have done something about it long ago. :-P The issue remains as to the community's comfort. I do agree though, this is not a world hunger issue and I think movement of the projects is little more than window dressing. I'd careful about categorizing more important and less important things given the evolving nature of what Eclipse is. I must say though that the Eclipse SDK is exceedingly important to me! And I wouldn't like it to get overly bloated...
Thanks, Ed. To be clear, I'm not against us having this discussion, and I'm sensitive to the community perception. On a vaguely related note, I'm going to try to overcome my hatred of travel and go to EclipseCon this year. Maybe we should set up a BOF to talk about this...
Discussions are good a good thing. I know there are interesting points and view that are equally valid though they might seem contradictory. It would be great to see you at EclipseCon. A BOF would be cool The bar at the Hyatt is very nice too. ;-)
+1 on keeping discussing it. It's one of the reasons for bring it up. Status quo is maintained if items aren't brought up for discussion. As for the community concern, I can only speak from my end users that I deal with when I mention eclipse. Those that know about it automatically assume it's a Java IDE. However, the product we give our members, is an XML IDE focused IDE, and only has a JDT because I have one plugin that requires it (haven't taken the time to rewrite it). If I didn't need that one plugin, I could drop JDT altogether, but still distribute my product and have full functionality. I love JDT for my own development, but the fact is that the community still thinks of eclipse as JDT, when that isn't the case anymore. Truthfully is moving it going to solve this, no. However, it does help with the perception. And since JDT is the most visible piece, it would send a strong message (whether good or bad would depend on point of view), that eclipse is truely more than JDT. I think I'm up to a buck fifty now. :)
Then maybe the "Eclipse project" name is too misleading (which is something we already discussed a long time ago). If it had been name "Eclipse SDK", wouldn't things be perceived differently ? To me, JohnA's comment 8 is quite accurate with a little nuance about specific support to JDT. Being a JDT person since day 1, I can tell you that the platform is NOT anyhow giving JDT any special feature card; precisely to avoid platform only servicing one particular usecase (JDT). So other tool projects shouldn't feel JDT is treated special. We are adopting new platform APIs, and interacting with the platform, but we are not treated special (any other early adopter of these API will be equally listened). So really, collocating SDK projects makes sense because they are just aiming at building the SDK; and JDT is sort of a demonstrator of all the cool things the platform exposes (if we did it, others can do it as well).
(In reply to comment #23) > Then maybe the "Eclipse project" name is too misleading (which is something we > already discussed a long time ago). If it had been name "Eclipse SDK", wouldn't > things be perceived differently? Partly...but I would go farther...name it "Eclipse Platform". And again, have the Platform, Equinox, and RCP pieces, that make up the platform of eclipse. > So really, collocating SDK > projects makes sense because they are just aiming at building the SDK; and JDT > is sort of a demonstrator of all the cool things the platform exposes (if we > did it, others can do it as well). The one thing I don't consider JDT to be is a SDK tool. I could technically, write Eclipse without the JDT, and PDE. In fact before there was eclipse, it was probably written in Smalltalk or something else to begin with. The fact that you see JDT as the demonstrator is just your view point... There are many eclipse projects doing very cool things with the API. The Eclipse Notification dialog is an example coming from Mylyn, the SSE from WTP, EMF from the Modeling Project, etc. I would rephrase it as saying that all of the other projects demonstrate just as well as JDT what can be done with the base platform. JDT got the ball rolling but it isn't a special case for demonstration and implementation of the API.
I agree JDT is not the sole demonstrator, but historically when the platform all started we needed one. There are many cool things you can do with the platform today. So, I see where you go now, you'd like to see "Eclipse project" be "Eclipse platform", and in this case, I agree JDT/PDE should be elsewhere. But, really it means (to us) "Eclipse SDK project"... Anyway, let's meet at EclipseCon bar and talk through it.
(In reply to comment #25) > I agree JDT is not the sole demonstrator, but historically when the platform > all started we needed one. There are many cool things you can do with the > platform today. And to me...this is the issue that people need to get by...yes it was setup this way historically, but just because it's always been this way isn't a reason that it has to remain this way. Not very Agile of us if we did that. :)
The confusion of "The Eclipse Project" being both the platform and the Java SDK was actually useful in the early days of Eclipse establishing a name of itself. Now it only hurts the larger goal. I agree that this split is long overdue and I'm all for it. However, since doing nothing is easier than doing something, the benefits need to feel more compelling for this to gain traction. So we need some sharpening of the message. What I've heard so far that certainly "resonates" for me is: 1) It relieves the pressure on the platform being the dumping ground 2) It opens up the possibility of introducing new dependencies by PDE and JDT. Note: it still may be decided that we don't *want* to add more dependencies and increase the footprint, but at least the possibility would be opened up a bit. 3) It sends the right message to the community that all who depend on the platform are equal citizens in Eclipse. +1 to beer bof at EclipseCon :->
I take it this means you've gotten over your aversion to travel and that we can expect to see you at EclipseCon. Excellent! We'll get you liquored up until you agree with all our demands. :-P
(In reply to comment #28) > I take it this means you've gotten over your aversion to travel and that we can > expect to see you at EclipseCon. Excellent! We'll get you liquored up until > you agree with all our demands. :-P Its McQ who has an aversion to travel. Me, I love it :)
Oops, that G of yours looked a lot like a Q! I'm still not sure how a Mike Wilson becomes of a McQ anyway, but I must say that I find it thoroughly confusing. I think we need to gather all you folks together at the same bar at the same time for some bloggable photos with identifying labels. I'm sure if we can just liquor up the lot of you, we'd get a lot these discussions moving along to their proper conclusions (I'll let you know what those are) a lot more quickly! :-P
Well, this is off-topic, but... It's historical. In my early university days, we used a system with a five character limit on user ids. Mine was "MIKEW", which if you pronounce it (i.e. "mi"..."kew") sounds like "McQ". People started calling me that, and I've been McQ ever since.
McQ, That's too funny and makes such perfect sense. I hope you will get over your aversion to travel at least this one time. This year's EclipseCon is shaping up to be by far the best yet. Be sure to book your hotel immediately before they run out of rooms at the Hyatt! I promise to buy you a drink!! Of course last year the community award winners had $1000 each to buy drinks for everyone, so I hope that tradition will continue... Sorry for the off topic topics, but Eclipse is about more than just technology. It's also about sociology and we've got one of the most technical fantastic community's on the planet.
The Platform is aimed at developers. To develop on top of the Platform, developers need tools. JDT and PDE are those tools (even if you technically could use Notepad/javac, but that would not be very convenient, would it?). To keep growing the Eclipse ecosystem, you need to make it easy to develop for the Platform. Bundling the Platform with JDT/PDE makes it easy to develop for the Platform. No separate download is needed. Developers are all set after they downloaded the Eclipse SDK and they can start developing their own plugin in the next minute. As a developer, I like this very much.
(In reply to comment #33) > The Platform is aimed at developers. To develop on top of the Platform, > developers need tools. JDT and PDE are those tools (even if you technically > could use Notepad/javac, but that would not be very convenient, would it?). To > keep growing the Eclipse ecosystem, you need to make it easy to develop for the > Platform. Bundling the Platform with JDT/PDE makes it easy to develop for the > Platform. No separate download is needed. Developers are all set after they > downloaded the Eclipse SDK and they can start developing their own plugin in > the next minute. As a developer, I like this very much. Yes, I agree that you need something to develop the Platform with, and as it stands now, JDT is used, and yes other items were used in the past. However, what you are talking about is Packaging. The Packaging project can take care of bundling together the components needed for Developing Eclipse. It doesn't mean that JDT/PDE must remain with the Platform. They aren't the platform, but a tool that uses the platform. There is a fine distinction here. The packaging project would handle creating the Eclipse SDK Package which would possibly include the JDT and PDE. Look at some of the recent proposals coming down the line, particularly the latest Glimmer project proposal for one that could technically be used to create eclipse plugins, and the eclipse API. As ZX has mentioned in the past, there is going to come a time when JDT isn't needed for writing eclipse plugins.
>It doesn't mean that JDT/PDE must remain with the Platform. Well they aren't in the Platform they are part of the 'Eclipse' project and there is already separate packaging for the Platform itself. Let's simply rename the project to 'Eclipse SDK' project then ;-)
(In reply to comment #35) > >It doesn't mean that JDT/PDE must remain with the Platform. > Well they aren't in the Platform they are part of the 'Eclipse' project and > there is already separate packaging for the Platform itself. > > Let's simply rename the project to 'Eclipse SDK' project then ;-) I would have no fundamental problem with it, as it helps with the distinction a bit more, but doesn't entirely make a clean break from the past and provide. Personal preference though is to still group all the tools for developing languages or IDEs into one project though. but again, that's personal preference.
(In reply to comment #35) > Let's simply rename the project to 'Eclipse SDK' project then ;-) If "Eclipse is aimed at developers" the question becomes "which developers?". Because, for example, C++ programmers are developers too, but they don't need JDT and PDE. And PHP programmers are developers, and they don't need JDT and PDE. ... So perhaps what is being said is "Eclipse is aimed at people who write Eclipse plug-ins" (thus requiring PDE), but I don't think that's a true statement: I think a fairly small number of the Eclipse users develop additional plug-ins. (I'd like to find a way to increase that number, but that's a separate conversation.) Similarly, "Eclipse SDK" is confusing when you consider the different "developer" audiences. Does the Eclipse SDK provide me with APIs for building on top of the Eclipse COSMOS project? No, the Eclipse COSMOS SDK does. Does the Eclipse SDK provide me with APIs for building on top of CDT? No, the Eclipse CDT SDK does. Etc. ... So perhaps the "Eclipse Platform SDK" or the "SDK for the Eclipse Platform" are better names?
Agree Bjorn that in the larger context the term "SDK" is ambiguous. Seems a holdover (there used to be only one SDK but now in Eclipse saying "software development kit" begs the question "for what?"). And agree Dave with your comment #34: I'm a big fan of the packaging projects, mostly because it allows a clearer separation between reusable technology and what one might consider "products", a topic we continue to struggle with. Which to me is really all we're talking about here too. If you forget about the historical reasons, if you were to just walk in off the street and see our current set up, it looks confusing and inconsistent. The real issue to me is that as we continue to blur product and technology we make these discussions painful and full of misunderstanding.
(In reply to comment #37) > (In reply to comment #35) > > Let's simply rename the project to 'Eclipse SDK' project then ;-) > If "Eclipse is aimed at developers" the question becomes "which developers?". > Because, for example, C++ programmers are developers too, but they don't need > JDT and PDE. And PHP programmers are developers, and they don't need JDT and > PDE. ... So perhaps what is being said is "Eclipse is aimed at people who > write Eclipse plug-ins" (thus requiring PDE), but I don't think that's a true > statement: I think a fairly small number of the Eclipse users develop > additional plug-ins. (I'd like to find a way to increase that number, but > that's a separate conversation.) > Similarly, "Eclipse SDK" is confusing when you consider the different > "developer" audiences. Does the Eclipse SDK provide me with APIs for building > on top of the Eclipse COSMOS project? No, the Eclipse COSMOS SDK does. Does the > Eclipse SDK provide me with APIs for building on top of CDT? No, the Eclipse > CDT SDK does. Etc. ... So perhaps the "Eclipse Platform SDK" or the "SDK for > the Eclipse Platform" are better names? +1 to what Bjorn is saying... +1 to the move to Tools in general My $0.02: 1. The "Platform" should just be the runtime/SWT/RCP etc. as proposed. The distinction is already made in the subproject structure of the Platform project between the Platform subproject and the JDT subproject, and there are different downloads for all these available, so there is already a notion of these being different entities. I don't think the move is much of a stretch for most people to comprehend. 2. Have an "Eclipse Plug-in Development SDK" download that bundles JDT, PDE, and whatever else is deemed required to author plug-ins. This will essentially be what the "Eclipse SDK" is now, but the name is more descriptive and differentiates it from #3. 3. Have an "Eclipse Platform Source SDK" download which just contains the source for the components listed in #1. I think such a name makes it fairly clear to newcomers and old-timers as to what they are getting. 4. I have yet to see any reason not to do this move other than inertia. Granted, there is a certain amount of work involved in moving these projects, and there would be some challenges involved, but I think the principle of the move is a good one, so even if the move were to take some time to accomplish given everyone's busy schedules (and given that we don't want to destabilize Ganymede), I think it would be good if people could at least agree that the idea of the move makes sense.
(In reply to comment #39) > 4. I have yet to see any reason not to do this move other than inertia. > Granted, there is a certain amount of work involved in moving these projects, > and there would be some challenges involved, but I think the principle of the > move is a good one, so even if the move were to take some time to accomplish > given everyone's busy schedules (and given that we don't want to destabilize > Ganymede), I think it would be good if people could at least agree that the > idea of the move makes sense. I would agree that this shouldn't happen until after Ganymede is out the door, but it should happen sooner rather than later in the development cycle for 3.5, just so it doesn't get pushed off until the middle of a milestone.
(In reply to comment #40) > > I would agree that this shouldn't happen until after Ganymede is out the door, > but it should happen sooner rather than later in the development cycle for 3.5, > just so it doesn't get pushed off until the middle of a milestone. > A comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=239601#c6 reminded me of this discussion. Time to open it up again?
(In reply to comment #41) > (In reply to comment #40) > > > > I would agree that this shouldn't happen until after Ganymede is out the door, > > but it should happen sooner rather than later in the development cycle for 3.5, > > just so it doesn't get pushed off until the middle of a milestone. > > > > A comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=239601#c6 reminded > me of this discussion. Time to open it up again? > I think so. Particularly since there are pieces in JDT that aren't dependant on Java per say. In particular some of the runtime support, while helpful and needed for Java and Ant configurations (i.e JRE tab, and classpath), there are other tooling projects that could use this support with out necessarily having to have JDT or PDE installed. In particular, the XSL Tools incubator project would love to be able to use the launch configuration tabs that setup the JRE and Classpaths, with out having to have JDT installed. We need to be able to launch some java related XSL processors, but our users particularly don't care about having a full Java development environment included. The same thing is true for ANT lanuching. It isn't necessarily just a JDT specific feature. ANT is used as a general purpose batch processor, so it shouldn't necessarily depend on having JDT installed. I don't mind it being included as an optional install for the platform, but think it's time for some refactoring and separation. Having JDT and PDE in the eclipse project just helps emphasis what bug 239601 is saying. That Eclipse is still Java, which we all know it isn't.
I don't get how moving JDT/PDE elsewhere would magically make some functionalities become available any differently. This could happen today, and independently. As to physically moving JDT/PDE elsewhere, this isn't planned today. We are only moving Equinox out (to RT project). We may learn from this experience, and decide to extract more pieces in the future (maybe). Last, re-reading the thread, it seems that people are confusing the Eclipse project and the Eclipse platform... Remember that the platform is a portion of it (subproject) only.
(In reply to comment #43) > I don't get how moving JDT/PDE elsewhere would magically make some > functionalities become available any differently. This could happen today, and > independently. > > As to physically moving JDT/PDE elsewhere, this isn't planned today. We are > only moving Equinox out (to RT project). We may learn from this experience, and > decide to extract more pieces in the future (maybe). > > Last, re-reading the thread, it seems that people are confusing the Eclipse > project and the Eclipse platform... Remember that the platform is a portion of > it (subproject) only. > It comes down to consistency sake and preception. JDT and PDE are tooling pieces that build upon the platform. No different than CDT, PDT, EMF, or any number of other projects. Plus the migration would potentially help make it more of an issue than it appears to be now, to refactor some of the common resuable items, and make them truelly consumable with out JDT. JDT would just become another tooling item. I understand their is reluctance to do this, as to some it doesn't seem to give much benefit for the amount of work that would need to be done, but this is where we need put our various hats on, are we doing what is best both preception wise, and user community wise, or are we reluctant to do it because it's always been like this. The Eclipse project should be specifically for those pieces that are commonly used amongst the other projects and may be needed by all of the projects. JDT while a vital tool, is just that a tool built on top of the Platform. The same goes for PDE. It's a toold that is built on the platform framework to help make writing plugins easier.
Re: consistency As pointed out earlier in the thread, there are various takes at making eclipse.org consistent. Though moving JDT/PDE to Tools could help some, it may be argued differently. > Plus the migration would potentially help make it > more of an issue than it appears to be now, to refactor some of the common > resuable items, and make them truelly consumable with out JDT. JDT would > just become another tooling item. This is where I think you are mistaken. JDT is already just another tooling item. Pushing down JDT functionalities did already occur, pls check org.eclipse.ltk.*, or org.eclipse.text.* pieces. As I said already, the location of JDT project is orthogonal to the fact that some of its functionalities are pushed down. The refactoring will only occur if more resources help us build these generic pieces. Anybody is welcome to help us; and if we had many more committers from the tools project, then yes maybe we should think of relocating. Today, we share more with the platform, and thus a common organization/PMC is more effective for daily operations. This doesn't mean that platform is tied with JDT in term of plugin dependencies etc..., but rather it is just the same organization which is building both. Splitting this organization in 2 or more, means more time consumed in more meetings, etc... this is not free move. So in the end, our downloads are packaged by EPP, which blurs projects layout, i.e. no-one needs to know the project structures, which are for the most part implementation details. We are pretty happy with this implementation today, so why change it for the sake of it ? This feels quite disruptive to me, and honestly I would rather focus the team on delivering more in 3.5, than learn to work differently, with different teams/organizations/schedule, and thus deliver less as a result. And maybe we will learn from move of Equinox to RT, and realize it could be a good thing for JDT/PDE; but we do not know that yet.
Ian's and Bjorn's latest survey response brings up the issue of how Eclipse is still considered a java IDE. So this issue is still relevant, and I don't think it's helped by having JDT specifically underneath the Eclipse project. It perpetuates the unintentional link between Eclipse and Java IDE. http://eclipse-projects.blogspot.com/2008/09/your-opinions-re-foundation-marketing-7.html Maybe if JDT and PDE didn't want to move to Technology, they could become part of a Top Level, IDE project or something, that would include all sorts of IDEs?
There's was a lot of good discussion here, but I don't see any actionable items coming out of it, so I'd like to close to get off the active list. I know the topic still comes up from time to time, and I'm sure will for the life of Eclipse ... but, having this bugzilla open I don't think will be what results in any action. Thanks for the discussion though.
