I have now moved the bindings, containers, databindings and idl
directories under sca/services
--
Jeremy
On Sep 16, 2006, at 1:49 PM, Jeremy Boynes wrote:
The pom hierarchy changes have now been done and the samples and
distributions re-enabled.
I would recommend removing all Tuscany artifacts from your local
repo and doing a full build from "java" once you update to r446951
--
Jeremy
On Sep 16, 2006, at 8:02 AM, Jeremy Boynes wrote:
For the next phase of this I want to consolidate the parent POMs
for extensions and kernel. As part of that I would like to do the
move of the extensions into their own sub-directory and plan to
reuse "services" for that. The resulting tree will look like:
sca/services/bindings
sca/services/containers
sca/services/databindings
sca/services/idl
sca/services/transports
I intend to do the move Monday unless I hear differently - if you
have uncommitted changes please get them in to avoid conflicts.
In the meantime I will be updating the pom hierarchy to reflect
this new layout.
--
Jeremy
On Aug 30, 2006, at 10:32 PM, Jeremy Boynes wrote:
I have updated the POMs for the spec projects and buildtools so
that we are ready to publish snapshot builds for them.
This will allow us to build and publish SCA and SDO as standalone
projects. Once SDO is published, we should be able to build and
publish DAS.
To tackle 3), I will move the projects under a new subdirectory
in sca called (for want of a better name as core is taken) "kernel".
--
Jeremy
On Aug 29, 2006, at 5:24 PM, Jeremy Boynes wrote:
Sounds good to me. I will start to publish unstable builds to
the apache snapshot repo to help stabilize things.
--
Jeremy
On Aug 25, 2006, at 5:20 PM, Jim Marino wrote:
Many of us have experienced build breaks over the past several
weeks, particularly in the Java SCA project. I believe the root
of the problem to be not having the correct level of
modularity. I would like to start with a general approach on
how to fix this and once we gain consensus, move to creating a
proposal for changing the current build structure.
1. The source tree should be independently built from
individual projects under /java, sca, sdo, and das. Currently
it is not since buildtools is required. I would like to get to
the point where people can check out individual sub projects
only and build from there.
2. For SCA Java, as Ant proposed, the samples dealing with
extensions would move to their appropriate extension projects.
Samples that used multiple extensions (e.g. BigBank with Celtix
and Axis) would stay under samples/sca
3. API, SPI, core, hostutil, host-api would be built
independently under a subdirectory of /sca
4. Runtime host projects would be build independently under a
subdirectory of /sca
5. Extensions would move into into a subdirectory of /sca (they
could still be organized according to type) and be built
individually against a particular version of the core "jars".
This would mean that extensions are not built together and are
not built with the core. This would shield the entire build
process from breaking when an extension breaks (e.g. Axis and
Axiom not being in sync). It would also mean changes to the
core could be vetted and not impact work being done on extensions.
Thoughts?
Jim
------------------------------------------------------------------
---
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]
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
