Re: Significant, not discussed changes on master (was: Re: MOJARRA_2_3X_ROLLING branch has been created)

From: Edward Burns <>
Date: Tue, 14 Mar 2017 07:16:17 -0700

>>>>> On Fri, 17 Feb 2017 23:34:57 +0100, arjan tijms <> said:

EB> Yes, and I know Vernon and Neil have dealt with it as well. The
EB> antiquated and crufty build system has long been a pain point.

AT> Indeed. It's of course not unusual for a project of this age, but it has
AT> been a pain point indeed to many.

EB> This work can certainly proceed, but I'd like to see notifications sent
EB> to the dev list. Even better if the change can be proposed and
EB> discussed before being enacted.

AT> Sure, I'll do that from now on then for changes not yet discussed. So if
AT> it's okay, I'll then continue with the small incremental changes mentioned
AT> (fixing a Sonar warning at a time) without proposing each such individual
AT> change, but if there's anything bigger than that, I'll propose and discuss
AT> it first here. Would that be okay?

Yes please.

AT> It goes without saying that I won't touch anything changing API contracts
AT> in the trunk, which I know has to wait for the next spec cycle to have
AT> started.

EB> I do have some questions though.

EB> What is the plan for the jsf-api and jsf-impl directories?

AT> The plan was to delete these. If the project is a proper maven project they
AT> won't be needed anymore. The IDE specific project files (like the Eclipse
AT> ones that I more or less maintain), won't be needed anyone either then as
AT> all IDEs recognise proper Maven projects. Finally the lib folder (which
AT> kinda emulates Maven's .m2 folder) can be fully removed as well then.

+1 for those changes.

EB> What is the plan for the api directory, since the classes formerly in
EB> jsf-api/src/main/java are now in the impl directory?

AT> If I understood correctly, the Mojarra project had already moved to a
AT> single jar solution, basically since the API contains many implementation
AT> things already. The Mojarra jar as used by GlassFish is clearly one jar,
AT> with two main packages. The impl directory reflects this directly.

EB> How do you generate the jsf-api.jar?

AT> Also partially answering the previous question; the api folder contains a
AT> pom.xml that specifically builds the API jar. It does this simply by taking
AT> all API classes from the impl build, and packaging those separately. In the
AT> same fashion, you can also build a jar with only the impl. classes (which I
AT> used to have in the strict-impl sub folder, but I deleted that one again).

AT> This API jar, just like the existing API jar, is only usable to compile
AT> against, of course.

AT> Hope this makes it more clear.

Yes, +1 for those changes and explanations.


| | office: +1 407 458 0017
| 10 business days until JavaLand 2017
| 28 business days until planned start of Servlet 4.0 Public Review