[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] ISiteFactory implementation on top of the Buckminster Maven provider?
|
Eugene Kuleshov brough up a very interesting idea in a discussion on the eclipse.tools.orbit
newsgroup: (see news://news.eclipse.org:119/e94eda$qnb$1@xxxxxxxxxxxxxxxxx) where he writes
"Not sure if it is a widely known fact that layout of update site and actual update is
pluggable and can be customized" and suggests a custom implementation that could read maven
repositories and extract information from POM files.
I'm cross posting this to both buckminster-dev and orbit since I think this might be of
interest to both groups.
As I indicate in a reply later in that thread, an update site backed by a maven repository
would be fairly easy for us to implement. We already read and extract information from maven
and POM files. We also have the functionality needed to scan URL-based repositories in order
to produce a catalog (the url catalog reader). The materialization is in place and an
initial prototype is already in the works for the special binderType that we discussed
earlier with Knut Wannheden in these threads:
buckminster-dev -> component binding
news://news.eclipse.org:119/mailman.16.1137584332.6125.buckminster-dev@xxxxxxxxxxx
buckminster-dev -> component materialization
news://news.eclipse.org:119/mailman.0.1134640109.6125.buckminster-dev@xxxxxxxxxxx
I think that it is more then feasible to create an ISiteFactory implementation that would
reflect a Maven repository by using already existing Buckminster extensions. We could
probably do it generic enough to reflect any repository that exposes jar files in one way or
another (JPackage for instance could be another candidate) since we already abstract various
types of repositories and component types.
In the Maven case, the URL needed in order to create the site would of course be something
like "http://www.ibiblio.org/maven/";. We let the maven categories map 1-1 to the site
categories and we generate features and plugins based on the dependency graph that we obtain
using transitive resolve on-the-fly.
Kind Regards,
Thomas Hallgren
