You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <st...@comcast.net> on 2011/12/01 21:00:14 UTC
Handling Non-Public runtime packages
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?
Re: Handling Non-Public runtime packages
Posted by Stephen Coy <st...@resolvesw.com>.
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 <sc...@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<sc...@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<st...@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<us...@maven.apache.org>
>>>>> For additional commands, e-mail: users-help@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<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Re: Handling Non-Public runtime packages
Posted by Stephen Connolly <st...@gmail.com>.
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 <sc...@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<sc...@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<st...@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<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@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<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Handling Non-Public runtime packages
Posted by Steve Cohen <sc...@javactivity.org>.
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<sc...@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<st...@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
>>> For additional commands, e-mail: users-help@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
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Handling Non-Public runtime packages
Posted by Anders Hammar <an...@hammar.net>.
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 <sc...@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<st...@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
>> For additional commands, e-mail: users-help@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
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Handling Non-Public runtime packages
Posted by Steve Cohen <sc...@javactivity.org>.
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<st...@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
> For additional commands, e-mail: users-help@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
For additional commands, e-mail: users-help@maven.apache.org
Re: Handling Non-Public runtime packages
Posted by Anders Hammar <an...@hammar.net>.
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 <st...@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
For additional commands, e-mail: users-help@maven.apache.org