You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2006/06/20 10:31:16 UTC
move of container.java to core2
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 core2 is the wrong approach. This leaves three options:
- move the required classes to SPI
- make container.java not dependent on core classes by duplicating them
- merging container.java with core.
I think moving the classes to SPI is not the best approach since they
are implementations. Having duplicate classes does not seem to be
the optimal approach either as that will result in a maintenance
burden and a lot of code repetition. As background, the sharing of
classes between core2 and container.java arises from the fact that
the runtime uses a POJO model to assemble system services, and hence
there is commonality between the two.
I prefer to do the latter as it appears to be the cleanest. Also,
java.container is not a very good example of how to extend the
recursive core due to its "advanced" capabilities. I'd rather include
a simple Java container geared to demonstrating how to extend the
runtime. It would be helpful if people provide input over the next
day...I plan to implement choice 3 tomorrow if there are no
alternatives.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jim Marino <jm...@myromatours.com>.
Maybe I'll just keep it implementation since impltype isn't that much
shorter and is very appealing. We could call it "imp" ;-)
Jim
On Jun 20, 2006, at 10:02 AM, Jeremy Boynes wrote:
> Jim Marino wrote:
>> yea sounds good except I'll abbreviate "implementation" to "impl" so
>> the package names are reasonable.
>>
>
> I think impl would be confusing given its usage elsewhere (as the
> package containing the impl of an api) - how about "impltype" ?
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jeremy Boynes <jb...@apache.org>.
Jim Marino wrote:
> yea sounds good except I'll abbreviate "implementation" to "impl" so
> the package names are reasonable.
>
I think impl would be confusing given its usage elsewhere (as the
package containing the impl of an api) - how about "impltype" ?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jim Marino <jm...@myromatours.com>.
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 an "SPI2". Also, most
>> of the
>> stuff that would be pulled out is related to injection and
>> reflection
>> which I don't think we want to expose as an API at this point.
>>
>
> YAGNI? Fair enough.
>
> We have "composite" and "system" sub-packages in core that
> correspond to
> implementation types - are you going to add "java" as third?
>
> Should we add "implementation" as a parent package to all three?
> I.e add
> o.a.t.core.implementation.[system,composite,java]
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jeremy Boynes <jb...@apache.org>.
Jim Marino wrote:
> I'm leaning towards combining them because separating commonalities out
> into a third project is basically creating an "SPI2". Also, most of the
> stuff that would be pulled out is related to injection and reflection
> which I don't think we want to expose as an API at this point.
>
YAGNI? Fair enough.
We have "composite" and "system" sub-packages in core that correspond to
implementation types - are you going to add "java" as third?
Should we add "implementation" as a parent package to all three? I.e add
o.a.t.core.implementation.[system,composite,java]
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jim Marino <jm...@myromatours.com>.
I'm leaning towards combining them because separating commonalities
out into a third project is basically creating an "SPI2". Also, most
of the stuff that would be pulled out is related to injection and
reflection which I don't think we want to expose as an API at this
point.
Jim
On Jun 20, 2006, at 8:09 AM, Jeremy Boynes wrote:
> I definitely agree that we should not be putting implementation into
> spi. We've been down the duplication path before and it did not work -
> the system and java containers quickly started to skew from each other
> (e.g. autowire only works for system components).
>
> Is there a way in which we can factor implementation "shared" by the
> system and java containers into a separate module? That would
> provide a
> common basis for other containers based on a POJO IoC model; however,
> implementation dependencies may well pull in a lot more of core than
> appropriate. It would only be worth doing if we expected a lot more
> containers that can use that infrastructure - I'm not sure that
> will be
> the case as others are likely to have a different programming model.
>
> Given that I think the approach of merging them together combined
> with a
> example of a simple 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. I believe having container.java as a separate
>> project
>> rely on core2 is the wrong approach. This leaves three options:
>>
>> - move the required classes to SPI
>> - make container.java not dependent on core classes by duplicating
>> them
>> - merging container.java with core.
>>
>> I think moving the classes to SPI is not the best approach since they
>> are implementations. Having duplicate classes does not seem to
>> be the
>> optimal approach either as that will result in a maintenance
>> burden and
>> a lot of code repetition. As background, the sharing of classes
>> between core2 and container.java arises from the fact that the
>> runtime
>> uses a POJO model to assemble system services, and hence there is
>> commonality between the two.
>>
>> I prefer to do the latter as it appears to be the cleanest. Also,
>> java.container is not a very good example of how to extend the
>> recursive core due to its "advanced" capabilities. I'd rather
>> include a
>> simple Java container geared to demonstrating how to extend the
>> runtime. It would be helpful if people provide input over the next
>> day...I plan to implement choice 3 tomorrow if there are no
>> alternatives.
>>
>> Jim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jeremy Boynes <jb...@apache.org>.
I definitely agree that we should not be putting implementation into
spi. We've been down the duplication path before and it did not work -
the system and java containers quickly started to skew from each other
(e.g. autowire only works for system components).
Is there a way in which we can factor implementation "shared" by the
system and java containers into a separate module? That would provide a
common basis for other containers based on a POJO IoC model; however,
implementation dependencies may well pull in a lot more of core than
appropriate. It would only be worth doing if we expected a lot more
containers that can use that infrastructure - I'm not sure that will be
the case as others are likely to have a different programming model.
Given that I think the approach of merging them together combined with a
example of a simple 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. I believe having container.java as a separate project
> rely on core2 is the wrong approach. This leaves three options:
>
> - move the required classes to SPI
> - make container.java not dependent on core classes by duplicating them
> - merging container.java with core.
>
> I think moving the classes to SPI is not the best approach since they
> are implementations. Having duplicate classes does not seem to be the
> optimal approach either as that will result in a maintenance burden and
> a lot of code repetition. As background, the sharing of classes
> between core2 and container.java arises from the fact that the runtime
> uses a POJO model to assemble system services, and hence there is
> commonality between the two.
>
> I prefer to do the latter as it appears to be the cleanest. Also,
> java.container is not a very good example of how to extend the
> recursive core due to its "advanced" capabilities. I'd rather include a
> simple Java container geared to demonstrating how to extend the
> runtime. It would be helpful if people provide input over the next
> day...I plan to implement choice 3 tomorrow if there are no alternatives.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
> Yes the commons option would have been ideal but unfortunately, It's
> more than just reflection and utility classes. It's also injection
> classes related to wiring and component-handling classes which depend
> on SPI. Having gone over the options, merging the two seems to be the
> lesser of two evils, the other approach being a lot of duplicate code.
>
> Jim
>
Can you tell me which injection and wiring classes and help me
understand why they're creating such coupling? Maybe some of them could
be turned into useful SPIs and the others could go into common? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jim Marino <jm...@myromatours.com>.
Yes the commons option would have been ideal but unfortunately, It's
more than just reflection and utility classes. It's also injection
classes related to wiring and component-handling classes which depend
on SPI. Having gone over the options, merging the two seems to be the
lesser of two 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 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 core2 is the wrong
>>>> approach. This leaves three options:
>>>>
>>>> - move the required classes to SPI
>>>> - make container.java not dependent on core classes by
>>>> duplicating them
>>>> - merging container.java with core.
>>>>
>>>> I think moving the classes to SPI is not the best approach since
>>>> they are implementations. Having duplicate classes does not
>>>> seem to be the optimal approach either as that will result in a
>>>> maintenance burden and a lot of code repetition. As background,
>>>> the sharing of classes between core2 and container.java arises
>>>> from the fact that the runtime uses a POJO model to assemble
>>>> system services, and hence there is commonality between the two.
>>>>
>>>> I prefer to do the latter as it appears to be the cleanest.
>>>> Also, java.container is not a very good example of how to extend
>>>> the recursive core due to its "advanced" capabilities. I'd
>>>> rather include a simple Java container geared to demonstrating
>>>> how to extend the runtime. It would be helpful if people provide
>>>> input over the next day...I plan to implement choice 3 tomorrow
>>>> if there are no alternatives.
>>>>
>>>> Jim
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>> I would prefer another option: Define a clean SPI contract with
>>> just interfaces so that containers (component implementation
>>> extensions) do not have to depend on internal classes from the
>>> core project. I thought that it was the reason for having an SPI
>>> project separate from core.
>>> I think that the core runtime and the java container should be
>>> decoupled with clean interface-based contracts between the two.
>>> What are the technical issues preventing us from achieving that?
>>>
>> That's exactly what we have, a clean SPI with mostly interfaces.
>> Container.java and core, however, both use java Pojo's (system
>> services, and Java C&I components) so there are some common
>> reflection and injection related classes. It doesn't make sense to
>> duplicate those classes and related test cases and maintain exact
>> replicas in two different projects of a significant amount of
>> code. On the other hand, keeping container.java separate and
>> referencing those core classes sends an unclear message to
>> extension developers. The other option, putting the implementation
>> classes in SPI is in my view also wrong for two reasons. First,
>> they are implementation-related, Second, they are not things we
>> want to expose in the SPI.
>>
>> So, to recap, we have a separate SPI extension package that does
>> not require extension developers to reference the core
>> implementation. Core, for example, is built on SPI. The issue I
>> was bringing up in this thread is that as core and container.java
>> share a significant amount of implementation, and container.java
>> is central to both SCA and the Java Tuscany implementation, it
>> makes sense to combine the two as opposed to duplicating the
>> shared implementation.
>>
>> Jim
>>
>>
>>
>>> --Jean-Sebastien
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> If I understand correctly, container.java and core both share
> utility classes that handle reflection and handling of Java
> annotations. Since we are a Java runtime other extensions and
> contributions to Tuscany will probably need this kind of utilities
> so I'd like to propose that we package them in tuscany-common.jar.
> This way they won't get mixed up with the SPIs (I agree with you
> that putting implementation classes in the SPI JAR is not good, I
> think the SPI JAR should just contain interfaces), and we can keep
> the java implementation extension and the core separate, which I
> think is important.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 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 core2 is the wrong approach. This leaves three options:
>>>
>>> - move the required classes to SPI
>>> - make container.java not dependent on core classes by duplicating them
>>> - merging container.java with core.
>>>
>>> I think moving the classes to SPI is not the best approach since
>>> they are implementations. Having duplicate classes does not seem
>>> to be the optimal approach either as that will result in a
>>> maintenance burden and a lot of code repetition. As background, the
>>> sharing of classes between core2 and container.java arises from the
>>> fact that the runtime uses a POJO model to assemble system services,
>>> and hence there is commonality between the two.
>>>
>>> I prefer to do the latter as it appears to be the cleanest. Also,
>>> java.container is not a very good example of how to extend the
>>> recursive core due to its "advanced" capabilities. I'd rather
>>> include a simple Java container geared to demonstrating how to
>>> extend the runtime. It would be helpful if people provide input over
>>> the next day...I plan to implement choice 3 tomorrow if there are no
>>> alternatives.
>>>
>>> Jim
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>> I would prefer another option: Define a clean SPI contract with just
>> interfaces so that containers (component implementation extensions)
>> do not have to depend on internal classes from the core project. I
>> thought that it was the reason for having an SPI project separate
>> from core.
>> I think that the core runtime and the java container should be
>> decoupled with clean interface-based contracts between the two. What
>> are the technical issues preventing us from achieving that?
>>
> That's exactly what we have, a clean SPI with mostly interfaces.
> Container.java and core, however, both use java Pojo's (system
> services, and Java C&I components) so there are some common reflection
> and injection related classes. It doesn't make sense to duplicate
> those classes and related test cases and maintain exact replicas in
> two different projects of a significant amount of code. On the other
> hand, keeping container.java separate and referencing those core
> classes sends an unclear message to extension developers. The other
> option, putting the implementation classes in SPI is in my view also
> wrong for two reasons. First, they are implementation-related, Second,
> they are not things we want to expose in the SPI.
>
> So, to recap, we have a separate SPI extension package that does not
> require extension developers to reference the core implementation.
> Core, for example, is built on SPI. The issue I was bringing up in
> this thread is that as core and container.java share a significant
> amount of implementation, and container.java is central to both SCA
> and the Java Tuscany implementation, it makes sense to combine the two
> as opposed to duplicating the shared implementation.
>
> Jim
>
>
>
>> --Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
If I understand correctly, container.java and core both share utility
classes that handle reflection and handling of Java annotations. Since
we are a Java runtime other extensions and contributions to Tuscany will
probably need this kind of utilities so I'd like to propose that we
package them in tuscany-common.jar. This way they won't get mixed up
with the SPIs (I agree with you that putting implementation classes in
the SPI JAR is not good, I think the SPI JAR should just contain
interfaces), and we can keep the java implementation extension and the
core separate, which I think is important.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jim Marino <jm...@myromatours.com>.
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 core2 into SPI. I believe having
>> container.java as a separate project rely on core2 is the wrong
>> approach. This leaves three options:
>>
>> - move the required classes to SPI
>> - make container.java not dependent on core classes by duplicating
>> them
>> - merging container.java with core.
>>
>> I think moving the classes to SPI is not the best approach since
>> they are implementations. Having duplicate classes does not seem
>> to be the optimal approach either as that will result in a
>> maintenance burden and a lot of code repetition. As background,
>> the sharing of classes between core2 and container.java arises
>> from the fact that the runtime uses a POJO model to assemble
>> system services, and hence there is commonality between the two.
>>
>> I prefer to do the latter as it appears to be the cleanest. Also,
>> java.container is not a very good example of how to extend the
>> recursive core due to its "advanced" capabilities. I'd rather
>> include a simple Java container geared to demonstrating how to
>> extend the runtime. It would be helpful if people provide input
>> over the next day...I plan to implement choice 3 tomorrow if there
>> are no alternatives.
>>
>> Jim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> I would prefer another option: Define a clean SPI contract with
> just interfaces so that containers (component implementation
> extensions) do not have to depend on internal classes from the core
> project. I thought that it was the reason for having an SPI project
> separate from core.
> I think that the core runtime and the java container should be
> decoupled with clean interface-based contracts between the two.
> What are the technical issues preventing us from achieving that?
>
That's exactly what we have, a clean SPI with mostly interfaces.
Container.java and core, however, both use java Pojo's (system
services, and Java C&I components) so there are some common
reflection and injection related classes. It doesn't make sense to
duplicate those classes and related test cases and maintain exact
replicas in two different projects of a significant amount of code.
On the other hand, keeping container.java separate and referencing
those core classes sends an unclear message to extension developers.
The other option, putting the implementation classes in SPI is in my
view also wrong for two reasons. First, they are implementation-
related, Second, they are not things we want to expose in the SPI.
So, to recap, we have a separate SPI extension package that does not
require extension developers to reference the core implementation.
Core, for example, is built on SPI. The issue I was bringing up in
this thread is that as core and container.java share a significant
amount of implementation, and container.java is central to both SCA
and the Java Tuscany implementation, it makes sense to combine the
two as opposed to duplicating the shared implementation.
Jim
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: move of container.java to core2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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. I believe having container.java as a separate project
> rely on core2 is the wrong approach. This leaves three options:
>
> - move the required classes to SPI
> - make container.java not dependent on core classes by duplicating them
> - merging container.java with core.
>
> I think moving the classes to SPI is not the best approach since they
> are implementations. Having duplicate classes does not seem to be
> the optimal approach either as that will result in a maintenance
> burden and a lot of code repetition. As background, the sharing of
> classes between core2 and container.java arises from the fact that the
> runtime uses a POJO model to assemble system services, and hence there
> is commonality between the two.
>
> I prefer to do the latter as it appears to be the cleanest. Also,
> java.container is not a very good example of how to extend the
> recursive core due to its "advanced" capabilities. I'd rather include
> a simple Java container geared to demonstrating how to extend the
> runtime. It would be helpful if people provide input over the next
> day...I plan to implement choice 3 tomorrow if there are no alternatives.
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I would prefer another option: Define a clean SPI contract with just
interfaces so that containers (component implementation extensions) do
not have to depend on internal classes from the core project. I thought
that it was the reason for having an SPI project separate from core.
I think that the core runtime and the java container should be decoupled
with clean interface-based contracts between the two. What are the
technical issues preventing us from achieving that?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org