On Feb 28, 2007, at 9:59 PM, Luciano Resende wrote:
While reviewing contribution code and thinking about some test
scenarios, I
have the following questions and would like to get some thoughts.
1.What should be the default behavior when i re-deploy a
contribution to the
repository ? Should
There are a few modules in the runtime that I don't think should be
included in this release:
* jxta due to the Bouncy Castle issue
* osgi (not ready)
* equinox (not ready)
For now I am going to move them to a contrib directory under sca as
this makes it easier to package runtime as a source
We need to follow the IP Clearance process for all code developed
outside Apache ...
--
Jeremy
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: March 1, 2007 4:14:07 PM PST
To: tuscany-commits@ws.apache.org
Subject: svn commit: r513560 [1/2] - in /incubator/tuscany/java/sdo/
impl/src:
-Sebastien Delfino wrote:
[snip]
Jeremy Boynes wrote:
The sca-api module contains old versions of the schemas from 0.9
days.
I think we should remove these from the jar as they are orthogonal
from the Java APIs. We could package them separately, on our
website,
or just leave them to the spec
On Feb 28, 2007, at 7:07 AM, Michael John Edwards (JIRA) wrote:
The SCA 1.0 specification XSDs are now available from:
http://www.osoa.org/xmlns/sca/1.0/
That location also includes a license file which grants permission
to use and repackage the files within projects implementing SCA.
On Feb 28, 2007, at 7:12 AM, Mike Edwards wrote:
Jeremy,
I have not got around to the Java API files yet.
It is my intention to publish them from www.osoa.org, probably
bundled as a single zip or jar file. Haven't decided the exact url
yet - suggestions welcome.
I haven't given the
One of the challenges with SPI is the amount of implementation it
contains, particularly in the extension package where we provide
baseclasses for many of the extension points.
The intention here was to provide implementation infrastructure
common to many extension points that they could
On Feb 28, 2007, at 9:37 AM, Simon Laws wrote:
Running
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
11.657 sec
F
AILURE!
testLauncherUsage(
org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestL
On Feb 28, 2007, at 10:15 AM, Jim Marino wrote:
...
If you want to remove debug, do (adjusting for your IDE, this works
with IDEA):
java -Xdebug -Xnoagent -Djava.compiler=NONE -
Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -
jar
We've had a couple of users recently talk about issues running
samples etc. many of which would go away if there was a release
available for them to use. I think we should do a release from trunk.
This would include:
* the 1.0 spec jars
* kernel
* runtime (including war and itest plugin)
*
On Feb 28, 2007, at 10:35 AM, Luciano Resende wrote:
My suggestion was to use a maven profile to have all pieces
necessary to run
a sample built, and I think this is the purpose of maven.
Note that I didn't suggest having maven performing the following
command
(that would actually run the
On Feb 28, 2007, at 10:25 AM, Luciano Resende wrote:
To run the samples, as we have not cut a release yet, you will need
to manually create a distribution. This should be pretty
straightforward:
1. In /kernel do 'mvn'
2. In /runtime/standalone run 'mvn'
3. In /core-samples/common run 'mvn
On Feb 28, 2007, at 11:25 AM, Jim Marino wrote:
For versioning the SCA jar, how about: 1.0-incubating?
That was what I was thinking as well. This would make the artifact:
org.osoa:sca-api-r1.0-1.0-incubating:jar
which separates the spec revision r1.0 from the jar version 1.0-
incubating
On Feb 28, 2007, at 1:02 PM, Simon Laws wrote:
On 2/28/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
This might be a CRLF issue with the master copy for the test output
as it works for me on OSX (\n type line separators). If so, then
except for aborting the build, it's not significant. Is anyone
On Feb 28, 2007, at 1:21 PM, Raymond Feng wrote:
Hi,
I can see the pain. Two related questions:
1) To contribute a loader without a base class, I'll have to
implement all methods in StAXElementLoader interface, right?
You would still be able to do that. The LoaderExtension is fairly
In general, this won't work in a federated world as there might not
be any representation of the composite on the runtime node.
I think what you're trying to do here is define a common resource for
use in the target runtime - very similar to how we're planning to
define ClassLoaders as
I was thinking about the war plugin and the way that it recreates the
war file generated by the normal war plugin. Instead I was thinking
we could bind it to the generate-resources phase and just have it
generate a directory with the necessary files in it - these would
then automatically
What's the difference between this and the existing MavenMonitorFactory?
On Feb 28, 2007, at 7:12 PM, Jim Marino wrote:
FYI,
I've created a simple MonitorFactory implementation for the iTest
plugin that forwards events to the Maven Log and also incorporated
the exception formatters. This
On Feb 26, 2007, at 9:49 PM, Snehit Prabhu wrote:
Hi,
I am trying to setup the Tuscany Trunk Distribution on my machine
for a
while now, with little success. Any help on the matter would be
appreciated.
I should mention that the complete M2 distribution has been
downloaded,
built and
typed sub-classes
for the
extensions.
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 1:30 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Marshalling WireDefinitions for federated deployment
For all of these:
cns:component
Thanks Ignacio
On Feb 26, 2007, at 8:35 AM, Jim Marino wrote:
On Feb 26, 2007, at 8:26 AM, Ignacio Silva-Lepe wrote:
I took a quick pass. I saw a couple of inconsistencies with respect
to the spec doc:
- @EndsConversation is defined in the spec doc (small typo)
Oops that is a bug in our
On Feb 26, 2007, at 9:12 AM, Raymond Feng wrote:
The xml type for a property can be from the introspection of the
java class or @DataType annotation if the java class doesn't
provide such metadata.
+1 to remove the xmlType attribute from @Property. We need to fix
the property handling
Resending a previous reply as my ISP's MTA seems to be acting up...
On 2/26/07, Jim Marino [EMAIL PROTECTED] wrote:
FYI,
Now that we have the AutowireResolver in place, I'm going to look
into adding support for full SCA 1.0 autowire semantics in trunk.
This will mean we can get rid of the
:
On Feb 25, 2007, at 1:23 PM, Jeremy Boynes wrote:
I've been through the sca-api-r1.0 classes and tried to bring
them in line with the specification, including applicable
errata :-) Apart from one issue with @Property I think they are
now in alignment.
It would be good if a couple of other
).
--
Jeremy
On 2/25/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
I've been through the sca-api-r1.0 classes and tried to bring them in
line with the specification, including applicable errata :-) Apart
from one issue with @Property I think they are now in alignment.
It would be good if a couple
On Feb 26, 2007, at 10:56 AM, Jim Marino wrote:
FYI,
Now that we have the AutowireResolver in place, I'm going to look
into adding support for full SCA 1.0 autowire semantics in trunk.
This will mean we can get rid of the @Autowire tag (using
@Reference instead).
It might be an idea to
Passed with +1's from jboynes, jmarino, isilval, rineholt and no -1's
I'll ask the IPMC to ratify this.
--
Jeremy
On Feb 21, 2007, at 6:34 PM, Jeremy Boynes wrote:
The parent pom and buildtools were recently updated and as these
are used by all other modules I think we should formally
The @Property annotation currently has two non-standard attributes:
public String override() default may;
public String xmlType() default ;
I have marked these as @Deprecated but have not removed them as there
are references in our implementation. I think it should be fairly
easy to
On Feb 25, 2007, at 12:21 PM, Jim Marino wrote:
On Feb 25, 2007, at 12:14 PM, Jeremy Boynes wrote:
The @Property annotation currently has two non-standard attributes:
public String override() default may;
public String xmlType() default ;
I have marked these as @Deprecated but have
I've been through the sca-api-r1.0 classes and tried to bring them in
line with the specification, including applicable errata :-) Apart
from one issue with @Property I think they are now in alignment.
It would be good if a couple of other people could review these so we
can release them.
I'm little confused by this one. AIUI we have two configurations in
the physical world:
1) two co-located components connected by a wire
the PCS would contain two PCDs and a PWD for the connection
2) a component connected to the network via a binding
the PCD would contain a PCD with
Not sure about this DefaultSCAContainer thingy - that's not something
that's in trunk.
Based on the deployment model in the spec, contribution is totally
separate from running components. Contribution is about defining type
information in the domain, something that happens once (per type);
:
On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote:
I'm little confused by this one. AIUI we have two configurations
in the physical world:
1) two co-located components connected by a wire
the PCS would contain two PCDs and a PWD for the connection
2) a component connected to the network
On Feb 25, 2007, at 5:25 PM, Jim Marino wrote:
On Feb 25, 2007, at 5:11 PM, Luciano Resende wrote:
It would take me about a week, with help, it probably would be done
sooner... We could use the loan app, I was using the calculator
sample app.
Let me merge the latest stuff I have to trunk.
There's still a reference to parent Component in the builder API e.g.
+public ServiceBinding build(Component parent,
ServiceDefinition serviceDefinition,
LocalBindingDefinition
bindingDefinition,
I found the layout here a little confusing, especially on the
distinction between someone who want's to write an SCA application
and test/run it on Tuscany and someone who is looking to start
contributing to Tuscany itself.
I'd suggest the following changes:
* rename User Guide to Quick
What you are seeing is exactly the right behaviour (well, depending
on where the NPE is coming from, but generally the right behaviour).
We don't want application code accessing system components as that
leads to all sorts of nasty issues (like major security holes).
So my first question
I'm confused on working - doesn't this have duplicate names and
hence should not run?
I also struggle to see how this is a sample - what is this showing a
user?
Isn't this more of an itest and if so how about using the itest plugin?
--
Jeremy
On Feb 22, 2007, at 3:09 PM, Luciano Resende
Thanks to everyone who responded. I'll apply this later today.
--
Jeremy
On Feb 19, 2007, at 6:09 PM, Jeremy Boynes wrote:
In prep for release, I plan to update the project-wide parent pom
to reflect project-wide settings. Attached is the delta I plan to
make compared to M2 but in brief
On Feb 21, 2007, at 8:05 AM, Ignacio Silva-Lepe wrote:
I'm not sure I understand this. Looking at ConnectorImpl,
attachInvokers
calls createTargetInvoker on a target, and it is called when a
source is
being wired. Since ConnectorImpl performs the wiring in a single pass
(at least for a
This one:
https://svn.apache.org/repos/asf/incubator/tuscany/java/pom.xml
This is no longer used as the parent for any of the modules and the
profiles it contains are no longer valid so it does not really serve
any purpose. I'd propose we remove it ...
--
Jeremy
I have updated the sca pom to the new parent and as part of that
removed all the global declarations that it contained except for
those relating to sourcecheck. This decouples the sca modules from a
single parent in line with with our modularity goal.
As a result we should not need to make
On Feb 21, 2007, at 11:31 AM, Luciano Resende wrote:
Hi Jeremy
Wouldn't we still have scenarios where we would like to build
multiple
projects from the Tuscany project root ? (e.g sca and samples/sca or
sca/sca-api-r1.0 and kernel). If so, the profiles inside java/pom.xml
should be way
On Feb 21, 2007, at 12:56 PM, David Jencks wrote:
On Feb 21, 2007, at 12:38 PM, Jeremy Boynes wrote:
On Feb 21, 2007, at 12:05 PM, Matt Hogstrom wrote:
Regarding Bouncy Castle, IIRC they used to include the IDEA
algorithm in their distribution and provided a one-off for
Geronimo to use
On Feb 21, 2007, at 12:05 PM, Matt Hogstrom wrote:
Regarding Bouncy Castle, IIRC they used to include the IDEA
algorithm in their distribution and provided a one-off for Geronimo
to use to bypass the patent issue. Not sure if that is an issue or
not for Tuscany but just a heads up.
On Feb 21, 2007, at 12:50 PM, Luciano Resende wrote:
If we follow the pattern we have been using for SDO, DAS, once we
build the
project, the samples are built together to make sure changes on the
core
didn't break functionality used by the samples. In the case of
SCA, don't
we want to do
On Feb 21, 2007, at 1:25 PM, Raymond Feng wrote:
So are you going to publish SNAPSHOT versions of the different
modules to maven repo all the time? I assume the published
artifacts are the dependencies used by modules. Otherwise, those
who want to play with the source code won't have a
On Feb 21, 2007, at 3:14 PM, Mike [bondolo] Duigou wrote:
JXTA JSE currently uses only a very small subset of Bouncy Castle
which does not include the IDEA cipher algorithm. We are currently
using
- PKCS#1 Certificate generation.
- PKCS#10 Certificate Signing Request generation. (optional)
The parent pom and buildtools were recently updated and as these are
used by all other modules I think we should formally release them.
These are distributed through the maven repo rather than as a end-
user distribution. Please vote to approve the release content:
parent-pom
[tag]
On Feb 20, 2007, at 5:13 AM, [EMAIL PROTECTED] wrote:
Author: antelder
Date: Tue Feb 20 05:13:27 2007
New Revision: 509546
URL: http://svn.apache.org/viewvc?view=revrev=509546
Log:
Add lots of wsdl-java testcases
Cool stuff.
Do we need a software grant for this?
--
Jeremy
The quick answer for both of these is that we've not implemented them
yet so there's no code at the moment. Providing support for this is
part of the work going on around federation and input to that would
be appreciated.
The basic idea is that the federation is divided into two layers:
*
On Feb 20, 2007, at 9:04 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Does that mean, we need to state on the page below that Tuscany uses
Bouncycastle? Also (just out of interest), aren't the export
restrictions applicable against certain crypto operations rather
than a
library?
I had an
Section 1.8.4 defines an @Conversation annotation but as far as I
recall we removed that and replace it with @Conversational and
@ConversationAttributes. It was removed from our svn in r508819 so am
I right in thinking this is an error in the spec document?
--
Jeremy
On Feb 19, 2007, at 11:28 PM, James M Snell wrote:
All of the instructions can be found at [1]. Just step through that
and
it shouldn't take too long.
As far as I understand, each project is responsible for it's own
notifications.
- James
[1] http://www.apache.org/dev/crypto.html
Thanks.
On Feb 20, 2007, at 2:56 PM, Luciano Resende wrote:
Jim wrote:
Based on some of the deployment work that will be done, we actually
need to separate out the load phase into two, one which loads the
assembly model and another phase which resolves the dependencies
necessary to construct the
On Feb 20, 2007, at 1:02 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
There has been quite a bit of activity over the last month-and-a-
half enhancing the Kernel. Based on this work, I'd like to cut a
release of Kernel, the Standalone Runtime, the Webap Runtime, and
the Maven iTest
On Feb 20, 2007, at 10:01 PM, Jim Marino wrote:
I temporarily added support for monitoring using JDK logging in the
standalone server. I'd like to change this to using log4j as the
default. What do people think?
I thought you didn't like additional dependencies? :-)
I agree we should add
I don't think we should do this this way. This makes things
inconvenient for everyone by making filenames which are already long
even longer.
Instead, how about just renaming the client to calc?
--
Jeremy
On Feb 18, 2007, at 10:12 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Sun Feb
On Feb 19, 2007, at 9:45 AM, Jim Marino wrote:
There has been quite a bit of activity over the last month-and-a-
half enhancing the Kernel. Based on this work, I'd like to cut a
release of Kernel, the Standalone Runtime, the Webap Runtime, and
the Maven iTest Plugin as a stepping stone to
On Feb 19, 2007, at 3:45 PM, Luciano Resende wrote:
Quick comment...
I'd suggest three release bundles (source):
* kernel
* runtime (which includes the three runtimes you mention above)
* core samples
with binary distributions of the standalone assembly plus maven
artifacts (including the war
The spec jar.
--
Jeremy
On Feb 19, 2007, at 4:37 PM, Raymond Feng wrote:
Hi, Jeremy.
Does your comment apply to the whole release or just the SCA spec jar?
Thanks,
Raymond
- Original Message - From: Jeremy Boynes
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday
In prep for release, I plan to update the project-wide parent pom to
reflect project-wide settings. Attached is the delta I plan to make
compared to M2 but in brief the changes are:
* change the version to 2-incubating
* remove the semi-official repo on the WS zone (if still needed the
Going through the POMs for the release, I noticed that the JXTA
module has a dependency on bouncycastle which I believe is subject to
US export control. AIUI the ASF is allowed to export this under open
source provisions but we need to document it; there's an ASF page on
this here:
On Feb 19, 2007, at 9:15 PM, Luciano Resende wrote:
I have updated the patch and tried building DAS against it and
seemed ok.
One small question, around the versions :
-version1-incubator/version
+version2-incubating-SNAPSHOT/version
We are changing from incubator to incubating ?
I think we should leave the context name stuff in there.
We don't need to use it for backtracking URIs so that part should
change to just storing the absolute id (assuming it is actually
available).
However, the context support is still useful for backtracking across
contexts (for
On Feb 18, 2007, at 9:27 AM, Jim Marino wrote:
On Feb 18, 2007, at 9:23 AM, Jeremy Boynes wrote:
I think we should leave the context name stuff in there.
We don't need to use it for backtracking URIs so that part should
change to just storing the absolute id (assuming it is actually
Working on the runtimes, I ran into a few quirks due to the way URIs
are represented during deployment - as a list of path name parts
rather than as a URI.
I'd like to simplify this by replacing #getPathNames with #getURI
containing the URI of the composite being deployed. That will remove
Is there any difference now between a SystemComposite and an ordinary
one?
If not, can anyone think of an issue in removing
SystemCompositeImplementation and related classes?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL
to be done by
whomever calls the local deployer.
I wasn't able to test the standalone runtime as I still get a compile
error and the smoketest hangs.
--
Jeremy
On Feb 17, 2007, at 6:36 AM, Jeremy Boynes wrote:
Working on the runtimes, I ran into a few quirks due to the way
URIs are represented
Meeraj
I probably broke the standalone runtime this afternoon as I still had
it commented out of the build due to a compile problem:
[INFO] Compilation failure
/Users/jboynes/tuscany/java/sca/runtime/standalone/standalone-host/
src/main/java/org/apache/tuscany/runtime/standalone/host/
I had a thought for supporting two different alternatives for
specifying the jar to run to the launcher:
1) use the current syntax (jarFile), but see if it has any Maven meta-
data and if so use that to add dependencies
2) allow the user to supply an artifactId on the command line e.g.
$
Announced this morning:
The complete set of 1.00 specs is now available on the Supporters
section of www.osoa.org on this page:
http://www.osoa.org/display/Supporters/Draft+SCA+1.0
+Specifications
You do need to be registered as a supporter to access this page.
--
Jeremy
On Feb 16, 2007, at 9:41 AM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Fri Feb 16 09:41:47 2007
New Revision: 508516
URL: http://svn.apache.org/viewvc?view=revrev=508516
Log:
comment out standalone runtime as the SmokeTests hangs for me
I temporarily commented the standalone modules out
, Jeremy Boynes [EMAIL PROTECTED] wrote:
I have the new webapp runtime going but ran into an issue with the
structure of the calculator sample. In M2, the web calculator used
the same composite definition as the standalone version - it included
the client classes but that code was never executed
]
--
--
The same happens on sdo directory.
Adriano Crestani
On 2/15/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 10:15 PM, Adriano Crestani wrote:
I suppose it would download many dependencies before BUILD
SUCCESSFUL
On Feb 15, 2007, at 7:34 AM, Adriano Crestani wrote:
I deactivated my firewall, but it's still not working : (. I got it
with mvn
-X:
I don't know then sorry.
I just checked out https://svn.apache.org/repos/asf/incubator/tuscany/
java/das to /tmp on my machine, removed org/apache/tuscany
What about this in the parent pom?
prerequisites
maven2.0.4/maven
/prerequisites
Do we need to re-release that?
--
Jeremy
On Feb 15, 2007, at 8:39 AM, Raymond Feng wrote:
Moving to 2.0.5 won't require any pom changes.
Thanks,
Raymond
- Original Message - From: Dan
, Dan Murphy wrote:
Not a very clean suggestion one you've probably thought of
already
Publish the itest site as is (in the tuscany web space) and just
link to it
from the wiki.
On 14/02/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
I started on some documentation for the itest plugin
to add it to the nav in general - are there
any pointers for that?
--
Jeremy
On Feb 15, 2007, at 11:29 AM, Jeremy Boynes wrote:
Yeah :-)
I've deployed the generated site to http://incubator.apache.org/
tuscany/plugins/tuscany-itest-plugin/index.html but it has not
refreshed yet.
When it does
I have the new webapp runtime going but ran into an issue with the
structure of the calculator sample. In M2, the web calculator used
the same composite definition as the standalone version - it included
the client classes but that code was never executed. With the 1.0
model, there are
I deployed a SNAPSHOT of the plugin so you should no longer need to
build that.
The plugin depends on kernel from trunk and I have not deployed that
so you will need a current local build.
--
Jeremy
On Feb 14, 2007, at 7:57 AM, Raymond Feng wrote:
I think you need to build the itest plugin
[
https://issues.apache.org/jira/browse/TUSCANY-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473217
]
Jeremy Boynes commented on TUSCANY-1114:
This POM is also included in the samples distribution so mvn -N
On Feb 14, 2007, at 12:32 PM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Wed Feb 14 12:32:41 2007
New Revision: 507683
URL: http://svn.apache.org/viewvc?view=revrev=507683
Log:
strawman for @Intent annotation and usage
This flurry of commits was caused by me working with Mike Rowley to
I started on some documentation for the itest plugin and am wondering
how to integrate this with the stuff on the wiki.
I'm using the reporting in the maven-plugin-plugin to generate the
doco as it pulls all the goal information out of the Mojo so apart
from usage/examples the content is
to this
as soon
as I am done with somethings that I currently tied up with.
- Venkat
On 2/7/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Sebastien mentioned stabilizing tools like WSDL2Java and Java2WSDL
etc. recently and Kelvin and I were previously discussing moving
those tools out of SCA
On Feb 14, 2007, at 10:15 PM, Adriano Crestani wrote:
I suppose it would download many dependencies before BUILD
SUCCESSFUL, but
no dependency was download :s
Am I missing something or it should work this way?
It is meant to work this way. The top-level directory is just a
placeholder
It's not a dependency on Java6, it's a dependency on StAX
(java.xml.stream). That happens to be included in Java6, but it is
also included in Java5 Enterprise Edition and is available separately
for use on Java5 Standard Edition and J2SE 1.4.
It seems the SDO implementation now has a hard
On Feb 13, 2007, at 2:25 PM, Jim Marino wrote:
Log:
make the test domain name configurable
Hi,
I was just curious how you see the test domain configuration being
used. Sounds like it is the right thing to do since other runtimes
will need to allow it but I was wondering if there is
On Feb 12, 2007, at 4:48 AM, Valerio Schiavoni wrote:
On 2/9/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Fractal would be great :-)
Yes!
The tag for M2 is here:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-
incubator-M2/
i get this error when trying 'mvn -Peclipse
On Feb 12, 2007, at 2:48 AM, Simon Laws wrote:
Thanks Jeremy for commenting. I am of course now looking back
through the
archive and seeing that discussions are underway. Doh, sorry about
that.
From the distributed assembly [1], federated deployment [2], physical
component definition [3]
On Feb 12, 2007, at 9:46 AM, Jim Marino wrote:
On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
Does bring up of runtime include a successful run of iTest?
I was specifically referring to the standalone runtime but it
appears Jeremy also has the itest plugin working with the really
neat
I started to look at migrating the itests to 1.0 and found myself
struggling to understand just what they do. For example:
https://svn.apache.org/repos/asf/incubator/tuscany/java/testing/sca/
itest/specTest/src/test/java/org/apache/tuscany/sca/test/spec/
ComponentServiceReferenceTest.java
is
On Feb 12, 2007, at 7:57 AM, ant elder wrote:
FYI, our board report is due in two days. I've started adding some
text to
the empty template to get things going, feel free to edit/amend/
rewrite as
you see fit: http://wiki.apache.org/incubator/February2007
Thanks Ant. I added a couple of
On Feb 12, 2007, at 5:29 PM, Jim Marino wrote:
On Feb 12, 2007, at 5:17 PM, Rick Rineholt wrote:
You list the dependencies here in the parent pom then in child
poms you don't list the version's and they use the parents. One
means of controlling the version you're using across multiple
Trying to run the propertyTest I get:
Caused by:
org.apache.tuscany.core.databinding.javabeans.XML2JavaMapperException: o
rg.apache.tuscany.core.databinding.javabeans.XML2JavaMapperException:
No field or setter method to configure xml data
at
On Feb 12, 2007, at 6:02 PM, Jim Marino wrote:
Why are we testing complex property deserialization in an
integration test? I would think these should be unit tests and run
as part of the checkin build?
I think we need both.
Unit tests to check the basic conversions and which should also
On Feb 12, 2007, at 6:11 PM, Jim Marino wrote:
Agreed, however, it is not apparent from that test what is really
going on or what the intent is.
The propertyTest itest? Agreed.
I'm adding a bunch of stuff to that :-)
--
Jeremy
That was the account I added (and the email associated with it is the
one you sent this from). You might try logging out/in.
What is not working for you?
--
Jeremy
On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote:
Sorry Jeremy, but I'm not being able to access the developer
options.
, but didn't work. There is no option to
assign the
task to me.
Adriano Crestani
On 2/11/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
That was the account I added (and the email associated with it is the
one you sent this from). You might try logging out/in.
What is not working for you?
--
Jeremy
On Feb 6, 2007, at 12:11 PM, Jeremy Boynes wrote:
One of the things that is changing in the spec is the way in which
user code outside SCA can access SCA resources. The
CompositeContext and CurrentCompositeContext classes have been
replaced with ComponentContext. You can see a prototype
101 - 200 of 1236 matches
Mail list logo
