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)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <47144334.1040608@erdfelt.com>
References: <20071015111645.1E5921A9832@eris.apache.org>
 <48010347-841C-4B14-AE06-D13F7896714B@apache.org>
 <47142B5D.3020206@exist.com> <47144334.1040608@erdfelt.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <87761038-5CAA-4161-B046-34076E417AD1@apache.org>
Content-Transfer-Encoding: 7bit
From: Brett Porter <brett@apache.org>
Subject: Re: svn commit: r584735 - in /maven/archiva/trunk:
 archiva-base/archiva-consumers/archiva-database-consumers/src/main/java/org/apache/maven/archiva/consumers/database/
 archiva-base/archiva-consumers/archiva-database-consumers/src/test/java/
 archiva-base/ar...
Date: Tue, 16 Oct 2007 14:12:02 +0800
To: archiva-dev@maven.apache.org


On 16/10/2007, at 12:51 PM, Joakim Erdfelt wrote:

> Use the repositoryFactory.getManagedRepository(repoId) to get a  
> ManagedRepositoryContent object.
> Then use the .toFile() .toPath() .toArtifactReference() methods in  
> there.  They should have the same method signature that you are  
> familiar with in the old BidirectionalRepositoryLayout classes.

I guess that's what I was thinking of. Good to know, thanks.

But I have some more comments :)

>> I think the content factory only provides the repository  
>> configuration while the layout factory provides a means of getting  
>> the layout (BidirectionalRepositoryLayout) of the repository where  
>> the artifact is located and converting the path from the given  
>> artifact. I needed the content factory to get the repository url  
>> and the layout factory for the artifact path so I could get the  
>> absolute path to the actual artifact and check if it still exists. :)
>
> BidirectionalRepositoryLayout is going away.

Please do not make this change before 1.0. We entered the beta series  
on the understanding of stabilising the code base - not only  
intending a feature freeze, but a proper code evolution path in my  
mind. Deprecate if you can (and must), though frankly I don't  
understand why this is such a big issue.

> They are broken.
> They do not work.
> They will not be fixed.
> They encourage shortcuts (which is bad).
> Shortcuts encourage bugs (which is also bad).
> Bad code is ... uhm ... bad (which is also also bad).  ;-)

I think you're over-reacting a little, no? :)

BiRL only appeared recently, after 0.9, supposedly to fix all the  
problems with the way it was done before - and now it's the root of  
all evil? :)

> I want to encourage operations against the repository to utilize  
> those objects

I think that's a great idea, so let's think about how we might  
encourage it.

Certainly deleting something is doing it by force, not  
encouragement... so we can rule that out :)

IMO, the only way to encourage the use of particular APIs is:
- by deprecating those that should not be used
- documenting the ones that should, in a centralised place that  
everyone can find.

There have been too many changes too Archiva for anyone to understand  
everything - even though I've looked at every single one, I can't  
keep up with the whole picture. I think we've discussed it before,  
and I believe the best way is for each module to be independently  
usable and documented, and with overviews tying them together so that  
folks know where to find what they need to use.

Agree?

Cheers,
Brett

--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/