[
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
