archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: reviewing the staging branch
Date Thu, 05 Aug 2010 01:29:42 GMT
For MRM-980 branch, the merging and resolving of conflicting versions are
already working. The artifacts merged are also being logged in the audit
logs now.

Aside from the bugs that need to be fixed (see linked issues in MRM-980
jira), what's left to be done are the webapp tests and the documentation.
I think the webapp-tests might be broken on the branch as the layout and
data displayed in the repositories page were broken (MRM-1398). Once these
are fixed and the webapp tests and docs are written, we can already merge
the branch to trunk.

As for a milestone release, I suggest we do one after the merge..

Thanks,
Deng

On Wed, Aug 4, 2010 at 11:55 PM, Brett Porter <brett@apache.org> wrote:

> What's the latest on this? I've had trouble following all the issues, but
> it'd be good to have a summary of where it's at.
>
> Any plans to merge to trunk, release a milestone, etc. in the near future?
>
> - Brett
>
> On 09/07/2010, at 11:14 AM, Eshan Sudharaka wrote:
>
> > ---------- Forwarded message ----------
> > From: Brett Porter <brett@apache.org>
> > Date: Thu, Jul 8, 2010 at 1:38 PM
> > Subject: reviewing the staging branch
> > To: dev@archiva.apache.org
> >
> >
> > Hi Eshan,
> >
> > I've just had a quick review of the staging branch. It looks close to
> > working for the file merge. It would be good to move forward soon because
> > there's many other things to do! :)
> >
> > We've been going around a few alternatives for the API, and I think it
> would
> > be good to clean it up and finalise it.
> >
> > These are the current issues in the code I think need cleaning up:
> > - there's a lot of use of fields - but the classes are only instantiated
> > once by Spring. This means they aren't thread-safe, and overly
> complicated
> > to work with (for example, the setters calling other setters). The
> > operations don't need any state since they are meant to be done in one
> go,
> > so the data can be passed to the merge() method
> > - the test code is running inside src/ instead of target/ - this means
> the
> > source code gets changed (and these changes appear in patches...). Also,
> the
> > test artifacts added to the test repository are a bit confusing - since
> > o.a.archiva:archiva is a POM, there shouldn't be JARs. I suggest creating
> > new artifacts for merging tests and not modifying the existing
> > maven2-repository test.
> > - the SourceArtifacts class is now redundant (calling
> > metadataRepository.getArtifacts(repo) can be used instead)
> > - the old archiva-repository-layer API should not be used (except for the
> > RepositoryMetadataMerge class). Use the methods from maven2-repository
> and
> > metadata-model instead. Never use ArchivaArtifact! :) There's a lot of
> > manually constructing Maven information, even though the APIs are
> available
> > already - eg RepositoryPathTranslator.
> >
> > Here is what I think needs to be done to get the merging API complete
> based
> > on the previous thread:
> >
> > First, create an org.apache.archiva.repository.staging.RepositoryMerger
> > interface, which is the external interface for those wishing to merge
> > repositories (in our case, used from the web application). Probably it
> has
> > these methods:
> >
> > void merge( String sourceRepoId, String targetRepoId );
> > void merge( String sourceRepoId, String targetRepoId,
> > Filter<ArtifactMetadata> filter );
> >
> > The filter could be called with "new IncludesFilter( listOfArtifacts )"
> to
> > merge a given list of artifacts, similar to the current lists passed into
> > the ArtifactsMerger.
> >
> > Second, change ArtifactsMerger to
> > org.apache.archiva.repository.staging.Maven2RepositoryMerger and
> implement
> > the RepositoryMerger interface. Move the code from doMerge into here.
> >
> > Finally, clean up the code following the comments above.
> >
> > After this is done, I think the implementation on the wiki should be made
> > more detailed, breaking it down to the tasks remaining, in order, with
> each
> > able to be completed in roughly a week.
> >
> > Does that sound like a good plan?
> >
> > yes.Thanks.
> >
> > Thanks,
> > Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
> >
> >
> > --
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>

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