investigate switching the build to gradle

[tcurdt]

TSSIA

[gesellix]

Is this meant in a sense like "replace the current Maven (pom.xml) with a Gradle (build.gradle) build"? If yes, I'm happy to investigate whether there are any complex/difficult build steps in the current pom.xml - see https://github.com/gesellix/jdeb/tree/gradle-build for progress.

This should be independent of providing a jdeb Gradle plugin.

[tcurdt]

@gesellix indeed - that was the idea. I haven't used gradle yet - but I was again just super annoyed with maven (#226) and gradle looks very promising.

[ebourg]

I'm not sure building a Maven plugin with Gradle is a good idea. I would personally prefer sticking to Maven.

[gesellix]

If you check out https://github.com/gesellix/jdeb/tree/gradle-build and run ./gradlew build you'll see that the unit tests are working - I only had to quick fix some paths. Well, if it had been a bigger problem, I would've been surprised ;-)

During the next days I can have a look at the integration tests. The first step is to include them in the build and then fix them. I expect that we then get to know if @ebourg is right about possible risks when building a Maven plugin with Gradle. I'd also argue that it feels a bit strange and that's why I would also think about maintaining both build tools for a while. The project is not too complex from a build configuration point of view so that I'd hope that the maintainers wouldn't have too much hazzle. At least it would be a start and a chance to get some experience.

@tcurdt what do you expect for this issue as outcome, or in other words: which questions do you need to be answered and what do you need to decide about the introduction of a Gradle build?

edit: this looks interesting but quite hacky: http://stackoverflow.com/questions/11209382/build-maven-plugins-using-gradle#answer-17181234

[tcurdt]

@gesellix that's for digging into this!

The question that needs to be answered:

• can we re-use the maven-maven-plugin
• can we re-use (or is there an alternative to) the shade-plugin
• can we get unit and integration test to work
• can we get code coverage to work

@ebourg we are building deb packages in java and also provide an ant plugin - what's your point? ;)
But you are right - the only way this could fly is when we can re-use the maven-maven-plugin.

[gesellix]

Having had some sleep I'd propose the following structure to address the potential issues with ant/maven/whatever plugins:

• core: contains the actual code, independent of any plugin. I hope this is possible, but I didn't check the code yet.
• maven-plugin: depends on core and adds any maven plugin specific resources. This module also produces an artefact to be published on Maven central.
• ant-plugin: same idea as with the maven-plugin. Can also produce a dedicated artefact to be consumed by Ant. I'm not sure if it's necessary, but this allows a clean core module.
• gradle-plugin: nothing new here, same as with the other plugins. I'm not sure, if that's necessary to be contained in the jdeb repo. It depends on the matter of taste and whether you maintainers are willing to maintain Gradle plugin code. I'd be open for discussion about donating the necessary code, but at some point you should think about the direction where jdeb should go and how many different variants you're willing to maintain.
• integration-test: contains integration tests, which don't fit into the other plugin specific modules - I would add that module only when really really necessary.

[gesellix]

Now regarding the maven-plugin module: I would think about making it a Maven project/module so that it feels "right" in a sense like @ebourg proposed.

[gesellix]

Notes regarding @tcurdt's questions:

can we re-use the maven-maven-plugin

• as proposed a dedicated maven-plugin module with its own pom.xml should be a no-brainer.

can we re-use (or is there an alternative to) the shade-plugin

• should be possible with the shadow plugin

can we get unit and integration test to work

• unit tests
• integration tests

can we get code coverage to work

• jacoco
• coveralls

[tcurdt]

Splitting up jdeb I had in mind for 2.x - not sure this is really a goal for 1.x. Not ruling it out - but I am concerned about having the tests spread across multiple sub modules though. I would rather have all tests and coverage in one place.

As for the shadow plugin - unfortunately it's still missing the minimize functionality

[gesellix]

Is the missing minimizeJar a show stopper? Do you have an ETA for jdeb 2.x?

[tcurdt]

@gesellix not sure I would call it a show stopper - but it definitely sucks (and given the original minimizeJar in the shade plugin was contributed by me I fear more work coming my way then).

So far 2.x is just a sum of what is wrong with 1.x.
There hasn't been much feedback/discussion on the #195 yet.

[ebourg]

I don't get the point of switching to Gradle. What's wrong with the Maven build for jdeb?

[tcurdt]

@ebourg I am not pushing for it - but #226 annoyed me so much that I got curious.

[gesellix]

Regarding the integration tests: they are highly Maven specific, so I suppose you prefer them to stay Maven specific?

I'd continue with the coverage tools first, since that seems to be your incentive to switch to Gradle ;-)

[tcurdt]

@gesellix well, ideally we would have integration test not just for the maven plugin but also ant (and gradle?) - at least that's my vision for 2.x.

[gesellix]

I'm still keeping this one in mind, so I'd like to share my thoughts:

I'd propose to wait for a split planned for 2.x. Splitting the code base could then consider this issue as one of all other aspects. Perfect would be when some platform independent artefact can be created, while specific ones (Ant, Maven plugin, Gradle plugin, ...) only need to be some kind of adapters.

The beauty for consumers would then be that e.g. a Maven environment wouldn't need to care about Gradle specifics. Even the integration tests are highly specific, acting like a consumer, while some might probably also be implemented as consumers of the core only.

A personal note about the duplicated integration tests across the specific modules: I wouldn't consider that as an issue, because sometimes they might be very similar, but the semantics change over time. I wouldn't try to enforce them to stay same, because from a consumer's point of view there's no value in "same integration tests across Maven and Gradle plugins". Re-using them only helps the maintainer, so the question is: how often does/should an integration test fail for a quite stable concept like creating a .deb file? ;-)

In essence: I propose to postpone the discussion until 2.x is near. Thoughts?

Edit: which feature or event would start the 2.x development?

[tcurdt]

This is off the table (for now). Hence closing.