You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Bahmer, Eric V" <ba...@lanl.gov> on 2013/07/26 18:01:28 UTC
Stop offline mode artifact version renumbering
I've searched through a few years archives of the mailing list and can't seem to find an answer to an issue that's been bugging me for a while now.
We've been using a highly customized third-party application for a while now and are looking to upgrade to a newer version.
The new version uses maven for part of it's build process.
I work in an environment that for SECURITY reasons I must run my build in OFFLINE mode.
I have already rebuilt over 600 rpms to have all the necessary dependencies available locally.
The problem I'm having is this:
The project uses jetty, it calls for version 7.5.3 to be used, I have a patched 8.1.0 installed.
Maven will resolve jetty correctly, however one of the jetty jars will end up with it's version number altered in the distribution.
jetty-server-8.1.0.v20120127.jar
jetty-servlet-8.1.0.v20120127.jar
jetty-start-7.5.3.v20111011.jar
This will not work as jetty-start reads it's own filename string and attempts to load other jetty jars with the same version string.
I can get around the problem by replacing the jetty version number <version.jetty> tag in the parent pom, which will make jetty-start have the same 8.1.0 version number.
However, jetty isn't the only jar that this is happening to.
The overall project which isn't entirely java has a few sub-projects built separately exhibiting this same behavior and I would rather avoid replacing every version number in every pom or adding them if they don't have them just so that all related packages like jetty, spring, or resteasy have matching version numbers.
I also don't want several copies of the same jar with different filenames because the version number is different for the sub-projects.
Otherwise I have to put a bunch of ugly loops in my rpm spec file to clean up both before the build and after.
Is there a way to force resolution of my locally installed version numbers and NOT rename the jar files to an incorrect version number? I've already tried the versions plugin, the dependency plugin, -U, -Dmaven.ignore.versions as well as combinations of them all.
I repeat that I have all necessary dependencies locally installed for offline build. I know my versions work. I want maven to ignore what the poms say about version and take the version number from what I have installed.
Re: Stop offline mode artifact version renumbering
Posted by Stephen Connolly <st...@gmail.com>.
The issue here is that you want to subvert Maven and provide your own jars.
When you decide to go down that road you *have* to provide *all* your own
poms.
If you were happy to take the poms and jars that you were given by a
*trusted* repository manager, then you'd be fine.
When you say something like "I want maven to ignore what the poms say about
version and take the version number from what I have installed" then you
don't want Maven.
Maven takes as a given that what the poms say about version is the truth.
If you want to use specific jars, you need to create the correct poms for
those jars.... and you need to think about the correct transitive
dependencies of those jars... and you need to do that for the closed graph
that is your entire dependency tree.
If you start from that place, you will get Maven to do what you need.
On 29 July 2013 23:09, Bahmer, Eric V <ba...@lanl.gov> wrote:
> I didn't pick the build system unfortunately.
> I'm just using what came with the productŠ
> And cursing their developers for using something that doesn't seem to mesh
> with high security environments.
>
>
> On 7/29/13 8:18 AM, "Stephen Connolly" <st...@gmail.com>
> wrote:
>
> >On 29 July 2013 15:04, Bahmer, Eric V <ba...@lanl.gov> wrote:
> >
> >> I was just hoping that maybe maven could use the local version numbers
> >> without renumbering everything as a command line option, especially for
> >>my
> >> environment where I can't have the maven going online and have to use
> >>the
> >> packages that I built from sources due to security requirements.
> >>
> >>
> >In the on-going war between Maven and people who want to make Maven do
> >things their way, chalk up another victory for Maven.
> >
> >You entered this battle determined to bend Maven to your will... that is
> >the only surefire way to ensure your defeat by Maven. I suspect the fixing
> >of your issues will involve unwinding a lot of "hard won" battles on your
> >behalf.
> >
> >I humbly suggest that you consider a different build system, as Maven does
> >not share your philosophy, and as such you will only end up hating Maven
> >(when you should be hating yourself for using it against an inappropriate
> >use-case). That way, when you have an appropriate use case for a Maven
> >style build of a project, you will still be open to using Maven for that
> >project.
> >
> >-Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Stop offline mode artifact version renumbering
Posted by "Bahmer, Eric V" <ba...@lanl.gov>.
I didn't pick the build system unfortunately.
I'm just using what came with the productŠ
And cursing their developers for using something that doesn't seem to mesh
with high security environments.
On 7/29/13 8:18 AM, "Stephen Connolly" <st...@gmail.com>
wrote:
>On 29 July 2013 15:04, Bahmer, Eric V <ba...@lanl.gov> wrote:
>
>> I was just hoping that maybe maven could use the local version numbers
>> without renumbering everything as a command line option, especially for
>>my
>> environment where I can't have the maven going online and have to use
>>the
>> packages that I built from sources due to security requirements.
>>
>>
>In the on-going war between Maven and people who want to make Maven do
>things their way, chalk up another victory for Maven.
>
>You entered this battle determined to bend Maven to your will... that is
>the only surefire way to ensure your defeat by Maven. I suspect the fixing
>of your issues will involve unwinding a lot of "hard won" battles on your
>behalf.
>
>I humbly suggest that you consider a different build system, as Maven does
>not share your philosophy, and as such you will only end up hating Maven
>(when you should be hating yourself for using it against an inappropriate
>use-case). That way, when you have an appropriate use case for a Maven
>style build of a project, you will still be open to using Maven for that
>project.
>
>-Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Stop offline mode artifact version renumbering
Posted by Stephen Connolly <st...@gmail.com>.
On 29 July 2013 15:04, Bahmer, Eric V <ba...@lanl.gov> wrote:
> I was just hoping that maybe maven could use the local version numbers
> without renumbering everything as a command line option, especially for my
> environment where I can't have the maven going online and have to use the
> packages that I built from sources due to security requirements.
>
>
In the on-going war between Maven and people who want to make Maven do
things their way, chalk up another victory for Maven.
You entered this battle determined to bend Maven to your will... that is
the only surefire way to ensure your defeat by Maven. I suspect the fixing
of your issues will involve unwinding a lot of "hard won" battles on your
behalf.
I humbly suggest that you consider a different build system, as Maven does
not share your philosophy, and as such you will only end up hating Maven
(when you should be hating yourself for using it against an inappropriate
use-case). That way, when you have an appropriate use case for a Maven
style build of a project, you will still be open to using Maven for that
project.
-Stephen
Re: Stop offline mode artifact version renumbering
Posted by "Bahmer, Eric V" <ba...@lanl.gov>.
The application in question has a java web app which sits between a
message broker service and a database.
There is a plugin that also uses jetty but tries to keep it's own local
copy in it's own lib subdirectory.
When I replace the version number in the parent pom of the main project it
fixes that jetty-start issue.
And if I want to build the plugin, I do the same to it's pom file.
So I'm fairly sure the 7.5.3 number is coming from the top level project
specifically as it's the only piece of software on the system where that
version string is defined.
I'm building on a RHEL6 based system, and I initially had to force an
install of maven and a bunch of dependencies from a fedora17 branch onto
a test system since it wasn't in the EPEL repo.
I then used that machine to recompile all those rpms from sources to have
a RHEL6 native install.
Since I built, and where necessary patched all those packages myself, I
trust that none of them are calling for jetty-7.5.3, however I do know
that a couple other transitives were giving me trouble, and I added a
custom depmap to the project as well as defining a common local repo in
the build directory for the project to use.
Without the local repo defined all the sub-packages used their own local
repo and later subs couldn't find the earlier jars it needed as
requirements.
One of the framework dependencies was attempting to call both
servlet-api-2.5 and servlet-api-3.0 which, and this is odd, but even
though nearly everything else depends on 3.0, it kept taking 2.5 instead.
And even when I had fixed the top level pom to specifically take 3.0 (as
jetty-8 needs 3.0, it would rename 2.5 to 3.0 and cause the app to fail.
I ended up removing tomcat6 entirely from the system and substituting a
later fedora rpm jboss-servlet-api-2.5 which rebundles the 2.5 apis and
rebuilt the package that kept trying to pull in the wrong version
(resteasy or spring framework) to use that instead of the earlier tomcat.
I was just hoping that maybe maven could use the local version numbers
without renumbering everything as a command line option, especially for my
environment where I can't have the maven going online and have to use the
packages that I built from sources due to security requirements.
On 7/28/13 1:59 PM, "Ziga GREGORIC" <zi...@gmail.com> wrote:
>Hi Eric,
>
>Not sure if I got you either, but see if this can help you out.
>
>Where is the jetty with 'unwanted' version coming from? Use mvn
>dependency:tree, but don't completely rely on results, as it is broken
>(there's an issue on this in jira) and you might find the artifact, that
>adds the wrong jetty as transitive dependency. For this artifact, add
>jetty
>to excludes (in your pom - don't manipulate jetty poms). In case something
>from jetty is now missing, add it in dependecies explicitly.
>
>Another approach, which is easier but might not always work is to define
>add dependencyManagement section and specify there all jetty versions you
>want to use.
>
>Forcing maven into taking what you have in the local repo by manipulating
>local repo xml's scares me off. I'd trust pom.xml's of my project,
>fine-tune it, test with -o on another box.
>
>Ziga
>
>
>On Sat, Jul 27, 2013 at 3:48 AM, Ron Wheeler
><rwheeler@artifact-software.com
>> wrote:
>
>> I am not sure that I understand the problem but will version ranges in
>> dependency specifications help?
>>
>> Ron
>>
>>
>>
>> On 26/07/2013 12:01 PM, Bahmer, Eric V wrote:
>>
>>> I've searched through a few years archives of the mailing list and
>>>can't
>>> seem to find an answer to an issue that's been bugging me for a while
>>>now.
>>>
>>> We've been using a highly customized third-party application for a
>>>while
>>> now and are looking to upgrade to a newer version.
>>> The new version uses maven for part of it's build process.
>>> I work in an environment that for SECURITY reasons I must run my build
>>>in
>>> OFFLINE mode.
>>> I have already rebuilt over 600 rpms to have all the necessary
>>> dependencies available locally.
>>>
>>> The problem I'm having is this:
>>>
>>> The project uses jetty, it calls for version 7.5.3 to be used, I have a
>>> patched 8.1.0 installed.
>>> Maven will resolve jetty correctly, however one of the jetty jars will
>>> end up with it's version number altered in the distribution.
>>>
>>> jetty-server-8.1.0.v20120127.**jar
>>> jetty-servlet-8.1.0.v20120127.**jar
>>> jetty-start-7.5.3.v20111011.**jar
>>>
>>> This will not work as jetty-start reads it's own filename string and
>>> attempts to load other jetty jars with the same version string.
>>>
>>> I can get around the problem by replacing the jetty version number
>>> <version.jetty> tag in the parent pom, which will make jetty-start
>>>have the
>>> same 8.1.0 version number.
>>>
>>> However, jetty isn't the only jar that this is happening to.
>>> The overall project which isn't entirely java has a few sub-projects
>>> built separately exhibiting this same behavior and I would rather avoid
>>> replacing every version number in every pom or adding them if they
>>>don't
>>> have them just so that all related packages like jetty, spring, or
>>>resteasy
>>> have matching version numbers.
>>> I also don't want several copies of the same jar with different
>>>filenames
>>> because the version number is different for the sub-projects.
>>> Otherwise I have to put a bunch of ugly loops in my rpm spec file to
>>> clean up both before the build and after.
>>>
>>> Is there a way to force resolution of my locally installed version
>>> numbers and NOT rename the jar files to an incorrect version number?
>>>I've
>>> already tried the versions plugin, the dependency plugin, -U,
>>> -Dmaven.ignore.versions as well as combinations of them all.
>>>
>>> I repeat that I have all necessary dependencies locally installed for
>>> offline build. I know my versions work. I want maven to ignore what the
>>> poms say about version and take the version number from what I have
>>> installed.
>>>
>>>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>------------------------------**------------------------------**---------
>> 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
For additional commands, e-mail: users-help@maven.apache.org
Re: Stop offline mode artifact version renumbering
Posted by Ziga GREGORIC <zi...@gmail.com>.
Hi Eric,
Not sure if I got you either, but see if this can help you out.
Where is the jetty with 'unwanted' version coming from? Use mvn
dependency:tree, but don't completely rely on results, as it is broken
(there's an issue on this in jira) and you might find the artifact, that
adds the wrong jetty as transitive dependency. For this artifact, add jetty
to excludes (in your pom - don't manipulate jetty poms). In case something
from jetty is now missing, add it in dependecies explicitly.
Another approach, which is easier but might not always work is to define
add dependencyManagement section and specify there all jetty versions you
want to use.
Forcing maven into taking what you have in the local repo by manipulating
local repo xml's scares me off. I'd trust pom.xml's of my project,
fine-tune it, test with -o on another box.
Ziga
On Sat, Jul 27, 2013 at 3:48 AM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> I am not sure that I understand the problem but will version ranges in
> dependency specifications help?
>
> Ron
>
>
>
> On 26/07/2013 12:01 PM, Bahmer, Eric V wrote:
>
>> I've searched through a few years archives of the mailing list and can't
>> seem to find an answer to an issue that's been bugging me for a while now.
>>
>> We've been using a highly customized third-party application for a while
>> now and are looking to upgrade to a newer version.
>> The new version uses maven for part of it's build process.
>> I work in an environment that for SECURITY reasons I must run my build in
>> OFFLINE mode.
>> I have already rebuilt over 600 rpms to have all the necessary
>> dependencies available locally.
>>
>> The problem I'm having is this:
>>
>> The project uses jetty, it calls for version 7.5.3 to be used, I have a
>> patched 8.1.0 installed.
>> Maven will resolve jetty correctly, however one of the jetty jars will
>> end up with it's version number altered in the distribution.
>>
>> jetty-server-8.1.0.v20120127.**jar
>> jetty-servlet-8.1.0.v20120127.**jar
>> jetty-start-7.5.3.v20111011.**jar
>>
>> This will not work as jetty-start reads it's own filename string and
>> attempts to load other jetty jars with the same version string.
>>
>> I can get around the problem by replacing the jetty version number
>> <version.jetty> tag in the parent pom, which will make jetty-start have the
>> same 8.1.0 version number.
>>
>> However, jetty isn't the only jar that this is happening to.
>> The overall project which isn't entirely java has a few sub-projects
>> built separately exhibiting this same behavior and I would rather avoid
>> replacing every version number in every pom or adding them if they don't
>> have them just so that all related packages like jetty, spring, or resteasy
>> have matching version numbers.
>> I also don't want several copies of the same jar with different filenames
>> because the version number is different for the sub-projects.
>> Otherwise I have to put a bunch of ugly loops in my rpm spec file to
>> clean up both before the build and after.
>>
>> Is there a way to force resolution of my locally installed version
>> numbers and NOT rename the jar files to an incorrect version number? I've
>> already tried the versions plugin, the dependency plugin, -U,
>> -Dmaven.ignore.versions as well as combinations of them all.
>>
>> I repeat that I have all necessary dependencies locally installed for
>> offline build. I know my versions work. I want maven to ignore what the
>> poms say about version and take the version number from what I have
>> installed.
>>
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Stop offline mode artifact version renumbering
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am not sure that I understand the problem but will version ranges in
dependency specifications help?
Ron
On 26/07/2013 12:01 PM, Bahmer, Eric V wrote:
> I've searched through a few years archives of the mailing list and can't seem to find an answer to an issue that's been bugging me for a while now.
>
> We've been using a highly customized third-party application for a while now and are looking to upgrade to a newer version.
> The new version uses maven for part of it's build process.
> I work in an environment that for SECURITY reasons I must run my build in OFFLINE mode.
> I have already rebuilt over 600 rpms to have all the necessary dependencies available locally.
>
> The problem I'm having is this:
>
> The project uses jetty, it calls for version 7.5.3 to be used, I have a patched 8.1.0 installed.
> Maven will resolve jetty correctly, however one of the jetty jars will end up with it's version number altered in the distribution.
>
> jetty-server-8.1.0.v20120127.jar
> jetty-servlet-8.1.0.v20120127.jar
> jetty-start-7.5.3.v20111011.jar
>
> This will not work as jetty-start reads it's own filename string and attempts to load other jetty jars with the same version string.
>
> I can get around the problem by replacing the jetty version number <version.jetty> tag in the parent pom, which will make jetty-start have the same 8.1.0 version number.
>
> However, jetty isn't the only jar that this is happening to.
> The overall project which isn't entirely java has a few sub-projects built separately exhibiting this same behavior and I would rather avoid replacing every version number in every pom or adding them if they don't have them just so that all related packages like jetty, spring, or resteasy have matching version numbers.
> I also don't want several copies of the same jar with different filenames because the version number is different for the sub-projects.
> Otherwise I have to put a bunch of ugly loops in my rpm spec file to clean up both before the build and after.
>
> Is there a way to force resolution of my locally installed version numbers and NOT rename the jar files to an incorrect version number? I've already tried the versions plugin, the dependency plugin, -U, -Dmaven.ignore.versions as well as combinations of them all.
>
> I repeat that I have all necessary dependencies locally installed for offline build. I know my versions work. I want maven to ignore what the poms say about version and take the version number from what I have installed.
>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org