Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of bahmer@lanl.gov designates
 204.121.3.52 as permitted sender)
From: "Bahmer, Eric V" <bahmer@lanl.gov>
To: Maven Users List <users@maven.apache.org>
Subject: Re: Stop offline mode artifact version renumbering
Thread-Topic: Stop offline mode artifact version renumbering
Thread-Index: AQHOihljaklbwzQQbUG7g3d2f16NoJl4Jx+AgALDVICAAMpxgA==
Date: Mon, 29 Jul 2013 14:04:32 +0000
Message-ID: <CE1BCD1A.11A9D%bahmer@lanl.gov>
In-Reply-To: 
 <CABJJssOHFe_UoAg6kUgoMNT81o2BnorM=QuoJRK0_j+izh5DKw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F3EA91B88CF49B4DAB2B648C794CAE21@win.lanl.gov>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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" <ziga.gregoric@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
>>
>>
>>=20
>>------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>>users-unsubscribe@maven.**apache.org<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