Mercury feedback

[Brett Porter <br...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I thought I'd spend an evening perusing the Mercury code to get  
familiar with it. Here are some (very terse) comments / questions /  
random thoughts - hope it makes sense. I would appreciate comments /  
responses.

I'm sure this is coming, but the top level stuff I would find helpful  
in understanding the library:
* introductory example usage doc
* more javadoc, particularly outlining the intended public API
* a roadmap of how this gets to 1.0.0, where work is needed. It's also  
unclear how complete some bits are. The roadmap on the wiki seems to  
list things that are already complete in alpha-1

A couple of big things that come out of this:
* IMO, overall metadata approach needs review from the current form  
rather than sticking with the current one, though I know backwards  
compat is needed (per my previous mail to the list about v4.0.0  
models). However the layout seems baked in to the repo API with  
metadata residing at each level - might be a gotcha in future.
* I would still seriously consider the separation of the transport +  
basics (crypto, utils) into a separate release line than the artifact/ 
repo layer. Firstly because the maturity of the code and community  
seems better on the first, but also the commits seem segmented and I  
think it might evolve slower in future, as well as being reused on its  
own.

Some more specific comments on the API/code...

crypto
* default extension is "none", which will come out as ".none", but  
default algo is sha-1, right?
* the naming in crypto basic is a bit confusing - the checksum package  
is really just a hex util?

artifact
* artifact interface seemed a mistake before - todo indicates it might  
be removed, would suggest it should
* similarly thought that dependency specifics (scope, resolved) and  
implementation specifics (snapshot version pattern) would be broken  
out? perhaps the whole artifact class goes away in favour of BMD, etc?
* what's a pom blob - just the raw POM content?
* stream/file duality could lead to confusing state for the default  
artfact object
* artifactmetadata - confusing name IMO, appears to be a resolution  
structure (why, error, resolved, artifactExists, artifactUri), but  
also a data element (release, dependencies) - maybe just rename?
* scope inclusion - too maven-oriented for this part of the library?  
same occurs in default artifact and enum
* quality enum - love this concept, esp. of the range. Should it be  
more closely aligned to versioning? I anticipate similar discussion  
about flexibility (like should RC, etc. be included in the enum) as  
this progresses - what are the thoughts on that?
* attribute query - didn't see this used, what is it for?
* maven version range - should implementation be housed in maven  
itself rather than mercury?
* shouldn't OSGi version be a separate implementation of VersionRange,  
rather than a conditional?
* metadata version comparator and version comparator are identical,  
could have a base class with type <T>

event
* is type enum extensible enough for other events later?

external
* isn't this really an implementable api? could be incorporated into  
artifact?

logging
* console logger looks incomplete

plexus
* this looks a bit odd... can't individual classes be annotated to be  
plexus components while remaining usable without it?
* the DefaultPlexusMercury seems like a generally useful group of  
factory methods

repo
* tying up of format and local vs remote is questionable I think, what  
if I wanted to use this as the repository API inside Archiva that  
handles "remote" repos on disk? Only seems to talk via a reader that  
requires a local repository, so I need a virtual repository to read a  
single local disk repo in "remote" format. Am I missing something?

transport
* file writer doesn't have code in it yet... remove from release?
* is there any key management for PGP in mercury (I may have asked  
this already), or is it primarily the stream verifiers?

sat
* I haven't fully gone through this module yet, as a lot of the  
interesting bits are here. How complete is it considered now?
* it seems to also have the "legacy" mode resolution in here... is  
that something that should be separated so that it can eventually be  
optional?
* is "java" dependency model constant really java, or maven?

And of course, the nitpicking :)
* the code format / style is pretty inconsistent... a reformat and  
some checkstyle love would make it easier to read :)
* there's some experimental stuff still in here that should be cleaned  
out, not all are marked "todo"
* seems to still suffer from the duplication problems of previous  
artifact mechanism, particularly in the artifact module - I would  
think the code can be drastically reduced in some areas
* some of the modules seem to be on a separate release cycle (the  
comparison plugins particularly - could just go to the main sandbox?)

Hope this is helpful!

Cheers,
Brett

- --
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkkuuloACgkQOb5RoQhMkRPRqwCfZpRYgxlfR7A0yXSnHst9VvHU
kvsAnjHanXKs4suQsh6yeAyLa8kKMVdg
=l0cN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org