[VOTE] Release Tuscany Bundle Plugin 1.0.8 RC1

[ant elder]

Please vote on releasing the Tuscany Bundle Plugin module 1.0.8 (RC1).

The change over the 1.0.7 release is to rename the module from
maven-bundle-plugin to tuscany-bundle-plugin, see TUSCANY-3861.

The tag for the release is:
https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/tuscany-bundle-plugin-1.0.8

The Maven staging repository is:
http://people.apache.org/~antelder/tuscany/tuscany-bundle-plugin-1.0.8-RC1

+1 from me.

  ...ant

Re: Issue with policy intents and shared implementations

[Simon Laws]

>
> A) I disagree that we only have to check the binding. The appliesTo
> XPath expression could potentially point to any element in the
> composite. Also, consider the case where an intent is specified on a
> higher level element:
> 
>   
> 
>
> "myIntent" could potentially not apply here, but we wouldn't be
> checking it if we only check the binding.

While I agree that you can attach to anywhere I doesn't seem to make
sense to applyTo anywhere but bindings and implementations. The spec
says

388 PolicySet authors need to be aware of the evaluation of the
@appliesTo attribute in order to designate
389 meaningful values for this attribute. Although policySets can be
attached to any element in an SCA
390 composite, the applicability of a policySet is not scoped by where
it is attached in the SCA framework.
391 Rather, policySets always apply to either binding instances or
implementation elements regardless of where they are attached.

So while technically you can describe and XPath statement that points
to anywhere in the composite I don't know what it means if the
appliesTo field doesn't point to an implementation or a binding.

>
> B) The binding policy sets will not encompass the full set of policy
> sets inherited by the endpoint, but the idea is that we will check
> every element that the endpoint has inherited from (I don't think this
> is correct today, as the component is missing.)

The endpoint should contain all of the policy sets that are applicable
to the binding up to this stage. The "inheritance" processing uses the
endpoint as the point of aggregation.
>
> C) It's called from within the loop because "policySetsToRemove" is
> the set of policy sets on the service which do not apply to the
> endpoint, and it needs to be removed from each endpoint underneath the
> service.

Ah OK, I get it. I still don't think we need it though.

> The code you listed I think would be correct if we assume that
> appliesTo can only reference a binding element (and implementations,
> though we don't care about that here.) Maybe we should be doing this
> (it would make sense), but without that limit in the spec I don't
> think we can assume it.

I think that is what the spec says.

>
> I'll take a look at the CTS failures.. I wouldn't expect them to be
> related to the changes to the appliesTo builder because those should
> only affect services with multiple endpoints, but there have certainly
> been some other changes that could break them.

Right, am looking too.

>
> Brent
>



-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Issue with policy intents and shared implementations

[Brent Daniel]

On Mon, Jun 20, 2011 at 3:42 AM, Simon Laws  wrote:
>>
>> Simon,
>>
>> Maybe I'm not understanding you, but I think this is working as it
>> should. We are forced to use a two step process, but the policies do
>> get removed from the EPs/EPRs.
>>
>> On the EP side, we loop through the list of component services and see
>> if we need to remove any policy sets. If we do, we also remove the
>> same policy sets from the endpoints for the service (since the
>> endpoints will have inherited the policy sets earlier in the build
>> process.)
>>
>> I think we're kind of stuck with this as it is -- the appliesTo
>> processing can not directly apply to the EP/EPR because it is XPath
>> based and needs to work against the actual composite model. We also
>> can't move it to occur prior to inheritance because it is legal to
>> specify a policy set on an element where it does not apply and have it
>> be inherited by an element where it does apply.
>>
>> Brent
>>
>
> Hi Brent
>
> I agree both that we have to run the appliesTo processing after the
> inheritance processing and that the XPath has to be applied against
> the composite model and not endpoints. I note that there were some
> recent changes to the code but looking at the current code for the
> part that deals with the EP
>
> 1               for (ComponentService componentService : 
> component.getServices()) {
> 2                       List policySetsToRemove =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> componentService, componentService.getPolicySets());
> 3                       for (Endpoint ep : componentService.getEndpoints()) {
> 4                           ep.getPolicySets().removeAll(policySetsToRemove);
> 5                               if (ep.getBinding() instanceof PolicySubject) 
> {
> 6                                   List bindingPolicySetsToRemove 
> =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> (PolicySubject)ep.getBinding(),
> ((PolicySubject)ep.getBinding()).getPolicySets());
> 7                                   
> ep.getPolicySets().removeAll(bindingPolicySetsToRemove);
> 8                               }
> 9                       }
> 10              }
>
> A) during the policy processing all of the policies that are relevant
> to the EP, regardless of where they are attached, should be
> accumulated on the endpoint by this stage so I don't see the need to
> check both the service and the binding. The only thing we need to
> check is the binding as the applies to will, I believe, only refer to
> binding or implementation types.
>
> B) passing in ((PolicySubject)ep.getBinding()).getPolicySets()) as the
> set of policy sets to check is not correct I believe because it will
> not hold the full set of policy sets aggregated at the EP
>
> C) why is ep.getPolicySets().removeAll(policySetsToRemove); called
> inside the loop. From A) and B) I don't think this line is required at
> all now.
>
> So I think we can reduce the above to
>
>                for (ComponentService componentService : 
> component.getServices()) {
>                        for (Endpoint ep : componentService.getEndpoints()) {
>                                if (ep.getBinding() instanceof PolicySubject) {
>                                    List policySetsToRemove =
> checkAppliesToSubject(document, appliesToSubjects, topComposite,
> (PolicySubject)ep.getBinding(), ep.getPolicySets());
>                                    
> ep.getPolicySets().removeAll(policySetsToRemove);
>                                }
>                         }
>                }
>
> Note. I still check against the binding model but get the policy sets
> from the EP. Similar changes would apply to reference also.
>
> With the code as it currently is in svn I'm getting failures in the
> policy compliance tests 9006, 9009, 9019, 9020, 9021. For 9006 it was
> expecting an exception and the test is now running successfully. Not
> sure which changes it's related to so I'll look at bit more closely as
> I've been changing policy stuff as well.
>
> Regards
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

A) I disagree that we only have to check the binding. The appliesTo
XPath expression could potentially point to any element in the
composite. Also, consider the case where an intent is specified on a
higher level element:

   


"myIntent" could potentially not apply here, but we wouldn't be
checking it if we only check the binding.

B) The binding policy sets will not encompass the full set of policy
sets inherited by the endpoint, but the idea is that we will check
every element that the endpoint has inherited from (I don't think this
is correct today, as the component is missing.)

C) It's called from within the loop because "policySetsToRemove" is
the set of policy sets on the service which do not apply to the
endpoint, and it needs to be removed from each endpoint underneath 

[jira] [Commented] (TUSCANY-3522) [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, CouchDB, Hadoop/Hbase

[Florian Moga (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051951#comment-13051951
 ] 

Florian Moga commented on TUSCANY-3522:
---

Patch applied at 
https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Eranda

> [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, 
> CouchDB, Hadoop/Hbase
> -
>
> Key: TUSCANY-3522
> URL: https://issues.apache.org/jira/browse/TUSCANY-3522
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Jean-Sebastien Delfino
>Assignee: Eranda Sooriyabandara
>  Labels: gsoc, gsoc2011, mentor
> Attachments: HBase-API.patch, alheaders.patch, couchdb-api.path, 
> fix.patch, rest-api-1.2.patch, rest-api.patch, twitapp.tar.gz
>
>
> NoSQL Datastore component
> =
> Write a portable data store component over a number of 'NoSQL' databases 
> (Apache Cassandra, Couchdb, Hadoop/Hbase and AppEngine Datastore databases.)
> This could be one component (written in Python or Java) or a set of 
> components (one per database) all implementing the same REST data store 
> interface, allowing applications to store data in different NoSQL databases 
> without having to worry about the details and API differences between the 
> databases.
> The project could start with just one or two databases and add more databases 
> as we go. This should be a really good opportunity for students to experiment 
> with these new NoSQL databases. 
> Resources:
> Tuscany
> http://tuscany.apache.org/
> Cassandra
> http://cassandra.apache.org/
> CouchDB
> http://couchdb.apache.org/
> Hadoop/HBase
> http://hadoop.apache.org/hbase/
> Appengine Datastore
> http://code.google.com/appengine/docs/python/datastore/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [GSoC] scala.implementation status

[Douglas Leite]

Hi Guilherme,

Take a look at [1] and [2], I think it might be useful for you when writing
a new implementation component type.

Regards,

[1]
http://tuscany.apache.org/sca-java-extension-development-guide.data/ExtendingTuscany1.pdf
[2]
http://tuscany.apache.org/mike-edwards-ramble-through-adding-a-new-implementation-type.html


On Mon, Jun 20, 2011 at 4:03 AM, ant elder  wrote:

> Hi Guilherme,
>
> That sounds like a comprehensive and indepth approach to the SCA Scala
> integration. You may find it a little daunting working out where and
> what in the Tuscany code you need to change and add to do it all
> though so I wonder if you should start with something quite simple
> like a very basic helloworld type app and get some of that going as a
> first step. We have a Scala helloworld from when a user was asking
> about it which just uses the standard SCA  so how
> about taking that and getting it to work using an
> ? You can find some emails about that sample at
> http://apache.markmail.org/message/zswdmbimo5al3erf
>
>   ...ant
>
> On Mon, Jun 13, 2011 at 4:02 PM, Guilherme Armigliatto
>  wrote:
> > Hello,
> >
> > I am a little behind the schudule because I am finishing my master
> course.
> > Fortunately it's finish at friday 17th! Then I will have more time to
> > dedicate to GSoC. =)
> >
> > One interesting thing I read about SCALA is that it has elements that can
> be
> > used as basis for a service-oriented software component model
> > implementation. In this way, a first mapping between SCA elements and
> SCALA
> > elements could be:
> > - components -> classes and traits
> > - services -> concrete members of a class
> > - references -> deferred members of a class
> > - composition -> mixins
> >
> > I am working on this and I will provide some pack soon.
> >
> > Regards,
> > Guilherme
> >
> > ---
> > Guilherme Moraes Armigliatto
> > Master Degree Student
> > Reasoning for Complex Data (RECOD)
> > Institute of Computing (IC), University of Campinas (UNICAMP)
> > Campinas, SP, Brazil
> >
> >
>



-- 
Douglas Siqueira Leite

[jira] [Updated] (TUSCANY-3522) [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, CouchDB, Hadoop/Hbase

[Eranda Sooriyabandara (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eranda Sooriyabandara updated TUSCANY-3522:
---

Attachment: alheaders.patch

This patch contains the missing Apache Licence headers.

> [GSoC 2011] Develop a 'NoSQL' Datastore component for Apache Cassandra, 
> CouchDB, Hadoop/Hbase
> -
>
> Key: TUSCANY-3522
> URL: https://issues.apache.org/jira/browse/TUSCANY-3522
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Jean-Sebastien Delfino
>Assignee: Eranda Sooriyabandara
>  Labels: gsoc, gsoc2011, mentor
> Attachments: HBase-API.patch, alheaders.patch, couchdb-api.path, 
> fix.patch, rest-api-1.2.patch, rest-api.patch, twitapp.tar.gz
>
>
> NoSQL Datastore component
> =
> Write a portable data store component over a number of 'NoSQL' databases 
> (Apache Cassandra, Couchdb, Hadoop/Hbase and AppEngine Datastore databases.)
> This could be one component (written in Python or Java) or a set of 
> components (one per database) all implementing the same REST data store 
> interface, allowing applications to store data in different NoSQL databases 
> without having to worry about the details and API differences between the 
> databases.
> The project could start with just one or two databases and add more databases 
> as we go. This should be a really good opportunity for students to experiment 
> with these new NoSQL databases. 
> Resources:
> Tuscany
> http://tuscany.apache.org/
> Cassandra
> http://cassandra.apache.org/
> CouchDB
> http://couchdb.apache.org/
> Hadoop/HBase
> http://hadoop.apache.org/hbase/
> Appengine Datastore
> http://code.google.com/appengine/docs/python/datastore/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TUSCANY-3879) Detailed installation tutorial for Tuscany eclipse plugin installation

[madhukara phatak (JIRA)]

Detailed installation tutorial for Tuscany eclipse plugin installation
--

 Key: TUSCANY-3879
 URL: https://issues.apache.org/jira/browse/TUSCANY-3879
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Documentation
Reporter: madhukara phatak


Wiki page for detailed tutorial for install tuscany plugin in eclipse. Wiki 
link  is here 
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+Tuscany+Plug+in+in+eclipse.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Adding installation manual to the apache tuscany site

[madhu phatak]

Jira https://issues.apache.org/jira/browse/TUSCANY-3879
Wiki
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+Tuscany+Plug+in+in+eclipse

On Mon, Jun 20, 2011 at 3:57 PM, madhu phatak  wrote:

> 6 months back*
>
>
> On Mon, Jun 20, 2011 at 3:57 PM, madhu phatak wrote:
>
>> Actually i tried tuscany 6 months using 2.0-M5 release . At that point of
>> time only 1.5. eclipse plugin was available. I used the plugin only for
>> creation maven projects like sca-deploymnent-jar . But for deployment i used
>> 2.x release . If you can give me the latest plugin url i can test and update
>> in the blog and wiki. As per site
>> http://tuscany.apache.org/updatesite/1.6.2/ is the latest site which is
>> not functional yet.
>>
>> Regards
>> Madhukara Phatak
>>
>>
>> On Mon, Jun 20, 2011 at 1:08 PM, ant elder  wrote:
>>
>>> Thats using the Tuscany 1.5.1 release which is getting pretty old now,
>>> is there a reason you need to use that release? If not it might be
>>> better to be documenting the latest releases. If you do need to be
>>> using 1.5.1 then note that over time we archive the older releases
>>> which causes the update site URL to change and thats happened to this
>>> one so you need to change the URL to
>>>
>>> http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
>>>
>>>   ...ant
>>>
>>> On Sat, Jun 18, 2011 at 5:11 PM, madhu phatak 
>>> wrote:
>>> > Hi I am writing Apache tuscany setup and usage guide
>>> > at
>>> http://computegeeken.blogspot.com/2011/06/apache-tuscany-part-1-installing.html
>>>  .
>>> > I want to add it to the apache site because the details about setup is
>>> > scarce in the site. Can anyone guide me how to do this?
>>> > Regards
>>> > Madhukar
>>>
>>
>>
>

Re: Issue with policy intents and shared implementations

[Simon Laws]

>
> Simon,
>
> Maybe I'm not understanding you, but I think this is working as it
> should. We are forced to use a two step process, but the policies do
> get removed from the EPs/EPRs.
>
> On the EP side, we loop through the list of component services and see
> if we need to remove any policy sets. If we do, we also remove the
> same policy sets from the endpoints for the service (since the
> endpoints will have inherited the policy sets earlier in the build
> process.)
>
> I think we're kind of stuck with this as it is -- the appliesTo
> processing can not directly apply to the EP/EPR because it is XPath
> based and needs to work against the actual composite model. We also
> can't move it to occur prior to inheritance because it is legal to
> specify a policy set on an element where it does not apply and have it
> be inherited by an element where it does apply.
>
> Brent
>

Hi Brent

I agree both that we have to run the appliesTo processing after the
inheritance processing and that the XPath has to be applied against
the composite model and not endpoints. I note that there were some
recent changes to the code but looking at the current code for the
part that deals with the EP

1   for (ComponentService componentService : 
component.getServices()) {
2   List policySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
componentService, componentService.getPolicySets());
3   for (Endpoint ep : componentService.getEndpoints()) {   

4   ep.getPolicySets().removeAll(policySetsToRemove);
5   if (ep.getBinding() instanceof PolicySubject) {
6   List bindingPolicySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
(PolicySubject)ep.getBinding(),
((PolicySubject)ep.getBinding()).getPolicySets());
7   
ep.getPolicySets().removeAll(bindingPolicySetsToRemove);
8   }
9   }
10  }

A) during the policy processing all of the policies that are relevant
to the EP, regardless of where they are attached, should be
accumulated on the endpoint by this stage so I don't see the need to
check both the service and the binding. The only thing we need to
check is the binding as the applies to will, I believe, only refer to
binding or implementation types.

B) passing in ((PolicySubject)ep.getBinding()).getPolicySets()) as the
set of policy sets to check is not correct I believe because it will
not hold the full set of policy sets aggregated at the EP

C) why is ep.getPolicySets().removeAll(policySetsToRemove); called
inside the loop. From A) and B) I don't think this line is required at
all now.

So I think we can reduce the above to

for (ComponentService componentService : 
component.getServices()) {
for (Endpoint ep : componentService.getEndpoints()) {
if (ep.getBinding() instanceof PolicySubject) {
List policySetsToRemove =
checkAppliesToSubject(document, appliesToSubjects, topComposite,
(PolicySubject)ep.getBinding(), ep.getPolicySets());

ep.getPolicySets().removeAll(policySetsToRemove);
}
 }
}

Note. I still check against the binding model but get the policy sets
from the EP. Similar changes would apply to reference also.

With the code as it currently is in svn I'm getting failures in the
policy compliance tests 9006, 9009, 9019, 9020, 9021. For 9006 it was
expecting an exception and the test is now running successfully. Not
sure which changes it's related to so I'll look at bit more closely as
I've been changing policy stuff as well.

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Adding installation manual to the apache tuscany site

[madhu phatak]

6 months back*

On Mon, Jun 20, 2011 at 3:57 PM, madhu phatak  wrote:

> Actually i tried tuscany 6 months using 2.0-M5 release . At that point of
> time only 1.5. eclipse plugin was available. I used the plugin only for
> creation maven projects like sca-deploymnent-jar . But for deployment i used
> 2.x release . If you can give me the latest plugin url i can test and update
> in the blog and wiki. As per site
> http://tuscany.apache.org/updatesite/1.6.2/ is the latest site which is
> not functional yet.
>
> Regards
> Madhukara Phatak
>
>
> On Mon, Jun 20, 2011 at 1:08 PM, ant elder  wrote:
>
>> Thats using the Tuscany 1.5.1 release which is getting pretty old now,
>> is there a reason you need to use that release? If not it might be
>> better to be documenting the latest releases. If you do need to be
>> using 1.5.1 then note that over time we archive the older releases
>> which causes the update site URL to change and thats happened to this
>> one so you need to change the URL to
>>
>> http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
>>
>>   ...ant
>>
>> On Sat, Jun 18, 2011 at 5:11 PM, madhu phatak 
>> wrote:
>> > Hi I am writing Apache tuscany setup and usage guide
>> > at
>> http://computegeeken.blogspot.com/2011/06/apache-tuscany-part-1-installing.html
>>  .
>> > I want to add it to the apache site because the details about setup is
>> > scarce in the site. Can anyone guide me how to do this?
>> > Regards
>> > Madhukar
>>
>
>

Re: Adding installation manual to the apache tuscany site

[madhu phatak]

Actually i tried tuscany 6 months using 2.0-M5 release . At that point of
time only 1.5. eclipse plugin was available. I used the plugin only for
creation maven projects like sca-deploymnent-jar . But for deployment i used
2.x release . If you can give me the latest plugin url i can test and update
in the blog and wiki. As per site
http://tuscany.apache.org/updatesite/1.6.2/ is the latest site which is not
functional yet.

Regards
Madhukara Phatak

On Mon, Jun 20, 2011 at 1:08 PM, ant elder  wrote:

> Thats using the Tuscany 1.5.1 release which is getting pretty old now,
> is there a reason you need to use that release? If not it might be
> better to be documenting the latest releases. If you do need to be
> using 1.5.1 then note that over time we archive the older releases
> which causes the update site URL to change and thats happened to this
> one so you need to change the URL to
>
> http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/
>
>   ...ant
>
> On Sat, Jun 18, 2011 at 5:11 PM, madhu phatak 
> wrote:
> > Hi I am writing Apache tuscany setup and usage guide
> > at
> http://computegeeken.blogspot.com/2011/06/apache-tuscany-part-1-installing.html
>  .
> > I want to add it to the apache site because the details about setup is
> > scarce in the site. Can anyone guide me how to do this?
> > Regards
> > Madhukar
>

[RESULT][VOTE] Release Tuscany Zip Plugin Alpha3 RC2

[ant elder]

Passed with three +1s from me, Florian, and Simon Laws.

   ...ant

On Fri, Jun 3, 2011 at 10:06 AM, ant elder  wrote:
> Please vote on releasing the Tuscany Zip Plugin module (RC2).
>
> The change over the alpha2 release is to rename the module from
> maven-zip-plugin to tuscany-zip-plugin, see TUSCANY-3861. This RC2
> fixes the issue Florian found with the old plugin name still being
> referenced.
>
> The tag for the release is:
> https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/tuscany-zip-plugin-alpha3
>
> The Maven staging repository is:
> http://people.apache.org/~antelder/tuscany/tuscany-zip-plugin-alpha3-RC2
>
> +1 from me.
>
>   ...ant
>

Re: [VOTE] Release Tuscany Zip Plugin Alpha3 RC2

[Simon Laws]

On Fri, Jun 17, 2011 at 12:43 PM, ant elder  wrote:
> There are two answers to that. Firstly the reason the files aren't
> included is because resource includes clause in the pom.xml only
> mentions the LICENSE/NOTICE but not the README so they don't get
> picked up in the built jar, the other reason of why its like that is
> because its never been called out that the jars we release must
> include doc files within them, so this plugin didn't on the previous
> releases and none of the other maven plugins of any of the module jars
> we've released have either.
>
> Its obviously just an oversight and it seems reasonable that those doc
> files would be included and so I've updated trunk for this plugin so
> that they will get included on the next release, but should this block
> this release? IMHO it shouldn't as we've not required it for any other
> jars we've released in the past, leaving this to the next release to
> fix seems ok to me. So I'm hoping someone will still give another +1
> on this vote thread.
>
>   ...ant
>
> On Fri, Jun 17, 2011 at 11:59 AM, Mike Edwards
>  wrote:
>> Ant,
>>
>> Why is this famed README not in either of the jar files:
>>
>> tuscany-zip-plugin-alpha3.jar
>> tuscany-zip-plugin-alpha3-sources.jar
>>
>>
>> Yours,  Mike.
>>
>>
>> On 17/06/2011 11:32, ant elder wrote:
>>>
>>> The most comprehensive doc is in the README file, IIRC thats mostly
>>> written by your good self Mike.
>>>
>>>    ...ant
>>>
>>
>>
>>
>>
>

I've tried it and the plugin works. As for the README It is an
oversight that it's not in there but not enough for me to vote against
it so +1 for this release.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Adding installation manual to the apache tuscany site

[ant elder]

Thats using the Tuscany 1.5.1 release which is getting pretty old now,
is there a reason you need to use that release? If not it might be
better to be documenting the latest releases. If you do need to be
using 1.5.1 then note that over time we archive the older releases
which causes the update site URL to change and thats happened to this
one so you need to change the URL to
http://archive.apache.org/dist/tuscany/java/sca/1.5.1/tuscany-sca-1.5.1-updatesite/

   ...ant

On Sat, Jun 18, 2011 at 5:11 PM, madhu phatak  wrote:
> Hi I am writing Apache tuscany setup and usage guide
> at http://computegeeken.blogspot.com/2011/06/apache-tuscany-part-1-installing.html .
> I want to add it to the apache site because the details about setup is
> scarce in the site. Can anyone guide me how to do this?
> Regards
> Madhukar

Re: Adding installation manual to the apache tuscany site

[Simon Laws]

On Sun, Jun 19, 2011 at 12:05 AM, Luciano Resende  wrote:
> On Sat, Jun 18, 2011 at 9:11 AM, madhu phatak  wrote:
>> Hi I am writing Apache tuscany setup and usage guide
>> at http://computegeeken.blogspot.com/2011/06/apache-tuscany-part-1-installing.html .
>> I want to add it to the apache site because the details about setup is
>> scarce in the site. Can anyone guide me how to do this?
>> Regards
>> Madhukar
>
> Thanks Madhukar, documentation contributions are very welcome. You
> could create a wiki page on [1] with the contents you want to
> contribute and we would move to the website. I'd also recommend a JIRA
> with a link to the wiki page, as this can count as a history of your
> contributions.
>
>
> [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

Excellent. Thanks Madhukar. Look forward to reading it.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [GSoC] scala.implementation status

[ant elder]

Hi Guilherme,

That sounds like a comprehensive and indepth approach to the SCA Scala
integration. You may find it a little daunting working out where and
what in the Tuscany code you need to change and add to do it all
though so I wonder if you should start with something quite simple
like a very basic helloworld type app and get some of that going as a
first step. We have a Scala helloworld from when a user was asking
about it which just uses the standard SCA  so how
about taking that and getting it to work using an
? You can find some emails about that sample at
http://apache.markmail.org/message/zswdmbimo5al3erf

   ...ant

On Mon, Jun 13, 2011 at 4:02 PM, Guilherme Armigliatto
 wrote:
> Hello,
>
> I am a little behind the schudule because I am finishing my master course.
> Fortunately it's finish at friday 17th! Then I will have more time to
> dedicate to GSoC. =)
>
> One interesting thing I read about SCALA is that it has elements that can be
> used as basis for a service-oriented software component model
> implementation. In this way, a first mapping between SCA elements and SCALA
> elements could be:
> - components -> classes and traits
> - services -> concrete members of a class
> - references -> deferred members of a class
> - composition -> mixins
>
> I am working on this and I will provide some pack soon.
>
> Regards,
> Guilherme
>
> ---
> Guilherme Moraes Armigliatto
> Master Degree Student
> Reasoning for Complex Data (RECOD)
> Institute of Computing (IC), University of Campinas (UNICAMP)
> Campinas, SP, Brazil
>
>