I recognize your situation and here's what I've done for JBoss EAP (4.3 and 5.0):
For all the runtime artifacts of the platform, I've created a tool that analyzes the dependencies between those artifacts. Based on this information I've created poms for all the artifact with this dependency info. The approach has been a best-effort, and might not be absolutely correct. For example, I'm not sure that dependencies due to annotations will be reflected. For the GAVs I've decided to give all artifacts the same groupId ("mycompany-jbosseap"), the artifactId is the original name of the jar and the version is the version number of the complete platform ("5.0.0.GA" for example). The reason for the groupId was to make sure that there would never be clash with something that JBoss/Red Hat would release. Using the version number of the platform is because it almost impossible to figure out the original version of some of the artifacts. Also, I've created import poms with dependencyManagement for all the artifacts. I have such an import pom for server side (the production server config) and one for client side. This approach works ok, but there are drawbacks. Also, some of the original decision I would probably do differently today if I started from a clean sheet. One drawback is that you could get the same artifact included twice, if some 3rd party dependency uses it's original GA. For example, "servlet-api" as it's original groupId is "javax.servlet" and not "mycompany-jbosseap". This is not a problem for a knowledgeable Maven user as you just add exclusions. But for normal developers I find that this is magic and they normally never analyze their dependency tree. If I would do this again, I would spend time figuring out the correct groupId (and artifactId) for the artifactId, at least for the non-jboss ones (many of the jboss ones have changed groupId recently, which make them tricky). The version number could then be some thing like "5.0.0.GA-jbosseap" to make sure it would not interfere with any official version. All developers are instructed to use these artifacts instead of any other, if possible. This will ensure that even compilation is done towards what will be the runtime platform. Then unit testing will use the same artifacts as are used in runtime. Any issues will be found as early as possible, which is important IMHO. A (customized) zip of the platform is also available from the repo. Which makes it possible to use Codehaus Cargo to automate ITs where the app server is installed, configured, started, and the application deployed to, as part of a Maven build. Quite nifty if you ask me. If you're in fact using JBoss EAP, I should inform you that Red Hat has created their own EAP 5.0 Maven repo. However, they do not have any dependency information in their poms which make their solution less good than mine IMO. They claim this will be fixed for the EAP 6.0 repo as Maven will then be used to build the platform. If I recall correctly they have the correct groupIds and artifactIds though. Search for "Project Wolf" to find out more. /Anders On Thu, Dec 1, 2011 at 21:00, Steve Cohen <stevec...@comcast.net> wrote: > I am perplexed by the following situation: > > I work for a very large corporation with strict bureaucratic rules about > what you can use. Nonetheless, they have a maven repository administered by > very helpful people. However the maven repository people don't talk so much > to the technical standards people (they don't even know each other) and > therein lies the problem. > > The technical standards folks mandate that certain versions of application > servers (for example, JBoss) must be used. These are not the publicly > available versions commonly found but "enterprise versions" that are either > built by RedHat for specific corporate clients or available to any paying > corporate client, I'm not sure which. These come packaged in .zip files > that may be downloaded from an internal corporate web site. > > That would be okay if all I was concerned about was creating a server to > develop on. But I also need to develop against the "targeted runtime" of > that server, and I want to use Maven, as I could with the publicly available > versions of the server. To do that, I need to have these server runtime > jars as "Provided" dependencies in my project. However, there are no poms > included with this zip file. I could load every jar in the package into a > team-private "third party" repo in the central repo, but this would then be > just a bunch of jars with no inter-dependency information available. Even > if POMs were available, getting them all into the repository is a > non-trivial task. > > How does one cope with this situation? > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org