Alexander,
this is a fantastic initiative and I actually just needed this a few weeks ago so I dug into it.
I'm with you for Java 11.
If at all possible and reasonable I'd love it if we could separate the parsing of AsciiDoc into an internal representation/AST from the transforming/converting into an output format.
So something like "asciidoc-lib" and "asciidoc-output-html", "asciidoc-output-pdf" as separate Java libraries.
If I read the "Scope" section (and some of the mails in this thread) correctly that's exactly what you're planning.
One of my use cases actually involves automatically creating AsciiDoc from within a program.
Realistically, I won't have much time to collaborate/help so I'll take whatever you're doing and I'll be grateful either way.
If you'd like you can add me (OpenCore) to the Interested Parties.
Over at Apache Training <
https://training.apache.org/> we're also building Training material based on AsciiDoc and it'd be useful there as well (admittedly a lack of time has slowed things there as well but...)
@Ben Radey: Pantheon looks very very interesting. I look forward to seeing more from it.
Cheers,
Lars
Hello Anthony,
thanks for pointing me at PDF output. I am also a great fan of
asciidoctor-pdf as it allows my Java builds to create PDF without other
dependencies. I'll add this to the list, although HTML output will
probably be first.
Regarding the JDK 8 vs. 11 vs. 17: This willl be a library project that
wants to support a wide variety of existing applications. Therefore I
want to be conservative about the JDK release. I want people to choose
between AsciidoctorJ and the new library to gather feedback. This
wouldn't work IMHO if it would target only newer releases.
As of today GraalVM only support OpenJDK 11 at maximum, thefore I
wouldn't go futher than 11 as of today.
The new Java features would allow to write more expressive and efficient
code, but I don't see them as enabler of new features the library can
provide. Please correct me if I missed something.
Best regards,
Alexander
On 10.06.2020 19:02, Anthony Vanelverdinghe wrote:
> Hi
>
> This is a great initiative! I have the following suggestions/questions:
> * instead of specifying the runtime environments, specify the targeted
> language release, possibly in a generic fashion, such as "the current
> LTS release"
> * given that this is a greenfield project, and an alternative
> (AsciidoctorJ) exists for people that are stuck with Java SE 8, I
> don't see why this project should restrain itself to Java SE 8
> * it seems that a project like this could benefit from a lot of the
> recent improvements in Java SE (text blocks, switch expressions,
> records, sealed classes, ...), so consider targeting Java SE 17 (the
> next LTS release, due next year, which will have most, if not all, of
> these features standardized). This depends on how fast you're planning
> to release a complete implementation, of course
> * what are the plans w.r.t. conversion to PDF, like done by
> asciidoctor-pdf [1]? If the goal is for this project to replace
> AsciidoctorJ in the Java ecosystem, I believe it's essential to its
> success to provide an implementation in pure Java for PDF conversion
> as well
>
> [1] https://github.com/asciidoctor/asciidoctor-pdf/
>
> Kind regards,
> Anthony
>
--
Alexander Schwartz (alexander.schwartz@xxxxxxx)
https://www.ahus1.de
_______________________________________________
asciidoc-wg mailing list
asciidoc-wg@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/asciidoc-wg
