Within the current 2.0.x releases, Maven provides extensions for downloading just about any type of artifact, with or without versions in the filenames. There are, of course, some problems. First the plugins make assumptions about formats (like versions in the filename). With the exception of snapshots, core runs just fine but you end up having to rewrite a bunch of plugins. Second, artifact resolvers don't play nicely if you muck with filenames that affect snapshots. This is a big area where core does not run fine. With NMaven 0.14, I needed to write layers of code on top of Maven just for snapshot support.
With NMaven 0.14, we have the following areas: 1) the local Maven repository, which is just used for downloading and resolving, 2) private assembly cache, which mirrors in format the global assembly cache (GAC); 3) private assembly bin, which contains executables and their dependent assemblies. (1) is used for all the Maven resolving and deploying of artifacts, it follows standards. (2) is used for compiling against; filenames do not contain versions; (3) is used for running of executables that are downloaded from the Maven repo. Having 3 different areas means that NMaven needs to copy and rename artifacts mutliple times after a resolve. This is where something like the filter that James mentions would be useful. Personally, I'd like to be able to register listener events within Mercury, if there is say an dotnet:exe type resolved, I'd like it to invoke a listener (actually a transaction with a list of listeners, that could provide rollback hooks) that would make the copies to various places. Shane On Fri, Sep 5, 2008 at 1:46 PM, James Carpenter <[EMAIL PROTECTED]> wrote: > Overview of Slight Mercury Enhancement which Solves the Problem: > > If a pre-process filter is supported by the RepositoryWriter and a > post-process filter is supported by the RepositoryReader (equates to the > 2nd > solution in the original post) no custom repository manager would be > needed. If I understand the Mercury architecture correctly, this can > probably be added to Mercury with very little effort. > > ----------------------------------------- > Conceptual Example: > > The post/pre process filters should probably be registered by the type and > classifier attributes of the ArtifactBasicMetadata. More generally one > would probably want to support registration by any combination of the > ArtifactBasicMetadata attributes with wildcard support. > > A conceptual example might clarify things a bit: > > Within a pom: > > .... > <build> > <mercuryConfig> > <repoWriterFilters> > <filterChain typePattern="dll|pdb" > classifierPattern="*"> > <filter > class="org.apache.nmaven.RepoWriterFilter"/> > </filterChain> > </repoReaderFilters/> > <filterChain typePattern="dll|pdb" > classifierPattern="*"> > <filter > class="org.apache.nmaven.RepoReaderFilter"/> > </filterChain> > </repoReaderFilters/> > </mercuryConfig> > </build> > > Assuming the right filters are somehow registered we might install a dll, > pdb and sources into the repo as follows: > > prompt> mvn install:install-file -Dfile=baz.dll -DgroupId="com.zoo" > -DartifactId="foo" version="1.3" -Dpackaging="dll" > > prompt> mvn install:install-file -Dfile=baz.pdb -DgroupId="com.zoo" > -DartifactId="foo" version="1.3" -Dpackaging="pdb" > > prompt> mvn install:install-file -Dfile=baz-sources.zip -DgroupId="com.zoo" > -DartifactId="foo" version="1.3" -Dpackaging="zip" -Dclassifier="sources" > > Browsing the repo we would see: > /maven2/com/zoo/foo/1.3/foo-1.3.pom > /maven2/com/zoo/foo/1.3/foo-1.3.pom.sha1 > /maven2/com/zoo/foo/1.3/foo-1.3.dllzip > /maven2/com/zoo/foo/1.3/foo-1.3.dllzip.sha1 > /maven2/com/zoo/foo/1.3/foo-1.3.pdbzip > /maven2/com/zoo/foo/1.3/foo-1.3-pdbzip.sha1 > /maven2/com/zoo/foo/1.3/foo-1.3-sources.zip > /maven2/com/zoo/foo/1.3/foo-1.3-sources.zipsha1 > > > Assume the following dependency which uses the dll: > <dependency> > <groupId>com.zoo</groupId> > <artifactId>foo</artifactId> > <version>1.3</version> > <type>dll</type> > </dependency> > > If this dependency was resoved using the > RepositoryReader#readArtifact(ArtifactBasicMetadata) method the returned > object would contain the binary contents (ByteStream, byte[], etc.) as well > as an indication of the filename as baz.dll. Assuming readArtifact takes a > directory into which to write the result the directory would simply contain > baz.dll. > > A slight kink here is the local repository should probably store the > artifact in archived format. So resolving a remote artifact would result > in > the local repo having the archived format and the workarea (target dir, > etc.) having the unarchived form: baz.dll. > > ----------------------------------------- > Summary: > > Some type of filtering support as described here would probably solve > NMaven's problem in a transparent manner. This would also be transparent > to > any usage of the mercury ant tasks. The only downside being any dll or pdb > artifacts downloaded directly in a browser pointed at the stardard > repository will need to be unarchived (unzip) in order to use them outside > the context of maven. > > In the example above I configured the filters in the POM. It may be more > appropriate to register them somewhere else. For example it might be > better > to let plugin's register filters in their plexus configuration files. (I > must confess I have never taken the time to truely understand how > maven/plexus processes the plexus config files associated with a plugin.) > > ---------------------------------- > Thanks: > > I'm looking foward to your response. Its quite exciting to know the > solution may be only a few weeks away. Thanks for all your efforts. > > Sincerely, > James Carpenter > email: [EMAIL PROTECTED] > > On Fri, Sep 5, 2008 at 12:06 PM, Oleg Gusakov > <[EMAIL PROTECTED]>wrote: > > > > > > > James Carpenter wrote: > > > >> 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. > >> > >> > > James, I am working hard to make it weeks, not months. Currently, there > are > > two pieces still WIP: repository metadata (how often to scan for newer > > versions, where to store that data) and real world testing. I am pretty > sure > > the last one will reveal tons of things to fix, which is fun! > > > >> Will Mercury be used to entirely replace the existing > >> DefaultArtifactResolver mechanism? > >> > > I hope to be able to do that > > > >> 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. > >> > > Standard, to be discussed and approved the community of cause > > > >> If I wait a few months > >> will all my problems simply disappear with maven magicially supporting > >> what > >> I need? > >> > >> > > That's the whole reason to do Mercury in the first place. But - if I > > understood your question correctly - you problem will become solvable > > withing standard maven, not solved. To get solved - it will require > another > > repository implementation, which I will happily help you to do, but > cannot > > do on my own as I don't know the details. > > > >> I assume you are providing concrete implementations of the necessary > >> interfaces to be backwards compatible with existing m2 repositories. Is > >> this a correct assumption? > >> > >> > > I implemented local and remote M2 repositories for the start and will > also > > try to make Mercury available as ant tasks - > > http://docs.codehaus.org/display/MAVEN/Mercury+1.0.0+roadmap - this I > will > > keep updating > > > > Have a nice one, > > Oleg > > > > > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
