archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maria Odea Ching" <och...@apache.org>
Subject Re: Plan to migrate towards Spring?
Date Tue, 19 Feb 2008 09:53:38 GMT
On Feb 19, 2008 11:23 AM, Joakim Erdfelt <joakim@erdfelt.com> wrote:

> 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.
>

Yeah, this is very likely to happen..


>
> 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.


+1 on Spring Caching


>
>
> >
> >> 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?


I don't think the webapp-tests ever got updated in parallel with any of our
releases (even the alpha & beta releases), so a lot of work would have to be
put here if we're going to limp it along..


>
> >
> >>
> >> 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.


+1, I agree this is going to be time consuming. We have to make sure that no
injected dependencies are left out. And there's also the tests, they are
using plexus as well so that's double the work for the migration.


> >
> >>
> >> 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).


+1 to JPA!
Some of the tests in the consumers are also using JDO.


>
>
> >
> >> 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.


A big +1 to this!
Having a Redback Spring Integration would also increase the users base of
Redback :)


>
>
> >
> >> 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.


I haven't used either, but +1 to migrating the registry.


>
>
> >
> >>
> >>
> >> 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.


+1 I was able to use the Spring Scheduler before and it wasn't very
difficult to get familiar with.


>
> >
> >>
> >>
> >> 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.
>

I'm not certain but doesn't the Spring Scheduler has a task executor as
well?


>
> >
> >>
> >>   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.
>

+1 to this


>
> >
> >> 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.


+1
I'm not very keen on switching to SpringMVC, I remember a few not-so-good
memories I had with its form controllers when I used it before (though that
was already a long time ago).
And as what has already been mentioned, moving to Struts 2 has a lower
impact.


> >
> > 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.
>

Yay!
Things are already looking great in Archiva :)


>
> - Joakim
>


Thanks,
Deng

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