Sounds like good news to me. Can you please define "not too distant a future"? Are you talking days, weeks, months, quarters? I realize you probably don't have an exact answer.
Will Mercury be used to entirely replace the existing DefaultArtifactResolver mechanism? What I'm really trying to ask is whether Mercury will be a bolt on library to maven which will only be used in special cases and which will require adapting plugins to be aware of its existence, or if it will be the standard approach. If I wait a few months will all my problems simply disappear with maven magicially supporting what I need? I assume you are providing concrete implementations of the necessary interfaces to be backwards compatible with existing m2 repositories. Is this a correct assumption? On Fri, Sep 5, 2008 at 10:42 AM, Oleg Gusakov <[EMAIL PROTECTED]>wrote: > 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] > >
