DISCUSS: maven package structure

[acoburn]

With Alpaca and Salmon now in separate repositories, I have some questions about the karaf provisioning feature and the location of the *-parent artifact. At present, both of those are part of Alpaca.

The current structure seems a little tangled to me. Here is a suggestion for separating them:

1. Remove alpaca-parent from the Alpaca repo, putting it into its own github repository. The advantage of doing this is that all java-based (i.e. maven-based) code can refer to a single parent POM w/o regard to the particular versioning needs of alpaca. The current structure is such that if Alpaca has a new version, but the changes don't affect the parent POM, the Salmon code would need to be updated simply to track the (non-) changes to that parent. If the parent is decoupled, all of these projects can be versioned independently, which is a very good thing IMO. The current (published) name of this artifact is islandora-parent, which has been changed to alpaca-parent. With this suggestion, I think reverting to islandora-parent would make sense.
2. Put all karaf-based provisioning code with the projects that provide those bundles. That is, have a karaf features file with Alpaca, covering all alpaca-related artifacts; and have a separate karaf feature file for Salmon, covering only those artifacts that are part of Salmon. The package structure could reflect this: i.e. ca.islandora.alpaca.karaf and ca.islandora.salmon.karaf.

Thoughts?

[ruebot]

This makes sense to me, and I'm happy to do the separation stuff again.

Would it also make sense to have a build tools repo like fcrepo has too? And, how does this play in with the Gradle side to things?

[acoburn]

If there is a common islandora-parent repo, I'd be inclined to put any build-tools-related code there, too. As for how this intersects with Gradle, that's still a work in progress, but it certainly isn't incompatible with transitioning to Gradle.

[acoburn]

Gradle doesn't have a "Parent-POM" construct like Maven, so this sort of structure wouldn't be so useful. Gradle accomplishes the same thing by allowing projects to either publish a gradle script on a public web server or wrap the common code in a gradle plugin. Both are quite possible. Perhaps we should hold off on any structural (repository) changes until we have a better idea of how the build environment will work. (Which I'd like to have pretty well clarified this week)

[acoburn]

@ruebot it appears that Gradle supports the scenario where a certain artifact (e.g. islandora-build-tools) may contain configuration files for checkstyle, license headers, etc, and that those artifact resources can be used by downstream projects without too much difficulty.

Edit: I have this figured out, so once we're ready (if we want to plunge into Gradle as a build environment), this will be really easy to set up.

[ruebot]

Resolved with #552