Rajini Sivaram wrote:
[snip]
I dont know the code well enough to understand how
these contributions are used/loaded/resolved etc. But yes, it will be good
to stop manipulating URLs to locate contributions.
+1, if I understand correctly, the scenario discussed here is like this:
Bob, application developer, writes Java code to bootstrap Tuscany and
load some SCA contributions into it, before starting his composites.
With the current API, Bob's code needs to do something like:
TuscanySomething.addContribution(<location of the contribution>)
Bob can't seriously hardcode the location of the contribution:
- C:\Bob's Dir\aContribution.jar is only going to work on Bob's machine.
- At development time the location is also different, something like
C:\Bob's IDE workspace\aProject\bin.
- When Bob builds with Maven the location is probably different again
C:\Bob's build Dir\target\classes.
Bob didn't want to have to write 3 different classes for these 3 cases,
so he put his SCA contribution on his classpath and wrote (almost)
portable code to locate it (by looking for a known resource on the
classpath and getting the location of the contribution from the
resource's URL).
This is a hack around an inconvenient Tuscany bootstrap API which
requires the app developer to give the location of his contributions.
How about trying to attack the real problems IMO:
- Bob shouldn't have to specify a location in the first place, he should
be able to identify his contributions by contribution logical URI.
- or even better, Bob should not have to write any code to bootstrap the
runtime and list contributions in the first place.
- and Bob shouldn't have to put his SCA contributions on his VM's
classpath either (see the Store tutorial for an example, where the store
contribution references the assets contribution without a classpath
dependency on it).
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
