I agree with almost all of this except the part about having ant and
maven builds, this sounds like the beginning of a dual maintenance rat
hole that I doubt we want to go down.

Also, once we get this build straightened out I would LOVE to have
machine running builds and posting results so that people could keep
track of the build status.  Unfortunately I don't have a machine to
donate to the cause, but if someone does I could try and help set it
up.

-Bert

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/[email protected]/msg14658.html
http://www.mail-archive.com/[email protected]/msg15892.html
http://www.mail-archive.com/[email protected]/msg16062.html
http://www.mail-archive.com/[email protected]/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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to