-----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
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkuuloACgkQOb5RoQhMkRPRqwCfZpRYgxlfR7A0yXSnHst9VvHU
kvsAnjHanXKs4suQsh6yeAyLa8kKMVdg
=l0cN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
