I still thinks that the solution for EJ would be some Maven proxy (Codehaus
or Proximity) and preparation of "in-house" M2 release package (with
modified settings.xml).

Here at our company (www.levi9.com) we have one Central proximity mirroring
repo1.maven.org with some local and other custom stuff deployed locally on
Proximity (some JDBC drivers, the well known Sun javax.* jars etc).
Furthermore, every M2 developer have LOCAL Proximity (bundled with Tomcat5)
running as service on his workstation with his local repo (to publish some
specific deps for his work and to share stuff between other M2 developers
without affecting corporate env) and another repo proxying Central
Proximity. This LOCAL Proximity is just an option but is widely used by
developers! Of course, all "mainstream" project related stuff goes to
Central Proximity.

So, the worst path that an artifact may pass is ibilio -> central proximity
-> local proximity -> local repo.

Our company is not so restrictive, so direct access to central repo is not
disabled (by some firewall or so) but every developer is using Central
Proximity as central mirror (just one settings in settings.xml or by
deploying customized M2 installation) per default. Later, they download from
intra bundled proximity and with settings.xml modification use the local
proximity instance.

[...]
  <mirrors>
    <mirror>
      <id>proximity-maven2</id>
      <mirrorOf>central</mirrorOf>
      <name>Proximity Maven2</name>
      <url>http://localhost:58080/proximity-maven2/repository</url>
    </mirror>
  </mirrors>
[...]

Btw, i made in Proximity some major enhancements, applicable and meant
exactly for corporate users:

- complete accessManager solution applicable per Proximity and per
Repository (you can conrol access on proximity level and per repository
level) eg. John has access to Central Proximity but not for Project-X
repository. He still can use Central Proximity as central mirror,
- possibility to make a repo offered to M2 but hidden from repo browsing,
- possibility to "pipeline" proximities (like in the example above) and
beside repo aggregation it does it is possible to "target" repos thus
maintaining the real repo source (parametrizing with ?repositoryId=central
URL queryString on remotePeer), eg. LOCAL Proximity's central repo targets
Central Proximity with repositoryId=central query string.
- many bugfixes in LuceneIndexer (much of performance enhancement) and in
other components,
- and finally, it is made java 1.4 compatible :)

Watch for release soon! (WAR and Tomcat5 bundle too)

Have fun with M2!
~t~

Reply via email to