Stephen McConnell wrote:
Leo Simons wrote:
I am prepared to take on Release Manager if needed - but I'll probably
be a PITA. So if someone else wants to take on the job - please
volunteer now. If someone else does volunteer - well - I'll still be a
PITA.
I thought I did volunteer. If it wasn't clear, I do.
Don't be too much of a PITA though.
Things on our plate
===================
- Phoenix 4.1 (dependendent packages refactored recently, many
features that didn't go into 4.0 now making it in IIUC)
- Fortress 1.0 (first release obviously)
- Framework 4.1.4 (javadoc changes, the wrapper classes, some
additions to ConfigurationUtil, more tests I believe)
I have a problem with 4.1.4 in its current state. My experience with the
wrapper classes was less than positive and resulting in my forking the
particular classes into Assembly to get things working properly. I would
prefer that we pass on a framework release and instead - put the wrapper
classes into Excalibur Component or a new package like Excalibur Legacy.
I don't want too see the crown jewels going out with stuff I know is
incomplete and insufficiently tested.
What changes needed to be done?
BTW, the Wrapper classes did start in Container, and then someone moved
them in Framework while stripping out the proxy management.
We can still manage them in the Framework repository, but we can move
them to a separate JAR that has a dependency on CGLIB. That way folks
who want to use the CGLIB based proxy generation can use the appropriate
wrappers with full functionality.
- Cornerstone (this badly needs a release I guess)
Yes and no.
Cornerstone (complete) sucks big time.
The only rationale release approach is to break these down into
individual components. I've done this for the following:
cornerstone-datasources-1.0.jar
cornerstone-connection-1.0.jar
cornerstone-masterstore-1.0.jar
cornerstone-scheduler-1.0.jar
cornerstone-sockets-1.0.jar
cornerstone-threads-1.0.jar
None of the above have a dist target so more work is needed. In addition
- the release of these components can wait until after an Excalibur
general release (because they are tied to at least Excalibur Threads 1.1
which is a release candidate + other Excalibur packages).
Right.
Component <-- used depreciated collections package
Immediately upgrade and release.
Container: <-- moved to Sandbox, Fortress need to be synchronized
Incorporate the interfaces in to Fortress and drop it.
Event: released: 1.0.1 candidate 2.0 <-- but Berin needs to provide status
It should be ready. I've tested it myself. Only need some changes to
the Status file.
Logger: current 1.1, needs to be bumped to 1.2 with recent additions
Ok.
Meta: moved to commons, Fortress updates needed.
Fortress (the released version) does not use it. It is unlikely that
it will ever get to that point.
Testcase: ???
It is used to test components. It currently uses ECM. After Fortress
is released and made the preferable container we need to migrate.
Util: ???
Currently alpha/beta. Needs to be merged into existing projects.
XMLUtil: apparent-candidate - has dependency on deprecated packages
(e.g. collection - but not code ref) more info needed
If no code references the deprecated collection, then remove the
artificial dependency. It's not hard.
- Framework 4.1.4
-1
(see above notes and Excalibur L:egacy allternative)
See my comments.
- all excalibur components used in fortress
See prior email - main issue is Instrumentation which needs to provide a
RMI solution.
Then write it. IMO it does not. The manager uses a pluggable
transport. That means it can use AltRMI, nothing (i.e. all in
the same JRE), or any pluggable transport. RMI has some
serious issues with insecure failover. I personally would never
use it for Instrument.
- Fortress 1.0
After excalibur release.
After the dependencies have been released. We do not need to wait
for *all* the dependencies to have been released.
- remaining excalibur components 1.0, 1.1, 1.2 releases
After excalibur release.
Huh? Release excalibur components after excalibur release?
That makes no sense. It is redundant.
Fortress itself is nearing the quality needed for a 1.0 release, but I
don't know if that is true for all its dependencies. I'm a bit hung up
on "remaining excalibur components 1.0, 1.1, 1.2 releases"...Steve,
how confident are you wrt your product table accuracy? Can we base
decisions of that? Also, how are things going with cornerstone
refactoring? Have you got a time schedule for that in mind?
Product table is already out of date. Automation is an absolute
necessity here. I would like to propose that we adopt Maven as the build
management framework across all of our projects. This will all the
seperation of the CVS build from published releases in a consistent
manner. I have been working with Mavan and am reasonably happy with the
resolutions on the management side - no so happy with the doc generation
side but that's a secondary concern. I'm confident that Nicola can
deliver the solutions we need there. I'm also concerned about the James
process - they are talking about moving over to Maven and the bottom
line is that they (at the end of the day) will need commensurate support
from ourselves.
+10. I agree. Lets get Maven.
As to the question - Excalibur - more info needed on Event from Berin
(feeling a little shaken by recent changes even though I think they are
positive). Several candidates release candidates detailed above.
Cornerstone should wait for a subsequent stage - but not long. Both
Cocoon and James have dependencies on non-release Cornerstone code. Even
worse James appears to be using some special variant that I have not
figured out (but things are moving towards a manageable synchronization
with Avalon). Bottom line - Cornerstone sucks big time in its current
form - but there is hope - with separation we can build a series of
manageable components. But it's a post Excalibur release concern.
Again, info only comes to those who ask. What do you feel shaken about?
The demos have been in use for ages, and they are definately good for
release.
Disagree - the have been changes and it really only reflects nothing
more that a test case. What is really needed is a proper component test
case.
A *Demo* is a demo. They demonstrate the fact that Phoenix works, and
provide a way of demonstrating how to work with it. It is ready for
a release when the docs are updated.
I dunno about sevak, but I have a hunch a release is desired by more
than a few of our users.
I'm not happy with Servak - would like to se more "community" discussion
on this.
Let's just get started on stuff we know we can do.
Let's do it!
============
Have we got the time, energy and spirit to stick our heads together
and get some overdue products out? I think we do.
Me too - but one step at a time - and lets do it in a manageble process.
1. Get in Maven acrosss the board.
Isn't there a branch for that?
2. Sequence out process Logkit --> Framework --> Excalibur -->
Cornerstone/Fortress --> Merlin/Phoenix
You know, it may be better to do it in this fashion:
LogKit
Excalibur (ECM dependencies)
ECM
Framework
Excalibur (Fortress dependencies)
Fortress
Excalibur (all remaining)
Cornerstone
Phoenix
Merlin
Why?
LogKit is immediately ready. Everything works with the last released
Framework, and there are some things that need to be taken care of with
Framework. ECM needs to be upgraded to remove all fear and doubt from
the Cocoon team about the Component interface. By that time, Framework
should be squared away. Fortress is ready, but any remaining fears will
be taken care of by then. Cornerstone needs an ALPHA release at the
very least. Phoenix needs a release after all the migration of packages
and everything. And then we can all focus on getting Merlin to a good
state and release it as a community effort.
Also, this approach allows us to have different people taking ownership
for the different projects for the immediate release. Each release
requires Mavenizing and updating the Status, and any possible
documentation changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
