You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tuscany.apache.org by an...@apache.org on 2010/10/18 12:49:36 UTC
svn commit: r1023732 -
/tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml
Author: antelder
Date: Mon Oct 18 10:49:36 2010
New Revision: 1023732
URL: http://svn.apache.org/viewvc?rev=1023732&view=rev
Log:
Update python to use base + extension approach
Modified:
tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml
Modified: tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml
URL: http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml?rev=1023732&r1=1023731&r2=1023732&view=diff
==============================================================================
--- tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml (original)
+++ tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml Mon Oct 18 10:49:36 2010
@@ -33,28 +33,17 @@
<dependencies>
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
- <artifactId>tuscany-sca-api</artifactId>
+ <artifactId>tuscany-core-runtime</artifactId>
+ <type>pom</type>
<version>2.0-SNAPSHOT</version>
+ <scope>provided</scope>
</dependency>
-
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-python</artifactId>
<version>2.0-SNAPSHOT</version>
+ <scope>provided</scope>
</dependency>
-
- <dependency>
- <groupId>org.apache.tuscany.sca</groupId>
- <artifactId>tuscany-core</artifactId>
- <version>2.0-SNAPSHOT</version>
- </dependency>
-
- <dependency>
- <groupId>org.apache.tuscany.sca</groupId>
- <artifactId>tuscany-databinding</artifactId>
- <version>2.0-SNAPSHOT</version>
- </dependency>
-
<dependency>
<groupId>org.python</groupId>
<artifactId>jython</artifactId>
Re: Module dependency on features, Re: svn commit: r1023732
Posted by ant elder <an...@gmail.com>.
On Tue, Oct 19, 2010 at 8:27 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi raymond
>
> On Mon, Oct 18, 2010 at 5:39 PM, Raymond Feng <cy...@gmail.com> wrote:
>> Hi,
>> I saw a bunch of changes in the pom.xml for modules to replace the
>> "fine-grained" dependency to "tuscany-core-runtime". I don't think it's a
>> good idea for two reasons:
>> 1. Features are used to describe a collection of modules. At this point,
>> "modules" and "features" are under two trees. With this change, we cannot
>> build the "modules" alone any more as it depends on "features".
>
> When I made the aggregated description I wanted a simple way to
> describe what collection of modules an extension needed to depend on.
> The Tuscany core SPI has always been somewhat difficult to tie down
> and subsequently the dependencies we placed in our existing poms were
> somewhat random and hard to describe consistently in this respect.
>
> Anyhow I made the core pom (simply as a way to describe the collection
> of core modules) and needed somewhere to put it so I put it in the
> features directory. This was probably a mistake as, having had the
> chance to think about this for a couple of weeks now I realize that
> the features and these new runtime poms are different. I believe now
> that the features are intended to describe fully configured subsets of
> the Tuscany runtime that could be releases. These runtime collections
> are not that. They are incremental descriptions that build on one
> another. In particular the core runtime is the compile dependency that
> extensions use. The base runtime builds on this and provides the base
> runtime functions that the extensions need for testing (it actually
> has more than this in and the precise content hasn't settled down yet
> but you get the idea).
>
> so 1 could easily be solved by moving the *-runtime poms into /modules
> which would get my +1.
>
I agree, and I have now made that change and tested with a full build.
...ant
Re: Module dependency on features, Re: svn commit: r1023732
Posted by Simon Laws <si...@googlemail.com>.
Hi raymond
On Mon, Oct 18, 2010 at 5:39 PM, Raymond Feng <cy...@gmail.com> wrote:
> Hi,
> I saw a bunch of changes in the pom.xml for modules to replace the
> "fine-grained" dependency to "tuscany-core-runtime". I don't think it's a
> good idea for two reasons:
> 1. Features are used to describe a collection of modules. At this point,
> "modules" and "features" are under two trees. With this change, we cannot
> build the "modules" alone any more as it depends on "features".
When I made the aggregated description I wanted a simple way to
describe what collection of modules an extension needed to depend on.
The Tuscany core SPI has always been somewhat difficult to tie down
and subsequently the dependencies we placed in our existing poms were
somewhat random and hard to describe consistently in this respect.
Anyhow I made the core pom (simply as a way to describe the collection
of core modules) and needed somewhere to put it so I put it in the
features directory. This was probably a mistake as, having had the
chance to think about this for a couple of weeks now I realize that
the features and these new runtime poms are different. I believe now
that the features are intended to describe fully configured subsets of
the Tuscany runtime that could be releases. These runtime collections
are not that. They are incremental descriptions that build on one
another. In particular the core runtime is the compile dependency that
extensions use. The base runtime builds on this and provides the base
runtime functions that the extensions need for testing (it actually
has more than this in and the precise content hasn't settled down yet
but you get the idea).
so 1 could easily be solved by moving the *-runtime poms into /modules
which would get my +1.
> 2. There are more modules/jars in the tuscany-core-runtime pom than an
> extension requires, for example, databinding-json doesn't require core,
> host-http, binding-ws, etc.
You mean "that an extension doesn't require"? If so I imagine that's
the case. And this goes some way to demonstrating the problem we have
in Tuscany of not knowing precisely what's required at a simplistic
level. I would say the core-runtime should have at least what is
required to implement any extension type. If we've missed things out
then we need to add them. If we've added too many things then we
should consider thinning it out assuming nothing breaks. The objective
being to end up with the list of modules that really are the core
compile dependencies for creating Tuscany extensions. I'm not
proposing that we have a core-binding-runtime,
core-databinding-runtime, etc. Of course we could but that seems to
add an extra layer of complexity just at the moment so I think we
should come back and review that later.
> At least, I want to see a solution for 1.
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> ________________________________________________________________
> On Oct 18, 2010, at 3:49 AM, antelder@apache.org wrote:
Re: Module dependency on features, Re: svn commit: r1023732
Posted by Simon Laws <si...@googlemail.com>.
Hi Lucinao
>
> This brings a good question, who is the target for these "aggregation
> themes" we have been working on (e.g features, shades, etc).
The objective in my mind was to define a common set of collections of
modules that brought together many of the strands of discussion that
we've been having over probably the last 12 months and be useful to
both extension developers alike. Various people have brought forward
ideas whether that be using pom type poms as an accepted way of
describing module collections, describing releasable collections using
the features idea, aggregating modules together into separate jars to
make life easier for users. These are all good things but there was no
consistency.
The thought about the new poms is a simple one. Tuscany is made up of
some core function to which extensions can be added (the word base has
been approrpriated from the shade idea to describe a very minimal set
of extensions over core such as impl.java that most people will want
in the first instance an which are required to run the basic otests).
That's it really.
As an extension developer I can create a maven dependency on
core-runtime in order to compile against, well, the core runtime
As an extension tester I can create a maven dependency on base-runtime
to get the basic support required for testing extensions
As a user I can create a classpath out of base-runtime +
myfavouriteextension-runtime in order to run my application
With the last one there are a number of ways that the user can use
this information
- as an ant fileset, that the maven bundle plugin generates for them
- as a manifest jar that the maven bundle plugin also generates for them
- manually by looking at the "which-jars" file and referencing the
jars in the modules directory
- The distro will also contain an aggregate jar for the base-runtime
so that the user can combine base-runtime + extension-rutime if they
want to
In all of this I see the 80/20 rule being important. It's very easy to
poke holes in it and point out that this dependency is not quite right
or we're missing such and such. However for 80% of the people it feels
like having a consistent approach to describing the base + extension
approach to creating a Tuscany runtime will pay dividend regarless of
how they choose to use it, e.g. ant fileset, manifest, aggregation,
what-files.
At the end of the day the user doesn't have to use this if they need a
particular configuration, They can peruse the what-files list and
concoct and alternative combination.
>To me,
> these are really targeted to end users which want to be shielded from
> knowing the Tuscany module dependency graph. Having said that, I don't
> think Tuscany modules should be using these at all, other then the
> issues already mentioned by Raymond, I wonder about the side effect on
> modularity as well as side effects the the complexity for applications
> embedding/extending the Tuscany runtime.
I haven't seen any side effects so far. The dependency on core-runtime
rather than individual modules is a convenience using the maven pomp
type pom mechanism which, as far as I know, doesn't prevent anything
else in out source code base working.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Regards
Simon
Re: Module dependency on features, Re: svn commit: r1023732
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Oct 18, 2010 at 9:39 AM, Raymond Feng <cy...@gmail.com> wrote:
> Hi,
> I saw a bunch of changes in the pom.xml for modules to replace the
> "fine-grained" dependency to "tuscany-core-runtime". I don't think it's a
> good idea for two reasons:
> 1. Features are used to describe a collection of modules. At this point,
> "modules" and "features" are under two trees. With this change, we cannot
> build the "modules" alone any more as it depends on "features".
> 2. There are more modules/jars in the tuscany-core-runtime pom than an
> extension requires, for example, databinding-json doesn't require core,
> host-http, binding-ws, etc.
> At least, I want to see a solution for 1.
> Thanks,
> Raymond
This brings a good question, who is the target for these "aggregation
themes" we have been working on (e.g features, shades, etc). To me,
these are really targeted to end users which want to be shielded from
knowing the Tuscany module dependency graph. Having said that, I don't
think Tuscany modules should be using these at all, other then the
issues already mentioned by Raymond, I wonder about the side effect on
modularity as well as side effects the the complexity for applications
embedding/extending the Tuscany runtime.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Module dependency on features, Re: svn commit: r1023732
Posted by Raymond Feng <cy...@gmail.com>.
Hi,
I saw a bunch of changes in the pom.xml for modules to replace the "fine-grained" dependency to "tuscany-core-runtime". I don't think it's a good idea for two reasons:
1. Features are used to describe a collection of modules. At this point, "modules" and "features" are under two trees. With this change, we cannot build the "modules" alone any more as it depends on "features".
2. There are more modules/jars in the tuscany-core-runtime pom than an extension requires, for example, databinding-json doesn't require core, host-http, binding-ws, etc.
At least, I want to see a solution for 1.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Oct 18, 2010, at 3:49 AM, antelder@apache.org wrote:
> Author: antelder
> Date: Mon Oct 18 10:49:36 2010
> New Revision: 1023732
>
> URL: http://svn.apache.org/viewvc?rev=1023732&view=rev
> Log:
> Update python to use base + extension approach
>
> Modified:
> tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml
>
> Modified: tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml
> URL: http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml?rev=1023732&r1=1023731&r2=1023732&view=diff
> ==============================================================================
> --- tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml (original)
> +++ tuscany/sca-java-2.x/trunk/modules/implementation-python-runtime/pom.xml Mon Oct 18 10:49:36 2010
> @@ -33,28 +33,17 @@
> <dependencies>
> <dependency>
> <groupId>org.apache.tuscany.sca</groupId>
> - <artifactId>tuscany-sca-api</artifactId>
> + <artifactId>tuscany-core-runtime</artifactId>
> + <type>pom</type>
> <version>2.0-SNAPSHOT</version>
> + <scope>provided</scope>
> </dependency>
> -
> <dependency>
> <groupId>org.apache.tuscany.sca</groupId>
> <artifactId>tuscany-implementation-python</artifactId>
> <version>2.0-SNAPSHOT</version>
> + <scope>provided</scope>
> </dependency>
> -
> - <dependency>
> - <groupId>org.apache.tuscany.sca</groupId>
> - <artifactId>tuscany-core</artifactId>
> - <version>2.0-SNAPSHOT</version>
> - </dependency>
> -
> - <dependency>
> - <groupId>org.apache.tuscany.sca</groupId>
> - <artifactId>tuscany-databinding</artifactId>
> - <version>2.0-SNAPSHOT</version>
> - </dependency>
> -
> <dependency>
> <groupId>org.python</groupId>
> <artifactId>jython</artifactId>
>
>