Hi,I know much more about maven than asdf and actually maven knows much more about the version than what you say.- SNAPSHOT is not an arbitrary keyword (eg. a classifier in maven parlance) but something that is baked in the artefact resolution and repository definition of maven. Snapshot versions can be updated and new versions looked for in a remote repository whereas "release" versions are never updated- if the version number follows maven conventions (X.Y.Z numbers) then actually you can define version ranges in dependencies (http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html),- moreover, there is a notion of ordering which is maintained in a repository metadata so that one can request the LATEST version of some artefact.My 2 ctsRegards,On Sun, Feb 23, 2014 at 5:02 PM, Mark Evenson <evenson@panix.com> wrote:On 2/23/14, 1:27, Cyrus Harmon wrote:
>
> Whoops. I attached the wrong patch.
>
> Correct one (hopefully) attached:
>
>
>
>
>
>
> On Feb 22, 2014, at 5:21 PM, Cyrus Harmon <ch-lisp@bobobeach.com> wrote:
>
>>
>> The attached patch adds support for maven snapshot versions with the following defsystem component syntax:
>>
>> (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6" :snapshot t)
>>
>> I’m open to other suggestions to solving this, but this works for my immediate needs.
No, that isn't a sufficiently generalized solution for my tastes, but
congratulations on hacking it to work for you!
As far as I understand Maven, the "-SNAPSHOT" is merely a suffix to the
version coordinate and is merely a convention, not supported by the
underlying Maven infrastructure as the version in Maven is merely an
opaque string without any meaningful ordering operations between
different versions (i.e. there is no sure way to tell that one version
in Maven is greater or lesser than another). So, making an keyword
argument for "-SNAPSHOT" but not "-rc-1" and whatever else gets stuffed
in here is the wrong way forward, especially as we can see that your
diff is mostly about "carrying the extra arg" through the various method
calls which would have to be duplicated for every additional suffix that
one encounters.
ASDF tries to be much stricter about its version component, which
probably means that trying to use the ASDF VERSION component to
represent both Maven's and ASDF's notion of a version is probably a
losing battle. Currently, the ASDF on abcl-1.3.0-dev signals a
non-intelligible error about ASDF/SYSTEM:BUILTIN-SYSTEM-P when ASDF
encounters a VERSION that is not strictly three integers separated by
two periods.
Fortunately, the current version of ASDF and ABCL-ASDF accepts the
following form:
(:mvn "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT")
which should do what you want without patching the API. This is where
the ENSURE-PARSED-MVN function that you recently patched comes in,
"fixing up" the MVN component to contain the right values. This works,
since in spite of requiring that ASDF versions can be meaningfully
compared, ASDF itself does not use this requirement for anything other
than possibly upgrading its own components.
I couldn't find your artifact on the standard Maven repo, but tested it
with the following artifact:
(:mvn "org.mod4j.com.google.inject/guice/1.0-XTEXT-PATCHED")
Could you test that this will work for your case?
Longer term, the way forward is to clearly not use the ASDF VERSION
field to store the MVN version at all.
--
"A screaming comes across the sky. It has happened before, but there
is nothing to compare to it now."