axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Jordahl" <>
Subject RE: [Axis2] C code generation using codegen tool - whre to put the code?
Date Tue, 23 May 2006 17:17:21 GMT
+1 to Dennis' feeling that the codegen module does not need to be broken
out of Axis2.

Like it or not, the code generation parts of Axis are intimately tied to
the core engine in both spirit and customers minds. 

Tom Jordahl
Adobe ColdFusion Team

-----Original Message-----
From: Dennis Sosnoski [] 
Sent: Friday, May 19, 2006 5:54 PM
Subject: Re: [Axis2] C code generation using codegen tool - whre to put
the code?

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 ( and 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? It seems to me like it's only useful for SOAP 
frameworks, and those all have their own code generation

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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message