archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nico...@apache.org>
Subject Re: Plan to migrate towards Spring?
Date Tue, 19 Feb 2008 10:42:47 GMT
About "Create alternative descriptors to use Spring for existing codebase."

We could create a maven plugin (similar to plexus one) to parse sources and
get Spring IoC annotations converted to plexus XML config (something like
springdoclet). It may also convert spring XML context to plexus
component.xml .

Based on this we could keep the plexus-based infrastructure until all
components have been migrated to use Spring, and then switch.

Nico.


2008/2/19, Joakim Erdfelt <joakim@erdfelt.com>:
>
> We also have a few of these tasks as dependent on the integration of
> Spring into the code tree.
>
> If we phase in the Spring support, and try to use spring and plexus at
> the same time we can't phase those tasks in because it'll likely break
> the plexus support.
>
> A rough timeline / order of tasks.
>
> Isolated Changes, No Spring Dependency.
> #)  Replace plexus-cli with commons-cli
> #)  Replace plexus CommandLine with ProcessBuilder
> #)  Replace plexus-digest with commons-codec implementation.
> #)  Bring plexus-expression-evaluator into archiva code-tree.
> #)  Use slf4j instead of plexus logger.
> #)  Use commons-io to replace plexus-utils equivalents.
> #)  Use commons-lang to replace plexus-utils equivalents.
> #)  Create AnonymousProjectReader
> #)  Migrate away from plexus-webdav to atlassian DAVServlet
> #)  Migrate webwork/xwork to Struts 2
>
> Changes Depending on Spring Integration.
>
> #)  Create jetty bundle (MRM-688)
> #)  Add Spring deps into existing codebase.
> #)  Create alternative descriptors to use Spring for existing codebase.
>     (At this point in time we now have a plexus and spring option.
>      We could attempt to set up a profile to use one over the other)
> #)  Switch plexus-registry for PlexusJavaConfig
> #)  Migrate plexus-cache to SpringCache
> #)  Switch from JDO/JPox to JPA.
> #)  Help RedBack use Spring.
> #)  Integrate RedBack / Spring into Archiva.
> #)  Switch plexus-scheduler for SpringScheduler
> #)  Switch plexus-taskqueue for other Queue (JMS?)
>
> (More comments inline)
>
> Brett Porter wrote:
> >
> > On 19/02/2008, at 9:37 AM, Joakim Erdfelt wrote:
> >
> >> org.codehaus.plexus.cache.Cache;
> >>
> >> Used:
> >>   archiva-repository-layer
> >>   archiva-policies
> >> Plan:
> >>   Use ehcache directly
> >>   or use Spring Caching (which uses ehcache)
> >
> > the latter sounds best. Also worth reviewing whether this is a design
> > issue - I'm surprised the policies needs a cache?
>
> The cache-failures-policy uses it.
> Easy, Once Spring is in place.
>
> >
> >> org.codehaus.plexus.commandline.DefaultExecutableResolver;
> >> org.codehaus.plexus.commandline.ExecutableResolver;
> >>
> >> Used:
> >>   archiva-webapp-test
> >> Plan:
> >>   Investigate Need.
> >
> > agreed.
> >
> >>
> >>   Fork into archiva if truely needed.
> >
> > well - there should be no problem with using plexus-utils if it
> > provides something for the time being. commons-exec did start moving
> > again too, I noticed.
>
> Nice.  Haven't looked at commons-exec yet.
> I fear archiva-webapp-tests is woefully out of date.  Do we limp it
> along?  Archive it?  Send it to sandbox?
>
> >
> >>
> >> org.codehaus.plexus.tools.cli.AbstractCli;
> >>
> >> Used:
> >>   archiva-cli
> >> Plan:
> >>   Use commons-cli instead.
> >
> > I also like the one by Sam Pullara that I used in the continuum data
> > management tools - you might like to check it out (uses annotations)
>
> I'll check it out, sounds nifty.  But honestly, do we really need
> archiva-cli ? ;-)
> It would be easy enough to do, has no dependency on Spring and would
> remove a dependency on Plexus.
>
> >
> >>
> >>
> >> org.codehaus.plexus.util.cli.Commandline;
> >> org.codehaus.plexus.util.cli.CommandLineUtils;
> >> org.codehaus.plexus.util.cli.StreamConsumer;
> >> org.codehaus.plexus.util.cli.WriterStreamConsumer;
> >>
> >> Used:
> >>   archiva-webapp-test
> >> Plan:
> >>   Use JDK 1.5 and java.lang.ProcessBuilder
> >
> > Sounds good if it has the necessary functionality.
>
> Its easy enough to use.  Used it in a bunch of places.
> Our needs within archiva-webapp-test seems straight forward enough.
> This would be easy to do, has no dependency on Spring or Plexus.
>
> >
> >>
> >>
> org.codehaus.plexus.component.repository.exception.ComponentLifecycleException
> ;
> >>
> >>
> org.codehaus.plexus.component.repository.exception.ComponentLookupException
> ;
> >>
> >> org.codehaus.plexus.context.Context;
> >> org.codehaus.plexus.context.ContextException;
> >> org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable
> ;
> >> org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable;
> >>
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializationException
> ;
> >>
> >> org.codehaus.plexus.personality.plexus.lifecycle.phase.Startable;
> >>
> org.codehaus.plexus.personality.plexus.lifecycle.phase.StartingException;
> >>
> >>
> org.codehaus.plexus.personality.plexus.lifecycle.phase.StoppingException;
> >>
> >> org.codehaus.plexus.PlexusConstants;
> >> org.codehaus.plexus.PlexusContainer;
> >> org.codehaus.plexus.PlexusTestCase;
> >>
> >> Used:
> >>   archiva-cli
> >>   archiva-repository-layer
> >>   archiva-webapp
> >>   archiva-artifact-reports
> >>   archiva-configuration
> >>   archiva-core-consumers
> >>   archiva-database
> >>   archiva-database-consumers
> >>   archiva-indexer
> >>   archiva-lucene-consumers
> >>   archiva-proxy
> >>   archiva-scheduled
> >>   archiva-webapp
> >> Plan:
> >>   Switch to Spring Container.
> >
> > We need to assess the impact of this on the webapp - I think we can
> > take all the plexus-isms out of there and just use the annotations,
> > then we could switch to the spring objectfactory pretty easily.
>
> Well, I'm worried about the POJOs using the Plexus specifics like
> Initializable, Startable, ContextAware, etc...
> Those will be hard to coexist with Spring I suspect.
> This will be time consuming, and difficult to do.
>
> >
> >>
> >> org.codehaus.plexus.digest.ChecksumFile;
> >> org.codehaus.plexus.digest.Digester;
> >> org.codehaus.plexus.digest.DigesterException;
> >>
> >> Used:
> >>   archiva-policies
> >>   archiva-commons
> >>   archiva-core-consumers
> >>   archiva-transaction
> >>   archiva-database-consumers
> >> Plan:
> >>   Migrate to commons-codec
> >
> > Are you sure it provides this? I thought these were convenience
> > wrappers for streaming, etc.
>
> Its not a 1 to 1 mapping of functionality, but with commons-codec in the
> picture, making a Checksum utility within Archiva is trivially easy.
> Easy to do, no dependency on Spring / Plexus for this one.
>
> >
> >> org.codehaus.plexus.evaluator.DefaultExpressionEvaluator;
> >> org.codehaus.plexus.evaluator.EvaluatorException;
> >> org.codehaus.plexus.evaluator.ExpressionEvaluator;
> >> org.codehaus.plexus.evaluator.ExpressionSource;
> >> org.codehaus.plexus.evaluator.sources.PropertiesExpressionSource;
> >> org.codehaus.plexus.evaluator.sources.SystemPropertyExpressionSource;
> >>
> >> Used:
> >>   archiva-repository-layer
> >>   archiva-configuration
> >> Plan:
> >>   Migrate expression-evaluator to archiva codebase.
> >
> > Need more info on what this does - seems like something the container
> > should handle?
>
> This is used in a bunch of places to provide a consistent ${expression}
> evaluation, in poms, config files, etc...
> It provides a bunch of expression sources that can be utilized in a
> search stack for values.
> There used to be a commons-el that might work too, but I fear that might
> be the ultimate in overkill for the usecase we have.
> This isn't that hard to do, has no dependency on Spring, and would
> remove a dependency on plexus.
>
> >
> >> org.codehaus.plexus.jdo.DefaultConfigurableJdoFactory;
> >> org.codehaus.plexus.jdo.JdoFactory;
> >>
> >> Used:
> >>   archiva-scheduled
> >>   archiva-database
> >> Plan:
> >>   Migrate to JDK 1.5 + JPA + Annotations
> >
> > Bigger job, but long term seems to make sense. This can be isolated in
> > the database module for now. Also not sure why JDO stuff is in
> > -scheduled.
>
> It shows up in the archiva-scheduled test cases.
> Used to set up a few tests.
> This would be a *BIG* Job, large amount of impact to the
> archiva-database codebase only (i hope).
> This would also eliminate a need for modello (another dependency I'd
> like to eliminate).
>
> >
> >> org.codehaus.plexus.logging.AbstractLogEnabled;
> >> org.codehaus.plexus.logging.Logger;
> >>
> >> Used:
> >>   archiva-repository-layer
> >>   archiva-webapp
> >> Plan:
> >>   Use slf4j directly
> >
> > +1
>
> This would be a simple change that can be done in small changes to the
> code tree.
> This is easy, has no Spring dependency, and moves up closer to
> eliminating Plexus.
>
> >
> >>
> >>   Develop redback <-> spring integration and use it.
> >
> > +1
>
> Big job, probably bigger than the JDO -> JPA effort.
> But I think this would be worth it.
>
> >
> >> org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry;
> >> org.codehaus.plexus.registry.Registry;
> >> org.codehaus.plexus.registry.RegistryException;
> >> org.codehaus.plexus.registry.RegistryListener;
> >>
> >> Used:
> >>   archiva-artifact-reports
> >>   archiva-configuration
> >>   archiva-core-consumers
> >>   archiva-database-consumers
> >>   archiva-indexer
> >>   archiva-lucene-consumers
> >>   archiva-proxy
> >>   archiva-repository-layer
> >>   archiva-scheduled
> >>   archiva-security
> >>   archiva-webapp
> >> Plan:
> >>   Use commons-configuration
> >>   or Spring JavaConfig
> >
> > Will need to look into this. I might just want to migrate the registry
> > to commons.
>
> Using Spring JavaConfig we gain some annotation based configurations too.
> This would also eliminate a need for modello.
>
> >
> >>
> >>
> >> org.codehaus.plexus.scheduler.AbstractJob;
> >> org.codehaus.plexus.scheduler.CronExpressionValidator;
> >> org.codehaus.plexus.scheduler.Scheduler;
> >>
> >> Uses:
> >>   archiva-scheduled
> >>   archiva-webapp
> >> Plan:
> >>   Use Spring Scheduler / Quartz.
> >
> > +1
>
> Medium difficulty level.  This is only half of the scheduling picture.
> We need a persistent queue of tasks too.
>
> >
> >>
> >>
> >> org.codehaus.plexus.taskqueue.execution.TaskExecutionException;
> >> org.codehaus.plexus.taskqueue.execution.TaskExecutor;
> >> org.codehaus.plexus.taskqueue.Task;
> >> org.codehaus.plexus.taskqueue.TaskQueue;
> >> org.codehaus.plexus.taskqueue.TaskQueueException;
> >>
> >> Used:
> >>   archiva-scheduled
> >>   archiva-webapp
> >> Plan:
> >>   Move to Spring JMS?
> >
> > I don't think it needs that - commons-collections and quartz can
> > probably do it :)
>
> Spring JMS exists already and provides a persisted queue for messages.
> We can get far more detailed in our tasks with this approach.
> We can even add a 'IndexNewArtifact' task with each uploaded / found
> artifact that persists to disk to ensure they get processed even with an
> archiva restart.
> We even gain the ability to go distributed with search/indexing in the
> future.
>
> >
> >>
> >>   Use commons-io equivalents
> >
> > +1
>
> Very Easy change.  No dependency on Spring, and brings us closer to
> eliminating Plexus.
>
> >
> >>
> >>
> >> org.codehaus.plexus.util.StringUtils;
> >>
> >> Used:
> >>   archiva-repository-layer
> >> Plan:
> >>   Switch to commons-lang
> >
> > +1
>
> Also a very easy change.  No dependency on Spring, and brings us closer
> to eliminating plexus.
>
> >
> >> org.codehaus.plexus.util.xml.pull.XmlPullParserException;
> >>
> >> Used:
> >>   archiva-artifact-converter
> >>   archiva-webapp
> >> Plan:
> >>   Implement AnonymousProjectReader idea from 1.0 days to
> >>   read the xml / modelVersion and then load the appropriate
> >>   ProjectModel###Reader object.
> >
> > Already implemented using StAX using the modello stax reader. That
> > would be the fastest approach - just reuse what Maven provides.
>
> Great.  Not an option (yet).
> As the maven Artifact libs are not friendly to missing content.
> We'll be right back to the issues we had with missing poms not allowing
> content to be indexed / downloaded / browsed / etc...
> The project readers in place in Archiva have been historically faster
> and less memory intensive than their maven component alternatives.
>
> >
> >>
> >> Plan:
> >>   Fork it.could.webdav into new archiva-davserver component.
> >
> > Let's look at this separately - I don't really want to maintain a DAV
> > implementation - I think we should work with someone else that does.
>
> Atlassian has a DAVServlet that we might be able to get away with.
> We'll have to check ASL license compatibility and whatnot, but it might
> be a good alternative.
> I'd also like to get a DAVServlet that coexists with the top level URL
> so that we can get OSX and Win32 native clients working with archiva as
> well. (A problem with the existing it.could.webdav impl)
>
> >
> >> org.codehaus.plexus.xwork.action.PlexusActionSupport;
> >>
> >> Used:
> >>   archiva-webapp
> >> Plan:
> >>   Switch to SwingMVC
> >
> > Swing?
>
> Whoops. SpringMVC
>
> >
> > I'm not convinced SpringMVC is a good move - we would be better going
> > to struts2 or staying with Webwork since it's minimal impact to the
> > code. The other doesn't bring any obvious benefit for all the work?
>
> I've been checking out some performance / scalability / tooling /
> testing tests recently at my office with regards to web frameworks.
> SpringMVC beat everything but Struts 1.x in performance.
> And SpringMVC makes testing really easy to boot.
> That's my motivation behind it.
>
> But yes, it would have a big impact.
> So, lets just consider something lower impact, moving from xwork/webwork
> to Struts 2.  I think we have some friends in the struts 2 community to
> help us out if we hit a roadblock or two.  Beside, we should be
> supporting out Apache brethren too.
> >
> > Good proposal, though - when will you be getting started?
>
> Some time between now and the end of the year.
>
> My time is limited at the moment, but I still have a desire to help move
> the project forward.
>
> - Joakim
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message