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 <sco...@javactivity.org> 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<sco...@javactivity.org> 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<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-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>>
>>>>
>>>> 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<users-unsubscr...@maven.apache.org>
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
