Using modules in open source libraries

[Alessio Stalla]

Portofino 4 (rough numbers):

elements 21 exported over 25 total
admin 12/12
atmosphere 2/2
base 12/16
calendar 4/4
chart 7/7
crud 7/7
database 12/13
each database module - mysql, postgresql, oracle, ... there are around 10
of them - generally 2 exported, 0 internal
gallery 3/3
jersey 1/1 (dynamic)
mail 7/8 (the non exported one is actually unused)
map 3/3
pageactions 24/24
quartz 2/2
resteasy 1/1 (dynamic)
stripes 1/1 (dynamic)
theme 1/1 (dynamic)

So in total around 10 internal over more than 130 (again counting roughly).

This is a web application framework so many packages contain classes
directly exposed via HTTP (e.g. JAX-RS resources). I counted those as
exported because they have to be at least dynamically available to web
frameworks/infrastructure such as JAX-RS. Anyway most of those actions are
intended to be extended by users, so arguably the numbers wouldn't change
much if the dynamic availability wasn't considered. Also, offsetting that,
I counted only Java packages, but many modules also include resources to be
exposed via web (Servlet API 3.x) in additional packages. I suppose those
ought to be exported as well.

And - in case someone objects that frameworks are rare things and most
people write applications instead - this is a web application as well. Just
one intended to be heavily extended. I mean, the default distribution is a
WAR file in a Tomcat instance.

The thing is, it has a core made of a few fatter modules, and several
small/tiny optional modules that build upon that. Users can provide their
own modules as well. So, the core with some refactoring with Jigsaw in mind
could reduce the ratio of exported/total packages a bit. The satellite
modules though are so small that it doesn't make sense for them to have
internal packages. At most, the biggest ones will have one or two, but most
of them are 1 to 3 packages.


On 26 July 2016 at 14:49, Jochen Theodorou <blackdrag at gmx.org> wrote:

>
> Groovy-core  44 exported and 25 maybe not exported
>
>
>
> On 26.07.2016 12:10, Stephen Colebourne wrote:
>
>> There has been a lot of discussion about exporting packages - at
>> compile time vs runtime and also the related problem of resources. I
>> decided to take a look at some open source projects to see whether a
>> list of exported packages is useful as currently defined:
>>
>> These standard open source projects were designed prior to modules:
>>
>> Joda-Time - 7 exported packages
>> Joda-Time-Hibernate - 1 exported package
>> Joda-Time-I18N - 1 exported package
>> Joda-Time-JspTags - 1 exported package
>> Joda-Money - 2 exported packages
>> Joda-Primitives - 10 exported packages
>> Joda-Convert - 2 exported packages
>> Joda-Collect - 1 exported package
>> Joda-Beans - 16 exported packages
>> Joda-Beans-Maven-Plugin - 1 exported package
>> Joda-Beans-UI - 5 exported packages
>> ThreeTen-Extra - 3 exported packages
>> ThreeTen-Backport - 6 exported packages
>> Google Guava - 18 exported packages, 1 non-exported package
>> SLF4J - 3 exported packages
>> JCommander - 4 exported packages, 1 non-exported package
>>
>> Looking at the list, it is clear that non-exported packages are a
>> small use-case.
>> - 81 exported packages
>> - 2 non-exported packages
>>
>> Strata [1] has been designed in Java 8 but with an awareness that
>> modules are coming:
>>
>> Strata-Collect - 8 exported packages
>> Strata-Basics - 7 exported packages
>> Strata-Data - 2 exported packages
>> Strata-Calc - 3 exported packages
>> Strata-Product - 23 exported packages
>> Strata-Market - 13 exported packages
>> Strata-Loader - 3 exported packages, 1 only exported at runtime for
>> reflection
>> Strata-Math - 1 exported package, 17 packages exported only to a
>> single friend module
>> Strata-Pricer - 19 exported packages, 10 non-exported packages
>> Strata-Measure - 15 exported packages
>>
>> - 94 exported packages
>> - 17 exported to a single other module
>> - 11 non-exported packages
>>
>> I'll use a different thread to express my opinion on what the data
>> means. Please use this thread to add summaries of other open source
>> projects.
>>
>> Stephen
>>
>> [1] https://github.com/OpenGamma/Strata
>>
>>