search

mdenet / educationplatform

Eclipse Public License 2.0
2 stars 3 forks source link

Tool configuration should contain information for discoverability #77

Closed barnettwilliam closed 1 year ago

barnettwilliam commented 1 year ago

A review comment from the MODELS paper suggested the tool configuration should contain extra information for discoverability when there are multiple tool providers e.g. version, date, author, contact information.

jgsuess commented 1 year ago

Hi! Sorry to butt in, but it seems you are on a road to reinvent the wheel. Eclipse went down this path with Eclipse 1.0, only to reset and replace infrastructure with OSGi. Please have a serious look at Eclipse RAP. It will allow you to dual use substantial amounts of infrastructure. If you do not like this, and want to focus on JS, please consider EMF Cloud. You will not have the resources to sustain the growth and cannot be an expert in all the facilities.

As for the feature request, in Eclipse P2 and marketplace offer this function, which will also be available in RAP.

szschaler commented 1 year ago

@jgsuess, you make a valid point. We did look at RAP, but initially didn't go down that route as I'm not sure we want to stay in the EMF world only in the long term. emf.cloud is similar, I guess.

I was interested in seeing that things like GLSP have broadened their backends quite significantly to cover non-EMF technologies, too. I'm beginning to think that we may need to look at this in more detail at some point soon. A similar consideration holds for LIonWeb, which perhaps is the most promising thing here. I'm hoping to learn more about this at the education platform workshop at MODELS.

At this point, we're trying to build a basic proof of concept for the education platform and learn about architectural requirements so that we can get a better basis for assessing these different alternatives for best fit. The purpose of this particular issue here is to keep track of suggestions, not to say that we will definitely focus on this.

jgsuess commented 1 year ago

Ah, I mistook this as a request to implement an enhancement feature. I clearly did not understand the way you track tickets. As for the use of RAP I can understand that the front-end interface is dated. However, I feel it is important to point out that Eclipse is not equal EMF. RAP allows the reuse of all of Epsilon, which via EMC is not EMF, but really much wider in span. So RAP equals Java+, if you want. If you count in Dynamic Modules (OSGi blueprint) and remote services, the power is quite astounding. Combined with Che and CDO this would be the vehicle I would build on.

With regard to LionWeb I would not invest at this time, as I would see maturity a way down the road and cannot see the substantial novelty.

If you are interested, I have a blueprint for an extensible system for online modeling based on the RAP set. I am happy to present this to you. By extensible I mean that there are sets of components that can be incrementally added to provide growing sets of requirements.

From my perspective the issue with PoCs is that they often fall prey to their own initial success to die as the required feature space proliferates. I hope that you are really ready to to throw this codebase here away, because the non-functional properties that determine reuse are usually very hard to retrofit. This issue may be the canary in the coal-mine: The reviewers assume that this system is a long-lived product open to adding features and living a full service life.

jgsuess commented 1 year ago

With regard to GLSP I recommend building on ELK. ELK can back GLSP and is multi-language and multi-target. I see great promise in ELK.