I've solved the main issues, added some tiny doc and unit tests.

Still early alpha code but now stable and ready for review if you want to
test it on Continuum.

Some tests (like DefaultPathParserTest) migrate succesfully to spring
context execution using the PlexusInSpringTestCase without any change.

Many other archiva tests fails as the XSLT translation cannot convert XML
formated "configuration" to be injected in CommonsConfigurationRegistry as a
PlexusConfiguration :

    <component>
      <role>org.codehaus.plexus.registry.Registry</role>
      <role-hint>configured</role-hint>      <implementation>
org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry
</implementation>
      <configuration>
        <properties>
          <system/>
          <xml fileName="${basedir}/src/test/conf/repository-manager.xml"
               config-name="org.apache.maven.archiva" config-at="
org.apache.maven.archiva"/>
        </properties>
      </configuration>
    </component>

The current stylesheet converts such <configuration> to a blank value.

To support such configuration, we need

1.  a String2PlexusConfiguration PropertyEditor (maybe not  trivial, but
should be possible)
2.  a XSL way to store the configuration child nodes as XML attributes.

I'm a XSL newbee so have no idea how to output the current node and all it's
children as a text content.
I've tested <xsl:copy-of slect="."> but without the expected result.

I also tried to set the configuration value as a nested CDATA content, but
cannot find how to create the plexus:configuration content as as CDATA
element.  <xsl:output cdata-section-elements="plexus:configuration"> didn't
fix this.








2008/2/26, nicolas de loof <[EMAIL PROTECTED]>:
>
> For your information, plexus-spring no handle plexus requirement without
> filed-name set.
>
> The -Dplexus-spring.debug=true option can be used to dump the translated
> spring XML (using dom4j)
>
> PlexusInSpringTestCase as been used as replacement for PlexusTestCase in
> archiva-policies with no other change required in the test class (only a new
> spring context file required to declare the LoggerManager)
>
> Some debugging logs have been added to trace the filed-injection and
> dependencies resolution.
>
>
> .. but still not ready as
> CacheFailuresTransferTest.testGetWithCacheFailuresOff pass run alone, but
> not if ran after testGetWithCacheFailuresOn!
> Seems there is some incomplete support on context cleanup / dispose
>
> Please be patient, Rahul ;-)
>
> Nico.
>
>
>
> 2008/2/26, Joakim Erdfelt <[EMAIL PROTECTED]>:
> >
> > nicolas,
> >
> > This is way cool!
> > A very slick way of helping the transition.
> > I'm looking forward to some free time to dive into it.
> >
> >
> > - Joakim
> >
> >
> >
> > nicolas de loof wrote:
> > > Hi Rahul,
> > >
> > > Thanks for yout interest for this plexus-to-spring migration helper.
> > > The code is still early experimental and requires some more testing :
> > it
> > > only has been tested on 2 archiva testcases and requires many fixes
> > and
> > > testcases to get stable.
> > >
> > > Please give me one week to test it more, add debugging logs and better
> > error
> > > handling / reporting : The current code is not really easy to debug
> > when
> > > some unexpected IoC occur... I also may improve support for plexus
> > lifecycle
> > > and specificities, as long as I discover requirements from archiva
> > codebase.
> > >
> > > It is allready isolated from archiva for reuse, and can move to plexus
> > when
> > > ready (I've no access to plexus svn).
> > >
> > > I promise to inform you about progress ;-)
> > >
> > > Nicolas.
> > >
> > > 2008/2/25, Rahul Thakur <[EMAIL PROTECTED]>:
> > >
> > >> Hi Nicolas,
> > >>
> > >> Sorry, I have looked at the recent updates to the code, hence my
> > >> question. Is this 'ready' enough to be used outside Archiva? I'd like
> > to
> > >> integrate this into Continuum.
> > >>
> > >> I think it might make sense to have this module in Plexus SVN repo -
> > wdyt?
> > >>
> > >> Good stuff!
> > >>
> > >> Cheers,
> > >> Rahul
> > >>
> > >> nicolas de loof wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I've repackaged and improved the spring support for plexus
> > components in
> > >>>
> > >> a
> > >>
> > >>> dedicated poject
> > >>> -->
> > >>>
> > >>>
> > >>
> > https://svn.apache.org/repos/asf/maven/archiva/branches/springy/plexus-spring/
> > >>
> > >>> This new module provides runtime translation from plexus component
> > >>> descriptors to a Spring XML context, using a simple XSL file and a
> > >>>
> > >> custom
> > >>
> > >>> ApplicationContext. Any existing plexus jars can then be used in a
> > >>>
> > >> spring
> > >>
> > >>> context.
> > >>>
> > >>> It defines a custom <plexus:> spring-namespace. Under the hood a
> > custom
> > >>> FactoryBean handles plexus components field-injection and (some)
> > >>>
> > >> lifecycle
> > >>
> > >>> interfaces. As I discover plexus features by testing on archiva, I'd
> > be
> > >>> pleased to get more infos on plexus IoC specificities.
> > >>>
> > >>> It also provides a PlexusInSpringTestCase that is a replacement
> > class
> > >>>
> > >> for
> > >>
> > >>> PlexusTestCase, providing equivalent methods and behavior.
> > >>>
> > >>> I've applied this (in springy branch) on archiva-policies and
> > >>>
> > >> archiva-proxy
> > >>
> > >>> (with some test failures in latest I have to investigate)
> > >>>
> > >>> On this basis and with the required improvements, I thing this is a
> > nice
> > >>>
> > >> way
> > >>
> > >>> to move archiva (or other plexus-based app) to spring and then
> > gradually
> > >>> refactor plexus components, either using Spring annotation or XML
> > >>>
> > >> context
> > >>
> > >>> files (my +1 for context files).
> > >>>
> > >>> Nicolas.
> > >>>
> > >>>
> > >>>
> > >
> > >
> >
> >
>

Reply via email to