I have fixed the domain manager itest issues in Linux/Mac OS
environment and I'm down to some contribution-jee errors.
Tests in error:
testSCAJarEarAppcomp(org.apache.tuscany.sca.test.contribution.jee.SCAJarEarAppcompWarAppcompTestCase)
On Fri, May 15, 2009 at 11:16 AM, Simon Lawssimonsl...@googlemail.com wrote:
I've been doing more investigation around backward compatibility this
week. I have the Running and interacting in the same domain scenario
in mind [1]. I haven't made all these changes but to make this work
using a
I've been making some good progress on dynamic domain operation, you
can now stop and start nodes and have the wiring pick up on the new
nodes, and you can configure the domain from a config URI which makes
it easy to start dynamic domains and I've added support for that to
things like the Tuscany
Its been nearly 6 weeks since the 2.0 M3 release so should we be
thinking about another release? We probably have enough content now -
the Assembly otests are nearly all passing, the're a new JSONP
binding, and the dynamic domain is starting to come together. So would
a M4 in a couple of weeks be
On Tue, Jun 16, 2009 at 8:04 PM, ant elderant.el...@gmail.com wrote:
On Tue, Jun 16, 2009 at 4:48 PM, Raymond Fengenjoyj...@gmail.com wrote:
Hi,
I realized that we have an established pattern for the code of
implementation and binding extensions. We also use copy/paste to create
new modules
[
https://issues.apache.org/jira/browse/TUSCANY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giorgio Zoppi updated TUSCANY-3241:
---
Attachment: partial-endpointdht.tar.gz
This is a partial work and update, not intended for
Just done a 1.5.1 linux build (Sun JDK 1.6-07) and this is what I see...
[INFO] Apache Tuscany SCA Store Tutorial Integration Test FAILED [18.309s]
[INFO]
[INFO] Error for project: Apache Tuscany SCA Gdata Binding
The JMS problem is just a timing issues. The TimeToLive is set very
short for one of the property tests and it's obviously behaving
slightly differently on my Linux compared to Windows.
Simon
On Tue, Jun 2, 2009 at 9:08 AM, Simon Lawssimonsl...@googlemail.com wrote:
snip...
1) Do we need to register the endpoint references? For callbacks, we can
just publish the endpoint for the callback.
Not now but his was for the future if we need to establish what
endpoint references are out
I agree with Mike's point. Given the code structure as it stands we
should be doing a full build before checking changes is. This doesn't
prevent any kind of profile being created for intermediate builds but
on check in we need to ensure that everything works. You will of
course say but we don't
Can we leave them in for the time being. I'm finding it useful for
testing at the moment. A central place where I can look at what
endpoint references are active as I mess about with the builders.
Simon
On Tue, Sep 1, 2009 at 12:50 PM, Simon Lawssimonsl...@googlemail.com wrote:
Alternatively we have to take a manual approach. I see the code
separated into a core and the extensions that the core supports. We
could make some rules/profiles for the types of build you need to do
depending on
structure like that so IMHO what Giorgio is doing with a profile that
suits himself seems like a fine way to make a gradual start on this.
Absolutely, this isn't about moving code about in the repository it's
about understanding which profiles/tests/contracts support more
granular builds.
2009/9/1 Simon Laws simonsl...@googlemail.com:
structure like that so IMHO what Giorgio is doing with a profile that
suits himself seems like a fine way to make a gradual start on this.
Absolutely, this isn't about moving code about in the repository it's
about understanding which
I guess that the main point for have a distributed endpoint resolution
or at least
my motivation is to be able to detect faults and trying to have an
architecture scalable and fault resilent (yes, i know a lot of work is
needed for accomplish that goal). Instead i'd use a centralized
domain is
I note that the domain-node module defines the package...
org.apache.tuscany.sca.node
Which is also defined in node-api. Is this necessary? How about
org.apache.tuscany.sca.domain.node
I can't get my Eclipse PDE workspace to settle down with the latest
2.x code (I do get a clean maven build)
On Tue, Sep 1, 2009 at 2:41 PM, Simon Lawssimonsl...@googlemail.com wrote:
How about
org.apache.tuscany.sca.domain.node
That seems fine for now so go for it. We can rationalize all the
domainy modules and packages later on.
...ant
I'm also getting lots of manifest problems in the domain-node and
endpoint-wrapper area. Are the manifests in svn intended to be
correct?
Simon
Giorgio Zoppi wrote:
However if we compartamentalize dependencies i guess that's is
feasible to identify some part of the infrastructure that are loosely
or tighly connected. And one could work on with a small set of the
infrastructure without breaking things.
Just 1c,
Giorgio.
Folks,
I am
I'm seeing missing import-package headers too. The issue is far deeper than
just the split packages. It creates quite a few dependencies to the
internal implementation classes. We need to find better ways to handle
such things.
I fixed the obvious ones under r810317 and r810319. The
See
http://hudson.zones.apache.org/hudson/job/Tuscany-2x/org.apache.tuscany.sca$tuscany-endpoint-wrapper/201/
--
[INFO]
[INFO] Building Apache Tuscany SCA Endpoint Wrapper
[INFO]
21 matches
Mail list logo
