You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/05/15 17:22:38 UTC
More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log
14 May 2007
[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).
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.
One of the goals of this release is stable SPIs. I have reviewed them
and there a few things that I think need to be fixed now to avoid
disrupting changes after the release.
- Package o.a.t.sca.scope is not clean or finalized IMO and since it's
currently only used by the core and implementation-java-runtime modules
I think we should move it to the core module and mature it there, we can
move it back to SPI when it has become a clean SPI.
- Same comment for o.a.t.sca.factory.
- o.a.t.Message has setWire/getWire methods with a FIXME comment
indicating that these methods should be removed, can we remove them now?
- Some of the factories and common runtime services are hardcoded in the
ModuleActivators. The ModuleActivators need a way to get these objects
from the runtime (maybe from the ExtensionPointRegistry) instead of
having to new them up.
I also took a look at the Javadoc for the SPIs and we need to spend some
time fixing it, as some of the Javadoc comments are obsolete or incorrect.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat
log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> Following on from Jean-Sebastien's SPI point. There are still open
> issues,
> e.g. [1] related to SPIs that we choose to put where. I'm only now
> getting
> to grips with what has been done in the reorganization effort
> (apologies for
> not keeping up) and am spotting some things that, on the face of it,
> don't
> seem obvious, e.g. I was looking at one of the extension processors
> and it
> extends BaseArtifactProcessor which is in o.a.t.assembly.xml and not
> obviously identified as something I should extend.
That's because BaseArtifactProcessor is not an SPI. It's a base
implementation class, which should not be used or extended directly by
Tuscany extensions. I think that the few processors that use it should
be fixed to not extend BaseArtifactProcessor anymore.
> Now I fully expect that
> when I write an extension I'll just copy one that already exists and not
> think any more about it. However what we are hoping to do next is have
> people try this SPI and implement new extensions. In my experience this
> means they they will find problems and we will have to consider
> changing it.
> So my question now is (you knew I would get there eventually) how
> stable is
> stable?
It's too early to speculate. Let's see if people run into any problems,
address any concrete problems then and try to do it without breaking our
SPIs.
>
> Simon
>
> [1] http://issues.apache.org/jira/browse/TUSCANY-1281
>
TUSCANY-1281 issue can be fixed with changes in the implementation
packages, without changing the SPIs themselves.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Simon Laws <si...@googlemail.com>.
Following on from Jean-Sebastien's SPI point. There are still open issues,
e.g. [1] related to SPIs that we choose to put where. I'm only now getting
to grips with what has been done in the reorganization effort (apologies for
not keeping up) and am spotting some things that, on the face of it, don't
seem obvious, e.g. I was looking at one of the extension processors and it
extends BaseArtifactProcessor which is in o.a.t.assembly.xml and not
obviously identified as something I should extend. Now I fully expect that
when I write an extension I'll just copy one that already exists and not
think any more about it. However what we are hoping to do next is have
people try this SPI and implement new extensions. In my experience this
means they they will find problems and we will have to consider changing it.
So my question now is (you knew I would get there eventually) how stable is
stable?
Simon
[1] http://issues.apache.org/jira/browse/TUSCANY-1281
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat
log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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 <an...@gmail.com> wrote:
>> >>
>> >> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by ant elder <an...@gmail.com>.
On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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 <an...@gmail.com> wrote:
> >>
> >> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat
log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <an...@gmail.com> wrote:
>>
>> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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. If you
have 2 composites A and B for example:
- if A includes B, then you'll get an error (name collision) if you try
to add both A and B to the domain
- if A uses B as an implementation, then you'll get unexpected
application behavior as the intent of the application developer is to
use B as a nested implementation and not a set of top level components.
Also, if you intented to use a particular contribution as a vehicle for
implementation artifacts (composites + other things) then chances are
that you won't have an sca-contribution.xml file in it, and
automatically adding all composites to the domain and activating all the
components they contain at the domain level is going to be pretty
unexpected as well.
>> If not then is
>> there anyone who volunteers to add the sca-contribution.xml (and when
>> can
>> they get it done?) ?
>>
>> ...ant
>>
>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Luciano Resende <lu...@gmail.com>.
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 ?
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 ?
For a sample using sca-contribution.xml, what do you want to demonstrate in
particular with this sample ?
On 5/15/07, ant elder <an...@gmail.com> wrote:
>
> On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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? If not then is
> there anyone who volunteers to add the sca-contribution.xml (and when can
> they get it done?) ?
>
> ...ant
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by ant elder <an...@gmail.com>.
On 5/15/07, Jean-Sebastien Delfino <js...@apache.org> 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? If not then is
there anyone who volunteers to add the sca-contribution.xml (and when can
they get it done?) ?
...ant
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Raymond Feng <en...@gmail.com>.
Hi,
As the o.a.t.s.scope and o.a.t.s.factory packages in the core-spi are in the
grey area, I'll move them into core for now and keep the package names
as-is. We could revisit this later when the requirements become clearer.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 15, 2007 8:22 AM
Subject: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log
14 May 2007
> [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).
>
> 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.
>
> One of the goals of this release is stable SPIs. I have reviewed them and
> there a few things that I think need to be fixed now to avoid disrupting
> changes after the release.
> - Package o.a.t.sca.scope is not clean or finalized IMO and since it's
> currently only used by the core and implementation-java-runtime modules I
> think we should move it to the core module and mature it there, we can
> move it back to SPI when it has become a clean SPI.
> - Same comment for o.a.t.sca.factory.
> - o.a.t.Message has setWire/getWire methods with a FIXME comment
> indicating that these methods should be removed, can we remove them now?
> - Some of the factories and common runtime services are hardcoded in the
> ModuleActivators. The ModuleActivators need a way to get these objects
> from the runtime (maybe from the ExtensionPointRegistry) instead of having
> to new them up.
>
> I also took a look at the Javadoc for the SPIs and we need to spend some
> time fixing it, as some of the Javadoc comments are obsolete or incorrect.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat
log 14 May 2007
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Raymond Feng wrote:
> Hi,
>
> I have now refactored the RuntimeWire.Source and RuntimeWire.Target
> into a new interface EndpointReference uner r538339. The Message
> interface now has the following methods:
>
> public interface Message {
> ...
> EndpointReference<RuntimeComponentReference> getFrom();
> void setFrom(EndpointReference<RuntimeComponentReference> from);
> EndpointReference<RuntimeComponentService> getTo();
> void setTo(EndpointReference<RuntimeComponentService> to);
> }
>
> The EndpointReference can be later on used to implement the
> CallableReference/ServiceReference and it can be serialized as URI to
> represent an endpoint.
>
> Please let me know your opinions.
>
> Thanks,
> Raymond
>
Do we absolutely need these generics? What if we wanted to send a
message back to a client, we probably wouldn't have a component service
to send the message to, right?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log 14 May 2007
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have now refactored the RuntimeWire.Source and RuntimeWire.Target into a
new interface EndpointReference uner r538339. The Message interface now has
the following methods:
public interface Message {
...
EndpointReference<RuntimeComponentReference> getFrom();
void setFrom(EndpointReference<RuntimeComponentReference> from);
EndpointReference<RuntimeComponentService> getTo();
void setTo(EndpointReference<RuntimeComponentService> to);
}
The EndpointReference can be later on used to implement the
CallableReference/ServiceReference and it can be serialized as URI to
represent an endpoint.
Please let me know your opinions.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 15, 2007 8:22 AM
Subject: More TODOs for the 0.90 release, was: Tuscany weekly IRC chat log
14 May 2007
> [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).
>
> 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.
>
> One of the goals of this release is stable SPIs. I have reviewed them and
> there a few things that I think need to be fixed now to avoid disrupting
> changes after the release.
> - Package o.a.t.sca.scope is not clean or finalized IMO and since it's
> currently only used by the core and implementation-java-runtime modules I
> think we should move it to the core module and mature it there, we can
> move it back to SPI when it has become a clean SPI.
> - Same comment for o.a.t.sca.factory.
> - o.a.t.Message has setWire/getWire methods with a FIXME comment
> indicating that these methods should be removed, can we remove them now?
> - Some of the factories and common runtime services are hardcoded in the
> ModuleActivators. The ModuleActivators need a way to get these objects
> from the runtime (maybe from the ExtensionPointRegistry) instead of having
> to new them up.
>
> I also took a look at the Javadoc for the SPIs and we need to spend some
> time fixing it, as some of the Javadoc comments are obsolete or incorrect.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org