cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Logging of AbstractSAXTransformer
Date Wed, 31 Oct 2007 16:31:31 GMT
Thorsten Scherler pisze:
>> Just go to the Cocoon's root directory and type:
>> mvn clean install (or some variant of this command like with -P allblocks, etc)
>> This will install all Cocoon's snapshot artifacts made from Cocoon's trunk to your
local Maven
>> repository. Then, when developing your application you just need to change version
of Cocoon's
>> dependencies to snapshosts, e.g. dependency on cocoon-core artifact should have 2.2.0-RC3-SNAPSHOT
>> version.
> That means (for other newbies) you need to edit your pom.xml and update
> all dependencies versions. If you have followed the tutorial on
> generating you own block you will need to change at least three
> dependencies. 

Yep, and keep in mind that we increase version numbers of modules after releasing (first internally)
our modules so in order to keep using trunk you will have to increase this numbers in your
pom file too.

If you want to make sure that you are really using dependencies built from latest trunk you
follow these steps:
1. go to Cocoon's trunk directory and hit this command:
mvn dependency:purge-local-repository -DresolutionFuzziness=groupId
(this will remove all Cocoon artifacts from your local repository)

2. Then:
mvn clean install
(this will install only latest snapshots of Cocoon artifacts to your local repository)

3. go to your application directory and type:
mvn clean install -o
(build in offline mode)

If build ends with success it means that you are using latest versions of all Cocoon artifacts.

NOTE: You may need to add declaration of depedency plug-in to pom.xml before using it.

> Well, till now I just found transformers/generators that are extending
> e.g. AbstractSAXTransformer which is an "old" component using avalon as
> usual. 

AbstractSAXTransformer is not a component but just an abstract class assuming its descendants
be Avalon-components. If you are extending such a class you must be careful because you must
if your super class can work ok without assumption that Avalon-contracts are respected as
they won't
be if your component is a Spring bean.

For example, when extending AbstractSAXTransformer you may want to check why it implements
Serviceable interface. As you can see:
    public void service(ServiceManager aManager) throws ServiceException {
        this.manager = aManager;

It only stores a manager so you need to check if it is used somewhere. After bit of research
figure out that manager is not used in AbstractSAXTransformer so this class can live without
ServiceManager at all. The same goes for other contracts.

Ok, this is bit tedious and hacky because you really need to examine *all* implementation
details of
*all* super classes. This brings us to the point:
For developing pure Spring beans we need to create new versions of all existing abstract classes
that will not depend on Avalon by any means and deprecate old classes.

This process started to begin (see org.apache.cocoon.util.AbstractLogEnabled class for example)
there is a work left. I would like to hear other's opinion on this.
Are we going to reimplement all of our abstract classes?

> Is there a replacement of the AbstractSAXTransformer as avalon-less (al)
> class? If I write a al-tranformer do I have to implement an interface
> with my transformer?

That's the safest method but you may use abstract classes if you are sure what are you doing.
Another method is to reimplement abstract class in Avalon-free way and contribute it as a
patch to
us. This may start as soon as we come up with clean rules on how this classes should look

> Yeah and maybe some "master" examples such as an
> al-AbstractSAXTransformer and al-AbstractGenerator.


>> Since I'm going to have some break from studying at my university in upcoming days
I would do this
>> work since such document is urgently needed.
>> Thorsten, I would be grateful if you could help me with this by reviewing what I
write or even
>> gathering all e-mails related to this topic from archives. Yes, this would be very
helpful because
>> it would generate more pressure on me. ;-)
> Yeah, will try to give you and the team a helping hand while advancing.
> We may want to open an issue to gather all links.

I agree, feel free to create such issue.

Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

View raw message