You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@citi-us.com> on 2003/02/27 18:55:47 UTC
[POA] Excalibur Releases
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.
Deciding factors:
* Are the interfaces something we like? If so +1 on release
* How much work is involved in bringing it close enough
for release? If too much -1.
* Are we comfortable with the reflection based approach
to loosen the requirement for Instrument?
* At a minimum Instrument and Instrument Manager need
to be released.
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.
Step three: Prepare all Fortress dependencies (and Fortress/XFC)
for release.
* Decide if we want to deprecate Pool (only used in ECM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> Step one: Decide what we are going to do with Instrument.
>
> -----------------------------------------------------------
> <snip summary/>
>
> I don't have a very strong opinion. I will support whatever option has
> the largest majority, as long as it something which will result in a
> release of ECM and fortress within an acceptable timeframe :D
>
> IMHO:
>
> - yes, the interfaces are good enough,
Then let's look at a release.
> - yes, the dependency on altrmi for implementation is ugly but that
> altrmi is not yet ready for release IIUC so any option (release as
> experimental, only release interfaces, don't release) is a compromise,
Separate out the AltRMI connector into a separate JAR would work if we
go for purity. Otherwise, we can warn the user if they use it that it
is an "experimental feature" in the logs. I think that will be good
enough.
> - no, introducing yet another package location is not a good idea (ie no
> org.apache.avalon.ext or something like that please, we already have
> "excalibur" and "cornerstone" which are nothing more than "meta package
> names" that add no meaning besides providing grouping, we don't need yet
> another grouping),
I agree on this.
> - sure, an alternative reflection-based or pluggable or lifecycle
> extension-based mechanism for soft dependency on instrument is perfectly
> acceptable to me, if it can be implemented quickly
I just did it for the InformixDataSource in the datasource project.
It works ok.
>
> Why do we need to release XFC now? Haven't looked at it yet.
>
We need to look at it. It provides the tools to upgrade an existing
system from ECM to Fortress. We at least should release that part
along with Fortress.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Step one: Decide what we are going to do with Instrument.
-----------------------------------------------------------
<snip summary/>
I don't have a very strong opinion. I will support whatever option has
the largest majority, as long as it something which will result in a
release of ECM and fortress within an acceptable timeframe :D
IMHO:
- yes, the interfaces are good enough,
- yes, the dependency on altrmi for implementation is ugly but that
altrmi is not yet ready for release IIUC so any option (release as
experimental, only release interfaces, don't release) is a compromise,
- no, introducing yet another package location is not a good idea (ie no
org.apache.avalon.ext or something like that please, we already have
"excalibur" and "cornerstone" which are nothing more than "meta package
names" that add no meaning besides providing grouping, we don't need yet
another grouping),
- granted, instrumentation docs have some relatively big holes that
would preferably be fixed, but this is not a release blocker,
- sure, an alternative reflection-based or pluggable or lifecycle
extension-based mechanism for soft dependency on instrument is perfectly
acceptable to me, if it can be implemented quickly
> 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.
+0 providing integrity of build system and gump build is maintained. I
for one don't feel like doing more moving of stuff.
I haven't looked at the testcase or its deps yet but I think the other
stuff is good to go.
We need to decide on how we want to actually distribute binaries (a
source and a binary dist, or a combined dist, or a source dist and a
jar, or just a jar, or another option). Probably best is to keep
following the pattern at
http://www.apache.org/dist/avalon/excalibur/components/ with a single
binary distribution containing docs and a zip with sourcefiles, and then
provide the jars in any asf repository as well when that gets off the
ground, ie it is of later concern.
> Step three: Prepare all Fortress dependencies (and Fortress/XFC)
> for release.
------------------------------------------------------------------
think we're mostly good to go wrt fortress and deps. Sure, the code
might not be perfect wrt checkstyle or unused imports, but those things
are not blockers :D
Why do we need to release XFC now? Haven't looked at it yet.
> * Decide if we want to deprecate Pool (only used in ECM)
pool is released @ http://www.apache.org/dist/avalon/excalibur/latest/
so I think we should only deprecate _after_ release in line with the
general policy discussed earlier wrt stuff like ECM, ie: no.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [POA] Excalibur Releases
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > pool is used by excalibur-thread.
> > excalibur-thread is used all over the place.
> > what is the implication here?
> The Doug Lea utilities have a better and more
> flexible thread pooling code. We may want to
> migrate toward that.
Yes. Operative word: "migrate." :-) Which will position you well for JSR
166.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> 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.
>>
>> Step three: Prepare all Fortress dependencies (and Fortress/XFC)
>> for release.
>>
>> * Decide if we want to deprecate Pool (only used in ECM)
>
>
>
> pool is used by excalibur-thread.
> excalibur-thread is used all over the place.
> what is the implication here?
Like I said "decide". That said, Excalibur Thread does have
some problems when the pool implementation truly blocks. It
hits a deadlock which is bad. The pool implementation that
it uses has an issue where the blocking breaks and then creates
a new instance even if it is above the maximum.
The Doug Lea utilities have a better and more flexible thread
pooling code. We may want to migrate toward that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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.
>
> Step three: Prepare all Fortress dependencies (and Fortress/XFC)
> for release.
>
> * Decide if we want to deprecate Pool (only used in ECM)
pool is used by excalibur-thread.
excalibur-thread is used all over the place.
what is the implication here?
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> 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
+1 on releasing instrument as is.
ok on instrument manager providing we seperate out the jar files (1 for
the manager, 1 for the AltRMI classes)
instrument client should be packaged as part of the AltRMI monitor
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> I do think that client needs to be repackaged as part of the AltRMI
>> monitori.
>
>
> can you explain how/what/why, the impact this can/should have on our
> release process, how much time/effort it would take, and who's going to
> do that?
>
> IIRC fortress and ecm don't depend on the client so it shouldn't
> actually impact the releases of those. Right?
Right. However the users won't really be able to enjoy the benefits
of Instrument without the client.
We can wait until after Fortress is released to get the Client
released.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> I do think that client needs to be repackaged as part of the AltRMI
>> monitori.
>
>
> can you explain how/what/why, the impact this can/should have
> on our release process, how much time/effort it would take, and
> who's going to do that?
What
----
Most of the discussion on the instrumentation suite separates things out
such that there is a suggestion that there are three packages:
instrument, the manager, and the client. This is incorrect. There are
three packages - but they don't correspond to the current CVS structure.
The three packages are:
1. the instrument package
2. the manager package
3. the AltRMI monitor package
The instrument package corresponds to the current excalibur instrument
package. No change needed. The manager package corresponds to the
current manager package with the exception of the two AltRMI transport
related classes (these correspond to the server side of the AltRMI
monitoring solution and should be repackaged under something like
o.a.e.instrument.altrim.server). The third package is the client side of
the AltRMI monitor solution and should be repackaged under
o.a.e.instrument.altrim.client.
How
---
Some package renaming and some reshuffling as described above.
Why
---
Because if we don't do things we end up with:
(a) inability to build with AltRMI
(b) an inconsistent structural breakdown (inconsistent
because of the non-separation of AltRMI as a monitoring
implementation
(c) confusion introduced by package naming that carries
implications that are incorrect (e.g. client is not
a generic client - its an AltRMI client)
Time and Effort
---------------
Depends on who helps out and the background they have on the
instrumentation package. Leo has already volunteered to help
out on this - I can help - but as you probably know, my knowledge
of the instrumentation package is limited (the above comments
are based simply on a review of the current code). My guess is
tha this can happen quickly but I would like to confirm that
with Leo and Leif first of all.
>
> IIRC fortress and ecm don't depend on the client so it shouldn't
> actually impact the releases of those. Right?
Right technically, wrong operationally. If we release the manager
we implicitly introducing people to the transport layer and client.
While these last two elements can be made available in alpha status
we are still creating a context in which people will use these things
and we will need to deal with the flack when these things have to
be changed. So let's get it clean up now and minimize the downside.
Cheers, Steve.
>
> cheers,
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> I do think that client needs to be repackaged as part of the AltRMI
> monitori.
can you explain how/what/why, the impact this can/should have on our
release process, how much time/effort it would take, and who's going to
do that?
IIRC fortress and ecm don't depend on the client so it shouldn't
actually impact the releases of those. Right?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [POA] Excalibur Releases
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Berin Loritsch [mailto:bloritsch@citi-us.com]
>>
>>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.
>
>
I don't mind if instrument stays under the excalibur package.
I do think that client needs to be repackaged as part of the AltRMI
monitori.
>> * 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.
>
>
Can we take a minimum change approach here ?
I.e. keep in it excalibut but clean up the seperation between manager
and monitor (i.e. the manager AltRMI extension and the instrument client)?
I think this is achievable and will lead to less confusing in the future.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [POA] Excalibur Releases
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
>
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org