Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] 2019-12: The Eclipse Eierlegende Wollmilchsau


Comments below.

On 10.12.2019 10:05, Mickael Istria wrote:
Hi Ed,

Thanks for bringing this.
I was actually waiting for the best opportunity to start discussing a very related topic, but from a maintenance POV not a user one, and I think this is a good one:
*What is the value and quality of SimRel? Is it worth it's cost?*

As you're highlighting, the actual SimRel doesn't result in good "common" toolset. Installing whole SimRel leads to a failing or non-usable IDE. So is this non-functional thing worth it?
I'd say yes, because not doing this just moves the problems from being centrally noticed to being even more widely distributed instead.
EPP packages behave fine, they're tested and delivered to the target audience in a good enough shape. Marketplace is now the main and best entry-point for many features and fits much better into typical user workflows
Stay tuned for my next email about marketplace. :-P

Does SimRel bring anything really good beyond EPP packages?
I think so.   But I also suspect we have accumulated much baggage on the train...
Anything good enough to be worth the maintenance effort?
In the end we still need a train-like thing for EPP.  We could put less on the train.  And I think the cost is not so much maintaining the train but rather producing the things on the train.   I feel that most train-level things could be more stream-lined and further automated.  In principle, why could we build staging packages daily?  What all needs to be done that can't be fully automated?
Is it an interesting exercise to expect all Eclipse Platform plugins in the Eclipse Foundation to work properly together as the same application?
This is a fundamental aspect of traditional Eclipse platform stack of technology.  That you can add features as needed for the development purposes.
Who is actually likely to invest in making their specific plugins fit better with all other Eclipse plugins if the typical audience doesn't care?
I would not assume that the end users don't care.   Don't most of us and our end-users add our favorite tools to some base installation?

My opinion on this is that SimRel is nowadays a giant hard to maintain inconsistent effort, and that EPP and Marketplace have superseded it and made it not so profitable anymore.
I don't think it's so hard to maintain.  It's the content that's the major effort.  But if we don't bother to look at how well content will integrate and interoperate, the problem won't go away.  It's more likely to get worse, and as far as the user is concerned all that is "Eclipse's fault".
I would suggest that we just abandon SimRel in favor of EPP building packages and a p2 repository containing all the dependencies for these packages; and other plugins should just target Marketplace as entry point, until they reach a good enough quality and value to get into some EPP package.
Personally I think that's a bad idea.   The train repo is after all the input to the EPP packaging build, so at best we could reduce the train to what's actually used by the packages.   Or so it seems to me anyway.


cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top