I would like to add optimally I'd prefer not to build/junit test SDO and DAS on every build (just use the snapshot). I might assume they may feel similar about the SCA parts. With Ant I could probably fix this up pretty quick, still wrapping my head around Maven especially 2.0.
With regard to optional components going stale, if we could figure out how to optionally build items under Maven and not just comment them out, I wonder if we could not have our cake and eat it too, if we had a nightly build/test (GUMP?) we could build most of the time just what we needed/required and have the nightly run the whole build and test battery. ant elder wrote: > Whats not completely clear from this is the 'rules', specifically when must > the 'optional' stuff be built? If code isn't being built in the regular > build that everyone runs it quickly goes stale. Look at our old Axis1 > binding, been out of the regular build a couple of weeks and already it > fails to build. > > I'd like to see everything being included in the regular build. If some > extension makes building difficult vote it out, don't exclude every > extension by default. > > Is so much structure needed at this stage, or does it just makes things more > complicated and make an unnecessary decision now about how Tuscany must be > used. Maybe I just don't like the baseline vs extension distinction. > > I'd go for a more simple hierarchy and leave the structuring to the > distributions. More like the way Mule or DOJO do things with various > distributions designed for specific environments - minimal, SCA-SPEC, J2EE, > the kitchen sink, etc. Perhaps with distributions customizable with a fancy > build script to add/remove things - "minimal,+JavaScript". > > ...ant > > On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> One theme that came out of the recent project promotion thread was a >> need to establish what our project structure should be. Part of that >> also is the level of "support" between parts of that project structure. >> I'd like to propose a strawman, not only of the structure but also of >> the rules. >> >> A project "core" that: >> * is as small as possible with carefully controlled dependencies >> * provides the fabric for the runtime (Contexts) >> * provides APIs for providing plugin extensions >> * provides SPIs for embedding in host environments >> * can be built separately and used by extensions in binary form >> (implying versioning and stability on the extension APIs) >> * has a rule that incompatible changes to the API require the changer >> to upgrade and test all extensions in the Tuscany project and with >> a specific vote to accept them >> >> Baseline services that are distributed with the core that: >> * provide a deployment model for extensions (include loading, >> context building, package handling (classpath)) >> * provide critical system services (monitoring, admin enablement) >> * provide system services needed to support baseline extensions >> (security provider, transaction manager, work manager, ...) >> * has the same rule on API changes for those services as the core >> >> Baseline extensions that are distributed with the core: >> * programming models that are part of the specification >> (currently Java, futures being C++, Spring, J2EE, BPEL, ...) >> * transport bindings that are part of the specification >> (currently WS, futures being JMS, ...) >> * data bindings that are part of the specification >> (currently SDO, futures being JAXB, ...) >> * policy handlers that are part of the specification >> (futures being Security, Transaction, ...) >> >> Optional services that can be used to extend the runtime: >> * programming models that are not part of the specification >> (currently JavaScript, future being PHP, ???) >> * transport bindings that are not part of the specification >> (currently JSON-RPC, future being ???) >> * data bindings that are not part of the specification >> (currently JSON, future being ???) >> * services for use by applications >> (database access, DAS implementations, directory access, ...) >> * these would be released separately and could be deployed >> to a host environment by a user >> >> Host integrations that provide installable distributions: >> * provide implementations of the core's SPIs that allow >> Tuscany to run in different environments. >> (currently J2SE, J2EE WAR and Tomcat, >> future being full J2EE, Geronimo, OSGi(Eclipse), ...) >> * provide installable distributions that include all the >> baseline compoments applicable to that environment >> * provide "extended" distributions tailored to different >> user communities that include selected optional services >> >> Sample and demo applications that: >> * show key concepts from the SCA programming model >> (currently helloworld) >> * show how to build a large scale application >> (currently bigbank) >> * show how to use Tuscany in different environments >> >> Testing >> * compliance test for the specification (when available) >> * pre-release tests for Tuscany >> * ALL modules above should test their own functionality >> (at both the unit and integration levels) as part of their >> own build. No manual setup should be required. >> >> >> Given that, I would suggest the following changes to the project layout: >> >> sca/ >> # "core" system >> sca/system/common >> sca/system/model >> sca/system/core >> >> # "baseline" services and extensions >> sca/baseline/service/monitor >> sca/baseline/service/security >> sca/baseline/service/transaction >> sca/baseline/service/work >> sca/baseline/container/java >> sca/baseline/transport/axis2 >> sca/baseline/data/sdo >> sca/baseline/policy/security >> >> # "optional" services and extensions >> sca/extension/container/rhino >> sca/extension/transport/jsonrpc >> sca/extension/data/json >> sca/extension/service/jndi >> sca/extension/service/jdbc >> >> # host environment integration >> sca/host/tomcat/runtime # integration code >> sca/host/tomcat/testing # integration testing >> sca/host/tomcat/win32 # packaging for release >> sca/host/j2se/runtime # etc... >> >> # samples and testing modules that are not part of a developer build >> sca/samples/helloworld/j2se >> sca/samples/helloworld/war >> sca/samples/bigbank >> sca/testing/compliance >> >> Thoughts? >> -- >> Jeremy >> > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
