One issue I see is diversity. The proposed PMC seems very dominated
by a single vendor as, if I understand the affiliations correctly, we
have:
Andrew Borley (IBM)
Andy Grove (RogueWave)
ant elder (IBM)
Ignacio Silva-Lepe (IBM)
Jean-Sebastien Delfino (IBM)
kelvin goodson (IBM)
Luciano Resende
On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote:
Hi Jeremy,
Here is a problem that most of us are facing with the Trunk and is
hindering
us to effectively contribute to the trunk. I see there is one
solution that
has been proposed to making this simpler with some compromises. If
This is an indication that the vote was initiated prematurely, before
agreement was reached. I would suggest withdrawing it until
individuals' concerns have been addressed unless we think this issue
is irreconcilable and that a decision should be forced.
--
Jeremy
On Mar 28, 2007, at 3:24
Nice diagram, Raymond, thanks for putting this together.
What I'm struggling with is that this seems fairly similar to the way
the code is organized now. Most of the boxes there already exist and
have interfaces to abstract away their implementation. Everything in
Cross-cutting system
been here before - r419320
--
Jeremy
On Mar 27, 2007, at 2:35 PM, Davanum Srinivas wrote:
the wholesale, revolutionary rewrite of the kernel...Pointers please
to exact emails.
thanks,
dims
On 3/27/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Nice diagram, Raymond, thanks for putting this together
On Mar 24, 2007, at 6:30 AM, Davanum Srinivas wrote:
Using assemblies is ok. It does not have to be published. Once
everyone is in the same bandwagon, then it's ok to publish. Till then,
please find a way to work with assemblies w/o having to rely on
published artifacts. If this is a maven
On Mar 23, 2007, at 2:11 AM, Luciano Resende wrote:
Hi Jeremy
For the assembly proposal, are you suggesting something like :
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/
sca/distribution/tss-sample/
Something like that, yeah.
You want to rely on things that are
On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote:
Jeremy
So, having these assemblies modules sounded interesting to me
until the
moment you said you want to base them on deployed artifacts... we
have never
had a habit of publishing SNAPSHOTS for all possible artifacts, and
even the
I think we should tag and deploy SNAPSHOTs of the revision used for
the demo - that way people can build as much or as little as they
wish. If you can post the list, I get those modules tagged and
deployed later today.
--
Jeremy
On Mar 22, 2007, at 6:13 AM, Meeraj Kunnumpurath wrote:
/runtime/
java/sca/services/
java/sca/contrib/discovery/
java/sca/contrib/discovery/jms
java/sca/console/
java/sca/core-samples/
java/distribution/sca/demo.app
java/distribution/sca/demo/
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22
We know from M2 experience and the number of profiles in the
integration branch that a top-down, build-everything approach does
not work.
We also know from practical experience that people struggle building
modules.
I believe there is a middle ground that supports both approaches;
* have
On Mar 22, 2007, at 8:47 AM, Simon Laws wrote:
Ok, cool, so I can run a simple app in a single VM. Let me try it
out.
Just to set expectations, I don't think the system configuration in
the default runtime has been switched over to the federated deployer
yet. So if you run the calc sample
On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
+1.
I think it's in line with the proposal in my response to Meeraj.
One question: For a bundle to reference a module in the Tuscany
source tree, do we really have to copy (or use svn:externals
property) if it points to a location (under
On Mar 22, 2007, at 11:19 AM, Simon Laws wrote:
stupidquestion
When you talk about flattening the module hierarchy do you mean this
literally in svn (which I like the sound of as I can never find
anything in
all the nested dirs - my inexperience showing) or is this some virtual
flattening?
On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
Jeremy. This sounds like a simpler approach than what is there now.
I like
the idea but a question.
1) move everything that does not logical depend on
org.apache.tuscany:sca:1.0-incubating to contrib
from your previous definition do you mean
For those not really familiar with Maven there is a lot of good
information in this book:
http://www.mergere.com/m2book_download.jsp
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Well, Meeraj and Jim did the real work.
OK, the circle is now complete :)
On Mar 22, 2007, at 2:33 PM, Meeraj Kunnumpurath wrote:
Ta, Actually Jeremy and Jim did most of it.
-Original Message-
From: Kevin Williams [mailto:[EMAIL PROTECTED]
Sent: 22 March 2007 20:44
To:
I have some cleanup work to do on work and on scopes but I would
expect to get that done in the next day or so (ready for the next
alpha).
On the physical model, I would like to get the bytecode based IFP
going to simplify the PCD message. We also need to get complex
properties working.
Srinivas wrote:
Jeremy,
I'd like to see some progress on the community front! Let's see this
approach agreed upon and fleshed out a bit more.
thanks,
dims
On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
On Mar 22, 2007, at 12:31 PM, Simon Laws wrote:
Jeremy. This sounds like a simpler
On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote:
I've confirmed that IBM, the copyright holder, gives permission to
Apache
to reuse the two EMF files in question.
Thanks for confirming this.
I've opened TUSCANY-1185 to contribute the two base classes,
provided in
an attachment.
On Mar 21, 2007, at 10:27 AM, Frank Budinsky wrote:
Jeremy, I don't understand your last comment:
I can't ack this for the ASF - that has to be done by an Officer as
described in the IP Clearance process. They would probably want
something official from IBM (Software Grant).
By attaching
On Mar 20, 2007, at 4:09 PM, Raymond Feng wrote:
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.
Which actually the correct behaviour, just not 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
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
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
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
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
..
}
... etc.
}
So, the question is, what kind of license do we need in these two
Tuscany
classes?
1. Apache.
2. Apache + Eclipse
3. Other?
Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.
Thanks,
Frank.
Jeremy Boynes [EMAIL
In WireAttacher, I think we need to pass the source component in the
target attach operation because:
* for callbacks the target may need to know source information (e.g.
for routing)
* for optimized wires it may be able to do nothing
I'll make this change. Given the signatures will be so
copying is addressed? I
also wonder where is the fine line between providing a changed
method vs
a copied method with a change in a subclass? For example, what if
one of
the copied methods was only 3 lines and we changed one of them? Is
that
still a copy?
Thanks,
Frank.
Jeremy Boynes
On Mar 19, 2007, at 4:17 PM, Raymond Feng wrote:
Hi,
I'm trying to bring up a databinding integration test with itest
plugin. But it seems that the MavenEmbeddedRuntime doesn't support
deployment of extensions, neither does the standalone runtime.
What's the plan to add this feature
Sorry about that - STATELESS should be working again.
--
Jeremy
On Mar 19, 2007, at 2:41 PM, [EMAIL PROTECTED] wrote:
Author: isilval
Date: Mon Mar 19 14:41:39 2007
New Revision: 520115
URL: http://svn.apache.org/viewvc?view=revrev=520115
Log:
Avoid problems with other scopes
Modified:
was simply the result of using that generator
against
our own schemas.
Regards, Kelvin.
On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
I have
+1 it was there for type safety in runtime but if it makes it hard to
marshall no problem removing it
I removed a couple of leftover references to GROUP in the JavaDoc
as well
--
Jeremy
On Mar 18, 2007, at 1:46 PM, Meeraj Kunnumpurath wrote:
Hi,
I have been looking at the type parameter
have temporarily commented out scopes other than composite
- normal service will be resume shortly.
--
Jeremy
On Mar 13, 2007, at 1:55 PM, Jeremy Boynes wrote:
On Mar 12, 2007, at 11:47 AM, Jeremy Boynes wrote:
On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:
Firstly, transporting Scope
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/http://
On Mar 17, 2007, at 2:49 PM, Jeremy Boynes wrote:
Instead, I'm going to move the work context into the invocation
message so that is available as part of the invocation chain and
make it the responsibility of the invoker to tunnel that through
the user component if necessary. That will also
Ah, apollogies for that. I have to admit that I'm a cvs person at
heart so
just getting to grips with svn. I ljust ooked up svn move and got
that why
didn't I look there first feeling, so I'll remember that for next
time.
Thanks for taking the time to explain.
If you're new to Subversion
Why?
On Mar 16, 2007, at 9:26 AM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Fri Mar 16 09:26:05 2007
New Revision: 519040
URL: http://svn.apache.org/viewvc?view=revrev=519040
Log:
Change the ArtifactResolver interface to take Contribution instead
of URI
Modified:
On Mar 16, 2007, at 9:46 AM, Raymond Feng wrote:
Hi,
Contribution is the model object that hosts the metadata and
introspected result for the contribution. Logically, you can use
the URI of the contribution to look up the ContributionService to
get the Contribution. I found it simpler
Raymond
There are two sets of issues here:
* How to support SCDL extensibility elements
* How to support import.sdo as an instance of that
As seed for discussion of the second, I don't think @Reference is the
right way to declare access to a HelperContext - this seems more like
a resource.
On Mar 16, 2007, at 4:50 PM, Jim Marino wrote:
On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
After thinking about it, I'm starting to think that a better place
for it is
under /java/sca/services.Thoughts ?
That was exactly why I asked :-) I think it should be under
services and
On Mar 16, 2007, at 5:55 PM, Daniel Kulp wrote:
The snapshot that was deployed today seems to be very broken. I
haven't
had a chance to look into it at all. The quick fix is to use the
last snapshot or last relase. If you require the 2.2 features, set
the
version to:
IIRC we do
On Mar 16, 2007, at 2:03 PM, Antollini, Mario wrote:
Hello Meeraj,
I have read several emails and I got to know that you are working
on the
Discovery service. I am very interested in this topic and I will
like to
get a better understanding about it.
Great to have you involved.
I have
I like the timing - about a month, 6 weeks at the most is a good
window between releases in early stages like we are.
I agree federation is the big delta between now and then - we should
have by then
* federated classloading (with multi-classloader support)
* federated scope
* the changes
It's not going right now as we were planning to integrate with the
contribution service (i.e. you would contribute the extension just
like any other composite, either through the contribution API or by
doing something like dropping it into a directory the contribution
service was
On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
I forgot to mention that the reason that so many XML files have
suddenly
appeared is that I've take the files that currently live in /
interop and
renamed and refactored them.
Thanks for explaining as this did look a bit odd.
One way to avoid
Resende
http://people.apache.org/~lresende
On 3/15/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
I like the timing - about a month, 6 weeks at the most is a good
window between releases in early stages like we are.
I agree federation is the big delta between now and then - we should
have
On Mar 15, 2007, at 3:49 PM, robert burrell donkin wrote:
On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
The Tuscany community recently voted to release version 1.0-
incubating of our implementation of the API classes for the OSOA
specification V1.0:
http://mail-archives.apache.org
On Mar 15, 2007, at 10:35 PM, Raymond Feng wrote:
Hi,
When I try to register a HelperContext component for the composite
from databinding-sdo extension, I found that I need to access the
ComponentManager which is in the core. Can we promote it to SPI?
Makes sense.
BTW, do we still
I cleaned up the doco a little - can you take a look and see if it
makes sense (and if not fix it :-) )
--
Jeremy
On Mar 14, 2007, at 10:01 AM, Ignacio Silva-Lepe wrote:
Hmm, yeah, I remember doing something like that earlier with the
distribution, but I thought things had changed. In any
Thanks for catching the launcher name.
The application jar though is calc.jar
--
Jeremy
On Mar 14, 2007, at 11:03 AM, [EMAIL PROTECTED] wrote:
Author: isilval
Date: Wed Mar 14 11:03:12 2007
New Revision: 518245
URL: http://svn.apache.org/viewvc?view=revrev=518245
Log:
use correct file names
[
https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Boynes updated TUSCANY-1002:
---
Comment: was deleted
When redefining sdoModel.xsd in XSDHelperImpl, special
[
https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Boynes updated TUSCANY-826:
--
Comment: was deleted
Containment cycle should result in Exception
I deleted the comments.
--
Jeremy
On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote:
I have spoken to ant, who has deleted the user. Ant has raised a
JIRA,
https://issues.apache.org/jira/browse/INFRA-1193, to clean up these
2 JIRAs.
Kelvin.
On 13/03/07, Frank Budinsky [EMAIL PROTECTED]
see how to get to a place in JIRA that allows that?
...ant
On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
I deleted the comments.
--
Jeremy
On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote:
I have spoken to ant, who has deleted the user. Ant has raised a
JIRA,
https
On Mar 13, 2007, at 4:55 AM, Jim Marino wrote:
Hi Meeraj,
I've been working on getting the WireAttachers going for
PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added
PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for
callbacks, as they will be used to
On Mar 12, 2007, at 1:28 PM, [EMAIL PROTECTED] wrote:
incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/
tuscany/core/model/physical/instancefactory/
InjectionSiteType.java (with props)
How about using j.l.annotation.ElementType?
--
Jeremy
Meeraj asked me offline what I meant by using ElementType so I added
this strawman for a mapping from something in SCA land (a callback,
reference or property value) to a Java injection site (field, method,
ctrArg). In the end it doesn't use ElementType at all...
Meeraj, I hope this makes
, 2007, at 10:16 PM, Jeremy Boynes wrote:
Firstly, transporting Scope is not enough on its own as there is more
than one COMPOSITE scope. The builders used to get this from the
deployment context but with federation it will need to be passed to in
the PCD. I think instead we should treat
On Mar 11, 2007, at 10:16 PM, Jeremy Boynes wrote:
Firstly, transporting Scope is not enough on its own as there is
more than one COMPOSITE scope. The builders used to get this from
the deployment context but with federation it will need to be
passed to in the PCD. I think instead we
On Mar 12, 2007, at 4:05 PM, ant elder wrote:
He didn't give much detail, and hasn't replied when i asked for
more about
what he was proposing (unless I missed the email?)
Got better things to do - most people understood it which was enough
for me. You might want to read up on the
and will not need to determine the information
from the live component instance. The remaining usage is virtually
all test cases for the component implementations and their
corresponding builders.
--
Jeremy
On Mar 10, 2007, at 9:24 PM, Jeremy Boynes wrote:
I've made a few changes today to simplify
atm, the PCD contains the URI of the component and the definitions
for all its services and references. The Java sub-class of this adds
the scope, classloader id, and room for the bytecode for the
InstanceFactory. I'd like to suggest a couple of changes to this:
Firstly, transporting Scope
On Mar 9, 2007, at 8:35 AM, Jeremy Boynes wrote:
We had +1's from jmarino, meerajk, isilval, lresende, jboynes
-0 from jsdelfino
No technical issues were made related to the Parent POM, Kernel and
Runtime so they are passed.
There was confusion over the use of the composite plugin
I've made a few changes today to simplify the lifecycle handling for
component instances. Previously, responsibility for this was shared
between the AtomicComponent implementation, the ScopeContainer
implementation and the TargetInvoker implementation. I have change
this to essentially
I have uploaded a second amendment of core-samples that reverts to
using a plain jar type for the common composite (r516441) to avoid
the confusion over a composite type. I ran the calc and webcalc
samples on OSX with Tomcat.
--
Jeremy
On Mar 8, 2007, at 10:32 PM, Jeremy Boynes wrote:
I
Subclassing in the model makes sense to me.
I don't think anything would need to be added to AbstractSCAObject -
by the time we get to the runtime all of the intents and policySets
should have been processed and converted into wires with the
necessary interceptors.
--
Jeremy
On Mar 9,
And as I forgot to vote, +1
--
Jeremy
On Mar 9, 2007, at 7:57 AM, Jeremy Boynes wrote:
I have uploaded a second amendment of core-samples that reverts to
using a plain jar type for the common composite (r516441) to
avoid the confusion over a composite type. I ran the calc and
webcalc
be withdrawn until resolved. The
core-samples have been updated not to use it and have since been run
on OSX and Tomcat but I think we should extend the vote for the
samples another 24 hours for people to confirm.
Thanks everyone
--
Jeremy
On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:
I have
On Mar 9, 2007, at 9:01 AM, Luciano Resende wrote:
Jeremy
As for the samples, I'm still seeing the issue/exceptions on tomcat
5.5.20 and tomcat 6.0.10 in windows, did you change anything on the
samples
to address them ?
Yes - Maven's WAR plugin only adds certain dependency types to the
On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:
What happens in a single node case? Will the controller always be
present?
Yes - just co-located with its sole runtime.
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
-1
This is contrary to our modularity policy and includes a bunch of
modules that are not relevant. There are modules in here that are at
different version levels and merging them in a single reactor build
will cause problems as mvn adjusts versions to those the reactor.
This will cause
Thanks
Perhaps we could set up a side tree with a number of projects that
built different assemblies (including all the dependencies people
wanted for them). That way the build-it-all approach could be used
for those assemblies and we wouldn't hit the version skew problems
doing it
? At least
this is
what I saw while reviewing the core-samples release candidate, a
calculator-2.0-alpha-incubating.composite that is actually an archive
containing common files for the calculator sample application.
Thoughts ?
On 3/2/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
I made a start
of _ar!
Thanks,
Raymond
- Original Message - From: Jeremy Boynes
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, March 08, 2007 10:11 PM
Subject: Re: Composite archive name confusion, was: Re: sca-
composite plugin
Any suggestions?
--
Jeremy
On Mar 8, 2007, at 7:55 PM
-incubating/
--
Jeremy
On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:
I have posted release candidates of the 2.0-alpha kernel release on
my home directory at people.apache.org and uploaded the artifacts
to the maven repo for:
SCA Parent POM 1.0-incubating
SCA Composite Plugin 1.0
I have fixed the two technical issues here (the location of the
parent pom and the type of the composite) and uploaded a new copy of
the files for core-samples.
--
Jeremy
On Mar 8, 2007, at 4:27 PM, Jean-Sebastien Delfino wrote:
-0 from me.
I tried the release and ran into several
I'd add that the API jar here does *not* contain the schemas.
We don't have approval yet for the 3rd party license covering the
ones on the OSOA site and to my knowledge do not yet have versions
available under the Apache License.
--
Jeremy
On Mar 7, 2007, at 9:59 AM, Mike Edwards wrote:
On Mar 7, 2007, at 6:42 PM, Jim Marino wrote:
When we convert over to the federated marhsallers, I think we can
get rid of AtomicComponent and just have Component. To do this, we
would need to move some of the lifecycle getters such as
conversational lifetime, etc. to Component. The other
On Mar 7, 2007, at 6:24 PM, Jim Marino wrote:
It should be the Multiparent CL from the ClassLoaderRegistry. It
looks like Jeremy got the multi-parent loading merged with the
composite classloader in r515464. This classloader will load the
impl class and we can use those to in turn load the
scheme could be used to address that.
I'll ask the IPMC to ratify this. I may wait until the kernel vote
completes so that they can do both at once.
Thanks everyone.
--
Jeremy
On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:
Please vote to approve the release of the sca-api's for r1.0
+1
--
Jeremy
On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:
Please vote to approve the release of the sca-api's for r1.0 of the
specification. This is the API code that we recently reviewed but
please vote again to confirm the release.
[tag] http://svn.apache.org/repos/asf
On Mar 6, 2007, at 2:10 AM, Dan Murphy wrote:
probably due to my j2ee experiences... I was wondering how / if the
runtime
would react to different versions of the same component/composite,
but I'm
sure we have some for of classloader isolation that would handle
this...
In 1.x we
released ? Other then that, +1.
On 3/6/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
+1
--
Jeremy
On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:
Please vote to approve the release of the sca-api's for r1.0 of the
specification. This is the API code that we recently reviewed but
please vote again
On Mar 6, 2007, at 12:01 PM, Luciano Resende wrote:
Bellow, a list of minor issues that we had in past releases, and
were all
questioned by IPMC :
- Artifacts does not have tuscany- prefix.
- Assembly/standalone distribution is extracting to current directory,
instead of a subdirectory
-
On Mar 6, 2007, at 7:03 PM, Jim Marino wrote:
Putting my spec hat on, I can pretty confidently say the chances of
content changes to the specs are remote at best. I'd characterize
'remote' as the possibility of getting 20 lawyers together and
having them agree on something that generates
It looks like it's using:
meta HTTP-EQUIV=Refresh CONTENT=0; URL=http://cwiki.apache.org/
TUSCANY/ /
which may take a sec to kick in as the page is being rendered.
I would suggest making the page really short - if we're not using the
generated site any longer you could just replace the
On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote:
Hi Jeremy,
I think what you're suggesting is along the lines of the 'whilst I
could
deploy nested composites' thought (I may have misunderstood you
though)...
I would have liked to deploy two separate composites as it seemed
likely
that the
I am going to update the XML namespace in trunk to match the release
version, specifically
* system namespace to http://tuscany.apache.org/xmlns/sca/system/2.0-
alpha
* user namespace to http://tuscany.apache.org/xmlns/sca/2.0-alpha
However, as the physical marshallers are still experimental
On Mar 5, 2007, at 2:10 PM, Dan Murphy wrote:
There may be some confusion here over deploy. In SCA you don't
deploy applications in the traditional sense - you contribute
implementations to a domain and then assemble component hierarchies
from them.
Interesting, I appreciated that there was
I have tagged the sca parent pom in preparation for releasing trunk
and am about to update the individual modules to use it. I am going
to hold off from deploying the pom to the release repository for now
so until then it will be necessary to build it locally first:
$ cd
I get a a bunch of sourcecheck failures in core (including PMD
failures) - many of these relate to the marshallers and contribution
service so Meeraj, Luciano, please could you clean them up.
Thanks
--
Jeremy
-
To
Passed with +1s from dims, jim, and pzf and no -1s
Thank you.
--
Jeremy
On Feb 26, 2007, at 2:36 PM, Jeremy Boynes wrote:
Resending as a [VOTE] thread as this one seems to be rambling ...
-- Forwarded message --
From: Jeremy Boynes [EMAIL PROTECTED]
Date: Feb 25, 2007 6:34 AM
Please vote to approve the release of the sca-api's for r1.0 of the
specification. This is the API code that we recently reviewed but
please vote again to confirm the release.
[tag] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/
spec/sca-api-r1.0/1.0-incubating
[src]
On Mar 2, 2007, at 5:02 AM, Guillaume Dufrêne wrote:
Hi Jeremy,
I'm using the launcher for running my sample.
So, my command looks like :
java -jar (sca-home)/bin/launcher.jar my_application.jar
In my case sca-home is located at C:\workspace\fcSOAP\tuscany-1.0-
incubator-M2 but anyway ...
On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote:
I do not try the 1st cause the 2nd seems smarter.
It seems easier to do with an ant script :-)
So, the 2nd solution works fine. Thanks !!
Phew :-)
I have added -Doffline=true to bypass maven update check.
Ok, now I have a
I made a start on this (r513843) - atm it just supports
packagingcomposite/packaging but I'll see about adding the
contribution and itest stuff as well.
--
Jeremy
On Feb 26, 2007, at 2:27 PM, Jeremy Boynes wrote:
[[ another resend due to flaky email service ]]
I've been thinking about
You will need to have the StAX API and an implementation visible in
the same classloader as used for SDO.
If you have the SDO impl jars in WEB-INF/lib you should make sure:
* stax-api-1.0.1.jar
* wstx-asl-3.2.0.jar
are in the same place (using the StAX impl from http://
woodstox.codehaus.org).
1 - 100 of 1236 matches
Mail list logo
