[question] Switch from maven to gulp-exist?

[line-o]

Library development in existdb can be a tad more comfortable when using gulp-exist as
packaging an installation can be automated. So in combination with file watchers this is a
powerful combination. That would also allow to run the tests from the command line with
npm test or gulp test.

With that setup we could also setup CI/CD for this project.

Libraries already using the setup described above:

• existsolutions/jwt
• e-editiones/roaster
• line-o/xbow

[joewiz]

I'm agnostic/pragmatic about build machinery, but test integration would be an improvement for us, as we have tests in this repository, but mvn test currently reports:

No tests to run.

@duncdrum mentioned this in #1. I had to run the tests manually in eXide before submitting my PR.

I should note that https://github.com/eXist-db/generator-exist now generates the files needed for GitHub Actions to automatically run tests. (I just used it for the first time on a new project, https://github.com/joewiz/airtable.xq, and GitHub Actions ran on every commit; though I don't have any tests in source control yet, as noted in joewiz/airtable.xq#1.)

[duncdrum]

We could hook up mvn Test in the same way as we did for the documentation app. But that relies on node, which would be an extra dependency over here, as opposed to the documentation app.

[line-o]

So I see one vote by reaction emoji. @adamretter care to elaborate why you are against a setup that is more comfortable to develop with?

[adamretter]

@line-o eXist-db is a Java project. Whilst there is no Java or JavaScript in this project, the mvn approach reuses the existing build tools of eXist-db. Switching this to Gulp/Node, only makes the build tool different, it involves adding more tools like node and gulp into a stack. Node and Gulp are only comfortable (easier) to those that already use them for other projects.

Not all the core-developers are JavaScript developers, but they are all Java developers and familiar with mvn (as that is already used by eXist-db itself).

[line-o]

Thanks for your answer. I do differentiate between exist-db, where I agree it is a java project, and anything built on top of it. A library or application that is purely XQuery does not need to have maven but can freely choose. Especially in situations where switching does offer more features.
I do not see any plus in sticking with maven other than familiarity and that could have and was the slowing factor in migrating from ant.

[line-o]

There is two key-features missing with maven:

• test-integration
• instant update on library content change

[adamretter]

Both can be added without switching the build tool

[line-o]

Sure it can, but is there a working example setup?

[adamretter]

Yes. I think @duncdrum named one on the last CC

[line-o]

This is not a particularly good example since it is not a library, the test-integration is using node and not maven or ant or any java and does not syncing to the database while developing, as far as I can tell.

[joewiz]

With #7 local and CI test integration is added via maven. I don't think we have "instant library update on content change" yet, but if we find a representative maven project that could serve as a model, perhaps we could incorporate that here.

[adamretter]

instant library update on content change

Sorry @joewiz but... what does that mean?

[line-o]

When developing a package or library it is very convenient to immediately be able to see the changes in a running exist-db instance. gulp-exist does offer this feature even for libraries, which otherwise is only possible by re-installing the package.

[adamretter]

@line-o Okay how does Gulp Exist do that? I ask because I could likely do the same process (if it makes sense) from Maven

[line-o]

Watch for filechanges, then rebuild and install.

[adamretter]

Note to self - gulp-exist requires you to have an instance of eXist-db up and running somewhere else which it then communicates with using XML-RPC. This isn't ideal as the user has to (1) setup and prepare a separate version of eXist-db, and then (2) also provide the connection URL and credentials.

With Maven we could instead do one of two things:

1. Produce an existdb-maven-plugin which is similar in principle to jetty-maven-plugin, that allows eXist-db to be started/stopped from Maven with custom execution ids.
2. Use the docker-maven-plugin that starts an eXist-db image in using a custom execution id and mounts a pre-prepared data/expathrepo/semver-${version} folder. There should also be a custom execution id to stop the image.