Most pack projects in Sakai just have one dependency that the impl
project and contain just one file that is the spring wiring for the
project (components.xml). I'd like to suggest we collapse the impl and
pack projects into one. This would remove about 60 projects This has
the following benefits:
- Smaller number of projects in Sakai which has the following benefits.
- This results in faster build times as maven doesn't have to
process as many projects.
- IDEs can more easily import the whole of Sakai and don't run out
of memory as quickly.
- Less confusing, the pack projects don't do much and so there is
confusion as to why they exist.
- Less space in build and ~/.m2. The impl project doesn't get put
into ~/.m2 and have it in 2 places in /target folders when doing a
- Easier to flatten out projects in the future. At the moment some of
the older projects have extra folders
/announcement/annoucement-impl/impl. By getting rid of the pack/impl
split we could move these projects up one level without changing the
toplevel project directory names.
- Easier testing of spring wiring. Having the components in a
different project makes it tricky to test the components.xml wiring as
you have to setup test stuff in another project all over again and so
the friction is too high to makes it sensible todo in most cases.
- Option to flatten other projects in the future. Some codebases are
split into lots of small projects which are then combined in the pack,
these projects could be flattened down. Often these projects aren't
used anywhere except in the component project (eg oauth). Keeping
these projects separate can hide dependency version issues as when
deployed all the classes end up in one classloader, however in
development they are treated as isolated components which they are
- This is already done in some projects (eg lessonbuilder), they don't
have an impl and just a pack (lessonbuilder-conponents). So this isn't
a new pattern and keeps things more consistent.
However it does have downsides:
- Some files will change location (components.xml) which means merges
back to older branches don't always work. However if we just changes
the <packaging> of the impl project 99% of files will stay in the same
- Deploying of impl. To keep the paths the same the simplest option is
to deploy the impls, this means impls will show up in
tomcat/components/. This may confuse people and doesn't keep our
naming as clean. We could update all the project names, however I
don't think this is worth it.
- Developers would have to clean out /components folder once when the
code change hits master as deployed paths would change.
- More small files in /components/.../
I'm not opposed to having modules/projects where it makes sense,
however there is a cost to doing this which we shouldn't ignore. We
can continue to produce a JAR from an impl project by using the maven
assembly plugin, but in 99% of cases this isn't needed.
I'm not suggesting removing all the impl/pack splits, just the simple
ones that serve no real purpose.