On Wed, 2007-10-31 at 17:31 +0100, Grzegorz Kossakowski wrote:
> 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.
Nice. Thanks for this instructions.
>
> > 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.
Actually this is a very good example of some short comes in our current
wrappers. The serviceable components are not initialized correctly. My
custom transformer is using service(...) and had thrown a NPE. After
debugging I found out that service(...) never got called.
The solution is to implement:
public void setManager(ServiceManager manager) throws ServiceException {
super.service(manager);
this.manager=manager;
}
and add to your spring config:
<property name="manager"
ref="org.apache.avalon.framework.service.ServiceManager"/>
>
> Ok, this is bit tedious and hacky because you really need to examine *all*
> implementation details of
> *all* super classes.
I am lucky that I have lots of experience with cocoon < 2.2 so the
interfaces and super classes are familiar to me but which strikes me
awkward is that they do not work as they did in "before 2.2".
> 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.
+1
>
> 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?
IMO we should otherwise avalon will be around forever and personally I
do not see the need for 2 different IoC container.
>
> > 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, can do it, but then we need to define IMO as well a new interface
for our components. I guess we still do
a) generate SAX
b) transform SAX
...
meaning all components (except serializer and readers) are producing SAX
events, right?
> >
> > 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.
will do so.
salu2
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
