Hi, you may want to have look at Apache Taverna's plugin system which did something similar. War story below..
We initially (2007) used Maven dependencies directly by parsing pom.xml dependencies and using a set of repositories, but found this very fragile because of versioning mismatches when upgrading anything; basically we ended pulling down both the newer and older version of dependencies of the main application, which might not match. Back then it was even trickier to use Maven APIs outside Maven, so we replicated our own pom.xml parsers and our own dependency tree resolution. (Not a good idea!) We called this Raven.. In addition to having to play catch up with Maven (e.g. property expansion within version strings) this infrastructure also ran into problems with third party maven repositories for plugins being unreliable, but because we had merged to a single list of repositories this affected installation of all plugins and slowed down every startup. (We actually added blacklisting of repos before Maven did :-)) While our first attempt, using our own "Raven" system assumed everything was a plugin, meaning we could ship a minimal launcher and pom files, but it would easily take 20 minutes on first launch to download everything. So we had to "prewarm" our local repository - a naïve copy from .m2/repository would also work. We introduced a distinction from the Application (the full base application that the installer provides) and optional plugins, which then must be compatible with the particular application version. This is more of a Firefox+plugins style model which is probably what you need as well. In the end we decided for a simpler OSGi based launcher where we have a maven plugin that can generate a Taverna plugin description (it unrolls all the transitive dependencies), which can then be installed from a single site independent of Maven infrastructure. So now we don't use anything Maven related at runtime, meaning you can also install plugins by dropping a file into a folder. Taverna Osgi has update support as well with pre-checking of compatibility, to avoid upgrading yourself to an version-incompatible state. We use it for a command line tool and a Swing-based workbench, with Swing components to manage plugin install. I'm afraid we don't have much documentation yet, see https://taverna.incubator.apache.org/download/osgi/ and ask on dev@taverna if you (or anyone else) are interested ! https://taverna.incubator.apache.org/community/lists On 1 Jan 2017 6:00 pm, <org.apache.maven.u...@io7m.com> wrote: > On 2017-01-01T17:37:26 +0100 > "Robert Scholte" <rfscho...@apache.org> wrote: > > > Hi, > > > > doing this outside the context of Maven is probably hard to do. What you > > at least need is the maven-artifact-resolver[1] (that's the project where > > the development of Eclipses Aether[2] continues), though is has not been > > released yet, so right now using Aether would be an option. > > You'll also need a maven-aether-provider[3]. > > I would expect that with these projects you should be able to do your > > stuff, although doing it with a custom maven-plugin is probably a lot > > easier. > > > > Robert > > > > [1] https://maven.apache.org/components/resolver-archives/ > resolver-LATEST/ > > [2] http://www.eclipse.org/aether/ > > [3] http://maven.apache.org/ref/3.3.9/maven-aether-provider/ > > > > 'Ello. > > Thanks for these. > > I should elaborate what I'm trying to do. > > I'm writing a small game and the game is designed to support third > party modification out of the box. What this means in practical terms > is that the game ships with a simple launcher and a directory full of > jar files and their associated Maven POMs. In the launcher, the user > states that they want to run the game with any extra specified mod > packages, and the launcher analyzes the local POM files of the packages > to determine if all of the dependencies are met (and will fetch packages > from our server or Maven Central if the dependencies aren't currently > installed). > > So, there isn't actually a plugin as all of this is happening post > "deployment". > > I'll have a go at a proof of concept with the links you've provided. > > M >
