Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: domain of nicolas.deloof@gmail.com
 designates 209.85.128.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=RmCwl/UOWldExQ5fDpFFYoY36e4WRvSRLC244XaFyG4YLnJwDaLUgYOb6Nl6FY9wvL8/Nq3sUfLYaP4S9oR+K6UqxJkGypD7Q6Eeekk48KO0IB7Magp8IspsSLL+RdNTj2NW5V6JKFcKLCjbNLTtTGZsaNC3Q8Tmhvk+NCII43E=
Message-ID: <4c39e3030802190310o7e39140dp3cdcfb94b91b157e@mail.gmail.com>
Date: Tue, 19 Feb 2008 12:10:48 +0100
From: "nicolas de loof" <nicolas@apache.org>
Sender: nicolas.deloof@gmail.com
To: archiva-dev@maven.apache.org
Subject: Re: Plan to migrate towards Spring?
In-Reply-To: <1a57a2980802190153k3c2523d1m5b1adbb247813773@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_18724_9010723.1203419448753"
References: <47BA089C.1030803@erdfelt.com>
	 <9201F89A-B6E2-41EA-B9F2-B0C45EAB5E19@apache.org>
	 <47BA4BC5.2070407@erdfelt.com>
	 <1a57a2980802190153k3c2523d1m5b1adbb247813773@mail.gmail.com>

------=_Part_18724_9010723.1203419448753
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

"Integrate RedBack / Spring into Archiva."

What is the advantage of redback compared to spring-security (aka "acegi") ?

spring-security allready supports role-based secutiry, DB user store and
"remember me".

Nico.


2008/2/19, Maria Odea Ching <oching@apache.org>:
>
> 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
>

------=_Part_18724_9010723.1203419448753--