maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <>
Subject Re: Handling Non-Public runtime packages
Date Fri, 02 Dec 2011 12:51:02 GMT
Who decided they're not going to support EAP6.0? Your company or JBoss/Red Hat?

I don't think the jboss community version fully support Maven, at
least not for 5.0 and earlier (which EAP 5 is based on). The
thing is that it is hard to do magic when the individual components
don't use Maven. For 7+ (which EAP 6 is based on) Maven will
be used, from what I've heard, so then they will be able to support a
EAP repo.

But I believe that two of the main Maven guys at Jboss are listening
to this list so they could clarify?


On Fri, Dec 2, 2011 at 13:39, Steve Cohen <> wrote:
> On 12/02/2011 01:47 AM, Anders Hammar wrote:
>> 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<>  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:
>> For additional commands, e-mail:
> Thanks, as I feared.  What a piece of @#$$%.  So those who pay for JBoss get
> development tools worse than the community version and those who negotiate
> such contracts don't know what Maven is.  And they've already decided they
> are NOT going to support EAP6.0 for some reason and go straight to EAP 7.0
> when they finally move off EAP 5.  So it will be like never before we get
> the support we need. I guess I will just manually put in the repo and call
> dependencies those things that I import in my code.  Ridiculous.  If they
> can do it for the community version why can't they do it for the EAP
> version?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message