Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)

[Pete Robbins]

+1

On 12/05/2008, Mark Combellack <[EMAIL PROTECTED]> wrote:
> Get's my +1 too.
>
> Mark
>
> > -Original Message-
> > From: ant elder [mailto:[EMAIL PROTECTED]
> > Sent: 10 May 2008 08:17
> > To: tuscany-dev
> > Subject: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
> >
> > Restarting the graduation vote with the updated proposal words, please
> > vote
> > on the proposal below to graduate Tuscany to a TLP.
> >
> > +1 from me.
> >
> >...ant
> >
> >  X. Establish the Apache Tuscany Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best
> > interests of the Foundation and consistent with the Foundation's
> > purpose to establish a Project Management Committee charged with
> > the creation and maintenance of open-source software for
> > distribution at no charge to the public, that simplifies the
> > development, deployment and management of distributed applications
> > built as compositions of service components. These components
> > may be implemented with a range of technologies and connected
> > using a variety of communication protocols. This software will
> > implement relevant open standards including, but not limited to,
> > the Service Component Architecture standard defined by the OASIS
> > OpenCSA member section, and related technologies.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Tuscany Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to Apache Tuscany;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Tuscany" be
> > and hereby is created, the person holding such office to
> > serve at the direction of the Board of Directors as the chair
> > of the Apache Tuscany Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Tuscany Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and
> > hereby are appointed to serve as the initial members of the
> > Apache Tuscany Project:
> >
> > * Adriano Crestani 
> > * ant elder 
> > * Brady Johnson 
> > * Frank Budinsky 
> > * Ignacio Silva-Lepe 
> > * Jean-Sebastien Delfino 
> > * kelvin goodson 
> > * Luciano Resende 
> > * Mark Combellack 
> > * Matthieu Riou 
> > * Mike Edwards 
> > * Paul Fremantle 
> > * Pete Robbins 
> > * Raymond Feng 
> > * Simon Laws 
> > * Simon Nash 
> > * Venkata Krishnan 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
> > be appointed to the office of Vice President, Apache Tuscany, to
> > serve in accordance with and subject to the direction of the
> > Board of Directors and the Bylaws of the Foundation until
> > death, resignation, retirement, removal or disqualification,
> > or until a successor is appointed; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Tuscany podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Tuscany podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
>
>


-- 
Pete

Re: [VOTE] Graduate Apache Tuscany as a Top Level Project

[Pete Robbins]

+1 for graduation as a TLP

On 29/04/2008, Mark Combellack <[EMAIL PROTECTED]> wrote:
> Here's my +1 for Tuscany to graduate as a TLP.
>
> Thanks,
>
> Mark
>
> > -Original Message-
> > From: ant elder [mailto:[EMAIL PROTECTED]
> > Sent: 28 April 2008 19:16
> > To: tuscany-dev
> > Subject: [VOTE] Graduate Apache Tuscany as a Top Level Project
> >
> > We've done a lot of work since last October. We now have a diverse
> > community
> > of contributors and have demonstrated the ability to attract new
> > committers
> > to create an even more diverse community, we have shown we can do releases
> > based on Apache guidelines, and we have shown we conduct our discussions
> > in
> > public within full view of the community and can resolve disagreements on
> > the lists. I think we're ready, so please vote on the proposal below to
> > graduate Tuscany to a TLP.
> >
> > +1 from me.
> >
> >...ant
> >
> > X. Establish the Apache Tuscany Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best
> > interests of the Foundation and consistent with the Foundation's
> > purpose to establish a Project Management Committee charged with
> > the creation and maintenance of open-source software that
> > simplifies the development and deployment of service oriented
> > applications and provides a managed service-oriented runtime
> > based on the standards defined by the OASIS OpenCSA group,
> > for distribution at no charge to the public.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Tuscany Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to Apache Tuscany;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Tuscany" be
> > and hereby is created, the person holding such office to
> > serve at the direction of the Board of Directors as the chair
> > of the Apache Tuscany Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Tuscany Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and
> > hereby are appointed to serve as the initial members of the
> > Apache Tuscany Project:
> >
> >- Adriano Crestani 
> >- ant elder 
> >- Brady Johnson 
> >- Frank Budinsky 
> >- Ignacio Silva-Lepe 
> >- Jean-Sebastien Delfino 
> >- kelvin goodson 
> >- Luciano Resende 
> >- Mark Combellack 
> >- Matthieu Riou 
> >- Mike Edwards 
> >- Paul Fremantle 
> >- Pete Robbins 
> >- Raymond Feng 
> >- Simon Laws 
> >- Simon Nash 
> >- Venkata Krishnan 
> >
> >  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
> > be appointed to the office of Vice President, Apache Tuscany, to
> > serve in accordance with and subject to the direction of the
> > Board of Directors and the Bylaws of the Foundation until
> > death, resignation, retirement, removal or disqualification,
> > or until a successor is appointed; and be it further
> >
> > RESOLVED, that the Apache Tuscany Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Tuscany podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Tuscany podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
>
>


-- 
Pete

[jira] Commented: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-2041:
---

I checked in  a fix for this into the branch. If you could test it out, and it 
works ok, I'll create a patch for HEAD as well

> Repeated nill elements of extended type cause "Parser found unknown element" 
> exception
> --
>
> Key: TUSCANY-2041
> URL: https://issues.apache.org/jira/browse/TUSCANY-2041
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: XP SP2, VC7 
>    Reporter: Simon Laws
>Assignee: Pete Robbins
> Fix For: Cpp-Next
>
>
> With the schema
> http://www.w3.org/2001/XMLSchema"; 
> targetNamespace="http://www.example.org/AnnonTypes"; 
> xmlns:tns="http://www.example.org/AnnonTypes"; 
> elementFormDefault="qualified">
> 
> 
>   
> 
>  maxOccurs="unbounded">
>   
> 
>   
> 
>   
> 
>   
>   
> 
>   
>  
> 
> And XML
> http://www.example.org/AnnonTypes"; 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>  xsi:schemaLocation="http://www.example.org/AnnonTypes 
> AnnonTypes2.xsd ">
>   
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>   

[jira] Assigned: (TUSCANY-2041) Repeated nill elements of extended type cause "Parser found unknown element" exception

[Pete Robbins (JIRA)]

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

Pete Robbins reassigned TUSCANY-2041:
-

Assignee: Pete Robbins

> Repeated nill elements of extended type cause "Parser found unknown element" 
> exception
> --
>
> Key: TUSCANY-2041
> URL: https://issues.apache.org/jira/browse/TUSCANY-2041
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: XP SP2, VC7 
>    Reporter: Simon Laws
>Assignee: Pete Robbins
> Fix For: Cpp-Next
>
>
> With the schema
> http://www.w3.org/2001/XMLSchema"; 
> targetNamespace="http://www.example.org/AnnonTypes"; 
> xmlns:tns="http://www.example.org/AnnonTypes"; 
> elementFormDefault="qualified">
> 
> 
>   
> 
>  maxOccurs="unbounded">
>   
> 
>   
> 
>   
> 
>   
>   
> 
>   
>  
> 
> And XML
> http://www.example.org/AnnonTypes"; 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>  xsi:schemaLocation="http://www.example.org/AnnonTypes 
> AnnonTypes2.xsd ">
>   
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
>   

Re: [C++] Decrease memory footprint of Tuscany Native?

[Pete Robbins]

I think the libxml2/iconv libraries are only required by SDO.
Factoring SDO out of SCA implementation would require some substantial
rework as we use SDO for parsing and loading our xml configuration
files. Altering the way we do this would require a new method of
parsing the files which again may use libxml or some other parsing
libraries.

On 31/12/2007, Philipp Konradi <[EMAIL PROTECTED]> wrote:
> Hi Andy,
>
> The memory footprint gets reduced from 6.7MB to 5.3MB if axis/axiom dlls are
> taken out.
> Assumed the dependancy to SDO gets configurable then the footprint can be
> reduced at least by further 0.7MB --> 4.6MB.
> Unfortunately still too much.
>
> Libxml2 and iconv dlls hold another bigger memory saving potential of
> 0.9MBeach.
> Assumed both can be replaced by some leaner alternatives then we would get
> much closer to the 2MB border.
> Any idea regarding how difficult that might be? Any other thoughts?
>
> Speaking of Embedded Domains I have a particular application in mind.
> It's a large distributed system consisting of many controllers communicating
> with each other. These controllers are usually small software pieces running
> in a device and managing several sensors/actors or other controllers.
> What we are currently looking for is an platform ideally:
> - allowing to inject dependencies and to compose such controllers out of
> smaller components
> - allowing to separate communication details from business logic
> - allowing some flexibility regarding communication protocols to use
> Tuscany SCA Native is one of the candidates we evaluate right now regading
> meeting the non-functional requirements. Memory footprint seems to be one of
> the biggest barriers.
>
> Regards,
> Philipp
>
>
>
> -Ursprüngliche Nachricht-
> Von: Andrew Borley [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 20. Dezember 2007 10:33
> An: tuscany-dev@ws.apache.org
> Betreff: Re: [C++] Decrease memory footprint of Tuscany Native?
>
> Hi Philipp,
>
> The axis2 stuff in the native codebase is purely to support the Web
> Service binding - you shouldn't need those DLLs to run the
> CPPCalculator as this sample no longer does any web service calls.
> The SDO, libxml, etc dlls are still required as these are used within
> sca for message propagation - but perhaps, in the future, they
> shouldn't be.. (SDO should perhaps be a configuarble data-bainding ,
> as in the java codebase). Embedded Domains sounds like an interesting
> scenario for Tuscany, could you expand?
>
> I'm not sure what the scope for reducing memory footprint would be -
> what happens if you take out the axis/axiom dlls?
>
> Cheers
> Andy
>
>
> On Dec 19, 2007 11:26 PM, Philipp Konradi <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > currently I'm investigating on usability of Tuscany SCA
> > Native in Embedded Domains.
> > One of the important requirements there is small memory footprint.
> > Starting the CppCalculator (local service invocation) I found out that it
> > requires currently ca. 6MB.
> > In the list of loaded dlls I saw axis2, axiom, sdo and some more
> libraries.
> >
> > My question now is: Is it possible to significantly decrease the memory
> > footprint in a reasonable amount of time/effort? Let's say to 2MB?
> >
> > Maybe some developers of the Native Runtime can help me with some
> > information?
> >
> > Many thanks,
> > Philipp
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-- 
Pete

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

Re: BigBank C++ running problem

[Pete Robbins]

Has the ws extension been built and installed in your runtime? e.g. in
 /extensions/ws

This extension should register the WebServiceBinding.

Cheers,

On 10/12/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Can somebody help me with this problem:
>
> E:\Adriano\Faculdade\Tuscany\Native_Release\cpp\sca\deploy\samples\CppBigBank\bi
> gbank.client>runclient.bat
> Using SCA installed at
> E:\Adriano\Faculdade\Tuscany\Native_Release\cpp\sca\deplo
> y
> Using SDO installed at
> E:\Adriano\Faculdade\Tuscany\Native_Release\cpp\sdo\deplo
> y
> Using Axis2C installed at E:\Adriano\Faculdade\Tuscany\cpp\axis2c-
> bin-0.96-win32
>
> 3892:3144 Unsupported binding type:
> http://www.osoa.org/xmlns/sca/1.0#WebService
> Binding
> Exception
>  Class:   SystemConfigurationException
>  Description: Binding type not supported:
> http://www.osoa.org/xmlns/sca/1.0#
> WebServiceBinding
>  Origin:
>   File:
> E:\Adriano\Faculdade\Tuscany\Native_Release\cpp\sca\runtime\
> core\src\tuscany\sca\model\ModelLoader.cpp
>   Line:650
>   Function:tuscany::sca::model::ModelLoader::addCompositeService
>  Path:
>   File:
> E:\Adriano\Faculdade\Tuscany\Native_Release\cpp\sca\runtime\ex
> tensions\cpp\src\osoa\sca\CompositeContext.cpp
>   Line:  101
>   Function:  osoa::sca::CompositeContext::getCurrent
>
> I'm getting this message when running SCA BigBank and Calculator sample.
> Does anybody know what I'm missing here?
>
> Thanks,
> Adriano Crestani
>


-- 
Pete

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

Re: [SDO C++] Escaping special characters in XML

[Pete Robbins]

I've applied this patch to the branch. I'll apply it to head later. I
had to change a couple of lines to construct SDOString from a start
and end iterator as this caused compile errors on VC8.

Cheers,

On 30/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> I've uploaded a proposed patch for
> http://issues.apache.org/jira/browse/TUSCANY-1553. Please take a look.
> It runs all the PHP regression tests without problems, and also makes
> the uploaded test run clean.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SDO C++] Problem with special characters in property names

[Pete Robbins]

I've checked a fix for this into the branch. I'll apply it to head later.

Cheers,

On 22/11/2007, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'll need to look into this. I can't find any restrictions in the spec
> for characters in property names so I'm assuming NCName. So I think
> your patch looks good.
>
> The usual place where hyphens in names become a problem is when
> mapping to programming language label but that is something that code
> gen should take care of.
>
> This will be an issue in the HEAD as well as the branch.
>
> Cheers,
>
> On 16/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> > A PHP user is facing a problem using a schema which uses the - (hyphen)
> > character in element names, as second or subsequent character. We thinks
> > this is valid XML, according to
> > http://www.w3.org/TR/REC-xml/#NT-NameChar, where the grammar is:
> >
> > [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar
> > | Extender
> > [5] Name ::= (Letter | '_' | ':') (NameChar)*
> >
> > What's actually happening is that he's getting an SDO_PropertyNotFound
> > exception when he tries to set the property. Within the PHP
> > implementation, this is resolving to
> >
> >   dop->set('element-name', value)
> >
> > which ends up at:
> >
> > void DataObjectImpl::setSDOValue(const SDOString& path,
> > const SDOValue& sval,
> > const SDOString& dataType)
> >
> > Practically the first thing that method does is to call stripPath(),
> > which removes the hyphen from the element name - resulting in the
> > exception later on.
> >
> > I tried this patch:
> > ### Eclipse Workspace Patch 1.0
> > #P pecl-sdo-FULMAR
> > Index: commonj/sdo/DataObjectImpl.cpp
> > ===
> > RCS file: /repository/pecl/sdo/commonj/sdo/DataObjectImpl.cpp,v
> > retrieving revision 1.20
> > diff -u -r1.20 DataObjectImpl.cpp
> > --- commonj/sdo/DataObjectImpl.cpp  24 Aug 2007 15:20:21 -  1.20
> > +++ commonj/sdo/DataObjectImpl.cpp  16 Nov 2007 19:10:23 -
> > @@ -951,7 +951,7 @@
> >  //
> >
> >  const char* DataObjectImpl::templateString =
> > -"
> > /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#";
> > +"
> > /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#-";
> >
> >  char* DataObjectImpl::stripPath(const char* path)
> >  {
> >
> > which appears to fix the problem. But I expect you'll tell me there is
> > more to it than that. I know there are existing issues about valid
> > characters in XPaths. But it seems a shame to prevent this simple
> > scenario from working because of Xpath.
> >
> > (NB we're still on the branch. I don't know if this also applies to the
> > trunk code.)
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Pete
>


-- 
Pete

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

Re: [SDO C++] Problem with special characters in property names

[Pete Robbins]

I'll need to look into this. I can't find any restrictions in the spec
for characters in property names so I'm assuming NCName. So I think
your patch looks good.

The usual place where hyphens in names become a problem is when
mapping to programming language label but that is something that code
gen should take care of.

This will be an issue in the HEAD as well as the branch.

Cheers,

On 16/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> A PHP user is facing a problem using a schema which uses the - (hyphen)
> character in element names, as second or subsequent character. We thinks
> this is valid XML, according to
> http://www.w3.org/TR/REC-xml/#NT-NameChar, where the grammar is:
>
> [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar
> | Extender
> [5] Name ::= (Letter | '_' | ':') (NameChar)*
>
> What's actually happening is that he's getting an SDO_PropertyNotFound
> exception when he tries to set the property. Within the PHP
> implementation, this is resolving to
>
>   dop->set('element-name', value)
>
> which ends up at:
>
> void DataObjectImpl::setSDOValue(const SDOString& path,
> const SDOValue& sval,
> const SDOString& dataType)
>
> Practically the first thing that method does is to call stripPath(),
> which removes the hyphen from the element name - resulting in the
> exception later on.
>
> I tried this patch:
> ### Eclipse Workspace Patch 1.0
> #P pecl-sdo-FULMAR
> Index: commonj/sdo/DataObjectImpl.cpp
> ===
> RCS file: /repository/pecl/sdo/commonj/sdo/DataObjectImpl.cpp,v
> retrieving revision 1.20
> diff -u -r1.20 DataObjectImpl.cpp
> --- commonj/sdo/DataObjectImpl.cpp  24 Aug 2007 15:20:21 -  1.20
> +++ commonj/sdo/DataObjectImpl.cpp  16 Nov 2007 19:10:23 -
> @@ -951,7 +951,7 @@
>  //
>
>  const char* DataObjectImpl::templateString =
> -"
> /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#";
> +"
> /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#-";
>
>  char* DataObjectImpl::stripPath(const char* path)
>  {
>
> which appears to fix the problem. But I expect you'll tell me there is
> more to it than that. I know there are existing issues about valid
> characters in XPaths. But it seems a shame to prevent this simple
> scenario from working because of Xpath.
>
> (NB we're still on the branch. I don't know if this also applies to the
> trunk code.)
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [Propose] A Tuscany Native release with SCA, SDO and DAS

[Pete Robbins]

Is the spec issue applicable to Java SDO as well as C++?

Cheers,

On 07/11/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I just submit some negative WSDL unit tests (svn revision 592942). They
> test that the WSDL parsing correctly handles erroneous WSDLs.
>
> In the process of writing them, I found 2 TuscanySDO bugs:
>https://issues.apache.org/jira/browse/TUSCANY-1900
>https://issues.apache.org/jira/browse/TUSCANY-1901
>
> And a pretty serious SDO spec issue. Michael Yoder can explain better,
> but basically the issue has to do with schemas that have a global
> element with xsd:any with maxOccurs > 1, you can only have a single
> valued property. This problem can be reproduced by uncommenting the
> following test case in runtime/core/test/main.cpp:
>TEST ( wsdlErrorsTest.testDuplicateSOAPAddress() );
> Basically the test fails because its expecting an SDO exception, but
> none is thrown.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Adriano Crestani
> Sent: Monday, November 05, 2007 10:08 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Propose] A Tuscany Native release with SCA, SDO and DAS
>
> thanks  brady ; )
>
> On Nov 5, 2007 12:43 PM, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> > good stuff. I'll check it out.
> >
> > On 05/11/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > I just submit the first SCA Native unit test. It's only a simple
> > > WSDL test, but it's a start :) This commit (svn revision 592062)
> > > includes the testing infrastructure and an incremental check in of
> > > the wsdl tests, meaning I have several more wsdl tests coming soon.
>
> > > I also have some composite tests planned to come soon. You'll also
> > > need to get svn revision 592064 to be able to run the tests from the
> root source dir.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, November 05, 2007 1:34 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [Propose] A Tuscany Native release with SCA, SDO and
> > > DAS
> > >
> > > Up to now we have tried to keep the distros separate so that we
> > > could, for example, create an SDO release without SCA. I'd like to
> > > keep it like this.
> > >
> > > Cheers,
> > >
> > > On 04/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > Agreed ; )
> > > >
> > > > Adriano Crestani
> > > >
> > > > On 11/2/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > My thought is that, SCA users might not be using SDO and/or DAS
> > > > > and vice versa, and if they use, they might have different
> versions
> > > > > playing together (e.g SCA X with SDO Y).   This is also the same
> > > > > pattern we have in the Java side, where SCA, SDO and DAS are
> > > > > released as separate packages.
> > > > >
> > > > > So, considering flexibility, I'd suggest to continue to use the
> > > > > same
> > >
> > > > > pattern used on the previous Native Release [1], and have
> > > > > separate artifacts freleased or each Native sub-project.
> > > > >
> > > > > Thoughts ?
> > > > >
> > > > > [1]
> > > > > http://people.apache.org/dist/incubator/tuscany/cpp/1.0-incubato
> > > > > r-M3
> > > > > /win32/
> > > > >
> > > > > On 11/1/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > > > Thanks everybody :D
> > > > > >
> > > > > > I'm studying right now how is the best way to distribute all
> > > > > > the 3
> > > > > projects
> > > > > > together. I'm thinking on place all into a root directory and
> > > > > > merge all
> > > > > 3
> > > > > > LICENSE, NOTICE and COPYING on this root directory is enough.
> > > > > > I thought about a top level build.xml too:
> &g

Re: Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool

[Pete Robbins]

This jar file will have to be part of the Release distributions as
well so we will need to include LICENCE information in a similar way
to our scagen jar
(cpp\sca\runtime\extensions\cpp\tools\scagen\META-INF)

Cheers,

On 07/11/2007, Pete Robbins <[EMAIL PROTECTED]> wrote:
> Yes, you're right we should fix it. The build for this jar should be v
> simple so probably does not need to include the system.xml etc..
>
> Cheers,
>
> On 07/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > I understand, but it's wrong, cause there is a circular dependency. But we
> > may left as it is, cause it will probably be deleted soon when the cpp-tasks
> > bug is fixed.
> >
> > Do you have any news about a fix for this bug Brady?
> >
> > Regards,
> > Adriano Crestani
> >
> > On Nov 7, 2007 3:45 AM, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > > The jar files are checked in to svn so should not be deleted I guess??
> > > It will be re-built if the java src gets updated.
> > >
> > > Cheers,
> > >
> > > On 07/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler
> > > that
> > > > is an adaptor that fixes a bug on cpp-tasks.
> > > >
> > > > However, when I try to build it from the source available on tools
> > > > directory, I get the following error:
> > > >
> > > > BUILD FAILED
> > > > E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml
> > > > :24: The following error occurred while executing this line:
> > > > E:\Adriano\cpp\sca\antscripts\system.xml:592: j
> > > > ava.lang.ClassNotFoundException:
> > > > tuscany.antCompilers.TuscanyMSVC8DevStudioCComp
> > > > iler
> > > >
> > > >
> > > > It occurs because build.xml located on \cpp\ > > das>\antscripts\
> > > > imports the system.xml that tries to define the compiler using the
> > > > TuscanyMSVC8DevStudioCCompiler class:
> > > >
> > > >   > > >extends="Tuscany-BaseCompiler"
> > > >classname="
> > > tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler">
> > > > > > > define="WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS"/>
> > > >  
> > > >
> > > >
> > > >
> > > > But, the adaptor is not compiled yet when the system.xml tries to define
> > > the
> > > > compiler.
> > > >
> > > > Is there a way to specify that ant should ignore this errors if the
> > > > TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any :
> > > (
> > > >
> > > > PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files
> > > > located on each project must be deleted.
> > > >
> > > > Adriano Crestani
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
> --
> Pete
>


-- 
Pete

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

Re: Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool

[Pete Robbins]

Yes, you're right we should fix it. The build for this jar should be v
simple so probably does not need to include the system.xml etc..

Cheers,

On 07/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> I understand, but it's wrong, cause there is a circular dependency. But we
> may left as it is, cause it will probably be deleted soon when the cpp-tasks
> bug is fixed.
>
> Do you have any news about a fix for this bug Brady?
>
> Regards,
> Adriano Crestani
>
> On Nov 7, 2007 3:45 AM, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> > The jar files are checked in to svn so should not be deleted I guess??
> > It will be re-built if the java src gets updated.
> >
> > Cheers,
> >
> > On 07/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler
> > that
> > > is an adaptor that fixes a bug on cpp-tasks.
> > >
> > > However, when I try to build it from the source available on tools
> > > directory, I get the following error:
> > >
> > > BUILD FAILED
> > > E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml
> > > :24: The following error occurred while executing this line:
> > > E:\Adriano\cpp\sca\antscripts\system.xml:592: j
> > > ava.lang.ClassNotFoundException:
> > > tuscany.antCompilers.TuscanyMSVC8DevStudioCComp
> > > iler
> > >
> > >
> > > It occurs because build.xml located on \cpp\ > das>\antscripts\
> > > imports the system.xml that tries to define the compiler using the
> > > TuscanyMSVC8DevStudioCCompiler class:
> > >
> > >   > >extends="Tuscany-BaseCompiler"
> > >classname="
> > tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler">
> > > > > define="WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS"/>
> > >  
> > >
> > >
> > >
> > > But, the adaptor is not compiled yet when the system.xml tries to define
> > the
> > > compiler.
> > >
> > > Is there a way to specify that ant should ignore this errors if the
> > > TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any :
> > (
> > >
> > > PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files
> > > located on each project must be deleted.
> > >
> > > Adriano Crestani
> > >
> >
> >
> > --
> > Pete
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>


-- 
Pete

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

Re: Problem with ant on building TuscanyMSVC8DevStudioCCompiler adaptor tool

[Pete Robbins]

The jar files are checked in to svn so should not be deleted I guess??
It will be re-built if the java src gets updated.

Cheers,

On 07/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> All 3 native projects have a tool called TuscanyMSVC8DevStudioCCompiler that
> is an adaptor that fixes a bug on cpp-tasks.
>
> However, when I try to build it from the source available on tools
> directory, I get the following error:
>
> BUILD FAILED
> E:\Adriano\cpp\sca\tools\ant_cpptasks\build.xml
> :24: The following error occurred while executing this line:
> E:\Adriano\cpp\sca\antscripts\system.xml:592: j
> ava.lang.ClassNotFoundException:
> tuscany.antCompilers.TuscanyMSVC8DevStudioCComp
> iler
>
>
> It occurs because build.xml located on \cpp\\antscripts\
> imports the system.xml that tries to define the compiler using the
> TuscanyMSVC8DevStudioCCompiler class:
>
>  extends="Tuscany-BaseCompiler"
>classname="tuscany.antCompilers.TuscanyMSVC8DevStudioCCompiler">
> define="WIN32,_CRT_SECURE_NO_DEPRECATE,_CRT_NON_CONFORMING_SWPRINTFS"/>
>  
>
>
>
> But, the adaptor is not compiled yet when the system.xml tries to define the
> compiler.
>
> Is there a way to specify that ant should ignore this errors if the
> TuscanyMSVC8DevStudioCCompiler.jar does not exists? I havent found any : (
>
> PS.: To see this bug, all three TuscanyMSVC8DevStudioCCompiler.jar files
> located on each project must be deleted.
>
> Adriano Crestani
>


-- 
Pete

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

Re: [Propose] A Tuscany Native release with SCA, SDO and DAS

[Pete Robbins]

good stuff. I'll check it out.

On 05/11/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I just submit the first SCA Native unit test. It's only a simple WSDL
> test, but it's a start :) This commit (svn revision 592062) includes the
> testing infrastructure and an incremental check in of the wsdl tests,
> meaning I have several more wsdl tests coming soon.  I also have some
> composite tests planned to come soon. You'll also need to get svn
> revision 592064 to be able to run the tests from the root source dir.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 05, 2007 1:34 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Propose] A Tuscany Native release with SCA, SDO and DAS
>
> Up to now we have tried to keep the distros separate so that we could,
> for example, create an SDO release without SCA. I'd like to keep it like
> this.
>
> Cheers,
>
> On 04/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > Agreed ; )
> >
> > Adriano Crestani
> >
> > On 11/2/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > >
> > > My thought is that, SCA users might not be using SDO and/or DAS and
> > > vice versa, and if they use, they might have different versions
> > > playing together (e.g SCA X with SDO Y).   This is also the same
> > > pattern we have in the Java side, where SCA, SDO and DAS are
> > > released as separate packages.
> > >
> > > So, considering flexibility, I'd suggest to continue to use the same
>
> > > pattern used on the previous Native Release [1], and have separate
> > > artifacts freleased or each Native sub-project.
> > >
> > > Thoughts ?
> > >
> > > [1]
> > > http://people.apache.org/dist/incubator/tuscany/cpp/1.0-incubator-M3
> > > /win32/
> > >
> > > On 11/1/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > Thanks everybody :D
> > > >
> > > > I'm studying right now how is the best way to distribute all the 3
> > > projects
> > > > together. I'm thinking on place all into a root directory and
> > > > merge all
> > > 3
> > > > LICENSE, NOTICE and COPYING on this root directory is enough. I
> > > > thought about a top level build.xml too:
> > > >
> > > > /LICENSE
> > > > /NOTICE
> > > > /COPYING
> > > > /build.xml
> > > > /das
> > > >   INSTALL
> > > >   README
> > > >   build.xml
> > > >   ...
> > > > /sdo
> > > >   INSTALL
> > > >   README
> > > >   build.xml
> > > >   ...
> > > > /sca
> > > >   INSTALL
> > > >   README
> > > >   build.xml
> > > >   ...
> > > >
> > > > Suggestions?
> > > >
> > > > Adriano Crestani
> > > >
> > > >
> > > > On 11/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > +1 from me as well :).  Let me know if you need help with
> anything.
> > > > >
> > > > > - Venkat
> > > > >
> > > > > On 11/1/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Brady has just closed the JIRA-1533, will you be able to add
> > > > > > some
> > > test
> > > > > > cases
> > > > > > for the next release though? Let us know if you will,
> > > > > > otherwise we
> > > > > should
> > > > > > remove the broken sca testcases before the release.
> > > > > >
> > > > > > Except that, all 3 native projects seems stable and I think we
>
> > > > > > could
> > > go
> > > > > on
> > > > > > preparing a native release. So, I'd like to volunteer for
> > > > > > release
> > > > > manager
> > > > > > of
> > > > > > Tuscany Native Release : )
> > > > > >
> > > > > > Thoughs? Suggestions?
> > > > > >
> > > > > > Adriano Crestani
&

Re: [Native] VS build versus ant build

[Pete Robbins]

On 05/11/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I can get started removing all the automake files (this will be fun
> getting rid of automake! :) ).
>
> As for the DAS and SDO samples in ant, the README_ANT_INSTALL mentions
> that the samples are the only item remaining to complete the entire ant
> build system. The samples have been added to ant for SCA, Adriano: can
> you look into completing the samples for DAS?
>
> Do you have some sort of checklist for creating a distribution? If I had
> that, I could get started adding that to the ant build system.

Not really. The distro was built on linux using "make dist" and on
windows by the builddist.bat scripts. It should be simpler with ant.
For the source distro we just need to zip up the source tree excluding
anything we don't want in the distro (e.g. the PHP extension has never
been build into a release). The binary release needs to include sample
source as well as a zip of the deployed runtime.


>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 05, 2007 2:11 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Native] VS build versus ant build
>
> I think we should be using ant for everything. The goal is to have a
> command line build and ant will give us that. We need to ensure that the
> samples can also be built/deployed using an ant script and that the
> documentation is updated to reflect this.
>
> While we are at it we should write some ant scripts to build and package
> a distribution.
>
> So, if ant build is working on all platforms we can get rid of the
> VSExpress stuff and the Automake stuff.
>
> Cheers,
>
> On 04/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > There are actually 3 build systems on native projects...make, ant and
> > VSExpress.
> >
> > - Make is completely deprecated with the addition of the new ant build
>
> > process. I think the make build system files (.sh and .bat) could
> > already be removed.
> >
> > - Ant seems to be working for all 3 projects, but DAS and SDO samples
> >
> > - VSExpress seems to be working fine for DAS and SDO, but seems to be
> > broken for SCA(at least the CppCalculator that is the only one I've
> > tested on VSExpress). VSExpress is useful for debugging and
> > development, however it uses .bat files to deploy the generated files,
>
> > adding more files to the maintenance list :s. Is there a way for
> > VSExpress to use ant to deploy its files? This way we would only need
> > to maintain the ant files. Otherwise, here is +1 to remove VSExpress
> files too.
> >
> > Thoughts? Suggestions?
> >
> > Adriano Crestani
> >
>
>
> --
> Pete
>
> -
> 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]
>
>


-- 
Pete

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

Re: RAT on Cpp trunk

[Pete Robbins]

On 05/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> I ran rat on the entire cpp trunk and got some thoughts about the results:
>
> 1-These files have no asf headers, however they have another lincense on it,
> so I don't know if the asf headers should be inserted or not:
>
> tuscany/cpp/sca/runtime/core/xsd/wsdl_11.xsd
> tuscany/cpp/sca/runtime/core/xsd/wsdl_11_http.xsd
> tuscany/cpp/sca/runtime/core/xsd/wsdl_11_mime.xsd
> tuscany/cpp/sca/runtime/core/xsd/wsdl_11_soap.xsd
> tuscany/cpp/sca/runtime/core/xsd/wsdl_11_soap12.xsd
>

These files should be left as they are. We need to add the licence
from these into the NOTICE file in our root.

> 2-There is no need to add asf header for this files, cause they have the
> same meaning as NOTICE, README, LINCENCE, etc files, right?!
>
> tuscany/cpp/sca/README_ANT_INSTALL
> tuscany/cpp/das/README_ANT_INSTALL
> tuscany/cpp/sdo/README_ANT_INSTALL
>

If these are to be included in the distribution then they need the
header. I think the info in here will go elsewhere in the
documentation.

> 3-These files are empty, could I delete them?
>
> tuscany/cpp/sca/samples/PHPCalculator/sample.calculator/runwsserver.bat
> tuscany/cpp/sca/samples/PHPCalculator/sample.calculator/sample.calculator.composite.back
> tuscany/cpp/sdo/runtime/core/src/commonj/sdo/DataObjectInstance.cpp
> tuscany/cpp/sdo/runtime/core/src/commonj/sdo/DataObjectInstance.h
>

Yes, these can be deleted.

>
> 4-These files seems to be output of some test app, so I suspect that they
> should be deleted, but I need somebody from SDO to confirm that:
>
> tuscany/cpp/sdo/runtime/core/test/querytest.txt
> tuscany/cpp/sdo/runtime/core/test/saveopen-output.txt
> tuscany/cpp/sdo/runtime/core/test/scenario1.txt
> tuscany/cpp/sdo/runtime/core/test/scenario2.txt
> tuscany/cpp/sdo/runtime/core/test/scenario3.txt
> tuscany/cpp/sdo/runtime/core/test/scenario4.txt
> tuscany/cpp/sdo/runtime/core/test/scenario5.txt
> tuscany/cpp/sdo/runtime/core/test/sequence.txt
> tuscany/cpp/sdo/runtime/core/test/setmany.txt
> tuscany/cpp/sdo/runtime/core/test/setnull.txt
> tuscany/cpp/sdo/runtime/core/test/showdefault1.txt
> tuscany/cpp/sdo/runtime/core/test/showdefault2.txt
> tuscany/cpp/sdo/runtime/core/test/simple.txt
> tuscany/cpp/sdo/runtime/core/test/stock.xml
> tuscany/cpp/sdo/runtime/core/test/stock_wsdl.txt
> tuscany/cpp/sdo/runtime/core/test/stock_xml.txt
> tuscany/cpp/sdo/runtime/core/test/testabstract.txt
> tuscany/cpp/sdo/runtime/core/test/testerrors.txt
> tuscany/cpp/sdo/runtime/core/test/testinc2.txt
> tuscany/cpp/sdo/runtime/core/test/testopen.txt
> tuscany/cpp/sdo/runtime/core/test/testorder.txt
> tuscany/cpp/sdo/runtime/core/test/teststyles.txt
> tuscany/cpp/sdo/runtime/core/test/testsubsload.txt
> tuscany/cpp/sdo/runtime/core/test/testutils.txt
> tuscany/cpp/sdo/runtime/core/test/testwsdl.txt
> tuscany/cpp/sdo/runtime/core/test/travel.txt
> tuscany/cpp/sdo/runtime/core/test/tuscany963.out.xml.txt
> tuscany/cpp/sdo/runtime/core/test/userdata.txt
> tuscany/cpp/sdo/runtime/core/test/xhtml_out.txt
> tuscany/cpp/sdo/runtime/core/test/48736_xml.txt
> tuscany/cpp/sdo/runtime/core/test/48736_xsd.txt
> tuscany/cpp/sdo/runtime/core/test/b46633.txt
> tuscany/cpp/sdo/runtime/core/test/b46634_out.txt
> tuscany/cpp/sdo/runtime/core/test/b47137.txt
> tuscany/cpp/sdo/runtime/core/test/b47137b.txt
> tuscany/cpp/sdo/runtime/core/test/b47293.txt
> tuscany/cpp/sdo/runtime/core/test/b48633_xml.txt
> tuscany/cpp/sdo/runtime/core/test/b48636_xml.txt
> tuscany/cpp/sdo/runtime/core/test/b48686_xml.txt
> tuscany/cpp/sdo/runtime/core/test/b48686_xsd.txt
> tuscany/cpp/sdo/runtime/core/test/badelement.txt
> tuscany/cpp/sdo/runtime/core/test/bothgroups_xsd.txt
> tuscany/cpp/sdo/runtime/core/test/bothgroupssamename_xsd.txt
> tuscany/cpp/sdo/runtime/core/test/bug2.txt
> tuscany/cpp/sdo/runtime/core/test/bug45933-output.txt
> tuscany/cpp/sdo/runtime/core/test/bug48300_xml.txt
> tuscany/cpp/sdo/runtime/core/test/bug48300_xsd.txt
> tuscany/cpp/sdo/runtime/core/test/bunique-out.txt
> tuscany/cpp/sdo/runtime/core/test/bunique-out.xsd_safe.txt
> tuscany/cpp/sdo/runtime/core/test/bunique-outxml.txt
> tuscany/cpp/sdo/runtime/core/test/buniqueread-out.txt
> tuscany/cpp/sdo/runtime/core/test/carotest3.txt
> tuscany/cpp/sdo/runtime/core/test/csload-output.txt
> tuscany/cpp/sdo/runtime/core/test/csload2-output.txt
> tuscany/cpp/sdo/runtime/core/test/csload3-output.txt
> tuscany/cpp/sdo/runtime/core/test/cssave-output.txt
> tuscany/cpp/sdo/runtime/core/test/cssave2-output.txt
> tuscany/cpp/sdo/runtime/core/test/datetest.txt
> tuscany/cpp/sdo/runtime/core/test/defaults.txt
> tuscany/cpp/sdo/runtime/core/test/doctest.txt
> tuscany/cpp/sdo/runtime/core/test/openloadNSout.txt
> tuscany/cpp/sdo/runtime/core/test/openseq.txt
> tuscany/cpp/sdo/runtime/core/test/order1.txt
> tuscany/cpp/sdo/runtime/core/test/order2.txt
> tuscany/cpp/sdo/runtime/core/test/notns.txt
> tuscany/cpp/sdo/runtime/core/test/nulltest.txt
> tuscany/cpp/sdo/runtime/core/test/oddchars.txt
> t

Re: [Native] VS build versus ant build

[Pete Robbins]

I think we should be using ant for everything. The goal is to have a
command line build and ant will give us that. We need to ensure that
the samples can also be built/deployed using an ant script and that
the documentation is updated to reflect this.

While we are at it we should write some ant scripts to build and
package a distribution.

So, if ant build is working on all platforms we can get rid of the
VSExpress stuff and the Automake stuff.

Cheers,

On 04/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> There are actually 3 build systems on native projects...make, ant and
> VSExpress.
>
> - Make is completely deprecated with the addition of the new ant build
> process. I think the make build system files (.sh and .bat) could already be
> removed.
>
> - Ant seems to be working for all 3 projects, but DAS and SDO samples
>
> - VSExpress seems to be working fine for DAS and SDO, but seems to be broken
> for SCA(at least the CppCalculator that is the only one I've tested on
> VSExpress). VSExpress is useful for debugging and development, however it
> uses .bat files to deploy the generated files, adding more files to the
> maintenance list :s. Is there a way for VSExpress to use ant to deploy its
> files? This way we would only need to maintain the ant files. Otherwise,
> here is +1 to remove VSExpress files too.
>
> Thoughts? Suggestions?
>
> Adriano Crestani
>


-- 
Pete

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

Re: [SDO C++] AccessViolation in XMLHelperImpl

[Pete Robbins]

Thanks for that. I'll fix it right away.

On 02/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote:
> A user has found a vulnerability in XMLHelperImpl::createDocument, the
> one with the const char * parameters. The problem being that the root
> element name is initialized with the parameter >before< the code which
> checks for the parameter being null. I'll add a guard for this in the
> PHP code, but really it should be fixed in Tuscany. Could someone apply
> this patch, please:
>
> Index:
> C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
> ===
> ---
> C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
> (revision 568508)
> +++
> C:/dev/tuscany_sdo_pre2.1/sdo-cpp-pre2.1/runtime/core/src/commonj/sdo/XMLHelperImpl.cpp
> (working copy)
> @@ -172,7 +172,7 @@
>  const char* rootElementName)
>  {
>SDOString uri;
> -   SDOString name = rootElementName;
> +   SDOString name;
>if (0 == rootElementURI)
>  uri = "";
>  else
>
> The patch was created against the branch, but the same code exists in
> the trunk.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [Propose] A Tuscany Native release with SCA, SDO and DAS

[Pete Robbins]

Up to now we have tried to keep the distros separate so that we could,
for example, create an SDO release without SCA. I'd like to keep it
like this.

Cheers,

On 04/11/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> Agreed ; )
>
> Adriano Crestani
>
> On 11/2/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > My thought is that, SCA users might not be using SDO and/or DAS and
> > vice versa, and if they use, they might have different versions
> > playing together (e.g SCA X with SDO Y).   This is also the same
> > pattern we have in the Java side, where SCA, SDO and DAS are released
> > as separate packages.
> >
> > So, considering flexibility, I'd suggest to continue to use the same
> > pattern used on the previous Native Release [1], and have separate
> > artifacts freleased or each Native sub-project.
> >
> > Thoughts ?
> >
> > [1]
> > http://people.apache.org/dist/incubator/tuscany/cpp/1.0-incubator-M3/win32/
> >
> > On 11/1/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > Thanks everybody :D
> > >
> > > I'm studying right now how is the best way to distribute all the 3
> > projects
> > > together. I'm thinking on place all into a root directory and merge all
> > 3
> > > LICENSE, NOTICE and COPYING on this root directory is enough. I thought
> > > about a top level build.xml too:
> > >
> > > /LICENSE
> > > /NOTICE
> > > /COPYING
> > > /build.xml
> > > /das
> > >   INSTALL
> > >   README
> > >   build.xml
> > >   ...
> > > /sdo
> > >   INSTALL
> > >   README
> > >   build.xml
> > >   ...
> > > /sca
> > >   INSTALL
> > >   README
> > >   build.xml
> > >   ...
> > >
> > > Suggestions?
> > >
> > > Adriano Crestani
> > >
> > >
> > > On 11/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > > >
> > > > +1 from me as well :).  Let me know if you need help with anything.
> > > >
> > > > - Venkat
> > > >
> > > > On 11/1/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Brady has just closed the JIRA-1533, will you be able to add some
> > test
> > > > > cases
> > > > > for the next release though? Let us know if you will, otherwise we
> > > > should
> > > > > remove the broken sca testcases before the release.
> > > > >
> > > > > Except that, all 3 native projects seems stable and I think we could
> > go
> > > > on
> > > > > preparing a native release. So, I'd like to volunteer for release
> > > > manager
> > > > > of
> > > > > Tuscany Native Release : )
> > > > >
> > > > > Thoughs? Suggestions?
> > > > >
> > > > > Adriano Crestani
> > > > >
> > > > > On 10/24/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Adriano,
> > > > > >
> > > > > > I think CPP-M4 is just fine.
> > > > > >
> > > > > > I started a Next Release Contents WIKI page [1] sometime back for
> > this
> > > > > > exact purpose.
> > > > > >
> > > > > > Maybe we could Add the SDO and DAS items here.
> > > > > >
> > > > > > The items listed for SCA are rather extensive and should possibly
> > be
> > > > > > reduced unless we can get some additional help.
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R
> > > > > > elease+Contents
> > > > > >
> > > > > >
> > > > > > 
> > > > > > Brady Johnson
> > > > > > Lead Software Developer - HydraSCA
> > > > > > Rogue Wave Software - [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > On
> > > > > > Behalf Of Adriano Crestani
> > > > > > Sent: Wednesday, October 24, 2007 12:19 AM
> > > > > > To: tuscany-dev@ws.apache.org
> > > > > > Subject: Re: [Propose] A Tuscany Native release with SCA, SDO and
> > DAS
> > > > > >
> > > > > > Cool,
> > > > > >
> > > > > > So I created a new release on JIRA: Cpp-M4( not sure if it's the
> > best
> > > > > > name, suggestions? ). We could start to set the JIRAs that are
> > > > supposed
> > > > > > to be fixed before this release to Cpp-M4 and leave the others to
> > > > > > Cpp-next.
> > > > > >
> > > > > > Suggestions?
> > > > > >
> > > > > > Adriano Crestani
> > > > > >
> > > > > > On 10/23/07, Simon Nash < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > +1 for this.
> > > > > > >
> > > > > > >Simon
> > > > > > >
> > > > > > > ant elder wrote:
> > > > > > >
> > > > > > > > That would be really good. I'm can't help so much with coding
> > but
> > > > > > > > i'd be happy to help out in any other way.
> > > > > > > >
> > > > > > > >...ant
> > > > > > > >
> > > > > > > > On 10/23/07, Adriano Crestani <[EMAIL PROTECTED] >
> > wrote:
> > > > > > > >
> > > > > > > >>Hi,
> > > > > > > >>
> > > > > > > >>How about a Tuscany Native release with all native projects:
> > SCA,
> > > > > > > >>SDO
> > > > > > > and
> > > > > > > >>DAS?
> > > > > > > >>
> > > > > > > >>The 3 projects have an Apache Ant build system that is a good
> > > > poi

[NOTICE] Michael Yoder voted as Tuscany committer

[Pete Robbins]

The Tuscany PPMC and Incubator PMC have voted for Michael to become a
Tuscany committer.

Congratulations and welcome!

I look forward to your continued excellent contributions to Tuscany.

Cheers,

-- 
Pete

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

Re: [SCA Native] next release content [was: Tuscany roadmap]

[Pete Robbins]

My comment was based on what Sam Ruby told us last time we went round
this loop. Unfortunately my trawl through mail archives can't find
anything. I'm no legal expert.

I believe using cxxtest would be OK but we need to check before using it.

Cheers,

On 23/10/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> Oh, sorry Simon, my mistake, it was really Pete who said it ; )
>
> Adriano Crestani
>
> On 10/23/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> >
> > Adriano Crestani wrote:
> >
> > > Hi Haleh,
> > >
> > > This way we would be using the Cxxtest api, and according to Simon it's
> > > considered derived work, so we couldn't distribute it, right Simon?
> > >
> > This comment came from Pete, not from me.  I'm not familiar with the
> > stdcxx license so I'll defer to Pete to explain why it's a concern.
> >
> >Simon
> >
> > > Adriano Crestani
> > >
> > > On 10/23/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> > >
> > >>But if you go with what Simon suggested, you leave the tests and test
> > tool
> > >>outside of distribution. Wouldn't that work?
> > >>
> > >>On 10/23/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> > >>
> > >>>I think this is one for the legal discuss list. This has been
> > >>>discussed before and I think the conclusion was that because you code
> > >>>to the cxxtest apis to write your test code it could be considered a
> > >>>derivative work.
> > >>>
> > >>>So, does it mean we cannot distribute a code using a api that we cannot
> > >>>distribute? Then we should start looking for another unit test. I was
> > >>>looking on the web site I commented before, most of them are GPL : (,
> > >>
> > >>but
> > >>
> > >>>I
> > >>>found this 2:
> > >>>
> > >>>http://unittest-cpp.sourceforge.net/
> > >>>http://tut-framework.sourceforge.net/
> > >>>
> > >>>Their license seems to have almost no restriction, but I cannot tell
> > for
> > >>>sure if they are compatible with ASF license.
> > >>>
> > >>>Regards,
> > >>>Adriano Crestani
> > >>>
> > >>>On 10/23/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >>>
> > >>>>I think this is one for the legal discuss list. This has been
> > >>>>discussed before and I think the conclusion was that because you code
> > >>>>to the cxxtest apis to write your test code it could be considered a
> > >>>>derivative work.
> > >>>>
> > >>>>Cheers,
> > >>>>
> > >>>>On 23/10/2007, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >>>>
> > >>>>>I think it's fine to distribute unit test source and tell people
> > >>
> > >>what
> > >>
> > >>>>>tool they need to build and run the tests.  And I agree that having
> > >>
> > >>a
> > >>
> > >>>>>list of suitable unit test tools on the Web site is helpful.
> > >>>>>
> > >>>>>  Simon
> > >>>>>
> > >>>>>Adriano Crestani wrote:
> > >>>>>
> > >>>>>
> > >>>>>>Hi Simon,
> > >>>>>>
> > >>>>>>Yes, you are right, I forgot this option, there is no problem to
> > >>>>
> > >>>>distribute
> > >>>>
> > >>>>>>the unit test source code :P. But anyway, the list contained on
> > >>
> > >>the
> > >>
> > >>>>web site
> > >>>>
> > >>>>>>I could be helpful :)
> > >>>>>>
> > >>>>>>Regards,
> > >>>>>>Adriano Crestani
> > >>>>>>
> > >>>>>>On 10/22/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>>Why does the test tool need to be distributed with a Tuscany
> > >>>
> > >>>release?
> > >>>
> > >>>>>>>If the build d

Re: [SCA Native] next release content [was: Tuscany roadmap]

[Pete Robbins]

I think this is one for the legal discuss list. This has been
discussed before and I think the conclusion was that because you code
to the cxxtest apis to write your test code it could be considered a
derivative work.

Cheers,

On 23/10/2007, Simon Nash <[EMAIL PROTECTED]> wrote:
> I think it's fine to distribute unit test source and tell people what
> tool they need to build and run the tests.  And I agree that having a
> list of suitable unit test tools on the Web site is helpful.
>
>   Simon
>
> Adriano Crestani wrote:
>
> > Hi Simon,
> >
> > Yes, you are right, I forgot this option, there is no problem to distribute
> > the unit test source code :P. But anyway, the list contained on the web site
> > I could be helpful :)
> >
> > Regards,
> > Adriano Crestani
> >
> > On 10/22/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >
> >>Why does the test tool need to be distributed with a Tuscany release?
> >>If the build depends on having the tool available, then I can see some
> >>justification for this, but even then it would be possible for people
> >>who build the source to download the tool separately.
> >>
> >>   Simon
> >>
> >>Adriano Crestani wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>Brady suggested to use CxxTest only on development process and don't
> >>>distribute it with the released source. However, whoever wants to modify
> >>
> >>the
> >>
> >>>code from a release would want to test it, to check if the modifications
> >>>does not compromise the software. So, I suggest to look for another text
> >>>unit tool that could be distributed with the released source. I really
> >>
> >>dont
> >>
> >>>know any other, but searching on web I found a list of open source C/C++
> >>>unit test tools on [1].
> >>>
> >>>[1] http://www.opensourcetesting.org/unit_c.php
> >>>
> >>>Regards,
> >>>Adriano Crestani
> >>>
> >>>On 8/10/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>>Good idea, I always prefer to see plenty of documentation. I updated the
> >>>>wiki with a documentation feature.
> >>>>
> >>>>http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R
> >>>>elease+Contents
> >>>>
> >>>>What sort of help do you think I'll have with these features?
> >>>>
> >>>>
> >>>>Brady Johnson
> >>>>Lead Software Developer - HydraSCA
> >>>>Rogue Wave Software - [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>-Original Message-
> >>>>From: haleh mahbod [mailto:[EMAIL PROTECTED]
> >>>>Sent: Friday, August 10, 2007 3:36 PM
> >>>>To: tuscany-dev@ws.apache.org
> >>>>Subject: Re: [SCA Native] next release content [was: Tuscany roadmap]
> >>>>
> >>>>How about enhancing the documentation (architecture, get started and
> >>>>user
> >>>>doc) to help new people come on board faster?
> >>>>
> >>>>Another thought might be to have an integration story between Native and
> >>>>Java. Some of this work started for OSCon, for example a sample of a
> >>>>composite which include C++ and Java components.
> >>>>
> >>>>
> >>>>On 7/26/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>
> >>>>>That looks good. I think there is more than enough in that list to
> >>>>>justify a release. My priorities would be:
> >>>>>1) upgrade to the sca 1.0 spec levels (assembly and cpp).
> >>>>>2) build system move to ant
> >>>>>(enough there for a release)
> >>>>>
> >>>>>We should discuss your ideas for the rearchitecture of the data model.
> >>>>>It sounds like a good idea so maybe we can flesh out a proposal for
> >>>>>that.
> >>>>>
> >>>>>Cheers,
> >>>>>
> >>>>>On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>
> >>>>>>Hello all,
> >>>>>>
> >>>>>>I created a wiki page detailing the TuscanySCA Native Next Release

Re: [VOTE] Graduate Tuscany as a top level project

[Pete Robbins]

+1

On 09/10/2007, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> +1 ; )
>
> Adriano Crestani
>
> On 10/9/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >
> > +1
> >
> > On 10/9/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> > > Ant, thanks for starting the thread. +1 from me.
> > >
> > > - Amita
> > >
> > > On 10/9/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 10/9/07, Radim Kolarik <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > +1 from me.
> > > > >
> > > > > Radim
> > > > >
> > > > > On 10/9/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > > > Looks like we've closed all the discussions around this so we can
> > now
> > > > > vote
> > > > > > on it. We've an Incubator discussion thread on our graduation but
> > I
> > > > > don't
> > > > > > see why we can't let that run in parallel, so ...
> > > > > >
> > > > > > Please vote on graduating Tuscany as a top level project and the
> > > > > proposal
> > > > > > below.
> > > > > >
> > > > > > Heres my +1.
> > > > > >
> > > > > >...ant
> > > > > >
> > > > > >   WHEREAS, the Board of Directors deems it to be in the best
> > > > > >interests of the Foundation and consistent with the
> > > > Foundation's
> > > > > >purpose to establish a Project Management Committee charged
> > > > with
> > > > > >the creation and maintenance of open-source software that
> > > > > >simplifies the development and deployment of service
> > oriented
> > > > > >applications and provides a managed service-oriented
> > runtime
> > > > > >based on the standards defined by the OASIS OpenCSA group,
> > > > > >for distribution at no charge to the public.
> > > > > >
> > > > > >   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > > > > >Committee (PMC), to be known as the "Apache Tuscany
> > Project",
> > > > > >be and hereby is established pursuant to Bylaws of the
> > > > > >Foundation; and be it further
> > > > > >
> > > > > >   RESOLVED, that the Apache Tuscany Project be and hereby is
> > > > > >responsible for the creation and maintenance of software
> > > > > >related to Apache Tuscany;
> > > > > >and be it further
> > > > > >
> > > > > >   RESOLVED, that the office of "Vice President, Apache
> > Tuscany" be
> > > > > >and hereby is created, the person holding such office to
> > > > > >serve at the direction of the Board of Directors as the
> > chair
> > > > > >of the Apache Tuscany Project, and to have primary
> > > > responsibility
> > > > > >    for management of the projects within the scope of
> > > > > >responsibility of the Apache Tuscany Project; and be it
> > further
> > > > > >
> > > > > >   RESOLVED, that the persons listed immediately below be and
> > > > > >hereby are appointed to serve as the initial members of the
> > > > > >Apache Tuscany Project:
> > > > > >
> > > > > >Adriano Crestani > dot
> > > > > org>
> > > > > >Andrew Borley> org>
> > > > > >Andy Grove   
> > > > > >ant elder> > > org>
> > > > > >Brady Johnson  
> > > > > >Frank Budinsky 
> > > > > >Ignacio Silva-Lepe  
> > > > > >Jean-Sebastien Delfino   
> > > > > >kelvin goodson> dot
> > > > > org>
> > > > > >Luciano Resende   
> > > > > >Mike Edwards&

Re: [SCA Native] Does the Operation class duplicate the SDO

[Pete Robbins]

Yes I agree that an SDO could manage the memory better. However the
C++ (and Java) spec state:

"The data exchange semantics for calls to local services is
by-reference.  This means that code must be written with the knowledge
that changes made to parameters (other than simple types) by either
the client or the provider of the service can be seen by the other."

We were catering for this in C++ in the proxy/wrapper by passing
pointers to the actual parameters used. I suppose the same could be
achieved by copying the parameters from the SDO back into the callers
parameters on return from the service call. We were probably trying to
avoid copying parameters multiple times per service call.

Cheers,

On 27/09/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Every SDO parameter ultimately boils down to one of the basic types
> (int, bool, char, etc) and SDO manages the memory for those basic types
> internally. So if you do a DataObjectPtr::setBoolean( xpath, bool ),
> you'll be passing in the value with "pass by value" semantics, but the
> SDO takes care of copying the value and managing the memory for the
> bool.
>
> I don't think the memory will be an issue if we use SDO here instead of
> the Operation class. It seems odd to me to have to allocate the basic
> types with new and pass in the pointer to the Operation class setters.
> Besides the fact that I don't think those new'ed parameter values ever
> get deleted (big memory leak). Once the SDO RefCountingPointer detects
> that no one else is using the SDO, it will take care of releasing the
> memory itself.
>
> As for the return values: That will be an SDO as well. The Service
> implementation will make the appropriate set calls on the return SDO,
> which the Tuscany runtime will be able to query. And again, when the no
> one else is referencing the SDO, the memory will be released.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 27, 2007 2:50 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] Does the Operation class duplicate the SDO
>
> I would imagine we can map the contents of the Operation into an SDO.
> Would this cope with "pass by reference" semantics? Would we be storing
> copies of the parameters in the SDO or pointers to them as is the case
> now with the Operation class? If so do we still get the same memory
> management problems as today?
>
> It seems a long time ago since we came up with the Operation class. I
> recall the interesting problems were around parameters and return values
> that are pointers or references ... and who allocates/frees the memory.
> Can we optimise this for local calls (pass by reference) or do we always
> pass by value?
>
> This area certainly needs a fresh brain to look at it ;-)
>
> Cheers,
>
>
> On 27/09/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I've been looking at how the Operation class works and have been
> > considering refactoring it since it has some memory leaks and should
> > use STL templates, and I came to the realization that its duplicating
> > a lot of what SDO does. The Operation class seems to serve 2 purposes:
> >- Store the Operation Name
> >- Store the Operation Parameters
> >
> > All of the Operation setReturnValue(), addParameter(), and
> > getParameter() methods are duplicating what an SDO DataObject does, so
>
> > why not just use an SDO? The method signatures that use the Operation
> > class can be changed to take a std::string for the operationName and
> > to take a DataObjectPtr for the parameters. The DataObjectPtr can
> > contain a DataObjectPtr child for each WSDL message part.
> > Additionally, I suggest adding a 3rd argument, which would be the
> > output message, so the resulting ServiceWrapper::invoke() signature
> would look like this:
> >
> >void ServiceWrapper::invoke( const std::string &operationName,
> > DataObjectPtr input, DataObjectPtr output );
> >
> > If we take this approach, the affected areas will be the samples
> > (anywhere a ServiceWrapper is used) and scagen.
> >
> > Any opinions?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
>
>
> --
> Pete
>
> -
> 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]
>
>


-- 
Pete

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

Re: [SCA Native] Does the Operation class duplicate the SDO

[Pete Robbins]

I would imagine we can map the contents of the Operation into an SDO.
Would this cope with "pass by reference" semantics? Would we be
storing copies of the parameters in the SDO or pointers to them as is
the case now with the Operation class? If so do we still get the same
memory management problems as today?

It seems a long time ago since we came up with the Operation class. I
recall the interesting problems were around parameters and return
values that are pointers or references ... and who allocates/frees the
memory. Can we optimise this for local calls (pass by reference) or do
we always pass by value?

This area certainly needs a fresh brain to look at it ;-)

Cheers,


On 27/09/2007, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I've been looking at how the Operation class works and have been
> considering refactoring it since it has some memory leaks and should use
> STL templates, and I came to the realization that its duplicating a lot
> of what SDO does. The Operation class seems to serve 2 purposes:
>- Store the Operation Name
>- Store the Operation Parameters
>
> All of the Operation setReturnValue(), addParameter(), and
> getParameter() methods are duplicating what an SDO DataObject does, so
> why not just use an SDO? The method signatures that use the Operation
> class can be changed to take a std::string for the operationName and to
> take a DataObjectPtr for the parameters. The DataObjectPtr can contain a
> DataObjectPtr child for each WSDL message part. Additionally, I suggest
> adding a 3rd argument, which would be the output message, so the
> resulting ServiceWrapper::invoke() signature would look like this:
>
>void ServiceWrapper::invoke( const std::string &operationName,
> DataObjectPtr input, DataObjectPtr output );
>
> If we take this approach, the affected areas will be the samples
> (anywhere a ServiceWrapper is used) and scagen.
>
> Any opinions?
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>


-- 
Pete

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

[jira] Closed: (TUSCANY-1509) Change TuscanySDO Native build system to use ant

[Pete Robbins (JIRA)]

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

Pete Robbins closed TUSCANY-1509.
-

Resolution: Fixed

New Jiras will be raised fr any outstanding problems

> Change TuscanySDO Native build system to use ant
> 
>
> Key: TUSCANY-1509
> URL: https://issues.apache.org/jira/browse/TUSCANY-1509
> Project: Tuscany
>  Issue Type: Improvement
>  Components: C++ SDO
>Affects Versions: Cpp-M3
> Environment: All platforms
>Reporter: Brady Johnson
> Fix For: Cpp-Next
>
> Attachments: build.xml, README_ANT_INSTALL.txt, 
> tuscany_patch_update1_jira1509, tuscanySDONative_ant.jar
>
>
> In an effort to simplify the build process, I would like to propose switching 
> over to use ant instead of automake. It will be much easier to maintain, and 
> is used by many more developers today than automake.
> I have already converted most of TuscanySCA to ant. I based this SDO build 
> system on the SCA build system.
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
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] Closed: (TUSCANY-1529) Tuscany SDO native for windows is not msvc backwards compatible

[Pete Robbins (JIRA)]

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

Pete Robbins closed TUSCANY-1529.
-

Resolution: Fixed

> Tuscany SDO native for windows is not msvc backwards compatible 
> 
>
> Key: TUSCANY-1529
> URL: https://issues.apache.org/jira/browse/TUSCANY-1529
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
> Environment: MSVC 8.0 and 7.1
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
> Attachments: tuscany_patch_jira1529
>
>
> I've been trying to compile Tuscany on platforms other than VSExpress (which 
> is msvc 8.0) and Linux. 
> I came across something that doesn't compile on msvc7.1 in SDODate.cpp. The 
> problem is the definition
> of localtime for windows. Its #define'd  as localtime_s for windows. A simple 
> check for compiler version
> would allow it to be defined for msvc 8.0 and anything previous, as follows:
> #ifndef tuscany_localtime_r
> #if defined(WIN32)  || defined (_WINDOWS)
>   #if _MSC_VER < 1400 // _MSC_VER: 1400 is msvc 8.0, so anything less is pre 
> 8.0
> #define tuscany_localtime_r(value, ignore) localtime(&value);
>   #else
> #define tuscany_localtime_r(value, tmp_tm) localtime_s(&tmp_tm, &value);
>   #endif
> #else
>   #define tuscany_localtime_r(value, tmp_tm) localtime_r(&value, &tmp_tm);
> #endif
> #endif // tuscany_localtime_r
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
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: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API

[Pete Robbins]

Patch applied.

One thing we need to do is update the NOTICE file to include the
licence from the wsdl schema files.

Cheers,

On 30/08/2007, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I uploaded an addendum patch to TUSCANY-1375. If someone could review
> and apply it that would be great.
>
> Thanks,
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 29, 2007 6:33 PM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++
> type definition API
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1375:
> ---
>
>Attachment: import.txt
>
> This patch updates the wsdl binding schemas import adding a
> schemaLocation attribute. This was required for the schemas to be valid.
>
> > C++ SDO spec portability: C++ type definition API
> > -
> >
> > Key: TUSCANY-1375
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1375
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: API issue - all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: import.txt, TUSCANY-1375.txt
> >
> >
> > The Tuscany C++ SDO implementation has off-spec type definition
> classes which are used by SCA. These should be removed or used only
> internally by the implementation until or unless they can be
> incorporated into the specification.
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 8:45 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: C++ SDO spec portability: C++ type definition API Hi,
> > C++ Tuscany SDO extends type definition API with the off-spec classes
> PropertyDefinition and TypeDefinition, which are used externally by SCA.
>
> > We also have found the C++ SDO specification type definition API
> > lacking, and have added the Impl member function
> > DataFactoryImpl::define(DataObjectPtr)
> > to parallel the Java type definition API using DataObject's of Types
> commonj.sdo#Type and commonj.sdo#Property.
> > Should a Jira be raised for these classes to be removed or kept
> internal to Tuscany C++ SDO? Is there API here that it would be good to
> present to the comittee?
> > Thanks,
> > Michael Yoder
> > Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
>
> --
> 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]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath

[Pete Robbins]

Thanks for that. I applied 1372 and 1442 (with minor change) earlier today.

Cheers,

On 29/08/2007, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> I resolved these jiras:
>
> TUSCANY-1366 - C++ SDO spec portability: SDORuntimeException off-spec
> member functions
> TUSCANY-1368 - C++ SDO portability: class interface Type off-spec enum
> values
> TUSCANY-1370 - C++ SDO spec compliance/portability: DataObject
> TUSCANY-1371 - C++ SDO spec compliance/portability:
> DataObject::getInstanceProperty(const std::string& prop)
> TUSCANY-1374 - C++ SDO spec portability: DataObjectInstance
> TUSCANY-1375 - C++ SDO spec portability: C++ type definition API
> TUSCANY-1376 - C++ SDO spec portability: RefCountingPointer
>
> For the others:
> 1372 and 1442 have patches pending I believe, and I think 1548 will
> require me to add another patch with additional testing
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 29, 2007 3:13 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties
> should require indexed xpath
>
> Patch applied. Can you resolve/close the Jiras if the work is now
> complete on them?
>
> Cheers,
>
> On 28/08/2007, Michael Yoder <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I have uploaded a patch for TUSCANY-1548. If someone could review and
> > apply it that would be great.
> >
> > Thanks,
> >
> > Michael
> > Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
> >
> > -Original Message-
> > From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 28, 2007 9:52 AM
> > To: Michael Yoder
> > Subject: [jira] Updated: (TUSCANY-1548) multi-valued properties should
>
> > require indexed xpath
> >
> >
> > [
> > https://issues.apache.org/jira/browse/TUSCANY-1548?page=com.atlassian.
> > ji ra.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Michael Yoder updated TUSCANY-1548:
> > ---
> >
> >Attachment: TUSCANY-1548.txt
> >
> > This patch enforces the requirement that multi-valued properties need
> > an index in an xpath for access, and must  be added with  getList().
> >
> > > multi-valued properties should require indexed xpath
> > > 
> > >
> > > Key: TUSCANY-1548
> > > URL:
> > https://issues.apache.org/jira/browse/TUSCANY-1548
> > > Project: Tuscany
> > >  Issue Type: Bug
> > >  Components: C++ SDO
> > >Affects Versions: Cpp-M3
> > > Environment: all
> > >Reporter: Michael Yoder
> > > Fix For: Cpp-Next
> > >
> > > Attachments: TUSCANY-1548.txt
> > >
> > >
> > > The C++ SDO spec XPath clearly shows access to many-valued
> > > properties
> > requiring [] or dot notation to denote an index. In order to retreive
> > a whole list the SDO spec uses the getList() API to retrieve a list.
> > > 6.1.13. The get/set API on Class DataObject ...
> > > Multi-valued properties are located by the getList API.
> > > Multi-valued properties accessed in an xpath without an index should
> > be invalid usage (Tuscany SDO is currently accesses the first element
> > in the list).
> >
> > --
> > 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]
> >
> >
>
>
> --
> Pete
>
> -
> 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]
>
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1548) multi-valued properties should require indexed xpath

[Pete Robbins]

Patch applied. Can you resolve/close the Jiras if the work is now
complete on them?

Cheers,

On 28/08/2007, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have uploaded a patch for TUSCANY-1548. If someone could review and
> apply it that would be great.
>
> Thanks,
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 28, 2007 9:52 AM
> To: Michael Yoder
> Subject: [jira] Updated: (TUSCANY-1548) multi-valued properties should
> require indexed xpath
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1548?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1548:
> ---
>
>Attachment: TUSCANY-1548.txt
>
> This patch enforces the requirement that multi-valued properties need an
> index in an xpath for access, and must  be added with  getList().
>
> > multi-valued properties should require indexed xpath
> > 
> >
> > Key: TUSCANY-1548
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1548
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO
> >Affects Versions: Cpp-M3
> > Environment: all
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1548.txt
> >
> >
> > The C++ SDO spec XPath clearly shows access to many-valued properties
> requiring [] or dot notation to denote an index. In order to retreive a
> whole list the SDO spec uses the getList() API to retrieve a list.
> > 6.1.13. The get/set API on Class DataObject ...
> > Multi-valued properties are located by the getList API.
> > Multi-valued properties accessed in an xpath without an index should
> be invalid usage (Tuscany SDO is currently accesses the first element in
> the list).
>
> --
> 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]
>
>


-- 
Pete

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

Re: [jira] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject

[Pete Robbins]

I applied v2 and then v2_b

Cheers,

On 28/08/2007, Michael Yoder (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
>
> Michael Yoder updated TUSCANY-1370:
> ---
>
>Attachment: TUSCANY-1370v2_b.txt
>
> The v2 patch left out treatment of the objectToXPath member function. This 
> patch takes care of the omission.
>
> > C++ SDO spec compliance/portability: DataObject
> > ---
> >
> > Key: TUSCANY-1370
> > URL: https://issues.apache.org/jira/browse/TUSCANY-1370
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: API issues -- all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1370.txt, TUSCANY-1370v2.txt, 
> > TUSCANY-1370v2_b.txt
> >
> >
> > The specification interface DataObject.h exposes off-spec member functions, 
> > these should be made internal to the implementation.
> >
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 6:34 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: C++ SDO spec compliance/portability: DataObject
> > Hi,
> > In the DataObject interface, these member functions are exposed which 
> > aren't in the C++ 2.1 spec:
> > virtual SDO_API bool hasProperty(const char* name) = 0;
> > virtual SDO_API bool hasProperty(const SDOString& name) = 0;
> > virtual SDO_API DataFactory* getDataFactory() = 0;
> > virtual SDO_API void setUserData(const char* path,void* value) = 0;
> > virtual SDO_API void setUserData(const SDOString& path, void* value) = 
> > 0;
> > virtual SDO_API void setUserData(unsigned int propertyIndex, void* 
> > value) = 0;
> > virtual SDO_API void setUserData(const Property& property, void* value) 
> > = 0;
> > virtual SDO_API void setUserData(void* value) = 0;
> > virtual SDO_API void* getUserData(const char* path) = 0;
> > virtual SDO_API void* getUserData(const SDOString& path) = 0;
> > virtual SDO_API void* getUserData(unsigned int propertyIndex) = 0;
> > virtual SDO_API void* getUserData(const Property& property) = 0;
> > virtual SDO_API void* getUserData() = 0;
> > virtual SDO_SPI const char* objectToXPath() = 0;
> > Would it be appropriate to file a Jira/patch to have these removed from the 
> > spec interface? Or alternatively a Jira to submit them to the spec 
> > committee?
> > Thanks,
> > Michael Yoder
> > Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO
>
> --
> 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]
>
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject

[Pete Robbins]

Hi,

I have applied 1368 and 1374. This patch gets conflicts with the
patches I've applied. They looked reasonably straight forward to
resolve but I must have done something wrong as the sdo tests crash
:-(

Could you do an extract from HEAD and create a new patch for this Jira?

Cheers,

On 25/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I uploaded a patch for TUSCANY-1370. If someone could review and apply
> it that would be great.
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 24, 2007 5:22 PM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1370) C++ SDO spec
> compliance/portability: DataObject
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1370:
> ---
>
>Attachment: TUSCANY-1370.txt
>
> This patch removes off-spec member functions from the DataObject
> interface.
>
>
> > C++ SDO spec compliance/portability: DataObject
> > ---
> >
> > Key: TUSCANY-1370
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1370
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: API issues -- all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1370.txt
> >
> >
> > The specification interface DataObject.h exposes off-spec member
> functions, these should be made internal to the implementation.
> >
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 6:34 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: C++ SDO spec compliance/portability: DataObject Hi, In the
> > DataObject interface, these member functions are exposed which aren't
> in the C++ 2.1 spec:
> > virtual SDO_API bool hasProperty(const char* name) = 0;
> > virtual SDO_API bool hasProperty(const SDOString& name) = 0;
> > virtual SDO_API DataFactory* getDataFactory() = 0;
> > virtual SDO_API void setUserData(const char* path,void* value) =
> 0;
> > virtual SDO_API void setUserData(const SDOString& path, void*
> value) = 0;
> > virtual SDO_API void setUserData(unsigned int propertyIndex, void*
> value) = 0;
> > virtual SDO_API void setUserData(const Property& property, void*
> value) = 0;
> > virtual SDO_API void setUserData(void* value) = 0;
> > virtual SDO_API void* getUserData(const char* path) = 0;
> > virtual SDO_API void* getUserData(const SDOString& path) = 0;
> > virtual SDO_API void* getUserData(unsigned int propertyIndex) = 0;
> > virtual SDO_API void* getUserData(const Property& property) = 0;
> > virtual SDO_API void* getUserData() = 0;
> > virtual SDO_SPI const char* objectToXPath() = 0; Would it be
> > appropriate to file a Jira/patch to have these removed from the spec
> interface? Or alternatively a Jira to submit them to the spec committee?
> > Thanks,
> > Michael Yoder
> > Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
>
> --
> 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]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class interface Type off-spec enum values

[Pete Robbins]

Michael, I'm looking at this and have a question.

I'm a little confused with the Int/IInteger/BigDecimal/Decimal changes.
For instance, I see we would no longer define a type
"commonj.sdo#BigDecimal" as this would be "commonj.sdo#Decimal" ? In
the spec I have BigDecimal is still mentioned (actually as I type this
I come to the conclusion that the spec is incosistent and the
references to the SDO Abstract Type BigDecimal should probably not be
there.).

We do still have commonj.sdo#Integer as an SDO Type ... but there is
no Type enum returned for this So if I create one I can't
determine it's type using getTypeEnum??? Seems odd.

Cheers,




On 24/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I updated a patch for TUSCANY-1368. If someone could review and apply it
> that would be great.
>
> Thanks,
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 24, 2007 2:50 PM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1368) C++ SDO portability: class
> interface Type off-spec enum values
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1368?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1368:
> ---
>
>Attachment: TUSCANY-1368.txt
>
> This patch updates the Type.h interface to be spec compliant. Enum
> values and public members not in the spec are removed from the
> interface. Also related/ripple 2.1 spec changes:
> - commonj.sdo#Int type added to factory (maps to enum Types::IntType)
> - commonj.sdo#BigInteger type rennamed commonj.sdo#Integer (maps to enum
> Types::BigInteger)
> - commonj.sdo#BigDecimal type renamed commonj.sdo#Decimal (maps to enum
> Types::BigDecimal)
> - set/getInteger accessors renamed to set/getInt (map to commonj.sdo#Int
> and xsd:int)
>
>
>
> > C++ SDO portability: class interface Type off-spec enum values
> > --
> >
> > Key: TUSCANY-1368
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1368
> > Project: Tuscany
> >  Issue Type: Improvement
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1368.txt
> >
> >
> > C++ SDO specification class interface Type has enum values
> ("OpenDataObjectType", "num_type")which are not in the specification,
> and are being used externally by SCA. It would seem that for SDO
> portability these should be taken internal to SDO or submitted to the
> spec committee.
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 21, 2007 9:21 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: SDO spec compliance/portability: Type enums the num_type
> > is just a convenient way to know the extent of an enum and is common
> practice. I guess the OpenDataObjectType must be a Tuscany specific
> extension to handle open types. I'd need to do some research to
> determine if this is missing from the spec or can be removed.
> > Please raise a Jira for the renaming of IntegerType.
> > It may be useful to raise Jiras for all these issues so we can track
> them.
> > Cheers,
> > On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > The Tuscany SDO C++ class Type::Types enum has these values which do
>
> > > not appear in the C++ 2.1 specification:
> > >
> > > - OpenDataObjectType
> > > - num_type
> > >
> > > Would it be appropriate to file a bug to remove the additional
> values?
> > > Or alternatively a bug for them to be submitted to the spec
> > > committee?
> > >
> > > In addition the 2.1 spec renamed the enum value "IntegerType" to
> > > "IntType".
> > >
> > > Would it be appropriate to file a bug to have this value renamed?
> > >
> > > Thanks,
> > >
> > > Michael Yoder
> > > Software Developer
> > > Rogue Wave Software
> > >
> > > 
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> &

Re: FW: [jira] Updated: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string& prop)

[Pete Robbins]

Applied now. Another great patch. Thanks!

On 22/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I uploaded a patch for TUSCANY-1371. If someone could review and apply
> it that would be great.
>
> Thanks,
>
> Michael
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 22, 2007 2:47 PM
> To: Michael Yoder
> Subject: [jira] Updated: (TUSCANY-1371) C++ SDO spec
> compliance/portability: DataObject::getInstanceProperty(const
> std::string& prop)
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1371?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1371:
> ---
>
>Attachment: TUSCANY-1371.txt
>
> This patch updates the DataObject::getProperty methods to the 2.1 spec
> API.
>
> > C++ SDO spec compliance/portability:
> > C++ DataObject::getInstanceProperty(const std::string& prop)
> > --
> > ---
> >
> > Key: TUSCANY-1371
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1371
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: API issue - all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1371.txt
> >
> >
> > The Tuscany C++ SDO specification interface introduces off-spec member
> function overloads for "getProperty". The SDO 2.1 spec introduces the
> member function: DataObject::getInstanceProperty(const std::string&
> prop), whicfh should replace these functions.
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 6:35 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: C++ SDO spec compliance/portability:
> > DataObject::getInstanceProperty(const std::string& prop) Hi, In the
> > DataObject interface, these member functions are present which are not
> in the C++ 2.1 specification:
> > virtual const Property& getProperty(unsigned int index) = 0;
> > virtual const Property& getProperty(const char* prop) = 0;
> > virtual const Property& getProperty(const SDOString& prop) = 0;
> > Since the 2.1 spec now has "getInstanceProperty(const std::string&
> prop)", would it be a good idea to file a Jira/patch to replace these
> member functions with it in the specification interface?
> > Thanks,
> > Michael Yoder
> > Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
>
> --
> 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]
>
>


-- 
Pete

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

[jira] Commented: (TUSCANY-1564) xsi:type not always set for complexTypes

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1564:
---

I have applied a patch to the branch only which I believe works. I think that 
we should always write xsi:type information for properties that are of an 
abstract type. In this case the property 'request' is of abstract type 
'requestType' so we must specify what the real type of the property is.

I have tested this and it appears not to break anything else so please can you 
try this out in php and let me know.

> xsi:type not always set for complexTypes
> 
>
> Key: TUSCANY-1564
> URL: https://issues.apache.org/jira/browse/TUSCANY-1564
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: Win XP and Gentoo Linux
>Reporter: Matthew Peters
>
> This has been reported by a user of the PHP SDO code. I have verified that he 
> is right - the problem does exist. I will cut and paste in the PHP example 
> from the defect http://pecl.php.net/bugs/bug.php?id=11774 but the php-ness of 
> the example is irrelevant: under the covers we are just manipulating a C++ 
> SDO and then calling XMLHelper->save()
> In the defect text below he puts in both expected and actual output. He is 
> right to raise the problem in the sense that I have tried reading in the 
> actual and expected xml under XERCES with schema validation turned on, and 
> the actual will *not* validate whereas the expected will. 
> Incidentally there is some history w.r.t. xsi:types - in a different case 
> they were coming out when we did not want them and they were suppressed for 
> us. See for example JIRA 1297. I do not know the rules which should determine 
> whether it should be present or not.
> Here follows the original PHP defect.
> Description:
> 
> xsi:type is not always set for complexTypes.  Notice the absence of 
> xsi:type="collectionInfo" in the actual output.
> Reproduce code:
> ---
> 
> http://www.w3.org/2001/XMLSchema";>
>   
>  
>   
>  
>
>   
>  
>   
>fixed="collectionInfo"/>
>
>   
>
>
>   
>  
> 
> 
>  
> 
> 
>  try {
>   $xmldas = SDO_DAS_XML::create("request.xsd");
>   try {
>   $doc = $xmldas->createDocument('', 'request-list');
>   $rdo = $doc->getRootDataObject();
>   $request = $xmldas->createDataObject('', 'collectionInfo');
>   $request->collection->insert('Blah');
>   $request->kind = 'collectionInfo';
>   $rdo->request->insert($request);
>   print($xmldas->saveString($doc));
>   } catch (SDO_Exception $e) {
>   print($e);
>   }
> } catch (SDO_Exception $e) {
>   print("Problem creating an XML document: " . $e->getMessage());
> }
> ?>
> Expected result:
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";>
> 
> Blah
> 
> 
> Actual result:
> --
> 
> http://www.w3.org/2001/XMLSchema-instance";>
> 
> Blah
> 
> 

-- 
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-1566) Element coming out in the wrong namespace

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1566.
---

   Resolution: Fixed
Fix Version/s: Cpp-Next

Fixed in HEAD and the branch.

> Element coming out in the wrong namespace
> -
>
> Key: TUSCANY-1566
> URL: https://issues.apache.org/jira/browse/TUSCANY-1566
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Fix For: Cpp-Next
>
> Attachments: Atom1.0.xsd
>
>
> We have a schema file that defines an atom feed. It specified 
> elementFormDefault="qualified" so that lower level elements should be in the 
> target namespace. I will attach the schema as a separate file. With a very 
> simple php test case as follows:
> $xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
> $document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
> $entry = $document->getRootDataObject();
> $author = $entry->createDataObject('author');
> $author->name[] = "Caroline Maynard";
> print $xmldas->saveString($document,2);
> we get
> 
> http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:tns="http://www.w3.org/2005/Atom";>
>   
> Caroline Maynard
>   
> 
> whereas we should see the  element in the tns namespace.
> I have checked this with XERCES: the xml that we are generating will not 
> validate, whereas if I alter it to have  in the tns namespace it will. 

-- 
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] Commented: (TUSCANY-1566) Element coming out in the wrong namespace

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1566:
---

This should be fairly easy to fix. I think it is in the logic where we are 
writing a primitive as an element in a sequenced DO.

> Element coming out in the wrong namespace
> -
>
> Key: TUSCANY-1566
> URL: https://issues.apache.org/jira/browse/TUSCANY-1566
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Attachments: Atom1.0.xsd
>
>
> We have a schema file that defines an atom feed. It specified 
> elementFormDefault="qualified" so that lower level elements should be in the 
> target namespace. I will attach the schema as a separate file. With a very 
> simple php test case as follows:
> $xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
> $document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
> $entry = $document->getRootDataObject();
> $author = $entry->createDataObject('author');
> $author->name[] = "Caroline Maynard";
> print $xmldas->saveString($document,2);
> we get
> 
> http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:tns="http://www.w3.org/2005/Atom";>
>   
> Caroline Maynard
>   
> 
> whereas we should see the  element in the tns namespace.
> I have checked this with XERCES: the xml that we are generating will not 
> validate, whereas if I alter it to have  in the tns namespace it will. 

-- 
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]

[NOTICE] Brady Johnson voted as Tuscany committer

[Pete Robbins]

The Tuscany PPMC and Incubator PMC have voted for Brady to become a
Tuscany committer.

Congratulations and welcome Brady!

I look forward to your continued excellent contributions to Tuscany.

Cheers,

-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1366) C++ SDO spec portability: SDORuntimeException off-spec member functions

[Pete Robbins]

patch applied.

Thanks!

On 17/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I uploaded a patch for TUSCANY-1366. If someone could review and apply
> it that would be great.
>
> Thanks,
>
> Michael
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 17, 2007 8:33 AM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1366) C++ SDO spec portability:
> SDORuntimeException off-spec member functions
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1366?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1366:
> ---
>
>Attachment: TUSCANY-1366.txt
>
> This patch removes the off-spec API from C++ SDO Exception classes. The
> shift operator is kept as a global operator. All the SDO existing
> exceptions were using a SCA exception serverity level of warning, so SDO
> to SCA exception conversion uses this level of severity. In looking at
> the code reporting multiple exception contexts (via re-throwing) was
> never functional (the code to do so was commented out with crash
> warnings). Likewise, this code will report on the initial context where
> the exception was thrown.
>
> > C++ SDO spec portability: SDORuntimeException off-spec member
> > C++ functions
> > --
> > -
> >
> > Key: TUSCANY-1366
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1366
> > Project: Tuscany
> >  Issue Type: Improvement
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: portability issue -- all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1366.txt
> >
> >
> > Tuscany C++ SDO specification class SDORuntimeException has off-spec
> member functions used by SCA (shown in the e-mail thread below). It
> would seem that for portability these should be taken internal to
> Tuscany SDO, or submitted to the spec committee.
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 7:37 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: RE: C++ SDO spec compliance/portability: SDORuntimeException
> > Thanks Pete, Yes, these issues I am putting together and posting came
> > up when doing a portability study using HydraSDO to build Tuscany SCA.
> Since the SDO spec is separate from SCA, we were thinking this would be
> a good goal. That seems to mean making them internal to Tuscany SDO or
> taking them to the committee.
> > Michael
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 21, 2007 9:02 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: C++ SDO spec compliance/portability: SDORuntimeException
> > Michael, An interesting set of questions! I'm not convinced that
> > adding methods to the spec api classes is a compliance issue (in fact
> it may be impossible to implement without modifying the spec apis ...
> constructors etc.) but it could be a portability issue if it is not
> clear that the methods are implementation specific.
> > The methods below are added so that an SDORuntimeException can contain
> a "stack" of locations indicating where it was thrown/rethrown etc..
> These are only used within the Tuscany implementation so I guess could
> be moved to protected and make the classes that use them friends?? I'm
> not sure how useful these are anyway but the exception class pre-dates
> it being used for SDORuntimeException.
> > There are also methods to allow simple streaming:
> > catch(SDORuntimeException& e)
> > {
> >cout << e;
> > }
> > I like the simplicity of this but I guess we could write an SDOUtils
> method to do something similar instead.
> > I'm not sure if any of these should be mandated by the specification.
> > Cheers,
> > On 21/06/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > The Tuscany SDO C++ class SDORuntimeException has these public
> > > member functions which do not appear in the C++ 2.1 specification:
> > >
> > >
> > > SDO_API severity_level getSeverity() const; SDO_API void
> > > setSeverity(severity_level sev); SDO_API void setMessageText(const
> > > std::string& msg_text); SDO_API void setExceptionLo

Re: [SCA Native] Next Release Design

[Pete Robbins]

Brady,

sorry I haven't had too much time to comment on this but it all looks
sensible and in the right direction to me.

Regarding the schema loading, where you say
"sca-implementation-java.xsd (loaded but ignored) " I think this means
we will load this schema but as no extension is registered to handle
the  those elements will be ignored when
building the model from scdl.

I think we should ensure that scdl is not the only way to define model
elements so that extensions can add to the model dynamically. I think
this is possible today but I need to re-familiarise myself with the
code ;-)

Cheers,

On 13/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> I have written some preliminary design specifications for the TuscanySCA
> M4 release.  This is a living document, and I will be continuously
> updating it.
>
> Before I get any further, I would like some opinions on the refactor of
> the "SCA Data Model". Input/Suggestions are very welcome.
>
> Here's the WIKI page:
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+Nativ
> e+Release+M4+Design+Specifications
>
> (the mail program may cut the link into several lines, so make sure you
> copy all the way to +Specifications)
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SCA Native] Test suite is stale and hasn't been maintained for ages

[Pete Robbins]

I've deleted this. It has been proposed several times to remove this
and I've never seen any objections.

It's gone!

Cheers,

On 13/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I wrote a JIRA about this:
>https://issues.apache.org/jira/browse/TUSCANY-1533
>
> Why don't we just delete it to avoid people wasting time wondering why
> it doesn't even compile for them (like I did).
> We'll be making a new one for the M4 release anyways.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Pete Robbins]

On 13/08/07, David Haney <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 10, 2007 8:33 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] java implementation and interface schema
> files
> > loaded but not used
> >
> > Brady Johnson wrote:
> > > Does anyone have any insight into why these files are loaded but
> never
> > > used in TuscanySCA Native:
> > >
> > >  /xsd/
> > > sca-implementation-java.xsd
> > > sca-interface-java.xsd
> > >
> > > I created a JIRA for this:
> > > https://issues.apache.org/jira/browse/TUSCANY-1513
> > >
> > > Their existence in the project is misleading and implies that
> TuscanySCA
> > > Native supports Java services.
> > > Perhaps these should be removed in M4.
> > >
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > > 
> > >
> > >
> > >
> > >
> >
> > Will you be able to load (and ignore without breaking) a composite
> > containing implementation.java and interface.java elements? I'm
> thinking
> > about scenarios where people share a composite between the two
> runtimes,
> > with part of it running on the Native runtime and part running on the
> > Java runtime.
> >
> > I guess I'll have the same question for the Java project, we should be
> > able to ignore (or just handle with a warning) implementation.cpp and
> > interface.cpp in the Java runtime.
> >
> > --
> > Jean-Sebastien
> >
>
> Won't this still be a problem for other extensions that are provided by
> Tuscany Java?  For example, implementation.script?  Does this imply that
> we should copy all of the extension xsd files from Tuscany Java into
> Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)?
>
> Is it possible we could have the composite loader ignore (or warn about)
> extension types that it doesn't recognize?  This would allow it to parse
> the composite files, but wouldn't require that our runtime explicitly
> recognize every extension type that isn't supported.

I think this is the way to go.

>
> -- David Haney
> -- Chief Architect, Hydra Products
> -- Rogue Wave Software
> -- http://www.roguewave.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Pete

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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Pete Robbins]

On 14/08/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The SCA Java runtime doesn't use the XSD for the assembly or extensions at
> runtime to parse the composite file. A StAX-based artifact processor is
> plugged into the runtime to handle the extensions such as
> implementation.java, implementation.script and binidng.rmi.
>
> Does SCA Native use the generated SDO from the XSDs to load the composite
> file?
>

No. SDO C++ does not have a generated SDO feature yet. We load the
schema to define types then load the XML to create dynamic SDOs. It
was simple. convenient and initially we were using it to test out the
SDO code.

> Thanks,
> Raymond
>
> - Original Message -
> From: "David Haney" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, August 13, 2007 2:35 PM
> Subject: RE: [SCA Native] java implementation and interface schema files
> loaded but not used
>
>
>
>
> > -Original Message-
> > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 10, 2007 8:33 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] java implementation and interface schema
> files
> > loaded but not used
> >
> > Brady Johnson wrote:
> > > Does anyone have any insight into why these files are loaded but
> never
> > > used in TuscanySCA Native:
> > >
> > >  /xsd/
> > > sca-implementation-java.xsd
> > > sca-interface-java.xsd
> > >
> > > I created a JIRA for this:
> > > https://issues.apache.org/jira/browse/TUSCANY-1513
> > >
> > > Their existence in the project is misleading and implies that
> TuscanySCA
> > > Native supports Java services.
> > > Perhaps these should be removed in M4.
> > >
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > > 
> > >
> > >
> > >
> > >
> >
> > Will you be able to load (and ignore without breaking) a composite
> > containing implementation.java and interface.java elements? I'm
> thinking
> > about scenarios where people share a composite between the two
> runtimes,
> > with part of it running on the Native runtime and part running on the
> > Java runtime.
> >
> > I guess I'll have the same question for the Java project, we should be
> > able to ignore (or just handle with a warning) implementation.cpp and
> > interface.cpp in the Java runtime.
> >
> > --
> > Jean-Sebastien
> >
>
> Won't this still be a problem for other extensions that are provided by
> Tuscany Java?  For example, implementation.script?  Does this imply that
> we should copy all of the extension xsd files from Tuscany Java into
> Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)?
>
> Is it possible we could have the composite loader ignore (or warn about)
> extension types that it doesn't recognize?  This would allow it to parse
> the composite files, but wouldn't require that our runtime explicitly
> recognize every extension type that isn't supported.
>
> -- David Haney
> -- Chief Architect, Hydra Products
> -- Rogue Wave Software
> -- http://www.roguewave.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]
>
>


-- 
Pete

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

Re: [SCA Native] Tuscany SCA Native for Windows is not msvc backwards compatible

[Pete Robbins]

I've applied 1529 and 1530.

Cheers,

On 10/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> I created a JIRA for this compilation issue and have already uploaded a
> patch. Can someone submit it please.
>
> https://issues.apache.org/jira/browse/TUSCANY-1530
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API

[Pete Robbins]

Another great patch! Thanks!

Should SDO.h only include headers for the public (i.e. spec) APIs? I
think it should so things like DASValue.h should be removed. Anyone
who wants to utilize the internal APIs should have to know they are
doing it!

What do you think?

Cheers,

On 10/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have uploaded a patch for TUSCANY-1375. If it could be reviewed and
> applied that would be great.
>
> Thanks,
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 09, 2007 9:16 PM
> To: Michael Yoder
> Subject: [jira] Updated: (TUSCANY-1375) C++ SDO spec portability: C++
> type definition API
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1375:
> ---
>
>Attachment: TUSCANY-1375.txt
>
> This patch privatizes the internal helper classes used in SDO for
> processing XML Schema, and removes their use from SCA.
>
> > C++ SDO spec portability: C++ type definition API
> > -
> >
> > Key: TUSCANY-1375
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1375
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: API issue - all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1375.txt
> >
> >
> > The Tuscany C++ SDO implementation has off-spec type definition
> classes which are used by SCA. These should be removed or used only
> internally by the implementation until or unless they can be
> incorporated into the specification.
> > -Original Message-
> > From: Michael Yoder
> > Sent: Thursday, June 21, 2007 8:45 PM
> > To: 'tuscany-dev@ws.apache.org'
> > Subject: C++ SDO spec portability: C++ type definition API Hi,
> > C++ Tuscany SDO extends type definition API with the off-spec classes
> PropertyDefinition and TypeDefinition, which are used externally by SCA.
>
> > We also have found the C++ SDO specification type definition API
> > lacking, and have added the Impl member function
> > DataFactoryImpl::define(DataObjectPtr)
> > to parallel the Java type definition API using DataObject's of Types
> commonj.sdo#Type and commonj.sdo#Property.
> > Should a Jira be raised for these classes to be removed or kept
> internal to Tuscany C++ SDO? Is there API here that it would be good to
> present to the comittee?
> > Thanks,
> > Michael Yoder
> > Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
>
> --
> 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]
>
>


-- 
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I noticed that the core header files were getting installed in the
wrong place: ...deploy/include/src/tuscany... rather than
...deploy/include/tuscany... etc so I fixed this.

Cheers,

On 07/08/2007, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I applied 7 today and will look at 8 now.
>
> Cheers
>
> On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I have 2 outstanding patches uploaded for the TuscanySCA Native ant
> > build:
> >  - tuscany_patch_update7_jira1438
> >  - tuscany_patch_update8_jira1438
> >
> > https://issues.apache.org/jira/browse/TUSCANY-1438
> >
> > Could someone submit them for me please.
> >
> > I had a bit of spare time this weekend, so I'll be uploading the ant
> > build files for TuscanySDO Native soon.
> >
> > I still haven't had a chance to advance the M4 design yet, I hope to be
> > able to start this afternoon.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 30, 2007 9:14 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [SCA Native] preliminary ant build
> >
> >
> > I added a utility target that displays all of the system properties.
> > Since its in system.xml, it can be executed from any build.xml that
> > imports system.xml, which is pretty much anywhere.
> >
> > Below is a sample output.
> >
> > The "svn diff" patch is attached.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > [EMAIL PROTECTED] sca]$ ant display.system
> > Buildfile: build.xml
> >
> > check.ws:
> >
> > check.python:
> >
> > check.php:
> >
> > check.ruby:
> >
> > check.rest:
> >
> > display.system:
> > [echo]
> > [echo] TuscanySCA paths
> > [echo]   tuscanySDO.install.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sdo/deploy
> > [echo]   tuscanySCA.root.dir=
> > /amd/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca
> > [echo]   tuscanySCA.root.src.dir=
> > /amd/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca/runtime
> > [echo]   tuscanySCA.install.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca/deploy
> > [echo]   tuscanySCA.library.version=  '.0.0.0'
> > [echo]
> > [echo] TuscanySCA compiler configuration
> > [echo]   compiler.name=   'g++'
> > [echo]   lib.ext= '.so'
> > [echo]   dll.ext= ''
> > [echo]   lib.prefix=  'lib'
> > [echo]   object.ext=  '.o'
> > [echo]   exe.ext= ''
> > [echo]   script.ext=  '.sh'
> > [echo]
> > [echo] TuscanySCA ws extension enabled
> > [echo]   axis2c.home.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/axis2c-src-0.96/deploy
> > [echo]
> > [echo] TuscanySCA php extension enabled
> > [echo]   php.lib.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/php-5.1.6/deploy/lib
> > [echo]   php.include.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/php-5.1.6/deploy/include/php
> > [echo]   php.sca.sdo.lib.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/sdo-1.0.3/lib
> > [echo]   php.sca.sdo.include.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/sdo-1.0.3
> > [echo]
> > [echo] TuscanySCA python extension enabled
> > [echo]   python.lib.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/Python-2.5.1/deploy/lib
> > [echo]   python.include.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/Python-2.5.1/deploy/include/python2.5
> > [echo]   python.version=   python2.5
> > [echo]
> >     [echo] TuscanySCA rest extension enabled
> > [echo]   rest.curl.lib.dir=/usr/lib
> > [echo]   rest.curl.include.dir=/usr/include/curl
> > [echo]   rest.httpd.include.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/httpd-2.0.59/deploy/include
> > [echo]   rest.apr.include.dir= /usr/include/apr-0
> > [echo]
> > [echo] TuscanySCA ruby extension enabled
> > [echo]   ruby.lib.dir=
> > /nfs/homes/bjohnson/tuscany_cpp/ruby-1.8.6/deploy/lib
> > [echo]   ruby.incl

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

[Pete Robbins]

Patch applied. Thanks for that... and for taking care of the affected
SCA source.

Cheers,

On 08/08/2007, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi Pete,
>
> I uploaded an updated patch for TUSCANY-1376 to address the windows
> compilation issue.
>
> Michael
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 08, 2007 9:43 AM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability:
> RefCountingPointer
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1376:
> ---
>
>Attachment: TUSCANY-1376v2.txt
>
> Updated patch to address windows compilation issue.
>
> > C++ SDO spec portability: RefCountingPointer
> > 
> >
> > Key: TUSCANY-1376
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1376
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1376.txt, TUSCANY-1376v2.txt
> >
> >
> > Tuscany  C++ SDO class RefCounting pointer has the member function:
> > operator T*() {return pointee;}
> > which expose the raw dumb pointer for SDO classes (for the common use
> of smart pointers). This member function is used by SCA, and raises
> undesirable object lifetime and allowed operation issues. The member
> function should be replaced with a safe (referenced in the below -email
> thread) conversion to bool member function.
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 22, 2007 6:16 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: C++ SDO spec portability: RefCountingPointer Michael, I
> > strongly suspect that the operator T*() ws put in for a good reason.
> It may be a good idea to remove this but it may be non-trivial.
> > The ostream operator << is very useful and there is a default
> implementation in RefCountingObject so that objects inheriting from
> RefCounting object do not need to implement anything... but they can if
> appropriate.
> > You are raising a lot if issues which is great and it would be
> > excellent to get Tuscany SDO up to 2.1 spec level. I suspect there
> > will be hundreds of issues some of which may require large
> re-writes/refactoring of the Tuscany SDO Code!! Raising these as Jiras
> is the best thing to do so we can track them. Helping fix them by
> submitting patches would be even better ;-) Cheers, On 22/06/07, Michael
> Yoder <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
> > > class RefCountingPointer has functions used externally by SCA:
> > >
> > >operator T*() {return pointee;}
> > >friend std::ostream& operator<< (std::ostream &os, const
> > > RefCountingPointer& ptr)
> > >
> > > It looks like the conversion to T* function may have been put in
> > > originally as a porting alternative to a member function template,
> > > but may not be needed any more since the member template is now
> > > included outside the #ifdef.
> > >
> > > Exposing the dumb pointer is undesirable since it raises object
> > > lifetime issues and allows other unwanted operations. Having a
> > > conversion to bool is convenient however, and can be implemented
> > > safely using a member function pointer trick (see:
> > > http://www.artima.com/cppsource/safebool.html).
> > >
> > > The shift operator also seems undesireable since it places a burden
> > > on all classes which use smart pointers to implement toString
> > > functionality.
> > >
> > > How does it sound to raise a Jira to have these member functions
> > > removed?
> > >
> > > Thanks,
> > > Michael Yoder
> > > Rogue Wave Software - [EMAIL PROTECTED] Software Developer -
> > > HydraSDO
> > >
> > > ---

Re: [SDO Native] ant build system for SDO Native

[Pete Robbins]

I've applied the patch. I noticed I had to define LIBXML2_INCLUDE and
LIBXML2_LIB. Previously on Windows we just defined LIBXML2_HOME. I
think what you have here is better as it is consistent with the
Linux/Mac build.

We will need to update the doc at some point when the ant build code
is stable. It will probably be best to remove the existing automake
and vcexpress builds at that point.

Cheers,

On 07/08/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> Thanks. I'll get on the case soon.
>
> I really appreciate the effort you have put in to this.
>
> Cheers,
>
> On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > I just uploaded a patch for JIRA:
> >
> >https://issues.apache.org/jira/browse/TUSCANY-1509
> > <https://issues.apache.org/jira/browse/TUSCANY-1509>
> >
> > Which is an enhancement bug for TuscanySDO Native to change the build
> > system over to use ant instead of automake.
> >
> > This first version uploaded includes targets to build, install, and
> > clean the sdo and sdo_axiom libraries and headers.
> >
> > On my PC, the build takes 53 seconds and on Linux, it takes about 45
> > seconds, which is a huge improvement over existing build systems.
> > Finally TuscanyNative has a common build system across all platforms.
> >
> > Things left to do for the SDO ant build system include:
> > - add targets for code document generation
> > - add targets SDO testing
> >
> > Can someone please submit the patch for me. Suggestions are very
> > welcome!
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> Pete
>


-- 
Pete

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

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

[Pete Robbins]

I get compile errors on Windows:

 warning C4346: 'commonj::sdo::RefCountingPointer::PointerType' :
dependent name is not a type
prefix with 'typename' to indicate a type
d:\tuscanysvn\cpp\sdo\runtime\core\src\commonj\sdo\refcountingpointer.h(124)
: error C2061: syntax error : identifier 'PointerType'
d:\tuscanysvn\cpp\sdo\runtime\core\src\commonj\sdo\refcountingpointer.h(128)
: error C2244: 'commonj::sdo::RefCountingPointer::{ctor}' : unable
to match function definition to an existing declaration
definition
'commonj::sdo::RefCountingPointer::RefCountingPointer(void)'
existing declarations
'commonj::sdo::RefCountingPointer::RefCountingPointer(const
commonj::sdo::RefCountingPointer &)'
'commonj::sdo::RefCountingPointer::RefCountingPointer(T *)'

Any ideas?

On 07/08/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'll get on it. BIG patch ;-)
>
> Cheers,
>
> On 07/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I uploaded a patch to address TUSCANY-1376. If someone could review and
> > apply it that would be great.
> >
> > Thanks,
> >
> > Michael Yoder
> > Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> > HydraSDO
> >
> > -Original Message-
> > From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 07, 2007 1:52 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability:
> > RefCountingPointer
> >
> >
> > [
> > https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.ji
> > ra.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Michael Yoder updated TUSCANY-1376:
> > ---
> >
> >Attachment: TUSCANY-1376.txt
> >
> > This patch removes the implicit conversion to dumb pointer in
> > RefCountingPointer (still available via the helper function
> > getRawPointer()). It also adds some additional operators and helper
> > functions, including a safe conversion to bool for use with if
> > expressions. Some addition unit tests are added, and some smart pointer
> > cleanup is included.
> >
> > > C++ SDO spec portability: RefCountingPointer
> > > 
> > >
> > > Key: TUSCANY-1376
> > > URL:
> > https://issues.apache.org/jira/browse/TUSCANY-1376
> > > Project: Tuscany
> > >  Issue Type: Bug
> > >  Components: C++ SDO, C++ Specification
> > >Affects Versions: Cpp-M3
> > > Environment: all platforms
> > >Reporter: Michael Yoder
> > > Fix For: Cpp-Next
> > >
> > > Attachments: TUSCANY-1376.txt
> > >
> > >
> > > Tuscany  C++ SDO class RefCounting pointer has the member function:
> > > operator T*() {return pointee;}
> > > which expose the raw dumb pointer for SDO classes (for the common use
> > of smart pointers). This member function is used by SCA, and raises
> > undesirable object lifetime and allowed operation issues. The member
> > function should be replaced with a safe (referenced in the below -email
> > thread) conversion to bool member function.
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, June 22, 2007 6:16 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: C++ SDO spec portability: RefCountingPointer Michael, I
> > > strongly suspect that the operator T*() ws put in for a good reason.
> > It may be a good idea to remove this but it may be non-trivial.
> > > The ostream operator << is very useful and there is a default
> > implementation in RefCountingObject so that objects inheriting from
> > RefCounting object do not need to implement anything... but they can if
> > appropriate.
> > > You are raising a lot if issues which is great and it would be
> > > excellent to get Tuscany SDO up to 2.1 spec level. I suspect there
> > > will be hundreds of issues some of which may require large
> > re-writes/refactoring of the Tuscany SDO Code!! Raising these as Jiras
> > is the best thing to do so we can track them. Helping fix them by
> > submitting patches would be even better ;-) Cheers, On 22/06/07, Michael
> > Yoder <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > In looking at C++ SD

Re: FW: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer

[Pete Robbins]

I'll get on it. BIG patch ;-)

Cheers,

On 07/08/07, Michael Yoder <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I uploaded a patch to address TUSCANY-1376. If someone could review and
> apply it that would be great.
>
> Thanks,
>
> Michael Yoder
> Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
> HydraSDO
>
> -Original Message-
> From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 07, 2007 1:52 PM
> To: tuscany-dev@ws.apache.org
> Subject: [jira] Updated: (TUSCANY-1376) C++ SDO spec portability:
> RefCountingPointer
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.ji
> ra.plugin.system.issuetabpanels:all-tabpanel ]
>
> Michael Yoder updated TUSCANY-1376:
> ---
>
>Attachment: TUSCANY-1376.txt
>
> This patch removes the implicit conversion to dumb pointer in
> RefCountingPointer (still available via the helper function
> getRawPointer()). It also adds some additional operators and helper
> functions, including a safe conversion to bool for use with if
> expressions. Some addition unit tests are added, and some smart pointer
> cleanup is included.
>
> > C++ SDO spec portability: RefCountingPointer
> > 
> >
> > Key: TUSCANY-1376
> > URL:
> https://issues.apache.org/jira/browse/TUSCANY-1376
> > Project: Tuscany
> >  Issue Type: Bug
> >  Components: C++ SDO, C++ Specification
> >Affects Versions: Cpp-M3
> > Environment: all platforms
> >Reporter: Michael Yoder
> > Fix For: Cpp-Next
> >
> > Attachments: TUSCANY-1376.txt
> >
> >
> > Tuscany  C++ SDO class RefCounting pointer has the member function:
> > operator T*() {return pointee;}
> > which expose the raw dumb pointer for SDO classes (for the common use
> of smart pointers). This member function is used by SCA, and raises
> undesirable object lifetime and allowed operation issues. The member
> function should be replaced with a safe (referenced in the below -email
> thread) conversion to bool member function.
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 22, 2007 6:16 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: C++ SDO spec portability: RefCountingPointer Michael, I
> > strongly suspect that the operator T*() ws put in for a good reason.
> It may be a good idea to remove this but it may be non-trivial.
> > The ostream operator << is very useful and there is a default
> implementation in RefCountingObject so that objects inheriting from
> RefCounting object do not need to implement anything... but they can if
> appropriate.
> > You are raising a lot if issues which is great and it would be
> > excellent to get Tuscany SDO up to 2.1 spec level. I suspect there
> > will be hundreds of issues some of which may require large
> re-writes/refactoring of the Tuscany SDO Code!! Raising these as Jiras
> is the best thing to do so we can track them. Helping fix them by
> submitting patches would be even better ;-) Cheers, On 22/06/07, Michael
> Yoder <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > In looking at C++ SDO portabilty, we found the the Tuscany C++ SDO
> > > class RefCountingPointer has functions used externally by SCA:
> > >
> > >operator T*() {return pointee;}
> > >friend std::ostream& operator<< (std::ostream &os, const
> > > RefCountingPointer& ptr)
> > >
> > > It looks like the conversion to T* function may have been put in
> > > originally as a porting alternative to a member function template,
> > > but may not be needed any more since the member template is now
> > > included outside the #ifdef.
> > >
> > > Exposing the dumb pointer is undesirable since it raises object
> > > lifetime issues and allows other unwanted operations. Having a
> > > conversion to bool is convenient however, and can be implemented
> > > safely using a member function pointer trick (see:
> > > http://www.artima.com/cppsource/safebool.html).
> > >
> > > The shift operator also seems undesireable since it places a burden
> > > on all classes which use smart pointers to implement toString
> > > functionality.
> > >
> > > How does it sound to raise a Jira to have these member functions
> > > removed?
> > >
> > > Thanks,

Re: [SDO Native] ant build system for SDO Native

[Pete Robbins]

Thanks. I'll get on the case soon.

I really appreciate the effort you have put in to this.

Cheers,

On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I just uploaded a patch for JIRA:
>
>https://issues.apache.org/jira/browse/TUSCANY-1509
> 
>
> Which is an enhancement bug for TuscanySDO Native to change the build
> system over to use ant instead of automake.
>
> This first version uploaded includes targets to build, install, and
> clean the sdo and sdo_axiom libraries and headers.
>
> On my PC, the build takes 53 seconds and on Linux, it takes about 45
> seconds, which is a huge improvement over existing build systems.
> Finally TuscanyNative has a common build system across all platforms.
>
> Things left to do for the SDO ant build system include:
> - add targets for code document generation
> - add targets SDO testing
>
> Can someone please submit the patch for me. Suggestions are very
> welcome!
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>


-- 
Pete

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

Re: [SCA Native] java implementation and interface schema files loaded but not used

[Pete Robbins]

It was simply that we were loading all the initial sca schema. So the
core code loads sca.xsd but I think we should change that to
specifically load the ones we need. Maybe the best thing is to load
any schema in /xsd and we can just delete the java
stuff.

If the Native runtime wants to support Java then that schema would be
loaded by the Java extension.

Cheers,

On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> Does anyone have any insight into why these files are loaded but never
> used in TuscanySCA Native:
>
>  /xsd/
>sca-implementation-java.xsd
>sca-interface-java.xsd
>
> I created a JIRA for this:
>https://issues.apache.org/jira/browse/TUSCANY-1513
>
> Their existence in the project is misleading and implies that TuscanySCA
> Native supports Java services.
> Perhaps these should be removed in M4.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
> 
>
>
>


-- 
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I applied 7 today and will look at 8 now.

Cheers

On 07/08/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I have 2 outstanding patches uploaded for the TuscanySCA Native ant
> build:
>  - tuscany_patch_update7_jira1438
>  - tuscany_patch_update8_jira1438
>
> https://issues.apache.org/jira/browse/TUSCANY-1438
>
> Could someone submit them for me please.
>
> I had a bit of spare time this weekend, so I'll be uploading the ant
> build files for TuscanySDO Native soon.
>
> I still haven't had a chance to advance the M4 design yet, I hope to be
> able to start this afternoon.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Brady Johnson [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 9:14 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: [SCA Native] preliminary ant build
>
>
> I added a utility target that displays all of the system properties.
> Since its in system.xml, it can be executed from any build.xml that
> imports system.xml, which is pretty much anywhere.
>
> Below is a sample output.
>
> The "svn diff" patch is attached.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> [EMAIL PROTECTED] sca]$ ant display.system
> Buildfile: build.xml
>
> check.ws:
>
> check.python:
>
> check.php:
>
> check.ruby:
>
> check.rest:
>
> display.system:
> [echo]
> [echo] TuscanySCA paths
> [echo]   tuscanySDO.install.dir=
> /nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sdo/deploy
> [echo]   tuscanySCA.root.dir=
> /amd/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca
> [echo]   tuscanySCA.root.src.dir=
> /amd/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca/runtime
> [echo]   tuscanySCA.install.dir=
> /nfs/homes/bjohnson/tuscany_cpp/tuscany_svn_head/sca/deploy
> [echo]   tuscanySCA.library.version=  '.0.0.0'
> [echo]
> [echo] TuscanySCA compiler configuration
> [echo]   compiler.name=   'g++'
> [echo]   lib.ext= '.so'
> [echo]   dll.ext= ''
> [echo]   lib.prefix=  'lib'
> [echo]   object.ext=  '.o'
> [echo]   exe.ext= ''
> [echo]   script.ext=  '.sh'
> [echo]
> [echo] TuscanySCA ws extension enabled
> [echo]   axis2c.home.dir=
> /nfs/homes/bjohnson/tuscany_cpp/axis2c-src-0.96/deploy
> [echo]
> [echo] TuscanySCA php extension enabled
> [echo]   php.lib.dir=
> /nfs/homes/bjohnson/tuscany_cpp/php-5.1.6/deploy/lib
> [echo]   php.include.dir=
> /nfs/homes/bjohnson/tuscany_cpp/php-5.1.6/deploy/include/php
> [echo]   php.sca.sdo.lib.dir=
> /nfs/homes/bjohnson/tuscany_cpp/sdo-1.0.3/lib
> [echo]   php.sca.sdo.include.dir=
> /nfs/homes/bjohnson/tuscany_cpp/sdo-1.0.3
> [echo]
> [echo] TuscanySCA python extension enabled
> [echo]   python.lib.dir=
> /nfs/homes/bjohnson/tuscany_cpp/Python-2.5.1/deploy/lib
> [echo]   python.include.dir=
> /nfs/homes/bjohnson/tuscany_cpp/Python-2.5.1/deploy/include/python2.5
> [echo]   python.version=   python2.5
> [echo]
> [echo] TuscanySCA rest extension enabled
> [echo]   rest.curl.lib.dir=/usr/lib
> [echo]   rest.curl.include.dir=/usr/include/curl
> [echo]   rest.httpd.include.dir=
> /nfs/homes/bjohnson/tuscany_cpp/httpd-2.0.59/deploy/include
> [echo]   rest.apr.include.dir= /usr/include/apr-0
> [echo]
> [echo] TuscanySCA ruby extension enabled
> [echo]   ruby.lib.dir=
> /nfs/homes/bjohnson/tuscany_cpp/ruby-1.8.6/deploy/lib
> [echo]   ruby.include.dir=
> /nfs/homes/bjohnson/tuscany_cpp/ruby-1.8.6/deploy/include
> [echo]
>
> BUILD SUCCESSFUL
> Total time: 1 second
> [EMAIL PROTECTED] sca]$
>
>
>
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 27, 2007 1:13 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> and now I've moved the core schema to cpp/sca/runtime/core/xsd
>
> On 27/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > OK.. done! runtime/core/build.xml replaces runtime/core/src/build.xml
> >
> > I'll move the xsd dir later.
> >
> > Cheers,
> >
> > On 27/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Your c

[jira] Commented: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed="true"

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1504:
---

Matthew, the speciifcation is available from here:

http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

> getSequence() returns null with a complexType defined without mixed="true"
> --
>
> Key: TUSCANY-1504
> URL: https://issues.apache.org/jira/browse/TUSCANY-1504
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
>Reporter: Matthew Schultz
> Attachments: letter.xsd
>
>
> getSequence returns null if complextType does not have the mixed attribute or 
> the mixed attribute is set to false.  
> Looking at the code, SDOSchemaSAX2Parser::startComplexType and
> SDOSchemaSAX2Parser::defineType appears to be the two places that
> isSequenced is set.  In startComplexType, it appears that both mixed and
> sequence are both treated as an attribute.  I cannot tell if it ever
> reads the child .
> It appears that isSequenced should be set to true on the basis of the
> child  and not on the basis of mixed.

-- 
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]

SDO sequenced DataObject vs XSD

[Pete Robbins]

A Jira (https://issues.apache.org/jira/browse/TUSCANY-1504)  has been
raised against the SDO C++ implementation which is saying that for a
schema:


http://www.w3.org/2001/XMLSchema";
  xmlns:letter="http://letterSchema";
  targetNamespace="http://letterSchema";>
  
  
  
  
  
  

  


the complex type "http://letterSchema#FormLetter"; is not "sequenced"
in SDO terms. I believe this is correct as the SDO use of the term
"sequenced" is related to the order of the setting of the properties
and in the above case maxOccurs=1 on the sequence and each of the
contained elements.This means an instance of a FormLetter DataObject
returns NULL for getSequence() in our implementation.

So... is my interpretation of the spec correct?

Cheers,

-- 
Pete

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

[jira] Commented: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed="true"

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1504:
---

I believe this is working as per the specification but I will ask for a 
clarification. The spec says:

>>>>>>>>>>>>
Element in all, choice, or sequence

<[GROUP] maxOccurs=[G_MAX]>
  


where 
  [GROUP] = all, choice, sequence
•   Element groups and model groups are treated as if they were expanded in 
place.
•   Nested [GROUP]s are expanded.   Property name=[NAME] 
  type=[TYPE] 
  many=true

Type sequenced=true

•   A property is created for every element
•   many=true when E_MAX or G_MAX is > 1
•   sequenced=true if the content allows elements to be interleaved.  (for 
example )
•   sequenced=true if G_MAX > 1 and there is more than one element in this 
group or a contained group.
•   Property declarations are the same whether group is  or  
or 
•   Property behavior ignores group declarations.
•   Validation of DataObjects for the group constraints is external to the 
DataObject interface.
<<<<<<<<<<<<<

The key statements are 
> sequenced=true if the content allows elements to be interleaved.  (for 
> example )
> sequenced=true if G_MAX > 1 and there is more than one element in this group 
> or a contained group.

So in your example neither of these is true as you have a sequence of elements 
with maxOccurs=1 (the default). A "Sequenced DataObject" records the order of 
the settings of the properties when the elements can be interleaved. In your 
example there can only ever be one instance of each property (element) and so 
the sequence in which they were set is not relevent. The properties are defined 
on the Type in the order declared in the sequence so you could access them in 
order by property index.

Cheers,


> getSequence() returns null with a complexType defined without mixed="true"
> --
>
> Key: TUSCANY-1504
> URL: https://issues.apache.org/jira/browse/TUSCANY-1504
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
>Reporter: Matthew Schultz
> Attachments: letter.xsd
>
>
> getSequence returns null if complextType does not have the mixed attribute or 
> the mixed attribute is set to false.  
> Looking at the code, SDOSchemaSAX2Parser::startComplexType and
> SDOSchemaSAX2Parser::defineType appears to be the two places that
> isSequenced is set.  In startComplexType, it appears that both mixed and
> sequence are both treated as an attribute.  I cannot tell if it ever
> reads the child .
> It appears that isSequenced should be set to true on the basis of the
> child  and not on the basis of mixed.

-- 
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-1423) There are no tools to verify or display tuscany services

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1423.
---

Resolution: Fixed

I believe this is all applied now

> There are no tools to verify or display tuscany services
> 
>
> Key: TUSCANY-1423
> URL: https://issues.apache.org/jira/browse/TUSCANY-1423
> Project: Tuscany
>  Issue Type: New Feature
>  Components: C++ SCA
>Affects Versions: Cpp-M3
> Environment: All platforms
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
> Attachments: build.xml, main.cpp, tuscanyScaJira1423_update2.tar, 
> TuscanyServiceLoader.cpp, TuscanyServiceLoader.cpp.model, 
> TuscanyServiceLoader.h
>
>
> According to Simon Laws thread "SCA Toys?" posted June 21, 2007, it would be 
> very useful to have a set of utilities or toys for TuscanySCA.
> I have created a toy for TuscanySCA C++ that loads tuscany services via 
> SCARuntime() and displays their information. This would be very
> useful for service development and verification.
> Following is the application's help usage:
> [EMAIL PROTECTED] bin]$ ./tuscanyServiceLoader -h
> Usage
> tuscanyDriver
> -ir Mandatory: Installation root where extensions are located: 
> ${TUSCANY_SCACPP}
> -sr Mandatory: System root where projects are located: 
> ${TUSCANY_SCACPP}/samples
> -sp Optional: System path
> -uri Optional: Base URI
> -dc Optional: Default Component name
> -model Optional: Display SCA Model Hierarchy
> -wsdl Optional: Display WSDL information
> -v Optional: Same as specifying both: -model and -wsdl
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
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-1448) CppBigBank example windows deploy script "deploy.bat" fails to deploy XML Schema

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1448.
---

Resolution: Fixed

patch applied

> CppBigBank example windows deploy script "deploy.bat" fails to deploy XML 
> Schema
> 
>
> Key: TUSCANY-1448
> URL: https://issues.apache.org/jira/browse/TUSCANY-1448
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
> Environment: windows
>Reporter: Michael Yoder
>
> The CppBigBank example deploy.bat script for windows fails to copy its XML 
> Schema file to the deploy directory (resulting in its types not being loaded 
> when the sample is executed).
> This can be fixed by adding a schema copy line to the script:
> 52a53
> > copy %samplebbsrc%\*.xsd %samplebb%

-- 
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: [SCA Native] preliminary ant build

[Pete Robbins]

and now I've moved the core schema to cpp/sca/runtime/core/xsd

On 27/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> OK.. done! runtime/core/build.xml replaces runtime/core/src/build.xml
>
> I'll move the xsd dir later.
>
> Cheers,
>
> On 27/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Your changes sound good. When you move the build.xml up to
> > tuscany/cpp/sca/runtime/core, you'll have to change the path properties
> > and the basedir of the root  element.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Friday, July 27, 2007 3:15 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > I've applied the latest patch and it looks good. I have added install
> > and clean targets for the xsd schema that get deployed.
> >
> > I think the schema that are currently in tuscany/cpp/sca/xsd should be
> > moved to tuscany/cpp/sca/runtime/core/xsd which would be a more logical
> > place for them. I would also like to move the build.xml file from
> > tuscany/cpp/sca/runtime/core/src up one level to
> > tuscany/cpp/sca/runtime/core.
> >
> > What do you think?
> >
> > Cheers,
> >
> > On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > I updated yet another patch which includes the following changes:
> > >
> > > - compile_targets.xml added  which calls
> > > .
> > >  This fixes the case for windows where *.lib needs to go in lib/ and
> > > *.dll in bin/
> > > - system.xml added targets:
> > >  , , , ,
> > >   These are called by the extension compile, link, and
> > > install targets to check  if the respective extensions have been
> > > enabled.
> > > - Added export definitions for Windows extension compilations.
> > > - Added dependant libraries to extension link targets.
> > >
> > >
> > > I think this should pretty much cover everything except the samples.
> > >
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, July 26, 2007 12:44 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > More good stuff. I've applied the latest patch but there are some
> > > issues.
> > >
> > > From a clean build if you just type "ant" in the top level cpp/sca
> > > directory then the build will fail on tuscany_sca_cpp because it needs
> >
> > > to link against /lib/tuscany_sca.dll which has not yet
> > > been installed as all the "build" targets are run recursively before
> > > the "install" targets.
> > >
> > > I also get a lot of unresolved references on windows when linking the
> > > tuscany_sca_cpp which I will look into.
> > >
> > > Cheers,
> > >
> > > On 25/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I just uploaded patch update 5 which includes the following:
> > > >
> > > > - runtime/extensions/php/build.xml
> > > > - minor change to php code so that it compiles
> > > > - compile-targets.xml added cpp-link-core which does not link in the
> >
> > > > tuscany_sca lib and changed cpp-link so that it does link it in.
> > > >
> > > > I'm working on the windows exports for the extensions, but windows
> > > > isn't behaving for me right now. (I really do dislike working with
> > > > microsoft) Hopefully I'll have this done soon.
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA
> > > > Rogue Wave Software - [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > --
> > > Pete
> > >
> > > -
> > > 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]
> > >
> > >
> >
> >
> > --
> > Pete
> >
> > -
> > 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]
> >
> >
>
>
> --
> Pete
>


-- 
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

OK.. done! runtime/core/build.xml replaces runtime/core/src/build.xml

I'll move the xsd dir later.

Cheers,

On 27/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Your changes sound good. When you move the build.xml up to
> tuscany/cpp/sca/runtime/core, you'll have to change the path properties
> and the basedir of the root  element.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 27, 2007 3:15 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> I've applied the latest patch and it looks good. I have added install
> and clean targets for the xsd schema that get deployed.
>
> I think the schema that are currently in tuscany/cpp/sca/xsd should be
> moved to tuscany/cpp/sca/runtime/core/xsd which would be a more logical
> place for them. I would also like to move the build.xml file from
> tuscany/cpp/sca/runtime/core/src up one level to
> tuscany/cpp/sca/runtime/core.
>
> What do you think?
>
> Cheers,
>
> On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I updated yet another patch which includes the following changes:
> >
> > - compile_targets.xml added  which calls
> > .
> >  This fixes the case for windows where *.lib needs to go in lib/ and
> > *.dll in bin/
> > - system.xml added targets:
> >  , , , ,
> >   These are called by the extension compile, link, and
> > install targets to check  if the respective extensions have been
> > enabled.
> > - Added export definitions for Windows extension compilations.
> > - Added dependant libraries to extension link targets.
> >
> >
> > I think this should pretty much cover everything except the samples.
> >
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, July 26, 2007 12:44 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > More good stuff. I've applied the latest patch but there are some
> > issues.
> >
> > From a clean build if you just type "ant" in the top level cpp/sca
> > directory then the build will fail on tuscany_sca_cpp because it needs
>
> > to link against /lib/tuscany_sca.dll which has not yet
> > been installed as all the "build" targets are run recursively before
> > the "install" targets.
> >
> > I also get a lot of unresolved references on windows when linking the
> > tuscany_sca_cpp which I will look into.
> >
> > Cheers,
> >
> > On 25/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > I just uploaded patch update 5 which includes the following:
> > >
> > > - runtime/extensions/php/build.xml
> > > - minor change to php code so that it compiles
> > > - compile-targets.xml added cpp-link-core which does not link in the
>
> > > tuscany_sca lib and changed cpp-link so that it does link it in.
> > >
> > > I'm working on the windows exports for the extensions, but windows
> > > isn't behaving for me right now. (I really do dislike working with
> > > microsoft) Hopefully I'll have this done soon.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> >
> > --
> > Pete
> >
> > -
> > 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]
> >
> >
>
>
> --
> Pete
>
> -
> 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]
>
>


-- 
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I've applied the latest patch and it looks good. I have added install
and clean targets for the xsd schema that get deployed.

I think the schema that are currently in tuscany/cpp/sca/xsd should be
moved to tuscany/cpp/sca/runtime/core/xsd which would be a more
logical place for them. I would also like to move the build.xml file
from tuscany/cpp/sca/runtime/core/src up one level to
tuscany/cpp/sca/runtime/core.

What do you think?

Cheers,

On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I updated yet another patch which includes the following changes:
>
> - compile_targets.xml added  which calls
> .
>  This fixes the case for windows where *.lib needs to go in lib/ and
> *.dll in bin/
> - system.xml added targets:
>  , , , ,
> 
>  These are called by the extension compile, link, and install targets
> to check
>  if the respective extensions have been enabled.
> - Added export definitions for Windows extension compilations.
> - Added dependant libraries to extension link targets.
>
>
> I think this should pretty much cover everything except the samples.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 26, 2007 12:44 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> More good stuff. I've applied the latest patch but there are some
> issues.
>
> From a clean build if you just type "ant" in the top level cpp/sca
> directory then the build will fail on tuscany_sca_cpp because it needs
> to link against /lib/tuscany_sca.dll which has not yet been
> installed as all the "build" targets are run recursively before the
> "install" targets.
>
> I also get a lot of unresolved references on windows when linking the
> tuscany_sca_cpp which I will look into.
>
> Cheers,
>
> On 25/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I just uploaded patch update 5 which includes the following:
> >
> > - runtime/extensions/php/build.xml
> > - minor change to php code so that it compiles
> > - compile-targets.xml added cpp-link-core which does not link in the
> > tuscany_sca lib and changed cpp-link so that it does link it in.
> >
> > I'm working on the windows exports for the extensions, but windows
> > isn't behaving for me right now. (I really do dislike working with
> > microsoft) Hopefully I'll have this done soon.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
>
> --
> Pete
>
> -
> 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]
>
>


-- 
Pete

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

Re: [SCA Native] Test suite

[Pete Robbins]

I'm sure this has come up before. I will try and find out what the
resolution was.

On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


As I understand it, the only issue would be if we distribute LPGL
software under the ASF licensing. What if we don't distribute CxxTest
with Tuscany, but rather request that users download it if they want to
run the tests?



Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

-Original Message-
From: Luciano Resende [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 5:01 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Test suite

I'd recommend checking if there are any issues with it's licensing, a
quick look at CxxTest website [1] mention that it's available under
LGPL, and that's not ASF friendly.

[1] http://cxxtest.sourceforge.net/

On 7/23/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> I understand that the current TuscanySCA Native test suite is not
> maintained. I have tried to use it recently and it doesnt even
compile.
> I'd like to start creating a new test suite, starting with the
> changes/patches that I've uploaded. Its not real clear what unit test
> framework was used, would there be any objections to me using CxxTest?
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [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]





--
Pete

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

Re: [SCA Native] next release content [was: Tuscany roadmap]

[Pete Robbins]

That looks good. I think there is more than enough in that list to
justify a release. My priorities would be:
1) upgrade to the sca 1.0 spec levels (assembly and cpp).
2) build system move to ant
(enough there for a release)

We should discuss your ideas for the rearchitecture of the data model.
It sounds like a good idea so maybe we can flesh out a proposal for
that.

Cheers,

On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:



Hello all,

I created a wiki page detailing the TuscanySCA Native Next Release
Contents, which will probably be called M4.


http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R
elease+Contents


Can I get some feedback on the items listed there. Also, what's the
Apache procedure to start planning and implementing the changes?



Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 12, 2007 11:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] next release content [was: Tuscany roadmap]

On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I forgot to mention another one in my previous post:
> - get the test suite up to date and working. I don't like making
> changes to code without running a good unit/basic test suite.

We do not have ANY test suite. I run through the samples to test
changes. The code under tuscany/cpp/sca/test is not maintained and
should probably be discarded. I think we need to build up a unit test
suite and would welcome suggestions on how to start this (use
cppunit?)

>
> I can start a separate thread for the ant vs make discussion.
> Basically, I think it would be easier to simplify the build process
> using make. I've looked through some of the makefiles and they're
> horrendous. :)

Let's discuss it here then. We need to be able to build from source on
windows, linux and Mac. On Windows we settled on MSVC 8 so it can build
with the free studio express. For linux we settled on automake as it
seemed to be fairly standard for C/C++ open source projects. In doing
this I had to learn automake and learnt to hate it ;-)  ... and as you
say some of the makefiles are ugly. If you believe an ant based build
would be better then I'll happily go along with that. Perhaps you could
start this off by showing us what the build would look like for, say,
cpp/sca/runtime/core ??

>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 12, 2007 9:53 AM
> To: tuscany-dev@ws.apache.org
> Subject: [SCA Native] next release content [was: Tuscany roadmap]
>
> We should definitely start planning some content for the next SCA
> Native release.
>
> On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Is there some sort of TuscanySCA roadmap? I've looked around a bit
> > and
>
> > haven't found one. I was curious what the future plans for
> > TuscanySCA CPP were in particular. I have a few ideas and I was
> > curious if they had been contemplated yet.
> >
> > - Move from Assembly Model 0.96 to 1.0
> Definitely. We also need to move the CPP extension to the 1.0 C++ C&I
> spec version
>
> > - Move to ant instead of make
> I need to understand this proposal a little better. Can you elaborate?
> Probably worth starting a separate thread to discuss this. I'm all for

> simplifying the build though!
>
> > - Remove runtime dependancy on model data structure (slight changes
> > to
>
> > data/model shouldnt affect runtime usage)
> ok
>
> > - Support additional WSDL bindings: RPC, DOC encoded...
> sounds good.
>
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
>
> Cheers,
>
> --
> Pete
>
> -
> 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]
>
>


--
Pete

-
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]





--
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

More good stuff. I've applied the latest patch but there are some issues.


From a clean build if you just type "ant" in the top level cpp/sca

directory then the build will fail on tuscany_sca_cpp because it needs
to link against /lib/tuscany_sca.dll which has not yet
been installed as all the "build" targets are run recursively before
the "install" targets.

I also get a lot of unresolved references on windows when linking the
tuscany_sca_cpp which I will look into.

Cheers,

On 25/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I just uploaded patch update 5 which includes the following:

- runtime/extensions/php/build.xml
- minor change to php code so that it compiles
- compile-targets.xml added cpp-link-core which does not link in the
tuscany_sca lib and changed cpp-link so that it does link it in.

I'm working on the windows exports for the extensions, but windows isn't
behaving for me right now. (I really do dislike working with microsoft)
Hopefully I'll have this done soon.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]




--
Pete

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

[jira] Resolved: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1478.
---

   Resolution: Fixed
Fix Version/s: Cpp-Next

Patch applied to HEAD and the sdo-cpp-pre2.1 branch

> For schemas with elementFormDefault=true, serialized instance documents are 
> invalid
> ---
>
> Key: TUSCANY-1478
> URL: https://issues.apache.org/jira/browse/TUSCANY-1478
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
> Environment: all
>Reporter: Michael Yoder
> Fix For: Cpp-Next
>
> Attachments: TUSCANY-1478.txt
>
>
> This appears to be a regression in XML serialization. The SCA CppBigBank 
> example is currently failing to get a response from the StockQuote service 
> due to sending an invalid request. 
> Using the XML Schema embedded in "StockQuoteService.wsdl", the following code:
> DataFactoryPtr mdg  = DataFactory::getDataFactory();
> XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
> xsh->defineFile("StockQuoteService.wsdl");
> DataObjectPtr doObj = mdg->create("http://swanandmokashi.com";,
>   "GetQuotes");
> doObj->setCString("QuoteTicker", "IBM");
> XMLHelperPtr xmlHelper = HelperProvider::getXMLHelper(mdg);
> XMLDocumentPtr doc = 
>   xmlHelper->createDocument(doObj,
> "http://swanandmokashi.com";,
> "GetQuotes");
> xmlHelper->save(doc, "out.xml");
> Will produce the invalid instance document:
> 
> http://swanandmokashi.com"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>IBM
> The element "QuoteTicker" should be namespace qualified.

-- 
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: FW: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid

[Pete Robbins]

I'm looking at it right now!

On 25/07/07, Michael Yoder <[EMAIL PROTECTED]> wrote:


Hi,

I uploaded a patch for C++ SDO which fixes its XML serialization to
produce XML valid against schemas with elementFormDefault=true. If
someone could verify and apply it that would be great. This gets the SCA
sample CppBigBank working again.

Thanks,

Michael
Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer -
HydraSDO

-Original Message-
From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 24, 2007 2:22 PM
To: tuscany-dev@ws.apache.org
Subject: [jira] Updated: (TUSCANY-1478) For schemas with
elementFormDefault=true, serialized instance documents are invalid


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

Michael Yoder updated TUSCANY-1478:
---

   Attachment: TUSCANY-1478.txt

This patch resolves the issue and adds a unit test.

> For schemas with elementFormDefault=true, serialized instance
> documents are invalid
> --
> -
>
> Key: TUSCANY-1478
> URL:
https://issues.apache.org/jira/browse/TUSCANY-1478
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
> Environment: all
>Reporter: Michael Yoder
> Attachments: TUSCANY-1478.txt
>
>
> This appears to be a regression in XML serialization. The SCA
CppBigBank example is currently failing to get a response from the
StockQuote service due to sending an invalid request.
> Using the XML Schema embedded in "StockQuoteService.wsdl", the
following code:
> DataFactoryPtr mdg  = DataFactory::getDataFactory();
> XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg);
> xsh->defineFile("StockQuoteService.wsdl");
> DataObjectPtr doObj = mdg->create("http://swanandmokashi.com";,
>   "GetQuotes");
> doObj->setCString("QuoteTicker", "IBM");
> XMLHelperPtr xmlHelper = HelperProvider::getXMLHelper(mdg);
> XMLDocumentPtr doc =
>   xmlHelper->createDocument(doObj,
> "http://swanandmokashi.com";,
> "GetQuotes");
> xmlHelper->save(doc, "out.xml"); Will produce the invalid
> instance document:
>   xmlns:tns="http://swanandmokashi.com";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>IBM
>  The element "QuoteTicker" should be
> namespace qualified.

--
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]


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





--
Pete

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

[jira] Resolved: (TUSCANY-1425) Compile failure on Fedora 6

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1425.
---

   Resolution: Fixed
Fix Version/s: Cpp-Next

Compile error fixed in branch and head

Warning fixed in TypeImpl.cpp as per patch

> Compile failure on Fedora 6
> ---
>
> Key: TUSCANY-1425
> URL: https://issues.apache.org/jira/browse/TUSCANY-1425
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: Fedora 6
>Reporter: Caroline Maynard
>Priority: Critical
> Fix For: Cpp-Next
>
> Attachments: tuscany-1425.patch
>
>
> A PHP user reports a compile failure on Fedora 6. The attached change to 
> SDOSchemaSAX2Parser.hsorts it, and seems benign on Win. 
> FWIW, I also attach a fix for a compiler warning in TypeImpl.cpp.
> The patch is against the pre-2.1 branch, which we're currently using for PHP, 
> but should be applied against the trunk too, please.

-- 
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: [SCA Native] SDO Build error on Linux

[Pete Robbins]

The fix is in the branch as well. Sorry I did not see that Jira.

On 25/07/07, Caroline Maynard <[EMAIL PROTECTED]> wrote:



Jean-Sebastien Delfino wrote:
> Trying to build Native/C++ SDO on Linux RHEL5 gives me this error:
>
> if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++
> -DHAVE_CONFIG_H -I. -I. -I../../../../..
> -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2
> -g -O0 -MT HelperProvider.lo -MD -MP -MF ".deps/HelperProvider.Tpo" -c
> -o HelperProvider.lo HelperProvider.cpp; \
>then mv -f ".deps/HelperProvider.Tpo" ".deps/HelperProvider.Plo";
> else rm -f ".deps/HelperProvider.Tpo"; exit 1; fi
> g++ -DHAVE_CONFIG_H -I. -I. -I../../../../..
> -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g
> -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c
> HelperProvider.cpp  -fPIC -DPIC -o .libs/HelperProvider.o
> ../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88:
> error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on
> member 'parseURI'
>
> Any idea?
>

It's very likely that this is the same as
http://issues.apache.org/jira/browse/TUSCANY-1425, which has been
sitting around for a while. Just a reminder, we do need this in the
branch as well, please.


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





--
Pete

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

Re: [SCA Native] SDO Build error on Linux

[Pete Robbins]

Works fine on all our linuxes including my RHEL... I've removed the
unnecessary qualifier so you should be fine now.

Cheers,

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

Trying to build Native/C++ SDO on Linux RHEL5 gives me this error:

if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I. -I../../../../..
-I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2
-g -O0 -MT HelperProvider.lo -MD -MP -MF ".deps/HelperProvider.Tpo" -c
-o HelperProvider.lo HelperProvider.cpp; \
   then mv -f ".deps/HelperProvider.Tpo"
".deps/HelperProvider.Plo"; else rm -f ".deps/HelperProvider.Tpo"; exit
1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../../../..
-I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g
-O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c
HelperProvider.cpp  -fPIC -DPIC -o .libs/HelperProvider.o
../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88:
error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on
member 'parseURI'
make[6]: *** [HelperProvider.lo] Error 1
make[6]: Leaving directory
`/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src/commonj/sdo'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
`/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src/commonj'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo'
make: *** [all] Error 2

Any idea?

--
Jean-Sebastien


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





--
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I've applied the patch. I'm having a few problems on Windows with my
environment I'm getting errors like:

compile.cpp.osoa:
  [cc] 2 total files to be compiled.
  [cc] CompositeContext.cpp
  [cc] 
D:\tuscanysvn\cpp\sca\runtime\extensions\cpp\src\osoa\sca\CompositeContext.cpp(44)
: warning C4273: 'osoa::sca::CompositeContext::CompositeContext' :
inconsistent dll linkage
  [cc]
D:\tuscanysvn\cpp\sca\runtime\extensions\cpp\src\osoa/sca/CompositeContext.h(86)
: see previous definition of '{ctor}'


I thought that the SCA_EXPORTS definition was causing this... but maybe not.

The PHP extension is not complete and was not included in the M3
release. What problems are you seeing getting it to build?

Cheers,

On 24/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I updated the jira1438 with update 4, which includes the following:
https://issues.apache.org/jira/browse/TUSCANY-1438

New build.xml files for the following
- runtime/extensions/python
- runtime/extensions/rest
- runtime/extensions/ruby

Moved -DSCA_EXPORT from Tuscany-BaseCompiler in system.xml and added it
to the runtime/core compilations

I'm working on php (which is the only one left for the source code) now,
but its giving me
problems, so it might take a while.



Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]



-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 24, 2007 7:52 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [SCA Native] preliminary ant build


That was the only drawback that I could see too. Each depot ought to be
basically stand-alone.

As for a top-level build.xml for all 3 projects, that would be very
simple and would not require any of the ant infrastructure used by the
individual projects. It would be very similar to the root build.xml for
TuscanySCA.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 11:30 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

A top level build in tuscany/cpp should be easy to do. I'm not sure we
should move (as Brady suggested) the common ant scripts up into
cpp/etc though. I think it's important that I can extract
tuscany/cpp/sdo, for example, and build it without using anything
outside of that tree.

Cheers,

On 24/07/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> Great idea, soon I will try to apply this idea to Native DAS and see
how it
> works. I think the idea could also be easily applied to Native SDO, as
it
> does not have too much dependencies and code generation as Native SCA
does.
>
> A folder ant-core could be created under tuscany/cpp/ folder to place
the
> ant scripts shared by the projects.
>
> Also, we could add a build.xml under tuscany/ccp/ that builds all 3
> subprojects at once, if the 3 to implement this ant build process.
What do
> you think?
>
> Regards,
> Adriano Crestani
>
> On 7/23/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> >
> > Correction, it should be like this:
> >
> >   
> >  > srcdir="${core.abs.dir}"
> > objdir="${lib.dir}"
> > infiles="${core.cpp.files}">
> >   
> > 
> >   
> > 
> >   
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 23, 2007 5:05 PM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [SCA Native] preliminary ant build
> >
> >
> > Pete,
> >
> > Good catch. That's an easy fix. I'll submit it with the next patch
> > tomorrow. Basically it involves removing SCA_EXPORTS from the
> > Tuscany-BaseCompiler and adding it to the runtime/core/src targets:
> > compile.core
> > compile.extension
> > compile.model
> > compile.util
> >
> > Like this:
> >   
> >  > srcdir="${core.abs.dir}"
> > objdir="${lib.dir}"
> > infiles="${core.cpp.files}"/>
> >   
> > 
> >   
> >   
> >
> > Tomorrow I'll have the python, ruby, rest, and maybe php extensions
> > complete.
> >
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> 

Re: [SCA Native] preliminary ant build

[Pete Robbins]

A top level build in tuscany/cpp should be easy to do. I'm not sure we
should move (as Brady suggested) the common ant scripts up into
cpp/etc though. I think it's important that I can extract
tuscany/cpp/sdo, for example, and build it without using anything
outside of that tree.

Cheers,

On 24/07/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:

Great idea, soon I will try to apply this idea to Native DAS and see how it
works. I think the idea could also be easily applied to Native SDO, as it
does not have too much dependencies and code generation as Native SCA does.

A folder ant-core could be created under tuscany/cpp/ folder to place the
ant scripts shared by the projects.

Also, we could add a build.xml under tuscany/ccp/ that builds all 3
subprojects at once, if the 3 to implement this ant build process. What do
you think?

Regards,
Adriano Crestani

On 7/23/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
>
> Correction, it should be like this:
>
>   
>  srcdir="${core.abs.dir}"
> objdir="${lib.dir}"
> infiles="${core.cpp.files}">
>   
> 
>   
> 
>   
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Brady Johnson [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 5:05 PM
> To: tuscany-dev@ws.apache.org
> Subject: RE: [SCA Native] preliminary ant build
>
>
> Pete,
>
> Good catch. That's an easy fix. I'll submit it with the next patch
> tomorrow. Basically it involves removing SCA_EXPORTS from the
> Tuscany-BaseCompiler and adding it to the runtime/core/src targets:
> compile.core
> compile.extension
> compile.model
> compile.util
>
> Like this:
>   
>  srcdir="${core.abs.dir}"
> objdir="${lib.dir}"
> infiles="${core.cpp.files}"/>
>   
> 
>   
>   
>
> Tomorrow I'll have the python, ruby, rest, and maybe php extensions
> complete.
>
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 2:41 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> I think there is a problem in the extension compilations. The
> SCA_EXPORTS directive should only be set when compiling the
> runtime/core. When compiling for dlls on windows which use the core dll
> SCA_EXPORTS must not be set. I guess this means we have to move the
> setting of this directive from the definition of the
> Tuscany-BaseCompiler
>
> Cheers,
>
> On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I've applied the patch. How are you creating the patches? I had
> > trouble applying it on Windows using ToirtoiseSVN.
> >
> > I've included the changes in the patch to the tools/TuscanyDriver
> > build. I haven't tested this and I'm not sure if it works with the
> > system.xml etc.
> >
> > Can you do a clean extract as a base for future patches?
> >
> > Cheers,
> >
> > On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'll give this a go. I should be able to run it on Mac as well.
> > >
> > > Cheers,
> > >
> > > On 23/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I updated the jira1438 with update 3, which includes the
> following:
> > > >https://issues.apache.org/jira/browse/TUSCANY-1438
> > > >
> > > >
> > > > - added build.xml for the following dirs:
> > > >runtime/extensions/build.xml
> > > >runtime/extensions/cpp/build.xml
> > > >runtime/extensions/sca/build.xml
> > > >runtime/extensions/ws/build.xml
> > > >
> > > > - changed system.xml to check for necessary axis, php, python,
> > > > rest, and ruby env vars. If they're not  set in the env, look for
> > > > them in platform.properties
> > > >
> > > > - changed compile-targets.xml targets
> > > > to 
> > > > to 
> > > >
> > > > - added compile-targets.xml target: 
> > > >
> > > > - added library versioning and the
> > > > platform.tuscanySCA.library.version
> > > > platform.properties property
> > > >
> > > >

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I think there is a problem in the extension compilations. The
SCA_EXPORTS directive should only be set when compiling the
runtime/core. When compiling for dlls on windows which use the core
dll SCA_EXPORTS must not be set. I guess this means we have to move
the setting of this directive from the definition of the
Tuscany-BaseCompiler

Cheers,

On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I've applied the patch. How are you creating the patches? I had
trouble applying it on Windows using ToirtoiseSVN.

I've included the changes in the patch to the tools/TuscanyDriver
build. I haven't tested this and I'm not sure if it works with the
system.xml etc.

Can you do a clean extract as a base for future patches?

Cheers,

On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'll give this a go. I should be able to run it on Mac as well.
>
> Cheers,
>
> On 23/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I updated the jira1438 with update 3, which includes the following:
> >https://issues.apache.org/jira/browse/TUSCANY-1438
> >
> >
> > - added build.xml for the following dirs:
> >runtime/extensions/build.xml
> >runtime/extensions/cpp/build.xml
> >runtime/extensions/sca/build.xml
> >runtime/extensions/ws/build.xml
> >
> > - changed system.xml to check for necessary axis, php, python, rest, and
> > ruby env vars. If they're not
> >  set in the env, look for them in platform.properties
> >
> > - changed compile-targets.xml targets
> > to 
> > to 
> >
> > - added compile-targets.xml target: 
> >
> > - added library versioning and the platform.tuscanySCA.library.version
> > platform.properties property
> >
> > Can someone submit this for me.
> >
> > The only thing left now is the build.xml for these extensions: php,
> > python, rest, ruby
> >
> > WRT testing on macs, I wont have a mac available until next week.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, July 19, 2007 8:23 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [SCA Native] preliminary ant build
> >
> >
> > I can look into testing it on Mac here. I believe we have several mac
> > machines for the purpose.
> >
> > I'll get back to you soon.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, July 19, 2007 2:44 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > I've taken out the references to tuscany_sca_config.h and patched the
> > automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac
> > as I need to kick the kids off my machine!
> >
> > On 19/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > Automake generates a config file with lots of standard stuff but the
> > > only  one we need is the IS_DARWIN, which is used in  2 places. I'll
> > > remove the 2 references to this header and change automale to set the
> > > IS_DARWIN compile flag.
> > >
> > > Cheers,
> > >
> > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I did the following diff command and got quite a lot of changes
> > > > (listed
> > > > below):
> > > >
> > > > # diff tuscany_sca_config.h.in tuscany_sca_config.h
> > > >
> > > > Are these not needed?
> > > >If not, I can get to work on removing all references to the
> > > > file.
> > > >If so, then we still need to figure out how to create the
> > file.
> > > >
> > > > I just realized, its 23:30, there... Go to bed! ;)
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA
> > > > Rogue Wave Software - [EMAIL PROTECTED]
> > > >
> > > >
> > > > 0a1
> > > > > /* tuscany_sca_config.h.  Generated by configure.  */
> > > > 4c5
> > > > < #undef CLOSEDIR_VOID
> > > > ---
> &

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I've applied the patch. How are you creating the patches? I had
trouble applying it on Windows using ToirtoiseSVN.

I've included the changes in the patch to the tools/TuscanyDriver
build. I haven't tested this and I'm not sure if it works with the
system.xml etc.

Can you do a clean extract as a base for future patches?

Cheers,

On 23/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I'll give this a go. I should be able to run it on Mac as well.

Cheers,

On 23/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I updated the jira1438 with update 3, which includes the following:
>https://issues.apache.org/jira/browse/TUSCANY-1438
>
>
> - added build.xml for the following dirs:
>runtime/extensions/build.xml
>runtime/extensions/cpp/build.xml
>runtime/extensions/sca/build.xml
>runtime/extensions/ws/build.xml
>
> - changed system.xml to check for necessary axis, php, python, rest, and
> ruby env vars. If they're not
>  set in the env, look for them in platform.properties
>
> - changed compile-targets.xml targets
> to 
> to 
>
> - added compile-targets.xml target: 
>
> - added library versioning and the platform.tuscanySCA.library.version
> platform.properties property
>
> Can someone submit this for me.
>
> The only thing left now is the build.xml for these extensions: php,
> python, rest, ruby
>
> WRT testing on macs, I wont have a mac available until next week.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Brady Johnson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 19, 2007 8:23 AM
> To: tuscany-dev@ws.apache.org
> Subject: RE: [SCA Native] preliminary ant build
>
>
> I can look into testing it on Mac here. I believe we have several mac
> machines for the purpose.
>
> I'll get back to you soon.
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 19, 2007 2:44 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> I've taken out the references to tuscany_sca_config.h and patched the
> automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac
> as I need to kick the kids off my machine!
>
> On 19/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > Automake generates a config file with lots of standard stuff but the
> > only  one we need is the IS_DARWIN, which is used in  2 places. I'll
> > remove the 2 references to this header and change automale to set the
> > IS_DARWIN compile flag.
> >
> > Cheers,
> >
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > I did the following diff command and got quite a lot of changes
> > > (listed
> > > below):
> > >
> > > # diff tuscany_sca_config.h.in tuscany_sca_config.h
> > >
> > > Are these not needed?
> > >If not, I can get to work on removing all references to the
> > > file.
> > >If so, then we still need to figure out how to create the
> file.
> > >
> > > I just realized, its 23:30, there... Go to bed! ;)
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > > 0a1
> > > > /* tuscany_sca_config.h.  Generated by configure.  */
> > > 4c5
> > > < #undef CLOSEDIR_VOID
> > > ---
> > > > /* #undef CLOSEDIR_VOID */
> > > 8c9
> > > < #undef HAVE_DIRENT_H
> > > ---
> > > > #define HAVE_DIRENT_H 1
> > > 11c12
> > > < #undef HAVE_DLFCN_H
> > > ---
> > > > #define HAVE_DLFCN_H 1
> > > 14c15
> > > < #undef HAVE_DOPRNT
> > > ---
> > > > /* #undef HAVE_DOPRNT */
> > > 17c18
> > > < #undef HAVE_GETCWD
> > > ---
> > > > #define HAVE_GETCWD 1
> > > 20c21
> > > < #undef HAVE_INTTYPES_H
> > > ---
> > > > #define HAVE_INTTYPES_H 1
> > > 23c24
> > > < #undef HAVE_MEMORY_H
> > > ---
> > > > #define HAVE_MEMORY_H 1
> > > 26c27
> > > < #undef HAVE_NDIR_H
> > > ---
> > > > /* #undef HAVE_NDIR_H */
> > > 29c30
> > &

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I'll give this a go. I should be able to run it on Mac as well.

Cheers,

On 23/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I updated the jira1438 with update 3, which includes the following:
   https://issues.apache.org/jira/browse/TUSCANY-1438


- added build.xml for the following dirs:
   runtime/extensions/build.xml
   runtime/extensions/cpp/build.xml
   runtime/extensions/sca/build.xml
   runtime/extensions/ws/build.xml

- changed system.xml to check for necessary axis, php, python, rest, and
ruby env vars. If they're not
 set in the env, look for them in platform.properties

- changed compile-targets.xml targets
to 
to 

- added compile-targets.xml target: 

- added library versioning and the platform.tuscanySCA.library.version
platform.properties property

Can someone submit this for me.

The only thing left now is the build.xml for these extensions: php,
python, rest, ruby

WRT testing on macs, I wont have a mac available until next week.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 8:23 AM
To: tuscany-dev@ws.apache.org
Subject: RE: [SCA Native] preliminary ant build


I can look into testing it on Mac here. I believe we have several mac
machines for the purpose.

I'll get back to you soon.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 2:44 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

I've taken out the references to tuscany_sca_config.h and patched the
automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac
as I need to kick the kids off my machine!

On 19/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> Automake generates a config file with lots of standard stuff but the
> only  one we need is the IS_DARWIN, which is used in  2 places. I'll
> remove the 2 references to this header and change automale to set the
> IS_DARWIN compile flag.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I did the following diff command and got quite a lot of changes
> > (listed
> > below):
> >
> > # diff tuscany_sca_config.h.in tuscany_sca_config.h
> >
> > Are these not needed?
> >If not, I can get to work on removing all references to the
> > file.
> >If so, then we still need to figure out how to create the
file.
> >
> > I just realized, its 23:30, there... Go to bed! ;)
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > 0a1
> > > /* tuscany_sca_config.h.  Generated by configure.  */
> > 4c5
> > < #undef CLOSEDIR_VOID
> > ---
> > > /* #undef CLOSEDIR_VOID */
> > 8c9
> > < #undef HAVE_DIRENT_H
> > ---
> > > #define HAVE_DIRENT_H 1
> > 11c12
> > < #undef HAVE_DLFCN_H
> > ---
> > > #define HAVE_DLFCN_H 1
> > 14c15
> > < #undef HAVE_DOPRNT
> > ---
> > > /* #undef HAVE_DOPRNT */
> > 17c18
> > < #undef HAVE_GETCWD
> > ---
> > > #define HAVE_GETCWD 1
> > 20c21
> > < #undef HAVE_INTTYPES_H
> > ---
> > > #define HAVE_INTTYPES_H 1
> > 23c24
> > < #undef HAVE_MEMORY_H
> > ---
> > > #define HAVE_MEMORY_H 1
> > 26c27
> > < #undef HAVE_NDIR_H
> > ---
> > > /* #undef HAVE_NDIR_H */
> > 29c30
> > < #undef HAVE_PUTENV
> > ---
> > > #define HAVE_PUTENV 1
> > 33c34
> > < #undef HAVE_STAT_EMPTY_STRING_BUG
> > ---
> > > /* #undef HAVE_STAT_EMPTY_STRING_BUG */
> > 36c37
> > < #undef HAVE_STDBOOL_H
> > ---
> > > #define HAVE_STDBOOL_H 1
> > 39c40
> > < #undef HAVE_STDINT_H
> > ---
> > > #define HAVE_STDINT_H 1
> > 42c43
> > < #undef HAVE_STDLIB_H
> > ---
> > > #define HAVE_STDLIB_H 1
> > 45c46
> > < #undef HAVE_STRDUP
> > ---
> > > #define HAVE_STRDUP 1
> > 48c49
> > < #undef HAVE_STRINGS_H
> > ---
> > > #define HAVE_STRINGS_H 1
> > 51c52
> > < #undef HAVE_STRING_H
> > ---
> > > #define HAVE_STRING_H 1
> > 55c56
> > < #undef HAVE_SYS_DIR_H
> > ---
> > > /* #undef HAVE_SYS_DIR_H */
> > 59c60
> > < #undef HAVE_SYS_NDIR_H
> > ---
> > > /* #undef HAVE_SYS_NDIR_

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I've taken out the references to tuscany_sca_config.h and patched the
automake for now with setting -DIS_DARWIN on mac. Yet to test it on
Mac as I need to kick the kids off my machine!

On 19/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

Automake generates a config file with lots of standard stuff but the
only  one we need is the IS_DARWIN, which is used in  2 places. I'll
remove the 2 references to this header and change automale to set the
IS_DARWIN compile flag.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I did the following diff command and got quite a lot of changes (listed
> below):
>
> # diff tuscany_sca_config.h.in tuscany_sca_config.h
>
> Are these not needed?
>If not, I can get to work on removing all references to the
> file.
>If so, then we still need to figure out how to create the file.
>
> I just realized, its 23:30, there... Go to bed! ;)
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> 0a1
> > /* tuscany_sca_config.h.  Generated by configure.  */
> 4c5
> < #undef CLOSEDIR_VOID
> ---
> > /* #undef CLOSEDIR_VOID */
> 8c9
> < #undef HAVE_DIRENT_H
> ---
> > #define HAVE_DIRENT_H 1
> 11c12
> < #undef HAVE_DLFCN_H
> ---
> > #define HAVE_DLFCN_H 1
> 14c15
> < #undef HAVE_DOPRNT
> ---
> > /* #undef HAVE_DOPRNT */
> 17c18
> < #undef HAVE_GETCWD
> ---
> > #define HAVE_GETCWD 1
> 20c21
> < #undef HAVE_INTTYPES_H
> ---
> > #define HAVE_INTTYPES_H 1
> 23c24
> < #undef HAVE_MEMORY_H
> ---
> > #define HAVE_MEMORY_H 1
> 26c27
> < #undef HAVE_NDIR_H
> ---
> > /* #undef HAVE_NDIR_H */
> 29c30
> < #undef HAVE_PUTENV
> ---
> > #define HAVE_PUTENV 1
> 33c34
> < #undef HAVE_STAT_EMPTY_STRING_BUG
> ---
> > /* #undef HAVE_STAT_EMPTY_STRING_BUG */
> 36c37
> < #undef HAVE_STDBOOL_H
> ---
> > #define HAVE_STDBOOL_H 1
> 39c40
> < #undef HAVE_STDINT_H
> ---
> > #define HAVE_STDINT_H 1
> 42c43
> < #undef HAVE_STDLIB_H
> ---
> > #define HAVE_STDLIB_H 1
> 45c46
> < #undef HAVE_STRDUP
> ---
> > #define HAVE_STRDUP 1
> 48c49
> < #undef HAVE_STRINGS_H
> ---
> > #define HAVE_STRINGS_H 1
> 51c52
> < #undef HAVE_STRING_H
> ---
> > #define HAVE_STRING_H 1
> 55c56
> < #undef HAVE_SYS_DIR_H
> ---
> > /* #undef HAVE_SYS_DIR_H */
> 59c60
> < #undef HAVE_SYS_NDIR_H
> ---
> > /* #undef HAVE_SYS_NDIR_H */
> 62c63
> < #undef HAVE_SYS_STAT_H
> ---
> > #define HAVE_SYS_STAT_H 1
> 65c66
> < #undef HAVE_SYS_TIME_H
> ---
> > #define HAVE_SYS_TIME_H 1
> 68c69
> < #undef HAVE_SYS_TYPES_H
> ---
> > #define HAVE_SYS_TYPES_H 1
> 71c72
> < #undef HAVE_UNISTD_H
> ---
> > #define HAVE_UNISTD_H 1
> 74c75
> < #undef HAVE_VPRINTF
> ---
> > #define HAVE_VPRINTF 1
> 77c78
> < #undef HAVE__BOOL
> ---
> > #define HAVE__BOOL 1
> 80c81
> < #undef IS_DARWIN
> ---
> > /* #undef IS_DARWIN */
> 84c85
> < #undef LSTAT_FOLLOWS_SLASHED_SYMLINK
> ---
> > #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
> 87c88
> < #undef PACKAGE
> ---
> > #define PACKAGE "tuscany_sca_native"
> 90c91
> < #undef PACKAGE_BUGREPORT
> ---
> > #define PACKAGE_BUGREPORT ""
> 93c94
> < #undef PACKAGE_NAME
> ---
> > #define PACKAGE_NAME "tuscany_sca_native"
> 96c97
> < #undef PACKAGE_STRING
> ---
> > #define PACKAGE_STRING "tuscany_sca_native 1.0-incubator-M3"
> 99c100
> < #undef PACKAGE_TARNAME
> ---
> > #define PACKAGE_TARNAME "tuscany_sca_native"
> 102c103
> < #undef PACKAGE_VERSION
> ---
> > #define PACKAGE_VERSION "1.0-incubator-M3"
> 105c106
> < #undef STDC_HEADERS
> ---
> > #define STDC_HEADERS 1
> 108c109
> < #undef VERSION
> ---
> > #define VERSION "1.0-incubator-M3"
> 111c112
> < #undef const
> ---
> > /* #undef const */
> 116c117
> < #undef inline
> ---
> > /* #undef inline */
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 4:22 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> yeah I figured that... I did exactly the same when committing changes
> earlier! I dodn't commit the changes inthe tools folder.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I wasn't aware

Re: [SCA Native] preliminary ant build

[Pete Robbins]

Automake generates a config file with lots of standard stuff but the
only  one we need is the IS_DARWIN, which is used in  2 places. I'll
remove the 2 references to this header and change automale to set the
IS_DARWIN compile flag.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I did the following diff command and got quite a lot of changes (listed
below):

# diff tuscany_sca_config.h.in tuscany_sca_config.h

Are these not needed?
   If not, I can get to work on removing all references to the
file.
   If so, then we still need to figure out how to create the file.

I just realized, its 23:30, there... Go to bed! ;)


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


0a1
> /* tuscany_sca_config.h.  Generated by configure.  */
4c5
< #undef CLOSEDIR_VOID
---
> /* #undef CLOSEDIR_VOID */
8c9
< #undef HAVE_DIRENT_H
---
> #define HAVE_DIRENT_H 1
11c12
< #undef HAVE_DLFCN_H
---
> #define HAVE_DLFCN_H 1
14c15
< #undef HAVE_DOPRNT
---
> /* #undef HAVE_DOPRNT */
17c18
< #undef HAVE_GETCWD
---
> #define HAVE_GETCWD 1
20c21
< #undef HAVE_INTTYPES_H
---
> #define HAVE_INTTYPES_H 1
23c24
< #undef HAVE_MEMORY_H
---
> #define HAVE_MEMORY_H 1
26c27
< #undef HAVE_NDIR_H
---
> /* #undef HAVE_NDIR_H */
29c30
< #undef HAVE_PUTENV
---
> #define HAVE_PUTENV 1
33c34
< #undef HAVE_STAT_EMPTY_STRING_BUG
---
> /* #undef HAVE_STAT_EMPTY_STRING_BUG */
36c37
< #undef HAVE_STDBOOL_H
---
> #define HAVE_STDBOOL_H 1
39c40
< #undef HAVE_STDINT_H
---
> #define HAVE_STDINT_H 1
42c43
< #undef HAVE_STDLIB_H
---
> #define HAVE_STDLIB_H 1
45c46
< #undef HAVE_STRDUP
---
> #define HAVE_STRDUP 1
48c49
< #undef HAVE_STRINGS_H
---
> #define HAVE_STRINGS_H 1
51c52
< #undef HAVE_STRING_H
---
> #define HAVE_STRING_H 1
55c56
< #undef HAVE_SYS_DIR_H
---
> /* #undef HAVE_SYS_DIR_H */
59c60
< #undef HAVE_SYS_NDIR_H
---
> /* #undef HAVE_SYS_NDIR_H */
62c63
< #undef HAVE_SYS_STAT_H
---
> #define HAVE_SYS_STAT_H 1
65c66
< #undef HAVE_SYS_TIME_H
---
> #define HAVE_SYS_TIME_H 1
68c69
< #undef HAVE_SYS_TYPES_H
---
> #define HAVE_SYS_TYPES_H 1
71c72
< #undef HAVE_UNISTD_H
---
> #define HAVE_UNISTD_H 1
74c75
< #undef HAVE_VPRINTF
---
> #define HAVE_VPRINTF 1
77c78
< #undef HAVE__BOOL
---
> #define HAVE__BOOL 1
80c81
< #undef IS_DARWIN
---
> /* #undef IS_DARWIN */
84c85
< #undef LSTAT_FOLLOWS_SLASHED_SYMLINK
---
> #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
87c88
< #undef PACKAGE
---
> #define PACKAGE "tuscany_sca_native"
90c91
< #undef PACKAGE_BUGREPORT
---
> #define PACKAGE_BUGREPORT ""
93c94
< #undef PACKAGE_NAME
---
> #define PACKAGE_NAME "tuscany_sca_native"
96c97
< #undef PACKAGE_STRING
---
> #define PACKAGE_STRING "tuscany_sca_native 1.0-incubator-M3"
99c100
< #undef PACKAGE_TARNAME
---
> #define PACKAGE_TARNAME "tuscany_sca_native"
102c103
< #undef PACKAGE_VERSION
---
> #define PACKAGE_VERSION "1.0-incubator-M3"
105c106
< #undef STDC_HEADERS
---
> #define STDC_HEADERS 1
108c109
< #undef VERSION
---
> #define VERSION "1.0-incubator-M3"
111c112
< #undef const
---
> /* #undef const */
116c117
< #undef inline
---
> /* #undef inline */


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 4:22 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

yeah I figured that... I did exactly the same when committing changes
earlier! I dodn't commit the changes inthe tools folder.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Ok, I wasn't aware that I had changed the tools.
>
> I simply did a "svn diff . > patch_file" from the tuscany root dir.
> You can disregard the tools changes. I'll look into it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 4:16 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> Cool! I've applied this change as well. The update2 patch contained
> changes to the tools/TuscanyDriver/build.xml. This doesn't work so you

> may want to look at it.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > If that's all we need the tuscany_sca_config.h file for then, yes
> > this
>
> > just got a whole lot easier. We can do the following on the
> > Tuscany-BaseCompiler
> >
> >  
> >
> >  
> >
> >   > exceptions="tr

Re: [SCA Native] preliminary ant build

[Pete Robbins]

yeah I figured that... I did exactly the same when committing changes
earlier! I dodn't commit the changes inthe tools folder.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Ok, I wasn't aware that I had changed the tools.

I simply did a "svn diff . > patch_file" from the tuscany root dir. You
can disregard the tools changes. I'll look into it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-----Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 4:16 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> If that's all we need the tuscany_sca_config.h file for then, yes this

> just got a whole lot easier. We can do the following on the
> Tuscany-BaseCompiler
>
>  
>
>  
>
>   exceptions="true" rtti="true">
> define="WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS"/>
>
>
> 
>
>
>  
>
> --------
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 3:41 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I uploaded a patch on top of what you submit to svn.
> >
> > Here is a description of what I changed:
> >
> > - Changed the name of compilers.xml to system.xml.
> >
> > - This update has better support for a platform.properties file that

> > is completely empty.
> >  That is, all of the platform dependent items are figured out by
ant.
> > If they are set in
> >  the platform.properties file then they override the ant
> determination.
> >
> > - Better directory path management has been added to the root
> > build.xml and  runtime/core/src/build.xml files.
> >
> > - The install and clean targets in runtime/core/src have been
> completed.
> >
> >
> > With respect to your latest post regarding "tuscany-sca-config.h":
> > I knew this was a problem on clean systems and had envisioned either

> > running a script or using a slimmed down automake/configure to setup

> > this file and any platform specific parameters. That's certainly
> > something we'll have to address, what do you think?
> >
>
> The only reason we use this automake generated file is to set the
> IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a

> different technique in ant to set this flag. Is there a "family=mac"
> or somesuch in ant? The automake simply runs a 'uname -s' command to
> figure it out.
>
> I think a goal for this shoul be that I can do a clean extract from
> svn and type "ant" in the top level directory and it will build with
> everything defaulted. We need various pre-reqs defined (SDO loccation,
> + other pre-reqs) but we should try to make this as simple as
> possible.
>
> Cheers,
>
>
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:22 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > the install dir defaults to sca/deploy so I think we don't need any
> > properties other than overrides.
> >
> > I'll check in what I have. so youi can see.
> >
> > Cheers,
> >
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > That's a good idea. Then the only thing that really need to be set

> > > in platform.properties file would be:
> > >tuscanySCA.install.dir
> > >and any possible overides
> > >
> > > I'll put that together real quick and upload it.
> > >
> > > Thanks
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA Rogue Wave Software -
> > > [EMAIL PROTECTED]
> >

Re: [SCA Native] preliminary ant build

[Pete Robbins]

Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


If that's all we need the tuscany_sca_config.h file for then, yes this
just got a whole lot easier. We can do the following on the
Tuscany-BaseCompiler

 
   
 

 
   
   
   

   
   
 


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]

-Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 3:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I uploaded a patch on top of what you submit to svn.
>
> Here is a description of what I changed:
>
> - Changed the name of compilers.xml to system.xml.
>
> - This update has better support for a platform.properties file that
> is completely empty.
>  That is, all of the platform dependent items are figured out by ant.
> If they are set in
>  the platform.properties file then they override the ant
determination.
>
> - Better directory path management has been added to the root
> build.xml and  runtime/core/src/build.xml files.
>
> - The install and clean targets in runtime/core/src have been
completed.
>
>
> With respect to your latest post regarding "tuscany-sca-config.h":
> I knew this was a problem on clean systems and had envisioned either
> running a script or using a slimmed down automake/configure to setup
> this file and any platform specific parameters. That's certainly
> something we'll have to address, what do you think?
>

The only reason we use this automake generated file is to set the
IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a
different technique in ant to set this flag. Is there a "family=mac"
or somesuch in ant? The automake simply runs a 'uname -s' command to
figure it out.

I think a goal for this shoul be that I can do a clean extract from svn
and type "ant" in the top level directory and it will build with
everything defaulted. We need various pre-reqs defined (SDO loccation,
+ other pre-reqs) but we should try to make this as simple as
possible.

Cheers,


>
> --------
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:22 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> the install dir defaults to sca/deploy so I think we don't need any
> properties other than overrides.
>
> I'll check in what I have. so youi can see.
>
> Cheers,
>
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > That's a good idea. Then the only thing that really need to be set
> > in platform.properties file would be:
> >tuscanySCA.install.dir
> >    and any possible overides
> >
> > I'll put that together real quick and upload it.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 9:00 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > Thanks for trying out the ant build scripts.
> > > >
> > > > Regarding core.dir, you're right, the name will need to change.
> > > > I can do that no problem.
> > > >
> > > > As for the "tuscanySCA.root.dir" : Your suggestion will work if
> > > > you only execute ant from the root directory, but not if you
> > > > execute ant
> >
> > > > from the runtime/core/src directory. That's why I put it in the
> > > > platform.properties, which is accessed by all build.xml's. Its
> > > > better ant coding style to have anything that needs to be
> > > > configured
> >
> > > > in a properties file, not in an ant build.xml file.
> > > >
> > >
> > > Yes... I realized that would limit

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


I uploaded a patch on top of what you submit to svn.

Here is a description of what I changed:

- Changed the name of compilers.xml to system.xml.

- This update has better support for a platform.properties file that is
completely empty.
 That is, all of the platform dependent items are figured out by ant.
If they are set in
 the platform.properties file then they override the ant determination.

- Better directory path management has been added to the root build.xml
and
 runtime/core/src/build.xml files.

- The install and clean targets in runtime/core/src have been completed.


With respect to your latest post regarding "tuscany-sca-config.h":
I knew this was a problem on clean systems and had envisioned either
running a script or using a slimmed down automake/configure to setup
this file and any platform specific parameters. That's certainly
something we'll have to address, what do you think?



The only reason we use this automake generated file is to set the
IS_DARWIN compiler flag for running on Mac OS X. I expect we can use a
different technique in ant to set this flag. Is there a "family=mac"
or somesuch in ant? The automake simply runs a 'uname -s' command to
figure it out.

I think a goal for this shoul be that I can do a clean extract from
svn and type "ant" in the top level directory and it will build with
everything defaulted. We need various pre-reqs defined (SDO loccation,
+ other pre-reqs) but we should try to make this as simple as
possible.

Cheers,





Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 9:22 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> That's a good idea. Then the only thing that really need to be set in
> platform.properties file would be:
>tuscanySCA.install.dir
>and any possible overides
>
> I'll put that together real quick and upload it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:00 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > Thanks for trying out the ant build scripts.
> > >
> > > Regarding core.dir, you're right, the name will need to change. I
> > > can do that no problem.
> > >
> > > As for the "tuscanySCA.root.dir" : Your suggestion will work if
> > > you only execute ant from the root directory, but not if you
> > > execute ant
>
> > > from the runtime/core/src directory. That's why I put it in the
> > > platform.properties, which is accessed by all build.xml's. Its
> > > better ant coding style to have anything that needs to be
> > > configured
>
> > > in a properties file, not in an ant build.xml file.
> > >
> >
> > Yes... I realized that would limit you to running ant from the top
> > level. So, as most of the info in platform.properties can be deduced

> > would a better solution be to have a top level (or in antscripts
> > dir) platform-properties.xml that
> >  a) imports platform.properties for any overrides
> >  b) sets the properties conditional on the platform.
> >
> > e.g.
> >  
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
>
> the build.xml files would all import this top level file:
>
>
> > > As for the platform.properties file for windows:
> > > The property platform can/should be removed, its not necessary. If

> > > the property "platform.compiler-definition" is set, then that
> > > value will be used for the compiler selection, else it will get
> > > set to msvc for windows as can be seen on line 18 of
compilers.xml.
> > >
> > > I think the way this should ship is to have several
> > > platform.properties files for the different platform:
> > >    platfor

Re: [SCA Native] preliminary ant build

[Pete Robbins]

There is a problem now with this build on a clean system.
tuscany-sca-config.h is a header generated by automake that contains
directives (IS_DARWIN for example). We will need to have the ant build
set compiler options for our conditional compiles instead of this.

Cheers,

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> That's a good idea. Then the only thing that really need to be set in
> platform.properties file would be:
>tuscanySCA.install.dir
>and any possible overides
>
> I'll put that together real quick and upload it.
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 9:00 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > Thanks for trying out the ant build scripts.
> > >
> > > Regarding core.dir, you're right, the name will need to change. I
> > > can do that no problem.
> > >
> > > As for the "tuscanySCA.root.dir" : Your suggestion will work if you
> > > only execute ant from the root directory, but not if you execute ant
>
> > > from the runtime/core/src directory. That's why I put it in the
> > > platform.properties, which is accessed by all build.xml's. Its
> > > better ant coding style to have anything that needs to be configured
>
> > > in a properties file, not in an ant build.xml file.
> > >
> >
> > Yes... I realized that would limit you to running ant from the top
> > level. So, as most of the info in platform.properties can be deduced
> > would a better solution be to have a top level (or in antscripts dir)
> > platform-properties.xml that
> >  a) imports platform.properties for any overrides
> >  b) sets the properties conditional on the platform.
> >
> > e.g.
> >  
> >
> >  
> >  
> >
> >  
> >  
> >
> >  
> >
>
> the build.xml files would all import this top level file:
>
>
> > > As for the platform.properties file for windows:
> > > The property platform can/should be removed, its not necessary. If
> > > the property "platform.compiler-definition" is set, then that value
> > > will be used for the compiler selection, else it will get set to
> > > msvc for windows as can be seen on line 18 of compilers.xml.
> > >
> > > I think the way this should ship is to have several
> > > platform.properties files for the different platform:
> > >platform.properties.linux
> > >platform.properties.windows
> > >platform.properties.mac
> > > Which will each have values pre configured for the corresponding
> > > platform. Then with either configure or a shell script, the platform
>
> > > file wil be copied to platform.properties and the directory
> > > properties will be set accordingly.
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > > -Original Message-
> > > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, July 18, 2007 7:08 AM
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [SCA Native] preliminary ant build
> > >
> > > I ran into a couple of issues tryingt o run this ant build. Firstly
> > > I got an error with a path
> > > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down
> > > to the fact that the property core.dir is set in the top level
> > > build.xml to "runtime/core/src" and in the
> > > runtime/core/src/build.xml the same property name is used and set tu
>
> > > "tuscany/sca/core". It looks to me like the second defintion of
> > > core.dir is being ignored. I'm not an ant expert ... do properties
> get propagated from higher level build files?
> > > I g

Re: [SCA Native] preliminary ant build

[Pete Robbins]

the install dir defaults to sca/deploy so I think we don't need any
properties other than overrides.

I'll check in what I have. so youi can see.

Cheers,

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

That's a good idea. Then the only thing that really need to be set in
platform.properties file would be:
   tuscanySCA.install.dir
   and any possible overides

I'll put that together real quick and upload it.

Thanks


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 9:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > Thanks for trying out the ant build scripts.
> >
> > Regarding core.dir, you're right, the name will need to change. I
> > can do that no problem.
> >
> > As for the "tuscanySCA.root.dir" : Your suggestion will work if you
> > only execute ant from the root directory, but not if you execute ant

> > from the runtime/core/src directory. That's why I put it in the
> > platform.properties, which is accessed by all build.xml's. Its
> > better ant coding style to have anything that needs to be configured

> > in a properties file, not in an ant build.xml file.
> >
>
> Yes... I realized that would limit you to running ant from the top
> level. So, as most of the info in platform.properties can be deduced
> would a better solution be to have a top level (or in antscripts dir)
> platform-properties.xml that
>  a) imports platform.properties for any overrides
>  b) sets the properties conditional on the platform.
>
> e.g.
>  
>
>  
>  
>
>  
>  
>
>  
>

the build.xml files would all import this top level file:


> > As for the platform.properties file for windows:
> > The property platform can/should be removed, its not necessary. If
> > the property "platform.compiler-definition" is set, then that value
> > will be used for the compiler selection, else it will get set to
> > msvc for windows as can be seen on line 18 of compilers.xml.
> >
> > I think the way this should ship is to have several
> > platform.properties files for the different platform:
> >platform.properties.linux
> >platform.properties.windows
> >platform.properties.mac
> > Which will each have values pre configured for the corresponding
> > platform. Then with either configure or a shell script, the platform

> > file wil be copied to platform.properties and the directory
> > properties will be set accordingly.
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 18, 2007 7:08 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > I ran into a couple of issues tryingt o run this ant build. Firstly
> > I got an error with a path
> > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down
> > to the fact that the property core.dir is set in the top level
> > build.xml to "runtime/core/src" and in the
> > runtime/core/src/build.xml the same property name is used and set tu

> > "tuscany/sca/core". It looks to me like the second defintion of
> > core.dir is being ignored. I'm not an ant expert ... do properties
get propagated from higher level build files?
> > I got around this by changing the name of core.dir to src.dir in one

> > of the files.
> >
> > Rather than specifying the paths to the source code etc in the
> > platform.properties I would prefer to set these automatically so in
> > the top level build.xml I added:
> >
> > 
> >
> > and then based other properties from this. It seemed to work!
> >
> > Do these changes make sense?
> >
> > Cheers,
> >
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'd like some info on what I need to edit in the
platform.properties.
> > > Particularly:
> > >
> > > platform.compiler-definition=g++m32
> > > platform=rhas4u4_gcc346
> > >
> > > One good thing about automake is that it detect

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> Thanks for trying out the ant build scripts.
>
> Regarding core.dir, you're right, the name will need to change. I can do
> that no problem.
>
> As for the "tuscanySCA.root.dir" : Your suggestion will work if you only
> execute ant from the root directory, but not if you execute ant from the
> runtime/core/src directory. That's why I put it in the
> platform.properties, which is accessed by all build.xml's. Its better
> ant coding style to have anything that needs to be configured in a
> properties file, not in an ant build.xml file.
>

Yes... I realized that would limit you to running ant from the top
level. So, as most of the info in platform.properties can be deduced
would a better solution be to have a top level (or in antscripts dir)
platform-properties.xml that
 a) imports platform.properties for any overrides
 b) sets the properties conditional on the platform.

e.g.
 
   
 
 
   
 
 
   
 



the build.xml files would all import this top level file:



> As for the platform.properties file for windows:
> The property platform can/should be removed, its not necessary. If the
> property "platform.compiler-definition" is set, then that value will be
> used for the compiler selection, else it will get set to msvc for
> windows as can be seen on line 18 of compilers.xml.
>
> I think the way this should ship is to have several platform.properties
> files for the different platform:
>platform.properties.linux
>platform.properties.windows
>platform.properties.mac
> Which will each have values pre configured for the corresponding
> platform. Then with either configure or a shell script, the platform
> file wil be copied to platform.properties and the directory properties
> will be set accordingly.
>
> ----
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 7:08 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> I ran into a couple of issues tryingt o run this ant build. Firstly I
> got an error with a path
> x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
> the fact that the property core.dir is set in the top level build.xml to
> "runtime/core/src" and in the runtime/core/src/build.xml the same
> property name is used and set tu "tuscany/sca/core". It looks to me like
> the second defintion of core.dir is being ignored. I'm not an ant expert
> ... do properties get propagated from higher level build files?
> I got around this by changing the name of core.dir to src.dir in one of
> the files.
>
> Rather than specifying the paths to the source code etc in the
> platform.properties I would prefer to set these automatically so in the
> top level build.xml I added:
>
> 
>
> and then based other properties from this. It seemed to work!
>
> Do these changes make sense?
>
> Cheers,
>
>
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I'd like some info on what I need to edit in the platform.properties.
> > Particularly:
> >
> > platform.compiler-definition=g++m32
> > platform=rhas4u4_gcc346
> >
> > One good thing about automake is that it detects your
> > platform/compiler etc automatically.
> >
> > Cheers,
> >
> >
> > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > Pete,
> > >
> > > I put together some documentation for using ant with TuscanySCA
> Native.
> > >
> > > How's this?
> > >
> > > 
> > > Brady Johnson
> > > Lead Software Developer - HydraSCA
> > > Rogue Wave Software - [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > Using ant to build TuscanySCA Native
> > >
> > >
> > >
> > > 1. Required Software to build TuscanySCA Native with ant:
> > >
> > > Ant:
> > >Ant comes installed with almost all Linux distributions
> > >version 1.6 or later
> > >Download: http://ant.apache.org/
> > >
> > > antcontrib:
> > >version 1.0b3 or later
> > >Download: http://ant-contrib.sourceforge.net/
> > >
> > > antcontrib cpptasks.jar
> > >version 1.0b4 or later
> >

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

Thanks for trying out the ant build scripts.

Regarding core.dir, you're right, the name will need to change. I can do
that no problem.

As for the "tuscanySCA.root.dir" : Your suggestion will work if you only
execute ant from the root directory, but not if you execute ant from the
runtime/core/src directory. That's why I put it in the
platform.properties, which is accessed by all build.xml's. Its better
ant coding style to have anything that needs to be configured in a
properties file, not in an ant build.xml file.



Yes... I realized that would limit you to running ant from the top
level. So, as most of the info in platform.properties can be deduced
would a better solution be to have a top level (or in antscripts dir)
platform-properties.xml that
a) imports platform.properties for any overrides
b) sets the properties conditional on the platform.

e.g.
 
   
 
 
   
 
 
   
 


As for the platform.properties file for windows:
The property platform can/should be removed, its not necessary. If the
property "platform.compiler-definition" is set, then that value will be
used for the compiler selection, else it will get set to msvc for
windows as can be seen on line 18 of compilers.xml.

I think the way this should ship is to have several platform.properties
files for the different platform:
   platform.properties.linux
   platform.properties.windows
   platform.properties.mac
Which will each have values pre configured for the corresponding
platform. Then with either configure or a shell script, the platform
file wil be copied to platform.properties and the directory properties
will be set accordingly.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 7:08 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml to
"runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me like
the second defintion of core.dir is being ignored. I'm not an ant expert
... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one of
the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in the
top level build.xml I added:



and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'd like some info on what I need to edit in the platform.properties.
> Particularly:
>
> platform.compiler-definition=g++m32
> platform=rhas4u4_gcc346
>
> One good thing about automake is that it detects your
> platform/compiler etc automatically.
>
> Cheers,
>
>
> On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > I put together some documentation for using ant with TuscanySCA
Native.
> >
> > How's this?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> >
> > Using ant to build TuscanySCA Native
> >
> >
> >
> > 1. Required Software to build TuscanySCA Native with ant:
> >
> > Ant:
> >Ant comes installed with almost all Linux distributions
> >version 1.6 or later
> >Download: http://ant.apache.org/
> >
> > antcontrib:
> >version 1.0b3 or later
> >Download: http://ant-contrib.sourceforge.net/
> >
> > antcontrib cpptasks.jar
> >version 1.0b4 or later
> >Download: http://ant-contrib.sourceforge.net/
> >Information: http://ant-contrib.sourceforge.net/cc.html
> >
> >
> > 2. Installation Instructions:
> >
> > Linux
> > -
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > export ANT_HOME="/home/you/ant"
> >
> > Add $ANT_HOME/bin to your path.
> > export PATH="${PATH}:${ANT_HOME}/bin"
> >
> > Optional ant tasks, s

Re: [SCA Native] preliminary ant build

[Pete Robbins]

That sounds like a good idea. I hope to minimize/automate as much of
the configuration as possible but there are a fair number of external
dependencies (libxml, httpd, libcurl, Ruby, Python... etc..)

Cheers,

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

Hey Guys

Does a lot of external dependencies need to be setup in order to
proper run the build ? Once this is complete, we could try to
integrate the ant build with Continuun (looks like it supports ant
builds) and try to get a nightly build published for Native project as
well ?

On 7/18/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > I ran into a couple of issues tryingt o run this ant build. Firstly I
> > got an error with a path
> > x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
> > the fact that the property core.dir is set in the top level build.xml
> > to "runtime/core/src" and in the runtime/core/src/build.xml the same
> > property name is used and set tu "tuscany/sca/core". It looks to me
> > like the second defintion of core.dir is being ignored. I'm not an ant
> > expert ... do properties get propagated from higher level build files?
> > I got around this by changing the name of core.dir to src.dir in one
> > of the files.
> >
> > Rather than specifying the paths to the source code etc in the
> > platform.properties I would prefer to set these automatically so in
> > the top level build.xml I added:
> >
> > 
> >
>
> or...
>
>
> > and then based other properties from this. It seemed to work!
> >
> > Do these changes make sense?
> >
> > Cheers,
> >
> >
> > On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > I'd like some info on what I need to edit in the platform.properties.
> > > Particularly:
> > >
> > > platform.compiler-definition=g++m32
> > > platform=rhas4u4_gcc346
> > >
> > > One good thing about automake is that it detects your
> > > platform/compiler etc automatically.
> > >
> > > Cheers,
> > >
> > >
> > > On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Pete,
> > > >
> > > > I put together some documentation for using ant with TuscanySCA Native.
> > > >
> > > > How's this?
> > > >
> > > > 
> > > > Brady Johnson
> > > > Lead Software Developer - HydraSCA
> > > > Rogue Wave Software - [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > Using ant to build TuscanySCA Native
> > > >
> > > >
> > > >
> > > > 1. Required Software to build TuscanySCA Native with ant:
> > > >
> > > > Ant:
> > > >Ant comes installed with almost all Linux distributions
> > > >version 1.6 or later
> > > >Download: http://ant.apache.org/
> > > >
> > > > antcontrib:
> > > >version 1.0b3 or later
> > > >Download: http://ant-contrib.sourceforge.net/
> > > >
> > > > antcontrib cpptasks.jar
> > > >version 1.0b4 or later
> > > >Download: http://ant-contrib.sourceforge.net/
> > > >Information: http://ant-contrib.sourceforge.net/cc.html
> > > >
> > > >
> > > > 2. Installation Instructions:
> > > >
> > > > Linux
> > > > -
> > > >
> > > > Make sure JAVA_HOME is set before starting.
> > > >
> > > > Install ant according to http://ant.apache.org/manual/index.html.
> > > >
> > > > Set the ANT_HOME variable to the directory where you install ant.
> > > > export ANT_HOME="/home/you/ant"
> > > >
> > > > Add $ANT_HOME/bin to your path.
> > > > export PATH="${PATH}:${ANT_HOME}/bin"
> > > >
> > > > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > > > in $ANT_HOME/lib
> > > > So place the antcontrib and cpptasks jars there.
> > > >
> > > > If you dont have write access to $ANT_HOME/lib, do the following:
> > > > - create ${user.home}/.ant/lib
> > > > - place the jars here
> > > >
> > > > Avoid adding optional ant tasks to your classpath, this is problematic.
> > > >

Re: [SCA Native] preliminary ant build

[Pete Robbins]

On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml
to "runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me
like the second defintion of core.dir is being ignored. I'm not an ant
expert ... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one
of the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in
the top level build.xml I added:





or...
  


and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> I'd like some info on what I need to edit in the platform.properties.
> Particularly:
>
> platform.compiler-definition=g++m32
> platform=rhas4u4_gcc346
>
> One good thing about automake is that it detects your
> platform/compiler etc automatically.
>
> Cheers,
>
>
> On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > Pete,
> >
> > I put together some documentation for using ant with TuscanySCA Native.
> >
> > How's this?
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> >
> >
> > Using ant to build TuscanySCA Native
> >
> >
> >
> > 1. Required Software to build TuscanySCA Native with ant:
> >
> > Ant:
> >Ant comes installed with almost all Linux distributions
> >version 1.6 or later
> >Download: http://ant.apache.org/
> >
> > antcontrib:
> >version 1.0b3 or later
> >Download: http://ant-contrib.sourceforge.net/
> >
> > antcontrib cpptasks.jar
> >version 1.0b4 or later
> >Download: http://ant-contrib.sourceforge.net/
> >Information: http://ant-contrib.sourceforge.net/cc.html
> >
> >
> > 2. Installation Instructions:
> >
> > Linux
> > -
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > export ANT_HOME="/home/you/ant"
> >
> > Add $ANT_HOME/bin to your path.
> > export PATH="${PATH}:${ANT_HOME}/bin"
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > in $ANT_HOME/lib
> > So place the antcontrib and cpptasks jars there.
> >
> > If you dont have write access to $ANT_HOME/lib, do the following:
> > - create ${user.home}/.ant/lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is problematic.
> >
> > Windows
> > ---
> >
> > Make sure JAVA_HOME is set before starting.
> >
> > Install ant according to http://ant.apache.org/manual/index.html.
> >
> > Set the ANT_HOME variable to the directory where you install ant.
> > set ANT_HOME=c:\ant
> >
> > Add %ANT_HOME%\bin to your path.
> > set PATH=%PATH%;%ANT_HOME%\bin
> >
> > Optional ant tasks, such as antcontrib and cpptasks, should be installed
> > in %ANT_HOME%\lib
> > So place the antcontrib and cpptasks jars there.
> >
> > If you dont have write access to %ANT_HOME%\lib, do the following:
> > - create ${user.home}\.ant\lib
> > - place the jars here
> >
> > Avoid adding optional ant tasks to your classpath, this is problematic.
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Pete Robbins [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 17, 2007 1:24 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [SCA Native] preliminary ant build
> >
> > Thanks Brady. I'll take a look at this. We will need doc as to what the
> > dependencies are (cpptasks etc) and any configuration that is needed.
> >
> > Cheers,
> >
> > On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> > >
> > > For anyone interested, I uploaded another patch for this JIRA that
> > > makes it work better for windows.
> > >
> > >tuscanySCAnative_ant_update1.ta

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I ran into a couple of issues tryingt o run this ant build. Firstly I
got an error with a path
x/cpp/sca/runtime/core/src/runtime/core/src. I trcked this down to
the fact that the property core.dir is set in the top level build.xml
to "runtime/core/src" and in the runtime/core/src/build.xml the same
property name is used and set tu "tuscany/sca/core". It looks to me
like the second defintion of core.dir is being ignored. I'm not an ant
expert ... do properties get propagated from higher level build files?
I got around this by changing the name of core.dir to src.dir in one
of the files.

Rather than specifying the paths to the source code etc in the
platform.properties I would prefer to set these automatically so in
the top level build.xml I added:



and then based other properties from this. It seemed to work!

Do these changes make sense?

Cheers,


On 18/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I'd like some info on what I need to edit in the platform.properties.
Particularly:

platform.compiler-definition=g++m32
platform=rhas4u4_gcc346

One good thing about automake is that it detects your
platform/compiler etc automatically.

Cheers,


On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> I put together some documentation for using ant with TuscanySCA Native.
>
> How's this?
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>
>
> Using ant to build TuscanySCA Native
>
>
>
> 1. Required Software to build TuscanySCA Native with ant:
>
> Ant:
>Ant comes installed with almost all Linux distributions
>version 1.6 or later
>Download: http://ant.apache.org/
>
> antcontrib:
>version 1.0b3 or later
>Download: http://ant-contrib.sourceforge.net/
>
> antcontrib cpptasks.jar
>version 1.0b4 or later
>Download: http://ant-contrib.sourceforge.net/
>Information: http://ant-contrib.sourceforge.net/cc.html
>
>
> 2. Installation Instructions:
>
> Linux
> -
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> export ANT_HOME="/home/you/ant"
>
> Add $ANT_HOME/bin to your path.
> export PATH="${PATH}:${ANT_HOME}/bin"
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in $ANT_HOME/lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to $ANT_HOME/lib, do the following:
> - create ${user.home}/.ant/lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
> Windows
> ---
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> set ANT_HOME=c:\ant
>
> Add %ANT_HOME%\bin to your path.
> set PATH=%PATH%;%ANT_HOME%\bin
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in %ANT_HOME%\lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to %ANT_HOME%\lib, do the following:
> - create ${user.home}\.ant\lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
>
>
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 17, 2007 1:24 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> Thanks Brady. I'll take a look at this. We will need doc as to what the
> dependencies are (cpptasks etc) and any configuration that is needed.
>
> Cheers,
>
> On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > For anyone interested, I uploaded another patch for this JIRA that
> > makes it work better for windows.
> >
> >tuscanySCAnative_ant_update1.tar.gz
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 10:46 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: [SCA Native] preliminary ant build
> >
> > Hello,
> >
> > This may be the second time you receive this email, the first time I
> > sent it with an attachment, which I later realized that this d

Re: [SCA Native] preliminary ant build

[Pete Robbins]

I'd like some info on what I need to edit in the platform.properties.
Particularly:

platform.compiler-definition=g++m32
platform=rhas4u4_gcc346

One good thing about automake is that it detects your
platform/compiler etc automatically.

Cheers,


On 17/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


Pete,

I put together some documentation for using ant with TuscanySCA Native.

How's this?


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]




Using ant to build TuscanySCA Native



1. Required Software to build TuscanySCA Native with ant:

Ant:
   Ant comes installed with almost all Linux distributions
   version 1.6 or later
   Download: http://ant.apache.org/

antcontrib:
   version 1.0b3 or later
   Download: http://ant-contrib.sourceforge.net/

antcontrib cpptasks.jar
   version 1.0b4 or later
   Download: http://ant-contrib.sourceforge.net/
   Information: http://ant-contrib.sourceforge.net/cc.html


2. Installation Instructions:

Linux
-

Make sure JAVA_HOME is set before starting.

Install ant according to http://ant.apache.org/manual/index.html.

Set the ANT_HOME variable to the directory where you install ant.
export ANT_HOME="/home/you/ant"

Add $ANT_HOME/bin to your path.
export PATH="${PATH}:${ANT_HOME}/bin"

Optional ant tasks, such as antcontrib and cpptasks, should be installed
in $ANT_HOME/lib
So place the antcontrib and cpptasks jars there.

If you dont have write access to $ANT_HOME/lib, do the following:
- create ${user.home}/.ant/lib
- place the jars here

Avoid adding optional ant tasks to your classpath, this is problematic.

Windows
---

Make sure JAVA_HOME is set before starting.

Install ant according to http://ant.apache.org/manual/index.html.

Set the ANT_HOME variable to the directory where you install ant.
set ANT_HOME=c:\ant

Add %ANT_HOME%\bin to your path.
set PATH=%PATH%;%ANT_HOME%\bin

Optional ant tasks, such as antcontrib and cpptasks, should be installed
in %ANT_HOME%\lib
So place the antcontrib and cpptasks jars there.

If you dont have write access to %ANT_HOME%\lib, do the following:
- create ${user.home}\.ant\lib
- place the jars here

Avoid adding optional ant tasks to your classpath, this is problematic.





-----Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 17, 2007 1:24 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build

Thanks Brady. I'll take a look at this. We will need doc as to what the
dependencies are (cpptasks etc) and any configuration that is needed.

Cheers,

On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> For anyone interested, I uploaded another patch for this JIRA that
> makes it work better for windows.
>
>tuscanySCAnative_ant_update1.tar.gz
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
>
>
> -Original Message-
> From: Brady Johnson [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 16, 2007 10:46 AM
> To: tuscany-dev@ws.apache.org
> Subject: [SCA Native] preliminary ant build
>
> Hello,
>
> This may be the second time you receive this email, the first time I
> sent it with an attachment, which I later realized that this dist list

> may reject. So here it is again, w/o the attachment. I created a JIRA
> and put the attachment there:
>
>https://issues.apache.org/jira/browse/TUSCANY-1438
>
> According to a previous thread titled "[SCA Native] next release
> content
> [was: Tuscany roadmap]" (I didnt want to add another "was" redirection
> ;) ), I have prepared ant build scripts for cpp/sca/runtime/core.
>
> The tar.gz file attached to the jira should just "overlay" onto the
> tuscany SCA cpp source code directory structure. It consists of the
> following files:
>
> /
>  |
>  | build.xml
>  |
>  | antscripts/
>  | |
>  | | compilers.xml
>  | | compile-targets.xml
>  | | platform.properties
>  |
>  | runtime/core/src/build.xml
>
> In order to use it, you will need to modify the platform.properties
> file. This will later be taken care of by either configure, or maybe
> just an install script.
>
> Currently it compiles and links runtime/core/src/tuscany/sca {core,
> extension, model, util} and creates libtuscany_sca.so. The install
> target installs the lib and the headers from those src directories to
> the install directory specified in platform.properties.
>
> Give it a spin and let me know what you think. It shouldnt take much
> to 

Re: [jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types

[Pete Robbins]

Tuscany cpp was being developed iat the same time as the specification
so it does not quite match the 0.96 spec... or the 1.0 spec.

We need to work now to move everything to 1.0 level of spec.

... and yes the schema and instance docs are not valid. Thanks for
raising this issue. I'll fix up the docs as per the .96 spec asap.

Cheers,


On 17/07/07, Michael Yoder (JIRA)  wrote:


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

Michael Yoder commented on TUSCANY-1443:


I see. If SCA CPP is currently 0.96 then the samples instance docs should be 
modified to be valid with the schemas in Tuscany source control. When  SCA CPP 
moves to 1.0, then both the schemas and instance docs can be updated.

Either way the issue is the instance docs are invalid with the schemas 
currently used by SCA CPP.

> sample composite files are invalid instance documents against SCA schema types
> --
>
> Key: TUSCANY-1443
> URL: https://issues.apache.org/jira/browse/TUSCANY-1443
> Project: Tuscany
>  Issue Type: Bug
> Environment: all
>Reporter: Michael Yoder
>
> The SCA samples composite files are invalid against the SCA schemas. In a 
component element, the property element has content. e.g. (from CppBigBank)
> 
>  .
>   EURO
> 
> When the XML Schema type does not allow mixed or simple content:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The type is open to additional attributes, so the instance documents can be 
made valid with simple changes like 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]





--
Pete

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

Re: [SCA Native] preliminary ant build

[Pete Robbins]

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

Should this documentation go under
http://incubator.apache.org/tuscany/sca-native-developer-guide.html

I can move it if yes.



I think we should wait until we move over to an ant build... which
will take a little longer.

Cheers,


On 7/17/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
>
> Pete,
>
> I put together some documentation for using ant with TuscanySCA Native.
>
> How's this?
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
>
>
> Using ant to build TuscanySCA Native
>
>
>
> 1. Required Software to build TuscanySCA Native with ant:
>
> Ant:
> Ant comes installed with almost all Linux distributions
> version 1.6 or later
> Download: http://ant.apache.org/
>
> antcontrib:
> version 1.0b3 or later
> Download: http://ant-contrib.sourceforge.net/
>
> antcontrib cpptasks.jar
> version 1.0b4 or later
> Download: http://ant-contrib.sourceforge.net/
> Information: http://ant-contrib.sourceforge.net/cc.html
>
>
> 2. Installation Instructions:
>
> Linux
> -
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> export ANT_HOME="/home/you/ant"
>
> Add $ANT_HOME/bin to your path.
> export PATH="${PATH}:${ANT_HOME}/bin"
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in $ANT_HOME/lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to $ANT_HOME/lib, do the following:
> - create ${user.home}/.ant/lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
> Windows
> ---
>
> Make sure JAVA_HOME is set before starting.
>
> Install ant according to http://ant.apache.org/manual/index.html.
>
> Set the ANT_HOME variable to the directory where you install ant.
> set ANT_HOME=c:\ant
>
> Add %ANT_HOME%\bin to your path.
> set PATH=%PATH%;%ANT_HOME%\bin
>
> Optional ant tasks, such as antcontrib and cpptasks, should be installed
> in %ANT_HOME%\lib
> So place the antcontrib and cpptasks jars there.
>
> If you dont have write access to %ANT_HOME%\lib, do the following:
> - create ${user.home}\.ant\lib
> - place the jars here
>
> Avoid adding optional ant tasks to your classpath, this is problematic.
>
>
>
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 17, 2007 1:24 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: [SCA Native] preliminary ant build
>
> Thanks Brady. I'll take a look at this. We will need doc as to what the
> dependencies are (cpptasks etc) and any configuration that is needed.
>
> Cheers,
>
> On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > For anyone interested, I uploaded another patch for this JIRA that
> > makes it work better for windows.
> >
> >tuscanySCAnative_ant_update1.tar.gz
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > -Original Message-
> > From: Brady Johnson [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 10:46 AM
> > To: tuscany-dev@ws.apache.org
> > Subject: [SCA Native] preliminary ant build
> >
> > Hello,
> >
> > This may be the second time you receive this email, the first time I
> > sent it with an attachment, which I later realized that this dist list
>
> > may reject. So here it is again, w/o the attachment. I created a JIRA
> > and put the attachment there:
> >
> >https://issues.apache.org/jira/browse/TUSCANY-1438
> >
> > According to a previous thread titled "[SCA Native] next release
> > content
> > [was: Tuscany roadmap]" (I didnt want to add another "was" redirection
> > ;) ), I have prepared ant build scripts for cpp/sca/runtime/core.
> >
> > The tar.gz file attached to the jira should just "overlay" onto the
> > tuscany SCA cpp source code directory structure. It consists of the
> > following files:
> >
> > /
> >  |
> >  | build.xml
> >  |
> >  | antscripts/
> >  | |
> >  | | compilers.xml
> >  | 

[jira] Commented: (TUSCANY-1423) There are no tools to verify or display tuscany services

[Pete Robbins (JIRA)]

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

Pete Robbins commented on TUSCANY-1423:
---

I have applied the latest attachment

> There are no tools to verify or display tuscany services
> 
>
> Key: TUSCANY-1423
> URL: https://issues.apache.org/jira/browse/TUSCANY-1423
> Project: Tuscany
>  Issue Type: New Feature
>  Components: C++ SCA
>Affects Versions: Cpp-M3
> Environment: All platforms
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
> Attachments: build.xml, main.cpp, TuscanyServiceLoader.cpp, 
> TuscanyServiceLoader.cpp.model, TuscanyServiceLoader.h
>
>
> According to Simon Laws thread "SCA Toys?" posted June 21, 2007, it would be 
> very useful to have a set of utilities or toys for TuscanySCA.
> I have created a toy for TuscanySCA C++ that loads tuscany services via 
> SCARuntime() and displays their information. This would be very
> useful for service development and verification.
> Following is the application's help usage:
> [EMAIL PROTECTED] bin]$ ./tuscanyServiceLoader -h
> Usage
> tuscanyDriver
> -ir Mandatory: Installation root where extensions are located: 
> ${TUSCANY_SCACPP}
> -sr Mandatory: System root where projects are located: 
> ${TUSCANY_SCACPP}/samples
> -sp Optional: System path
> -uri Optional: Base URI
> -dc Optional: Default Component name
> -model Optional: Display SCA Model Hierarchy
> -wsdl Optional: Display WSDL information
> -v Optional: Same as specifying both: -model and -wsdl
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
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-1439) All classes derived from ReferenceBinding implement getTargetServiceBinding()

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1439.
---

Resolution: Fixed

Patch applied. One minor change to RubyReferenceBinding required for compile 
error

> All classes derived from ReferenceBinding implement getTargetServiceBinding()
> -
>
> Key: TUSCANY-1439
> URL: https://issues.apache.org/jira/browse/TUSCANY-1439
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SCA
>Affects Versions: Cpp-M3
> Environment: all platforms
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
> Attachments: tuscany_jira1439
>
>
> All classes derived from ReferenceBinding implement 
> getTargetServiceBinding(). This method should be moved up to 
> ReferenceBinding. Doing so greatly simplifies walking the SCA Model hierarchy 
> and retrieving the ServiceWrapper.
> Affected sub-classes are:
>   CompositeReferenceBinding
>   CPPReferenceBinding
>   PHPReferenceBinding
>   PythonReferenceBinding
>   RESTReferenceBinding
>   RubyReferenceBinding
>   WSReferenceBinding

-- 
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: Status of C++ code generation

[Pete Robbins]

Andy, I guess you are clear to go ahead and make those changes.

Cheers,

On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote:

Hi Pete, sounds good to me.

On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> Graham,
>
> so if we move these methods to DataObjectImpl you should still be able
> to use them by casting your DataObjectPtr to the impl? I think we
> should do this in SDO HEAD along with the other 2.1 spec changes.
> There should be only a small amount of rework required when you move
> the PHP code up to use a 2.1 spec SDO.
>
> Cheers,
>
> On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote:
> > Hi Andy/Pete,
> >
> > Yes, we do use this method in the PHP SDO code - thanks for remembering us 
:-)
> >
> > I think we need to draw a distinction between SDO C++ for applications
> > and SDO C++ as an embeddable library.  The SDO C++ spec covers the
> > former and therefore does not talk about get/setUserData.  The library
> > role of SDO C++ enables us to more easily write native SDO
> > implementations for other languages (PHP, Ruby, etc...) and is IMO
> > very important (I guess I would say that :-) ).
> >
> > Get/setUserData is used by SDO PHP to manage the relationship between
> > the PHP SDO Objects and C++ SDO Objects.  Earlier versions of the PHP
> > Extension tried to manage this separately, but this solution was
> > complex and prone to problems.
> >
> > I hope this helps.
> >
> > Regards,
> >
> > Graham.
> >
> >
> > On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > Andy, the static code generation was an old experiment and is not
> > > used.I have been meaning to remove it for some time as it is confusing
> > > being there.
> > >
> > > The get/setUserData was actually put in there at the request of the
> > > PHP-SDO team. I'm not sure of the details but I think they use this to
> > > maintain a correlation between the C++ SDO objects and PHP objects???
> > > This code is not used anywhere within Tuscany SDO (or SCA) code.
> > >
> > > This may be a case where a real life application has shown up a
> > > limitation in the spec and that we should take a proposal to the spec
> > > group. I'll try and find out how essential this function is and if
> > > there is another way to work around this to enable a spec compliant
> > > api in Tuscany
> > >
> > > Cheers,
> > >
> > > On 17/07/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > > > I'm currently looking at some of the issues that my collegaue, Michael
> > > > Yoder, raised regarding the use of propietary methods in the SDO header
> > > > files. In particular, I'm looking at the setUserData / getUserData
> > > > methods in DataObject.h [TUSCANY-1370]. These methods could easily be
> > > > moved to the DataObjectImpl.h header instead. The methods are only
> > > > referenced in code generated static client code (generated by
> > > > DataFactoryImpl::generateInterface).
> > > >
> > > > However, I'm nervous about making the change because the current sdotest
> > > > suite does not excercise the static code generated classes enough to
> > > > call these methods. For instance, if I change the code generator to call
> > > > a non-existant method "foo" instead of getUserData or setUserData then
> > > > the current tests still pass.
> > > >
> > > > What is the status of the code generator? The Tuscany web site
> > > > (http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that there
> > > > are no plans to support this feature. Is this correct?
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > >
> > >
> > > --
> > > Pete
> > >
> > > -
> > > 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]
> >
> >
>
>
> --
> Pete
>
> -
> 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]





--
Pete

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

Re: Status of C++ code generation

[Pete Robbins]

Graham,

so if we move these methods to DataObjectImpl you should still be able
to use them by casting your DataObjectPtr to the impl? I think we
should do this in SDO HEAD along with the other 2.1 spec changes.
There should be only a small amount of rework required when you move
the PHP code up to use a 2.1 spec SDO.

Cheers,

On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote:

Hi Andy/Pete,

Yes, we do use this method in the PHP SDO code - thanks for remembering us :-)

I think we need to draw a distinction between SDO C++ for applications
and SDO C++ as an embeddable library.  The SDO C++ spec covers the
former and therefore does not talk about get/setUserData.  The library
role of SDO C++ enables us to more easily write native SDO
implementations for other languages (PHP, Ruby, etc...) and is IMO
very important (I guess I would say that :-) ).

Get/setUserData is used by SDO PHP to manage the relationship between
the PHP SDO Objects and C++ SDO Objects.  Earlier versions of the PHP
Extension tried to manage this separately, but this solution was
complex and prone to problems.

I hope this helps.

Regards,

Graham.


On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> Andy, the static code generation was an old experiment and is not
> used.I have been meaning to remove it for some time as it is confusing
> being there.
>
> The get/setUserData was actually put in there at the request of the
> PHP-SDO team. I'm not sure of the details but I think they use this to
> maintain a correlation between the C++ SDO objects and PHP objects???
> This code is not used anywhere within Tuscany SDO (or SCA) code.
>
> This may be a case where a real life application has shown up a
> limitation in the spec and that we should take a proposal to the spec
> group. I'll try and find out how essential this function is and if
> there is another way to work around this to enable a spec compliant
> api in Tuscany
>
> Cheers,
>
> On 17/07/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > I'm currently looking at some of the issues that my collegaue, Michael
> > Yoder, raised regarding the use of propietary methods in the SDO header
> > files. In particular, I'm looking at the setUserData / getUserData
> > methods in DataObject.h [TUSCANY-1370]. These methods could easily be
> > moved to the DataObjectImpl.h header instead. The methods are only
> > referenced in code generated static client code (generated by
> > DataFactoryImpl::generateInterface).
> >
> > However, I'm nervous about making the change because the current sdotest
> > suite does not excercise the static code generated classes enough to
> > call these methods. For instance, if I change the code generator to call
> > a non-existant method "foo" instead of getUserData or setUserData then
> > the current tests still pass.
> >
> > What is the status of the code generator? The Tuscany web site
> > (http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that there
> > are no plans to support this feature. Is this correct?
> >
> > Thanks,
> >
> > Andy.
> >
>
>
> --
> Pete
>
> -
> 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]





--
Pete

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

[jira] Resolved: (TUSCANY-1440) [SDO Native] Windows compilation issues

[Pete Robbins (JIRA)]

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

Pete Robbins resolved TUSCANY-1440.
---

Resolution: Fixed

fixed

> [SDO Native] Windows compilation issues
> ---
>
> Key: TUSCANY-1440
> URL: https://issues.apache.org/jira/browse/TUSCANY-1440
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M3
> Environment: Windows
>Reporter: Brady Johnson
>Priority: Minor
> Fix For: Cpp-Next
>
>
> The commonly used #define int64_t in SDO native may conflict with existing 
> software packages on Windows since it doesnt use #ifndef.
> The define is in: runtime/core/src/commonj/sdo/export.h
> It should be changed as follows:
> #ifndef int64_t
> #define int64_t __int64
> #endif
> I can apply a patch if necessary, but this is a simple change.
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]

-- 
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: [SCA Native] preliminary ant build

[Pete Robbins]

Thanks Brady. I'll take a look at this. We will need doc as to what
the dependencies are (cpptasks etc) and any configuration that is
needed.

Cheers,

On 16/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


For anyone interested, I uploaded another patch for this JIRA that makes
it work better for windows.

   tuscanySCAnative_ant_update1.tar.gz


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]




-Original Message-
From: Brady Johnson [mailto:[EMAIL PROTECTED]
Sent: Monday, July 16, 2007 10:46 AM
To: tuscany-dev@ws.apache.org
Subject: [SCA Native] preliminary ant build

Hello,

This may be the second time you receive this email, the first time I
sent it with an attachment, which I later realized that this dist list
may reject. So here it is again, w/o the attachment. I created a JIRA
and put the attachment there:

   https://issues.apache.org/jira/browse/TUSCANY-1438

According to a previous thread titled "[SCA Native] next release content
[was: Tuscany roadmap]" (I didnt want to add another "was" redirection
;) ), I have prepared ant build scripts for cpp/sca/runtime/core.

The tar.gz file attached to the jira should just "overlay" onto the
tuscany SCA cpp source code directory structure. It consists of the
following files:

/
 |
 | build.xml
 |
 | antscripts/
 | |
 | | compilers.xml
 | | compile-targets.xml
 | | platform.properties
 |
 | runtime/core/src/build.xml

In order to use it, you will need to modify the platform.properties
file. This will later be taken care of by either configure, or maybe
just an install script.

Currently it compiles and links runtime/core/src/tuscany/sca {core,
extension, model, util} and creates libtuscany_sca.so. The install
target installs the lib and the headers from those src directories to
the install directory specified in platform.properties.

Give it a spin and let me know what you think. It shouldnt take much to
finish it for the rest of tuscany cpp.

If it works out, we can then discuss how to configure
platform.properties.


Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


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





--
Pete

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

Re: Status of C++ code generation

[Pete Robbins]

Andy, the static code generation was an old experiment and is not
used.I have been meaning to remove it for some time as it is confusing
being there.

The get/setUserData was actually put in there at the request of the
PHP-SDO team. I'm not sure of the details but I think they use this to
maintain a correlation between the C++ SDO objects and PHP objects???
This code is not used anywhere within Tuscany SDO (or SCA) code.

This may be a case where a real life application has shown up a
limitation in the spec and that we should take a proposal to the spec
group. I'll try and find out how essential this function is and if
there is another way to work around this to enable a spec compliant
api in Tuscany

Cheers,

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

I'm currently looking at some of the issues that my collegaue, Michael
Yoder, raised regarding the use of propietary methods in the SDO header
files. In particular, I'm looking at the setUserData / getUserData
methods in DataObject.h [TUSCANY-1370]. These methods could easily be
moved to the DataObjectImpl.h header instead. The methods are only
referenced in code generated static client code (generated by
DataFactoryImpl::generateInterface).

However, I'm nervous about making the change because the current sdotest
suite does not excercise the static code generated classes enough to
call these methods. For instance, if I change the code generator to call
a non-existant method "foo" instead of getUserData or setUserData then
the current tests still pass.

What is the status of the code generator? The Tuscany web site
(http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that there
are no plans to support this feature. Is this correct?

Thanks,

Andy.




--
Pete

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

Re: SCA Toys?

[Pete Robbins]

I've added the patch for TUSCANY-1423 into tuscany/cpp/sca/tools now
that I have moved the scagen tool to the cpp extension.

I have not added this source into the build. We can use this tree to
see how the ant build works???

Cheers,

On 12/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:

I'm thinking this should go in cpp/sca/tools. Currently we have the
scagen tool in that folder but I've been meaning to move that to
cpp\sca\runtime\extensions\cpp\tools for some time now as it is really
part of the C++ language extension.

Cheers,

On 11/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
>
> I created a JIRA for this:
>https://issues.apache.org/jira/browse/TUSCANY-1423
>
> I also uploaded a patch, so its ready for some kindly commiter to submit
> it.
>
> FYI, the -model option doesn't work yet, since its depending on
> functionality to be added with:
>https://issues.apache.org/jira/browse/TUSCANY-1422
>
> Thanks
>
> 
> Brady Johnson
> Lead Software Developer - HydraSCA
> Rogue Wave Software - [EMAIL PROTECTED]
>
>
> -Original Message-
> From: Pete Robbins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 11, 2007 2:00 PM
> To: tuscany-dev@ws.apache.org
> Subject: Re: SCA Toys?
>
> Nice!
>
> please attach a patch to a Jira and I'll test/commit it.
>
> Cheers,
>
> On 11/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
> >
> > I havent seen much posted about this lately.
> >
> > I have a "toy" for TuscanySCA C++ that will use the SCARuntime to load
>
> > a service and dump out pertinent information. Also, if there are any
> > failures, it will dump that to stderr as well.
> >
> > See below for a sample output with the CppBigBank service:
> >
> > After looking at the svn structure, maybe the best place for it would
> > be:
> >
> > cpp/sca/toys
> >
> > If anyone thinks this would be useful, I'll attach the code and
> > someone can submit it for me.
> >
> > Thanks
> >
> > 
> > Brady Johnson
> > Lead Software Developer - HydraSCA
> > Rogue Wave Software - [EMAIL PROTECTED]
> >
> >
> > [EMAIL PROTECTED] bin]$ ./tuscanyServiceChecker -ir ${TUSCANY_SCACPP}
>
> > -sr ${TUSCANY_SCACPP}/samples/CppBigBank/deploy
> > Included composite: bigbank.app
> >WSDL namespace: http://www.bigbank.com/AccountService
> >PortType: AccountService
> >Operation Info:
> >OperationName: getAccountReport
> >SOAP Action:
> > http://www.bigbank.com/AccountService/getAccountReport
> >Endpoint:
> > http://localhost:9090/axis2/services/bigbank.AccountManagementComponen
> > t/
> > AccountService
> >SOAP version:  0
> >Document Style:1
> >Wrapped Style: 1
> >In Encoded Style:  0
> >Out Encoded Style: 0
> >InputMsgURI:
> > http://www.bigbank.com/AccountService
> >InputMsgName:
> > getAccountReportRequest
> >OutputMsgURI:
> > http://www.bigbank.com/AccountService
> >OutputMsgName:
> > getAccountReportResponse
> >Input Message Part:
> > Name: getAccountReportRequest
> > Type: getAccountReport
> > URI:
> > http://www.bigbank.com/AccountService
> >Output Message Part:
> > Name: getAccountReportResponse
> > Type: getAccountReportResponse
> > URI:
> > http://www.bigbank.com/AccountService
> >WSDL namespace: http://www.webserviceX.NET/
> >PortType: StockQuoteSoap
> >Operation Info:
> >OperationName: GetQuote
> >SOAP Action:
> > http://www.webserviceX.NET/GetQuote
> >Endpoint:
> > http://www.webservicex.net/stockquote.asmx
> >SOAP version:  0
> >Document Style:   

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

[Pete Robbins]

I have applied a change (revision 556081). Now SCA HEAD requires SDO HEAD.

Cheers,

--
Pete

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

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

[Pete Robbins]

On 13/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:


There are 2 options here:

1. Make the sdo spec 2.1 changes in SDO head and SCA head. This will
cause SCA head to not compile with SDO M3.

2. Make the sdo spec 2.1 changes in an SDO branch and an SCA branch,
thus allowing SCA head to compile with SDO M3. Then a merge will have to
be done at some point to get the changes into M4.

The deciding factor is whether or not we ALWAYS want SCA head to compile
with SDO M3. IMO I don't think this is necessary. It should be
understood that the SVN Head is changing and that it may not always
compile 100% with previous releases (M3). If someone wants to compile
the source code, get either:
   SDO M3 and SCA M3
-- Or --
   SDO SVN Head and SCA SVN Head
   (efforts should be made that these 2 compile together as often
as possible, if not always)

That said, I vote for option 1.



+1



Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]


-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Friday, July 13, 2007 10:42 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec
changes

The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType which
I put in the SCA HEAD but then backed out. If everyone agrees that HEAD
SCA should build against HEAD SDO I will re-apply the change.

Cheers,

--
Pete

-
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]





--
Pete

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

Re: [SCA Native] Can we make an SCA branch for SDO 2.1 spec changes

[Pete Robbins]

The current state is that SCA HEAD will only build against the sdo
branch or M3. The minor change was renaming IntegerType to IntType
which I put in the SCA HEAD but then backed out. If everyone agrees
that HEAD SCA should build against HEAD SDO I will re-apply the
change.

Cheers,

--
Pete

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