ant elder wrote:
On 5/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Comments inline.

Luciano Resende wrote:
> So, just to make clear, the plan here, while using sca-contribution,
> is to
> call SCADomain.newInstance(String DomainURI) and then we would require
> sca-contribution to be available, so we can find the root of the
> contribution, and then we would get deployables from that ?

Yes

>
> What should be the behaviour if no sca-contribution is specified ? the
> SCA
> spec does mention this file is optional. Also, what we do if no
> deployables
> is specified ?

If you don't give any deployable composites to newInstance and you don't
have any deployables in an sca-contribution.xml, you end up with an
empty domain, that's all.

>
> For a sample using sca-contribution.xml, what do you want to
> demonstrate in
> particular with this sample ?
>

How about specifying deployables :) I see two interesting use cases:
- the webapp sample
- the implementation-composite sample, where you'll list only the outer
composite as deployable, showing that the inner composite is not a
deployable.

> On 5/15/07, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> On 5/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> >
>> > [snip]
>> > ant elder wrote:
>> > > Here's todays weekly IRC chat log. The only topic discussed was the
>> > > SCA 0.90release, the current plan is to cut a
>> > > 0.90 release branch this Wednesday.
>> > >
>> > > We went through the open JIRA's targeted at 0.90 to see if anyone
>> wanted
>> > > particular JIRA's as must fix for 0.90 and which ones could be
>> > > defered. The
>> > > current JIRA's for 0.90 are:
>> > >
>> >
>>
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312478
>>
>> > >
>> > > . Tomorrow I'm going to move all of those out of 0.90 except for
>> > > TUSCANY-1247, TUSCANY-1248, and TUSCANY-1265.  If anyone has any
>> others
>> > > which should be in 0.90 just say.
>> > >
>> > > The samples were also discussed, sounds like most of them are
ready,
>> > > there's
>> > > some issues around the those related to how to write Tuscany
>> extensions,
>> > > discussion will continue on the mailing list.
>> > >
>> > > Venkat will run RAT against the current distro's and email the
>> mailing
>> > > list
>> > > the results, slaws will try the distro's on linux.
>> > >
>> > > The latest distributions built of the trunk code as of just now
>> > (r537917)
>> > > are at:
>> > > http://people.apache.org/~antelder/tuscany/latest/<
>> > http://people.apache.org/%7Eantelder/tuscany/latest/>.
>> > >
>> > > Please try these out and report any issues (or even just that you
>> > > tried and
>> > > a sample worked!)
>> > >
>> > >   ...ant
>> > >
>> >
>> > Sorry that I missed yesterday's IRC chat. I have a few more things to
>> > add to our TODO list for the release:
>> >
>> > I'd like to have in the binary distro a JAR containing the Tuscany
>> > source that people can attach to the Tuscany JAR for debugging in
>> an IDE
>> > (we already discussed this on the list but can't find the thread
now).
>>
>>
>> Could just the src distribution be used for this for 0.90? I've just
>> tried
>> and Eclipse works fine using that as the src for the Tuscany all jar.
>>
>>
>> > I am not sure where we are with our Webapp story. If we go with the
>> > context listener approach, we need to adjust it to take its
>> > configuration and list of deployables from sca-contribution.xml
>> instead
>> > of web.xml. If we go with another approach we need to adjust the
>> sample.
>> >
>> > For consistency, SCADomain.newInstance() should also work without a
>> list
>> > of composites and take its configuration from sca-contribution.xml if
>> > there is one.
>> >
>> > We need some samples to show sca-contribution.xml (adjust some of the
>> > existing samples).
>> >
>> > The above items are important IMO as they touch APIs used by
>> application
>> > developers.
>>
>>
>> I've taken all the config based on init-params out of the webapp host
so
>> currently it just uses whatever composites it finds in the top-level
>> classes
>> folder of the webapp. The calculator-web sample works with this and
>> doesn't
>> specify any special config. is this not enough for 0.90?

Making all composites deployable is going to break in most cases.


Its not *all* composites, its only those in the top level folder, can't the
ones that shouldn't be deployed just go somewhere else?

Anyway, I'm find with the sca-contrabution.xml approach if someone can get
it done soon.

  ...ant


Ah OK, I missed that. I think it would be fine as a default convention if sca-contribution.xml is not present, if we could make it work consistently, with JARs as well as WARs, but I'm not sure how this would work in a JAR, which is the default packaging for SCA contributions. How would you determine the actual location of the contribution root if it's given to you as a JAR present on your classpath?

If we can't make that convention work with JARs, then we may have to use a fixed composite file name as a convention, I'd suggest /deployable.composite.

Thoughts?

--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to