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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
