On 1/3/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Rajini Sivaram wrote:
> >
> > Why would you want to add implementation-data-api.jar and derby.jar as
> > contributions rather than as maven (and Eclipse) project dependencies?
>
> Here's the scenario:
> 1. Contribution store.jar imports classes from contribution assets.jar.
> 2. Classes in assets.jar depend on foo.jar (derby.jar in my example but
> could be any JAR containing runtime and/or business classes).
Sorry, I was confused because I saw implementation-data-api.jar and thought
it was a Tuscany runtime dependency rather than an internal dependency of
assets.jar.
(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.
(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?
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? What if foo.jar requires another bar.jar? Will
foo.jarautomatically import all classes from all contributions (
bar.jar and even assets.jar since there is no dependency list for foo)?
With
> > tuscany-implementation-data-api and derby as dependencies in pom.xml,
> I am
> > able to run LaunchStore without any exceptions (from Eclipse with the
> > .classpath file generated from the modified pom.xml).
>
> Sure, it works for me too, but defeats the purpose of SCA contributions,
> as a user of assets.jar I shouldn't have to know about its dependencies
> on other jars.
I am not sure I understand what you meant by "as a user of assets.jar I
shouldn't have to know".
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);
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)?
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. 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.
--
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Thank you...
Regards,
Rajini
