Declarative DAS - Exposing data as Services

[Luciano Resende]

In the past, we have discussed Declarative DAS [1], for those that are
not familiar with the past discussions, you can find a quick summary
at [2].

Basically, Declarative DAS extends the SCA programming model to expose
services that interact with a persistent layer in a declarative
fashion hiding the implementation details from the service
developer.It's all about simplicity, allowing a service to be defined
without explicitly coding the persistence layer.

I have added a first cut of this under revision #547551 . The
implementation.das right now only supports static services interfaces.
My plans is to expand the implementation to handle all crud operations
and also dynamic interfaces. I'd also like to add a quick sample that
would retrieve the data from it's repository using the
implementaiton.das and then use then play with how it could be
integrated with the feed binding or json-rpc binding. Stay tunned as
these are all coming in the near future...

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09978.html
[2] http://lresende.blogspot.com/2007/01/declarative-data-access-services.html

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: [DAS] Status of DAS Release

[Luciano Resende]

Thanks Amita for looking into this...
I have fixed the distribution issue as in TUSCANY-1348, and the
logging issue as in TUSCANY-1349. I also noticed an issue with logging
in dbConfig, where we were not checking if logging was enabled and
always calling log, and I have also fixed that.

Please let me know if things are looking better now.

On 6/14/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:

Small update, tried to build and test with empty repos and it went through
with no issues.

Regards,
Amita

On 6/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> Things tested to be working -
> all UT as part of mvn build
> all samples in different browsers.
>
> Apart from das\distribution\binary\pom.xml - change and documentation
> changes in JIRA 1335, I have a doubt in logging mechanism in web samples.
>
> In DBConfig utility , the code uses Logger.getLogger(className) - to get
> logger from log4j.
>
> Whereas in all RDB DAS code, it is
> LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS
> util.
> In this, the level is OFF - hardcoded in the code.
>
> So, when the log4j.properties file is used in tomcat to switch on logging,
> the logging works for DBConfig (as it is using direct log4j), but logging
> does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB
> DAS jar.
>
> Is this the desired behavior? Will there be any need to switch on logging
> in web samples for RDB DAS code and how to do it without touching
> tuscany-das-rdb-1.0-incubating.jar?
>
> Regards,
> Amita
>
> On 6/11/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Hi All,
> >
> > When tried mvn -Pdistribution on das:-
> > das\distribution\binary\pom.xml - does not list ajax web sample under
> > dependency and thus does not package same
> >
> > As now, non-committer does not have access to edit wiki, I have created
> > JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please
> > see how these can be completed using attached zipped files.
> >
> > Architecture Guide - 
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide
> >
> > images to upload - ClassDiag.jpg, rdbDAS.gif
> >
> > User Guide -
> > http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide
> > Under Samples(See Capabilities in use)
> > Put links for:-
> > Web Sample -
> > 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm
> > J2SE Sample -
> > 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm
> > Advanced Web Sample - 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm
> >
> >
> > Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki
> >
> > need to checkin under 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE
> > NOTES
> > RELEASE_NOTES.txt
> >
> > About to complete CHANGES.txt , will add by eod to JIRA 1335..
> >
> > Regards,
> > Amita
> >
> > On 6/10/07, Adriano Crestani <[EMAIL PROTECTED] > wrote:
> > >
> > > I went through all das samples and they seem to be working fine on
> > > Windows
> > > XP Home Edition SP 2 environment. I also corrected some links on
> > > readmes
> > > that were pointing to old tuscany website.
> > >
> > > I ran the rat on java/das directory and added Apache Licence header to
> > > files
> > > that were missing it.
> > >
> > > Regards,
> > > Adriano Crestani
> > >
> > > On 6/8/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > > >
> > > > First of all, let me thank you all for helping on this release.
> > > > Recently there has been a lot of progress, and things are looking
> > > good
> > > > from the list of issues we had listed in the wiki [1]. The remaining
> > > > documentation tasks could probably go in parallel with the release
> > > > candidates. So, we should start thinking about creating a branch for
> > > > the next release sometime soon, probably over the weekend or Monday
> > > > and then start publishing release candidates from that.
> > > >
> > > > Also, I think we should look into the following items before we
> > > create
> > > > the first RC :
> > > >
> > > >- run rat and make the results available
> > > >- review the contents of license, readme, release_notes, changes,
> > > etc
> > > >- review javadoc
> > > >- make sure samples readme are updated and correct and the
> > > samples
> > > > are working ok on different environments
> > > >
> > > > I'd also like to suggest two other things :
> > > >- Name the release beta1, to be aligned with the beta1 release of
> > > SDO.
> > > >- Any blocking issue to be tracked as blocking JIRA and directly
> > > > assigned to beta1 release.
> > > >
> > > > Does this sound ok to everyone?  Any Thoughts ?
> > > >
> > > >
> > > > [1]
> > > > 
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+Beta1+Release
> > >
> > > >
> > > >
> > > > --
> > > > Luciano Resende
> > > 

[jira] Resolved: (TUSCANY-1349) Log4j integration is broken due to forced debug level=OFF inside internal logger factory

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-1349.
--

Resolution: Fixed

Removed logger factory and we are now calling log4j factory directly without 
specifying any default behaviour (like default debug level), as this was 
causing issues during enable of the log trough log4j properties file.

Fixed under revision #547538

> Log4j integration is broken due to forced debug level=OFF inside internal  
> logger factory
> -
>
> Key: TUSCANY-1349
> URL: https://issues.apache.org/jira/browse/TUSCANY-1349
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS RDB
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-DAS-beta1
>
>
> In DBConfig utility , the code uses Logger.getLogger(className) - to get
> logger from log4j.
> Whereas in all RDB DAS code, it is
> LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS
> util.
> In this, the level is OFF - hardcoded in the code.
> So, when the log4j.properties file is used in tomcat to switch on logging,
> the logging works for DBConfig (as it is using direct log4j), but logging
> does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB
> DAS jar.
> Is this the desired behavior? Will there be any need to switch on logging in
> web samples for RDB DAS code and how to do it without touching
> tuscany-das-rdb-1.0-incubating.jar?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1349) Log4j integration is broken due to forced debug level=OFF inside internal logger factory

[Luciano Resende (JIRA)]

Log4j integration is broken due to forced debug level=OFF inside internal  
logger factory
-

 Key: TUSCANY-1349
 URL: https://issues.apache.org/jira/browse/TUSCANY-1349
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS RDB
Affects Versions: Java-DAS-beta1
Reporter: Luciano Resende
Assignee: Luciano Resende
 Fix For: Java-DAS-beta1


In DBConfig utility , the code uses Logger.getLogger(className) - to get
logger from log4j.

Whereas in all RDB DAS code, it is
LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS
util.
In this, the level is OFF - hardcoded in the code.

So, when the log4j.properties file is used in tomcat to switch on logging,
the logging works for DBConfig (as it is using direct log4j), but logging
does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB
DAS jar.

Is this the desired behavior? Will there be any need to switch on logging in
web samples for RDB DAS code and how to do it without touching
tuscany-das-rdb-1.0-incubating.jar?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1348) DAS binary distribution missing sample-ajax-das sample application

[Luciano Resende (JIRA)]

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

Luciano Resende resolved TUSCANY-1348.
--

Resolution: Fixed

Fixed by adding the new sample to the distribution under rev #547529

> DAS binary distribution missing sample-ajax-das sample application
> --
>
> Key: TUSCANY-1348
> URL: https://issues.apache.org/jira/browse/TUSCANY-1348
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java DAS Samples
>Affects Versions: Java-DAS-beta1
>Reporter: Luciano Resende
>Assignee: Luciano Resende
> Fix For: Java-DAS-beta1
>
>
> When tried mvn -Pdistribution on das:-
> das\distribution\binary\pom.xml - does not list ajax web sample under
> dependency and thus does not package same

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1348) DAS binary distribution missing sample-ajax-das sample application

[Luciano Resende (JIRA)]

DAS binary distribution missing sample-ajax-das sample application
--

 Key: TUSCANY-1348
 URL: https://issues.apache.org/jira/browse/TUSCANY-1348
 Project: Tuscany
  Issue Type: Bug
  Components: Java DAS Samples
Affects Versions: Java-DAS-beta1
Reporter: Luciano Resende
Assignee: Luciano Resende
 Fix For: Java-DAS-beta1


When tried mvn -Pdistribution on das:-
das\distribution\binary\pom.xml - does not list ajax web sample under
dependency and thus does not package same

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback

[Kevin Williams (JIRA)]

IndexOutOfBoundsException thrown when trying to locate a service that includes 
a callback
-

 Key: TUSCANY-1347
 URL: https://issues.apache.org/jira/browse/TUSCANY-1347
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Embedded Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
 Fix For: Java-SCA-Next


More complete description and test case to follow

Here is the exception thrown...
[6/14/07 17:59:55:187 MDT] 0020 SystemErr R 
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:572)
at java.util.ArrayList.get(ArrayList.java:347)
at 
org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98)
at 
org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58)
at 
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292)
at 
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228)
at 
org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80)
at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [EMF Maven Repository] EMF 2.3 Repository?

[Ole Ersoy]

Hi Frank,

Good guess :-).  All the dependencies download fine.  


Thanks again,
- Ole



Frank Budinsky wrote:

Hi Ole,

I'm not sure exactly where it is, but I know that the EMF project has been 
moved from the "tools" project to a new top level "modeling" project at 
Eclipse. So maybe the location is something like this now:


http://mirrors.cat.pdx.edu/eclipse/modeling/emf/maven2/

If that doesn't work, I'd ask on the EMF newsgroup.

Frank.


Ole Ersoy <[EMAIL PROTECTED]> wrote on 06/14/2007 04:19:47 PM:


Hi,

Does anyone know if there is a maven repository for the EMF 2.3 
artifacts?  I used to use the one below for the M4 release, but it 
looks like it has been "Deprecated".

http://mirrors.cat.pdx.
edu/eclipse/tools/emf/maven2/

Thanks
- Ole



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




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




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

Re: [EMF Maven Repository] EMF 2.3 Repository?

[Ole Ersoy]

Hi Frank,

Thanks - I'll check it out.  Incidentally - The artifacts are missing from Ibiblio after all.  I 
saw Maven print "Downloading" and jump to conclusions.  Later in the log, it says 
"Unable...".

Hopefully they will be in the pdx mirror, once it comes back up.

Thanks again,
- Ole




Frank Budinsky wrote:

Hi Ole,

I'm not sure exactly where it is, but I know that the EMF project has been 
moved from the "tools" project to a new top level "modeling" project at 
Eclipse. So maybe the location is something like this now:


http://mirrors.cat.pdx.edu/eclipse/modeling/emf/maven2/

If that doesn't work, I'd ask on the EMF newsgroup.

Frank.


Ole Ersoy <[EMAIL PROTECTED]> wrote on 06/14/2007 04:19:47 PM:


Hi,

Does anyone know if there is a maven repository for the EMF 2.3 
artifacts?  I used to use the one below for the M4 release, but it 
looks like it has been "Deprecated".

http://mirrors.cat.pdx.
edu/eclipse/tools/emf/maven2/

Thanks
- Ole



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




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




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

[jira] Updated: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?

[Scott Kurz (JIRA)]

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

Scott Kurz updated TUSCANY-824:
---

Attachment: skurz.824.v1.patch

This patch attempts to solve two databinding-related problems, though neither 
solution has necessarily been agreed upon by the community.

First, it sets up an operation DB (if one isn't set) by looking for non-default 
DBs set on the inputs/output/faults.This is what we were specifically
discussing in the thread mentioned in the JIRA.

Second, I also addressed the question of how to calculate the databinding of a 
fault type. 

As this comment in DataTransformationInteceptor.getFaultType() mentions:

private DataType getFaultType(DataType exceptionType) {
// FIXME: We cannot assume the exception will have a databinding set

there might be no DB on the exception type.The case I was trying to address 
was the case that the exception class was a POJO with no
special DB, but the exception class, in the pattern mentioned in the JAX-WS 
spec, wrappers a FaultBean accessible via getFaultInfo().

Since the various ExceptionHandler's already know how to "unwrapper" an 
exception to find the DataType of the FaultBean within, I added an option to
the DefaultDataBindingExtensionPoint to check for an ExceptionHandler for each 
of the DB's it goes through, and see if exceptionHandler.getFaultType(..) can 
return something.

Even if this seems worthy, I know it might be best handled separately... but 
this JIRA's a bit broad to begin with anyway.  

> DataBinding: Is it a concern of Programming Model vs. Assembly?
> ---
>
> Key: TUSCANY-824
> URL: https://issues.apache.org/jira/browse/TUSCANY-824
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-M2
>Reporter: ant elder
>Assignee: Raymond Feng
>Priority: Critical
> Fix For: Java-SCA-Next
>
> Attachments: skurz.824.v1.patch
>
>
> There have been some question about the DataBinding framework and if it 
> should be a concern of the Programming Model vs. Assembly?
> See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html
> and a follow up mention in: 
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (TUSCANY-1238) SDO overlapping annonymous types clash

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1238.
---

Resolution: Fixed

FIxed at revision 534152. 

> SDO overlapping annonymous types clash
> --
>
> Key: TUSCANY-1238
> URL: https://issues.apache.org/jira/browse/TUSCANY-1238
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
> Environment: All
>Reporter: Simon Laws
> Fix For: Cpp-Next
>
>
> If I have the schema:
> 
> http://www.w3.org/2001/XMLSchema";
> targetNamespace=" http://www.example.org/AnnonTypes";
> xmlns:tns="http://www.example.org/AnnonTypes"; 
> elementFormDefault="qualified">
>
> 
>   
> 
>   
>   
>  
> 
>   
> 
>   
> 
>   
> 
>  
>   
>   
>   
>   
>  
> 
>   
> 
>   
> 
>  
> 
>  
>   
>   
> 
>   
> 
> 
> And the XML
> 
> http://www.example.org/AnnonTypes "
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation=" http://www.example.org/AnnonTypes 
> AnnonTypes.xsd ">
>   
> 
>   tns:ValueA
> 
>   
>   
> 
>   tns:ValueB
> 
>   
> 
> C++ SDO will report undefined types because, in the case of annonymuos types, 
> C++ SDO (and the spec) currently use the containing element name as the type 
> name. In this case this results in two types with the same name and one 
> replaces the other in the type model. In java the secon annonymous type would 
> be called Overlapping1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [EMF Maven Repository] EMF 2.3 Repository?

[Frank Budinsky]

Hi Ole,

I'm not sure exactly where it is, but I know that the EMF project has been 
moved from the "tools" project to a new top level "modeling" project at 
Eclipse. So maybe the location is something like this now:

http://mirrors.cat.pdx.edu/eclipse/modeling/emf/maven2/

If that doesn't work, I'd ask on the EMF newsgroup.

Frank.


Ole Ersoy <[EMAIL PROTECTED]> wrote on 06/14/2007 04:19:47 PM:

> Hi,
> 
> Does anyone know if there is a maven repository for the EMF 2.3 
> artifacts?  I used to use the one below for the M4 release, but it 
> looks like it has been "Deprecated".
> http://mirrors.cat.pdx.
> edu/eclipse/tools/emf/maven2/
> 
> Thanks
> - Ole
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

[EMF 2.3 Maven Repository] Never Mind

[Ole Ersoy]

Hi,

Sorry about starting a new thread.  GMail hides the copy of the original thread 
from me...

Looks like the emf artifact are pushed to ibiblio.  Sorry for the noise. 


Cheers,
- Ole


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

[EMF Maven Repository] EMF 2.3 Repository?

[Ole Ersoy]

Hi,

Does anyone know if there is a maven repository for the EMF 2.3 artifacts?  I used to use 
the one below for the M4 release, but it looks like it has been "Deprecated".
   
http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/

Thanks
- Ole



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

[jira] Resolved: (TUSCANY-747) [SDO for C++] Unable to load an XML doc with no namespace

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-747.
--

Resolution: Fixed

This should now be fixed as of revision r547380 

> [SDO for C++] Unable to load an XML doc with no namespace
> -
>
> Key: TUSCANY-747
> URL: https://issues.apache.org/jira/browse/TUSCANY-747
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: All
>Reporter: Geoff Winn
> Fix For: Cpp-Next
>
>
> Given the following XML:
> JaneDoe
> I have no XSD for this document, and don't want to have one or have to
> define specific SDO types for it. I just want to load this XML into an
> SDO DataObject.
> XMLDocumentPtr doc = XMLHelper::load(xml);
> gives me an XMLDocumentPtr with no root DataObject.
> char* xml = XMLHelper::save(doc);
> gives me this:
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1346) Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components

[Matthew Sykes (JIRA)]

Resolution to TUSCANY-1332 assumes a closed top-level composite that does not 
support addition of new components


 Key: TUSCANY-1346
 URL: https://issues.apache.org/jira/browse/TUSCANY-1346
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model, Java SCA Core Runtime, Java SCA 
Embedded Runtime
Affects Versions: Java-SCA-0.90, Java-SCA-0.91
Reporter: Matthew Sykes


The resolution to TUSCANY-1332 involved exploitation of the composite include 
function to "include" all known deployable composites into the domain such that 
the components contained within the deployable composites would be wired 
together when the domain level composite was activated.  While this resolved 
the issues of wiring across multiple composites contained within different 
contributions, this approach requires that the system know of all composites 
that may be part of the domain at the time the domain is activated.

When embedding Tuscany in a server runtime, however, deployment and activation 
of composites may occur after the domain is activated.  With the current 
implementation that is contained with EmbeddedSCADomain, runtimes that consume 
Tuscany would have to stop and restart the domain composite to deploy and 
activate new components and their services.  While this may be appropriate for 
small systems, it's not workable in complex environments.

I believe Tuscany needs a wiring and activation model that is more dynamic such 
that components can be added to (or removed from) the domain and wired after 
the domain composite was initially activated.  This flexibility would have 
implications to the way wiring is done and how multiplicity is validated as the 
shape of the domain changes.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Code Guidelines - @Version Question

[Vamsavardhana Reddy]

Sent the file to your e-mail instead of dev-list.  I hope it won't be
filtered this time.

Vamsi

On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

Humm, your file got filtered, but i was looking at our default
template [1] and still didn't help much... could you please paste your
[auto-props] section here.

 I also found some other documentation [2] that made me a little more
confuse on how this works :)

[1] https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props
[2] http://svnbook.red-bean.com/en/1.1/ch07s02.html

On 6/14/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:
> You need to update subversion settings so that Rev and Date get added
> as svn properties when a new file is added.  On windows, the config
> file is "C:\Documents and Settings\\application
> data\Subversion\config".  Attaching the one from my machine.  Look at
> the "[auto-props]" section.
>
> Vamsi
>
> On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > I was trying to use the code guidelines from our Development Guilde
> > [1], where it suggests the usage of @version $Rev$ $Date$ on the
> > header of the class being defined, but it's not getting updated to me
> > when I use TortoiseSVN to commit files. Does anyone have any idea
> > what's wrong, or if this is a limitation from TortoiseSVN ?
> >
> >
> > [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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




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

Re: Code Guidelines - @Version Question

[Luciano Resende]

Humm, your file got filtered, but i was looking at our default
template [1] and still didn't help much... could you please paste your
[auto-props] section here.

I also found some other documentation [2] that made me a little more
confuse on how this works :)

[1] https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-props
[2] http://svnbook.red-bean.com/en/1.1/ch07s02.html

On 6/14/07, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote:

You need to update subversion settings so that Rev and Date get added
as svn properties when a new file is added.  On windows, the config
file is "C:\Documents and Settings\\application
data\Subversion\config".  Attaching the one from my machine.  Look at
the "[auto-props]" section.

Vamsi

On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I was trying to use the code guidelines from our Development Guilde
> [1], where it suggests the usage of @version $Rev$ $Date$ on the
> header of the class being defined, but it's not getting updated to me
> when I use TortoiseSVN to commit files. Does anyone have any idea
> what's wrong, or if this is a limitation from TortoiseSVN ?
>
>
> [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[jira] Created: (TUSCANY-1345) Many StAXArtifactProcessor implementations read policy but do not write it

[Matthew Sykes (JIRA)]

Many StAXArtifactProcessor implementations read policy but do not write it
--

 Key: TUSCANY-1345
 URL: https://issues.apache.org/jira/browse/TUSCANY-1345
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-0.90, Java-SCA-0.91
 Environment: sca-java-0.90
Reporter: Matthew Sykes
Priority: Minor


While the 0.90 release was closing down, several changes were made to the 
StAXArtifactProcessor implementations used by the assembly model processors to 
get rid of the use of an abstract base class capable of dealing with policy.  
When that work was done, the read operations were updated to read the policy 
but the write operations were not.

It seems that if the processors are going to be used to serialize the model, 
the write operations would need to serialize the polices as well.

I've seen this issue in the RMIBindingProcessor, WebServiceBindingProcessor, 
and JavaImplementationProcessor but there may be others.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (TUSCANY-1344) Tuscany does not provide a loader for the elements in scdl

[Matthew Sykes (JIRA)]

Tuscany does not provide a loader for the  elements in scdl
--

 Key: TUSCANY-1344
 URL: https://issues.apache.org/jira/browse/TUSCANY-1344
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90, Java-SCA-0.91
 Environment: sca-java-0.90
Reporter: Matthew Sykes
Priority: Trivial


There doesn't appear to be a StAXArtifactProcessor capable of reading and 
serializing  elements in the scdl.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Code Guidelines - @Version Question

[Vamsavardhana Reddy]

You need to update subversion settings so that Rev and Date get added
as svn properties when a new file is added.  On windows, the config
file is "C:\Documents and Settings\\application
data\Subversion\config".  Attaching the one from my machine.  Look at
the "[auto-props]" section.

Vamsi

On 6/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

I was trying to use the code guidelines from our Development Guilde
[1], where it suggests the usage of @version $Rev$ $Date$ on the
header of the class being defined, but it's not getting updated to me
when I use TortoiseSVN to commit files. Does anyone have any idea
what's wrong, or if this is a limitation from TortoiseSVN ?


[1] http://incubator.apache.org/tuscany/sca-java-development-guide.html

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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




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

Re: Subscribe Request

[Luciano Resende]

Welcome Menghe, you should be sending a subscription request to :
[EMAIL PROTECTED]



On 6/14/07, menghe yun <[EMAIL PROTECTED]> wrote:

Subscribe Request




--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Subscribe Request

[menghe yun]

Subscribe Request

Code Guidelines - @Version Question

[Luciano Resende]

I was trying to use the code guidelines from our Development Guilde
[1], where it suggests the usage of @version $Rev$ $Date$ on the
header of the class being defined, but it's not getting updated to me
when I use TortoiseSVN to commit files. Does anyone have any idea
what's wrong, or if this is a limitation from TortoiseSVN ?


[1] http://incubator.apache.org/tuscany/sca-java-development-guide.html

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

Re: Does Tuscany SDO C++ support open content properties?

[Pete Robbins]

Andy, I think I have fixed this in HEAD now. There is still a couple of
issues I need to look at but I'd be interested to see if it works for you.

Cheers,


On 14/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:


Pete,

Thanks for that information. The main use case I am currently looking at
is the ability to parse an XML document where types have not been defined.
From memory, whenever I have attempted this the
XMLDocument.getRootDataObject() method returns NULL.

Thanks,

Andy.


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wed 13/06/2007 12:57
To: tuscany-dev@ws.apache.org
Subject: Re: Does Tuscany SDO C++ support open content properties?

Open content properties are supported in the SDO C++ implementation. I'm
not
sure if support is quite up to "spec" level but it's fairly close.

Deserializing an xml document to SDO without schema is probably "not quite
there" and the XMLHelper and parser code would need looking at to make
this
work as per the SDO spec... but I think it could be reasonably simple to
support.

Do you have a particular scenario that you need to work?

Cheers,


On 13/06/07, Andy Grove <[EMAIL PROTECTED]> wrote:
>
> I understand that Tuscany SDO C++ requires types to be defined before
> parsing xml documents. Would I be correct in assuming that this is
because
> open content properties are not yet supported? If so, are there any
plans
> for implementing this support?
>
> Thanks,
>
> Andy.
>



--
Pete

Th


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





--
Pete

Policy Framework Impl. in Tuscany

[Venkata Krishnan]

Hi,

I am keen on adding further to the Policy support thats in Tuscany today. I
recently run thro the Policy Framework specs and was looking into Tuscany on
how far we had gone on this.  Here's my understanding of all that.  I
request people's perspective on my understanding before I go ahead and
implement things.

1.  Policy intents and PolicySets are things that can be defined at the
domain level.  I propose we have Policy Registry or Repository that hosts
the set of all intents and policy sets that pertain to a domain.

2. There can be a PolicyRegistryService that can provide interfaces to add,
retrieve and remove intents and policies to the Policy Registry /
Repository.

3. The set of intents and policy sets for a domain could be defined in the
definitions.xml file which could be picked up by the ContributionsProcessor
(see line 2490 of Assembly Model Spec).  Infact there is more - such as the
intents that are supported by binding and implementation types in the domain
and so on.  We could have a processor for the sca definitions that will read
among other artifacts the policy intents and policy sets and add them to the
registry.  The model objects to represent policy intents and policy sets and
the factory to create them are already in place under the policy module.

4. SCA artifacts will have intents and policy sets attached to them.
Presently the artifact processors create the Intents and PolicySet objects.
I propose that the artifact processor that read these SCA Artifacts will
just about read the QNames and resolve them in the resolution phase with the
help of the PolicyRegistryService.  This way we can also check if the intent
or policy set specified for an artifact is really applicable to the artifact
or not.

5. Loading of PolicySet could get a bit deeper since there is extensibility
that is allowed on the policy language that could be used.  But I guess
WS-Policy will need to be supported for by Tuscany as that is view to be a
common thing that could be used

So thats a summary the loading part.

In the building phase there are algorithms that the Policy Framework Specs
has specified to validate the wiring between components in the context of
policies (including each end of the wire could inherit from ancestor
artifacts and what is the binding or implementation type being used and what
that supports inherently).

Finally during runtime we have to make sure that the policy statements are
handed out to the appropriate QoS infrastructures i.e Security or
Transaction support modules so that they may be enforced.  I am a bit
unclear on the options related to this at the present moment.

Before I get to a discussion on the wiring and runtime aspects related to
policy I wish to know if my thoughts are in the right direction this far.

Thanks

- Venkat

Re: [SDO Java DISCUSS] Contents of the next SDO release

[Fuhwei Lwo]

I like to share some pain I have in the past by embedding EMF.

1. Runtime problem - EMF has several OSGi bundles containing some 
initialization and resource files with the same names. Once we lump all the 
bundles together, we need to merge all content otherwise we will run into some 
runtime problems.

2. Support problem - After we refactor EMF, it's hard to get support from EMF 
team because we don't know the problem is from the code we merged or original 
EMF code. Once EMF team knew their code has been touched, they would no longer 
support us not mentioning legal complication by changing EMF code.

That's why I asked whether there is any compelling benefit by refactoring EMF.

Fuhwei

Fuhwei Lwo <[EMAIL PROTECTED]> wrote: I may have missed the reasoning behind 
refactoring EMF's package name to org.apache.tuscany.sdo.emf.*.  Can anyone 
tell me the benefit by doing that?  Thanks.

Fuhwei

ant elder  wrote: I guess there's various ways it could be done, i was thinking 
of an
sdo-complete jar containing all the sdo classes (org.apache.tuscany.sdo.**)
and all the emf classes renamed from org.eclipse.emf.** to be
org.apache.tuscany.sdo.emf.**.

   ...ant

On 6/13/07, kelvin goodson  wrote:
>
> Ant,  this all sounds good,
> +1 to the spec project move,
> and certainly +1 to aggregating jars if we can
>
> but just to push back one more time, as I can see scope for your response
> to Frank being open to misinterpretation.  Can I check on what you mean by
> renaming the packages,  and whether there are any legal issues there please?
>
>
> Kelvin
>
> On 13/06/07, ant elder  wrote:
> >
> > On 6/13/07, Frank Budinsky  wrote:
> > >
> > > Ant,
> > >
> > > You said this:
> > >
> > > > While building that it could also rename the
> > > > emf packages to start with org.apache.tuscany to avoid any version
> > > problems
> > > > when using Tuscany SDO with existing EMF code.
> > >
> > > We have discussed doing this for quite some time. It would certainly
> > > eliminate the EMF version problems, but I never knew if the Eclipse
> > and
> > > Apache licenses actually allow us to do this. Are you sure that this
> > is
> > > allowed?
> >
> >
> > Pretty sure yes. Its fine for us to distribute the emf binaries as they
> > are
> > "Category B: Binary Licenses Only" as defined in
> > http://www.apache.org/legal/3party.html, and AFAICS there's nothing in
> > the
> > EPL that prevents us doing this.
> >
> >...ant
> >
>
>

Re: IDE-specific files in svn

[Jean-Sebastien Delfino]

ant elder wrote:

On 6/14/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Hi,

I remember about a year ago discussing whether or not it is
acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
.project files) into svn, and we decided to not do it. Does anyone
remember if this was really an Apache policy, or just a decision we made
for Tuscany? If the latter, I wonder if we should reconsider. 
Personally,

I think it would be very convenient if we had the Eclipse .project and
.classfile in the projects, so that people could just check out Tuscany
projects directly into Eclipse. For people not using Eclipse, having 
these

superfluous files around really doesn't seem like a big deal. I also
wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
that Eclipse users (like me) would just ignore.

What do others think about this?



AFAIK there's no 'rule' that says this must not be done. However no other
Apache (or non-Apache) project that i can think of does this so it 
would be

unusual  and that makes me wonder why.

Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem 
or is
there something else about it thats a pain? (Also we may be able to 
get rid

of the '-Peclipse' bit now if that would make it easier to bare?

  ...ant



One comment and two questions:

- Some Apache C projects (e.g. Axis2/C) already have IDE (Visual Studio) 
files in SVN. I am not sure about any Java projects.


- To help understand how useful it is to have these files, could you 
please post them and provide a short description of what I'll need to do 
to load my Eclipse workspace from scratch, including how you download 
dependencies and how you set up any classpath variables or user 
libraries other than M2_REPO?


- Are you thinking about providing these IDE files for committers (who 
already have Maven and do Maven builds before committing)? or other 
contributors and users? If this is mostly for contributors and users, 
how about generating these IDE files in our nightly builds? If they are 
not generated then are you going to make sure that they are always in 
sync with the build?


Thanks

--
Jean-Sebastien


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

Re: SCA & WS-BPEL

[Matthieu Riou]

Hi Sam,

I'll have a deeper look at this today or tomorrow. I'll certainly have a
look at what you've contributed so far. My understanding is that Tuscany's
SPIs have significantly changed so we may be better off starting from
scratch from the skeleton Luciano has created and import (understand
copy/paste) the code you've already done gradually (tweaking what needs to
be tweaked).

Anyway I'll create a new issue for this, trying to merge the new skeleton
and what you've done before and maybe we can start from that.

Cheers,
Matthieu

On 6/14/07, sam tam <[EMAIL PROTECTED]> wrote:


Hello,

This is regarding the integration of Apache ODE and Apache Tuscany !

I have contributed a container in Apache Tuscnay for BPEL which was an
initial startup  http://issues.apache.org/jira/browse/TUSCANY-897

I think that was during M2 release [ During the month of Dec 2006 ]

I want to contribute more for  the integration because I had been working
on
it before .

I replied to Luciano's mail regarding this in Apache ODE  ML but
accidentally I missed Tuscany ML.

So I just want to inform you guys !

Sam Tam.



On 6/9/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Hi All
>
>I'm sending this e-mail to reactivate the collaboration between
> Apache Tuscany and Apache ODE as initiated by Matthieu a while ago[1].
> It would be great if we could have an WS-BPEL component implementation
> described in [2] and [3], where we would be able to run executables
> WS-BPEL process from an SCA runtime.
>
>In order to get this started, I have put together a skeleton that
> we could use as the bases for implementation.bepel and it's available
> at [4]. I'm in the middle of simplifying it further, and I'll keep you
> guys posted of my progress.
>
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html
> [2] http://osoa.org/display/Main/SCA+BPEL+White+Paper
> [3]
>
http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1
> [4]
>
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>



--

Re: Distributed runtimes and topology

[Simon Laws]

On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:


I've starting to move and reorganize some of the distributed runtime ideas
from my sandbox into the trunk. So far there is not much there

modules/
  topology  - and empty module for topology model things
samples/
  calculator-distributed - the current motivating use case.

There have been several threads around this recently covering topology,
base uris and distribution, for example.

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18613.html
and
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18644.html

I've be updating the page (
http://cwiki.apache.org/confluence/display/TUSCANY/Distributed+Runtime) to
try and capture some of the thinking. Over the next few days I'm going to
try and get the basic SCADomain topology meta data reading up and running in
head.

I welcome any comments or help in this area.

Regards

Simon




Hi Jean-Sebastien

Following the last few comments from the Lazy loading thread [1] I see you
added some model classes to the topology model. I'm now filling out the
o.a.t.s.topology.xml package a little. A bit of an education for me on how
the xml reading works!

What I plan to do is get a very simple model read in, representing the node
and the topology component of that node, and populate this with the list of
components that are assigned to the node.

Once we have the list of component to node assignements read in I can then
worry about how this slots into the rest of the runtime. It's probably going
to have to be a bit subtler that my previous changes to the
CompositeActivator I suspect. I'm going to need a little help with this bit.
So more questions later

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18798.html

Re: Wiki Access issues ? **HELP**

[Mike Edwards]

Venkat,

Yes, it works just fine.  Time to start helping...!

Mike.

Venkata Krishnan wrote:

HI Mike,

I have already added you id as 'confluence administrator' which I've
mentioned on another thread on the ML.  Could you please try and let me 
know

if it works.  Thanks.

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



Folks,

So what's with the Edit access to the Tuscany Wiki??

I don't seem to have edit access at the moment, despite being a
committer.  Who has admin rights for the Wiki?  Can one of the admins
please grant me edit access, please?

Also, I know that there was a discussion about broadening the admin
access for the Wiki.  Has anything been done about that?  My offer to
play admin for the Tuscany Wiki remains open - I have plenty of
experience based on my ownership of the www.osoa.org Wiki, which is also
based on Confluence.

Yours,  Mike.

Simon Laws wrote:
> So I expect this is just the product of edit access being restricted to
> committers. Please comment on Luciano's post here [1] so that  a new
space
> can be provisioned (assuming that this is what is agreed) ASAP.
>
> Simon
>
> [1]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18622.html
>

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






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

Re: Website - Consistent navigation menus

[Mike Edwards]

Venkat,

Many thanks,

Mike.

Venkata Krishnan wrote:

Hi Mike, I have added your id in as 'confluence-administrators'.

- Venkat

On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:



Luciano,

Only just spotted your request in the emails

My user ID is edwardsmj

Do I need to send this directly to infra, or will you handle it?

Yours,  Mike.

Luciano Resende wrote:
> Venkat, Mike, infra is asking for your confluence user ids, could you
> please provide this info.
>
> On 6/8/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
>> Conversation seems to have stopped so, from the previous comments...
>>
>> * Confluence admins:
>>
>> Venkat, Luciano, Mike Edwards [1] have been proposed to cover the
>> timezones
>> we operate in. Venkat are you progressing this?
>>
>> * http://cwiki.apache.org/confluence/display/TUSCANY space access:
>>
>> As this is now feeding our main (http://incubator.apache.org/tuscany/)
>> website we have been advised to restrict access to committers to
>> prevent our
>> shop front acquiring dubious content. I have removed "create" access
from
>> confluence users as I think we have been sailing close to the wind on
>> this
>> and it would be a shame to have our web site messed up, 
particularly as
>> we've recently put out releases and we hope people are looking at 
them.

>>
>> There are alternative approaches to this blanket change, for example,
>> we may
>> be able to mark all of the web site pages in the /TUSCANY spaces as
>> restricted but this would take some effort and complicate the
management
>> task We could also stop the automatic generation of the site and do it
on
>> demand manually but the idea of linking up the wiki to generate the
>> web site
>> was to avoid this.
>>
>> The main option that is on the table is to go with the committer only
>> access
>> to the TUSCANY space and create other spaces for whatever else we
>> need, for
>> example, a generally accessible wiki. Luciano has started a
conversation
>> about this [2] but I don't see much feedback. If you feel strongly can
>> you
>> go and comment so that we can move this forward quickly now we are
>> restricting create access to /TUSCANY
>>
>> * Contributions to the web site
>>
>> We need to describe a mechanism where non-committers can contribute
>> content
>> to the web site. Looking at the comments here it seems that this will
>> have
>> to be through attaching text, cwiki markup or whatever other resources
>> are
>> required (png, jpg etc) to JIRA so that a committer can update the
site.
>> Logically this is no different from the situation we had when the site
>> was
>> maintained out of svn except of course that we could use diffs then.
>>
>> Regards
>>
>> Simon
>>
>> [1]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18665.html
>> [2]
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18641.html
>>
>
>

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






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

Re: [DAS] Status of DAS Release

[Amita Vadhavkar]

Small update, tried to build and test with empty repos and it went through
with no issues.

Regards,
Amita

On 6/13/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:


Things tested to be working -
all UT as part of mvn build
all samples in different browsers.

Apart from das\distribution\binary\pom.xml - change and documentation
changes in JIRA 1335, I have a doubt in logging mechanism in web samples.

In DBConfig utility , the code uses Logger.getLogger(className) - to get
logger from log4j.

Whereas in all RDB DAS code, it is
LoggerFactory.INSTANCE.getLogger(className) - to get logger from RDB DAS
util.
In this, the level is OFF - hardcoded in the code.

So, when the log4j.properties file is used in tomcat to switch on logging,
the logging works for DBConfig (as it is using direct log4j), but logging
does not switch on for RDB DAS classes, as it is hardcoded OFF in the RDB
DAS jar.

Is this the desired behavior? Will there be any need to switch on logging
in web samples for RDB DAS code and how to do it without touching
tuscany-das-rdb-1.0-incubating.jar?

Regards,
Amita

On 6/11/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> Hi All,
>
> When tried mvn -Pdistribution on das:-
> das\distribution\binary\pom.xml - does not list ajax web sample under
> dependency and thus does not package same
>
> As now, non-committer does not have access to edit wiki, I have created
> JIRA-TUSCANY-1335 for all the pending updates for DAS I was doing. Please
> see how these can be completed using attached zipped files.
>
> Architecture Guide - 
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+architecture+guide
>
> images to upload - ClassDiag.jpg, rdbDAS.gif
>
> User Guide -
> http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+User+Guide
> Under Samples(See Capabilities in use)
> Put links for:-
> Web Sample -
> 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/companyweb/readme.htm
> J2SE Sample -
> 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/customer/readme.htm
> Advanced Web Sample - 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/samples/sample-ajax-das/readme.htm
>
>
> Development Guide - DAS_Java_Development_Guide.txt - need to add to wiki
>
> need to checkin under 
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/distribution/src/main/release/RELEASE
> NOTES
> RELEASE_NOTES.txt
>
> About to complete CHANGES.txt , will add by eod to JIRA 1335..
>
> Regards,
> Amita
>
> On 6/10/07, Adriano Crestani <[EMAIL PROTECTED] > wrote:
> >
> > I went through all das samples and they seem to be working fine on
> > Windows
> > XP Home Edition SP 2 environment. I also corrected some links on
> > readmes
> > that were pointing to old tuscany website.
> >
> > I ran the rat on java/das directory and added Apache Licence header to
> > files
> > that were missing it.
> >
> > Regards,
> > Adriano Crestani
> >
> > On 6/8/07, Luciano Resende < [EMAIL PROTECTED]> wrote:
> > >
> > > First of all, let me thank you all for helping on this release.
> > > Recently there has been a lot of progress, and things are looking
> > good
> > > from the list of issues we had listed in the wiki [1]. The remaining
> > > documentation tasks could probably go in parallel with the release
> > > candidates. So, we should start thinking about creating a branch for
> > > the next release sometime soon, probably over the weekend or Monday
> > > and then start publishing release candidates from that.
> > >
> > > Also, I think we should look into the following items before we
> > create
> > > the first RC :
> > >
> > >- run rat and make the results available
> > >- review the contents of license, readme, release_notes, changes,
> > etc
> > >- review javadoc
> > >- make sure samples readme are updated and correct and the
> > samples
> > > are working ok on different environments
> > >
> > > I'd also like to suggest two other things :
> > >- Name the release beta1, to be aligned with the beta1 release of
> > SDO.
> > >- Any blocking issue to be tracked as blocking JIRA and directly
> > > assigned to beta1 release.
> > >
> > > Does this sound ok to everyone?  Any Thoughts ?
> > >
> > >
> > > [1]
> > > 
http://cwiki.apache.org/confluence/display/TUSCANY/RDB+DAS+-+Java+DAS+Beta1+Release
> >
> > >
> > >
> > > --
> > > Luciano Resende
> > > Apache Tuscany Committer
> > > http://people.apache.org/~lresende
> > > http://lresende.blogspot.com/
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>

Re: IDE-specific files in svn

[Frank Budinsky]

I was assuming we would check in one "default" configuration. There's 
nothing preventing people from running maven eclipse:eclipse or manually 
changing them in their own environments. We wouldn't want people to 
accidentally check their changes back in so we'd probably want them on the 
svn:ignore list.

I wasn't really implying that we need to have a policy that every Tuscany 
project include IDE files. I was really just wondering if it would be 
acceptable to allow such files to be checked in to any of the projects. 
For SDO, for example, the two projects that I know are currently being 
reused by other projects (in isolation) are sdo-api and sdo-lib. Having 
Eclipse files for just those two would be helpful.

Frank.

[EMAIL PROTECTED] wrote on 06/14/2007 05:14:44 AM:

> Right thats the problem isn't it. If we check in the IDE files in we're
> assuming one particular way of using the code. For the SCA project which 
is
> quite big i've several different workspaces - one with every thing 
including
> modules, samples and itest, another workspace just with modules, and 
another
> just with samples etc. That wouldn't work with the IDE files checked in 
as
> I'd have to change them for the the different workspaces and then when 
doing
> checkin's try real hard to not accidentally commit my local changes to 
the
> IDE files which would be a real pain and almost certainly quite often 
happen
> by accident.
> 
>...ant
> 
> On 6/14/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > There's pain in the process, not huge, but irritating
> >
> > first off there's the definition of the M2_REPO variable,  not a huge
> > problem, especially if you stick to just one workspace.  I tend to 
create
> > workspaces as and when I need them,  and I can't see how to make my 
variable
> > definition cross multiple workspaces.
> >
> > Next, and probably more significant is removing the binary 
dependencies
> > and setting up inter project dependencies.   After the maven 
eclipse:eclipse
> > command for example, the tools project depends on the binary artifacts
> > generated from the maven build of the impl, lib and api projects . 
What
> > most developers are going to want is inter project dependencies.  So 
there's
> > quite a bit of manual deletion of jars from the class path entries, 
then,
> > you might want for example the lib project to expose the api projects
> > interface, etc. etc.
> >
> > I'm quite well practised at setting this up,  but its still a 5 minute
> > job.
> >
> > Regards, Kelvin.
> >
> > On 14/06/07, ant elder < [EMAIL PROTECTED]> wrote:
> > >
> > > On 6/14/07, Frank Budinsky < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I remember about a year ago discussing whether or not it is
> > > > acceptable/appropriate to check-in IDE specific files (e.g., 
Eclipse
> > > > .project files) into svn, and we decided to not do it. Does anyone
> > > > remember if this was really an Apache policy, or just a decision 
we
> > > made
> > > > for Tuscany? If the latter, I wonder if we should reconsider.
> > > Personally,
> > > > I think it would be very convenient if we had the Eclipse .project 
and
> > >
> > > > .classfile in the projects, so that people could just check out
> > > Tuscany
> > > > projects directly into Eclipse. For people not using Eclipse, 
having
> > > these
> > > > superfluous files around really doesn't seem like a big deal. I 
also
> > > > wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) 
files
> > > > that Eclipse users (like me) would just ignore.
> > > >
> > > > What do others think about this?
> > >
> > >
> > > AFAIK there's no 'rule' that says this must not be done. However no
> > > other
> > > Apache (or non-Apache) project that i can think of does this so it 
would
> > > be
> > > unusual  and that makes me wonder why.
> > >
> > > Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the 
problem
> > > or is
> > > there something else about it thats a pain? (Also we may be able to 
get
> > > rid
> > > of the '-Peclipse' bit now if that would make it easier to bare?
> > >
> > >...ant
> > >
> >
> >


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

Re: IDE-specific files in svn

[ant elder]

Where are you running the mvn eclipse command from? When I do it from the
top-level SDO folder all the projects get setup using inter project
dependencies (with the exception of sdo-api as thats outside in spec/sdo-api
right now but that will be fixed when its moved into the sdo folder)?

  ...ant

On 6/14/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


There's pain in the process, not huge, but irritating

first off there's the definition of the M2_REPO variable,  not a huge
problem, especially if you stick to just one workspace.  I tend to create
workspaces as and when I need them,  and I can't see how to make my variable
definition cross multiple workspaces.

Next, and probably more significant is removing the binary dependencies
and setting up inter project dependencies.   After the maven eclipse:eclipse
command for example, the tools project depends on the binary artifacts
generated from the maven build of the impl, lib and api projects .  What
most developers are going to want is inter project dependencies.  So there's
quite a bit of manual deletion of jars from the class path entries,  then,
you might want for example the lib project to expose the api projects
interface, etc. etc.

I'm quite well practised at setting this up,  but its still a 5 minute
job.

Regards, Kelvin.

On 14/06/07, ant elder < [EMAIL PROTECTED]> wrote:
>
> On 6/14/07, Frank Budinsky < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I remember about a year ago discussing whether or not it is
> > acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> > .project files) into svn, and we decided to not do it. Does anyone
> > remember if this was really an Apache policy, or just a decision we
> made
> > for Tuscany? If the latter, I wonder if we should reconsider.
> Personally,
> > I think it would be very convenient if we had the Eclipse .project and
>
> > .classfile in the projects, so that people could just check out
> Tuscany
> > projects directly into Eclipse. For people not using Eclipse, having
> these
> > superfluous files around really doesn't seem like a big deal. I also
> > wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
> > that Eclipse users (like me) would just ignore.
> >
> > What do others think about this?
>
>
> AFAIK there's no 'rule' that says this must not be done. However no
> other
> Apache (or non-Apache) project that i can think of does this so it would
> be
> unusual  and that makes me wonder why.
>
> Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem
> or is
> there something else about it thats a pain? (Also we may be able to get
> rid
> of the '-Peclipse' bit now if that would make it easier to bare?
>
>...ant
>

Re: IDE-specific files in svn

[Frank Budinsky]

Agree with all that, plus the fact that you need to install maven and 
check-out using the command line. If we had .project files, people could 
check-out the projects they want "directly into Eclipse" and work with 
them without ever needing mvn.

Frank.

"kelvin goodson" <[EMAIL PROTECTED]> wrote on 06/14/2007 04:56:40 
AM:

> There's pain in the process, not huge, but irritating
> 
> first off there's the definition of the M2_REPO variable,  not a huge
> problem, especially if you stick to just one workspace.  I tend to 
create
> workspaces as and when I need them,  and I can't see how to make my 
variable
> definition cross multiple workspaces.
> 
> Next, and probably more significant is removing the binary dependencies 
and
> setting up inter project dependencies.   After the maven eclipse:eclipse
> command for example, the tools project depends on the binary artifacts
> generated from the maven build of the impl, lib and api projects .  What
> most developers are going to want is inter project dependencies.  So 
there's
> quite a bit of manual deletion of jars from the class path entries, 
then,
> you might want for example the lib project to expose the api projects
> interface, etc. etc.
> 
> I'm quite well practised at setting this up,  but its still a 5 minute 
job.
> 
> Regards, Kelvin.
> 
> On 14/06/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 6/14/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I remember about a year ago discussing whether or not it is
> > > acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> > > .project files) into svn, and we decided to not do it. Does anyone
> > > remember if this was really an Apache policy, or just a decision we 
made
> > > for Tuscany? If the latter, I wonder if we should reconsider.
> > Personally,
> > > I think it would be very convenient if we had the Eclipse .project 
and
> > > .classfile in the projects, so that people could just check out 
Tuscany
> > > projects directly into Eclipse. For people not using Eclipse, having
> > these
> > > superfluous files around really doesn't seem like a big deal. I also
> > > wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) 
files
> > > that Eclipse users (like me) would just ignore.
> > >
> > > What do others think about this?
> >
> >
> > AFAIK there's no 'rule' that says this must not be done. However no 
other
> > Apache (or non-Apache) project that i can think of does this so it 
would
> > be
> > unusual  and that makes me wonder why.
> >
> > Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem 
or
> > is
> > there something else about it thats a pain? (Also we may be able to 
get
> > rid
> > of the '-Peclipse' bit now if that would make it easier to bare?
> >
> >...ant
> >


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

Re: Request for Interim Build Distribution

[kelvin goodson]

I'm trying to publish the artifacts at the moment,  but something has
changed and the deploy is broken.  It may be a change to the parent pom, or
something to do with my upgraded maven level,  I don't know.  What I am
seeing is ...

C:\Development\JiraDev\clean>mvn deploy:deploy
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Tuscany SDO Implementation Project
[INFO]   Tuscany SDO Library
[INFO]   Tuscany SDO Implementation
[INFO]   Tuscany SDO Tools
[INFO]   Tuscany SDO Maven Plugin
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]


[INFO] Building Apache Tuscany SDO Implementation Project
[INFO]task-segment: [deploy:deploy]
[INFO]

[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache.snapshots
Password:: 
Password:: 
Uploading:
scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/sdo/tuscany-sdo/1.0-i

ncubating-SNAPSHOT/tuscany-sdo-1.0-incubating-20070614.123540-5.pom
6K uploaded
[INFO] Retrieving previous metadata from apache.snapshots
Password:: 
[INFO] Uploading repository metadata for: 'snapshot
org.apache.tuscany.sdo:tuscany-sdo:1.0-incubating-SNAPSHOT'
Password:: 
[INFO] Retrieving previous metadata from apache.snapshots
Password:: 
[INFO] Uploading repository metadata for: 'artifact
org.apache.tuscany.sdo:tuscany-sdo'
Password:: 
[INFO]

[INFO] Building Tuscany SDO Library
[INFO]task-segment: [deploy:deploy]
[INFO]

[INFO] [deploy:deploy]
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The packaging for this project did not assign a file to the build
artifact
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 2 minutes 19 seconds
[INFO] Finished at: Thu Jun 14 13:37:58 BST 2007
[INFO] Final Memory: 5M/21M
[INFO]


C:\Development\JiraDev\clean>

I can see the error being reported here [1],  but can't yet work out what
needs tweaking to put this right.  Any help gratefully received.

Kelvin

[1]
http://maven.apache.org/plugins/maven-deploy-plugin/xref/org/apache/maven/plugin/deploy/DeployMojo.html


On 14/06/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:


Hi Kelvin,

The published snapshot artifacts would be fine. Is there any way you could
append the corresponding source files to these special snapshot jars?

- Ron

- Original Message 
From: kelvin goodson <[EMAIL PROTECTED]>
To: Ron Gavlin <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2007 7:03:24 AM
Subject: Re: Request for Interim Build Distribution

Hi Ron,
  it's a very simple thing for me to publish snapshot artifacts to the
apache incubator maven repository, so that if you are building with maven
and declare snapshot dependencies on SDO it would pick up the most recent
snapshot build of the trunk.  Would that fit your purposes?

To build a release distribution is a fair bit more effort, and I'd kind of
be reluctant to put the effort into that right at this very moment,  because
we are just about to improve the structure of the repository and the
release, and I'd like to keep a focus on what's important for the release.

If you needed an archive and felt like creating one there's a simple
script [1] that would need configuring to your environment to make the zip
and tar.gz files that make up a release candidate.  You could set the TAG
variable to point simple to the trunk I think.  If it was purely for your
internal use you could cut out all the stuff about signing archives etc,
which I would not be able to cut out if I were to post an archive on the
apache infrastructure.

Let me know what you think.

Regards, Kelvin.

[1] 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/buildSDORelease.bat


On 13/06/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:
>
> Hi Kelvin,
>
> I know Luciano, yourself and others are working on an automated
> mechanism for posting nightly builds of SCA, SDO, and DAS for users to
> download. In the meantime, would it be too much trouble for you to manually
> post a SNAPSHOT SDO release to 
http://people.apache.org/~kelvingoodsonthat
 represents the current state of the head (that now includes my patch)?
> We have a bunch of testing to do against the current, pre-1.0 Tuscany
> release (we are

Re: Request for Interim Build Distribution

[kelvin goodson]

Ron,
 that's great.  All that would need to be done in terms of preserving the
source is to make a note of the svn repository version number at the time of
the build.  You can then browse and extract this source with a revision
number qualifier on the URL or svn extract command.  There's also a way to
use the svn:externals command to make a kind of symbolic link from within
svn to a directory,  and that can include a revision number,  so I could for
example create such a beast in my sandbox.  Anyone checking out from svn
using that folder would get a version of the trunk that is how it appeared
at the time of that revision.  I could perhaps create a SNAPSHOT_070614
folder for example in my sandbox, and set the svn external property to the
appropriate level.  Would that suit your needs?

Regards, Kelvin.

On 14/06/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:


Hi Kelvin,

The published snapshot artifacts would be fine. Is there any way you could
append the corresponding source files to these special snapshot jars?

- Ron

- Original Message 
From: kelvin goodson <[EMAIL PROTECTED]>
To: Ron Gavlin <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2007 7:03:24 AM
Subject: Re: Request for Interim Build Distribution

Hi Ron,
  it's a very simple thing for me to publish snapshot artifacts to the
apache incubator maven repository, so that if you are building with maven
and declare snapshot dependencies on SDO it would pick up the most recent
snapshot build of the trunk.  Would that fit your purposes?

To build a release distribution is a fair bit more effort, and I'd kind of
be reluctant to put the effort into that right at this very moment,  because
we are just about to improve the structure of the repository and the
release, and I'd like to keep a focus on what's important for the release.

If you needed an archive and felt like creating one there's a simple
script [1] that would need configuring to your environment to make the zip
and tar.gz files that make up a release candidate.  You could set the TAG
variable to point simple to the trunk I think.  If it was purely for your
internal use you could cut out all the stuff about signing archives etc,
which I would not be able to cut out if I were to post an archive on the
apache infrastructure.

Let me know what you think.

Regards, Kelvin.

[1] 
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/buildSDORelease.bat


On 13/06/07, Ron Gavlin <[EMAIL PROTECTED]> wrote:
>
> Hi Kelvin,
>
> I know Luciano, yourself and others are working on an automated
> mechanism for posting nightly builds of SCA, SDO, and DAS for users to
> download. In the meantime, would it be too much trouble for you to manually
> post a SNAPSHOT SDO release to 
http://people.apache.org/~kelvingoodsonthat
 represents the current state of the head (that now includes my patch)?
> We have a bunch of testing to do against the current, pre-1.0 Tuscany
> release (we are still using an M2-based release) and folks here want to test
> against a build distribution generated by your infrastructure rather than
> one I roll out myself.
>
> If this request is too much trouble, then we can wait until the
> automated nightly posting infrastructure is in place or you release the next
> beta.
>
> Thanks,
>
> - Ron
>
>
>
>
>

Re: SCA & WS-BPEL

[sam tam]

Hello,

This is regarding the integration of Apache ODE and Apache Tuscany !

I have contributed a container in Apache Tuscnay for BPEL which was an
initial startup  http://issues.apache.org/jira/browse/TUSCANY-897

I think that was during M2 release [ During the month of Dec 2006 ]

I want to contribute more for  the integration because I had been working on
it before .

I replied to Luciano's mail regarding this in Apache ODE  ML but
accidentally I missed Tuscany ML.

So I just want to inform you guys !

Sam Tam.



On 6/9/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Hi All

   I'm sending this e-mail to reactivate the collaboration between
Apache Tuscany and Apache ODE as initiated by Matthieu a while ago[1].
It would be great if we could have an WS-BPEL component implementation
described in [2] and [3], where we would be able to run executables
WS-BPEL process from an SCA runtime.

   In order to get this started, I have put together a skeleton that
we could use as the bases for implementation.bepel and it's available
at [4]. I'm in the middle of simplifying it further, and I'll keep you
guys posted of my progress.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html
[2] http://osoa.org/display/Main/SCA+BPEL+White+Paper
[3]
http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1
[4]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/





--

Re: IDE-specific files in svn

[kelvin goodson]

Can we do anything with svn:externals properties or overlays to help with
this.  Or maybe we could check in a standard set of patches that represent
adding eclipse stuff to projects?  Users could then do an extract in one of
a set of standard patterns, and then apply a patch to put the IDE files in
place.

Kelvin.

On 14/06/07, ant elder <[EMAIL PROTECTED]> wrote:


Right thats the problem isn't it. If we check in the IDE files in we're
assuming one particular way of using the code. For the SCA project which
is
quite big i've several different workspaces - one with every thing
including
modules, samples and itest, another workspace just with modules, and
another
just with samples etc. That wouldn't work with the IDE files checked in as
I'd have to change them for the the different workspaces and then when
doing
checkin's try real hard to not accidentally commit my local changes to the
IDE files which would be a real pain and almost certainly quite often
happen
by accident.

   ...ant

On 6/14/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> There's pain in the process, not huge, but irritating
>
> first off there's the definition of the M2_REPO variable,  not a huge
> problem, especially if you stick to just one workspace.  I tend to
create
> workspaces as and when I need them,  and I can't see how to make my
variable
> definition cross multiple workspaces.
>
> Next, and probably more significant is removing the binary dependencies
> and setting up inter project dependencies.   After the maven
eclipse:eclipse
> command for example, the tools project depends on the binary artifacts
> generated from the maven build of the impl, lib and api projects .  What
> most developers are going to want is inter project dependencies.  So
there's
> quite a bit of manual deletion of jars from the class path
entries,  then,
> you might want for example the lib project to expose the api projects
> interface, etc. etc.
>
> I'm quite well practised at setting this up,  but its still a 5 minute
> job.
>
> Regards, Kelvin.
>
> On 14/06/07, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > On 6/14/07, Frank Budinsky < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I remember about a year ago discussing whether or not it is
> > > acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> > > .project files) into svn, and we decided to not do it. Does anyone
> > > remember if this was really an Apache policy, or just a decision we
> > made
> > > for Tuscany? If the latter, I wonder if we should reconsider.
> > Personally,
> > > I think it would be very convenient if we had the Eclipse .project
and
> >
> > > .classfile in the projects, so that people could just check out
> > Tuscany
> > > projects directly into Eclipse. For people not using Eclipse, having
> > these
> > > superfluous files around really doesn't seem like a big deal. I also
> > > wouldn't mind if someone wants to check-in other IDE (e.g. IDEA)
files
> > > that Eclipse users (like me) would just ignore.
> > >
> > > What do others think about this?
> >
> >
> > AFAIK there's no 'rule' that says this must not be done. However no
> > other
> > Apache (or non-Apache) project that i can think of does this so it
would
> > be
> > unusual  and that makes me wonder why.
> >
> > Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem
> > or is
> > there something else about it thats a pain? (Also we may be able to
get
> > rid
> > of the '-Peclipse' bit now if that would make it easier to bare?
> >
> >...ant
> >
>
>

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Simon Laws]

Hi, a couple of points in line...

On 6/14/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

I have migrated all content (or atleast most - folks who have added
something to the main wiki in the last 24 hrs, please check and copy over
the changes to TUSCANYWIKI).  I have provided all 'create' permissions to
confluence-users.  So, if somebody is having trouble creating pages,
please
let me know.

As for contributing content to this wiki here is what comes to my mind...
- committers and non-committers may create content on the TUSCANYWIKI.



Also, for site updates, anyone can copy existing pages from the current web
site by cut and pasting the source from the  TUSCANY space into the
TUSCANYWIKI space.

- committers can copy over the contents to TUSCANY after they are done with

TUSCANYWIKI to ensure that the two are in sync.  I am yet to figure out an
automated way to do this.



I don't think we need an automated way of doing this as it would remove the
human oversight that we are introducing by having two spaces.

- non committers, when they are done with some content, can post a JIRA to

the ML with a link to the TUSCANYWIKI page that needs to be synchronized
with TUSCANY



We need people to attach the source rather than a link
1/ With a link the linked page may change and what they intented to submit
may not be what gets reviewed.
2/ People attaching content to JIRA are checking a box to say that they are
contributing it to Apache. Difficult to audit this if a link is attached.

- committers looking into a JIRA can go over to TUSCANYWIKI and review the

changes and simply copy over the page to TUSCANY

Thats all I can think about at the present moment and please feel free to
suggest better alternatives to this.

Thanks

- Venkat

On 6/14/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> Can you please also outline what  are the steps that a contributor can
> follow to provide updates to the website through this wiki?
>
> Thanks,
> Haleh
>
> On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I have created the Tuscany Wiki space now on confluence -
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Index.
> >
> > Mike, I need help with copying the pages over from TUSCANY and then
> > stubbing
> > the autoexport for TUSCANYWIKI.  Right now I just about see export and
> > import of spaces.  Thanks
> >
> > - Venkat
> >
> > On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> > >
> > > Venkat,
> > >
> > > +1 from me.
> > >
> > > How to migrate content?  I assume that you mean how do we control
the
> > > process?  The steps in actually moving content are reasonably
> > > straightforward - but the process for deciding to do it must mirror
> that
> > > for placing code into trunk, as mentioned on some other emails...
> > >
> > >
> > > Yours,  Mike.
> > >
> > > Venkata Krishnan wrote:
> > > > Hi, I have the admin access now.  I am able to see the 'Create
> Space'
> > > > option
> > > > on the dashboard now.  Before I go ahead let me conform the
> following
> > > >
> > > > - We are going to create a space named 'Tuscany Wiki' with key
> > > > 'TUSCANYWIKI'
> > > > - All contents of the present wiki space 'TUSCANY' will be copied
> over
> > > to
> > > > this new space
> > > > - We will disable the html autoexport for TUSCANYWIKI as we really
> > don't
> > > > need this.
> > > > - TUSCANYWIKI will be open to all confluence users.
> > > >
> > > > Please let me know if any of you have concerns about all of
> > this.  Also,
> > > > are
> > > > we clear about how we are going to migrate content submitted on
> > > TUSCANYWIKI
> > > > over to TUSCANY?
> > > >
> > > > Thanks
> > > >
> > > > - Venkat
> > > >
> > > > On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > >>
> > > >> Ok, thanks Venkat for looking into this.
> > > >>
> > > >> Simon
> > > >>
> > > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

[jira] Closed: (TUSCANY-1297) xsi:type in generated XML causes it not to validate/load into: visual studio or Mindreef SOAPscope

[Matthew Peters (JIRA)]

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

Matthew Peters closed TUSCANY-1297.
---


I concur this is fixed. Thank you! 

> xsi:type in generated XML causes it not to validate/load into: visual studio 
> or Mindreef SOAPscope
> --
>
> Key: TUSCANY-1297
> URL: https://issues.apache.org/jira/browse/TUSCANY-1297
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: any
>Reporter: Matthew Peters
> Fix For: Cpp-Next
>
>
> We use SDO to build and generate WSDL. We use the standard WSDL and SOAP 
> schemas (schemata?) to build the model then add port, operation, binding etc. 
> elements, then serialise the lot to XML. There are occasional xsi:type 
> attributes in the serialised XML which cause the WSDL not to validate or load 
> in visual studio. Here is a snippet from WSDL that we have generated in this 
> way:
>  type="tns2:Labnet_API_LabnetOnline_001_ImplementationPortType">
> 
>   
> 
>   
>   
> 
>   
>   
> 
>  transport="http://schemas.xmlsoap.org/soap/http"; style="document"/>
>   
> These xsi:type attributes cause this WSDL to fail to load. I quote one of our 
> users:
> > MS Visual Studio (I'm using Visual Web Dev 2005 Express Edition) will
> > not import a SCA generated WSDL.  It complains that it does not validate
> > because of the following element attributes:
> > xsi:type="tns3:tBody"  of 
> > xsi:type="tns3:tAddress" of 
> > Stripping out these attributes resolved the VS WSDL import problem.
> and a different bug report but the same problem:
> > WSDL generated does not validate (ran against the oXygen editor and
> Mindreef SOAPscope). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: IDE-specific files in svn

[ant elder]

Right thats the problem isn't it. If we check in the IDE files in we're
assuming one particular way of using the code. For the SCA project which is
quite big i've several different workspaces - one with every thing including
modules, samples and itest, another workspace just with modules, and another
just with samples etc. That wouldn't work with the IDE files checked in as
I'd have to change them for the the different workspaces and then when doing
checkin's try real hard to not accidentally commit my local changes to the
IDE files which would be a real pain and almost certainly quite often happen
by accident.

  ...ant

On 6/14/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


There's pain in the process, not huge, but irritating

first off there's the definition of the M2_REPO variable,  not a huge
problem, especially if you stick to just one workspace.  I tend to create
workspaces as and when I need them,  and I can't see how to make my variable
definition cross multiple workspaces.

Next, and probably more significant is removing the binary dependencies
and setting up inter project dependencies.   After the maven eclipse:eclipse
command for example, the tools project depends on the binary artifacts
generated from the maven build of the impl, lib and api projects .  What
most developers are going to want is inter project dependencies.  So there's
quite a bit of manual deletion of jars from the class path entries,  then,
you might want for example the lib project to expose the api projects
interface, etc. etc.

I'm quite well practised at setting this up,  but its still a 5 minute
job.

Regards, Kelvin.

On 14/06/07, ant elder < [EMAIL PROTECTED]> wrote:
>
> On 6/14/07, Frank Budinsky < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I remember about a year ago discussing whether or not it is
> > acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> > .project files) into svn, and we decided to not do it. Does anyone
> > remember if this was really an Apache policy, or just a decision we
> made
> > for Tuscany? If the latter, I wonder if we should reconsider.
> Personally,
> > I think it would be very convenient if we had the Eclipse .project and
>
> > .classfile in the projects, so that people could just check out
> Tuscany
> > projects directly into Eclipse. For people not using Eclipse, having
> these
> > superfluous files around really doesn't seem like a big deal. I also
> > wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
> > that Eclipse users (like me) would just ignore.
> >
> > What do others think about this?
>
>
> AFAIK there's no 'rule' that says this must not be done. However no
> other
> Apache (or non-Apache) project that i can think of does this so it would
> be
> unusual  and that makes me wonder why.
>
> Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem
> or is
> there something else about it thats a pain? (Also we may be able to get
> rid
> of the '-Peclipse' bit now if that would make it easier to bare?
>
>...ant
>

Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus

[Venkata Krishnan]

Hi,

I have migrated all content (or atleast most - folks who have added
something to the main wiki in the last 24 hrs, please check and copy over
the changes to TUSCANYWIKI).  I have provided all 'create' permissions to
confluence-users.  So, if somebody is having trouble creating pages, please
let me know.

As for contributing content to this wiki here is what comes to my mind...
- committers and non-committers may create content on the TUSCANYWIKI.
- committers can copy over the contents to TUSCANY after they are done with
TUSCANYWIKI to ensure that the two are in sync.  I am yet to figure out an
automated way to do this.
- non committers, when they are done with some content, can post a JIRA to
the ML with a link to the TUSCANYWIKI page that needs to be synchronized
with TUSCANY
- committers looking into a JIRA can go over to TUSCANYWIKI and review the
changes and simply copy over the page to TUSCANY

Thats all I can think about at the present moment and please feel free to
suggest better alternatives to this.

Thanks

- Venkat

On 6/14/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Can you please also outline what  are the steps that a contributor can
follow to provide updates to the website through this wiki?

Thanks,
Haleh

On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have created the Tuscany Wiki space now on confluence -
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Index.
>
> Mike, I need help with copying the pages over from TUSCANY and then
> stubbing
> the autoexport for TUSCANYWIKI.  Right now I just about see export and
> import of spaces.  Thanks
>
> - Venkat
>
> On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> >
> > Venkat,
> >
> > +1 from me.
> >
> > How to migrate content?  I assume that you mean how do we control the
> > process?  The steps in actually moving content are reasonably
> > straightforward - but the process for deciding to do it must mirror
that
> > for placing code into trunk, as mentioned on some other emails...
> >
> >
> > Yours,  Mike.
> >
> > Venkata Krishnan wrote:
> > > Hi, I have the admin access now.  I am able to see the 'Create
Space'
> > > option
> > > on the dashboard now.  Before I go ahead let me conform the
following
> > >
> > > - We are going to create a space named 'Tuscany Wiki' with key
> > > 'TUSCANYWIKI'
> > > - All contents of the present wiki space 'TUSCANY' will be copied
over
> > to
> > > this new space
> > > - We will disable the html autoexport for TUSCANYWIKI as we really
> don't
> > > need this.
> > > - TUSCANYWIKI will be open to all confluence users.
> > >
> > > Please let me know if any of you have concerns about all of
> this.  Also,
> > > are
> > > we clear about how we are going to migrate content submitted on
> > TUSCANYWIKI
> > > over to TUSCANY?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> > > On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > >>
> > >> Ok, thanks Venkat for looking into this.
> > >>
> > >> Simon
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: Serving web content from embedded Tomcat and Jetty

[ant elder]

On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


ant elder wrote:
> On 6/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> In multiple instances I've run into an annoying limitation of our
>> embedded Tomcat and Jetty support... We cannot serve Web content, HTML
>> pages, scripts etc. when we run Tomcat or Jetty embedded in a J2SE
>> program. This makes it more difficult than it should be to test SCA
>> applications that use our JSON-RPC binding in particular, as you need
to
>> package these applications in WARs, deploy them to a standalone Tomcat
>> or Jetty, use remote debugging to step through them etc... as opposed
to
>> simply running them from a J2SE program's main()...
>>
>> I'd like to leverage a small variation of our Crud/resource
>> implementation type sample to fix that, and simply use a component to
>> serve web content out of a directory inside an application.
>>
>> Here's how the helloworld-jsonrpc sample composite will look with that
>> component implementation (see the BEGIN/END new-stuff section):
>>
>> http://www.osoa.org/xmlns/sca/1.0";
>>   targetNamespace="http://sample";
>>   xmlns:sample="http://sample";
>>name="helloworldjsonrpc">
>>
>> 
>> 
>>  > interface="helloworldjsonrpc.HelloWorldService"/>
>>  
>> 
>> > class="helloworldjsonrpc.HelloWorldServiceImpl"/>
>> 
>>
>> 
>>
>> 
>> 
>> 
>>
>> 
>>
>> 
>>
>> With that simple change, we will be able to run directly from J2SE and
>> serve Web content out of the configured directory... so we won't have
to
>> always package the whole app in a WAR and deploy it to a standalone Web
>> container.
>>
>> Thoughts?
>>
>> If there's no objection, I'd like to start adding that support later
>> this week.
>
>
> Sounds cool, and it would be really good for apps to work with the
> standalone http hosts.
>
> But what exactly does implementation.webResource do? Doesn't there
> need to
> be some sort of binding on the MyHelloWorldContent component to expose
> it as
> an http resource?
>
>   ...ant
>

Yes, a simplified HTTP binding, which just registers the default file
servlet, configured with the binding's uri and the location specified on
the webResource, with the servlet host.

Since it's going to be pretty limited I'm not planning to expose it as a
new module separate from the implementation module, unless other Tuscans
are interested in it and want to pick it up.

in general application developers won't even have to know about it.

The following declaration:





will turn into a component declaring a default service with that default
HTTP binding configured to map uri="myfiles" to a file servlet serving
files in folder "myfiles".

If people really really really wanted to tweak the binding they would
write something like that:


http://localhost:1234/myuri"/>




but I'm thinking about not implementing that XML support initially, and
wait until people actually ask for it before over-engineering this.



Maybe I'll get used to it now you've explained it but it did seem a bit
confusing to me that a component/implementation could magically use a
different default binding. Not sure if this is better or worse or even
allowed, but could it be some contribution file reader component thats
invisible and you use an explicit  with an http binding to make the
files available? Eg:

   
   
   

  ...ant

Re: IDE-specific files in svn

[kelvin goodson]

There's pain in the process, not huge, but irritating

first off there's the definition of the M2_REPO variable,  not a huge
problem, especially if you stick to just one workspace.  I tend to create
workspaces as and when I need them,  and I can't see how to make my variable
definition cross multiple workspaces.

Next, and probably more significant is removing the binary dependencies and
setting up inter project dependencies.   After the maven eclipse:eclipse
command for example, the tools project depends on the binary artifacts
generated from the maven build of the impl, lib and api projects .  What
most developers are going to want is inter project dependencies.  So there's
quite a bit of manual deletion of jars from the class path entries,  then,
you might want for example the lib project to expose the api projects
interface, etc. etc.

I'm quite well practised at setting this up,  but its still a 5 minute job.

Regards, Kelvin.

On 14/06/07, ant elder <[EMAIL PROTECTED]> wrote:


On 6/14/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I remember about a year ago discussing whether or not it is
> acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> .project files) into svn, and we decided to not do it. Does anyone
> remember if this was really an Apache policy, or just a decision we made
> for Tuscany? If the latter, I wonder if we should reconsider.
Personally,
> I think it would be very convenient if we had the Eclipse .project and
> .classfile in the projects, so that people could just check out Tuscany
> projects directly into Eclipse. For people not using Eclipse, having
these
> superfluous files around really doesn't seem like a big deal. I also
> wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
> that Eclipse users (like me) would just ignore.
>
> What do others think about this?


AFAIK there's no 'rule' that says this must not be done. However no other
Apache (or non-Apache) project that i can think of does this so it would
be
unusual  and that makes me wonder why.

Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem or
is
there something else about it thats a pain? (Also we may be able to get
rid
of the '-Peclipse' bit now if that would make it easier to bare?

   ...ant

Re: IDE-specific files in svn

[kelvin goodson]

Sounds good to me,  we'd just have to make some decisions about the nature
of the classpath entries. I would assume that for the api, lib, impl, tools
and plugins projects we would set up inter-project dependencies,  but what
would we do about classpath entries for binary artifacts such as EMF?  The
current way we describe relies on a local maven repository,  but it would be
nice not to have to assume that the user has maven.  It would also be nice
not to have lots of red error markers over the eclipse workspace indicating
that the 3rd party dependencies need resolving. Are we allowed to put binary
3rd party dependencies into svn?

Kelvin.

On 14/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote:


Frank,

I'm of the opinion that anything that makes it easier for developers to
get to grips with our stuff, the better.  Personally, having to to
create all the Eclipse stuff has been a pain, so doing this would save
me time and effort.

I agree with your sentiment that if others want to add features for
other IDE's then that should be OK too.

Yours,  Mike.

Frank Budinsky wrote:
> Hi,
>
> I remember about a year ago discussing whether or not it is
> acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
> .project files) into svn, and we decided to not do it. Does anyone
> remember if this was really an Apache policy, or just a decision we made
> for Tuscany? If the latter, I wonder if we should reconsider.
Personally,
> I think it would be very convenient if we had the Eclipse .project and
> .classfile in the projects, so that people could just check out Tuscany
> projects directly into Eclipse. For people not using Eclipse, having
these
> superfluous files around really doesn't seem like a big deal. I also
> wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
> that Eclipse users (like me) would just ignore.
>
> What do others think about this?
>
> Thanks,
> Frank.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: IDE-specific files in svn

[ant elder]

On 6/14/07, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Hi,

I remember about a year ago discussing whether or not it is
acceptable/appropriate to check-in IDE specific files (e.g., Eclipse
.project files) into svn, and we decided to not do it. Does anyone
remember if this was really an Apache policy, or just a decision we made
for Tuscany? If the latter, I wonder if we should reconsider. Personally,
I think it would be very convenient if we had the Eclipse .project and
.classfile in the projects, so that people could just check out Tuscany
projects directly into Eclipse. For people not using Eclipse, having these
superfluous files around really doesn't seem like a big deal. I also
wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files
that Eclipse users (like me) would just ignore.

What do others think about this?



AFAIK there's no 'rule' that says this must not be done. However no other
Apache (or non-Apache) project that i can think of does this so it would be
unusual  and that makes me wonder why.

Is it just the extra "mvn -Pelcipse eclipse:eclipse" thats the problem or is
there something else about it thats a pain? (Also we may be able to get rid
of the '-Peclipse' bit now if that would make it easier to bare?

  ...ant

Re: 0.91 release?

[ant elder]

Taking a branch around the 20th sounds ok to me.

The high level things I'm focusing on for the 0.91 release are:

- Simplification of using script components (working without .componentType
side files)
- First cut of the simpler binding/implementation SPI
- clean up of ajax and jsonrpc bindings
- The EJB binding

I'd also said to someone on the user list I'd get WS services without wsdl
working so will try to do that as well.

Most of the code for those is close-ish to being done, though there's still
a whole lot of related sample work to get done.

I'd started a wiki page for 0.91 at
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents

  ...ant

On 6/13/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Thanks for the faith and encouragement.  This is going to be my first
experience and I am sure of getting all the help from you folks to pull
this
off successfully.

So, to start with, I propose to cut a branch around June 20th, 2007.  If
people are ok with this, then all that we'd like to be a part of 0.91should
get in by then (June 20th, 2007).  Does that work fine with everybody?

Also, I'd also like to list down the significant additions / enhancements
over 0.90 for the Release Notes.  You can state the item here on this
thread
and I will take care of recording it.

- Venkat

On 6/13/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> +1 from me too.  I'm sure Venkat will do a fine job.
>
>Simon
>
> Jean-Sebastien Delfino wrote:
>
> > Simon Laws wrote:
> >
> >> Yeah, Venkat did loads on the last release. +1 from me for Venkat as
> >> 0.91 RM
> >>
> >> Simon
> >>
> >
> > +1 from me
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: IDE-specific files in svn

[Mike Edwards]

Frank,

I'm of the opinion that anything that makes it easier for developers to 
get to grips with our stuff, the better.  Personally, having to to 
create all the Eclipse stuff has been a pain, so doing this would save 
me time and effort.


I agree with your sentiment that if others want to add features for 
other IDE's then that should be OK too.


Yours,  Mike.

Frank Budinsky wrote:

Hi,

I remember about a year ago discussing whether or not it is 
acceptable/appropriate to check-in IDE specific files (e.g., Eclipse 
.project files) into svn, and we decided to not do it. Does anyone 
remember if this was really an Apache policy, or just a decision we made 
for Tuscany? If the latter, I wonder if we should reconsider. Personally, 
I think it would be very convenient if we had the Eclipse .project and 
.classfile in the projects, so that people could just check out Tuscany 
projects directly into Eclipse. For people not using Eclipse, having these 
superfluous files around really doesn't seem like a big deal. I also 
wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files 
that Eclipse users (like me) would just ignore.


What do others think about this?

Thanks,
Frank.

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




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

Re: Build Failure( - Compilation failure) [ \script\ScriptInvoker.java:[52,66] unreported exception java.lang.NoSuchMethodException ]

[ant elder]

This looks like a bug in Apache BSF to me. The invokeMethod and
invokeFunction methods of javax.script.Invocable should declare
java.lang.NoSuchMethodExcept as a checked exception but they don't so the
Tuscany code doesn't catch that, but when building with JDK6 its using the
jsr223 api's from the jdk so you get the error.

Thanks for finding this. Any chance you'd like to submit a patch to  fix it?


The class with the bug is here:
https://svn.apache.org/repos/asf/jakarta/bsf/trunk/bsf3/bsf-api/src/main/java/javax/script/Invocable.java
The JSR 223 doc is here:
http://jcp.org/aboutJava/communityprocess/edr/jsr223/

  ...ant

On 6/13/07, ant elder <[EMAIL PROTECTED]> wrote:


Which JDK version are you using - are you using JDK6 by any chance? (and
if so could you try using 5?)

  ...ant

On 6/13/07, sam tam < [EMAIL PROTECTED]> wrote:
>
> Hello,
> Am getting some compilation failure during the build !
>
> Does any one have any solution for this !
>
>
>
> 
__
>
>
>
> [INFO] Building Apache Tuscany Implementation Script
> [INFO]task-segment: [install]
> [INFO]
>
> -
> ---
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> Downloading:
> http://people.apache.org/repo/m2-incubating-repository/groovy/groov
> y-all/1.0/groovy-all-1.0.pom
> Downloading:
> http://repo1.maven.org/maven2/groovy/groovy-all/1.0/groovy-all-1.0.
> pom
> [INFO] [compiler:compile]
> [INFO] Compiling 5 source files to
> D:\Tuscany\sca\modules\implementation-script\
> target\classes
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
>
> [INFO] Compilation failure
>
> 
D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
> a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
> java.lan
> g.NoSuchMethodException ; must be caught or declared to be thrown
>
>
>
>
> 
D:\Tuscany\sca\modules\implementation-script\src\main\java\org\apache\tuscany\sc
> a\implementation\script\ScriptInvoker.java:[52,66] unreported exception
> java.lan
> g.NoSuchMethodException; must be caught or declared to be thrown
>
>
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> 
> [INFO] Total time: 1 minute 29 seconds
> [INFO] Finished at: Wed Jun 13 18:37:16 IST 2007
>
> 
__
>
>
>
>
>
> Also i have cleaned the repo and tried again, yet the same error !
>
> Kindly help me out !
>
> Thanks in advance,
>
> Sam...
>