|Did someone call for CPAN? ;) Honestly, to me this discussion is about having something like CPAN for Eclipse plugins. I agree with Konstantin that these things don't have to be part of the platform. I'm not sure if IP is a concern here, but it all sounds like Orbit for external contributions to Eclipse. Developed and maintained externally but made accessible by cean.eclipse.org - the "comprehensive eclipse archive network". Combined with a customizable CBI build for your own IDE configuration or target platforms, and you are good to go.|
Nice idea, though, I'm not sure how this solves the general issues with the IDE we currently see.
I don’t think we need another container project or a monolithic “IDE” project to hold features that don’t find place in existing projects. These days, it is a lot easier to create a micro-project under say Tools or Technology than it used to be. It isn’t a matter of a few clicks, like it should be, but it is a lot better than what it used to be and you meet a lot less resistance along the way.
I am personally of the opinion that it isn’t good to keep growing the size of the platform. The platform should stay small to be suitable to a wide variety of usecases and be mainly concerned with facilitating work happening elsewhere. We do not need to stuff more into the platform to improve Eclipse IDE.
Maybe this is a case where the Eclipse IDE Project makes sense. Then we wouldn't be having this discussion and the Eclipse IDE would have it's image viewer. Mind you, we still might need changes to the Platform to enable it, but they would be in the right direction of making the Platform more pluggable. BTW, we have a lot of functionality in the CDT that really belongs in the Platform, In Our Humble Opinion. We just found it easier (back in the dark times), to just implement it close to home. I wonder how many other projects have done the same. I'd bet we could build up an IDE project with a lot of functionality day one. But I'd like to hear from Platform leadership team first. Does the Platform want to open up more in this direction? Or would they prefer we find a different home for these common features. Having been involved in the discussion and having made several attempts to facilitate a solution, I see the image viewer story as most illustrative of what happens when a contributor is unwilling to be flexible. Various options were offered that would have led to an image view in Eclipse IDE packages, but it was either in platform or nowhere, so in the end we have no image viewer in Eclipse IDE to date. Projects will reject features for various reasons. We need to be ready to find alternate accommodations and contributors need to be flexible enough to work with such accommodations. We are certainly better prepared for this today than six years ago. EMO is more willing than before to accept micro-projects and improvements in common infrastructure (such as the common build system) make it a lot less costly to have a project around a single feature, if such thing is necessary. BTW, to be fair fair about the image viewer story, the rejection happened 6 years ago near the end of the dark times… I do not make purchasing/consortium participation decisions on behalf of NVIDIA. I am an input to such decisions made by my superiors. What I am writing to this list is my personal opinion. At NVIDIA, I am working on "Nsight Eclipse Edition" - that is an Eclipse-based IDE for CUDA developers. Before NVIDIA I was working on other Eclipse-based IDEs (paid or not). I find it ironic that it is possible to get GSoC student work on adding generics to the JFace into the main repo, while experienced developer's contribution of image viewer (I mentioned the bug number in my original letter) was rejected with prejudice. I personally had to implement similar viewer more then once for different projects. I am looking at this WG from a point of view "what would we get for participation" - as this is the question I need to answer if I raise this topic with my manager. Personally, I believe there is a need for a more open collaboration place for adopters to work on what they see as a better Eclipse Platform for IDEs. Currently adopters are forced to ship their own forks - so I wonder if this project could become some sort of unified fork that better suits the needs of IDEs. One thing I would like to point out is that for some teams it might be easier to contribute developer time than money as those decisions are made on different levels and development teams more readily recognize the value of collaboration. Before playing this back-and-forth: What's your position on the WG - or funding developers in general that work on, say, JDT, CDT or EMF? Are you looking at this from an investors view point or more from a developer's view point. Not sure what the role of a lead architect at nvidia is. In any case, from your writing I get the impression that you don't see any good way to contribute to the existing platform (no critic in here). If that's true, what can we do? Will all tries to modernize the Eclipse IDE fail? So let's imagine some company is really bothered by such issues and joins this working group (note the hefty price tag of $120k/year). The price tags are just a proposal and haven't been validated currently. But I think you are referring to the highest one which includes steering committee membership. My understanding is that non-steering participation does not give any voting rights. 1. Are there any guarantees somebody would actually implement these enhancements? What may prevent these funds from being spent on EMF enhancements if they get more votes? I think it will be important to make that the working group operates open and transparent. Therefore, the whole funding and wishlist including voting will be visible. That allows to make a clear judgment on what impact specific funding will make. This means that either companies invested in CDT or EMF will not get what they joined for. 2. What would be a timeframe before implementation starts? Would there be a committed delivery schedule? I expect this to happen as part of the work item analysis and upon assignment of such items to the implementation partner. How will this happen? A lot of time will be spent defining the "wish list", then RFPs will be sent out, prospecting "implementation partners" will submit proposals, voting on proposals will commence, so on? Sounds like years will pass without any output. 3. How could such a general-purpose text editor avoid sharing the fate of Bug 155323? It's an important role of the working group steering committee to find solutions to such problems. I could imagine that if no project is willing to accept a feature such as a general purpose image viewer or text file editor, the work is brought in as a new project and made available as part of the release train and in the downloadable packages. I do not think these two items can happen without at least some platform changes (I am only familiar with E3 - and at least hooks will have to be put there). This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
ide-dev mailing listide-dev@xxxxxxxxxxx