>>>>> On Fri, 17 Feb 2017 23:34:57 +0100, arjan tijms <arjan.tijms_at_gmail.com> 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.
EB>
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.
Right.
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?
EB>
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.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 10 business days until JavaLand 2017
| 28 business days until planned start of Servlet 4.0 Public Review