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
