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 - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
