> > - "commons"-style components. Even if we'll use explicit interfaces for
> > ...
>
> I'll need to review the commons project to adopt any
> standards that are in play there, but I don't see a
> problem. This brings up some things I'll need to know
The important ideas ( for this discussion ) are:
- bean-style components ( i.e. setter/getter instead of properties for
example - properties/xml/other config mechansims can be used via adapters)
- independent components as much as possible
- no "framework" interfaces ( like the Toolkit interfaces you define ).
The JasperToolkit is ok, but the "util" components should be independent
if possible ( for example a the javac tool that compiles java to class, it
is a toolkit component - but it should be implemented as a "bean", and
then have a Toolkit adapter - if we need to ).
> codebase. How should we handle packaging such stuff?
> I realize that the goal is to put generalized stuff
> into the commons project, how do we leverage that from
> Jasper? I.E. what exactly is the strategy for sharing
> the commons stuff? Oh never mind - I'll go sit down
> and do some reading.
I don't think anyone knows :-) And we don't have to solve
this problem right now - first we need to reorganize the
code and identify the componetns and utils, then we can worry
about commons and sharing ( or using ).
> > If you agree with starting with jasper4 ( because
> > it's more complex ), I
> > can start doing an initial split in components.
> >
>
> I agree with using Jasper 4 code as the basis. What
> I'd like is to first concentrate on making sure the
> base set of services proposed represents a suitable
> set of tools that are
Well, I have a feeling we have a small disagereement on this
one :-)
I would rather have a step-by-step process, with a number of
simple refactorings ( like moving some files in different
package ). It doesn't have to be right from the first time.
I think the direction is clear and most components - but
I doubt we can or should try to define the interfaces or
abstraction at this stage. This is a complex system
( more complex than tomcat itself IMHO ! ), and
I doubt a "waterfall" will work. ( I'm not a XP fanatic,
but some ideas are good ).
I don't want to start a XP or revolution/evolution or
any other debate like that - it's just that I would prefer
to start with some experiments and get some prototype
working before we even start discussing interfaces
and component details.
For example we can start with separating the runtime,
then separate the generator, then add the 1.1 runtime
and generator, and see how the code looks. ( in this or
another order ).
What do you think ? ( we can do that in parallel, in the
end what matters is to have more modularity ).
Costin
