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 would
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 will
be Avalon-components. If you are extending such a class you must be careful
because you must check
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 you
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) but
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 like.
>
> Yeah and maybe some "master" examples such as an
> al-AbstractSAXTransformer and al-AbstractGenerator.
Yep.
>> 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
http://reflectingonthevicissitudes.wordpress.com/
