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.

On 2/23/14, 22:14, Arnaud Bailly wrote:

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-proje... ),

• 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.

Thanks for providing an inkling that my statements about Maven versioning were not correct.

A summary of my "research" with a little bit of DuckDuckGo'in:

The "version rules" seem to be best documented [within the version plugin][1] which allows the ranges you mention. Apparently there are multiple schemes for comparing versions, and there is even a configurable mechanism for rules. One caveat here is that ABCL currently is only using the Aether infrastructure, and not Maven itself so not everything applicable to Maven applies to ABCL's use of Aether. For example, we don't parse the Maven 'settings.xml' file.

The string following the "-" is known as a qualifier: a classifier is something appended to an artifact name to allow for different types to satisfy different conditions.

The "SNAPSHOT" qualifier is [indeed treated differently from others][2], and cannot be listed in the POM graph originating from http://repo1.maven.org/maven2.

[1]: http://mojo.codehaus.org/versions-maven-plugin/version-rules.html

[2]: http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-s...

On 2/24/14, 7:34, Cyrus Harmon wrote:

[…]

While we’re on the subject, I don’t like the idea of constantly reloading artifacts from maven, especially when, AFAIUI, ABCL doesn’t currently support reloading classes from jars. I guess the question is should we resolve the maven artifact at compile time or load time? Probably not both. Well, it probably should be some custom ASDF component-type that has a resolve-op, but that’s an exercise for another day.

In the meantime, how about something like this:

[…]

This has us only resolving the the maven artifact once.

I'm not entirely conversant on which component-type is invoked at which phase, but I [have applied a version of your patch][r14631] which does resolution during the ASDF COMPILE-OP phase, and actually adds this value to the JVM classpath during the LOAD-OP phase which removes the "double lookup" of Maven artifacts.

[r14631]: http://abcl.org/trac/changeset/14631

Oh, I see! Thanks for showing me the correct :mvn invocation for, e.g., -SNAPSHOT. Works great!

On Feb 23, 2014, at 9:02 AM, 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."