Hi Brett,
which descriptor do you talk about?
- the archetype-metadata.xml located in the archetype jars
- the archetype-catalog.xml located at repositories root
In the later case maybe the archetype:crawl goal (or the
RepositoryCrawler component in archetype-common) could help you
Regards,
Raphaël
2008/3/19, Brett Porter <[EMAIL PROTECTED]>:
> I've only taken a quick look. I do like the idea of gathering more
> information so this is a good avenue to pursue.
>
> I have some really fundamental questions first though, so help me out:
> - how would this replace scanning if it only deals with JARs?
> - what are the assumptions that have been proven to be misguided that
> you refer to?
> - I haven't looked at the code, but my initial reaction was that it
> either overlaps or copies a lot from current archiva classes or maven-
> shared-jar - is that correct or am I missing something?
>
> When I think about collecting more information about artifacts, I
> really think about decorators that can be added (so you can add your
> own). Wouldn't this be best done as a small set of those? (which could
> be integrated into trunk now - in fact it was something I wanted to
> look at tomorrow to add the new archetype descriptor indexing now that
> its released)
>
> Thanks,
> Brett
>
>
> On 11/03/2008, at 3:25 PM, Joakim Erdfelt wrote:
>
> > I've been working on and off on a few different archiva related
> > tools / tasks / libs.
> >
> > Brett and Wendy convinced me to upload what I got and outline what
> > I've got in mind to let the creative juices flow. (besides, I'm
> > running out of time to commit to archiva, so this work will be slow
> > to progress if i do it alone).
> >
> > Concept: archiva-jarinfo.
> >
> > A library for jar indexing / searching / identification for local
> > repositories, arbitrary directories of jars, and even remote
> > repositories.
> >
> > For use by ...
> >
> > * Archiva itself as a possible replacement for repository scanning,
> > indexing, and searching.
> > (Searching on checksums, filenames, classnames, imports,
> > identification fields, and even public / exposed methods)
> > * Archiva RepoMan WebStart Tool - a tool I've been wanting to help
> > identify and upload content to an Archiva repository.
> > * Archiva Maven Plugin - imagine typing $ mvn archiva:search -
> > Dquery=Logger and getting hits on
> > log4j, slf4j, commons-logging, plexus-logging, etc... found from
> > results from local repository and remote repository.
> > * Q4E integration - adding some ability to q4e to search local
> > repository and remote repositories for dependencies.
> >
> > Some details.
> >
> > (Some of this exists and works, Some of it does not, remember this
> > is a Work in Progress)
> >
> > The existing repository scanning / indexing in Archiva server makes
> > some assumptions that have proven to be misguided (such as only
> > searching for new content based on timestamp). The new approach
> > that archiva-jarinfo takes is to mitigate the time consuming part of
> > the scan that the new content timestamp check attempts to avoid, the
> > processing of the jar file.
> > This is done by checking for a new xml file with the contents of the
> > jar file (called ${artifact}-${version}.jarinfo), if the file
> > exists, it's up to date, if it doesn't exist, the jar details are
> > collected and the jarinfo file is created.
> > I've seen this useful if you sync or copy repository directories
> > too. as the jarinfo files come along for the ride and reduce the
> > requirements for archiva to determine the jar details yet again.
> > The scan creates a Jar Info Bundle (*.jib file) that is just a jar
> > file with all of the *.jarinfo xml files in it, for consumption by
> > remote JarInfo clients to use for indexing purposes.
> >
> > The JarInfo client uses the JarInfo lib to create an index for
> > checksums, jar content filenames, and public/exposed bytecode
> > information.
> >
> > The JarInfo client can search local repos, remote repos, and even
> > arbitrary directories of jar files.
> >
> > The JarInfo client can take an anonymous Jar file and perform a
> > series of identification checks in an attempt to identify the Jar
> > file based on jar file contents, and even similarity to jar files
> > found in the JarInfo indexes.
> >
> > That's all the info I can squeeze out tonite, hopefully someone else
> > will find this useful.
> >
> > Thanks,
> > - Joakim
>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
