[Metafacture] Progress on Metafacture 5.0.0

[Günter Hipler]

Hi Christoph,

thanks for your work and sorry for the really delayed reply.

I'm really happy with the current development. Sebastian and I already 
adapted all our own modules against the stable version 4 and I played 
around with the modules based on version 5 although I haven't had the 
time to test it against our productive workflows. But as far as I have 
seen, shouldn't be a lot of work.

So far I haven't work with Gradle nor with Groovy. So for me it's 
difficult to send a comment - more a general annotation:

I think people not in the core software business would appreciate a more 
fluid DSL possible with Groovy - although nowadays people are always 
talking about scala for such things. So far my knowledge in this area is 
limited, mostly reading things. I guess Groovy might scale down the 
barriers. Sebastian is the guy with more experience in this field.

I have heard people quite often saying that XML seems to be bulky for 
them using it as DSL.

Nevertheless - thanks again for the upcoming version on the horizon.

Günter



On 24.07.2017 19:53, Böhme, Christoph wrote:
> Hi everyone,
>
> this is a short update on the development of Metafacture 5.
>
> Metafacture 4.0.0 introduced the new package structure which is a requirement for the planned split up. I think the new package structure is a big step forward. As  result of it the number of dependencies between packages and between classes has been greatly reduced and there is now a clear direction of dependencies from a large number of independent feature packages to much smaller number of base packages.This will help for long term maintainability of Metafacture. Additionally, the newly introduced framework.helper, metamorph.api and and metamorph.api.helper packages should help to make it more easy to extend Metafacture. However, there still remains a lot to be done in this area.
>
> But let me come to the next release: Earlier today I pushed a large commit which turns the metafacture-core project into a multi-module project that produces individual artifacts for each of the top level packages. So, in the future it is much easier to use Metafacture without introducing unnecessary external dependencies in your projects. Dependencies between Metafacture modules are also much more explicit now. I think this will help us to keep a healthy package structure. While I originally had planned to version each module individually, I dropped this plan as managing individual version numbers within a single project is cumbersome and adds too much complexity to the build and release process. I am considering moving metafacture-framework and metamorph-api into separate repositories, though, to have stable version numbers for the extension APIs at least.
>
> In addition to converting the project structure the today's commit also changes the root package of Metafacture from org.culturegraph.mf to org.metafacture. I think, this will help to make clear that Culturegraph is not just Metafacture. It also makes the package names a bit simplier.
>
> Most things are now in place for the Metafacture 5.0.0 release. There are only a couple of (hopefully) smaller tasks to do:
> 1. Transfer the metafacture-runner project back into the core repository
> 2. Move metafacture-framework and metamorph-api into separate repositories
> 3. Make it unnecessary to release the pom of the root project which is only used as a parent by the child modules of the project.
>
> For the last task I am currently investigating two solutions. The first is to use the flatten-maven-plugin, the second is to switch to Gradle for building Metafacture. The solution with the flatten-maven-plugin works quite well. However, it required a couple of bug fixes in the plugin and another one in Maven itself. At the moment there is no release of the flatten-plugin which contains all these bug fixes. So, I am a bit stuck here. Another problem of the Maven build is that it always runs all tests in all sub-projects which makes the build quite slow.
>
> For these reasons I gave Gradle a try. So far it is much faster and the build script is much more concise (that got me thinking if we could use Groovy as a base for Metamorph, too -- but that is just a vague idea). I also like the fact that there is a clear separation between the build script and the POM that is published to Maven Central. However, while Gradle gives much more freedom it also requires more thinking on how to organise processes such as releasing a project. As there is currently not much process on the Maven-based solution, I am working on completing the Gradle-based setup.
>
> I am hoping to release Metafacture 5.0.0 by the end of the summer at the latest.
>
> Cheers,
> Christoph
>

-- 
Günter Hipler

Universität Basel | Universitätsbibliothek | Projekt swissbib

Schönbeinstrasse 18-20 | 4056 Basel | Schweiz

Tel +41 61 207 31 12 | Fax +41 61 207 31 03

E-Mail guenter.hipler at unibas.ch | http://www.ub.unibas.ch | https://www.swissbib.ch