You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/09/28 12:52:17 UTC

New MetaGenerate subproject in Excalibur

Folks,

The result of a couple of hours work.

This project generates basic xinfo for Phoenix.  It uses QDox by Joe 
Walnes and others.

See http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/metagenerate/
Please take a look and let me know if it is worth taking further.

Features :

    * Xinfo generation only
    * Jars 13KB in size so far.
    * QDox jar is 50KB so far
    * Sub-second response time
    * Ant taskdef
    * Integration test using Junit.

Thoughts?  Kill or go further?

We potentially have a way of generating all meta info for all components 
for Phoenix, Fortress etc.

The taskdef loks like this so far :-

    <generatemeta dest="build/metagenerate">
      <fileset dir="src/test">
        <include name="**/*.java"/>
      </fileset>
    </generatemeta>

It is quite possible that we could have extra attributes for things like

    * Checking service names and dependency names against the compiled
      class-model
    * manifest name

Going back to bed now as am very hung-over.

- Paul
 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,

I now have this generating Xinfo, MxInfo and manifests to a certain 
level of satisfaction.

I have run it through the Phoenix codebase and it generates the same 
MXInfo files Phoenix does which functional differences :

  1) it specifies "java.io.File[]" instead of "File[]"
  2) when taking decriptions for params for operations it is smarter
     about the variable name not being prepended to the description.

It runs (I guess) five times faster than xdoclet (not my magic, that of 
QDox).  
It is also tiny in comparison to xdoclet.  Qdox and the MetaGenerate jar 
are a quarter of the combined size of of the xdoclet jars.
Lasty it does not use Log4J (v important to us I hope).

I need some help on the issue of CheckStyle (I cannot for the life of me 
get it running)

Could people give it a run through (it's own test target generates 
output to build/metagenerate)

Next Features
-------------

  * Compatability targets as configurable Ant attributes.
    (Fortress features etc).
  * Optional Validation concepts -
    checks for non existant class given 'service name="org.fred.MisSpelled"'

Regards,

- Paul




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,

>> We're _not_ using one codebase then?  
>
>
>
> Correct - the phonix code base for component assembly reads in an 
> xinfo based on a phoneix specific DTD and the Merlin system reads in 
> an xinfo based on the excalibur/meta type DTD.  The DTDs describe 
> similar things but the structures are different.  In the 
> excalibur/meta DTD you have the addition of context, extensions and 
> stage depedencies which do not exist in the Phoenix meta.  In 
> addition, all of the second level elements can contain attribute 
> defintions (which don't exist in the Phoenix DTD).
>
> Basically, excalibur/meta is a superset of the Phoenix meta.  Merlin 
> can describe a Phoneix block using the excalibur/meta but the reverse 
> is not true.  Take a look at the page 
> http://jakarta.apache.org/avalon/excalibur/meta/type.html for an 
> example of a excalibur/meta type description.

I knew that.

I still felt it was possible to generate multiple outputs.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Stephen McConnell <mc...@apache.org>.

Paul Hammant wrote:

> Stephen,
>
>> No, but it reads Phoenix specific tags and generates Phoenix specific 
>> meta.
>>
>>> We can have one XML generater that generates all for all yes?
>>
>>
>> Maybe - but not in the way its implemented - the code base is 
>> implicitly Phoenix based in that the code knows how to translate a 
>> "phoenix:xxx" to corresponding Phoenix meta statement in a file. 
>> That's actually what I found attractive - the implementation is clean 
>> because is is NOT doing a generic generation process.
>>
>>> We could have switches in the Ant taskdef to control the generated XML?
>>
>>
>> Sure - but how would seperate the different meta models without a 
>> corresponding parrallel tag translation engine for excalibur/meta?  
>> Just for reference - what you have written appears to me to be a good 
>> example of a tag translation engine for Phoenix.
>
>
> Because it picks op on the word "phoenix"?  The xinfo file it 
> generates does not have the word "phoenix" in it
>
> We're _not_ using one codebase then?  


Correct - the phonix code base for component assembly reads in an xinfo 
based on a phoneix specific DTD and the Merlin system reads in an xinfo 
based on the excalibur/meta type DTD.  The DTDs describe similar things 
but the structures are different.  In the excalibur/meta DTD you have 
the addition of context, extensions and stage depedencies which do not 
exist in the Phoenix meta.  In addition, all of the second level 
elements can contain attribute defintions (which don't exist in the 
Phoenix DTD).

Basically, excalibur/meta is a superset of the Phoenix meta.  Merlin can 
describe a Phoneix block using the excalibur/meta but the reverse is not 
true.  Take a look at the page 
http://jakarta.apache.org/avalon/excalibur/meta/type.html for an example 
of a excalibur/meta type description.

Cheers, Steve.

>
> Regards,
>
> - Paul
>
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,

> No, but it reads Phoenix specific tags and generates Phoenix specific 
> meta.
>
>> We can have one XML generater that generates all for all yes?
>
> Maybe - but not in the way its implemented - the code base is 
> implicitly Phoenix based in that the code knows how to translate a 
> "phoenix:xxx" to corresponding Phoenix meta statement in a file. 
> That's actually what I found attractive - the implementation is clean 
> because is is NOT doing a generic generation process.
>
>> We could have switches in the Ant taskdef to control the generated XML?
>
> Sure - but how would seperate the different meta models without a 
> corresponding parrallel tag translation engine for excalibur/meta?  
> Just for reference - what you have written appears to me to be a good 
> example of a tag translation engine for Phoenix.

Because it picks op on the word "phoenix"?  
The xinfo file it generates does not have the word "phoenix" in it

We're _not_ using one codebase then?  

Regards,

- Paul




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Stephen McConnell <mc...@apache.org>.

Paul Hammant wrote:

> Stephen,
>
>>> Stephen,
>>>
>>> No dude, we're supposed to do it in the same package! This one 
>>> generates meta information, yours uses it!? 
>>
>>
>>
>>
>> Umm .. your going to have to explain this some more.
>> The code that is there is Phoenix specific - I'm talking about 
>> equivalent code targetted at the excalibur/meta package.
>
>
> If does not import any Phoenix classes.


No, but it reads Phoenix specific tags and generates Phoenix specific meta.

>
> We can have one XML generater that generates all for all yes?


Maybe - but not in the way its implemented - the code base is implicitly 
Phoenix based in that the code knows how to translate a "phoenix:xxx" to 
corresponding Phoenix meta statement in a file. That's actually what I 
found attractive - the implementation is clean because is is NOT doing a 
generic generation process.

>
> We could have switches in the Ant taskdef to control the generated XML?


Sure - but how would seperate the different meta models without a 
corresponding parrallel tag translation engine for excalibur/meta?  Just 
for reference - what you have written appears to me to be a good example 
of a tag translation engine for Phoenix.

Steve.

>
> - Paul
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,

>> Stephen,
>>
>> No dude, we're supposed to do it in the same package! This one 
>> generates meta information, yours uses it!? 
>
>
>
> Umm .. your going to have to explain this some more.
> The code that is there is Phoenix specific - I'm talking about 
> equivalent code targetted at the excalibur/meta package.

If does not import any Phoenix classes.

We can have one XML generater that generates all for all yes?

We could have switches in the Ant taskdef to control the generated XML?

- Paul



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Stephen McConnell <mc...@apache.org>.

Paul Hammant wrote:

> Stephen,
>
> No dude, we're supposed to do it in the same package! This one 
> generates meta information, yours uses it!? 


Umm .. your going to have to explain this some more.
The code that is there is Phoenix specific - I'm talking about 
equivalent code targetted at the excalibur/meta package.

Steve.

>
>
> - Paul
>
>>
>> Paul:
>>
>> Have just taken a look - initial impressions are that it's a nice 
>> model to work with - am thinking about cloning what your doing for 
>> the meta package - any thoughts ?
>>
>> Steve.
>>
>>
>> Paul Hammant wrote:
>>
>>> Folks,
>>>
>>> The result of a couple of hours work.
>>>
>>> This project generates basic xinfo for Phoenix.  It uses QDox by Joe 
>>> Walnes and others.
>>>
>>> See 
>>> http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/metagenerate/
>>> Please take a look and let me know if it is worth taking further.
>>>
>>> Features :
>>>
>>>    * Xinfo generation only
>>>    * Jars 13KB in size so far.
>>>    * QDox jar is 50KB so far
>>>    * Sub-second response time
>>>    * Ant taskdef
>>>    * Integration test using Junit.
>>>
>>> Thoughts?  Kill or go further?
>>>
>>> We potentially have a way of generating all meta info for all 
>>> components for Phoenix, Fortress etc.
>>>
>>> The taskdef loks like this so far :-
>>>
>>>    <generatemeta dest="build/metagenerate">
>>>      <fileset dir="src/test">
>>>        <include name="**/*.java"/>
>>>      </fileset>
>>>    </generatemeta>
>>>
>>> It is quite possible that we could have extra attributes for things 
>>> like
>>>
>>>    * Checking service names and dependency names against the compiled
>>>      class-model
>>>    * manifest name
>>>
>>> Going back to bed now as am very hung-over.
>>>
>>> - Paul
>>>
>>>
>>>
>>> -- 
>>> To unsubscribe, e-mail:   
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail: 
>>> <ma...@jakarta.apache.org>
>>>
>>>
>>>
>>
>
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,

No dude, we're supposed to do it in the same package! This one generates 
meta information, yours uses it!?

- Paul

>
> Paul:
>
> Have just taken a look - initial impressions are that it's a nice 
> model to work with - am thinking about cloning what your doing for the 
> meta package - any thoughts ?
>
> Steve.
>
>
> Paul Hammant wrote:
>
>> Folks,
>>
>> The result of a couple of hours work.
>>
>> This project generates basic xinfo for Phoenix.  It uses QDox by Joe 
>> Walnes and others.
>>
>> See http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/metagenerate/
>> Please take a look and let me know if it is worth taking further.
>>
>> Features :
>>
>>    * Xinfo generation only
>>    * Jars 13KB in size so far.
>>    * QDox jar is 50KB so far
>>    * Sub-second response time
>>    * Ant taskdef
>>    * Integration test using Junit.
>>
>> Thoughts?  Kill or go further?
>>
>> We potentially have a way of generating all meta info for all 
>> components for Phoenix, Fortress etc.
>>
>> The taskdef loks like this so far :-
>>
>>    <generatemeta dest="build/metagenerate">
>>      <fileset dir="src/test">
>>        <include name="**/*.java"/>
>>      </fileset>
>>    </generatemeta>
>>
>> It is quite possible that we could have extra attributes for things like
>>
>>    * Checking service names and dependency names against the compiled
>>      class-model
>>    * manifest name
>>
>> Going back to bed now as am very hung-over.
>>
>> - Paul
>>
>>
>>
>> -- 
>> To unsubscribe, e-mail:   
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <ma...@jakarta.apache.org>
>>
>>
>>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: New MetaGenerate subproject in Excalibur

Posted by Stephen McConnell <mc...@apache.org>.
Paul:

Have just taken a look - initial impressions are that it's a nice model 
to work with - am thinking about cloning what your doing for the meta 
package - any thoughts ?

Steve.


Paul Hammant wrote:

> Folks,
>
> The result of a couple of hours work.
>
> This project generates basic xinfo for Phoenix.  It uses QDox by Joe 
> Walnes and others.
>
> See http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/metagenerate/
> Please take a look and let me know if it is worth taking further.
>
> Features :
>
>    * Xinfo generation only
>    * Jars 13KB in size so far.
>    * QDox jar is 50KB so far
>    * Sub-second response time
>    * Ant taskdef
>    * Integration test using Junit.
>
> Thoughts?  Kill or go further?
>
> We potentially have a way of generating all meta info for all 
> components for Phoenix, Fortress etc.
>
> The taskdef loks like this so far :-
>
>    <generatemeta dest="build/metagenerate">
>      <fileset dir="src/test">
>        <include name="**/*.java"/>
>      </fileset>
>    </generatemeta>
>
> It is quite possible that we could have extra attributes for things like
>
>    * Checking service names and dependency names against the compiled
>      class-model
>    * manifest name
>
> Going back to bed now as am very hung-over.
>
> - Paul
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>