On irc this morning the question came up about which version of the
spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
of methods from 2.1 but not all.
Is this the case?
If so, are we allowed to release a jar which does not correspond to
an official version of the spec?
On Oct 2, 2006, at 12:01 PM, Frank Budinsky wrote:
Jeremy Boynes [EMAIL PROTECTED] wrote on 10/02/2006 02:43:22 PM:
On irc this morning the question came up about which version of the
spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
of methods from 2.1 but not all
On Oct 2, 2006, at 1:42 PM, Frank Budinsky wrote:
I don't see this as a big deal, but if others feel strongly that it is
bad, then we can take the two offensive methods out of the TypeHelper
interface and cast to TypeHelperImpl in a couple of places. I'd
suggest we
just make this change in
This changes the artifactId for the samples/das pom.xml and as a
result samples/das/companyweb no longer builds.
What should this parent artifact be - parent or tuscany-samples-das?
--
Jeremy
On Oct 2, 2006, at 9:45 AM, [EMAIL PROTECTED] wrote:
Author: bdaniel
Date: Mon Oct 2 09:45:38 2006
, Kelvin.
On 30/09/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
If we are going to start releasing these separately (or really just
being prepared to) then I think this would be worth doing. It's a
fairly simple change to do even now so should we do this for this
release?
Speaking of which, it looks
I noticed that the sdo distribution includes the maven plugin. I
don't think that's really needed as normally this would be downloaded
by maven from a pluginRepository rather that taken from some other
distribution. I'd suggest removing it.
--
Jeremy
On Sep 30, 2006, at 6:10 AM, Ignacio Silva-Lepe wrote:
Ok, I took a look. Fixing CompositeReference to not be interface/
method centric is not a big deal. However
CompositeReferenceTargetInvoker and
CompositeReferenceCallbackTargetInvoker are defined in terms of
PojoTargetInvoker which
If we are going to start releasing these separately (or really just
being prepared to) then I think this would be worth doing. It's a
fairly simple change to do even now so should we do this for this
release?
Speaking of which, it looks like EMF 2.2.1 is available from their
maven repo.
On Sep 29, 2006, at 12:43 AM, Jim Marino wrote:
Andy,
I checked in most of your patch with a few mods to remove a
dangling clogging dependency in the poms and minor checkstyle
stuff. I didn't check in ScaWebApplicationContext as Jeremy has
some changes going on that we'll need to
ScaWebApplicationContext in
since I have some internal uses of this right now.
Thanks!
andy
At 15:07 29/09/2006, Jeremy Boynes wrote:
On Sep 29, 2006, at 12:43 AM, Jim Marino wrote:
Andy,
I checked in most of your patch with a few mods to remove a
dangling clogging dependency in the poms and minor
On Sep 29, 2006, at 8:41 AM, Raymond Feng wrote:
Hi, Jim.
That's my proposal.
Venkat, I'm a bit worried to use ASM for this purpose. I agree with
Jim that annotating by parameters is consistent with CDI.
If there's no objections, I'll make the changes based on my proposal.
Is that with
On Sep 29, 2006, at 12:03 PM, Andy Piper wrote:
At 19:43 29/09/2006, Jeremy Boynes wrote:
On Sep 29, 2006, at 10:32 AM, Andy Piper wrote:
At 16:27 29/09/2006, Jeremy Boynes wrote:
I added (r451320) the utility and ScaWebApplicationContext - don't
know if the latter works.
I can't really
On Sep 29, 2006, at 2:08 PM, Ignacio Silva-Lepe wrote:
I am trying to run the hellowordwsclient sample by changing the
bound reference to use an interface.java, with which it runs ok.
But if I then add a callbackInterface I get the error below.
By using a callbackInterface, an
On Sep 26, 2006, at 6:26 AM, scabooz wrote:
- Original Message - From: Jeremy Boynes
[EMAIL PROTECTED]
On Sep 25, 2006, at 6:47 PM, scabooz wrote:
Sebastien did a good job enumerating the rationale for why the
binding.sca
exists in the specifications. Perhaps your concern is over
+1
--
Jeremy
On Sep 25, 2006, at 10:26 PM, Jim Marino wrote:
I would like to nominate Ignacio as a committer. He has done a
great deal of work adding non-blocking support into the Java SCA
runtime and is active in the community through things such as list
discussions.
Here's my +1.
What endpoint address should it return?
--
Jeremy
On Sep 26, 2006, at 8:09 AM, ant elder (JIRA) wrote:
WS binding returns wsdl with incorrect endpoint from ?wsdl
--
Key: TUSCANY-756
URL:
How about just newing up the instance and inject/mock its dependencies?
--
Jeremy
On Sep 26, 2006, at 11:12 AM, Luciano Resende wrote:
Hi All
I have created some jUnit for account services exercising the
persistence
layer using DAS. I would also like to extend the jUnit testcases to
option, as it was going to
bypass the
SCA wiring.. but if this is acceptable, it's pretty much what i had
as a 1st
pass to exercise the service.
- Luciano
On 9/26/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
How about just newing up the instance and inject/mock its
dependencies?
--
Jeremy
On Sep 26, 2006, at 1:06 PM, Jim Marino wrote:
XML serialization is better than java serialization - more portable.
Yes agreed it is more portable and should be an option but with
JMS were are not invoking across providers and we are dealing with
Java on the receiving end. Also, I think
On Sep 26, 2006, at 1:34 PM, Ignacio Silva-Lepe wrote:
Hmm, maybe I'm missing something, but AFAIK there is no interop in
JMS across providers, not to mention programming languages.
I believe I can use a JMS API to ActiveMQ to send a message to a C
or .NET program. I think some commercial
On Sep 26, 2006, at 1:55 PM, Ignacio Silva-Lepe wrote:
Ah, so I took the bait. So then the question is what does ActiveMQ
do when it gets a Java serialized message, e.g., an ObjectMessage?
It should be able to handle it, otherwise it would be subsetting
the JMS spec.
I think it delivers
On Sep 26, 2006, at 2:39 PM, Jim Marino wrote:
On Sep 26, 2006, at 2:24 PM, Rick wrote:
Thanks Jim for replying. The WebAppRuntimeImpl is not a component
implementation it boots up the sca runtime in a webaap
environment. Seems like chick/egg situation. Maybe I misunderstood.
I'm not
On Sep 26, 2006, at 12:01 PM, scabooz wrote:
Jeremy,
We need to bring these threads back together. Mike's comments
further reinforce the concepts.
Agreed. If I can summarize:
* the current need for binding.sca is to support rare cases of
overrides
* most assemblies will not need it
On Sep 26, 2006, at 6:38 PM, Jim Marino wrote:
\
My understanding of the init levels is that it's scope of
influence is for components in a composite.
Yes that's correct and if you have dependencies across modules,
it's not going to help. What we need is for the dependency thingy
Meeraj
On Sep 24, 2006, at 10:45 PM, Luciano Resende wrote:
There was some discussion in IRC about using mvn export to generate
source
distribution for Tuscany. I was wondering if this could could be
integrated
in the build process, using maven assembly plugin ? or some other
plugin
that I might
On Sep 23, 2006, at 1:27 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
On Sep 22, 2006, at 12:20 PM, Jim Marino wrote:
If we want interop can't we say use binding.ws since binding.sca
isn't really meant for interop but for optimization and
abstraction of the physical binding? I
On Sep 21, 2006, at 3:05 AM, Andy Piper wrote:
Trying to get up an running again. I can't run clean because of the
missing war plugin and I can't build because of SDO test failures.
Any clues?
Running org.apache.tuscany.sdo.test.CrossScopeCopyTestCase
Tests run: 1, Failures: 0, Errors: 1,
On Sep 21, 2006, at 6:57 AM, kelvin goodson wrote:
In trying to follow the release management draft guidelines at
http://incubator.apache.org/guides/releasemanagement.html I have a few
questions.
1) for a source distribution the guidelines say Check for version
Should we do the same for SDO? I see 2.9.3 in the following modules:
./samples/sca/echo.databinding/pom.xml
./sdo/impl/pom.xml
--
Jeremy
On Sep 19, 2006, at 10:44 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Sep 19 22:44:18 2006
New Revision: 448078
URL:
Upgrade to XmlSchema 1.1
Key: TUSCANY-736
URL: http://issues.apache.org/jira/browse/TUSCANY-736
Project: Tuscany
Issue Type: Bug
Reporter: Jeremy Boynes
XmlSchema 1.1 has been released so we should
] wrote on 09/20/2006 12:19:35 PM:
I think so.
If the folks from SDO side agree, I can go ahead to commit the
changes.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, September 20, 2006 6:50 AM
Subject: Woodstox
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=all ]
Jeremy Boynes reassigned TUSCANY-738:
-
Assignee: Jeremy Boynes
tuscany war plugin and default runtime location of extensions seem to be out
of sync
Are you adding them as dependencies of the war or as extensions
in the plugin?
If the former then I think this would be the expected and correct
behaviour - to make it work you would need to ensure everything was
moved to the webapp classloader. That has the downside of potentially
On Sep 20, 2006, at 11:00 AM, Raymond Feng wrote:
Hi,
Unfortunately, it references stax-api-1.0 from the pom.xml. Any
fixes or workarounds?
Yeah - in sca/pom.xml where we define the XmlSchema add in an exclude
for stax-api-1.0. That will mean things that reference XmlSchema but
not our
Components: Maven Plugins
Affects Versions: Java-M2
Reporter: Jeremy Boynes
The version of the runtime to use should be a configuration property of the war
plugin and not hard coded in Dependency.
Ideally, the default value for runtime version should come from a POM property,
perhaps
On Sep 19, 2006, at 7:21 AM, Lee Surprenant (JIRA) wrote:
Had problems trying to create a patch which created files...
If it helps, I believe they get included if you svn add the file
before using svn diff
--
Jeremy
-
Couple of comments inline - I'll leave other areas to Raymond.
On Sep 19, 2006, at 10:54 AM, Venkata Krishnan wrote:
1) I find that the DefaultValue in the class Property is supposed
to be
present as a Document instance.
//Added by Venkat for this mail : should the following line
On Sep 16, 2006, at 9:24 AM, Raymond Feng wrote:
Hi, Jeremy.
I have some uncommitted changes (databinding and core/spi) and plan
to check them in during the weekend.
Saw the big commit last night :) Are you current now and should I go
ahead with the moves?
--
Jeremy
[ http://issues.apache.org/jira/browse/TUSCANY-731?page=all ]
Jeremy Boynes closed TUSCANY-731.
-
Resolution: Cannot Reproduce
Looks like this has already been fixed
Update jsonRPC pom files to fix compilation errors
On Sep 18, 2006, at 11:00 AM, Raymond Feng wrote:
Which one do you prefer?
I prefer
b) http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
I have now moved the bindings, containers, databindings and idl
directories under sca/services
--
Jeremy
On Sep 16, 2006, at 1:49 PM, Jeremy Boynes wrote:
The pom hierarchy changes have now been done and the samples and
distributions re-enabled.
I would recommend removing all Tuscany
On Sep 17, 2006, at 2:37 AM, ant elder wrote:
From whats been posted previously about this I'm still not really
clear
exactly how things are going to work. Here's a couple of questions:
Are composites required to use the non-standard dependency element
in the
SCDL? I'm hoping not and that
How odd. I checked on my machine and I also have squiffy characters
in that file but I am able to build. I am on Intel OSX 10.4.7 with
$ java -version
java version 1.5.0_06
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed
On Sep 16, 2006, at 7:48 AM, Peter Cousins wrote:
I was thinking application components would receive the information
using push, which seems to be what you're thinking.
Yes.
I was thinking that the aspect components could access the context
information using pull, because their behavior is
The pom hierarchy changes have now been done and the samples and
distributions re-enabled.
I would recommend removing all Tuscany artifacts from your local repo
and doing a full build from java once you update to r446951
--
Jeremy
On Sep 16, 2006, at 8:02 AM, Jeremy Boynes wrote
To allow the build to use the tuscany-war-plugin to build the samples
I needed to remove the extensionstrue/extensions element from the
plugin configuration. Things still seem to work but is this a valid
thing to have done?
--
Jeremy
I think that's the same question Meeraj just asked :-)
--
Jeremy
On Sep 15, 2006, at 10:41 AM, ant elder wrote:
The webapp war plugin is putting all the dependent jars for
extensions in
the extensions directory. I don't think they will get picked up
there, for
now I've been copying them to
On Sep 15, 2006, at 10:35 AM, ant elder wrote:
It looks like extensions don't work in webapps because LauncherImpl
getInstallDirectory is returning a bad File. The URL obtained for the
LauncherImpl class is:
jar:jndi:/localhost/scriptWebapp/WEB-INF/tuscany/boot/core-
On Sep 15, 2006, at 12:21 PM, Rick wrote:
I thought the general direction by default was to really have no
dependencies/extensions packaged.
+1
That the runtime (possibly by identifying in the application scdl
the extensions) then using the dependency information in the SCDL
would
Thanks Rajith
I have a question on the thought behind sca:databinding. In Tuscany
we have a databinding framework that allows us to convert between
different data formats on a wire - for example, a component can call
out using a SDO to a component that is expecting a JAXB object and
the
[ http://issues.apache.org/jira/browse/TUSCANY-723?page=all ]
Jeremy Boynes closed TUSCANY-723.
-
Resolution: Fixed
Patch applied - thanks
Repository entry missing in SCA tools
-
Key: TUSCANY-723
On Sep 13, 2006, at 2:09 AM, Venkata Krishnan wrote:
+1 for the Calculator Sample
With respect to reuse, I am imagining as follows: -
- that overall there is a directory called 'sample\interface' that
will
contain all service interfaces (java, wsdl and so on ) that are
going to
used in
It works for me - you may need newer versions of Axis or something.
I'm on IRC if that would help work through this.
--
Jeremy
On Sep 13, 2006, at 6:54 AM, Ignacio Silva-Lepe wrote:
After getting a newer copy of axiom-api-SNAPSHOT.jar in my repo, to
get rid of a previous class not found error
On Sep 13, 2006, at 7:50 AM, Liu, Jervis wrote:
Hi, I understand there is an on-going process in the spec group to
define a JAX-WS integration with SCA, it would be interesting to
look into this context issue from the aspect of JAX-WS services.
According to JAX-WS spec, a thread local
[
http://issues.apache.org/jira/browse/TUSCANY-642?page=comments#action_12434472
]
Jeremy Boynes commented on TUSCANY-642:
---
CommentsOut patch applied - thanks
Composite references and services - model and runtime representations
On Sep 13, 2006, at 4:48 AM, Peter Cousins wrote:
I agree that business application logic should not use this context
information. Ideally, there would support for users to write simple
plugins that could run inside the call context as aspects (in the AOP
sense). Only the aspects would
1.0-incubator-M2 rfeng, dkulp, lresende, bdaniel, kgoodson
0.95-incubatorvenkat, aborley
I included dkulp's proposal on the format.
Looks like the preference is for 1.0-incubator-M2 so I will start
to update the poms to that.
--
Jeremy
On Sep 8, 2006, at 10:17 AM, Jeremy Boynes wrote
[
http://issues.apache.org/jira/browse/TUSCANY-715?page=comments#action_12434221
]
Jeremy Boynes commented on TUSCANY-715:
---
Patch applied - thanks
Update tools module to use latest XmlSchema version
On Sep 12, 2006, at 10:18 AM, Venkata Krishnan wrote:
Hi Jeremy,
I have submitted a patch for this. Please take a look and let me
know if it
is ok.
Also, in the IRC you were mentioning about some bug in the wsdl
module that
hacked to fix and you wanted me to take a look. Could you
Please can we make sure the ASF header is included on the source files.
--
Jeremy
On Sep 12, 2006, at 1:57 PM, [EMAIL PROTECTED] wrote:
Author: frankb
Date: Tue Sep 12 13:57:00 2006
New Revision: 442701
URL: http://svn.apache.org/viewvc?view=revrev=442701
Log:
Fix for TUSCANY-627
Added:
On Sep 12, 2006, at 3:18 PM, Raymond Feng wrote:
Hi, Peter.
Thank you for bringing this requirement to the table even though we
don't have this feature in Tuscany yet.
First of all, I think it's a valid requirement to support context
propagation for service invocations, especially for
I have modified most of the POMs to make the version 1.0-incubator-M2-
SNAPSHOT but I have not yet done the sca samples and distribution -
they are commented out of the build for now. I plan to get to them
later tonight or tomorrow.
One thing that made this quite painful is the number that
On Sep 11, 2006, at 1:24 AM, Andrew Borley wrote:
Not trying to open any worm-cans, but having 1.0 at the start of
the name
makes it look like it's a 1.0 release, when in actuality it's still a
milestone release - is this the effect we're looking for? Is the
code at a
1.0 level of quality,
Thanks !
On Sep 10, 2006, at 11:55 PM, Meeraj Kunnumpurath wrote:
Can I volunteer?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Sep 11, 2006, at 3:57 AM, kelvin goodson wrote:
Now in the java world here's a nasty catch, one side effect of
this which,
given the way we run things, only occurs in a maven test run, and
not when
running junits in eclipse is that one unit test can affect a later
one. In
maven the
Lee
Unless they've changed things again, that class is only available in
recent snapshots - can you check which repo mvn downloaded XmlScheam
from (it should be the M1 repo at http://people.apache.org/repository
and *not* the M2 one). The POM warnings are not fatal, they just
prevent
I was somewhat surprised by this change as the commit message
provides no indication that an entire module was commented out of the
build. This also causes some other modules to fail if an old version
of this module is removed from someone's local repo.
Please can we make sure that commit
They seem to be publishing concurrently to
http://people.apache.org/repository/ws-commons/jars/
and
http://people.apache.org/repository/org.apache.ws.commons/jars/
The former is probably for legacy applications as the pom in the
trunk (at least for XmlSchema) now has a groupId of
Tools
Reporter: Jeremy Boynes
Priority: Critical
The API for XmlSchema has changed since the 1.0.2 version. We are using a newer
version due to updates in Axis2 and the tools need to be modified to use its
new API.
--
This message is automatically generated by JIRA
Do you want to include these in the M2 release or should we based
that on the 2.0.1 API?
--
Jeremy
On Sep 11, 2006, at 3:02 PM, Frank Budinsky wrote:
Hi,
I just wanted to mention that a feature being dropped into the SDO
Java
codebase involves adding two new methods to the TypeHelper
On Sep 9, 2006, at 10:42 PM, Jim Marino wrote:
I thought we were working off snapshots of SDO and that we had
decoupled the build process? If not, can we remove this from the
main build?
That's the plan but we need to finalize the release version id before
we can do so. Until then you
We have quite a few samples that have copies of the same components
and the services that they implement. I think we should separate the
components from the samples themselves and move them to a common
sample-components project that just contains the implementations;
this could then be
On Sep 10, 2006, at 12:01 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Sun Sep 10 12:01:37 2006
New Revision: 441986
URL: http://svn.apache.org/viewvc?view=revrev=441986
Log:
Add XML schema loading with Apache XmlSchema to WSDL IDL to
introspect JAX-WS Wrapper Style operation
We had a
Any more thoughts on this? Most popular so far is 1.0-incubator-M2
--
Jeremy
On Sep 8, 2006, at 10:17 AM, Jeremy Boynes wrote:
Before publishing artifacts to the snapshot repo I need to make
sure all the versions contain incubator which means updating all
the POMs. I would like to change
It might be unusual but it is valid - I think we should track normal/
abnormal completion like Raymond suggested.
--
Jeremy
On Sep 8, 2006, at 8:11 PM, Jim Marino wrote:
Originally we decided against this, as returning exceptions like
this is really bad coding convention and I can't think of
I sent the location to tuscany-private
--
Jeremy
On Sep 7, 2006, at 9:57 PM, Raymond Feng wrote:
Can you give us a pointer where to get the clover license for apache?
Thanks,
Raymond
- Original Message - From: Jeremy Boynes
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent
On Sep 8, 2006, at 6:19 AM, Frank Budinsky wrote:
Well, even the most fanatical VI user I know has moved to using an
Eclipse
VI plugin now, so I really can't imagine very many (other than
people that
also spend their weekends carving wheels out of stone :-) really
using it
these days. As
On Sep 8, 2006, at 8:39 AM, Andrew Borley wrote:
Thanks Ant - do you know how I get the right access privileges to
be able to
assign or close jira issues?
Done.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On Sep 8, 2006, at 8:47 AM, ant elder wrote:
I think right now Jeremy may be the only one with JIRA admin
privileges for
Tuscany, i can't see where I can add these in JIRA anyway. If that
is the
case I'm not sure why, is there any reason why all committers can't
have
admin access?
I
Already did that a while ago.
--
Jeremy
On Sep 8, 2006, at 9:01 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Could you pls do that for me as well (if that is ok)?
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 08 September 2006 16:46
To: tuscany-dev
Done
--
Jeremy
On Sep 8, 2006, at 9:03 AM, kelvin goodson wrote:
ditto ;-)
On 08/09/06, Meeraj Kunnumpurath [EMAIL PROTECTED] wrote:
Jeremy,
Could you pls do that for me as well (if that is ok)?
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 08
No, that was Meeraj, I just did yours.
--
Jeremy
On Sep 8, 2006, at 9:11 AM, kelvin goodson wrote:
Sorry, thanks Jeremy, I guess I just hadn't logged out to see the
update
On 08/09/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Already did that a while ago.
--
Jeremy
On Sep 8, 2006, at 9
On Sep 8, 2006, at 9:28 AM, Raymond Feng wrote:
Hi,
I'm a loyal Eclipse user (never have a chance to try IDEA) and let
me try to be constructive here.
Thanks - I appreciate the constructive comments :-)
What are issues here due to the conflict of maven and Eclipse? I
observed two:
Before publishing artifacts to the snapshot repo I need to make sure
all the versions contain incubator which means updating all the
POMs. I would like to change this to the version of this next release
and so would like input on what that should be:
[ ] 1.0-M2-incubator
[ ]
On Sep 8, 2006, at 10:43 AM, Venkata Krishnan wrote:
Hi Jeremy,
'0.95-incubator'.
I vaguely recollect reading some mail that mentioned that M* is
necessary in
incubator releases.. if this is true then...
It is not - incubator is but that's all.
--
Jeremy
I think the attachment was stripped - I'd suggest adding it to a JIRA.
--
Jeremy
On Sep 8, 2006, at 10:55 AM, Andy Piper wrote:
Multi-arg patch attached.
andy
At 08:33 08/09/2006, Jim Marino wrote:
I've updated the Spring sample to show remote wiring between to two
Spring composite
It the things maven uses to make archives (e.g. jars) and it lives at
codehaus.
Our parent pom includes the codehaus snapshot repo as a
pluginRepository but perhaps this is a normal dependency and not a
plugin - which module are you building?
--
Jeremy
On Sep 8, 2006, at 12:11 PM, Frank
I've published a coverage report for the kernel here:
http://www.buildtuscany.org/index.html
It is currently showing 63.7% coverage which I have to admit is
better than I expected and makes me optimistic that we can hit a 75%
target for this release.
One of the big things pulling the
On Sep 7, 2006, at 1:06 AM, Andy Piper wrote:
At 06:25 07/09/2006, Jeremy Boynes wrote:
snipping a little ...
Would it be possible to break this down a little - there are changes
in there to the startup code and to the Spring container - is it
possible to separate those so
By embracing Eclipse we alienate everyone else who does not use it
- forcing people to install, learn, and now bugfix Eclipse if they
want to contribute to Tuscany is not very open. Please bear in mind I
am not advocating people use IDEA either - I want to make sure that
the project is
Thanks Raymond - comments inline, quite a bit snipped though.
On Sep 6, 2006, at 11:27 PM, Raymond Feng wrote:
2) Identify parameters that are required to be transformed?
From the wiring fabrics, the databinding interceptor receives an
Object[] as the input and produce an Object as the
On Sep 7, 2006, at 6:46 AM, Jim Marino wrote:
On Sep 7, 2006, at 6:35 AM, ant elder wrote:
On 9/7/06, Jim Marino [EMAIL PROTECTED] wrote:
On Sep 7, 2006, at 2:01 AM, ant elder wrote:
On 9/7/06, Raymond Feng [EMAIL PROTECTED] wrote:
1) Define compatiblity of two service contracts that can be
On Sep 7, 2006, at 9:32 AM, Raymond Feng wrote:
2) Identify parameters that are required to be transformed?
From the wiring fabrics, the databinding interceptor receives an
Object[] as the input and produce an Object as the output. We
need to figure out which parameter needs to be
with IDEA and Eclipse so I'm tempted to go with that - any objections?
--
Jeremy
On Sep 5, 2006, at 8:14 AM, Jeremy Boynes wrote:
On Aug 16, 2006, at 2:49 PM, Jim Marino wrote:
2) SCA Core (spi, core, hostutil, test, plus apis once that
refactor is done)
Features I would like to see complete
[
http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433190
]
Jeremy Boynes commented on TUSCANY-688:
---
Patches applied - thanks.
I did have a slight problem with the sample before applying the sample patch
On Sep 7, 2006, at 11:26 AM, Raymond Feng wrote:
I propose that we change the Operation model as follows:
Operation
--- name (Name of the operation)
--- inputType (For java, it's a DataType representing the Object
[]. For WSDL, it could be a DataType representing the top-level
request
[
http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433202
]
Jeremy Boynes commented on TUSCANY-688:
---
The duplicate problem seems to occur if I run the build twice:
$ mvn -o clean
$ mvn -o package
# OK
$ mvn -o
On Sep 7, 2006, at 12:10 PM, Raymond Feng wrote:
and
physicalType: OMElement.class
logicalType: QName{http://example.com, order}
When we try to populate the OMElement for order with Customer and
String, we have to create child OMElements under order and the
child elements requires
You lost me.
On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote:
Maybe we can broaden relative path semantics therefore it may not
necessarily be mandatory any longer to introduce scdlResource.
e.g. the ClassPath is dir1, dir2, jar1, jar2.
Even if a resolved relative path is
as that for bootLibs (Most of the
stuff
in the plugin is factored out from the Maven dependency plugin)
Ta
Meeraj
From: Jeremy Boynes [EMAIL PROTECTED]
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany war plugin
Date: Tue, 5 Sep 2006 19:41:13 -0700
On Sep 5
501 - 600 of 1236 matches
Mail list logo
