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/07 21:34:20 UTC
Cleaning up the tree under java/sca, was: SCA source tree and build
structure
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: 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
>
>