Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dan Allen
    @mojavelinux
    if the included page has an image, then the path to the image is incorrect. this will require some thought.
    for now, I just have to use a relative path to the publish location, but that's obviously not ideal.
    (we also need to get warnings up and running for unresolved includes. that will happen in 1.2 likely)
    danyill
    @danyill
    Ah. That's interesting. So far I mainly use includes for page setup (default attributes etc.) and for re-using text.
    So being able to get my page setup "right" across a lot of pages quite quickly helps a great deal :-)
    Dan Allen
    @mojavelinux
    yeah, it's not as common of a case (to have images in the cross-module includes). this client just happens to be doing it that way.
    but that will be the next progression.
    I think it will be very helpful to have a sort of common images module anyway that all modules can use...so even when they are not in includes, that's very useful
    the reality is that the imagesdir concept in Asciidoctor just doesn't scale very far. and we sort of knew that, but now we just need to embrace that fact
    and focus on what the ID of the image is and not so much where it is
    danyill
    @danyill
    agree about item of common images. I can see some advantage of this for using a git subtree for general documentation to separate writing/visual media.
    Dan Allen
    @mojavelinux
    indeed, makes something like git lfs a bit easier to integrate too because then you only need to do it once (or as few times as necessary)
    danyill
    @danyill
    incidentally I think it is a requirement for the "modules" directory, is that right? For "documentation only" repos, would you consider having each module able to be from the base repo?
    For coding I guess that's not the most common use case. For me it's all pure documentation
    Dan Allen
    @mojavelinux
    yes, we're going to have a configuration for the location of modules in antora.yml
    in fact, I have it all scribbled up on my whiteboard. i just haven't had a chance to get it into the issue tracker yet
    danyill
    @danyill
    I'm used to seeing repos with the 'README.adoc' or whatever in the base. And having the "base" for an Antora repo being the ROOT folder is reasonably intuitive but modules/ROOT is not so much IMHO
    cool
    Dan Allen
    @mojavelinux
    and there's really no limitation as to where it can go...so the value could be "." which means the repo root
    danyill
    @danyill
    Cool, that's exactly what I would like :laughing:
    Dan Allen
    @mojavelinux
    :+1: me too...for simple repos, the extra structure is just too elaborate
    what really amazed me in making 1.1 is how compartmentalized everything is
    so for instance, when we changed the location of partials from pages/_partials to partials, that's all done in the content classifier. no other part of the code cared at all
    danyill
    @danyill
    Yes, that's a very tricky thing to achieve when everything about Antora is "convention". Good conventions ain't easy.
    Dan Allen
    @mojavelinux
    and the same for where to look for modules
    it's all in this one place in the code
    so the architecture is really surprising me. the 850 tests also helps ;)
    a simple architecture, but somehow very effective. and plenty of room for the things we still want
    danyill
    @danyill
    How are we going for extensions in Antora? I need to move my git-metadata extension to Antora. But possibly in the long game this might be a useful native Antora thing. I'd like to play with it (my Javascript is non-existent though).
    Dan Allen
    @mojavelinux
    in fact, that's just it. we made plenty of room for ideas to go. and that is going to pay off, i'm sure of it
    danyill
    @danyill
    I'd like to be able to bring git data into pages and also pull git data out through an inline macro (i have a PR in the extensions lab for this).
    Dan Allen
    @mojavelinux
    Asciidoctor extensions work great.
    I use about 5 of them already. and in some ways, even more powerful since they have access to the Antora context objects
    danyill
    @danyill
    Would they work great for something which is used to taking git data? I might have thought that would require a closer integration to Antora because it's a virtual file system in Antora
    My extension for git metadata just takes the file path and finds the repo and then pulls information out. I couldn't do that with Antora I'm guessing
    I'm just after a hint and then I'll have a play
    Dan Allen
    @mojavelinux
    you have access to the git repository info in the Antora context....the repository is closed at that point, but you can reopen it. though we may have to put the clone path to the repo in that data...I hadn't though about that
    we may be missing where Antora cloned the repo...if you had that, you could do everything you wanted
    danyill
    @danyill
    I may have a little play with this at some stage. Are you saying the remote isn't stored? Or the local fs path?
    Dan Allen
    @mojavelinux
    for each file, you have access to file.src.origin which contains the repository URL, the reference, and the start path. then file.src.path gives you the path from the start path.
    you could always clone the repo again yourself. but what is missing, now that I think about it, is where Antora cloned it
    (if it's a local repository, that information is obviously the url)
    danyill
    @danyill
    Where Antora temporarily stored it?
    For processing/
    ?
    Dan Allen
    @mojavelinux
    it uses an auto-generated folder name in the system cache folder (or if the cache folder that you specify in the configuration)
    you could always figure it out of course by using the same logic antora uses to generate the folder name, but that's just not very nice
    we should pass it on
    file.src.origin.cloneDir or something of that sort
    we'll need an issue for that. really no reason not to do it