User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
Perhaps there's someone in the community who understands all these
constraints, and understands the Java Platform Module System, and
can suggest the best approach going forward?
arjan tijms wrote on 11/29/18 2:57 AM:
Hi,
Currently Mojarra and EL-RI are two other projects that
combine API and IMPL in a single jar.
In JSF/Mojarra there's an historic impediment where API
classes contain large, even huge, amounts of implementation
specific code.
It's almost an oxymoron, but it currently is what it is.
It would be great to one day be able to split off a more
pure API artefact, but it's far from trivial.
Kind regards,
Arjan
On Thu, Nov 29, 2018 at 8:56 AM Greg Wilkins <gregw@xxxxxxxxxxx>
wrote:
All,
If course it is possible to work around
having classes in two different jars. Tools can be
changed, we can compile against different classes than we
run against, tests can be changed etc.
But these don't change the fact that
generally speaking it is a bad idea to package the same
class into two different jars/modules. We might be able to
make it workable in this specific case, but I'd much
rather we had policy settings that avoided the need for
such work arounds.
For many projects the API is an artifact
produced entirely separately from the implementation and
it is thus really bad practise to repackage the artifacts
into a single artifacts. It can obscure copyright, and
licensing, it can encourage alternate potentially
different APIs, and it is going to make modules more
difficult. Let's just stop doing it generally.
If there are specific projects where it
makes sense, let's have a specific convention for
combining API and implementation into a single "runtime"
jar.
