I think we may need something like this again when we support nested
configuration...what do you think?
On Apr 17, 2006, at 6:37 AM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Mon Apr 17 06:37:49 2006
New Revision: 394667
URL: http://svn.apache.org/viewcvs?rev=394667view=rev
Log:
On Apr 20, 2006, at 4:31 AM, Daniel Kulp wrote:
Jim,
I think this is a really good start but before they get moved up I'd
like to see some unit test coverage.
Agreed. Normally, I wouldn't have even submitted a patch without
some
tests in place. That really bothers me. But I was
I noticed in system.module we are using qualified names for system
services based on the full name of the implementation class. I'd
prefer if we continue to use the dot notation, but shorten the names,
e.g.:
org.apache.tuscany.core.loader.WSDLDefinitionRegistry
to
I was thinking we would reserve system for Tuscany things. This
would be unique.
Jim
On Apr 20, 2006, at 3:20 PM, Jeremy Boynes wrote:
Jim Marino wrote:
I noticed in system.module we are using qualified names for system
services based on the full name of the implementation class. I'd
great. I'll take a look today and tomorrow. I'm also interested in
helping so let me know what you would like done.
Jim
On Apr 25, 2006, at 8:38 AM, Jean-Sebastien Delfino wrote:
I checked a first implementation of support for async non-blocking
calls in the sandbox. Directory
Sure - it's already in the sandbox under jim/docs/
exception_handling.html. These were agreed to at the outset of the
project (along with the IDE templates) and drafted by Sebastien,
Jeremy, myself based on some guidelines donated by Mike Rowley.
Jim
On Apr 25, 2006, at 9:25 AM, haleh
On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote:
Generally I like this approach - I do have a couple of small
comments inline.
On 4/25/06, ant elder [EMAIL PROTECTED] wrote:
Create a new folder under testing called 'interop' . Interop may
not be the
best name, feel free to suggest
Just a friendly reminder to those working on the core or model to
please include celtix in their refactorings. I accidentally forgot to
check in my refactors (sandbox is separate) and run the checkstyle
tests from celtix/binding.celtix resulting in Dan having a broken
demo :-( Also,
+1 to move it
Jim
On Apr 25, 2006, at 8:38 AM, Jean-Sebastien Delfino wrote:
I checked a first implementation of support for async non-blocking
calls in the sandbox. Directory sandbox/sebastien/java/sca/async
contains the runtime code, sandbox/sebastien/java/samples/
helloworldasync
On Apr 25, 2006, at 5:58 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote:
Generally I like this approach - I do have a couple of small
comments inline.
On 4/25/06, ant elder [EMAIL PROTECTED] wrote:
Create a new folder under
The only one I think we may not want is the TYPECAST. That said, I'm
not fussy about line length as long as it is consistent, not too
long, not too short. One thing I would like to change is throwing
errors for when parameter names hide member variables since I think
this is o.k. Dan, do
Could you post a stack trace?
Thanks,
Jim
On Apr 26, 2006, at 10:45 AM, Scott Kurz wrote:
I'm observing an issue (running April 17th SVN contents) and I'm
not sure if
this is a bug or a limitation with the current Tuscany
implementation or if
this is working according to the 0.9 spec (in
Nevermind,
'
I just saw the JIRA. Thanks.
Jim
On Apr 26, 2006, at 12:31 PM, Jim Marino wrote:
Could you post a stack trace?
Thanks,
Jim
On Apr 26, 2006, at 10:45 AM, Scott Kurz wrote:
I'm observing an issue (running April 17th SVN contents) and I'm
not sure if
this is a bug
So if we do not have the space restriction, checks for parameter
names, and run this only pre-commit, would you be o.k. with it? I
would like to have this in since it is a nice check and should not be
burdensome assuming people set the proper template in their IDE.
On Apr 26, 2006, at
. I'm also proposing this for after JavaOne and many of
the more important items.
Jim
On Apr 26, 2006, at 4:15 PM, Jeremy Boynes wrote:
Jim Marino wrote:
So if we do not have the space restriction, checks for parameter
names, and run this only pre-commit, would you be o.k. with it? I
would
+1 Dan submitted a patch with testcases so I think it should go into
the build process with that patch applied. Thanks Dan!
Jim
On Apr 26, 2006, at 11:42 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
Just a friendly reminder to those working on the core or model to
please include
Yep, absolutely that makes sense.
Jim
On Apr 26, 2006, at 7:03 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
I agree poor test coverage is more important but this shouldn't be
a big deal - I'll even do it for all of the packages myself. I
think this is one of those incremental
They should be working for Java types. Could you open a Jira and
post the two component classes (particularly the interfaces) you are
trying to wire together along with the SCDL? I'll try and take a look
this weekend.
Jim
On Apr 27, 2006, at 1:08 PM, Ignacio Silva-Lepe wrote:
Not sure
Hi Ignacio,
I'm planning to work on conversational support following JavaOne if
you (or others are interested). This will involve a refactoring of
the scope containers slightly to accommodate a persistent store. Let
me know if you are interested in working on this together.
Jim
On
Cool. I have some work on a BigBank async sample done as part of the
specification collaboration that I need to clear but once I do, we
can discuss that as part of this topic. The scope containers may
need to be refactored slightly (we can discuss) as well as I believe
there may need to
Result of the vote for Dan Kulp as committer on Apache Tuscany:
+1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt
No -1s
Dan welcome to the Apache Tuscany community! We'll start the process
of getting you karma.
Jim
On Apr 29, 2006, at 10:28 AM, Jim Marino wrote:
I'd like to propose
Hi,
I've noticed in JIRA we are naming our release .91. Is that just a
JIRA thing (i.e. make it easier to organize stuff for us) or is it
assumed that we would call the JavaOne binary a .91 release? I
think we should discuss what we want to call the binary, so I'll
throw my opinion in
I noticed with the recent changes to move samples under /java/sca
they are not built as part of the main developer build. I agree the
samples should be moved there but not that they be built as part of
the main developer build. I'm not sure whether this was a byproduct
of the move but
Small clarification the first sentence should be:
I noticed with the recent changes to move samples under /java/sca
they are now built as part of the main developer build.
Begin forwarded message:
From: Jim Marino [EMAIL PROTECTED]
Date: May 5, 2006 1:14:52 PM PDT
To: tuscany-dev
Yes by all means. Could you post it to JIRA?
Thanks!
Jim
On May 7, 2006, at 12:14 PM, meeraj kunnumpurath wrote:
Hi,
I have written a Groovy container for Tuscany. Is it worth submitting?
Kind regards
Meeraj
--
___
Search for businesses by
Congrats Dan!
http://www.theserverside.com/news/thread.tss?thread_id=40320
This is the same in IntelliJ too so I think it is a good thing to do. +1
On May 10, 2006, at 6:32 AM, cr22rc2 wrote:
I'd like to propose for all samples be it the yet undecided name
for what BB is and the other technology samples to prepend to the
maven artifactid sample-. I hate to be
+1
On May 18, 2006, at 4:00 PM, Jean-Sebastien Delfino wrote:
Hi!
I created source and binary distributions of the latest Tuscany
Milestone 1 release candidate level (SVN revision r407596) and
placed them in my home directory:
http://people.apache.org/~jsdelfino/test-incubating-M1/tuscany-
Hi Raymond,
I took a look at the implementation and have a few observations:
- It appears that a Spring application context is created for each
method on a bean. Was this intentional, since I would have thought
that a Spring application context would be created per composite? In
other
Groovy now.
Thanks,
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, May 23, 2006 9:20 AM
Subject: Re: [jira] Updated: (TUSCANY-415) Add a Spring container
to Tuscany so that Spring beans can be used as an implementation
Hi Raymond,
Comments inline...
On May 24, 2006, at 9:30 AM, Raymond Feng wrote:
Hi, Jim/Jeremy.
I don't see XXXImplementationLoader (except
SystemImplementationLoader) any more in the sandbox code. Are they
just not implmented or do we now have a new model to populate the
jmarino: so Raymond, I checked in some skeletal code last night
[11:15am] rfeng: yes, I did a brief reading
[11:16am] jmarino: k good .did you also have a chance to take a look
at the Groovy extension?
[11:16am] rfeng: so the basic idea is to model a set of spring beans
as a composite?
On May 24, 2006, at 3:04 PM, Jeremy Boynes wrote:
On 5/24/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Thanks for the explanations.
I can help to port/develop the implementation/componentType
loaders. As the
first step, I'm trying JavaImplementationLoader and
for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed
code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've
Hi Raymond,
Jeremy is in the process of moving the annotation processing
framework from trunk to sandbox/core2, which involves some refactors
to the processing rules it implements to better accommodate
unannotated Pojos (this was an issue with M1).
Jim
On May 26, 2006, at 9:38 AM,
On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote:
In M1 we do not have a consistent approach on how the component type
information is derived for a component implemented by a Java class.
This, combined with some poor wording in the spec itself
(inconsistencies, fragmentation), led to a number
preferred approach or alternative suggestions?
My preferred approach is to design a management API incrementally
Thanks,
...ant
On 5/26/06, Jim Marino [EMAIL PROTECTED] wrote:
Yea sorry got called into other things yesterday.
We definitely don't want to cast like that since
Hi John,
Tuscany M1 should be able to run in any Servlet container. We have
done a deep integration with Tomcat for an out-of-the-box experience.
Moving forward, we plan to support additional platforms. If you
really want to deploy to WebLogic or Websphere, the easiest mechanism
would
Hi,
There has been some mention offline of Jeremy and I providing an
overview of changes to the SCA specifications and related recursive
core architecture work going on in the sandbox, perhaps Wednesday.
I'm happy to do this, however, I'm a bit concerned that since this
has not been
Yes this would be appreciated. Can you make sure it's in a common
graphic format - I'm too cheap to shell out the $$ for a UML tool ;-)
Jim
On Jun 5, 2006, at 12:29 PM, Jeremy Boynes wrote:
Raymond Feng wrote:
Hi,
I have created some basic slides and UML diagrams when I looked
into the
have anything in the way of
explanatory material that you could circulate on the list/wiki
before
the presentation, I think that would be very useful.. certainly I
could use a little more context to help with my own browsing.
thanks,
k
On 6/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
Jim
proposals we could discuss with them.
Ideas?
Jim
On Jun 6, 2006, at 2:18 PM, Paul Fremantle wrote:
By the way can someone explain what the term Recursive Core
Architecture means?
Paul
On 6/6/06, Jim Marino [EMAIL PROTECTED] wrote:
It looks as if we have the choice of Thursday or Friday this week
Thanks Raymond for taking this on. I have made to refactors today so
could you regenerate (I hope you didn't have to do the model by
hand)? The two basic changes I did are:
1. Rename ScopeContext to ScopeContainer since it contains component
implementation instances
2. Internalized
and membership regulations
around the spec group?
Is there a web page you can point me at that outlines those?
Paul
On 6/7/06, Jim Marino [EMAIL PROTECTED] wrote:
Good question...
In the spec group, one of the major changes we are currently
undertaking is a move to a recursive model where components
Great - thanks a bunch!
On Jun 7, 2006, at 10:19 AM, Raymond Feng wrote:
Hi, Jim.
The UML diagrams on the wiki page (http://wiki.apache.org/ws/
Tuscany/TuscanyJava/SandboxCore) are now updated to reflect your
changes.
Thanks,
Raymond
- Original Message - From: Jim Marino
of the collaboration agreement
designed for this purpose.
Simon
Jim Marino wrote:
Good question...
In the spec group, one of the major changes we are currently
undertaking is a move to a recursive model where components can
either
be leaf-types (atomic) or composite, in which case they may
On Jun 7, 2006, at 2:43 PM, Jeremy Boynes wrote:
Paul Fremantle wrote:
Jim
Its a great question. I think the answer is that they stick to
published specs, which is what I was expecting Tuscany to do given
the
closed nature of the spec group. I'll ask around to find out.
Geronimo has
Separating this into a new thread since the other one has a new
ongoing topic...
Some of the people are going to have trouble staying past 9.30PST for
the call to cover the new spec changes and core design. So, we are
going to have the meeting run from 7.30PST-9.30PST. I will circulate
I think Jeremy is being charitable in taking some of the blame; it
was mostly my (new) machine. Thanks for fixing.
Jim
On Jun 8, 2006, at 4:31 PM, Jeremy Boynes wrote:
I did a big checkin Saturday to fix problems with SVN properties that
were incorrectly set due to incorrect configurations
Sorry I will post in a more accessible format ASAP.
Jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Jun 9, 2006, at 7:42 AM, Jim Marino wrote:
tuscany.architecture.v4.ppt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Sorry - trouble this am my time :-) Now Attached.
Jim
On Jun 9, 2006, at 7:50 AM, Jim Marino wrote:
On Jun 9, 2006, at 7:42 AM, Jim Marino wrote:
tuscany.architecture.v4.ppt
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Hi,
Thanks everyone who attended today's call. The slides have been checked
into SVN at:
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/doc
We would appreciate any comments, questions, feedback, and suggestions
on the session, and more importantly, the sandbox code at:
Yea thanks for pointing this out. I stuck things there since I was
having a bit of trouble getting checkstyle picked up by the lower
projects and figured I wait for your help to sort it out :) One thing
is a relaxed some of the checks (e.g. line length to 120, parameter
names are allowed
I also forgot one big area that needs work: Management. This is a
topic that is starting to come up in the spec group and it would be
great if we could propose some ideas to them.
Jim
On Jun 9, 2006, at 2:48 PM, Jim Marino wrote:
Hi,
Thanks everyone who attended today's call. The slides
FYI Dan
I switched awhile back from Eclipse (I was a long-time user) to
IntelliJ and I love it. It takes a bit getting used to the key
mappings but the refactoring capabilities are just awesome. I'm also
amazed at the things it can catch from analyzing code. And even
better, JetBrains
in these areas.
Cheers,
Joel Hawkins
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 10, 2006 1:08 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Subject: SCA Spec Update and Recursive Core presentation
I also forgot one big area that needs work: Management
Hi Rashmi,
Jeremy will be able to answer your question regarding bootstrapping.
For how to locate services, the spec API is evolving to accommodate
the new recursive API. I have some thoughts I have been working on in
the sandbox under jboynes/spec/sca but they are very early which will
The easiest solution to this is to check the sandbox code out and
build it using the correct poms.
Jim
On Jun 13, 2006, at 7:29 AM, Scott Kurz wrote:
How does one build sandbox code, for example Jeremy's sandbox
(which he's
moving to a branch) ?
I tried extracting the sandbox and
wrote:
OK.. doing a find-replace on the sandbox's poms seems to work...
just making
sure that was correct... thanks
On 6/13/06, Jim Marino [EMAIL PROTECTED] wrote:
The easiest solution to this is to check the sandbox code out and
build it using the correct poms.
Jim
On Jun 13, 2006, at 7:29
I've been seeing the same thing for a while and was also going to ask
about it but never got around to it
On Jun 13, 2006, at 9:07 AM, Jeremy Boynes wrote:
I noticed that the build for the code in the sandbox builds each
module
twice - not sure when this started but it didn't use to. Is
-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 4:38 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Subject: SCA Spec Update and Recursive Core presentation
Hi Joel,
Great. Do you have some specific areas you are interested in working
on w.r.t to Tuscany? I started
Which code base are you intending to use: the M1 which implements the
old .9 spec or the sandbox one which implements support for the new
recursive model, or both?
In terms of how to specifically improve the extensibility story, my
opinions have been embodied in the sandbox code and
In trying to eliminate reliance on core2 by container.java in the
sandbox and have it only rely on the extensibility SPI, it occurred
to me that this would mandate moving a lot of implementation classes
from core2 into SPI. I believe having container.java as a separate
project rely on
POJO container is the least worst option.
--
Jeremy
Jim Marino wrote:
In trying to eliminate reliance on core2 by container.java in the
sandbox and have it only rely on the extensibility SPI, it
occurred to
me that this would mandate moving a lot of implementation classes
from
core2 into SPI
yea sounds good except I'll abbreviate implementation to impl so
the package names are reasonable.
Jim
On Jun 20, 2006, at 9:25 AM, Jeremy Boynes wrote:
Jim Marino wrote:
I'm leaning towards combining them because separating
commonalities out
into a third project is basically creating
On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
In trying to eliminate reliance on core2 by container.java in the
sandbox and have it only rely on the extensibility SPI, it
occurred to me that this would mandate moving a lot of
implementation classes from
with the version of ASM it
is using. I don't have the Tuscany thread right now but if you do a
search, it involves deleting a version of ASM from you maven repo. If
you can't find it, let me know and I'll look.
Jim
On Jun 20, 2006, at 12:59 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote
In the new core2 API, component factory is no longer needed.
AtomicComponent contains the invocation chains and and is responsible
for creating invokers. Related to having WSDL or Java interface
types, one of the things we also did was separate proxy creation from
the wire so now you can
On Jun 21, 2006, at 4:48 AM, cr22rc wrote:
I'd like to help out on this and also the SPI analysis work you
spoke of. Per the samples I had some thoughts that instead of just
jumping straight to them is to add some more for baby steps in
bring up. For example I'd like to see as starters
a
point that this is too much for one sample, but generally these
three technologies look in the minds of people to be sort of
separate and I still like the idea of a sample that shows them all
coming together.
Jim Marino wrote:
On Jun 21, 2006, at 4:48 AM, cr22rc wrote:
I'd like
2:08 AM
Subject: Re: Tuscany SPI interfaces
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said
evils, the other approach being a lot of duplicate code.
Jim
On Jun 21, 2006, at 5:21 PM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
On Jun 20, 2006, at 10:37 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
In trying to eliminate reliance on core2 by container.java
FYI
I've started migrating sandbox code to use the new recursive SCA API.
This API has been accepted with a bunch of changes including
Jeremy's constructor injection proposal. The intent is the Tuscany
SCA API jar will be donated to/used by the spec group. A quick
overview of what has
I've add a simple temporary class that to the eagerinit sample -
LifecycleDemonstration - that demonstrates component lifecycle
management, eager initialization, and destruction. As soon as we get
the SCDL loading connected to the builders, this class can go away
and we will be able to
I'm going to tweak the composite startup code so
that we don't need to leak the scope container to the deployer's
client. I hope to get that done on the next leg :-)
--
Jeremy
On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote:
I've add a simple temporary class that to the eagerinit sample
Ken was working on this. Ken? Since he may be traveling, if we don't
hear back, I'll apply it tomorrow.
Jim
On Jun 25, 2006, at 11:38 PM, Raymond Feng wrote:
A gentle reminder: Is anyone looking into the patch? I just tried
it with Spring 2.0 RC1 and here's a new one updated to 2.0 RC1
process. We could expand it further but I
think that we'll basically end up duplicating the code that would be
in the Launcher. Rick, weren't you looking at that? How is it going?
--
Jeremy
On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote:
Basically the runtime has two hierarchical trees, one
On Jun 26, 2006, at 4:20 PM, Jeremy Boynes wrote:
On 6/26/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Here are a few thoughts and questions on our SPI story. I'd like to
start a discussion on these items and get your thoughts.
Cool. My first thought is that what you're describing
objects, which will generate lots of questions. Looking
forward to
the journey.
Cheers,
Joel
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 18, 2006 3:58 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Subject: SCA Spec Update and Recursive Core
On Jun 26, 2006, at 5:10 PM, Jean-Sebastien Delfino wrote:
I'm looking at the Invoker/interceptor contribution mechanism and
I'd like to propose to make them actual components. Currently an
interceptor is not a component, it's an object added to an
invocation chain by a Builder component.
Thanks for volunteering! The Spring container that Ken is working on
will demonstrate how composites function. However, just to be
accurate, we do not have *any* samples in core2 yet - it's not just a
question about recursion. If people want to develop them and help
out that would be
issued by the runtime
All of these methods deal directly with a component and are very easy
to implement. I don't see the need to Balkanize the API. Which of
these methods do you think can be broken out?
Jim
On Jun 21, 2006, at 2:08 AM, Jean-Sebastien Delfino wrote:
Jim Marino
Hi Raymond,
I think this would be really good to get it into the sandbox. Can
you point me to the latest patch and we'll get it in ASAP?
Jim
On Jun 28, 2006, at 9:36 AM, Raymond Feng wrote:
Hi,
Do you think if my prototype can be used as a seed to flush out a
good data mediation
I was thinking it would be a system service since it appears to be
applicable to a wide variety of things in the runtime. Having it as a
system service also allows it to be managed and autowired to other
extension points (e.g. services, bindings, components that may want
to use it).
If
implementations
5) Split the project into multiple ones: one for the framework and
each
per
data binding
6) Add more data bindings
Any feedback will be welcome.
Thanks,
Raymond
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 28, 2006 10
type to the component
implementations
5) Split the project into multiple ones: one for the framework and
each per
data binding
6) Add more data bindings
Any feedback will be welcome.
Thanks,
Raymond
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent
On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote:
I'd like to start working on providing support for callbacks,
assuming the sandbox is a good place to do this.
Great. In case you haven't seen it, we have some architecture slides
in the sandbox under jboynes/sca/doc in
On Jun 29, 2006, at 1:47 PM, Ignacio Silva-Lepe wrote:
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, June 29, 2006 12:18 PM
Subject: Re: Support for callbacks
On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote:
I'd
Just a reminder (since it was buried in a previous email
thread)...When doing checkins on the sandbox core2 implementation,
please run:
$ mvn -Psourcecheck
This will execute PMD and Checkstyle as part of the build.
Thanks,
Jim
On Jul 1, 2006, at 12:07 AM, Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
1. Use scenarios to drive the M2 work
Start a community discussion on the end to end scenarios that we
want to
support in M2.
I'm thinking about concrete end to end scenarios that define the
end user
I'd say change PMD.
On Jul 1, 2006, at 1:04 AM, Jeremy Boynes wrote:
On 6/30/06, Jim Marino [EMAIL PROTECTED] wrote:
Just a reminder (since it was buried in a previous email
thread)...When doing checkins on the sandbox core2 implementation,
please run:
$ mvn -Psourcecheck
This will execute
Hi Ignacio,
Let's try IRC, perhaps Monday's chat? Other comments inline...
On Jun 30, 2006, at 1:30 PM, Ignacio Silva-Lepe wrote:
Apologies Jeremy, didn't mean to exclude people, just trying
to expedite the discussion.
The first basic issue I see is how to incorporate callbacks as
defined
Yea sorry, comment out the rule.
Jim
On Jul 1, 2006, at 1:17 AM, Jeremy Boynes wrote:
On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote:
I'd say change PMD.
Do you mean comment out the rule or fix the bug?
The latter is a better solution but I'm hoping you mean the first :-)
--
Jeremy
On Jul 1, 2006, at 2:42 AM, Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
- Modularity, building our runtime in a more modular way, with more
but
simpler modules, clean SPI modules with only interfaces, and
decoupling the
core and the Java component implementation type / container.
-
On Jul 1, 2006, at 1:17 AM, Jeremy Boynes wrote:
Oh look, there's an elephant in the sandbox.
On 6/30/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
2. Stage the assembly of our M2 runtime.
I propose that we start a fresh stream for M2 and build the
runtime through
baby steps, in
On Jul 1, 2006, at 9:28 AM, Jeremy Boynes wrote:
On 7/1/06, Jim Marino [EMAIL PROTECTED] wrote:
I believe a good portion of that 300K is related to the Geronimo
WorkManager dependencies. Since WorkManager can be implemented as a
thin facade over the JDK 5 concurrency libraries, we should look
I've added a skeleton wiki page for scenarios people are working on
or are interested in for the Java SCA runtime at :
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios?action=show
Most of the content are placeholders so it would be great if those
interested started to add more
On Jul 2, 2006, at 2:51 PM, Clemens Utschig - Utschig (Oracle) wrote:
Comments linline ...
Jim Marino wrote:
On Jul 2, 2006, at 2:02 PM, Simon Nash wrote:
My comments are inline below.
Simon
Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
1. Use scenarios to drive the M2 work
More comments inline...
On Jul 2, 2006, at 2:02 PM, Simon Nash wrote:
My comments are inline below.
Simon
Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
1. Use scenarios to drive the M2 work
Start a community discussion on the end to end scenarios that
we want to
support in M2.
101 - 200 of 1205 matches
Mail list logo
