> From: Berin Loritsch [mailto:[EMAIL PROTECTED]
>
> Step one: Decide what we are going to do with Instrument.
>
> Option A: Release instrument and instrument manager ASAP
> + Code is kept clean
> - We have alot to do
> Option B: Make dependencies on instrument soft by using
> reflection.
> + We can take our time with instrument
> - Reflection code is ugly.
Berin,
I'd like to add an
Option C: Rework the package structure for Instrument
and release it. Just move code around, nothing more.
+ We're not touching any logic, meaning that we'll be
doing a lot of search/replace but when it compiles
it is ready to go.
- We have a lot to do
By reworking package structure I mean moving the interfaces to:
org.apache.avalon.instrument
org.apache.avalon.framework.ext.instrument
org.apache.avalon.frameworkext.instrument
org.apache.avalon.frameworkx.instrument
org.apache.avalon.extensions.instrument
org.apache.avalon.ext.instrument
come.on.insert.your.idea.here
...
or whatever package name we come up with. There was strong opposition
to putting instrument in o.a.a.framework, but I think there was
some consensus that it should be interface/impl separated and
moved out of excalibur.
> Deciding factors:
> * Are the interfaces something we like? If so +1 on release
They are *good enough*. Since the instrument package will only be
one among many lifecycle extensions (of which some other will be
instrumentation as well), we don't have to be framework-perfect
with this one. Basically, the fact that they are used in the ECM
and Fortress now is reason enough to release.
> * How much work is involved in bringing it close enough
> for release? If too much -1.
I think a package renaming/refactoring is achievable (i.e. I volunteer
to do it). Anything else is too much. Any change in program logic is
way too much.
> * Are we comfortable with the reflection based approach
> to loosen the requirement for Instrument?
No. That is just another thing that can go wrong.
> * At a minimum Instrument and Instrument Manager need
> to be released.
Yes.
> Step two: Prepare all ECM depenedencies (and ECM/TestCase)
> for release.
>
> * All fully deprecated packages (like concurrent and
> collections) get moved into a "compat" project that
> exists strictly to provide a backwards compatibility
> layer. The original location gets nuked.
Yes. Will ECM move into the compat project?
> Step three: Prepare all Fortress dependencies (and Fortress/XFC)
> for release.
>
> * Decide if we want to deprecate Pool (only used in ECM)
Iff ECM is deprecated, deprecate Pool. (Otherwise not.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
