Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] refactoring

Hi Chris

I'd like the opinion of Eclipse experts like Stephane :)

But IMO having many plugins is not a problem, it's a solution (to application architecture, cross dependencies etc.).

What do you say about that : the problem you describe is not about how plugins are separated, but about easing the build of a release (what about writing a script that increments the version number of all sub-plugins ?), about knowing which plugins are obsolete and unmaintained (what about putting them in a "trash" place in the CVS, or having another build cycle for them ?).

In this context, our plugins can be classified this way :
* 1. WE build required plugins : all metamodel (and converter), we, we-conf (aspects), views, transformations plugins - except "dumb" samples * 2. WE optional, sample and prototype plugins : transfo-test, samples (including views, conf "dumb" samples, stub transfo), monitoring / runtime WorkflowService APIs * 3. other projects not directly needed : runtime "only" APIs, swing apps...

1. should be well defined, always be perfectly managed and maintained, and built in every build. I maintain that 1. is well architectured, not hard to delve in, and pretty clear. 2. should be managed by the person who did it, or another one that takes responsibility.
3. is not in any build, but only for specific uses.

Nowadays, JWT is build and made available as a single feature in the download site. I believe 2. should be put in a separate feature, maybe jwt-samples. The idea is that 1. is rock solid and well defined, and not crippled by possibly obsolete or "dumb" aspect or transfo samples. And that 2. provides everything else that someone could be interested in, like samples and prototypes. (Actually, what goes in 2. vs 1. should be thought about : should Logging go in 2. because it is a sample, or in 1. because it is a valuable feature ?) And if 2. doesn't build because of a single project, we could even throw it out for the time being whitout afterthought.

In any way, I'm not for crippling the architecture in order to solve productivity problems.

And to answer your question, the model may be used alone, at runtime. And I've written code that does that :)

Regards,
Marc (shocked but not suprised, and open to discuss it on Skype or on the phone ;)

Christian Saad a écrit :
Hi guys,

since Hudson is currently on vacation, I'm writing this mail because I'd like to hear your opinions about an issue which is bugging me for quite some time now. I'm aware that it's quite a controversial subject, so of course I don't expect that you have the same perception here :)

Doing some maintenance work on JWT in the last weeks and months, I currently have ~60 (!) JWT plugins in my workspace. As you know of course most of them have been added at one time or the other to provide a new feature or extension of an existing one and have been categorized accordingly which at least provides some sort of overview. However, in my opinion we have reached a critical amount which makes it very hard to maintain (technical&documentation-wise) all existing plugins and which makes this maintainance also very error-prone. In addition I think it's very confusing for new users and/or developers who stumble upon such a huge repository of potentially (un)interesting plugins and I fear that some may not be willing or able to invest the time to find what they would need and move on.

Therefore I would like to suggest to think about some possibilities for refactoring, i.e. deciding where a package-wise distinction inside a single plugin would be sufficient and preferrable to completely separate plugins. Given our limited resources, I would take a really pragmatic approach taking into account our personal experiences over the last years, e.g. even go so far ( yes, the final frontier ;) ) as to say why not merge model&edit code (in my experience in "real life" the model is never used alone, and even if it is, the disadvantage would only be a few unneccessary dependencies to emf edit but chances are that it's present in the target environment anyway).

Ok, so I hope you're not too completely shocked by my reformist ideas (alas I haven't nailed them yet to the door of the university) and I would very much like to hear if you have the same perception or if you don't see a problem at all or if you have different ideas about solutions.

Regards,
Chris
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev


Back to the top