James,
There is alternative to the approaches you mentioned:
http://docs.codehaus.org/display/MAVEN/Mercury
This project was started to address, among others, the issues you raise.
What it does in this field - isolate client code from the files -
Resolver operates metadata, not files, Repository talks GAVs, not files,
so you can implement Repository, storing artifacts in, say, a database -
http://docs.codehaus.org/display/MAVEN/Mercury+Repository+Abstraction
The only place where files show up again is a result of readArtifacts()
operation - it guarantees that the resulting Artifact instance points to
a local File, not presuming anything about where and why the File is.
Mercury is not in the trunk yet, but it's aiming to gradually make there
in not too distant a future.
Thanks,
Oleg
James Carpenter wrote:
Introduction:
What mechanism can be used to store artifacts in the repository which are
sensitive to having versions in the filename? This is a concern for certain
artifacts such as .NET assemblies (particularly closed source 3rd party
assemblies) which contain internal meta-data which is aware of the filename
along with a digital signature to ensure the assembly is not tampered with.
------------------------------
Potential Solutions:
I see two general approaches to the problem:
1) Teach the DefaultArtifactResolver to somehow support alternate filename
patterns for certain artifact types within a m2 repo.
2) Create/leverage a post-process hook in the DefaultArtifactResolver which
can used to un-archive the relevant artifact type after resolution. This
approach allows the repository format to remain unchanged, but requires a
good architectural design that supports post-processing without requiring
changes to existing plugins.
--------------------------------
Questions:
1) Does such functionality already exist?
2) Please compare and contrast the architectural advantages/complications
with each approach. Which would be best and why?
3) Is there another solution I have not thought of?
4) What classes/interfaces should I take a look at in order to affect the
necessary change so as to contribute an appropriate patch back to the
project?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
