Css4j lacks a single-step build

[carlosame]

Currently, to build the library one has to fetch the css4j-dist repository, execute a script and then execute Gradle. This is not only annoying for developers, it is also difficulting the set up of a good CI system.

This library has three other modules in addition to the core module: css4j-agent, css4j-awt and css4j-dom4j. The idea has always been to promote them to independent projects, and in fact they are rarely updated. But downstream users seem to prefer that they all come in a single release, together with the main module. And admittedly, quite a few people would never learn about the other modules if they were kept as completely independent projects.

So my plan is to integrate css4j-agent, css4j-awt and css4j-dom4j into the main css4j (this repository). If you'd prefer to have them as completely independent projects (or keep things like they are now) please comment or downvote this post.

I'm going to post a heads-up about this in the css4j Google Group.

[vmassol]

IMO it's better as separate artifacts since not everyone need all of them. For example the xwiki project doesn't need nor want to have css4j-awt classes in its distribution.

[carlosame]

it's better as separate artifacts since not everyone need all of them.

I should have worded it more clearly than it is: in any case, the artifacts would be kept separate. The alternatives are the following:

1. The css4j git repository contains a multi-module build that produces separate artifacts for css4j, css4j-agent, css4j-awt and css4j-dom4j. That's a single-step build.
2. Each repository (css4j, css4j-agent, css4j-awt and css4j-dom4j) contains a stand-alone build for its own module/artifact. That's a separate single-step build for each repository.
3. Leave things as they are now (multi-step build).

Consequences of each approach for distribution:

1. Simultaneous distribution of 4 artifacts.
2. Independent distribution of artifacts, each with its own release cycle. That makes sense as I expect that the non-core modules are very rarely going to be modified: the AWT module may never change in the future!
3. The current distribution through css4j-dist, which confuses people.

[vmassol]

ok, provided you keep generating multiple artifacts, I don't have any problem! A single build sounds ok but it means releasing new versions of the different artifacts even when there are no changes to them. It's fine for xwiki. Thanks for asking Carlos.

[carlosame]

I did not mention an important argument to favour 2): css4j-dom4j depends on the dom4j project which lacks a declared module name (see dom4j/dom4j/issues/67). Maven repositories are reluctant to accept modular artifacts that have non-modular dependencies, you only have to see the warning that Maven emitted when it was building css4j-dom4j:

[WARNING] **********************************************************************************************************************************************************
[WARNING] * Required filename-based automodules detected: [htmlparser-1.4.jar, dom4j-2.1.3.jar]. Please don't publish this project to a public artifact repository! *
[WARNING] **********************************************************************************************************************************************************

There is a similar issue with htmlparser and css4j-agent, and while I still hope that dom4j may perhaps be fixed in the long term, unfortunately do not have the same expectation about htmlparser.

[vmassol]

ok I thought you wanted 1) :) (since a single step build means 1) for me as it's in the same repo: one repo = one build = one release cycle). I agree that 2) is cleaner.

[carlosame]

I thought you wanted 1)

The initial idea was 2) ("The idea has always been to promote them to independent projects"), but I fear that quite a few people may miss css4j-awt or even css4j-dom4j if I do that. No final decision yet.

[carlosame]

Commit [ca6bea9] makes this project autonomous from css4j-dist. Tomorrow I'll commit similar changes to the other sub-projects, then close this issue (unless there are additional comments).

The basic idea is that, starting with 3.6.0, any module with a 3.x major version can be combined, same with 4.x once it comes out etc. For example, you'll be able to combine css4j-dom4j 3.6.0 with css4j 3.7.0 and css4j-agent 3.6.1, but not with css4j 4.0.0.

The most likely reasons to bump the major version to 4.x would be:

• A new selector requires specific support in css4j-dom4j (breaking backwards compatibility).
• A new method is added to the StyleDatabase interface (if that causes incompatibility with the current css4j-awt).

The main reasons to keep the other modules as separate projects: css4j-agent needs relatively frequent updates (to keep the public suffix list up to date) while css4j-awt could potentially be unchanged for a while. css4j-dom4j appears to be pretty stable as well.