Hi, First, thanks for doing this. I follow what you propose here and makes sense to me. So +1.
Just the concern about having the existing folders as well - I suppose we will clean that up at some point of time once we get this going smooth. - Venkat. On 4/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Hi all, We've discussed the need for a working top-down build in a number of threads now: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14658.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15892.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16085.html We're also starting to discuss the contents of our next release, so it's probably about time to do something concrete to fix that build :) Here's a pretty basic proposal for how to fix it. First simplify our trunk structure: java/ pom/parent/pom.xml sca/ pom.xml modules/ pom.xml assembly binding-axis2 contribution core databinding discovery-jms federation http-jetty idl-java impl-java ... The "next release" discussion will help us determine the list of modules. samples/ build.xml <-- I'd like to build the samples with Ant as well as Maven pom.xml calculator supplychain bigbank helloworld ... Here also, the release discussion will help determine the list. itest pom.xml bindings exceptions spec ... Here I suggest to copy the tests from the integration branch. Maven technicalities: - sca/pom.xml's parent will be pom/parent/pom.xml - Other poms will use the pom from the parent folder as parent pom - Group ids: org.apache.tuscany.sca, org.apache.tuscany.sca.samples, org.apache.tuscan.sca.itest - Version of our modules will be specified once in java/sca/pom.xml, child poms don't need specify a version as they get it from their parent Naming conventions: - Use all lowercases and dashes in folder names (like in the jar names) - Maven artifact id = tuscany-<folder name> Building the tree: Simple... cd java/sca, then mvn. It should work even if you start with an empty Maven local repository, and it should always work :) Build breaks should be avoided or get fixed quickly, it's the least we can do to be nice to our community of developers and users to avoid breaking them all the time. Handling modules not part of the next release: If people want to work on some new modules that won't be part of the next release and not included in the top-down build, that's fine, we can just avoid listing these modules in java/sca/modules/pom.xml. So, they can be there in the same source tree but they won't break the release top-down build, and they won't have to be building at all times. So, to make this proposal concrete, I'm planning to put my build guy hat on and start putting that build structure together on Tuesday. I won't break any of the existing modules as the new folder names won't conflict with the existing folders. Also I'll copy the modules to the new folders instead of moving them. I would like to have this structure running for a few days, get people's input, feedback or help to make it work :) and adjust it step by step to what people in our community want. If it works well, then great, we'll have a working build again and a happy community :) If people want to try something else, we can try it too. Finally, we can revisit the tree structure, the build etc. after the next release as well. Thoughts? -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
