Yes. Which version of VC are you building with? The bin version of SDO
is built with VSExpress (VC 8).
You could try downloading the src release and building it on your machine.
Cheers,
On 21/03/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
My TUSCANY_SDOCPP is pointing to
C:\tuscany_sdo_cpp
My TUSCANY_SDOCPP is pointing to
C:\tuscany_sdo_cpp-1.0-incubator-M3-binthat's the latest version, I
suppose.
Adriano Crestani
On 3/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 21/03/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
> When I run it on vs express the cosole opens, the text "
On 21/03/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
When I run it on vs express the cosole opens, the text "**Sample
ObjectCreation" is printed on the cosole and then an error
message appears:
Unhandled exception at 0x7c812a5b in sdo_misc.exe: Microsoft C++ exception:
st
On 21/03/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
On 20/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
> >
> > I've downloaded the SDO src distribution on XP and it builds and runs as
> > advertised.
> >
> > +1 from me.
> >
> > Geoff.
> >
>
On 20/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 3/20/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
>
> I've downloaded the SDO src distribution on XP and it builds and runs as
> advertised.
>
> +1 from me.
>
> Geoff.
>
> On 20/03/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > +1
> >
> >
When I run it on vs express the cosole opens, the text "**Sample
ObjectCreation" is printed on the cosole and then an error
message appears:
Unhandled exception at 0x7c812a5b in sdo_misc.exe: Microsoft C++ exception:
std::bad_alloc at memory location 0x0012f3b0..
Adriano Cres
On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote:
Hi Sebastien
My understanding is that these are separate modules that are not
going to
destabelize the trunk at the moment. My personal opinion is that it
would be
OK to have this work done in the trunk as most of new work is being
de
Do you have any more information that could help the guys help you or
investigate the issue ?
On 3/20/07, Adriano Crestani <[EMAIL PROTECTED]> wrote:
I downloaded the sdo bin for windows and compiled the sdo misc sample and
I
got a "runtime error". I compiled via vc express and command line, an
Hi Sebastien
My understanding is that these are separate modules that are not going to
destabelize the trunk at the moment. My personal opinion is that it would be
OK to have this work done in the trunk as most of new work is being
developed.
--
Luciano Resende
http://people.apache.org/~lresen
On Mar 20, 2007, at 12:43 PM, Matt Hogstrom wrote:
Was there a separate DISCUSS thread on this. Looks like an
interesting idea but I'm having trouble digging through the volumes
of e-mail and the two sentences below don't help me understand the
depth of the issues. Is there one thread I
I downloaded the sdo bin for windows and compiled the sdo misc sample and I
got a "runtime error". I compiled via vc express and command line, and I got
the same error on both compilations.
Adriano Crestani
On 3/20/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 3/20/07, Geoffrey Winn <[EMAIL PRO
Consider it withdrawn.
On Mar 20, 2007, at 8:36 PM, Davanum Srinivas wrote:
Jeremy,
Please allow time for discussion. Please withdraw this vote as it is
getting hijacked because discussion is not over yet.
thanks,
dims
On 3/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Raymond Fe
Hi,
I am trying to run hello world web service sample. I
am following instructions given with the sample.
According to instruction
1. To build the sample issue :
mvn
2. Set up the Tuscany standalone runtime environment
using the following command:
mvn dependency:unpack
After completion t
Jeremy,
Please allow time for discussion. Please withdraw this vote as it is
getting hijacked because discussion is not over yet.
thanks,
dims
On 3/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Raymond Feng wrote:
> Hi,
>
> Here's my vote.
>
> [X] +1 we should do this
> [ ] -1 keep
Hi,
Interestingly I just hit the same issue independent of your work. I got two
instances of the ComponentManager and the one contributed from the
system.scdl shadows the primordial one.
Does it mean the primordial components are not replaceable?
Thanks,
Raymond
- Original Message -
On 3/20/07, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
I've downloaded the SDO src distribution on XP and it builds and runs as
advertised.
+1 from me.
Geoff.
On 20/03/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> +1
>
>...ant
>
> On 3/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > P
Raymond Feng wrote:
Hi,
Here's my vote.
[X] +1 we should do this
[ ] -1 keep things as they are
The vote is based on my understanding of the benefits of
interface-based models as follows.
1) Better pluggability for the model implementation and loading: We
can easily generate the model and
Jim Marino wrote:
On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our SCA
runtime kernel. I posted two diagrams on our Wiki at
http://cwiki.apache.org/confluence/display/TUSCANY/Componentizi
Agree with Ant, we probably don't need jUnit into the binary distro.
At the same time, do we really need ASM?
On the other hand, roughly I see 2 kinds of audience:
2-1. developers who participate in development. I guess they might lean to
work upon the source repository instead of the release
2-2
[
https://issues.apache.org/jira/browse/TUSCANY-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1188.
-
Resolution: Invalid
The sequence annotation is in NS commonj.sdo/xml
> XSDHelper and X
[
https://issues.apache.org/jira/browse/TUSCANY-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1187.
-
Resolution: Invalid
The readOnly annotation is in NS commonj.sdo/xml
> XSDHelper and X
Thanks a lot for the clarification Meeraj! It is already compiling...
Mario
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 5:35 PM
To: Antollini, Mario
Subject: RE: FW: Discovery update
Mario,
This is the order in which to build,
/
[
https://issues.apache.org/jira/browse/TUSCANY-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Murray updated TUSCANY-1187:
--
Component/s: Java SDO Implementation
Assigned to the correct component.
> XSDHelper and XSD2
[
https://issues.apache.org/jira/browse/TUSCANY-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Murray updated TUSCANY-1188:
--
Attachment: expectedExceptions.xsd
SequencedAnnotationTestCase.java
Attachmen
XSDHelper and XSD2JavaGenerator do not recognize sdo:sequence="true"
Key: TUSCANY-1188
URL: https://issues.apache.org/jira/browse/TUSCANY-1188
Project: Tuscany
Issue Type:
[
https://issues.apache.org/jira/browse/TUSCANY-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482530
]
Frank Budinsky commented on TUSCANY-1186:
-
David, your example looks kind of nutty.
1) mixed="true" and sd
[
https://issues.apache.org/jira/browse/TUSCANY-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Murray updated TUSCANY-1187:
--
Attachment: ReadOnlyAnnotationTestCase.java
expectedExceptions.xsd
Test case
XSDHelper and XSD2JavaGenerator do not recognize sdo:readOnly="true"
Key: TUSCANY-1187
URL: https://issues.apache.org/jira/browse/TUSCANY-1187
Project: Tuscany
Issue Type:
David Adcox has opened a Jira regarding sequenced Types in a Statically
created Type. He used mixed="true" (which implies sequenced="true") to
achieve this. His Jira does not demonstrate successful use of
sdo:sequence="true" in the XSD.
Brian,
First of all, the sdo:sequence annotation is just one (probably the most
unlikely) way to create a sequenced type from XSD. The most common way is
to create a "mixed" complexType. That's really what SDO Sequence was
designed for.
That said, looking at the code, it looks like it is suppo
[
https://issues.apache.org/jira/browse/TUSCANY-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David T. Adcox updated TUSCANY-1186:
Attachment: api_test.xsd
Test1186.jar
The jar file contains a test client
[
https://issues.apache.org/jira/browse/TUSCANY-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482515
]
David T. Adcox commented on TUSCANY-1186:
-
I need to amend the comments for this issue. It is only for Sta
[
https://issues.apache.org/jira/browse/TUSCANY-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1185.
-
Resolution: Fixed
Accepted.
> Contribution of EMF classes, BasicExtendedMetaData and X
Hi Sebastien,
I don't see any other replies, and I feel like I'm being tricked in
some way
First, let me say that this could be more clearly described. However,
there is a precedent in the WSDL extension for @requires. It is
described in section 1.5.4 of the assembly spec. When applied to
t
I've confirmed that IBM, the copyright holder, gives permission to Apache
to reuse the two EMF files in question.
I've opened TUSCANY-1185 to contribute the two base classes, provided in
an attachment.
Jeremy, let me know if this is good enough for you, or if you still want
me to remove the Tu
Sequenced type of DataObject returns 'null' from getSequence() method, it
should return empty Sequence object
--
Key: TUSCANY-1186
URL: https://issues.apa
[
https://issues.apache.org/jira/browse/TUSCANY-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky updated TUSCANY-1185:
Attachment: BasicExtendedMetaData.java
> Contribution of EMF classes, BasicExtendedMetaDa
[
https://issues.apache.org/jira/browse/TUSCANY-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky updated TUSCANY-1185:
Attachment: XSDEcoreBuilder.java
> Contribution of EMF classes, BasicExtendedMetaData and
Contribution of EMF classes, BasicExtendedMetaData and XSDEcoreBuilder
--
Key: TUSCANY-1185
URL: https://issues.apache.org/jira/browse/TUSCANY-1185
Project: Tuscany
Issue Ty
Was there a separate DISCUSS thread on this. Looks like an
interesting idea but I'm having trouble digging through the volumes
of e-mail and the two sentences below don't help me understand the
depth of the issues. Is there one thread I can look at or is it
really a mosaic of different t
I believe that both XSDHelper and XSD2JavaGenerator are not properly
accounting for sequence and read-only indicators in the XSD. I have a test
case which I can attach to the Jira. I'm appending my XSD below because the
problem may lie in my XSD.
If I define the Type with the TypeHelper using
You also need to update the poms for the individual samples and and
elements in their SCDL.
--
Jeremy
On Mar 20, 2007, at 9:43 AM, [EMAIL PROTECTED] wrote:
Author: meerajk
Date: Tue Mar 20 09:43:37 2007
New Revision: 520468
URL: http://svn.apache.org/viewvc?view=rev&rev=520468
Log:
upgraded
[
https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1006.
-
Resolution: Fixed
I'm assuming this is fixed in EMF 2.2.2. Please reopen if not.
> Cha
On Mar 20, 2007, at 9:26 AM, Venkata Krishnan wrote:
Hi Jeremy,
As part of this discussion and vote could we also summarize the
technical
reasons for each of us to be going one way or the other. Since
this is a
major decision point it would be good for everybody to know why we
as a
comm
Brian,
There is already spec discussion about possibly deprecating the DataGraph
interface entirely. Even if that doesn't happen, I think that the (URI,
name) methods should be deprecated.
Frank.
"Brian Murray" <[EMAIL PROTECTED]> wrote on 03/20/2007 10:28:29
AM:
> Thanks Kelvin.
>
> That i
Checking it in sounds good, when ever you're ready, and I can do what you
suggest and for now locally change things so that its used. But right the
databinding code in the core/spi doesn't work anyway does it? Maybe the post
processors are still running but they're not doing anything, so we could
I can't see how kernel modularization is related to interface based models.
Model is only part of the SPI, SPI also provides a set os services, which
all have well-defined contracts. I am not sure what extra benefits we have
by supporting different data binding mechanisms for the model objects.
Hi,
I don't get a formal vote, but as an embedder it is extremely painful
to consume and embed a new level of code when the SPI layer
(that's supposed to insulate embedders) is changing as often as the
underlying kernel implementation. At the moment, the current
SPI layer might as well be invisi
Hi, Ant.
I'm doing the databinding integration locally. To avoid destablization of
the current core and achieve better modularity, I created a module
"tuscany-core-databinding" to hold all the integration code which hooks the
databinding framework to the wiring fabric. Then I could remove all
Hi,
Here's my vote.
[X] +1 we should do this
[ ] -1 keep things as they are
The vote is based on my understanding of the benefits of interface-based
models as follows.
1) Better pluggability for the model implementation and loading: We can
easily generate the model and loading code using Ja
Hi Jeremy,
As part of this discussion and vote could we also summarize the technical
reasons for each of us to be going one way or the other. Since this is a
major decision point it would be good for everybody to know why we as a
community are taking a specific direction and helps us to get back
Hi,
I am trying to run samples. I am having problem when i
run "mvn dependency:unpack". I want to know how do i
know what plug-in's i should configure in
"maven-dependency-plugin" section?
[INFO] One or more required plugin parameters are
invalid/missing for 'dependenc
y:unpack'
[0] inside the d
I've downloaded the SDO src distribution on XP and it builds and runs as
advertised.
+1 from me.
Geoff.
On 20/03/07, ant elder <[EMAIL PROTECTED]> wrote:
+1
...ant
On 3/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> Please vote to approve the release of milestone 3 of Tuscany SCA Nat
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with
separate implementation and factory classes. This will have a major
impact on the kernel code and all extens
Hi,
I would like a more elaborate explanation on what is meant in this context
by interfaces, factory classes and separate implementations. As we are now,
our model classes just encapsulate state, with hardly any behaviour. We
quite nicely separate model from the runtime artifacts by moving be
Mario,
I will try to be as detailed as I can, if you need further info, pls ask.
Tuscany code structure is roughly organized into kernel, runtime, services
and extensions. There are other modules like plugins, console etc, which are
not relavant in the context of this discussion. There is also
+1
I'm not sure that the proposal is exactly "Rewrite kernel model to be based
on interfaces" but for the sake of this vote I'm +1.
Note also that the current trunk code has been undergoing major changes
recently/currently anyway and has already made major changes to the
extension SPIs with more
Hi,
My view is that, if the design that Sebastien is proposing is a step forward
in our modularization goals then its good to get it into the trunk. I like
the design and here is my +1 to move this into the trunk. IMO, moving to
the trunk does not mean the kernel will have to be immediately in
On Mar 20, 2007, at 7:26 AM, Antollini, Mario wrote:
Meeraj,
I am willing to help you. However, keep in mind that I am neither a
Tuscany developer nor a committer. Therefore you must give me a task I
can actually work on.
In case you do write to me, please be very specific since I do not
hav
Thanks Kelvin.
That is a workaround for the example I provided. However, the absence of
HelperContext as a parm does seem to render createRootObject(URI, Name) and
DataGraph.getType(URI, name) of very limited use.
The DataGraph methods are different from the following:
DataObject.createDataObje
Meeraj,
I am willing to help you. However, keep in mind that I am neither a
Tuscany developer nor a committer. Therefore you must give me a task I
can actually work on.
In case you do write to me, please be very specific since I do not have
much experience with Tuscany's code.
Looking forward to
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with
separate implementation and factory classes. This will have a major
impact on the kernel code and all extensi
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with
separate implementation and factory classes. This will have a major
impact on the kernel code and all extensions. This vote is not about
what is in the model,
I agree putting it the trunk makes sense for all the reasons already
mentioned.
The trunk is where main development should take place unless there are a
good reasons not to. Code going into trunk does not have to be finished and
perfect but should be worked on in the trunk to incrementally improv
Trying to get the Axis2 and e4x databindings working again in trunk but
building the databinding framework module I get some test failures due to
missing methods when running with mvn but they all work in eclipse. It looks
like there's a conflict due to some of the classes being duplicated in the
Ole,
Thanks for your explanation. With yours and Frank Budinsky's comments, I am
more clear now.
Fuhwei Lwo
Ole Ersoy <[EMAIL PROTECTED]> wrote: Hi Fuhwei,
Sure. The ecore2ecore model maps one ecore model to another.
Here's a real world scenario that I'm using it for that will hopefully
mak
Frank,
Standard disclaimer: I am not a lawyer and I am not qualified to give
legal interpretations. However, I have heard many lawyers give talks
on copyright :-) Based on this, I'd expect that the "new" method would
need to follow standard legal guidelines for defence against a claim
of copyrig
I think it's a good idea to move this code out of the integration
branch. I prefer to keep the integration branch for its original
purpose of providing a stable environment for developing and testing
end to end scennarios.
I agree that it's important not to destabilize trunk by adding this
code.
Hi,
I have temporarily replaced the JXTA discovery service with JMS (Jim, this
is important you for tomorrow's demo).
We have been using JXTA so far for discovery. We use PDP (Peer Discovery
Protocol) for maintaining the federated runtime topology adn PRP (Peer
Resolver Protocol) for sending
Brian,
this would be an issue for the SDO spec, but I don't think it's
necessary, since you can use
Type type =helperContext1.getTypeHelper().getType(uri, name);
and then use
dataGraph.createRootObject(type);
the root object will then provide the type scope context for subsequent
updates to th
+1
...ant
On 3/16/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
Please vote to approve the release of milestone 3 of Tuscany SCA Native
and
Tuscany SDO C++.
The SDO release includes performance improvements (30-40%) along with
improvements to robustness.
The SCA release includes support for C
On 3/20/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
> I'd like to start a discussion on how we could componentize our SCA
> runtime kernel. I posted two diagrams on our Wiki at
>
http://cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our+runtime
72 matches
Mail list logo
