@vogella : Maybe you could help here?

Absolutely.

Here some pre-requisites :

• https://github.com/de-jcup/eclipse-asciidoctor-editor/blob/master/asciidoctor-editor-gradle-dep/build.gradle
  does refer ASP server. Currently ASP server jars are not available, because formerly hosted at bintray....
  see Host library at another location (bintray no longer available) asp#30

Some additional information:

• https://github.com/de-jcup/eclipse-asciidoctor-editor/blob/master/asciidoctor-editor-gradle-dep/build.gradle
  contains task installLibraries which copies the java libraries fetched by gradle to plugin lib folders
  (which are not inside git). This process should be not necessary with tycho. See also
  https://github.com/de-jcup/eclipse-asciidoctor-editor/blob/master/asciidoctor-editor-gradle-dep/README.md
• I think the asciidoctor-editor-gradle-dep could be removed when switching to tycho

Something I would appreciate:

• Should still work with Java 8, so even very old eclipse versions could use the plugin
• Maven standard parts + tycho only
• Keep existing folder structure if possible (multi project build)

The plan is to replace the Gradle build with Maven or do you plan to keep both?

Please see #372 for the initial setup. For the necessary libraries, I would not know where to search them. If they are available via Maven central you can add them to the target platform via M2e integration, see here https://www.vogella.com/tutorials/EclipseJarToPlugin/article.html

I hope this help, I don't think I would be very efficient trying to add the libs. Can you handle that?

@vogella : Thank you very much. I will check the PR and tryout to add the libs etc. If I have still questions I will ask you then.

Sure and thanks. Adding more plug-ins is just a question of adding path to the pom.xml. It is a bit more complex for test plug-ins. Once the libs are there, I can do this. Maybe we can do this in your repo directly in a branch? Could you give me write access?

The plan is to replace the Gradle build with Maven or do you plan to keep both?

• I think there should be only one build system.
• When all gradle tasks are replaced by maven pendants (and more...) and github actions are updated as well, we should remove the gradle parts completely.

Sure and thanks. Adding more plug-ins is just a question of adding path to the pom.xml. It is a bit more complex for test plug-ins. Once the libs are there, I can do this. Maybe we can do this in your repo directly in a branch? Could you give me write access?

I just invited you.

Just as an information: My eclipse commons library is currently directly added into GIT. With #373 this will become a maven dependency as well. The library is just one central library to "not reinvent the wheel" and is used in most of my eclipse plugins.

#372 is the first step but PR will not close this issue, so removed the former link.

Any news with asp-server-asciidoctorj-launcher-dist.jar? It is required by de.jcup.asciidoctoreditor and IIRC you were planning to add it to Maven? Alternative you could also add the JAR to the the lib folder so that we can continue with the update of the build and remove it later once you moved it to Maven central.

Any news with asp-server-asciidoctorj-launcher-dist.jar? It is required by de.jcup.asciidoctoreditor and IIRC you were planning to add it to Maven? Alternative you could also add the JAR to the the lib folder so that we can continue with the update of the build and remove it later once you moved it to Maven central.

Hello @vogella , sorry for the late response, was very busy. I just created de-jcup/asp#39 to address the problem.

I'm a bit confused. What do we want to do as a next step?

@de-jcup any updates from your side?

Update:

• eclipse commons now available at maven-central (https://mvnrepository.com/artifact/de.jcup.eclipse.commons/eclipse-commons)
• asp parts are available at ( https://mvnrepository.com/artifact/de.jcup.asp)

I have added the dependencies as PDT dependencies in last commits,, but there are still some problems.
For example: https://mvnrepository.com/artifact/de.jcup.asp/asp-server-asciidoctorj/1.3.1 contains the ASP server and has a runtime dependencies (e.g. asciidoctorj, asciidoctorj-pdf, ... more). The problem here is, that PDT maven dependencies does only show up/ handle compile dependencies.

@de-jcup anything left here?

There are still some steps to do:

• We must reintegrate the library plugin to the maven build

  Reason:

  • the library plugin was designed to have all ASP/AsciidoctorJ dependencies inside
  • at runtime for ASP the library ASP jar was used to start the ASP.
  • also we wanted to have new features/bugfixes editor releases updated without downloading same dependencies again, even when we have changed just one line inside editor plugin. So hotfix releases do only need some hundred Kilobytes instead also downloading ASP/AsciidocotorJ parts which are many MB.

• Currently at runtime the ASP lauch mechanism will not work

• ASPSupport.java

 File aspFolder = PluginContentInstaller.INSTANCE.getLibsFolder();
 File aspServer = new File(aspFolder, "asp-server-asciidoctorj-dist.jar");
  ...
 aspServerAdapter.setPathToServerJar(aspServer.getAbsolutePath());

We need the complete dist jar to launch. Also the maven central version number is currently not supported here.

We must reintegrate the library plugin to the maven build

As we source from Maven only changed parts will be included in the new build and downloaded.

Currently at runtime the ASP lauch mechanism will not work

If the server is part of the classpath of the plugin you can start it directly from the plug-in

I want to separate the download not for development, but for the users (update time)

For example:
I released V2.5.0 of the editor plugin (old style with gradle) some days ago with library plugin 2.4.0 dependency which contains ASP 1.4.1

Some hours ago I fixed a serious bug and released V2.5.1 which uses again library plugin 2.4.0

Because the only changes were done inside the editor plugin the users only needed to download ~ 1 MB for the editor plugin and not ~ 50 MB with the complete ASP server.

So this means

• we can deploy faster
• updates by users are faster
• we produce less network traffic at all
  (I know at these days 50 MB should not really matter, but if somebody has a weak internet connection it could matter
  and it is easy to optimize here, so ...)

Still don't understand. If the Maven dependencies are not updated they will also not be updated hence you will not see big updatesd if you only update the core plug-in

Remark: The former two commits did also merge the current master (containing changes for 3.0.0) into this branch.

Consumption of Maven libraries via the Tycho build is now also common practice for the platform build and all of my clients. As soon as the libraries are available via Maven central building this plug-in via Maven Tycho is trivial.

@vogella : I am still running out of time and I did invest much time to get it working in any way (and failed). Currently I cannot work on it.

No worries we all have time restrictions. If all lib requirements would be at Maven central or a P2 update site setting up a Tycho build would be trivial and I could provide it.

Maybe providing a P2 repo for the dependencies would be possible in the future.