Berin Loritsch wrote:
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.
Great.
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?
I would like to suggest that we leave the framework at 4.1.3 - move the wrapper classes into a seperate package - Excalibur Legacy - and sort that out possibly using the CGLIB stuff.
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 packageImmediately upgrade and release.
Yep.
Container: <-- moved to Sandbox, Fortress need to be synchronizedIncorporate the interfaces in to Fortress and drop it.
I'll take care of this: 1. update the build file to reference the avalon-lifecycle-1.0.jar file. 2. update the imports 3. remove the container project
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.
OK
Logger: current 1.1, needs to be bumped to 1.2 with recent additionsOk.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.
OK - so I can safely go ahead and remove Excalibur Meta.
Testcase: ???It is used to test components. It currently uses ECM. After Fortress is released and made the preferable container we need to migrate.
OK
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 neededIf 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.
Eeither Instrument Manager / Client moves to pluggable transport, or we neeed an AltRMI release. Seems to me that our assumptions concerning the Instrumentation suite and AltRMI depedencies are different. I would be good to get some clarification on this.
- Fortress 1.0After excalibur release.After the dependencies have been released. We do not need to wait for *all* the dependencies to have been released.
Yes - I agree.
- remaining excalibur components 1.0, 1.1, 1.2 releasesAfter excalibur release.Huh? Release excalibur components after excalibur release? That makes no sense. It is redundant.
It was late. :-)
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?
See prev. email. (don't worry - the feeling is disapating) :-)
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.
Disagree.
It is used primarily for validation - tends to change when new things are added - is not something we should be releasing as a product - people should not be using it as a reusable component.
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.
Sounds good - two caviats -
* I prefer we stay with 4.1.3 anbd seperate out the wrappers to a seperate project
* Cornerston as a collection should not be released - only specific components should be released
Cheers, Steve.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
