Looks to me like there is a concrete packaging proposal from Leo > What _can_ be done quickly: > - define and build avalonapi-4.0b.jar which has the same role > as "avalon-core.jar" above, but does not have the interface > separated from implementation yet. +1 > - Cocoon2 beta ;) Don't know what Cocoon2 is so I'll refrain from putting up an opinion on this. > - start on phoenix-4.0b.jar, which has the same role as > "phoenix-core.jar" above, and for now includes > org.apache.avalon.atlantis as it isn't stable enough > yet. +1 But can you clarify - is it a question of stability or a question of validation ? > - start on excalibur-3.3a.jar, which contains the code not > stable enough for avalonapi-4.0b.jar yet. +1 Cheers, Steve.
> >1) a well-documented specification (interfaces; contracts) > >2) a (reference) implementation that does nothing more > >than implement that specification > > what specification? We don't have one. Exactly! ;) (<-- meaning: we probably do need one) > Your model only works if we consider Avalon as just an application server. > As soon as this assumption breakes the model falls down. I don't make that > assumption (and I would argue against it) so ... ? Why? (really, why? I fail to see it...) The model I'm talking about is mostly quite similar to what is done with java.* and javax.*, at least with newer code like JMX or Connector. As is see it, if you want to use nothing more than the core framework code (say the lifecycle stuff and everything related to that), you do a "build core-dist" or something... i.e. you can have a J2ME, J2SE and a J2EE which have code living in the same namespaces - you can also have a couple of avalon distro's/.jars for different use-cases. Let's tinker about this a little bit... BASIC FILES IN DAILY USE ------------------------ avalonapi.jar | | This is the complete tree that specification implementors | have to provide an implementation for. Some packages are | marked "[optional]" to indicate they're an optional part of | the spec. These could also be in avalon-spec-ext-XXX.jars | or something. | I've just picked some stuff randomly here. | |--- org.apache.avalon.* with |--- org.apache.avalon.atlantis.* [optional] |--- org.apache.avalon.camelot.* [optional] \--- org.apache.avalon.collections.* [optional] phoenix.jar | \ Complete implementation of avalon-spec.jar. phoenix-core.jar | \ Implementing the non-optional parts of avalon-spec.jar phoenix-atlantis.jar | | Implementing the atlantis part of avalon-spec.jar, \ to be used as an add-on for phoenix-core.jar phoenix-camelot.jar | | Implementing the camelot part of avalon-spec.jar, \ to be used as an add-on for phoenix-core.jar phoenix-collectons.jar | | Implementing the atlantis part of avalon-spec.jar, \ to be used as an add-on for phoenix-core.jar CONVENIENCE JARS FOR COMMON USE-CASES ------------------------------------- avalon-core.jar | | This is a .jar to be used in places where all you need is the | core framework code to simplify working with applications. I've | included the RI of the spec here to reduce the number of .jars | from 2 to 1. | | (SPECIFICATION) | |--- org.apache.avalon.lifecycle.* |--- org.apache.avalon.context.* |--- org.apache.avalon.configuration.* |--- org.apache.avalon.parameters.* |--- org.apache.avalon.component.* |--- org.apache.avalon.log.* |--- org.apache.avalon.thread.* (perhaps) |--- (similar stuff) | | (IMPLEMENTATION) | |--- org.apache.phoenix.lifecycle.* |--- org.apache.phoenix.context.* |--- org.apache.phoenix.configuration.* |--- org.apache.phoenix.parameters.* |--- org.apache.phoenix.component.* |--- org.apache.phoenix.log.* |--- org.apache.phoenix.thread.* (perhaps) \--- (similar stuff) avalon-complete.jar | | This convenience .jar contains all the Avalon and Phoenix code. | All you have to do is run it and the atlantis impl fires up and | runs. You can use RMI to talk to the JMX adaptor, to provide it | with the location of apps you wish to deploy. | | So you could have this .jar in the lib/ of say JAMES (together | with logkit.jar and apache-jmx.jar), and have a small bootstrap | class that tells Phoenix where to find the JAMES.sar and deploy | it. | |--- org.apache.avalon.* \--- org.apache.phoenix.* EXTENSIONS / ADD-ONS / EXTERNALS -------------------------------- apache-jmx.jar | | This contains the org.apache.jmx.* code, which is a requirment for \ _Phoenix_ if you wish to use JMX. logkit.jar | | This contains the org.apache.log.* code, which is likely to be a | requirment for almost every _Phoenix_ app because it is needed for | logging. Another Avalon implementation may implement logging | very differently. | The assumption here is that most of the details of logging are | something for the implementation to worry about; most of the | logging settings don't need to be modifiable/known to the apps | running on top of Avalon. This might be entirely wrong. In that | case, either org.apache.log.* should contain more (see below), \ or it shouldn't exist. excalibur.jar | | This contains all utility code for avalon applications - these are | Components/Blocks/Services that are not defined by the specification, | but that are needed in many apps (pooling, datasource, timer, sockets, | store, scheduler, etc). | \--- org.apache.excalibur.* excalibur-XXX.jar | | As excalibur grows, it will probably make sense to separate it out | into multiple .jars so application deployers only have to include \ the components they need. demos.jar | | This contains the current demos from the Cornerstone CVS. | |--- org.apache.demos.avalon.* (I'm at a loss where these should end up; \ probably org.apache.excalibur.demos) NOTES ----- - org.apache.avalon.log has the most basic parts of logging only; the parts apps built on Avalon need to deal with (Loggable and Logger interfaces only, probably). - "phoenix" here means RI. We could also have a different name for this and have org.apache.phoenix only serve as the RI of org.apache.avalon.atlantis, but this is IMHO not the most logical organisation (org.apache.avalon.atlantis should be implemented by org.apache.XXX.atlantis). - I know we can't do this yet... What _can_ be done quickly: - define and build avalonapi-4.0b.jar which has the same role as "avalon-core.jar" above, but does not have the interface separated from implementation yet. - Cocoon2 beta ;) - start on phoenix-4.0b.jar, which has the same role as "phoenix-core.jar" above, and for now includes org.apache.avalon.atlantis as it isn't stable enough yet. - start on excalibur-3.3a.jar, which contains the code not stable enough for avalonapi-4.0b.jar yet. If we do this, org.apache.excalibur needs to be in the Avalon in the Avalon package. If we want to move parts of Cornerstone to excalibur, it makes sense to instead clean up cornerstone and then rename it to excalibur. I think I've made myself about as clear as possible =) cheers all, LSD <java:sig> About LSD = new PersonalInfo(); LSD.name("Leo Simons"); LSD.email("[EMAIL PROTECTED]"); LSD.URL( [ http://www.leosimons.com, // personal website http://www.atfantasy.com, // fantasy RPG portal http://www.the-sign.nl // web-design company ] ); LSD.quote("Buh!"); email.setSig((String)LSD); </java:sig> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
