Berin Loritsch wrote:
Doug Lea's Concurrency Utils are currently packaged in a jar file in the Excalibur event package. The manifest does not declare an extension name, version, implementation version or vendor id. This means that the jar will not function as an extension in environments that support extensions (e.g. Tomcat, Merlin, etc.). I think it is the only jar file that does not declare itself via its manifest - and I think we need to sort that out. My guess is that your probably the best person to handle sorting this one out.Stephen McConnell wrote:Berin Loritsch wrote:
Doug Lea's Concurrency UtilsNeed to get the manifest into something rationale before a release.Huh? Translate, please.
Also - what/where are the license details related to the Concurrency package?
Excalibur Event
More info needed from you - I'm feeling nervouse folowing recent changes and comments.
Info only comes to those who ask questions.
I was under the impression the the Event package was released but there is a WARNING file in the package that clearly states it is alpha and as such my fears about change are reduced. I still think we need to bump to 2.0. Also clearing up the Concurrency package will make me feel a lot more comfortable.
Excalibur Container (i.e. the lifecycle extensions)Need to migrate to Sandbox Lifecycle.
?? Why ??.
Because it was decided way back to move the lifecycle extension stuff to sandbox - which is what I did. In the migration I changed the package name to org.apache.avalon.lifecycle (also discussed way back). All that needs to be done is to update the imports in Fortress.
Look, we can easily incorporate the classes in Excalibur Container into Fortress for the time being, and blow away the Excalibur Container project. Or, even better we can merge Fortress overtop and call it Excalibur Container (Codename: Fortress). Either way, the interfaces are still present for a Merlin release. If Sandbox Lifecycle has the same exact interfaces (i.e. the package and interface are the same), then you can use that in Merlin and Fortress can include them for the release. No released product should depend on an unreleased or alpha project. All Sandbox code is unreleased, alpha, or beta.
Sandbox Lifecycle needs to be released as a precusor to Fortress release. Its just a matter of updating Fortress.
Fortress has a build and deployment depedency on AltRMI (at least in the current build file). If what you are saying is correct - then the AltRMI build depedency can be removed - however - it my understanding that the Instrumentation package has build depedencies and code dependecies on AltRMI.Excalibur Instrument**
-1
Problem until instrument provides plugable transpost or a RMI solution is in place.
Transport is pluggable. In fact no transport is even necessary.
Instument-client package communicates with an instrument manager using AltRMI. My impression is that this is hardwired into each - but*could* be made pluggable. As far as I understand this isn't the case today.Excalibur AltRMI
This is linked to Instrumentation if I understand correctly. It is also in under discussion as a incubator candidate. I don;t want tto get into a AltRMI depedency becauase of an Instrumentation dependenty. I think we need to sort the Instrumentation depedency first.
AltRMI is *optional*. If the user doesn't want it, they do not need it.
Does that aleviate fears?
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]
