Re: [jwt-dev] refactoring

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hi Stephane,

Thanks for your balanced views :)

You're right, not imposing too much dependencies on extenders is also 
paramount.

Regards,
Marc

Stéphane Drapeau a écrit :
> 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
> > >       
> >