archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: WIP/POC archiva-jarinfo
Date Wed, 19 Mar 2008 12:01:19 GMT
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)


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

View raw message