Does maven currently support or can be extend to support the notion of
Repository Groups?

Background on why this would be needed:

To properly deal with SGi bundles, you really need a set of bundles you
will compile against. If you take an eclipse install for example there
could be 130+ osgi bundles in the eclipse/plugins folder. The eclipse
compiler needs to be told the target, eclipse install, it will use for
resolving dependencies. If the bundle you are compiling calls out a
dependency on version 3.2.0 of the org.eclipse.core.runtime bundle then
resolution is easy as the compiler plugin simply needs to see if it has the
org.eclipse.core.runtime plugin with that version in its bundle map.
However if the bundle you are compiling instead uses a package import
dependency (i.e. org.apache.commons.logging) then the compiler need to
review all of the bundles that export java packages and chose the best match
for which bundle it will add to the classpath for compilation.

When targeting an eclipse install on the filesystem then this can work with
changing/extending maven however installing and deploying still need work.
If instead maven had the notion of Repository Groups then a repo group "
org.eclipse.platform-3.2" could be specified and this group would have
pointers, symlinks, etc to the component artifacts in the group which may be
in 1 or more repos. Repo groups would allow users to essentially define
their own software stacks such as "spring-webapp-2.0" as a repo group and
adding this dependency to your pom would transitively resolved when the
group was resolved and add spring-2.0, commons-logging-1.1, log4j-1.2.13 and
hibernate-3.1.3 to the classpath for the project.

Wb

6/9/06, Brett Porter <brett (AT) apache (DOT) orgwrote:

Wendell Beckwith wrote:
I'm working with limited knowledge from both sides (always a combo for
success) but can you clarify what you mean by a custom maven
install? Are
you talking just for the dependency resolution stuff or are we going to
need
to change so much about maven that's darn near a fork?
--
Yep, you'll need to put a JAR into $M2_HME/lib or similar that contains
the alternate dependency resolver. It can be completely separated, I
think.

However, we generally don't want to have to modify the Maven install, so
if this is a common case we may want to support it via the PM. The
<extensionstag is there for that purpose, but we may not find it is
loaded early enough for the dependency resolver.

Regardless, it will be possible to do this, and we can work to making it
cleaner afterwards.

- Brett