Dear Mark,
thanks for your request. I'm not sure I understand how your ASDF dependencies do or don't map to MVN entities, though. I also don't understand the maven model very well.
Questions for consideration by the ASDF community:
- As I understand it, my problem doesn't have the problems of redefining ASDF behavior during ASDF's load phase that Faré wishes to eliminate in asdf-3.3. If I were to slog through asdf-3.2.x to implement the planning which I need would such an effort be impacted in any way that you can foresee by what you need to change for asdf-3.3?
If you're going to go deep inside ASDF's planning code, I would strongly recommend starting off the 'plan' branch (due to be committed in ASDF 3.3) rather than off 3.2, as there was significant refactoring and merging would be a huge pain.
Also, if some of your dependencies are from defsystem-depends-on, you *definitely* need to start off the 'plan' branch.
- Does anyone know if there an existing analogy for the ASDF:MVN component in an ASDF extension that I could profitably study? Currently, ABCL-ASDF hackishily neuters the ASDF:COMPONENT association with a pathname, mainly because in the current implementation a given ASDF:MVN component results in one or more jar archives. Does creating additional ASDF:MVN (a subclass of ASDF:COMPONENT) instances in the in-memory ASDF that aren't reflected in an *.asd file raise any problems that anyone is aware of?
The current ASDF model is that every component has only one pathname, though that pathname can be NIL, or can be a directory. If you need multiple files, you can create multiple components indeed.
I don't understand what an MVN component is or does, but I don't see any problem a priori with having multiple of them. Is it supposed to represent (a) a dependency on an external maven package? Or is it supposed to represent (b) a jar that is included as pre-built in the current source? Or (c) the ability to build a jar from source in the current system, that can then be pushed to maven?
In case (a), it probably should be a special subclass of SYSTEM. In case (b) a component with a single file pathname should be fine. In case (c) I would probably also have some subclass of SYSTEM do it, and use one or many secondary systems.
- In the last few months, I think I remember that there has been discussion around the possible use of ASDF to locate and download shared objects for CFFI definitions (or maybe this was within the CFFI community?). The ABCL-ASDF case is a little simpler in that the needed Maven binary objects are identical, unlike the CFFI problem which has per-operating systems and (possibly) per-dynamic linker implementation dependencies. But still, as I remember the outcome of that discussion, the general feeling was that such a mechanism does not belong in ASDF. Does the ASDF cognoscenti think that what I am proposing here for ABCL-ASDF also seem to be "too much"? Note, that ABCL-ASDF will only ever work on ABCL (unless, of course, we get another JVM CL implementation), and as such, is intended to be written as an ASDF extension that should have no impact on other's usage of ASDF. Still, what has been implemented (and what I am proposing), seems to violate Faré's description of ASDF as a build system that should only deal with Common Lisp artifacts.
I don't remember any discussion about downloading CFFI shared objects (though I have vague recollections of discussions about cl-test-grid and/or Quicklisp doing automatic installation of Ubuntu packages or such.)
Thanks for the attention and the solid re-engineering of ASDF,
Thanks for your appreciation.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Anyone who says he can see through women is missing a lot. — Groucho Marx