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