Css4j lacks a single-step build about css4j HOT 7 CLOSED

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.

from css4j.

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.

from css4j.

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.

from css4j.

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.

from css4j.

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.

from css4j.

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.

from css4j.

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.

from css4j.