Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <F0F1BEF8-0B64-4DEE-AFA4-9D11D7B5012B@apache.org>
From: Brett Porter <brett@apache.org>
To: archiva-dev@maven.apache.org
In-Reply-To: <14293357.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Help on how Archiva consumers work
Date: Wed, 12 Dec 2007 22:44:35 +1100
References: <14272457.post@talk.nabble.com> <475F980E.3080607@exist.com>
 <14292430.post@talk.nabble.com> <475FB8E5.9020205@exist.com>
 <14293357.post@talk.nabble.com>

http://maven.apache.org/developers/maven-eclipse-codestyle.xml

Thanks!

- Brett

On 12/12/2007, at 10:35 PM, D=E1rio Oliveros wrote:

>
> Thank you for letting me contribute with such a nice project. I =20
> appreciate
> it.
> BTW do you happen to have any code style formatter profile for Eclipse
> Europa ? I noticed Archiva's is a little bit different from Java =20
> Convention
> profile and I could not find it anywhere.
> Thanks.
>
>
> Maria Odea Ching-2 wrote:
>>
>> Okey dokey, thanks a lot Dario!  :-)
>>
>> -Deng
>>
>> D=E1rio Oliveros wrote:
>>> Good to hear from you.
>>>
>>> I had made some code changes before getting your response back and
>>> surprisingly I was on the right track by working on pretty much =20
>>> the same
>>> steps as you've suggested in the first place. The only difference =20=

>>> was
>>> regarding the UnprocessedArtifactPredicate to where I added a new
>>> condition
>>> for checking whether whenProcessed date is before lastModified =20
>>> instead of
>>> using snapshot verification. Besides I changed the else statement of
>>> ArtifactsProcessedConstraint by adding the same verification as =20
>>> shown
>>> previously:
>>> whereClause =3D "whenProcessed =3D=3D null || (whenProcessed !=3D =
null &&
>>> whenProcessed < lastModified)";
>>> In your third step, I went for the date checking instead of =20
>>> checksum.
>>>
>>> Anyway it looks like your second solution is better since it tends =20=

>>> to be
>>> cleaner than the first one.
>>> I will take a look and let you know as soon as I can. Once I fix the
>>> issue,
>>> I will post the patch for your analysis.
>>>
>>> Thank you so much for your support.
>>>
>>>
>>>
>>> Maria Odea Ching-2 wrote:
>>>
>>>> Hi Dario,
>>>>
>>>> I think the solution you've proposed would work.. to implement =20
>>>> it, these
>>>> are probably what you need to change in Archiva:
>>>>
>>>> 1. update the UnprocessedArtifactPredicate
>>>>    - add the constraint to get the SNAPSHOT artifacts as you've
>>>> mentioned (there is a 'snapshot' field in the =20
>>>> ArchivaArtifactModel which
>>>> flags whether the artifact is a snapshot or not, though using =20
>>>> this would
>>>> return all snapshots -- unique & non-unique)
>>>>
>>>> 2. update UnprocessedArtifactPredicate
>>>>    - add check if artifact isProcessed() OR isSnapshot() for the
>>>> condition the artifact needs to satisfy
>>>>
>>>> 3. update ProjectModelToDatabaseConsumer
>>>>    - in the statement if( hasProjectModelInDatabase(...) ) is
>>>> satisfied, the project model/pom file should be verified against =20=

>>>> the
>>>> existing project model (in the db) if there were updates or =20
>>>> changes made
>>>> to it (maybe via the lastModified date or via its checksum). If =20
>>>> there
>>>> are changes, then the existing project model must be removed from =20=

>>>> the db
>>>> and the new project model shall be added.
>>>>
>>>>
>>>> I've also thought of another way to tackle this issue..
>>>>
>>>> You could just update the =20
>>>> DatabaseCleanupRemoveProjectModelConsumer to
>>>> add checking for changes in the project models/pom files of those
>>>> artifacts that have already been processed. If the project model =20=

>>>> has
>>>> been changed, just remove the project model from the db and =20
>>>> update the
>>>> ArchivaArtifactModel's "whenProcessed" field to NULL so that it =20
>>>> would
>>>> qualify in the UnProcessedArtifactPredicate(false) constraint. =20
>>>> The other
>>>> thing that needs to be done is to update the JdoDatabaseUpdater's
>>>> update() method -- just switch the lines updateAllUnprocessed() and
>>>> updateAllProcessed() inside it. updateAllProcessed() should be =20
>>>> executed
>>>> first  before updateAllUnprocessed() in order to capture the =20
>>>> updates
>>>> performed in DatabaseCleanupRemoveProjectModelConsumer.
>>>>
>>>> More thoughts/suggestions anyone? :-)
>>>>
>>>>
>>>> Thanks,
>>>> Deng
>>>>
>>>>
>>>> D=E1rio Oliveros wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I would like to understand why a processed artifact does not have
>>>>> update-db-project consumer in case of a non-unique SNAPSHOT =20
>>>>> project
>>>>> (please
>>>>> refer to http://jira.codehaus.org/browse/MRM-622 for more =20
>>>>> information).
>>>>>
>>>>> The reason for bringing this up is that the database is not being
>>>>> updated
>>>>> accordingly when a non-unique SNAPSHOT project with dependency =20
>>>>> version
>>>>> changes is deployed once again to Archiva repository. Even =20
>>>>> though it
>>>>> contains differences compared to the previous one, it's considered
>>>>> processed
>>>>> already and therefore not updated. It looks like a bug in my =20
>>>>> opinion
>>>>> and
>>>>> I
>>>>> would like to contribute for this fix.
>>>>>
>>>>> Should I change the query constraint for unprocessed artifacts
>>>>> (ArtifactsProcessedConstraint(false)) so it also retrieves the
>>>>> non-unique
>>>>> SNAPSHOT projects or add a new consumer to processed artifacts for
>>>>> database
>>>>> update ?
>>>>>
>>>>> Any tips or pointers would be appreciated.
>>>>>
>>>>> Thanks,
>>>>> D=E1rio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> --=20
> View this message in context: =
http://www.nabble.com/Help-on-how-Archiva-consumers-work-tp14272457p142933=
57.html
> Sent from the archiva-dev mailing list archive at Nabble.com.
>