Dennis Sosnoski wrote:
Sanjiva Weerawarana wrote:
On Fri, 2006-05-19 at 10:25 +0530, Ajith Ranabahu wrote:
As for moving the codegen tool out, I'm not really sure we should be
doing that right now. One issue I see in that is the use of core Axis2
components inside the codegen module where there is a tight dependency
on Axis2 components such as the Axis service. Yet the codegen is
supposed to be "independent" to a certain extent and it surely belongs
in a seperate project.
So why not do it? All we need is to depend on the axis2-core jar right?
We can pick up a specific version of that from a maven repo and make it
work. I'm not seeing a negative reason for moving it out ...
We now have the data binding frameworks (at least JiBX, XMLBeans, and
JAXB) decoupled from the codegen module for classloading purposes, but
still tightly coupled in terms of the code. That means the couplings
go both ways - codegen depends on the Axis2 core code, and the Axis2
data binding modules depend on codegen. The situation with ADB and
JaxMe is even worse, since these haven't been made into separate
plugin modules for the codegen yet
(http://issues.apache.org/jira/browse/AXIS2-558 and
http://issues.apache.org/jira/browse/AXIS2-559). As long as there are
these strong dependencies there appears to be little to gain by moving
codegen into a separate project.
These difficulties aside, I don't really see a lot of benefit in
moving this to a separate project. In the case of Axiom and TcpMon the
coupling problems were much less and the use case for the code as
separate entities much better, I'd think. Do you see other uses for
the code generation beyond Axis2C?
We could codegen for PHP, for PHP binding build on top of Axis2C.
Thanks,
Samisa...
It seems to me like it's only useful for SOAP frameworks, and those
all have their own code generation implementations.
I'd think the needs of the C code generation can be handled by just
adding a target to the build that generates a zip with the jars needed
for codegen. That would certainly make it easier for me and the other
developers working on the codegen than having it as a separate project.
- Dennis
---------------------------------------------------------------------
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]
