build breaks (and how to fix them)
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]
Re: build breaks (and how to fix them)
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]
Re: build breaks (and how to fix them)
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]
Re: build breaks (and how to fix them)
Hi Jeremy I'm trying to catch up on things, after couple days out... do I need to update anything on DAS or what you mentioned here is that because DAS has a SDO dependency, it will have to be built and published after that ? - Luciano On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> 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] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: build breaks (and how to fix them)
On Aug 31, 2006, at 4:48 PM, Luciano Resende wrote: Hi Jeremy I'm trying to catch up on things, after couple days out... do I need to update anything on DAS or what you mentioned here is that because DAS has a SDO dependency, it will have to be built and published after that ? When I modified the artifactId I updated DAS as well so there's nothing to change there. I plan to publish snapshots of SDO later tonight and when that happens DAS should be able to pick them up (no need to build everything together). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
On Aug 30, 2006, at 10:32 PM, Jeremy Boynes wrote: 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". I have moved api, host-api, spi and core under a sub-directory called kernel. I have not changed the poms yet except to change the module path in sca/pom.xml - I will be moving these to a new groupId : org.apache.tuscany.sca.kernel -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
Can we also move the databinding extensions under services so we have: service/transports services/databinding services/ Jim On Aug 31, 2006, at 8:19 PM, Jeremy Boynes wrote: On Aug 30, 2006, at 10:32 PM, Jeremy Boynes wrote: 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". I have moved api, host-api, spi and core under a sub-directory called kernel. I have not changed the poms yet except to change the module path in sca/pom.xml - I will be moving these to a new groupId : org.apache.tuscany.sca.kernel -- Jeremy - 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]
Re: build breaks (and how to fix them)
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]
Re: build breaks (and how to fix them)
Hi, Jeremy. I have some uncommitted changes (databinding and core/spi) and plan to check them in during the weekend. Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Saturday, September 16, 2006 8:02 AM Subject: Re: build breaks (and how to fix them) 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]
Re: build breaks (and how to fix them)
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]
Re: build breaks (and how to fix them)
On Sep 16, 2006, at 9:24 AM, Raymond Feng wrote: Hi, Jeremy. I have some uncommitted changes (databinding and core/spi) and plan to check them in during the weekend. Saw the big commit last night :) Are you current now and should I go ahead with the moves? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build breaks (and how to fix them)
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]
