Re: [jwt-dev] refactoring

[Stéphane Drapeau <stdrapeau@xxxxxxxxx>]

Hi guys,

I think it's a good idea to reduce the number of plugins. We did it
for the SCA Tools project.
However, from my point of view, it is not a good idea to merge the
model and edit code.
The plugin containing the model can easily be used in standalone mode,
and, users can only need this plugin as a starting point for other
dvlpts, like for model transformation.

Best regards,

Stephane Drapeau
Obeo

2010/5/5 Marc Dutoo <marc.dutoo@xxxxxxxxxxx>:
> 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
>
>