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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
