archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud HERITIER" <aherit...@gmail.com>
Subject Re: [VOTE] Merge Archiva Database Branch to Trunk
Date Fri, 27 Apr 2007 11:34:02 GMT
I vote A. We switch the branch and the trunk.
I'll apply Nicolas' patches on this branch and we'll release a new version.
What it is important is to document it on the web site to inform our users
that the trunk isn't stable and that we released some alpha.

Arnaud

On 27/04/07, nicolas de loof <nicolas.deloof@gmail.com> wrote:
>
> I just checked out the branch and ran mvn install. I got all test failures
> for Archiva Database (on windows 2000)
>
> I then built with "-Dmaven.test.skip=true" and deployed on my local tomcat
> (with old database deleted)
>
> Got some funy ascii-art in logs, but some errors
>
> "org.apache.maven.archiva.database.ArchivaDatabaseException: Error in JDO
> during
> get of Database object id [internal] of type
> org.apache.maven.archiva.model.Arch
> ivaRepositoryModel using no fetch-group"
>
> .. and accessing localhost:8080/archiva :
>
> Caught Exception while registering Interceptor class
> pssEnvironmentCheckInterceptor - [unknown location]
>         org.codehaus.plexus.xwork.PlexusObjectFactory.buildInterceptor(
> PlexusObjectFactory.java:152)
> ...
>
>
> Maybe the database refactoring is required, but IMHO the current
> branch isn't ready for becoming the trunk ...
>
>
>
>
>
>
> 2007/4/27, Emmanuel Venisse <emmanuel@venisse.net>:
> >
> > It's ok now, thanks.
> >
> > The branch seems to be good and well organized.
> > Even if I found some NPE when I used the webapp, I'm +1 to use it as
> > trunk.
> >
> > I don't think you'll can do option B easily, so I vote to option A. You
> > can move the actual trunk to branches/archiva-0.9.x until the new trunk
> is
> > stable.
> >
> > Emmanuel
> >
> > Joakim Erdfelt a écrit :
> > > Please try again.
> > >
> > > All of the unit tests now work on windows.
> > >
> > > - Joakim
> > >
> > > Emmanuel Venisse wrote:
> > >> Option C: Tests don't work on windows so I can't test it.
> > >>
> > >> When they'll be fixed, I'll be for Option B.
> > >>
> > >> Emmanuel
> > >>
> > >> Joakim Erdfelt a écrit :
> > >>> Lots of work has been done in the archiva database branch in the
> past
> > >>> 2 months.
> > >>>
> > >>> It has come time to start the merge back into trunk and get the help
> > >>> of others to finish off the work.
> > >>>
> > >>> I wanted to point people to the branch and let them take a look
> > >>> around, and then vote.
> > >>>
> > >>> As I see it we have 3 options.
> > >>>
> > >>> option A [ ] Make the branch the new trunk.
> > >>> option B [ ] Merge the branch into the existing trunk.
> > >>> option C [ ] -1 Do not merge the branch into trunk.
> > >>>
> > >>> I'll wait the usual 72 hours and tabulate the scores.
> > >>> Scores will be tabulated around 1:00am Sunday UTC.
> > >>>
> > >>> I favor option A personally, but I don't know what that will mean to
> > >>> those people that have trunk currently checked out.
> > >>>
> > >>> The Branch:
> > >>>
> >
> https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor
> > >>>
> > >>>
> > >>> The Good:
> > >>> 1) Completed Integration of JPOX Database into system.
> > >>> 2) Completely overhauled the repository scanning for performance,
> > >>> availability, resilience, and capabilities.
> > >>> 3) Completely overhauled the reporting system for growth and use of
> > >>> the database.
> > >>>
> > >>> The Bad:
> > >>> 1) Admin screens have not yet been converted to the new
> > >>> configuration. (that's a priority for me ATM)
> > >>> 2) Automatic Artifact relocation on proxied requests has not been
> > >>> implemented.
> > >>> 3) Untested.
> > >>>
> > >>> I'm eager to get the other devs involved ASAP.
> > >>>
> > >>> While the vote is going on, I'll be alternating between Redback
> > >>> development and Archiva Admin Screen work.
> > >>>
> > >>> - Joakim Erdfelt
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>

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