Btw, just a heads up.. the last day for student's coding is Aug 16, so we
have 12 days to go to wrap up the branch :)

On Thu, Aug 5, 2010 at 9:29 AM, Deng Ching <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected]>
>> > Date: Thu, Jul 8, 2010 at 1:38 PM
>> > Subject: reviewing the staging branch
>> > To: [email protected]
>> >
>> >
>> > 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
>> > [email protected]
>> > http://brettporter.wordpress.com/
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > P.A.Eshan Sudharaka
>> > Dept of Computer Science and Engineering
>> > University of Moratuwa
>> > Sri Lanka
>>
>> --
>> Brett Porter
>> [email protected]
>> http://brettporter.wordpress.com/
>>
>>
>>
>>
>>
>

Reply via email to