Comments inline.
On 1/3/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
