<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div>This is very interesting. It did seem like more lookups started happening when I switched to the -SNAPSHOT convention.<div><br></div><div>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.</div><div><br></div><div>In the meantime, how about something like this:</div><div><br></div><div><div>diff --git i/contrib/abcl-asdf/abcl-asdf.lisp w/contrib/abcl-asdf/abcl-asdf.lisp</div><div>index aace30e..da430bd 100644</div><div>--- i/contrib/abcl-asdf/abcl-asdf.lisp</div><div>+++ w/contrib/abcl-asdf/abcl-asdf.lisp</div><div>@@ -15,6 +15,7 @@ (defclass mvn (iri)</div><div> ((group-id :initarg :group-id :initform nil)</div><div> (artifact-id :initarg :artifact-id :initform nil)</div><div> (repository :initform "<a href="http://repo1.maven.org/maven2/">http://repo1.maven.org/maven2/</a>") ;;; XXX unimplmented</div><div>+ (resolved-path :initform nil :accessor resolved-path)</div><div> (classname :initarg :classname :initform nil)</div><div> (alternate-uri :initarg :alternate-uri :initform nil)</div><div> ;; inherited from ASDF:COMPONENT ??? what are the CL semantics on overriding -- ME 2012-04-01</div><div>@@ -27,12 +28,13 @@ (defmethod find-component ((component iri) path)</div><div> </div><div> ;;; We intercept compilation to ensure that load-op will succeed</div><div> (defmethod perform ((op compile-op) (c mvn))</div><div>- (abcl-asdf:resolve </div><div>- (ensure-parsed-mvn c)))</div><div>+ (unless (resolved-path c)</div><div>+ (setf (resolved-path c)</div><div>+ (abcl-asdf:resolve </div><div>+ (ensure-parsed-mvn c)))))</div><div> </div><div> (defmethod perform ((operation load-op) (c mvn))</div><div>- (let ((resolved-path </div><div>- (abcl-asdf:resolve (ensure-parsed-mvn c))))</div><div>+ (let ((resolved-path (resolved-path c)))</div><div> (when (stringp resolved-path)</div><div> (java:add-to-classpath (abcl-asdf:as-classpath resolved-path)))))</div><div> </div><div>This has us only resolving the the maven artifact once.</div></div><div><br></div><div>thanks,</div><div><br></div><div>Cyrus</div><div><br></div><div><div><div>On Feb 23, 2014, at 2:14 PM, Arnaud Bailly <<a href="mailto:arnaud.oqube@gmail.com">arnaud.oqube@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi,<div>I know much more about maven than asdf and actually maven knows much more about the version than what you say. </div><div> - 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</div>
<div> - if the version number follows maven conventions (X.Y.Z numbers) then actually you can define version ranges in dependencies (<a href="http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html">http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html</a>),</div>
<div> - 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.</div><div><br></div><div>My 2 cts</div><div><br></div><div>Regards,</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><div>--<br></div>Arnaud Bailly<br></div>FoldLabs Associate: <a href="http://foldlabs.com/" target="_blank">http://foldlabs.com</a><br></div>
</div>
<br><br><div class="gmail_quote">On Sun, Feb 23, 2014 at 5:02 PM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/23/14, 1:27, Cyrus Harmon wrote:<br>
><br>
> Whoops. I attached the wrong patch.<br>
><br>
> Correct one (hopefully) attached:<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Feb 22, 2014, at 5:21 PM, Cyrus Harmon <<a href="mailto:ch-lisp@bobobeach.com">ch-lisp@bobobeach.com</a>> wrote:<br>
><br>
>><br>
>> The attached patch adds support for maven snapshot versions with the following defsystem component syntax:<br>
>><br>
>> (:mvn "org.openscience.cdk/cdk-bundle" :version "1.5.6" :snapshot t)<br>
>><br>
>> I’m open to other suggestions to solving this, but this works for my immediate needs.<br>
<br>
No, that isn't a sufficiently generalized solution for my tastes, but<br>
congratulations on hacking it to work for you!<br>
<br>
As far as I understand Maven, the "-SNAPSHOT" is merely a suffix to the<br>
version coordinate and is merely a convention, not supported by the<br>
underlying Maven infrastructure as the version in Maven is merely an<br>
opaque string without any meaningful ordering operations between<br>
different versions (i.e. there is no sure way to tell that one version<br>
in Maven is greater or lesser than another). So, making an keyword<br>
argument for "-SNAPSHOT" but not "-rc-1" and whatever else gets stuffed<br>
in here is the wrong way forward, especially as we can see that your<br>
diff is mostly about "carrying the extra arg" through the various method<br>
calls which would have to be duplicated for every additional suffix that<br>
one encounters.<br>
<br>
ASDF tries to be much stricter about its version component, which<br>
probably means that trying to use the ASDF VERSION component to<br>
represent both Maven's and ASDF's notion of a version is probably a<br>
losing battle. Currently, the ASDF on abcl-1.3.0-dev signals a<br>
non-intelligible error about ASDF/SYSTEM:BUILTIN-SYSTEM-P when ASDF<br>
encounters a VERSION that is not strictly three integers separated by<br>
two periods.<br>
<br>
Fortunately, the current version of ASDF and ABCL-ASDF accepts the<br>
following form:<br>
<br>
(:mvn "org.openscience.cdk/cdk-bundle/1.5.6-SNAPSHOT")<br>
<br>
which should do what you want without patching the API. This is where<br>
the ENSURE-PARSED-MVN function that you recently patched comes in,<br>
"fixing up" the MVN component to contain the right values. This works,<br>
since in spite of requiring that ASDF versions can be meaningfully<br>
compared, ASDF itself does not use this requirement for anything other<br>
than possibly upgrading its own components.<br>
<br>
I couldn't find your artifact on the standard Maven repo, but tested it<br>
with the following artifact:<br>
<br>
(:mvn "org.mod4j.com.google.inject/guice/1.0-XTEXT-PATCHED")<br>
<br>
Could you test that this will work for your case?<br>
<br>
Longer term, the way forward is to clearly not use the ASDF VERSION<br>
field to store the MVN version at all.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
"A screaming comes across the sky. It has happened before, but there<br>
is nothing to compare to it now."<br>
<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div></body></html>