Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-32184

Remove majority of pack projects



    • Bug
    • Status: RESOLVED
    • Major
    • Resolution: Fixed
    • 12.0
    • 12.0
    • Global
    • None


      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.

      Gliffy Diagrams



            Issue Links



                  buckett Matthew Buckett
                  buckett Matthew Buckett
                  0 Vote for this issue
                  1 Start watching this issue



                    Git Integration