+1.
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 03, 2007 3:45 AM
Subject: SCA source tree and build structure
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]
