For JEE 6 applications you can use this pom fragment:
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee6-specs-bom</artifactId>
<version>2.0.0.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
in your dependencyManagement.
Unfortunately, this does not exist for JBoss EAP 5.x that I'm aware of.
JBoss/Redhat do have a lot of artefacts in their maven repo, which I believe is
now mirrored at central. It may be worthwhile exploring the org.jboss artefacts
there to see if it contains what you're looking for.
Cheers,
Steve C
On 03/12/2011, at 7:55 PM, Stephen Connolly wrote:
> Ahhh well you should be able to use the pom's they have as templates for
> EAP 5.0 poms
>
> On 3 December 2011 01:10, Steve Cohen <[email protected]> wrote:
>
>> Sorry, it's our company who will not bless use of EAP 6.0 at all, but will
>> bless it EAP 7.0 soon. Hopefully there will be Maven for that. I didn't
>> mean to imply anything about JBoss's plans.
>>
>> There is a Maven repo for jboss.org 5.1.0.GA. I was groaning about
>> having to go backwards from that.
>>
>> Steve
>>
>>
>>
>> On 12/02/2011 06:51 AM, Anders Hammar wrote:
>>
>>> 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 jboss.org 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 jboss.org 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?
>>>
>>> /Anders
>>>
>>> On Fri, Dec 2, 2011 at 13:39, Steve Cohen<[email protected]> 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<[email protected]>
>>>>> 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-unsubscribe@maven.**apache.org<[email protected]>
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>>
>>>>> 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:
>>>> users-unsubscribe@maven.**apache.org<[email protected]>
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@maven.**apache.org<[email protected]>
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> users-unsubscribe@maven.**apache.org<[email protected]>
>> For additional commands, e-mail: [email protected]
>>
>>
