Here's my own +1
On 18/03/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 18/03/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 18/03/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Andrew Borley wrote:
On 3/16/07, Pete Robbins [EMAIL PROTECTED] wrote:
Please vote to
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
to
+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
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
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
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
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
make
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
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,
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
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:
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
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
+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
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
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
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
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 Native
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
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
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
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,
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
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.
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
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 is a
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
[
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.
You also need to update the poms for the individual samples and and
dependency 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=revrev=520468
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
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
Contribution of EMF classes, BasicExtendedMetaData and XSDEcoreBuilder
--
Key: TUSCANY-1185
URL: https://issues.apache.org/jira/browse/TUSCANY-1185
Project: Tuscany
Issue
[
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
Sequenced type of DataObject returns 'null' from getSequence() method, it
should return empty Sequence object
--
Key: TUSCANY-1186
URL:
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
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
[
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
[
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
[
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
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
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.
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:
[
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
[
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
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-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Murray updated TUSCANY-1188:
--
Attachment: expectedExceptions.xsd
SequencedAnnotationTestCase.java
[
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
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
]
Frank Budinsky resolved TUSCANY-1187.
-
Resolution: Invalid
The readOnly annotation is in NS commonj.sdo/xml
XSDHelper and
[
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
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
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
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
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:
Please vote to
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
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 things
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
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
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
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, and I
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
61 matches
Mail list logo
