Re: Automated nightly builds
The current status is: DAS is building with the distribution profile enabled. SCA distribution profile was causing errors as mentioned in [1]. Did we find a solution for them ? SDO was missing distribution profile. Ant was working on SDO distributions, but I'm not sure the profile is done. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18807.html On 6/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Are the distribution artefacts now being produced? Can we add the links to the web site? If so what should they be? Simon It doesn't look like they are. Luciano, or anybody who has access to the confluence config, would it be possible to switch the build profile to -Pdistribution? Thanks... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1373) C++ SDO spec compliance/portability: DataFactory::setDefault
[ https://issues.apache.org/jira/browse/TUSCANY-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1373: -- Component/s: C++ Specification C++ SDO Affects Version/s: Cpp-M3 adding specification component C++ SDO spec compliance/portability: DataFactory::setDefault Key: TUSCANY-1373 URL: https://issues.apache.org/jira/browse/TUSCANY-1373 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder In the Tuscany C++ SDO specification interface DataFactory.h, there are additional overloads for the setDefault member function which take a type uri/name instead of a reference to a Type object. These additions should either be made internal to the implementation or proposed to the spec committee. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 7:04 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataFactory::setDefault Hi, In the DataFactory interface, there are additional overloads for the setDefault member function which take URI and name parameters for a Type instead of a reference to a Type object. virtual SDO_API void setDefault( const char* typuri, const char* typnam, const char* propname, bool b ) = 0; virtual SDO_API void setDefault( const SDOString typuri, const SDOString typnam, const SDOString propname, bool b ) = 0; . Would it be a good idea to file a Jira to have these submitted to the specification committe as additions? 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]
[jira] Updated: (TUSCANY-1374) C++ SDO spec portability: DataObjectInstance
[ https://issues.apache.org/jira/browse/TUSCANY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1374: -- Component/s: C++ Specification Affects Version/s: Cpp-M3 adding specification component C++ SDO spec portability: DataObjectInstance Key: TUSCANY-1374 URL: https://issues.apache.org/jira/browse/TUSCANY-1374 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder The Tuscany C++ SDO implementation has a public class DataObjectInstance used by SCA examples. For portability it would be desirable for the examples to use the spec API, and have this non-spec class removed or made internal to the implementation. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 8:28 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec portability: DataObjectInstance Hi, Tuscany C++ SDO introduces an off-spec class used externally by a few SCA samples, DataObjectInstance. What is the rationale for having this class? Would it be alright for the samples to use SDO API smart pointers instead, and remove this class, or is this a concept that might be worth considering for the specification? 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]
[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.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1368: -- Component/s: C++ Specification C++ SDO Affects Version/s: Cpp-M3 adding specification component 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 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] -- Pete -- 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] Updated: (TUSCANY-1372) C++ SDO spec compliance/portability: DataFactory
[ https://issues.apache.org/jira/browse/TUSCANY-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1372: -- Component/s: C++ Specification C++ SDO Affects Version/s: Cpp-M3 adding specification component C++ SDO spec compliance/portability: DataFactory Key: TUSCANY-1372 URL: https://issues.apache.org/jira/browse/TUSCANY-1372 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder The Tuscany C++ SDO specification interface DataFactory.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:54 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataFactory Hi, In the DataFactory interface, the below member functions are exposed which aren't in the C++ 2.1 spec. Would it be appropriate to file a Jira/patch to have these removed from the spec interface? SDO_API virtual DataFactoryPtr clone(); virtual SDO_API bool generateInterface(const char* fileroot, const char *factoryname) = 0; virtual SDO_API bool generateInterface(const SDOString fileroot, const SDOString factoryname) = 0; virtual SDO_API void setPropertySubstitute( const char* uri, const char* inTypeName, const char* propname, const char* subname, const char* subTypeUri, const char* subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const SDOString uri, const SDOString inTypeName, const SDOString propname, const SDOString subname, const SDOString subTypeUri, const SDOString subTypeName) = 0; virtual SDO_API void setPropertySubstitute( const Type containertype, const char* propname, const char* subname, const Type subtype) = 0; virtual SDO_API void setPropertySubstitute( const Type containertype, const SDOString propname, const SDOString subname, const Type subtype) = 0; 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]
[jira] Updated: (TUSCANY-1376) C++ SDO spec portability: RefCountingPointer
[
https://issues.apache.org/jira/browse/TUSCANY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Robbins updated TUSCANY-1376:
--
Component/s: C++ Specification
Affects Version/s: Cpp-M3
adding specification component
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
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
RefCountingPointerT 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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] Updated: (TUSCANY-1370) C++ SDO spec compliance/portability: DataObject
[ https://issues.apache.org/jira/browse/TUSCANY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1370: -- Component/s: C++ Specification Affects Version/s: Cpp-M3 adding specification component 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 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]
[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.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1371: -- Component/s: C++ Specification Affects Version/s: Cpp-M3 adding specification component C++ SDO spec compliance/portability: 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 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]
[jira] Updated: (TUSCANY-1366) C++ SDO spec portability: SDORuntimeException off-spec member functions
[
https://issues.apache.org/jira/browse/TUSCANY-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Robbins updated TUSCANY-1366:
--
Component/s: C++ Specification
adding specification component
C++ SDO spec portability: SDORuntimeException off-spec member 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
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 setExceptionLocation(const
std::string file,
unsigned long line,
const std::string function=);
SDO_API void setLocation(const std::string file,
unsigned long line,
const std::string function=);
SDO_API void trace(const std::string text=%1:\n %3 %4 %2);
SDO_API virtual ostream PrintSelf(ostream os) const; SDO_API friend
ostream operator (ostream os, const SDORuntimeException except);
What's the rational behind these additional member functions? Would it
be appropriate to file a bug to have them removed from the public API?
Or alternatively a bug for them to be submitted to the spec committee?
Thanks,
Michael Yoder
Software Developer
Rogue Wave Software
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
--
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] Updated: (TUSCANY-1375) C++ SDO spec portability: C++ type definition API
[ https://issues.apache.org/jira/browse/TUSCANY-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1375: -- Component/s: C++ Specification Affects Version/s: Cpp-M3 adding specification component 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 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]
[jira] Updated: (TUSCANY-1367) C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType
[ https://issues.apache.org/jira/browse/TUSCANY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins updated TUSCANY-1367: -- Component/s: C++ Specification adding specification component C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType Key: TUSCANY-1367 URL: https://issues.apache.org/jira/browse/TUSCANY-1367 Project: Tuscany Issue Type: Improvement Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: portability issue - all platforms Reporter: Michael Yoder The C++ SDO 2.1 spec renamed Type::Types::IntegerType to Type::Types::IntType. This will need to be updated in the Type interface. -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] -- Pete -- 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: SDO C++ compliance with 2.1 spec - help needed
On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Cheers, On 22/06/07, Pete Robbins [EMAIL PROTECTED] wrote: As is shown by the analysis that Michael Yoder is doing, comparing SDO 2.1spec API vs Tuscany SDO C++ API, it is clear that there will be a fair amount of work involved in getting the Tuscany code in to shape. Some changes are fairly simple but others may need wide ranging changes in the way Tuscany SDO is implemented. This will not be done overnight. I'd like to propose that we cut a branch of the current code and start the 2.1 work in HEAD (or should the 2.1 work start in a branch?). I know the PHP SCA community are using a cut later than M3 with some fixes I have written and expect them to raise more problems from time to time, this is why I'd like a maintenance branch available while we work on a 2.1compliany implementation. Would anyone else (committer or not) like to help out with the 2.1effort? Cheers, -- Pete -- Pete Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. Simon
[jira] Resolved: (TUSCANY-1367) C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType
[ https://issues.apache.org/jira/browse/TUSCANY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins resolved TUSCANY-1367. --- Resolution: Fixed Fix Version/s: Cpp-Next fixed C++ SDO spec compliance/portability: Type::Types::IntegerType should be renamed Type::Types::IntType Key: TUSCANY-1367 URL: https://issues.apache.org/jira/browse/TUSCANY-1367 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 The C++ SDO 2.1 spec renamed Type::Types::IntegerType to Type::Types::IntType. This will need to be updated in the Type interface. -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] -- Pete -- 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: servicemix-sca now compiling
On 6/22/07, Kit Plummer [EMAIL PROTECTED] wrote: I've made all the fixes (to accommodate CheckStyle and PMD). Is a project-level patch the best way to handle all of the affected files? Yep. Just create a JIRA issue and link it the one that Brian just filed for his patch so that I know which one to apply first. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
Re: Automated nightly builds
Ok, I have fixed the sca build issue described by Jean-Sebastien, so now, SCA, SDO and DAS are configured to run with the distribution profile. Once the three builds are passing successfully, I'll send the link to the nightly distributions in a new thread. On 6/22/07, Luciano Resende [EMAIL PROTECTED] wrote: The current status is: DAS is building with the distribution profile enabled. SCA distribution profile was causing errors as mentioned in [1]. Did we find a solution for them ? SDO was missing distribution profile. Ant was working on SDO distributions, but I'm not sure the profile is done. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18807.html On 6/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Are the distribution artefacts now being produced? Can we add the links to the web site? If so what should they be? Simon It doesn't look like they are. Luciano, or anybody who has access to the confluence config, would it be possible to switch the build profile to -Pdistribution? Thanks... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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]
[LDAP DAS] Efficient Determination of the Type's member that represents its ID
Hey Guys, I'm in the process of coding the EDataObjectReader. It first looks up a LDAP context containing a DataObject instances property values. In order to do this, it needs to know which Type member represents the Type's ID. Does Tuscany have an efficient way of determining this ID? With the EMF API it looks like I have to preprocess all the EClass instances, and store each EClass's ID (isID() returns true) EAttribute on a Map for more efficient retrieval. Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
