tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Date Fri, 04 Jan 2008 20:19:47 GMT
Comments inline.

>> On 1/3/08, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:
>> (1) and (2) should work the same way. Requiring internal dependencies of
>> assets.jar to be added to the classpath defeats the purpose of using SCA
>> contributions.
> 
> Rajini Sivaram wrote:
> (1) store.jar finds classes from assets.jar only if the package containing
> the class is exported by assets.jar (the provider of the package decided to
> export it) AND store.jar  imports the package.
> 
> How can (2) work in the same way? Will assets.jar explicitly import the
> packages from foo.jar, since it is a regular SCA contribution containing
> export/import statements in sca-contribution.xml?

Yes [1]

> 
> What about import/exports for foo.jar? foo.jar is not a regular SCA
> contribution (at least it is different because it doesn't contain
> sca-contribution.xml). Does that mean that all classes from foo.jar are
> considered exported?

I'm considering that, yes.

> What if foo.jar requires another bar.jar? Will
> foo.jar automatically import all classes from all contributions (
> bar.jar and even assets.jar since there is no dependency list for foo)?
> 

There may be a better way, but I'm thinking about defining assets.jar's 
classpath in assets.jar's sca-contribution.xml. [2]

> 
> I am not sure I understand what you meant by "as a user of assets.jar I
> shouldn't have to know".
> 

As a developer of store.jar I am using a ShoppingCart component 
implementation from assets.jar, I don't want to know that ShoppingCart 
has dependencies on derby.jar or foo.jar.

> LaunchStore (which is a user of assets.jar) does:
>         node.addContribution("http://org/apache/derby", derbyContribution);
>         node.addContribution("
> http://org/apache/tuscany/implementation-data-api", dataAPIContribution);
>         node.addContribution("http://assets", assetsContribution);
> 

and I should not have to write the above code at all :) [3]

> What is the knowledge that you can do without by adding a dependency as a
> contribution? Unless there is proper provisioning for SCA contributions
> where I can install assets.jar and derby.jar and
> implementation-data-api.jarget automatically installed, I dont see any
> difference in terms of what a
> user needs to know between adding non-SCA contributions as contributions and
> adding them as entries in the thread context classloader. As far as I can
> tell, the difference between contributions and classpath is in package
> visibility scoping which can be explicitly specified for contributions, but
> is free for all with classpath. But won't these rules be diluted by enabling
> internal dependencies to be added as contributions in their own right
> without imposing any visibility restrictions (almost as if they have been
> added to classpath)?

Sorry I'm not able to parse that long question, could you please 
summarize it?

> 
> IMHO, assets.jar should have some way of specifying that it wants to import
> classes from foo.jar - either an explicit import statement, or a dependency
> on another contribution, which makes the assets contribution classloader
> search foo's contribution classpath.

Yes, same as the "Yes [1]" above.

And foo.jar should preferably be able
> to specify its dependencies on other contributions/jars using the node API
> rather than through sca-contribution.xml.
> 

See [2] and [3], I need a reasonable approach to existing JARs and cut 
on the API calls.

To summarize, I'm suggesting that:
- SCA contributions must list dependencies in sca-contribution.xml
- existing JARs with no sca-contribution.xml export all their classes
- most of the code currently in LaunchStore should be automated/hidden

--
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message