tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: SCA source tree and build structure
Date Tue, 03 Apr 2007 17:40:53 GMT
Overall, +1

Quick question around copying versus moving, how are we going to clean-up
later on ?

As for Bert suggestion on having a automated build, I remember Slava Imeshev
had setup one for us in the past, maybe we could get that going again...

On 4/3/07, Raymond Feng <enjoyjava@gmail.com> wrote:
>
> Forgot to ask one question:
>
> We have inconsistent version ids for artifacts in the trunk, do you plan
> to
> reconcile them? If so, what should the version id look like? I propose
> that
> we use something like 1.0-incubating-alpha1-SNAPSHOT to reflect the fact
> that we're working toward a 1.0 release.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <jsdelfino@apache.org>
> To: <tuscany-dev@ws.apache.org>
> 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/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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Luciano Resende
http://people.apache.org/~lresende

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message