You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Joakim Erdfelt <jo...@erdfelt.com> on 2008/02/18 23:37:16 UTC
Plan to migrate towards Spring?
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.
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.
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.
org.codehaus.plexus.cache.Cache;
Used:
archiva-repository-layer
archiva-policies
Plan:
Use ehcache directly
or use Spring Caching (which uses ehcache)
org.codehaus.plexus.commandline.DefaultExecutableResolver;
org.codehaus.plexus.commandline.ExecutableResolver;
Used:
archiva-webapp-test
Plan:
Investigate Need.
Fork into archiva if truely needed.
org.codehaus.plexus.tools.cli.AbstractCli;
Used:
archiva-cli
Plan:
Use commons-cli instead.
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
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.
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
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.
org.codehaus.plexus.i18n.I18N;
Used:
archiva-converter
Plan:
Migrate to standard JDK i18n pattern.
org.codehaus.plexus.jdo.DefaultConfigurableJdoFactory;
org.codehaus.plexus.jdo.JdoFactory;
Used:
archiva-scheduled
archiva-database
Plan:
Migrate to JDK 1.5 + JPA + Annotations
org.codehaus.plexus.logging.AbstractLogEnabled;
org.codehaus.plexus.logging.Logger;
Used:
archiva-repository-layer
archiva-webapp
Plan:
Use slf4j directly
org.codehaus.plexus.redback.authentication.AuthenticationDataSource;
org.codehaus.plexus.redback.authentication.AuthenticationException;
org.codehaus.plexus.redback.authentication.AuthenticationResult;
org.codehaus.plexus.redback.authorization.AuthorizationException;
org.codehaus.plexus.redback.authorization.AuthorizationResult;
org.codehaus.plexus.redback.keys.KeyManager;
org.codehaus.plexus.redback.keys.memory.MemoryKeyManager;
org.codehaus.plexus.redback.policy.AccountLockedException;
org.codehaus.plexus.redback.policy.DefaultUserSecurityPolicy;
org.codehaus.plexus.redback.policy.MustChangePasswordException;
org.codehaus.plexus.redback.policy.UserSecurityPolicy;
org.codehaus.plexus.redback.rbac.RBACManager;
org.codehaus.plexus.redback.rbac.RbacManagerException;
org.codehaus.plexus.redback.rbac.Resource;
org.codehaus.plexus.redback.rbac.UserAssignment;
org.codehaus.plexus.redback.role.RoleManager;
org.codehaus.plexus.redback.role.RoleManagerException;
org.codehaus.plexus.redback.system.check.EnvironmentCheck;
org.codehaus.plexus.redback.system.DefaultSecuritySession;
org.codehaus.plexus.redback.system.DefaultSecuritySystem;
org.codehaus.plexus.redback.system.SecuritySession;
org.codehaus.plexus.redback.system.SecuritySystem;
org.codehaus.plexus.redback.system.SecuritySystemConstants;
org.codehaus.plexus.redback.users.memory.MemoryUserManager;
org.codehaus.plexus.redback.users.User;
org.codehaus.plexus.redback.users.UserManager;
org.codehaus.plexus.redback.users.UserNotFoundException;
org.codehaus.plexus.redback.xwork.filter.authentication.HttpAuthenticator;
org.codehaus.plexus.redback.xwork.interceptor.SecureAction;
org.codehaus.plexus.redback.xwork.interceptor.SecureActionBundle;
org.codehaus.plexus.redback.xwork.interceptor.SecureActionException;
Used:
archiva-security
archiva-webapp
Plan:
Develop redback <-> spring integration and use 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
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.
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?
org.codehaus.plexus.util.DirectoryWalker;
org.codehaus.plexus.util.DirectoryWalkListener;
org.codehaus.plexus.util.FileUtils;
org.codehaus.plexus.util.IOUtil;
org.codehaus.plexus.util.SelectorUtils;
Used:
archiva-repository-layer
archiva-artifact-converter
archiva-common
archiva-configuration
archiva-core-consumers
archiva-database-consumers
archiva-indexer
archiva-metadata-reports
archiva-policies
archiva-transaction
archiva-webapp
Plan:
Use commons-io equivalents
org.codehaus.plexus.util.StringUtils;
Used:
archiva-repository-layer
Plan:
Switch to commons-lang
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.
org.codehaus.plexus.webdav.AbstractDavServerComponent;
org.codehaus.plexus.webdav.DavServerComponent;
org.codehaus.plexus.webdav.DavServerException;
org.codehaus.plexus.webdav.DavServerListener;
org.codehaus.plexus.webdav.DavServerManager;
org.codehaus.plexus.webdav.servlet.DavServerRequest;
org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet;
org.codehaus.plexus.webdav.util.MimeTypes;
org.codehaus.plexus.webdav.util.WebdavMethodUtil;
Used:
archiva-webapp
Plan:
Fork it.could.webdav into new archiva-davserver component.
org.codehaus.plexus.xwork.action.PlexusActionSupport;
Used:
archiva-webapp
Plan:
Switch to SwingMVC
- Joakim
Re: Plan to migrate towards Spring?
Posted by nicolas de loof <ni...@apache.org>.
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 <jo...@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
>
RE: RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)
Posted by "Simmons, Robert" <RS...@icat.com>.
The trend to single sign on is compelling. More and more companies out
there are chosing to use LDAP as the authorization mechanism rather than
just authentication. What would be improtant to me is if I could set
user roles in LDAP and use that information to restrict deployment to
the archiva repository as well as restrict the use of the repository. I
don't have detailed knowledge of the structure of archiva itself so I
couldn't speak to how to accomplish this.
-- Robert
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Tuesday, February 19, 2008 10:23 AM
To: archiva-dev@maven.apache.org
Subject: Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards
Spring?)
On 20/02/2008, at 4:15 AM, Simmons, Robert wrote:
> The benefit to JAAS would be easier integration with companies that
> use LDAP to manage roles within a company.
Actually - this raises a good point - would just having this at the
WebDAV level be sufficient? I realise a lot of people are purely looking
to operate Archiva as a secured proxy and the administration features of
the webapp could be separately secured since there are often less users
needing to be set up for that.
- Brett
>
>
> -- Robert
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Tuesday, February 19, 2008 9:44 AM
> To: archiva-dev@maven.apache.org
> Subject: Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards
> Spring?)
>
>
> On 20/02/2008, at 1:36 AM, Joakim Erdfelt wrote:
>
>> nicolas de loof wrote:
>>> "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.
>>>
>> Redback is an RBAC implementation.
>
> Don't forget that 80% of what Archiva uses Redback for is the web
> application user/role management.
>
>>
>> The Redback <--> Spring integration is likely to take the form of
>> another acegi authorization provider, but it's still a little early
>> yet to speculate on how this will occur.
>>
>> A more general question would be ... do we need RBAC for Archiva?
>> or can we get away with standard JAAS Roles?
>
> An even more general question would be - it works, why change it? :)
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
>
> Confidentiality Note: This message contains information that may be
> confidential and/or privileged. If you are not the intended
> recipient, you should not use, copy, disclose, distribute or take
> any action based on this message. If you have received this message
> in error, please advise the sender immediately by reply email and
> delete this message. Although ICAT Managers, LLC scans e-mail and
> attachments for viruses, it does not guarantee that either are virus-
> free and accepts no liability for any damage sustained as a result
> of viruses. Thank you.
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.
Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)
Posted by Brett Porter <br...@apache.org>.
On 20/02/2008, at 4:15 AM, Simmons, Robert wrote:
> The benefit to JAAS would be easier integration with companies that
> use
> LDAP to manage roles within a company.
Actually - this raises a good point - would just having this at the
WebDAV level be sufficient? I realise a lot of people are purely
looking to operate Archiva as a secured proxy and the administration
features of the webapp could be separately secured since there are
often less users needing to be set up for that.
- Brett
>
>
> -- Robert
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Tuesday, February 19, 2008 9:44 AM
> To: archiva-dev@maven.apache.org
> Subject: Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards
> Spring?)
>
>
> On 20/02/2008, at 1:36 AM, Joakim Erdfelt wrote:
>
>> nicolas de loof wrote:
>>> "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.
>>>
>> Redback is an RBAC implementation.
>
> Don't forget that 80% of what Archiva uses Redback for is the web
> application user/role management.
>
>>
>> The Redback <--> Spring integration is likely to take the form of
>> another acegi authorization provider, but it's still a little early
>> yet to speculate on how this will occur.
>>
>> A more general question would be ... do we need RBAC for Archiva?
>> or can we get away with standard JAAS Roles?
>
> An even more general question would be - it works, why change it? :)
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
>
> Confidentiality Note: This message contains information that may be
> confidential and/or privileged. If you are not the intended
> recipient, you should not use, copy, disclose, distribute or take
> any action based on this message. If you have received this message
> in error, please advise the sender immediately by reply email and
> delete this message. Although ICAT Managers, LLC scans e-mail and
> attachments for viruses, it does not guarantee that either are virus-
> free and accepts no liability for any damage sustained as a result
> of viruses. Thank you.
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
RE: RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)
Posted by "Simmons, Robert" <RS...@icat.com>.
The benefit to JAAS would be easier integration with companies that use
LDAP to manage roles within a company.
-- Robert
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Tuesday, February 19, 2008 9:44 AM
To: archiva-dev@maven.apache.org
Subject: Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards
Spring?)
On 20/02/2008, at 1:36 AM, Joakim Erdfelt wrote:
> nicolas de loof wrote:
>> "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.
>>
> Redback is an RBAC implementation.
Don't forget that 80% of what Archiva uses Redback for is the web
application user/role management.
>
> The Redback <--> Spring integration is likely to take the form of
> another acegi authorization provider, but it's still a little early
> yet to speculate on how this will occur.
>
> A more general question would be ... do we need RBAC for Archiva?
> or can we get away with standard JAAS Roles?
An even more general question would be - it works, why change it? :)
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.
Re: RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)
Posted by Brett Porter <br...@apache.org>.
On 20/02/2008, at 1:36 AM, Joakim Erdfelt wrote:
> nicolas de loof wrote:
>> "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.
>>
> Redback is an RBAC implementation.
Don't forget that 80% of what Archiva uses Redback for is the web
application user/role management.
>
> The Redback <--> Spring integration is likely to take the form of
> another acegi authorization provider, but it's still a little early
> yet to speculate on how this will occur.
>
> A more general question would be ... do we need RBAC for Archiva?
> or can we get away with standard JAAS Roles?
An even more general question would be - it works, why change it? :)
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
nicolas de loof wrote:
> "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.
>
Redback is an RBAC implementation.
RBAC at NIST - http://csrc.nist.gov/groups/SNS/rbac/
RBAC FAQ - http://csrc.nist.gov/groups/SNS/rbac/faq.html
RBAC on Wikipedia - http://en.wikipedia.org/wiki/RBAC
Spring and Acegi do not have an RBAC implementation.
The Redback <--> Spring integration is likely to take the form of
another acegi authorization provider, but it's still a little early yet
to speculate on how this will occur.
A more general question would be ... do we need RBAC for Archiva? or
can we get away with standard JAAS Roles?
- Joakim
Re: Plan to migrate towards Spring?
Posted by nicolas de loof <ni...@apache.org>.
"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 <oc...@apache.org>:
>
> On Feb 19, 2008 11:23 AM, Joakim Erdfelt <jo...@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
>
Re: Plan to migrate towards Spring?
Posted by Maria Odea Ching <oc...@apache.org>.
On Feb 19, 2008 11:23 AM, Joakim Erdfelt <jo...@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
Re: Plan to migrate towards Spring?
Posted by Wendy Smoak <ws...@gmail.com>.
On Feb 18, 2008 8:23 PM, Joakim Erdfelt <jo...@erdfelt.com> wrote:
> 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.
Yeah... but what are they testing for? The Archiva webapp doesn't
need to hold up to thousands of hits a second. :)
Struts 2 does have some known performance issues. On the dev list
there's a renewed effort to figure out how to get away from OGNL (the
prime suspect) and move to a different expression language.
> 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.
It's less about using another Apache project than about what the
volunteer labor force here wants to work with.
Speaking for myself I can't find any motivation to work on the Archiva
webapp that uses an old version of WebWork. I'm not that interested
in Spring MVC. I'm sure it's fine framework, it's just not the
community I want to be involved in. I would welcome the excuse to get
more involved at Struts again while working on a Struts 2.1 app
though.
--
Wendy
Re: Plan to migrate towards Spring?
Posted by Joakim Erdfelt <jo...@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
Re: Plan to migrate towards Spring?
Posted by "Napoleon Esmundo C. Ramirez" <na...@gmail.com>.
On Feb 19, 2008 7:17 AM, Brett Porter <br...@apache.org> wrote:
>
> 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.
+1
>
> >
> > 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).
This sounds workable. In my experience, both IoC can work side-by-side with
alternate configurations. This may be the step to migrating to a bigger
world. ;)
>
>
> > 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.
I agree to using JPA.
>
>
> >
> > Develop redback <-> spring integration and use it.
>
> +1
A tough road, but I agree to this.
>
>
> >
> >
> > 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.
+1
>
>
> >
> >
> > 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
Quartz is good.
>
> >
> > Use commons-io equivalents
>
> +1
>
>
> >
> >
> > org.codehaus.plexus.util.StringUtils;
> >
> > Used:
> > archiva-repository-layer
> > Plan:
> > Switch to commons-lang
>
> +1
I wonder why we don't use most of the commons-* ? :-/
>
>
> >
> >
> > 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?
SpringMVC would impact too much of the current code. I'd still rather go
with webwork.
>
>
> Good proposal, though - when will you be getting started?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: Plan to migrate towards Spring?
Posted by Brett Porter <br...@apache.org>.
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/
Re: Plan to migrate towards Spring?
Posted by Emmanuel Venisse <em...@venisse.net>.
> 2008/2/18, Joakim Erdfelt <jo...@erdfelt.com>:
>>
>> 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)
>
>
>
> +1000 : I was never very confortable with plexus and lack of documentation
> on available components.
>
+1 for Spring and other components
+1 for Struts 2, I don't think think we need a full ajax UI with something
like GWT for now
Emmanuel
Re: Plan to migrate towards Spring?
Posted by Fabrice Bellingard <be...@gmail.com>.
On Feb 19, 2008 8:52 AM, nicolas de loof <ni...@apache.org> wrote:
> 2008/2/18, Joakim Erdfelt <jo...@erdfelt.com>:
>
> +1000 : I was never very confortable with plexus and lack of documentation
> on available components.
Definitely the same. Moving towards Spring will help new comers to get
started faster with developing Archiva.
So here's my +1 for moving toward Spring and any other component/techno that
is easier to use for developing (like the commons-*, quartz, ...) or that
makes Archiva easier to maintain in the long term (JPA, ...).
Concerning the web UI, IMHO, moving to Struts 2 would be a good option and a
wiser decision, as getting rid of Plexus will already require quite some
efforts.
Fabrice
Re: Plan to migrate towards Spring?
Posted by nicolas de loof <ni...@apache.org>.
2008/2/18, Joakim Erdfelt <jo...@erdfelt.com>:
>
> 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)
+1000 : I was never very confortable with plexus and lack of documentation
on available components.
+1 for all moves from plexus-utils to apache commons-x equivalents
org.codehaus.plexus.commandline.DefaultExecutableResolver;
> org.codehaus.plexus.commandline.ExecutableResolver;
>
> Used:
> archiva-webapp-test
> Plan:
> Investigate Need.
> Fork into archiva if truely needed.
commons-exec allready did the investigation, but not ready yet for release
AFAIK.
Plan:
> Migrate expression-evaluator to archiva codebase.
No idea what plexus.evaluator provides, but does this relates to commons-el
or commons-jexl ?
>
Plan:
> Migrate to JDK 1.5 + JPA + Annotations
+1 : JDO is dead. JPA has many stable implementations now. Which one do you
have in mind ?
Plan:
> Fork it.could.webdav into new archiva-davserver component.
If so I'd suggest some enhancements to support storing in SMB "windows
share" filesystem
org.codehaus.plexus.xwork.action.PlexusActionSupport;
>
> Used:
> archiva-webapp
> Plan:
> Switch to SwingMVC
What is the benefict here ? Natural update from existing code is to move to
Struts2. If we have to re-implement the web UI, why not use a higher
abstraction level framework, like apache Wicket ?
Thanks for this exciting proposal. Any chance to see maven-core migration to
Spring also ? ;-)
Nico