You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/04/03 12:45:03 UTC
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
Re: SCA source tree and build structure
Posted by Luciano Resende <lu...@gmail.com>.
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 <en...@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" <js...@apache.org>
> To: <tu...@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
Re: Build update, was: SCA source tree and build structure
Posted by Luciano Resende <lu...@gmail.com>.
I have added the Contribution Service implementation to the build.
On 4/4/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >> Hi,
> >>
> >> Yes, what Luciano is suggesting here makes sense to me as well.
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >> On 4/4/07, Luciano Resende <lu...@gmail.com> wrote:
> >>>
> >>> Sebastien wrote:
> >>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
> >>> alpha1 is
> >>> >probably better. I'll start with alpha1 then.
> >>>
> >>> Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or
> alpha1
> >>> when
> >>> we branch/tag for release, together with the removal of SNAPSHOT ?
> This
> >>> would make trunk always with same version id, right ?
> >>>
> >>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>> >
> >>> > [snip]
> >>> > Raymond Feng 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
> >>> > >
> >>> >
> >>> > Yes I plan to reconcile them, like this:
> >>> >
> >>> > >
> >>> > >> - 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
> >>> > >>
> >>> >
> >>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
> >>> alpha1 is
> >>> > probably better. I'll start with alpha1 then.
> >>> >
> >>> > --
> >>> > Jean-Sebastien
> >>> >
> >>> >
> >>> >
> ---------------------------------------------------------------------
> >>> > 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
> >>>
> >>
> >
> > OK then, it makes sense to me too, I'll change to
> > 1.0-incubating-SNAPSHOT.
> >
>
> Here's an update on the progress with the new build structure.
>
> To build the sca tree, you should now be able to do the following:
> cd tuscany/java/sca
> mvn
> and get the following output.
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Apache Tuscany Project Parent ......................... SUCCESS
> [1.356s]
> [INFO] Apache Tuscany Build Tools ............................ SUCCESS
> [0.975s]
> [INFO] SCA API Version 1.0 ................................... SUCCESS
> [0.900s]
> [INFO] Apache Tuscany SCA Implementation Project ............. SUCCESS
> [0.033s]
> [INFO] Apache Tuscany SCA Implementation Modules ............. SUCCESS
> [0.044s]
> [INFO] Apache Tuscany Interface Model ........................ SUCCESS
> [0.972s]
> [INFO] Apache Tuscany Policy Model ........................... SUCCESS
> [1.206s]
> [INFO] Apache Tuscany Assembly Model ......................... SUCCESS
> [2.266s]
> [INFO] Apache Tuscany SCA Contribution Service ............... SUCCESS
> [1.134s]
> [INFO] Apache Tuscany SCA XML Assembly Support ............... SUCCESS
> [2.860s]
> [INFO] Apache Tuscany DataBinding Framework .................. SUCCESS
> [4.500s]
> [INFO] Apache Tuscany Data Binding for Axiom ................. SUCCESS
> [1.746s]
> [INFO] Apache Tuscany HTTP Servlet Host ...................... SUCCESS
> [0.331s]
> [INFO] Apache Tuscany Jetty HTTP Service ..................... SUCCESS
> [4.493s]
> [INFO] Apache Tuscany Tomcat HTTP Service .................... SUCCESS
> [2.545s]
> [INFO] Apache Tuscany Java Interface Model ................... SUCCESS
> [0.687s]
> [INFO] Apache Tuscany SCA XML Java Interface Extension ....... SUCCESS
> [1.365s]
> [INFO] Apache Tuscany WSDL Interface Model ................... SUCCESS
> [0.750s]
> [INFO] Apache Tuscany SCA XML WSDL Interface Extension ....... SUCCESS
> [1.383s]
> [INFO] Apache Tuscany Java Implementation Model .............. SUCCESS
> [0.823s]
> [INFO] Apache Tuscany SCA XML Java Implementation Extension .. SUCCESS
> [1.436s]
> [INFO] Apache Tuscany Axis2 Java2WSDL Tool ................... SUCCESS
> [9.311s]
> [INFO] Apache Tuscany Maven Plugin for Java2WSDL ............. SUCCESS
> [1.400s]
> [INFO] Apache Tuscany Axis2 WSDL2Java Tool ................... SUCCESS
> [6.734s]
> [INFO] Apache Tuscany Maven Plugin for WSDL2Java ............. SUCCESS
> [0.594s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 50 seconds
> [INFO] Finished at: Wed Apr 04 19:23:58 PDT 2007
> [INFO] Final Memory: 28M/115M
> [INFO]
> ------------------------------------------------------------------------
>
> This is just a subset of the whole SCA tree, more work is required to
> bring up the remaining pieces, in particular:
> - the core runtime
> - the contribution service implementation
> - the SDO, JaxB and SDO-Axiom databinding
> - the various Axis2, JMS, RMI etc. bindings
> - The support for JMX management and the discovery/JMS
> - the Spring implementation support
>
> Our integration tests are under java/sca/itest but not included in the
> build yet, as we need to get the above modules building first.
>
> The java/sca/samples directory is currently empty. The work to bring
> them up and get them to at least compile could be done in parallel if
> people are interested in helping out with that.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: Moving spec/sca-api module under sca? was: Build update
Posted by Luciano Resende <lu...@gmail.com>.
Ok then, let's move to the modules directory for now, as we will need to
release it anyway on our next release. When the time arrives and we need to
re think the spec module location, then we revisit the case.
On 4/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Luciano Resende wrote:
> > But we probably want to release 2 things, sca-spec and sca, right ?
> > and then
> > in subsequent releases of sca, we are only going to release sca,
> > unless the
> > spec changes and we need to update sca-spec jar.
> >
> >
> [snip]
> >>
> >>
> >> I could be convinced, but I'm not sure I understand yet :)
> >>
> >> Aren't we going to release an sca-api JAR in our next
> >> tuscany-incubating-xyz.tar.gz?
> >>
> >> --
> >> Jean-Sebastien
> >>
> >>
>
> I'm still confused :) Let's imagine for illustration purposes that we
> have 2 alpha releases, alpha1 and alpha2. I am assuming that:
> tuscany-incubating-1.0-alpha1.tar.gz will contain an sca-api JAR from a
> specific SVN revision, let's say X
> tuscany-incubating-1.0-alpha2.tar.gz will contain an sca-api JAR from an
> SVN revision Y
> where the sca-api JAR is just the API provided to application developers
> for one the many component implementation types that we want to support,
> POJO component implementations in this case.
>
> Is there a reason why we'd want to single this JAR out and force POJO
> component developers to get this one (and only this one) from a
> different distribution than tuscany-incubating.tar.gz?
>
> Also, perhaps SVN revision X will be the same revision as Y, or not...
> we can't really predict that, as we may find bugs in the spec interfaces
> or their javadocs. But isn't the same true for any other module in our
> distribution? Why would we want to handle the release of sca-api JAR
> differently?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: Moving spec/sca-api module under sca? was: Build update
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Luciano Resende wrote:
> But we probably want to release 2 things, sca-spec and sca, right ?
> and then
> in subsequent releases of sca, we are only going to release sca,
> unless the
> spec changes and we need to update sca-spec jar.
>
>
[snip]
>>
>>
>> I could be convinced, but I'm not sure I understand yet :)
>>
>> Aren't we going to release an sca-api JAR in our next
>> tuscany-incubating-xyz.tar.gz?
>>
>> --
>> Jean-Sebastien
>>
>>
I'm still confused :) Let's imagine for illustration purposes that we
have 2 alpha releases, alpha1 and alpha2. I am assuming that:
tuscany-incubating-1.0-alpha1.tar.gz will contain an sca-api JAR from a
specific SVN revision, let's say X
tuscany-incubating-1.0-alpha2.tar.gz will contain an sca-api JAR from an
SVN revision Y
where the sca-api JAR is just the API provided to application developers
for one the many component implementation types that we want to support,
POJO component implementations in this case.
Is there a reason why we'd want to single this JAR out and force POJO
component developers to get this one (and only this one) from a
different distribution than tuscany-incubating.tar.gz?
Also, perhaps SVN revision X will be the same revision as Y, or not...
we can't really predict that, as we may find bugs in the spec interfaces
or their javadocs. But isn't the same true for any other module in our
distribution? Why would we want to handle the release of sca-api JAR
differently?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Moving spec/sca-api module under sca? was: Build update
Posted by Luciano Resende <lu...@gmail.com>.
But we probably want to release 2 things, sca-spec and sca, right ? and then
in subsequent releases of sca, we are only going to release sca, unless the
spec changes and we need to update sca-spec jar.
On 4/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Raymond Feng wrote:
> > Good points. I agree it's probably better to keep it at sca/spec level.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: "Venkata Krishnan"
> > <fo...@gmail.com>
> > To: <tu...@ws.apache.org>
> > Sent: Thursday, April 05, 2007 10:15 AM
> > Subject: Re: Build update, was: SCA source tree and build structure
> >
> >
> >> Yes and I very faintly remember this to be the reason why we moved
> >> the specs
> >> out to where it is now. Isn't it ?
> >>
> >> - Venkat
> >>
> >> On 4/5/07, Luciano Resende <lu...@gmail.com> wrote:
> >>>
> >>> I was under the impression that the spec-sca-api-r1.0 module would be
> a
> >>> stable one unless the spec changes. Isn't right that, under spec/ we
> >>> can
> >>> have multiple sca releases based on the same spec-sca-api-r1.0, but
> >>> moving
> >>> it to /modules we will be forced to have a spec api release every
> >>> time we
> >>> release sca ?
> >>>
> >>> On 4/5/07, Raymond Feng <en...@gmail.com> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > For SCA, I suggest that we further move it to >
> >>> "modules/spec-sca-api-r1.0
> >>> ".
> >>> >
> >>> > Thanks,
> >>> > Raymond
> >>> >
> >>> > ----- Original Message -----
> >>> > From: "Jean-Sebastien Delfino" <js...@apache.org>
> >>> > To: <tu...@ws.apache.org>
> >>> > Sent: Thursday, April 05, 2007 8:36 AM
> >>> > Subject: Re: Build update, was: SCA source tree and build structure
> >>> >
> >>> >
> >>> > > Bert Lamb wrote:
> >>> > >> Just to note, in order for this build to work from a fresh empty
> >>> maven
> >>> > >> local repo, you'll need to run "mvn" from the > >>
> >>> /java/spec/sca-api-r1.0
> >>> /
> >>> > >> directory first.
> >>> > >>
> >>> > >> -Bert
> >>> > >>
> >>> > >
> >>> > > Good point. I had forgotten to commit my change to
> >>> java/sca/pom.xml > > to
> >>> > > include the spec-api in the top-down build. It's now fixed in >
> >>> > revision
> >>> > > r525846.
> >>> > >
> >>> > > Also, I'm not sure it's obvious to everybody that the SCA API is
> >>> hiding
> >>> > > under java/spec instead of being under the java/sca folder.
> Similar
> >>> > > comment for the SDO API.
> >>> > >
> >>> > > How about moving java/spec/sca-api-r1.0 to java/sca and
> >>> > > java/spec/sdo-api to java/sdo as well?
> >>> > >
> >>> > > Thoughts?
> >>> > >
> >>> > > --
> >>> > > Jean-Sebastien
> >>> > >
> >>> > >
>
> I could be convinced, but I'm not sure I understand yet :)
>
> Aren't we going to release an sca-api JAR in our next
> tuscany-incubating-xyz.tar.gz?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Moving spec/sca-api module under sca? was: Build update
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Good points. I agree it's probably better to keep it at sca/spec level.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Venkata Krishnan"
> <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, April 05, 2007 10:15 AM
> Subject: Re: Build update, was: SCA source tree and build structure
>
>
>> Yes and I very faintly remember this to be the reason why we moved
>> the specs
>> out to where it is now. Isn't it ?
>>
>> - Venkat
>>
>> On 4/5/07, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>> I was under the impression that the spec-sca-api-r1.0 module would be a
>>> stable one unless the spec changes. Isn't right that, under spec/ we
>>> can
>>> have multiple sca releases based on the same spec-sca-api-r1.0, but
>>> moving
>>> it to /modules we will be forced to have a spec api release every
>>> time we
>>> release sca ?
>>>
>>> On 4/5/07, Raymond Feng <en...@gmail.com> wrote:
>>> >
>>> > Hi,
>>> >
>>> > For SCA, I suggest that we further move it to >
>>> "modules/spec-sca-api-r1.0
>>> ".
>>> >
>>> > Thanks,
>>> > Raymond
>>> >
>>> > ----- Original Message -----
>>> > From: "Jean-Sebastien Delfino" <js...@apache.org>
>>> > To: <tu...@ws.apache.org>
>>> > Sent: Thursday, April 05, 2007 8:36 AM
>>> > Subject: Re: Build update, was: SCA source tree and build structure
>>> >
>>> >
>>> > > Bert Lamb wrote:
>>> > >> Just to note, in order for this build to work from a fresh empty
>>> maven
>>> > >> local repo, you'll need to run "mvn" from the > >>
>>> /java/spec/sca-api-r1.0
>>> /
>>> > >> directory first.
>>> > >>
>>> > >> -Bert
>>> > >>
>>> > >
>>> > > Good point. I had forgotten to commit my change to
>>> java/sca/pom.xml > > to
>>> > > include the spec-api in the top-down build. It's now fixed in >
>>> > revision
>>> > > r525846.
>>> > >
>>> > > Also, I'm not sure it's obvious to everybody that the SCA API is
>>> hiding
>>> > > under java/spec instead of being under the java/sca folder. Similar
>>> > > comment for the SDO API.
>>> > >
>>> > > How about moving java/spec/sca-api-r1.0 to java/sca and
>>> > > java/spec/sdo-api to java/sdo as well?
>>> > >
>>> > > Thoughts?
>>> > >
>>> > > --
>>> > > Jean-Sebastien
>>> > >
>>> > >
I could be convinced, but I'm not sure I understand yet :)
Aren't we going to release an sca-api JAR in our next
tuscany-incubating-xyz.tar.gz?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build update, was: SCA source tree and build structure
Posted by Raymond Feng <en...@gmail.com>.
Good points. I agree it's probably better to keep it at sca/spec level.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, April 05, 2007 10:15 AM
Subject: Re: Build update, was: SCA source tree and build structure
> Yes and I very faintly remember this to be the reason why we moved the
> specs
> out to where it is now. Isn't it ?
>
> - Venkat
>
> On 4/5/07, Luciano Resende <lu...@gmail.com> wrote:
>>
>> I was under the impression that the spec-sca-api-r1.0 module would be a
>> stable one unless the spec changes. Isn't right that, under spec/ we can
>> have multiple sca releases based on the same spec-sca-api-r1.0, but
>> moving
>> it to /modules we will be forced to have a spec api release every time we
>> release sca ?
>>
>> On 4/5/07, Raymond Feng <en...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > For SCA, I suggest that we further move it to
>> > "modules/spec-sca-api-r1.0
>> ".
>> >
>> > Thanks,
>> > Raymond
>> >
>> > ----- Original Message -----
>> > From: "Jean-Sebastien Delfino" <js...@apache.org>
>> > To: <tu...@ws.apache.org>
>> > Sent: Thursday, April 05, 2007 8:36 AM
>> > Subject: Re: Build update, was: SCA source tree and build structure
>> >
>> >
>> > > Bert Lamb wrote:
>> > >> Just to note, in order for this build to work from a fresh empty
>> maven
>> > >> local repo, you'll need to run "mvn" from the
>> > >> /java/spec/sca-api-r1.0
>> /
>> > >> directory first.
>> > >>
>> > >> -Bert
>> > >>
>> > >
>> > > Good point. I had forgotten to commit my change to java/sca/pom.xml
>> > > to
>> > > include the spec-api in the top-down build. It's now fixed in
>> > > revision
>> > > r525846.
>> > >
>> > > Also, I'm not sure it's obvious to everybody that the SCA API is
>> hiding
>> > > under java/spec instead of being under the java/sca folder. Similar
>> > > comment for the SDO API.
>> > >
>> > > How about moving java/spec/sca-api-r1.0 to java/sca and
>> > > java/spec/sdo-api to java/sdo 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build update, was: SCA source tree and build structure
Posted by Venkata Krishnan <fo...@gmail.com>.
Yes and I very faintly remember this to be the reason why we moved the specs
out to where it is now. Isn't it ?
- Venkat
On 4/5/07, Luciano Resende <lu...@gmail.com> wrote:
>
> I was under the impression that the spec-sca-api-r1.0 module would be a
> stable one unless the spec changes. Isn't right that, under spec/ we can
> have multiple sca releases based on the same spec-sca-api-r1.0, but moving
> it to /modules we will be forced to have a spec api release every time we
> release sca ?
>
> On 4/5/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > Hi,
> >
> > For SCA, I suggest that we further move it to "modules/spec-sca-api-r1.0
> ".
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Jean-Sebastien Delfino" <js...@apache.org>
> > To: <tu...@ws.apache.org>
> > Sent: Thursday, April 05, 2007 8:36 AM
> > Subject: Re: Build update, was: SCA source tree and build structure
> >
> >
> > > Bert Lamb wrote:
> > >> Just to note, in order for this build to work from a fresh empty
> maven
> > >> local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0
> /
> > >> directory first.
> > >>
> > >> -Bert
> > >>
> > >
> > > Good point. I had forgotten to commit my change to java/sca/pom.xml to
> > > include the spec-api in the top-down build. It's now fixed in revision
> > > r525846.
> > >
> > > Also, I'm not sure it's obvious to everybody that the SCA API is
> hiding
> > > under java/spec instead of being under the java/sca folder. Similar
> > > comment for the SDO API.
> > >
> > > How about moving java/spec/sca-api-r1.0 to java/sca and
> > > java/spec/sdo-api to java/sdo 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
>
Re: Build update, was: SCA source tree and build structure
Posted by Luciano Resende <lu...@gmail.com>.
I was under the impression that the spec-sca-api-r1.0 module would be a
stable one unless the spec changes. Isn't right that, under spec/ we can
have multiple sca releases based on the same spec-sca-api-r1.0, but moving
it to /modules we will be forced to have a spec api release every time we
release sca ?
On 4/5/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> For SCA, I suggest that we further move it to "modules/spec-sca-api-r1.0".
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Thursday, April 05, 2007 8:36 AM
> Subject: Re: Build update, was: SCA source tree and build structure
>
>
> > Bert Lamb wrote:
> >> Just to note, in order for this build to work from a fresh empty maven
> >> local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0/
> >> directory first.
> >>
> >> -Bert
> >>
> >
> > Good point. I had forgotten to commit my change to java/sca/pom.xml to
> > include the spec-api in the top-down build. It's now fixed in revision
> > r525846.
> >
> > Also, I'm not sure it's obvious to everybody that the SCA API is hiding
> > under java/spec instead of being under the java/sca folder. Similar
> > comment for the SDO API.
> >
> > How about moving java/spec/sca-api-r1.0 to java/sca and
> > java/spec/sdo-api to java/sdo 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
Re: Build update, was: SCA source tree and build structure
Posted by Raymond Feng <en...@gmail.com>.
Hi,
For SCA, I suggest that we further move it to "modules/spec-sca-api-r1.0".
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, April 05, 2007 8:36 AM
Subject: Re: Build update, was: SCA source tree and build structure
> Bert Lamb wrote:
>> Just to note, in order for this build to work from a fresh empty maven
>> local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0/
>> directory first.
>>
>> -Bert
>>
>
> Good point. I had forgotten to commit my change to java/sca/pom.xml to
> include the spec-api in the top-down build. It's now fixed in revision
> r525846.
>
> Also, I'm not sure it's obvious to everybody that the SCA API is hiding
> under java/spec instead of being under the java/sca folder. Similar
> comment for the SDO API.
>
> How about moving java/spec/sca-api-r1.0 to java/sca and
> java/spec/sdo-api to java/sdo 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
Re: Build update, was: SCA source tree and build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Bert Lamb wrote:
> Just to note, in order for this build to work from a fresh empty maven
> local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0/
> directory first.
>
> -Bert
>
Good point. I had forgotten to commit my change to java/sca/pom.xml to
include the spec-api in the top-down build. It's now fixed in revision
r525846.
Also, I'm not sure it's obvious to everybody that the SCA API is hiding
under java/spec instead of being under the java/sca folder. Similar
comment for the SDO API.
How about moving java/spec/sca-api-r1.0 to java/sca and
java/spec/sdo-api to java/sdo 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
Re: Build update, was: SCA source tree and build structure
Posted by Bert Lamb <al...@pobox.com>.
Just to note, in order for this build to work from a fresh empty maven
local repo, you'll need to run "mvn" from the /java/spec/sca-api-r1.0/
directory first.
-Bert
On 4/4/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > Venkata Krishnan wrote:
> >> Hi,
> >>
> >> Yes, what Luciano is suggesting here makes sense to me as well.
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >> On 4/4/07, Luciano Resende <lu...@gmail.com> wrote:
> >>>
> >>> Sebastien wrote:
> >>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
> >>> alpha1 is
> >>> >probably better. I'll start with alpha1 then.
> >>>
> >>> Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1
> >>> when
> >>> we branch/tag for release, together with the removal of SNAPSHOT ? This
> >>> would make trunk always with same version id, right ?
> >>>
> >>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>> >
> >>> > [snip]
> >>> > Raymond Feng 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
> >>> > >
> >>> >
> >>> > Yes I plan to reconcile them, like this:
> >>> >
> >>> > >
> >>> > >> - 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
> >>> > >>
> >>> >
> >>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
> >>> alpha1 is
> >>> > probably better. I'll start with alpha1 then.
> >>> >
> >>> > --
> >>> > Jean-Sebastien
> >>> >
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > 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
> >>>
> >>
> >
> > OK then, it makes sense to me too, I'll change to
> > 1.0-incubating-SNAPSHOT.
> >
>
> Here's an update on the progress with the new build structure.
>
> To build the sca tree, you should now be able to do the following:
> cd tuscany/java/sca
> mvn
> and get the following output.
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Apache Tuscany Project Parent ......................... SUCCESS
> [1.356s]
> [INFO] Apache Tuscany Build Tools ............................ SUCCESS
> [0.975s]
> [INFO] SCA API Version 1.0 ................................... SUCCESS
> [0.900s]
> [INFO] Apache Tuscany SCA Implementation Project ............. SUCCESS
> [0.033s]
> [INFO] Apache Tuscany SCA Implementation Modules ............. SUCCESS
> [0.044s]
> [INFO] Apache Tuscany Interface Model ........................ SUCCESS
> [0.972s]
> [INFO] Apache Tuscany Policy Model ........................... SUCCESS
> [1.206s]
> [INFO] Apache Tuscany Assembly Model ......................... SUCCESS
> [2.266s]
> [INFO] Apache Tuscany SCA Contribution Service ............... SUCCESS
> [1.134s]
> [INFO] Apache Tuscany SCA XML Assembly Support ............... SUCCESS
> [2.860s]
> [INFO] Apache Tuscany DataBinding Framework .................. SUCCESS
> [4.500s]
> [INFO] Apache Tuscany Data Binding for Axiom ................. SUCCESS
> [1.746s]
> [INFO] Apache Tuscany HTTP Servlet Host ...................... SUCCESS
> [0.331s]
> [INFO] Apache Tuscany Jetty HTTP Service ..................... SUCCESS
> [4.493s]
> [INFO] Apache Tuscany Tomcat HTTP Service .................... SUCCESS
> [2.545s]
> [INFO] Apache Tuscany Java Interface Model ................... SUCCESS
> [0.687s]
> [INFO] Apache Tuscany SCA XML Java Interface Extension ....... SUCCESS
> [1.365s]
> [INFO] Apache Tuscany WSDL Interface Model ................... SUCCESS
> [0.750s]
> [INFO] Apache Tuscany SCA XML WSDL Interface Extension ....... SUCCESS
> [1.383s]
> [INFO] Apache Tuscany Java Implementation Model .............. SUCCESS
> [0.823s]
> [INFO] Apache Tuscany SCA XML Java Implementation Extension .. SUCCESS
> [1.436s]
> [INFO] Apache Tuscany Axis2 Java2WSDL Tool ................... SUCCESS
> [9.311s]
> [INFO] Apache Tuscany Maven Plugin for Java2WSDL ............. SUCCESS
> [1.400s]
> [INFO] Apache Tuscany Axis2 WSDL2Java Tool ................... SUCCESS
> [6.734s]
> [INFO] Apache Tuscany Maven Plugin for WSDL2Java ............. SUCCESS
> [0.594s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 50 seconds
> [INFO] Finished at: Wed Apr 04 19:23:58 PDT 2007
> [INFO] Final Memory: 28M/115M
> [INFO]
> ------------------------------------------------------------------------
>
> This is just a subset of the whole SCA tree, more work is required to
> bring up the remaining pieces, in particular:
> - the core runtime
> - the contribution service implementation
> - the SDO, JaxB and SDO-Axiom databinding
> - the various Axis2, JMS, RMI etc. bindings
> - The support for JMX management and the discovery/JMS
> - the Spring implementation support
>
> Our integration tests are under java/sca/itest but not included in the
> build yet, as we need to get the above modules building first.
>
> The java/sca/samples directory is currently empty. The work to bring
> them up and get them to at least compile could be done in parallel if
> people are interested in helping out with that.
>
> --
> 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
Build update, was: SCA source tree and build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Venkata Krishnan wrote:
>> Hi,
>>
>> Yes, what Luciano is suggesting here makes sense to me as well.
>>
>> Thanks
>>
>> - Venkat
>>
>> On 4/4/07, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>> Sebastien wrote:
>>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
>>> alpha1 is
>>> >probably better. I'll start with alpha1 then.
>>>
>>> Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1
>>> when
>>> we branch/tag for release, together with the removal of SNAPSHOT ? This
>>> would make trunk always with same version id, right ?
>>>
>>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> >
>>> > [snip]
>>> > Raymond Feng 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
>>> > >
>>> >
>>> > Yes I plan to reconcile them, like this:
>>> >
>>> > >
>>> > >> - 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
>>> > >>
>>> >
>>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
>>> alpha1 is
>>> > probably better. I'll start with alpha1 then.
>>> >
>>> > --
>>> > Jean-Sebastien
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>
>
> OK then, it makes sense to me too, I'll change to
> 1.0-incubating-SNAPSHOT.
>
Here's an update on the progress with the new build structure.
To build the sca tree, you should now be able to do the following:
cd tuscany/java/sca
mvn
and get the following output.
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
------------------------------------------------------------------------
[INFO] Apache Tuscany Project Parent ......................... SUCCESS
[1.356s]
[INFO] Apache Tuscany Build Tools ............................ SUCCESS
[0.975s]
[INFO] SCA API Version 1.0 ................................... SUCCESS
[0.900s]
[INFO] Apache Tuscany SCA Implementation Project ............. SUCCESS
[0.033s]
[INFO] Apache Tuscany SCA Implementation Modules ............. SUCCESS
[0.044s]
[INFO] Apache Tuscany Interface Model ........................ SUCCESS
[0.972s]
[INFO] Apache Tuscany Policy Model ........................... SUCCESS
[1.206s]
[INFO] Apache Tuscany Assembly Model ......................... SUCCESS
[2.266s]
[INFO] Apache Tuscany SCA Contribution Service ............... SUCCESS
[1.134s]
[INFO] Apache Tuscany SCA XML Assembly Support ............... SUCCESS
[2.860s]
[INFO] Apache Tuscany DataBinding Framework .................. SUCCESS
[4.500s]
[INFO] Apache Tuscany Data Binding for Axiom ................. SUCCESS
[1.746s]
[INFO] Apache Tuscany HTTP Servlet Host ...................... SUCCESS
[0.331s]
[INFO] Apache Tuscany Jetty HTTP Service ..................... SUCCESS
[4.493s]
[INFO] Apache Tuscany Tomcat HTTP Service .................... SUCCESS
[2.545s]
[INFO] Apache Tuscany Java Interface Model ................... SUCCESS
[0.687s]
[INFO] Apache Tuscany SCA XML Java Interface Extension ....... SUCCESS
[1.365s]
[INFO] Apache Tuscany WSDL Interface Model ................... SUCCESS
[0.750s]
[INFO] Apache Tuscany SCA XML WSDL Interface Extension ....... SUCCESS
[1.383s]
[INFO] Apache Tuscany Java Implementation Model .............. SUCCESS
[0.823s]
[INFO] Apache Tuscany SCA XML Java Implementation Extension .. SUCCESS
[1.436s]
[INFO] Apache Tuscany Axis2 Java2WSDL Tool ................... SUCCESS
[9.311s]
[INFO] Apache Tuscany Maven Plugin for Java2WSDL ............. SUCCESS
[1.400s]
[INFO] Apache Tuscany Axis2 WSDL2Java Tool ................... SUCCESS
[6.734s]
[INFO] Apache Tuscany Maven Plugin for WSDL2Java ............. SUCCESS
[0.594s]
[INFO]
------------------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 50 seconds
[INFO] Finished at: Wed Apr 04 19:23:58 PDT 2007
[INFO] Final Memory: 28M/115M
[INFO]
------------------------------------------------------------------------
This is just a subset of the whole SCA tree, more work is required to
bring up the remaining pieces, in particular:
- the core runtime
- the contribution service implementation
- the SDO, JaxB and SDO-Axiom databinding
- the various Axis2, JMS, RMI etc. bindings
- The support for JMX management and the discovery/JMS
- the Spring implementation support
Our integration tests are under java/sca/itest but not included in the
build yet, as we need to get the above modules building first.
The java/sca/samples directory is currently empty. The work to bring
them up and get them to at least compile could be done in parallel if
people are interested in helping out with that.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA source tree and build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> Yes, what Luciano is suggesting here makes sense to me as well.
>
> Thanks
>
> - Venkat
>
> On 4/4/07, Luciano Resende <lu...@gmail.com> wrote:
>>
>> Sebastien wrote:
>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
>> alpha1 is
>> >probably better. I'll start with alpha1 then.
>>
>> Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1
>> when
>> we branch/tag for release, together with the removal of SNAPSHOT ? This
>> would make trunk always with same version id, right ?
>>
>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >
>> > [snip]
>> > Raymond Feng 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
>> > >
>> >
>> > Yes I plan to reconcile them, like this:
>> >
>> > >
>> > >> - 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
>> > >>
>> >
>> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but
>> alpha1 is
>> > probably better. I'll start with alpha1 then.
>> >
>> > --
>> > Jean-Sebastien
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>
OK then, it makes sense to me too, I'll change to 1.0-incubating-SNAPSHOT.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA source tree and build structure
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Yes, what Luciano is suggesting here makes sense to me as well.
Thanks
- Venkat
On 4/4/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Sebastien wrote:
> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
> >probably better. I'll start with alpha1 then.
>
> Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1
> when
> we branch/tag for release, together with the removal of SNAPSHOT ? This
> would make trunk always with same version id, right ?
>
> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > Raymond Feng 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
> > >
> >
> > Yes I plan to reconcile them, like this:
> >
> > >
> > >> - 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
> > >>
> >
> > I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
> > probably better. I'll start with alpha1 then.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
Re: SCA source tree and build structure
Posted by Luciano Resende <lu...@gmail.com>.
Sebastien wrote:
> I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
>probably better. I'll start with alpha1 then.
Should we leave like 1.0-incubating-SNAPSHOT, and only add M3 or alpha1 when
we branch/tag for release, together with the removal of SNAPSHOT ? This
would make trunk always with same version id, right ?
On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Raymond Feng 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
> >
>
> Yes I plan to reconcile them, like this:
>
> >
> >> - 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
> >>
>
> I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
> probably better. I'll start with alpha1 then.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> 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
Re: SCA source tree and build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Raymond Feng 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
>
Yes I plan to reconcile them, like this:
>
>> - 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
>>
I was initially thinking about 1.0-incubating-M3-SNAPSHOT, but alpha1 is
probably better. I'll start with alpha1 then.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA source tree and build structure
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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
Re: SCA source tree and build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Venkata Krishnan wrote:
> 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.
>
I think this will answer Luciano's question as well: Yes, this is the
idea, create new folders now to avoid any big breaks, then clean up /
remove the old folders when people are happy with the new structure and
things go smooth.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA source tree and build structure
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA source tree and build structure
Posted by Raymond Feng <en...@gmail.com>.
+1.
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@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
Re: Cleaning up the tree under java/sca, was: SCA source tree and
build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Ignacio Silva-Lepe wrote:
> I would like to understand how this cleanup impacts users of the "old
> modules",
> ie, the code under java/sca, in particular:
> java/sca
> kernel/core
> kernel/spi
> runtime/itest/plugin
> runtime/standalone/assembly
> runtime/standalone/launcher
> runtime/standalone/standalone-host
> http.jetty
>
> I have been developing an extension that depends quite closely on the
> previous
> list of old modules and I need to determine what I need to do to bring
> it up
> to
> speed with the new modules.
>
> I have been following some of the discussion and it seems like some
> modules,
> such as http.jetty have been pretty much moved without much change.
> Wrt the kernel modules, kernel/spi in particular, it's not clear to me
> how
> much
> they have changed. How much has the spi architecture changed? Will I need
> to re-write my extension all over? How much have loader and builder
> interfaces,
> and their extensions, changed?
> Also, are system scdls still the way to introduce extension system
> components?
> Specifically, I am using the runtime/itest/plugin for a "local" test
> of my
> extension, and the runtime/standalone for a "distributed" test. I have a
> couple of
> system scdls that I incorporate into the itest/plugin and into the
> standalone
> runtime by including them into the plugin system scdl and the standalone
> assembly system scdl. Does this still work?
>
> I was hoping I would not have to go through such a major switch but since
> modules are now being removed, it does not look I have much choice.
>
> Can anybody provide guidance?
>
Ignacio,
If you want to continue to use the old modules you can use svn:externals
like in java/distribution/sca/tsss-demo
svn propget svn:externals
kernel -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/kernel
runtime -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime
http.jetty -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/http.jetty
jms -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/jms-discovery
console -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/console
core-samples -r522095
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/core-samples
As for the other questions, the impact really depends on your
extension... I'll be happy to help you port it over, but where is your
extension? What does it do?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Cleaning up the tree under java/sca, was: SCA source tree and build structure
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
I would like to understand how this cleanup impacts users of the "old
modules",
ie, the code under java/sca, in particular:
java/sca
kernel/core
kernel/spi
runtime/itest/plugin
runtime/standalone/assembly
runtime/standalone/launcher
runtime/standalone/standalone-host
http.jetty
I have been developing an extension that depends quite closely on the
previous
list of old modules and I need to determine what I need to do to bring it up
to
speed with the new modules.
I have been following some of the discussion and it seems like some modules,
such as http.jetty have been pretty much moved without much change.
Wrt the kernel modules, kernel/spi in particular, it's not clear to me how
much
they have changed. How much has the spi architecture changed? Will I need
to re-write my extension all over? How much have loader and builder
interfaces,
and their extensions, changed?
Also, are system scdls still the way to introduce extension system
components?
Specifically, I am using the runtime/itest/plugin for a "local" test of my
extension, and the runtime/standalone for a "distributed" test. I have a
couple of
system scdls that I incorporate into the itest/plugin and into the
standalone
runtime by including them into the plugin system scdl and the standalone
assembly system scdl. Does this still work?
I was hoping I would not have to go through such a major switch but since
modules are now being removed, it does not look I have much choice.
Can anybody provide guidance?
On 4/7/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Jean-Sebastien Delfino 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?
> >
>
> Most modules under java/sca have now been copied to java/sca/modules and
> integrated in the top-down build described earlier in this thread.
>
> To avoid confusion with the old copies of these modules, I would like to
> start cleaning up the tree under java/sca, and:
> - Remove the old copy of the modules which are now available in
> java/sca/modules
> - Move the modules that are not integrated in the top-down build to
> java/sca/contrib, obviously they can be integrated under
> java/sca/modules and in the top-down build at any point if people want.
>
> If there's no objection, I'll start doing that cleanup sometime on Monday.
>
> The resulting structure will be:
> java/sca/
> contrib
> modules
> samples
> itest
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Cleaning up the tree under java/sca, was: SCA source tree and build
structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino 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?
>
Most modules under java/sca have now been copied to java/sca/modules and
integrated in the top-down build described earlier in this thread.
To avoid confusion with the old copies of these modules, I would like to
start cleaning up the tree under java/sca, and:
- Remove the old copy of the modules which are now available in
java/sca/modules
- Move the modules that are not integrated in the top-down build to
java/sca/contrib, obviously they can be integrated under
java/sca/modules and in the top-down build at any point if people want.
If there's no objection, I'll start doing that cleanup sometime on Monday.
The resulting structure will be:
java/sca/
contrib
modules
samples
itest
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Do we need Ant builds for our samples? was: SCA source tree and
build structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> I'll jump in here, as I was the one pushing this proposal for M2.
>
> I think it's useful to have some samples building using Ant to show
> how someone who isn't a maven user can build Tuscany applications
> (rather than Tuscany itself). In this sense, the Ant scripts serve
> as a template for people to create their own build scripts using their
> build tool or IDE of choice.
>
> When I started to do this for M2, I very soon got beyond the Ant/maven
> differences and ran into issues of how the distribution was packaged
> and how extensions and dependencies were located or downloaded. It is
> not a lot of work to maintain a few Ant scripts for selected samples
> in parallel to maven poms. It is much more work to address the other
> environmental issues that are tied to an assumption that maven will be
> the sole build tool for Tuscany applications and the sole repository
> for Tuscany distributions and dependent artifacts.
>
> I'm still interested in making progress in this area. For now I agree
> that we should get everything building smoothly with maven. When we
> have achieved that, I think it would make sense to take a step back and
> think about how a user could build and run Tuscany applications without
> using maven or depending on artifacts held in maven repositories.
>
> Simon
>
> Luciano Resende wrote:
>
>> I'd prefer to focus on getting our maven build working smoothness first.
>>
>> On 4/3/07, Bert Lamb <al...@pobox.com> wrote:
>>
>>>
>>> My gut tells me there has to be a way to make our maven build easier
>>> than it is right now, and I think we are on track to do that. So if
>>> we can make the maven build simple enough to run then that should be
>>> good enough, no?
>>>
>>> If, however, we can't get to the point where you can just run "mvn
>>> install" to build a sample, then I think we could investigate simpler
>>> ant scripts.
>>>
>>> -Bert
>>>
>>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>> > [snip]
>>> > Bert Lamb wrote:
>>> > > I agree with almost all of this
>>> >
>>> > Great :)
>>> >
>>> > > 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.
>>> >
>>> > Here is why I was proposing an Ant build for the samples:
>>> > - We had this in M1, our samples were initially only built with Maven
>>> > but then we thought that it would simpler for our users to be able to
>>> > build the samples with just Ant. IIRC our M1 release included Ant
>>> > scripts for the samples.
>>> > - We wanted to have Ant scripts in M2 (see [1] and [2]) but they
>>> > eventually didn't make it to the actual release distribution.
>>> >
>>> > The idea is to help Ant users build our samples. Also, I'd like to
>>> make
>>> > sure that our runtime story is not too tied to Maven and that it's
>>> > actually convenient to build SCA/Tuscany applications with something
>>> > else than Maven. On the other hand we need to show how to build some
>>> > samples with Maven as well. Other projects like Axis2 for example
>>> have
>>> > adopted a similar approach. They build their runtime with Maven, and
>>> > their samples with Ant.
>>> >
>>> > On the other hand, I agree with you about the dual maintenance rat
>>> > hole... I don't want dual maintenance either. To avoid dual
>>> maintenance
>>> > maybe we could have the pom.xml just call the ant script? or have
>>> some
>>> > samples built with Ant, some with Maven? or... I'm also happy to not
>>> > worry about building samples with Ant for now if people think that
>>> it's
>>> > not useful, I don't particularly like writing build scripts :)
>>> >
>>> > What do people think?
>>> >
>>> > [1]
>>> >
>>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%3C455BA409.2090804@hursley.ibm.com%3E
>>>
>>> > [2] https://issues.apache.org/jira/browse/TUSCANY-906
>>> >
>>> > --
>>> > Jean-Sebastien
>>> >
Ok, I'm not going to worry about Ant build scripts for now then and will
start with just Maven. We can re-evaluate having Ant build scripts or
not for the samples later after we have a smooth Maven build in place.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Do we need Ant builds for our samples? was: SCA source tree and
build structure
Posted by Simon Nash <na...@hursley.ibm.com>.
I'll jump in here, as I was the one pushing this proposal for M2.
I think it's useful to have some samples building using Ant to show
how someone who isn't a maven user can build Tuscany applications
(rather than Tuscany itself). In this sense, the Ant scripts serve
as a template for people to create their own build scripts using their
build tool or IDE of choice.
When I started to do this for M2, I very soon got beyond the Ant/maven
differences and ran into issues of how the distribution was packaged
and how extensions and dependencies were located or downloaded. It is
not a lot of work to maintain a few Ant scripts for selected samples
in parallel to maven poms. It is much more work to address the other
environmental issues that are tied to an assumption that maven will be
the sole build tool for Tuscany applications and the sole repository
for Tuscany distributions and dependent artifacts.
I'm still interested in making progress in this area. For now I agree
that we should get everything building smoothly with maven. When we
have achieved that, I think it would make sense to take a step back and
think about how a user could build and run Tuscany applications without
using maven or depending on artifacts held in maven repositories.
Simon
Luciano Resende wrote:
> I'd prefer to focus on getting our maven build working smoothness first.
>
> On 4/3/07, Bert Lamb <al...@pobox.com> wrote:
>
>>
>> My gut tells me there has to be a way to make our maven build easier
>> than it is right now, and I think we are on track to do that. So if
>> we can make the maven build simple enough to run then that should be
>> good enough, no?
>>
>> If, however, we can't get to the point where you can just run "mvn
>> install" to build a sample, then I think we could investigate simpler
>> ant scripts.
>>
>> -Bert
>>
>> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> > [snip]
>> > Bert Lamb wrote:
>> > > I agree with almost all of this
>> >
>> > Great :)
>> >
>> > > 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.
>> >
>> > Here is why I was proposing an Ant build for the samples:
>> > - We had this in M1, our samples were initially only built with Maven
>> > but then we thought that it would simpler for our users to be able to
>> > build the samples with just Ant. IIRC our M1 release included Ant
>> > scripts for the samples.
>> > - We wanted to have Ant scripts in M2 (see [1] and [2]) but they
>> > eventually didn't make it to the actual release distribution.
>> >
>> > The idea is to help Ant users build our samples. Also, I'd like to make
>> > sure that our runtime story is not too tied to Maven and that it's
>> > actually convenient to build SCA/Tuscany applications with something
>> > else than Maven. On the other hand we need to show how to build some
>> > samples with Maven as well. Other projects like Axis2 for example have
>> > adopted a similar approach. They build their runtime with Maven, and
>> > their samples with Ant.
>> >
>> > On the other hand, I agree with you about the dual maintenance rat
>> > hole... I don't want dual maintenance either. To avoid dual maintenance
>> > maybe we could have the pom.xml just call the ant script? or have some
>> > samples built with Ant, some with Maven? or... I'm also happy to not
>> > worry about building samples with Ant for now if people think that it's
>> > not useful, I don't particularly like writing build scripts :)
>> >
>> > What do people think?
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%3C455BA409.2090804@hursley.ibm.com%3E
>>
>> > [2] https://issues.apache.org/jira/browse/TUSCANY-906
>> >
>> > --
>> > 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
Re: Do we need Ant builds for our samples? was: SCA source tree and build structure
Posted by Luciano Resende <lu...@gmail.com>.
I'd prefer to focus on getting our maven build working smoothness first.
On 4/3/07, Bert Lamb <al...@pobox.com> wrote:
>
> My gut tells me there has to be a way to make our maven build easier
> than it is right now, and I think we are on track to do that. So if
> we can make the maven build simple enough to run then that should be
> good enough, no?
>
> If, however, we can't get to the point where you can just run "mvn
> install" to build a sample, then I think we could investigate simpler
> ant scripts.
>
> -Bert
>
> On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > [snip]
> > Bert Lamb wrote:
> > > I agree with almost all of this
> >
> > Great :)
> >
> > > 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.
> >
> > Here is why I was proposing an Ant build for the samples:
> > - We had this in M1, our samples were initially only built with Maven
> > but then we thought that it would simpler for our users to be able to
> > build the samples with just Ant. IIRC our M1 release included Ant
> > scripts for the samples.
> > - We wanted to have Ant scripts in M2 (see [1] and [2]) but they
> > eventually didn't make it to the actual release distribution.
> >
> > The idea is to help Ant users build our samples. Also, I'd like to make
> > sure that our runtime story is not too tied to Maven and that it's
> > actually convenient to build SCA/Tuscany applications with something
> > else than Maven. On the other hand we need to show how to build some
> > samples with Maven as well. Other projects like Axis2 for example have
> > adopted a similar approach. They build their runtime with Maven, and
> > their samples with Ant.
> >
> > On the other hand, I agree with you about the dual maintenance rat
> > hole... I don't want dual maintenance either. To avoid dual maintenance
> > maybe we could have the pom.xml just call the ant script? or have some
> > samples built with Ant, some with Maven? or... I'm also happy to not
> > worry about building samples with Ant for now if people think that it's
> > not useful, I don't particularly like writing build scripts :)
> >
> > What do people think?
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%3C455BA409.2090804@hursley.ibm.com%3E
> > [2] https://issues.apache.org/jira/browse/TUSCANY-906
> >
> > --
> > 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
Re: Do we need Ant builds for our samples? was: SCA source tree and build structure
Posted by Bert Lamb <al...@pobox.com>.
My gut tells me there has to be a way to make our maven build easier
than it is right now, and I think we are on track to do that. So if
we can make the maven build simple enough to run then that should be
good enough, no?
If, however, we can't get to the point where you can just run "mvn
install" to build a sample, then I think we could investigate simpler
ant scripts.
-Bert
On 4/3/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> [snip]
> Bert Lamb wrote:
> > I agree with almost all of this
>
> Great :)
>
> > 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.
>
> Here is why I was proposing an Ant build for the samples:
> - We had this in M1, our samples were initially only built with Maven
> but then we thought that it would simpler for our users to be able to
> build the samples with just Ant. IIRC our M1 release included Ant
> scripts for the samples.
> - We wanted to have Ant scripts in M2 (see [1] and [2]) but they
> eventually didn't make it to the actual release distribution.
>
> The idea is to help Ant users build our samples. Also, I'd like to make
> sure that our runtime story is not too tied to Maven and that it's
> actually convenient to build SCA/Tuscany applications with something
> else than Maven. On the other hand we need to show how to build some
> samples with Maven as well. Other projects like Axis2 for example have
> adopted a similar approach. They build their runtime with Maven, and
> their samples with Ant.
>
> On the other hand, I agree with you about the dual maintenance rat
> hole... I don't want dual maintenance either. To avoid dual maintenance
> maybe we could have the pom.xml just call the ant script? or have some
> samples built with Ant, some with Maven? or... I'm also happy to not
> worry about building samples with Ant for now if people think that it's
> not useful, I don't particularly like writing build scripts :)
>
> What do people think?
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%3C455BA409.2090804@hursley.ibm.com%3E
> [2] https://issues.apache.org/jira/browse/TUSCANY-906
>
> --
> 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
Do we need Ant builds for our samples? was: SCA source tree and build
structure
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Bert Lamb wrote:
> I agree with almost all of this
Great :)
> 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.
Here is why I was proposing an Ant build for the samples:
- We had this in M1, our samples were initially only built with Maven
but then we thought that it would simpler for our users to be able to
build the samples with just Ant. IIRC our M1 release included Ant
scripts for the samples.
- We wanted to have Ant scripts in M2 (see [1] and [2]) but they
eventually didn't make it to the actual release distribution.
The idea is to help Ant users build our samples. Also, I'd like to make
sure that our runtime story is not too tied to Maven and that it's
actually convenient to build SCA/Tuscany applications with something
else than Maven. On the other hand we need to show how to build some
samples with Maven as well. Other projects like Axis2 for example have
adopted a similar approach. They build their runtime with Maven, and
their samples with Ant.
On the other hand, I agree with you about the dual maintenance rat
hole... I don't want dual maintenance either. To avoid dual maintenance
maybe we could have the pom.xml just call the ant script? or have some
samples built with Ant, some with Maven? or... I'm also happy to not
worry about building samples with Ant for now if people think that it's
not useful, I don't particularly like writing build scripts :)
What do people think?
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%3C455BA409.2090804@hursley.ibm.com%3E
[2] https://issues.apache.org/jira/browse/TUSCANY-906
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA source tree and build structure
Posted by Bert Lamb <al...@pobox.com>.
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 <js...@apache.org> 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: 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