-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dain Sundstrom wrote: | |> My questions at the root of this are: |> ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of |> a 'minimal' Geronimo? Is it able to claim anything with regard to the |> TCK? | | | It depends on the specifications the subproject is implementing and if | Sun has a stand-alone tck for the specifications. For example, if it | were the Geronimo 'just a webserver edition' we could certify it for | servlets and jsp because they have standalone tcks, but if it were tx | and jca we could not certify it since there are no standalone tcks for | those specs. Understood. My main question was if there was some sort of 'prohibition' on the use of 'full system' pass/fail statistics for those pieces that do, in fact, have their own tcks. [I don't view this as a roadblock to anything, but a definite plus if each individual piece that was able (due to having and passing their own tcks) could state it passes.] | | On the other hand, I'm sure if enough people are interested, sufficient | pressure could be applied to Sun to carve a stand-alone tck out of the | j2ee monolith. This I would see as a 'good thing'. Amazing how software has progressed (*cough*) to 'smaller components combined into larger applications', but tests (even certifications) aren't quite there yet. | |> ~ 2. In stating "there is a demonstrated desire", what roadblocks or |> opposition is there to having each of the current modules (short of the |> kernel, common, core and presumably deployment - and anything else |> needed for the server to start-up and do nothing) each be |> 'self-contained'? Obviously the 'base' server would have to know what |> it's really capable of (unless you go off the deep end with discovery), |> but over and above that base it seems that a WebConnector - be it Jetty |> for user 1 or Tomcat for user 2 may be used with or without Naming, with |> or without Spring and/or Transactions, etc. Why would there be a need to |> limit modules just to what there is a "demonstrated desire" to have? | | | Each subproject has an inherent amount of overhead. For example, each | subproject needs a separate project management committee, each one will | need to produce releases (not an easy task) and so on. I would sat | that "there is a demonstrated desire" when we have enough people | showing up to handle the overhead and work on the code. I personally | would say one person is not enough, and seven is more then enough. Agreed. My view here would be to take the position "Here is the 'best laid plan', who is willing to make it work" instead of "Here is how people are working, what's the best plan we can come up with that doesn't affect that". Granted, there will probably be pieces that should probably be split out without resources to manage it, but if you aim high you have a better chance of getting an optimal solution in place. And nothing says that this can't be further refined down the road. | |> Making everything as small and self-contained (even if they don't 'run' |> on their own) seems to be a smart move in allowing a bug in one module |> to be fixed and made available without waiting on anything else (how |> many times have we wanted a typo fixed that had to wait for a completely |> new feature to be implemented?). | | | I think there are technical and realistic limits to this. Some modules | are simply to small to be full projects. For example the rmi | classloadder is like 5 classes. Also some modules naturally fit | together and have a high degree of coupling. For example the Tx | manager and the j2ca implementation naturally fit together. Now you | can use the Tx manager standalone, but you can't really use j2ca | without a Tx manager. Because of that linking the modules normally move | together. I would say we put both in one sub project and have them | release two jars. | | -dain Agreed here as well. The RMI classloader is what I consider 'too small to make it worth it' and fell in to my "as small and self-contained" as possible. Possible should be read with the implication of 'realistic'. My view on the tx/j2ca type of 'module' is tempered with "overhead costs" and agree that those types of modules may be best combined as you stated. (although removal of that tempered view thinks they should be separate, with the j2ca simply having a dependency on tx.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCmLImaCoPKRow/gARAvX6AJ9Q54WWyRF1M7K6drBBBsOtbSdtrACeMJW3 LhwcnkO+Bqm9EtvL9h0fSsA= =ssHt -----END PGP SIGNATURE-----
