On 19/02/2008, at 9:37 AM, Joakim Erdfelt wrote:
> I've felt that we need to migrate our choice of IoC (plexus) towards
> a better documented and better supported container (I'm leaning
> towards Spring)
>
> I also recognize that this kind of change can't be done quickly or
> in a big-bang approach.
> I've started an assessment of the plexus usage within Archiva and
> have planned out a first draft on what we can do to change that usage.
Sounds great.
>
> There are plenty of plexus components that need to be migrated
> before we can make the change to use a container such as spring.
> There's also the whole Redback package that would need to be
> migrated as well.
Another thing is that (if it's easier/makes sense) we can continue
using those plexus components but add alternate wiring information to
them. I think some of them are valuable or need a different fix (eg,
the webdav).
>
>
> So here's my first draft.
> If there is interest, we can start to plan, schedule, and do the
> changes in small increments.
> This should probably live as a document in the wiki, but for now I
> think we can discuss this in the mailing list.
+1
>
>
> 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?
> 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.
>
>
> 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)
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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?
> 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.
>
>
> org.codehaus.plexus.logging.AbstractLogEnabled;
> org.codehaus.plexus.logging.Logger;
>
> Used:
> archiva-repository-layer
> archiva-webapp
> Plan:
> Use slf4j directly
+1
>
> Develop redback <-> spring integration and use it.
+1
>
>
> 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.
>
>
> 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
>
>
> 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 :)
>
> Use commons-io equivalents
+1
>
>
> org.codehaus.plexus.util.StringUtils;
>
> Used:
> archiva-repository-layer
> Plan:
> Switch to commons-lang
+1
> 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.
>
> 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.
>
>
> org.codehaus.plexus.xwork.action.PlexusActionSupport;
>
> Used:
> archiva-webapp
> Plan:
> Switch to SwingMVC
Swing?
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?
Good proposal, though - when will you be getting started?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
|