search

openequella / openEQUELLA

Core openEQUELLA sources
https://openequella.github.io/
Apache License 2.0
42 stars 44 forks source link

Remove Dependency on Pearson Maven Repo #2

Closed smclaughlin520 closed 7 years ago

doolse commented 7 years ago

So all the dependencies not found in Maven central have been collected up into a local repo .zip. Got a preferred place I can upload this zip?

There are 52 artifacts in all, which roughly fall into 5 categories:

  1. Jars which were just downloaded from their project website and uploaded to nexus, some of these may indeed have an equivalent in Maven central but we just didn't look for it.
  2. Internal Equella build artefacts which we have the full source for
  3. Pearson internal jars
  4. Open source libraries which we desperately needed a small bug fix so we patched the source and built our own - possibly still have the source for the fix, also possible that upgrading the library will help
  5. Open source projects which we extended significantly because the original had been abandoned (can only think of one case here - JPF)

How would you like to go about managing these? I could begin by assigning each to a category along with any relevant information (source repos etc..)

abidingotter commented 7 years ago

The Apache commons file upload jar was hacked to allow for multipart requests to fully resolve whilst the uploads still happened in the background. There may be another way of doing it now, but it would require significant Equella re-writing if we were to lose the hacked file upload jar.

drewwills commented 7 years ago

Folks,

For a short-term (non-permanent) solution to this issue I suggest we wire up these dependencies in a manner something like this example: https://github.com/Jasig/uPortal/blob/master/uportal-portlets-overlay/CalendarPortlet/pom.xml#L41

That will get us software that builds, but it's not a solution we want to maintain in the long run.

We need to tackle these items one-by-one. This is work that Unicon can help with.

In general terms, a likely solution for each of the types (1 - 5) above would be...

  1. Look for the equivalent in Maven Central; encourage the developer(s) to make the library available in Maven Central
  2. These items should be part of the contribution to open source, and we should set up additional Git repos under this organization for them. We can cut releases and post them to Maven Central.
  3. If these aren't a part of the open source contribution, we will need to cut them out (refactor the code that uses them until it doesn't). This is work that Unicon can help with.
  4. Try upgrading the library; offer solutions to the maintainers
  5. Maybe there is a new, attractive alternative; otherwise we can look at the approach for type 2 items
smclaughlin520 commented 7 years ago

@ddelblanco @msultzaberger -- Please check in with @drewwills on how you can assist on this Task?

doolse commented 7 years ago

The categorisation was completed with the results in a google sheet: https://docs.google.com/spreadsheets/d/1GYyQ2jdw9IKccQDVt-cpcvgJuI5MuCUgOAzCkr4JIYw/edit?usp=sharing

The grouping ended up being:

  1. Non-maven - homepage to find binaries or source.
  2. Maven - either an exact binary match was found, or a newer version could probably be a drop in replacement. New groupId/artifactId/version.
  3. Source changed - libraries which we (possibly) modified and built our own version. Homepage of source project and possibly location of changes.
  4. Our original source - the stuff we wrote and uploaded. Repo and path location.
  5. Other - A few things that didn't quite fit, just notes on why.
doolse commented 7 years ago

The master branch now contains no nexus dependency.