Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav <be...@rodehav.com>]

We are using maven 3.0.3 and have problems using property values defined in
our local settings.xml for specifying systemPath values for system-scoped
dependencies. It seems this possibility has been removed in maven 3.

The system-scoped variable is necessary because we depend directly on a
third party application server jar file which now has hard coded dependency
jars listed in its MANIFEST. It is simply not practical to install these
(several dozen - perhaps hundreds) jars into our remote Maven repository.

The problem is serious because the pom files which use this system-scoped
dependency do not pass validation when parsed by the reactor, preventing
any transitive dependencies from being resolved in child projects. The
current workaround is to define these properties in our parent pom instead,
but this is not ideal since the values are environment-specific in nature
and should not be hard coded in the pom.

I wonder why this has changed in maven 3 and what then is the best practice
to handle a situation like ours (it must be a common scenario)?

As a side note we actually discovered this on computers running maven 2.2.1
but using m2eclipse. M2eclipse seems to use an embedded snapshot version of
maven 3  for its dependency resolution (we use m2eclipse
12.0.20101115-1102). It has worked perfectly for a long time but just
recently started to exhibit this behaviour. We don't really know what has
triggered this but we are guessing that m2eclipse perhaps updated itself
with a new snapshot version of maven 3 - not really sure have m2eclipse
works regarding this.

I appreciate any help,

/Bengt

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Coy <st...@resolvesw.com>]

On 15/11/2011, at 9:24 PM, Stephen Connolly wrote:

> Actually this is not going to be as big an issue as you think.

hmm

> 
> Keep in mind you are not sucking in _all_ the container's jars into
> your uber jar, only the public ones (unless you are very lazy... in
> which case you're going to have problems anyway)
> 
> The container's classloaders should look something a bit like
> 
> System -> Common -> Server
>                     \-> Your App
> 
> Now the above is very simplified, but most JEE containers boil down to
> something like the above.... if your app is an EAR you will have a
> similar fork with the EAR common dependencies in a shared classloader
> and then the EJBs being in one class loader descended from your app's
> common and the WARs being in another classloader(s) descended from
> common.


I know this. I have ten years on JBoss and over 7 years on WebLogic and WebSphere.



> 
> So your app should only be depending on things that are in the App
> Server's Common classloader, i.e. all the javax.* packages for the JEE
> spec the container implements plus the public APIs of the App Server's
> additional extensions.

Yep

> 
> Typically the app server's are reasonably helpful and put their public
> jars in one lib folder separate from the server's internal lib
> folder... but then again there is no need for them to do that at
> all... they should at least call out which jars are safe to depend on
> (i.e. public) somewhere in their docs.

In fact, WebSphere does this very nicely. Unfortunately WebLogic does not. I spent many days on this a couple of years ago. 

> My understanding is that it is
> just the weblogic.jar that you'd want to uber-ize as that is the
> public facing API.

The API that we needed (a Tuxedo client) is buried in one of the "modules" jars, together with it's implementation. And it had OSGI style package dependencies that just exploded as I tried to work my way back out of it. We get it for free indirectly when including weblogic.jar as a system scope dependency through it's manifest classpath.

> 
> You then depend on that uberjar _with_scope_provided_ this is because
> the jar is being provided for you.
> 
> In weblogic, if you want to use a version of xerces that is not the
> one sucked in by weblogic.jar, then you need to configure your app
> with a filtering classloader in any case, so the classpath hell will
> either be there anyway, or you will have to man up and write the
> filtering classloader descriptor anyway. The provided weblogic.jar
> dependency will not have any transitive deps in any case (unless you
> add them yourself) and being scope=provided, it will not be transitive
> itself

We're talking build time dependencies here. WebLogic appears to be using some form of OSGI container that at runtime gives the kind of class visibility behaviour that you would expect.

I agree that the "system" scope is an ugly ugly solution, but in the end one has to be pragmatic. This is the only real use case I've *ever* had for "system" scope. Removing that Maven capability makes working with some WebLogic APIs a trial for the developers that need them. You're right that we could each write a program to analyse the OSGI Import-Package entries (there are no Class-Path entries in the "modules") of the manifest.mf and try and build some kind of uberjar. But really?

All this talk of OSGI makes me wonder if tycho could help somehow.

What do you think?

Steve C

* Incidentally, we never package xerces and friends in our EAR or WAR files. We stick to the standard javax.xml apis and use whatever implementation is provided by the container. That has always been a recipe for trouble. If you're building WAR files and deploying only to a servlet container then YMMV.



> 
> -Stephen
> 
> On 15 November 2011 09:27, Nord, James <JN...@nds.com> wrote:
>> Not that I am needing to do this but in order to further my understanding...
>> 
>> If you create an Uber JAR - then you can end up in classpath hell - as the dependencies aren't correct (it could include common-io 1.2 and you need commons-io 1.3 which is declared transitively)  This then means that even though you don't depend on commons-io you need to start adding all transitive dependencies to your pom just incase the app server ships with a different one and the uber jar takes precedence over the transitive dependency.  The J2EE container should allow you to override some bits of the provide jars should they not?
>> 
>> /James
>> 
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: 15 November 2011 08:26
>> To: Maven Users List
>> Subject: Re: Properties in settings.xml does not work for system scoped dependencies
>> 
>> the correct scope for those deps should be provided imho.
>> 
>> the problem you have is getting the deps you need, system scope is just a workaround.
>> 
>> ideally you would create an uberjar from the geologic jar and just install that into your repo manager.
>> 
>> the focus should be on taking a jar and making an uberjar from its manifest classpath... should be easy, then install that uberjar in your repo. forget about identifying which of the 480 odd jars has your dep, when you depend on geologic specific classes, that's what you need.
>> 
>> - Stephen
>> 
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Nov 2011 03:19, "Stephen Coy" <st...@resolvesw.com> wrote:
>> 
>>> Hi there,
>>> 
>>> I've been a maven user since the early 1.0 days and have contributed
>>> patches at various times for the ejb-plugin, ear-plugin and others.
>>> 
>>> I've also had the unfortunate experience of having to use WebLogic 10+
>>> to create useable maven poms for our projects. In fact, when I read
>>> the OP I knew he was talking about Weblogic even though he did not mention it.
>>> 
>>> The *only* way I've been able to do this successfully was with a
>>> system scoped dependency on the weblogic.jar.
>>> 
>>> This is because weblogic contains a maze of relative manifest class
>>> paths that are truly mind boggling.
>>> 
>>> The very first class path entry in weblogic.jar looks like:
>>> 
>>> ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
>>> (plus a dozen or more others)
>>> 
>>> That modules directory contains 465 (very OSGI looking) jars and sub
>>> directories. Do you really think it's practical to install all of
>>> these into a repository manager? How would you generate the
>>> dependencies for each pom?
>>> 
>>> This would not be an issue for any "plain old JEE" application.
>>> However, if you have any need at all for weblogic specific APIs then a
>>> system scoped dependency is the only practical way. Even when you do
>>> figure out which one of those ~500 jars contains your API, you then
>>> need to read it's manifest and pick out its dependencies, and then the dependencies' dependencies, etc.
>>> 
>>> If someone has a simple solution to this then I'd like to hear it too.
>>> Otherwise, *please* restore the system scope functionality.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Steve C
>>> 
>>> 
>>> On 14/11/2011, at 2:55 AM, Benson Margulies wrote:
>>> 
>>>> No possible licensing restriction can prevent you from having your
>>>> own shared repository with nexus or archiva or artifactory and
>>>> pushing whatever you want to it.
>>>> 
>>>> For that matter, it's not too hard to write a script that calls
>>>> install:install-file on each of a pile of jar files. You can't do
>>>> this in the reactor and then use the results (AFAIK), but you can
>>>> run this and then run the build.
>>>> 
>>>> In other words, anything you can do with system scope you can do
>>>> with less headaches with a repo manager or instal:install-file.
>>>> 
>>>> 
>>>> On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com>
>>> wrote:
>>>>> Last time I went through this I never came all the way to a
>>>>> complete
>>> list
>>>>> but I do remember there were lots of jars missing. I guess I'll
>>>>> have to reiterate this again since system scope doesn't seem to be
>>>>> supported anymore.
>>>>> 
>>>>> /Bengt
>>>>> 
>>>>> 2011/11/12 Wayne Fay <wa...@gmail.com>
>>>>> 
>>>>>> What else do you need? Why not full client + some reasonable
>>>>>> (small) handful of other dependencies?
>>>>>> 
>>>>>> Wayne
>>>>>> 
>>>>>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com>
>>> wrote:
>>>>>>> It works but the full client is not enough for us to be able to
>>>>>>> build
>>> our
>>>>>>> application.
>>>>>>> 
>>>>>>> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>>>>>>>> 
>>>>>>>> Does this no longer work?
>>>>>>>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>>>>>>>> On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>>>>>>>> 
>>>>>>>>> Stephen and Wayne,
>>>>>>>>> 
>>>>>>>>> I agree that using system scope is undesirable. However, there
>>>>>>>>> is a
>>>>>>> reason
>>>>>>>>> why maven has had this  support - it is needed in real life. In
>>>>>>>>> my
>>>>>>> case, I
>>>>>>>>> use Weblogic. When first trying to migrate our old ant based
>>>>>>>>> build
>>>>>>> system
>>>>>>>>> to maven, I started out by trying to put the Weblogic jar:s in
>>>>>>>>> the
>>>>>> maven
>>>>>>>>> repo. It just wasn't doable. They have split the big, all
>>>>>> encompassing,
>>>>>>> jar
>>>>>>>>> file from previous versions into hundreds of individual jar
>>>>>>>>> files. I
>>>>>>> gave
>>>>>>>>> up after a while. I guess if I could find a tool that could
>>>>>>>>> convert
>>>>>> all
>>>>>>>>> these jars into one "super jar" then I could put that jar in
>>>>>>>>> the
>>> maven
>>>>>>>>> repo. I'm not sure that Oracle's licensing rules would allow it
>>>>>> though.
>>>>>>>>> 
>>>>>>>>> Dropping support like this because you don't think it's the
>>>>>>>>> best way
>>>>>> to
>>>>>>>>> handle things will not give you a loyal user base. We need to
>>>>>>>>> solve
>>>>>>> these
>>>>>>>>> kind of issues somehow. Before you remove support you must
>>>>>>>>> provide
>>> an
>>>>>>>>> alternate solution. Requiring that hundreds of proprietary jars
>>>>>>>>> have
>>>>>> to
>>>>>>> be
>>>>>>>>> put in the maven repo (and updated each time we upgrade
>>>>>>>>> Weblogic) is
>>>>>>> just
>>>>>>>>> not realistic. I've been searching for a good tool that can
>>>>>>>>> traverse
>>>>>> the
>>>>>>>>> manifest classpath's and create a single jar from all
>>>>>>>>> individual
>>> jars.
>>>>>>> Do
>>>>>>>>> you know of any such tool?
>>>>>>>>> 
>>>>>>>>> The transitive dependency problem is not exactly the way you
>>> describe
>>>>>> it
>>>>>>>>> Stephen. I don't need transitive dependencies from a system
>>>>>>>>> scoped dependency but I want the transitive dependencies to
>>>>>>>>> work up to the
>>>>>>> system
>>>>>>>>> scoped dependency:
>>>>>>>>> 
>>>>>>>>> If A depends on B that depends on S (via a system scoped
>>> dependency),
>>>>>>> then
>>>>>>>>> maven should be able to include S on A's build classpath.
>>>>>>>>> 
>>>>>>>>> The way maven works right now I tend to agree that system
>>>>>>>>> scoped dependencies are useless. This is because their location
>>>>>>>>> must be
>>> hard
>>>>>>> coded
>>>>>>>>> in the POM. Naturally system scoped dependencies reside in
>>>>>>>>> different
>>>>>>> places
>>>>>>>>> in different environments. In our case it resides where the
>>>>>>>>> user has installed Weblogic.
>>>>>>>>> 
>>>>>>>>> /Bengt
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2011/11/11 Stephen Connolly <st...@gmail.com>
>>>>>>>>> 
>>>>>>>>>> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>>>>>>>>>>>> System scoped dependencies are dead. Ignore their zombie
>>>>>>>>>>>> like
>>>>>>> walking
>>>>>>>>>>>> about. Stop fighting maven and just install the jars into a
>>>>>>>>>>>> repo
>>>>>>>>>>> 
>>>>>>>>>>> I agree, but shouldn't we kill system entirely at some point
>>>>>>>>>>> (I
>>>>>> mean
>>>>>>>>>>> in the code) -- if we see a system-scoped dependency, we just
>>>>>>>>>>> fail
>>>>>>> the
>>>>>>>>>>> build with an appropriate error message? It is a dead concept
>>>>>>>>>>> IMO
>>>>>>> and
>>>>>>>>>>> is simply confusing to users who try to use it.
>>>>>>>>>> 
>>>>>>>>>> Yes I agree... but lets get 3.0.4 out first ;-)
>>>>>>>>>> 
>>>>>>>>>> To answer the OP
>>>>>>>>>> 
>>>>>>>>>> Think of it like this, when you specify a "system" scope
>>>>>>>>>> dependency then you are stating that the system is responsible
>>>>>>>>>> for providing
>>>>>> that
>>>>>>>>>> dependency _and_ all its dependencies -> transitive stops at
>>>>>>>>>> system
>>>>>>>>>> 
>>>>>>>>>> Similarly, with provided scope, you are saying that somebody
>>>>>>>>>> else
>>> is
>>>>>>>>>> taking care of providing that dependency at run time, and so
>>>>>> therefore
>>>>>>>>>> maven doesn't have to worry about it or its dependencies.
>>>>>>>>>>> 
>>>>>>>>>>> Wayne
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> - 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
>>> 
>>> 
>> 
>> 
>> **************************************************************************************
>> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>> 
>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
>> **************************************************************************************
>> 
>> ---------------------------------------------------------------------
>> 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: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly <st...@gmail.com>]

Actually this is not going to be as big an issue as you think.

Keep in mind you are not sucking in _all_ the container's jars into
your uber jar, only the public ones (unless you are very lazy... in
which case you're going to have problems anyway)

The container's classloaders should look something a bit like

System -> Common -> Server
                     \-> Your App

Now the above is very simplified, but most JEE containers boil down to
something like the above.... if your app is an EAR you will have a
similar fork with the EAR common dependencies in a shared classloader
and then the EJBs being in one class loader descended from your app's
common and the WARs being in another classloader(s) descended from
common.

So your app should only be depending on things that are in the App
Server's Common classloader, i.e. all the javax.* packages for the JEE
spec the container implements plus the public APIs of the App Server's
additional extensions.

Typically the app server's are reasonably helpful and put their public
jars in one lib folder separate from the server's internal lib
folder... but then again there is no need for them to do that at
all... they should at least call out which jars are safe to depend on
(i.e. public) somewhere in their docs. My understanding is that it is
just the weblogic.jar that you'd want to uber-ize as that is the
public facing API.

You then depend on that uberjar _with_scope_provided_ this is because
the jar is being provided for you.

In weblogic, if you want to use a version of xerces that is not the
one sucked in by weblogic.jar, then you need to configure your app
with a filtering classloader in any case, so the classpath hell will
either be there anyway, or you will have to man up and write the
filtering classloader descriptor anyway. The provided weblogic.jar
dependency will not have any transitive deps in any case (unless you
add them yourself) and being scope=provided, it will not be transitive
itself

-Stephen

On 15 November 2011 09:27, Nord, James <JN...@nds.com> wrote:
> Not that I am needing to do this but in order to further my understanding...
>
> If you create an Uber JAR - then you can end up in classpath hell - as the dependencies aren't correct (it could include common-io 1.2 and you need commons-io 1.3 which is declared transitively)  This then means that even though you don't depend on commons-io you need to start adding all transitive dependencies to your pom just incase the app server ships with a different one and the uber jar takes precedence over the transitive dependency.  The J2EE container should allow you to override some bits of the provide jars should they not?
>
> /James
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: 15 November 2011 08:26
> To: Maven Users List
> Subject: Re: Properties in settings.xml does not work for system scoped dependencies
>
> the correct scope for those deps should be provided imho.
>
> the problem you have is getting the deps you need, system scope is just a workaround.
>
> ideally you would create an uberjar from the geologic jar and just install that into your repo manager.
>
> the focus should be on taking a jar and making an uberjar from its manifest classpath... should be easy, then install that uberjar in your repo. forget about identifying which of the 480 odd jars has your dep, when you depend on geologic specific classes, that's what you need.
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Nov 2011 03:19, "Stephen Coy" <st...@resolvesw.com> wrote:
>
>> Hi there,
>>
>> I've been a maven user since the early 1.0 days and have contributed
>> patches at various times for the ejb-plugin, ear-plugin and others.
>>
>> I've also had the unfortunate experience of having to use WebLogic 10+
>> to create useable maven poms for our projects. In fact, when I read
>> the OP I knew he was talking about Weblogic even though he did not mention it.
>>
>> The *only* way I've been able to do this successfully was with a
>> system scoped dependency on the weblogic.jar.
>>
>> This is because weblogic contains a maze of relative manifest class
>> paths that are truly mind boggling.
>>
>> The very first class path entry in weblogic.jar looks like:
>>
>> ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
>> (plus a dozen or more others)
>>
>> That modules directory contains 465 (very OSGI looking) jars and sub
>> directories. Do you really think it's practical to install all of
>> these into a repository manager? How would you generate the
>> dependencies for each pom?
>>
>> This would not be an issue for any "plain old JEE" application.
>> However, if you have any need at all for weblogic specific APIs then a
>> system scoped dependency is the only practical way. Even when you do
>> figure out which one of those ~500 jars contains your API, you then
>> need to read it's manifest and pick out its dependencies, and then the dependencies' dependencies, etc.
>>
>> If someone has a simple solution to this then I'd like to hear it too.
>> Otherwise, *please* restore the system scope functionality.
>>
>>
>> Cheers,
>>
>> Steve C
>>
>>
>> On 14/11/2011, at 2:55 AM, Benson Margulies wrote:
>>
>> > No possible licensing restriction can prevent you from having your
>> > own shared repository with nexus or archiva or artifactory and
>> > pushing whatever you want to it.
>> >
>> > For that matter, it's not too hard to write a script that calls
>> > install:install-file on each of a pile of jar files. You can't do
>> > this in the reactor and then use the results (AFAIK), but you can
>> > run this and then run the build.
>> >
>> > In other words, anything you can do with system scope you can do
>> > with less headaches with a repo manager or instal:install-file.
>> >
>> >
>> > On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com>
>> wrote:
>> >> Last time I went through this I never came all the way to a
>> >> complete
>> list
>> >> but I do remember there were lots of jars missing. I guess I'll
>> >> have to reiterate this again since system scope doesn't seem to be
>> >> supported anymore.
>> >>
>> >> /Bengt
>> >>
>> >> 2011/11/12 Wayne Fay <wa...@gmail.com>
>> >>
>> >>> What else do you need? Why not full client + some reasonable
>> >>> (small) handful of other dependencies?
>> >>>
>> >>> Wayne
>> >>>
>> >>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com>
>> wrote:
>> >>>> It works but the full client is not enough for us to be able to
>> >>>> build
>> our
>> >>>> application.
>> >>>>
>> >>>> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>> >>>>>
>> >>>>> Does this no longer work?
>> >>>>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>> >>>>> On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>> >>>>>
>> >>>>>> Stephen and Wayne,
>> >>>>>>
>> >>>>>> I agree that using system scope is undesirable. However, there
>> >>>>>> is a
>> >>>> reason
>> >>>>>> why maven has had this  support - it is needed in real life. In
>> >>>>>> my
>> >>>> case, I
>> >>>>>> use Weblogic. When first trying to migrate our old ant based
>> >>>>>> build
>> >>>> system
>> >>>>>> to maven, I started out by trying to put the Weblogic jar:s in
>> >>>>>> the
>> >>> maven
>> >>>>>> repo. It just wasn't doable. They have split the big, all
>> >>> encompassing,
>> >>>> jar
>> >>>>>> file from previous versions into hundreds of individual jar
>> >>>>>> files. I
>> >>>> gave
>> >>>>>> up after a while. I guess if I could find a tool that could
>> >>>>>> convert
>> >>> all
>> >>>>>> these jars into one "super jar" then I could put that jar in
>> >>>>>> the
>> maven
>> >>>>>> repo. I'm not sure that Oracle's licensing rules would allow it
>> >>> though.
>> >>>>>>
>> >>>>>> Dropping support like this because you don't think it's the
>> >>>>>> best way
>> >>> to
>> >>>>>> handle things will not give you a loyal user base. We need to
>> >>>>>> solve
>> >>>> these
>> >>>>>> kind of issues somehow. Before you remove support you must
>> >>>>>> provide
>> an
>> >>>>>> alternate solution. Requiring that hundreds of proprietary jars
>> >>>>>> have
>> >>> to
>> >>>> be
>> >>>>>> put in the maven repo (and updated each time we upgrade
>> >>>>>> Weblogic) is
>> >>>> just
>> >>>>>> not realistic. I've been searching for a good tool that can
>> >>>>>> traverse
>> >>> the
>> >>>>>> manifest classpath's and create a single jar from all
>> >>>>>> individual
>> jars.
>> >>>> Do
>> >>>>>> you know of any such tool?
>> >>>>>>
>> >>>>>> The transitive dependency problem is not exactly the way you
>> describe
>> >>> it
>> >>>>>> Stephen. I don't need transitive dependencies from a system
>> >>>>>> scoped dependency but I want the transitive dependencies to
>> >>>>>> work up to the
>> >>>> system
>> >>>>>> scoped dependency:
>> >>>>>>
>> >>>>>> If A depends on B that depends on S (via a system scoped
>> dependency),
>> >>>> then
>> >>>>>> maven should be able to include S on A's build classpath.
>> >>>>>>
>> >>>>>> The way maven works right now I tend to agree that system
>> >>>>>> scoped dependencies are useless. This is because their location
>> >>>>>> must be
>> hard
>> >>>> coded
>> >>>>>> in the POM. Naturally system scoped dependencies reside in
>> >>>>>> different
>> >>>> places
>> >>>>>> in different environments. In our case it resides where the
>> >>>>>> user has installed Weblogic.
>> >>>>>>
>> >>>>>> /Bengt
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 2011/11/11 Stephen Connolly <st...@gmail.com>
>> >>>>>>
>> >>>>>>> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>> >>>>>>>>> System scoped dependencies are dead. Ignore their zombie
>> >>>>>>>>> like
>> >>>> walking
>> >>>>>>>>> about. Stop fighting maven and just install the jars into a
>> >>>>>>>>> repo
>> >>>>>>>>
>> >>>>>>>> I agree, but shouldn't we kill system entirely at some point
>> >>>>>>>> (I
>> >>> mean
>> >>>>>>>> in the code) -- if we see a system-scoped dependency, we just
>> >>>>>>>> fail
>> >>>> the
>> >>>>>>>> build with an appropriate error message? It is a dead concept
>> >>>>>>>> IMO
>> >>>> and
>> >>>>>>>> is simply confusing to users who try to use it.
>> >>>>>>>
>> >>>>>>> Yes I agree... but lets get 3.0.4 out first ;-)
>> >>>>>>>
>> >>>>>>> To answer the OP
>> >>>>>>>
>> >>>>>>> Think of it like this, when you specify a "system" scope
>> >>>>>>> dependency then you are stating that the system is responsible
>> >>>>>>> for providing
>> >>> that
>> >>>>>>> dependency _and_ all its dependencies -> transitive stops at
>> >>>>>>> system
>> >>>>>>>
>> >>>>>>> Similarly, with provided scope, you are saying that somebody
>> >>>>>>> else
>> is
>> >>>>>>> taking care of providing that dependency at run time, and so
>> >>> therefore
>> >>>>>>> maven doesn't have to worry about it or its dependencies.
>> >>>>>>>>
>> >>>>>>>> Wayne
>> >>>>>>>>
>> >>>>>>>>
>> >>>> -----------------------------------------------------------------
>> >>>> ----
>> >>>>>>>> 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
>> >>>
>> >>>
>> >>
>> >
>> > --------------------------------------------------------------------
>> > - 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
>>
>>
>
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
> ---------------------------------------------------------------------
> 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: Properties in settings.xml does not work for system scoped dependencies

["Nord, James" <JN...@nds.com>]

Not that I am needing to do this but in order to further my understanding...

If you create an Uber JAR - then you can end up in classpath hell - as the dependencies aren't correct (it could include common-io 1.2 and you need commons-io 1.3 which is declared transitively)  This then means that even though you don't depend on commons-io you need to start adding all transitive dependencies to your pom just incase the app server ships with a different one and the uber jar takes precedence over the transitive dependency.  The J2EE container should allow you to override some bits of the provide jars should they not?

/James

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: 15 November 2011 08:26
To: Maven Users List
Subject: Re: Properties in settings.xml does not work for system scoped dependencies

the correct scope for those deps should be provided imho.

the problem you have is getting the deps you need, system scope is just a workaround.

ideally you would create an uberjar from the geologic jar and just install that into your repo manager.

the focus should be on taking a jar and making an uberjar from its manifest classpath... should be easy, then install that uberjar in your repo. forget about identifying which of the 480 odd jars has your dep, when you depend on geologic specific classes, that's what you need.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Nov 2011 03:19, "Stephen Coy" <st...@resolvesw.com> wrote:

> Hi there,
>
> I've been a maven user since the early 1.0 days and have contributed
> patches at various times for the ejb-plugin, ear-plugin and others.
>
> I've also had the unfortunate experience of having to use WebLogic 10+
> to create useable maven poms for our projects. In fact, when I read
> the OP I knew he was talking about Weblogic even though he did not mention it.
>
> The *only* way I've been able to do this successfully was with a
> system scoped dependency on the weblogic.jar.
>
> This is because weblogic contains a maze of relative manifest class
> paths that are truly mind boggling.
>
> The very first class path entry in weblogic.jar looks like:
>
> ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
> (plus a dozen or more others)
>
> That modules directory contains 465 (very OSGI looking) jars and sub
> directories. Do you really think it's practical to install all of
> these into a repository manager? How would you generate the
> dependencies for each pom?
>
> This would not be an issue for any "plain old JEE" application.
> However, if you have any need at all for weblogic specific APIs then a
> system scoped dependency is the only practical way. Even when you do
> figure out which one of those ~500 jars contains your API, you then
> need to read it's manifest and pick out its dependencies, and then the dependencies' dependencies, etc.
>
> If someone has a simple solution to this then I'd like to hear it too.
> Otherwise, *please* restore the system scope functionality.
>
>
> Cheers,
>
> Steve C
>
>
> On 14/11/2011, at 2:55 AM, Benson Margulies wrote:
>
> > No possible licensing restriction can prevent you from having your
> > own shared repository with nexus or archiva or artifactory and
> > pushing whatever you want to it.
> >
> > For that matter, it's not too hard to write a script that calls
> > install:install-file on each of a pile of jar files. You can't do
> > this in the reactor and then use the results (AFAIK), but you can
> > run this and then run the build.
> >
> > In other words, anything you can do with system scope you can do
> > with less headaches with a repo manager or instal:install-file.
> >
> >
> > On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >> Last time I went through this I never came all the way to a
> >> complete
> list
> >> but I do remember there were lots of jars missing. I guess I'll
> >> have to reiterate this again since system scope doesn't seem to be
> >> supported anymore.
> >>
> >> /Bengt
> >>
> >> 2011/11/12 Wayne Fay <wa...@gmail.com>
> >>
> >>> What else do you need? Why not full client + some reasonable
> >>> (small) handful of other dependencies?
> >>>
> >>> Wayne
> >>>
> >>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >>>> It works but the full client is not enough for us to be able to
> >>>> build
> our
> >>>> application.
> >>>>
> >>>> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
> >>>>>
> >>>>> Does this no longer work?
> >>>>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
> >>>>> On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
> >>>>>
> >>>>>> Stephen and Wayne,
> >>>>>>
> >>>>>> I agree that using system scope is undesirable. However, there
> >>>>>> is a
> >>>> reason
> >>>>>> why maven has had this  support - it is needed in real life. In
> >>>>>> my
> >>>> case, I
> >>>>>> use Weblogic. When first trying to migrate our old ant based
> >>>>>> build
> >>>> system
> >>>>>> to maven, I started out by trying to put the Weblogic jar:s in
> >>>>>> the
> >>> maven
> >>>>>> repo. It just wasn't doable. They have split the big, all
> >>> encompassing,
> >>>> jar
> >>>>>> file from previous versions into hundreds of individual jar
> >>>>>> files. I
> >>>> gave
> >>>>>> up after a while. I guess if I could find a tool that could
> >>>>>> convert
> >>> all
> >>>>>> these jars into one "super jar" then I could put that jar in
> >>>>>> the
> maven
> >>>>>> repo. I'm not sure that Oracle's licensing rules would allow it
> >>> though.
> >>>>>>
> >>>>>> Dropping support like this because you don't think it's the
> >>>>>> best way
> >>> to
> >>>>>> handle things will not give you a loyal user base. We need to
> >>>>>> solve
> >>>> these
> >>>>>> kind of issues somehow. Before you remove support you must
> >>>>>> provide
> an
> >>>>>> alternate solution. Requiring that hundreds of proprietary jars
> >>>>>> have
> >>> to
> >>>> be
> >>>>>> put in the maven repo (and updated each time we upgrade
> >>>>>> Weblogic) is
> >>>> just
> >>>>>> not realistic. I've been searching for a good tool that can
> >>>>>> traverse
> >>> the
> >>>>>> manifest classpath's and create a single jar from all
> >>>>>> individual
> jars.
> >>>> Do
> >>>>>> you know of any such tool?
> >>>>>>
> >>>>>> The transitive dependency problem is not exactly the way you
> describe
> >>> it
> >>>>>> Stephen. I don't need transitive dependencies from a system
> >>>>>> scoped dependency but I want the transitive dependencies to
> >>>>>> work up to the
> >>>> system
> >>>>>> scoped dependency:
> >>>>>>
> >>>>>> If A depends on B that depends on S (via a system scoped
> dependency),
> >>>> then
> >>>>>> maven should be able to include S on A's build classpath.
> >>>>>>
> >>>>>> The way maven works right now I tend to agree that system
> >>>>>> scoped dependencies are useless. This is because their location
> >>>>>> must be
> hard
> >>>> coded
> >>>>>> in the POM. Naturally system scoped dependencies reside in
> >>>>>> different
> >>>> places
> >>>>>> in different environments. In our case it resides where the
> >>>>>> user has installed Weblogic.
> >>>>>>
> >>>>>> /Bengt
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2011/11/11 Stephen Connolly <st...@gmail.com>
> >>>>>>
> >>>>>>> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> >>>>>>>>> System scoped dependencies are dead. Ignore their zombie
> >>>>>>>>> like
> >>>> walking
> >>>>>>>>> about. Stop fighting maven and just install the jars into a
> >>>>>>>>> repo
> >>>>>>>>
> >>>>>>>> I agree, but shouldn't we kill system entirely at some point
> >>>>>>>> (I
> >>> mean
> >>>>>>>> in the code) -- if we see a system-scoped dependency, we just
> >>>>>>>> fail
> >>>> the
> >>>>>>>> build with an appropriate error message? It is a dead concept
> >>>>>>>> IMO
> >>>> and
> >>>>>>>> is simply confusing to users who try to use it.
> >>>>>>>
> >>>>>>> Yes I agree... but lets get 3.0.4 out first ;-)
> >>>>>>>
> >>>>>>> To answer the OP
> >>>>>>>
> >>>>>>> Think of it like this, when you specify a "system" scope
> >>>>>>> dependency then you are stating that the system is responsible
> >>>>>>> for providing
> >>> that
> >>>>>>> dependency _and_ all its dependencies -> transitive stops at
> >>>>>>> system
> >>>>>>>
> >>>>>>> Similarly, with provided scope, you are saying that somebody
> >>>>>>> else
> is
> >>>>>>> taking care of providing that dependency at run time, and so
> >>> therefore
> >>>>>>> maven doesn't have to worry about it or its dependencies.
> >>>>>>>>
> >>>>>>>> Wayne
> >>>>>>>>
> >>>>>>>>
> >>>> -----------------------------------------------------------------
> >>>> ----
> >>>>>>>> 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
> >>>
> >>>
> >>
> >
> > --------------------------------------------------------------------
> > - 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
>
>


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly <st...@gmail.com>]

the correct scope for those deps should be provided imho.

the problem you have is getting the deps you need, system scope is just a
workaround.

ideally you would create an uberjar from the geologic jar and just install
that into your repo manager.

the focus should be on taking a jar and making an uberjar from its manifest
classpath... should be easy, then install that uberjar in your repo. forget
about identifying which of the 480 odd jars has your dep, when you depend
on geologic specific classes, that's what you need.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 15 Nov 2011 03:19, "Stephen Coy" <st...@resolvesw.com> wrote:

> Hi there,
>
> I've been a maven user since the early 1.0 days and have contributed
> patches at various times for the ejb-plugin, ear-plugin and others.
>
> I've also had the unfortunate experience of having to use WebLogic 10+ to
> create useable maven poms for our projects. In fact, when I read the OP I
> knew he was talking about Weblogic even though he did not mention it.
>
> The *only* way I've been able to do this successfully was with a system
> scoped dependency on the weblogic.jar.
>
> This is because weblogic contains a maze of relative manifest class paths
> that are truly mind boggling.
>
> The very first class path entry in weblogic.jar looks like:
>
> ../../../modules/features/weblogic.server.modules_10.3.5.0.jar
> (plus a dozen or more others)
>
> That modules directory contains 465 (very OSGI looking) jars and sub
> directories. Do you really think it's practical to install all of these
> into a repository manager? How would you generate the dependencies for each
> pom?
>
> This would not be an issue for any "plain old JEE" application. However,
> if you have any need at all for weblogic specific APIs then a system scoped
> dependency is the only practical way. Even when you do figure out which one
> of those ~500 jars contains your API, you then need to read it's manifest
> and pick out its dependencies, and then the dependencies' dependencies, etc.
>
> If someone has a simple solution to this then I'd like to hear it too.
> Otherwise, *please* restore the system scope functionality.
>
>
> Cheers,
>
> Steve C
>
>
> On 14/11/2011, at 2:55 AM, Benson Margulies wrote:
>
> > No possible licensing restriction can prevent you from having your own
> > shared repository with nexus or archiva or artifactory and pushing
> > whatever you want to it.
> >
> > For that matter, it's not too hard to write a script that calls
> > install:install-file on each of a pile of jar files. You can't do this
> > in the reactor and then use the results (AFAIK), but you can run this
> > and then run the build.
> >
> > In other words, anything you can do with system scope you can do with
> > less headaches with a repo manager or instal:install-file.
> >
> >
> > On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >> Last time I went through this I never came all the way to a complete
> list
> >> but I do remember there were lots of jars missing. I guess I'll have to
> >> reiterate this again since system scope doesn't seem to be supported
> >> anymore.
> >>
> >> /Bengt
> >>
> >> 2011/11/12 Wayne Fay <wa...@gmail.com>
> >>
> >>> What else do you need? Why not full client + some reasonable (small)
> >>> handful of other dependencies?
> >>>
> >>> Wayne
> >>>
> >>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >>>> It works but the full client is not enough for us to be able to build
> our
> >>>> application.
> >>>>
> >>>> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
> >>>>>
> >>>>> Does this no longer work?
> >>>>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
> >>>>> On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
> >>>>>
> >>>>>> Stephen and Wayne,
> >>>>>>
> >>>>>> I agree that using system scope is undesirable. However, there is a
> >>>> reason
> >>>>>> why maven has had this  support - it is needed in real life. In my
> >>>> case, I
> >>>>>> use Weblogic. When first trying to migrate our old ant based build
> >>>> system
> >>>>>> to maven, I started out by trying to put the Weblogic jar:s in the
> >>> maven
> >>>>>> repo. It just wasn't doable. They have split the big, all
> >>> encompassing,
> >>>> jar
> >>>>>> file from previous versions into hundreds of individual jar files. I
> >>>> gave
> >>>>>> up after a while. I guess if I could find a tool that could convert
> >>> all
> >>>>>> these jars into one "super jar" then I could put that jar in the
> maven
> >>>>>> repo. I'm not sure that Oracle's licensing rules would allow it
> >>> though.
> >>>>>>
> >>>>>> Dropping support like this because you don't think it's the best way
> >>> to
> >>>>>> handle things will not give you a loyal user base. We need to solve
> >>>> these
> >>>>>> kind of issues somehow. Before you remove support you must provide
> an
> >>>>>> alternate solution. Requiring that hundreds of proprietary jars have
> >>> to
> >>>> be
> >>>>>> put in the maven repo (and updated each time we upgrade Weblogic) is
> >>>> just
> >>>>>> not realistic. I've been searching for a good tool that can traverse
> >>> the
> >>>>>> manifest classpath's and create a single jar from all individual
> jars.
> >>>> Do
> >>>>>> you know of any such tool?
> >>>>>>
> >>>>>> The transitive dependency problem is not exactly the way you
> describe
> >>> it
> >>>>>> Stephen. I don't need transitive dependencies from a system scoped
> >>>>>> dependency but I want the transitive dependencies to work up to the
> >>>> system
> >>>>>> scoped dependency:
> >>>>>>
> >>>>>> If A depends on B that depends on S (via a system scoped
> dependency),
> >>>> then
> >>>>>> maven should be able to include S on A's build classpath.
> >>>>>>
> >>>>>> The way maven works right now I tend to agree that system scoped
> >>>>>> dependencies are useless. This is because their location must be
> hard
> >>>> coded
> >>>>>> in the POM. Naturally system scoped dependencies reside in different
> >>>> places
> >>>>>> in different environments. In our case it resides where the user has
> >>>>>> installed Weblogic.
> >>>>>>
> >>>>>> /Bengt
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2011/11/11 Stephen Connolly <st...@gmail.com>
> >>>>>>
> >>>>>>> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> >>>>>>>>> System scoped dependencies are dead. Ignore their zombie like
> >>>> walking
> >>>>>>>>> about. Stop fighting maven and just install the jars into a repo
> >>>>>>>>
> >>>>>>>> I agree, but shouldn't we kill system entirely at some point (I
> >>> mean
> >>>>>>>> in the code) -- if we see a system-scoped dependency, we just fail
> >>>> the
> >>>>>>>> build with an appropriate error message? It is a dead concept IMO
> >>>> and
> >>>>>>>> is simply confusing to users who try to use it.
> >>>>>>>
> >>>>>>> Yes I agree... but lets get 3.0.4 out first ;-)
> >>>>>>>
> >>>>>>> To answer the OP
> >>>>>>>
> >>>>>>> Think of it like this, when you specify a "system" scope dependency
> >>>>>>> then you are stating that the system is responsible for providing
> >>> that
> >>>>>>> dependency _and_ all its dependencies -> transitive stops at system
> >>>>>>>
> >>>>>>> Similarly, with provided scope, you are saying that somebody else
> is
> >>>>>>> taking care of providing that dependency at run time, and so
> >>> therefore
> >>>>>>> maven doesn't have to worry about it or its dependencies.
> >>>>>>>>
> >>>>>>>> Wayne
> >>>>>>>>
> >>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>> 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
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > 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: Properties in settings.xml does not work for system scoped dependencies

[Stephen Coy <st...@resolvesw.com>]

Hi there,

I've been a maven user since the early 1.0 days and have contributed patches at various times for the ejb-plugin, ear-plugin and others.

I've also had the unfortunate experience of having to use WebLogic 10+ to create useable maven poms for our projects. In fact, when I read the OP I knew he was talking about Weblogic even though he did not mention it.

The *only* way I've been able to do this successfully was with a system scoped dependency on the weblogic.jar.

This is because weblogic contains a maze of relative manifest class paths that are truly mind boggling.

The very first class path entry in weblogic.jar looks like:

../../../modules/features/weblogic.server.modules_10.3.5.0.jar
(plus a dozen or more others)

That modules directory contains 465 (very OSGI looking) jars and sub directories. Do you really think it's practical to install all of these into a repository manager? How would you generate the dependencies for each pom?

This would not be an issue for any "plain old JEE" application. However, if you have any need at all for weblogic specific APIs then a system scoped dependency is the only practical way. Even when you do figure out which one of those ~500 jars contains your API, you then need to read it's manifest and pick out its dependencies, and then the dependencies' dependencies, etc.

If someone has a simple solution to this then I'd like to hear it too. Otherwise, *please* restore the system scope functionality.


Cheers,

Steve C


On 14/11/2011, at 2:55 AM, Benson Margulies wrote:

> No possible licensing restriction can prevent you from having your own
> shared repository with nexus or archiva or artifactory and pushing
> whatever you want to it.
> 
> For that matter, it's not too hard to write a script that calls
> install:install-file on each of a pile of jar files. You can't do this
> in the reactor and then use the results (AFAIK), but you can run this
> and then run the build.
> 
> In other words, anything you can do with system scope you can do with
> less headaches with a repo manager or instal:install-file.
> 
> 
> On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com> wrote:
>> Last time I went through this I never came all the way to a complete list
>> but I do remember there were lots of jars missing. I guess I'll have to
>> reiterate this again since system scope doesn't seem to be supported
>> anymore.
>> 
>> /Bengt
>> 
>> 2011/11/12 Wayne Fay <wa...@gmail.com>
>> 
>>> What else do you need? Why not full client + some reasonable (small)
>>> handful of other dependencies?
>>> 
>>> Wayne
>>> 
>>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com> wrote:
>>>> It works but the full client is not enough for us to be able to build our
>>>> application.
>>>> 
>>>> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>>>>> 
>>>>> Does this no longer work?
>>>>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>>>>> On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>>>>> 
>>>>>> Stephen and Wayne,
>>>>>> 
>>>>>> I agree that using system scope is undesirable. However, there is a
>>>> reason
>>>>>> why maven has had this  support - it is needed in real life. In my
>>>> case, I
>>>>>> use Weblogic. When first trying to migrate our old ant based build
>>>> system
>>>>>> to maven, I started out by trying to put the Weblogic jar:s in the
>>> maven
>>>>>> repo. It just wasn't doable. They have split the big, all
>>> encompassing,
>>>> jar
>>>>>> file from previous versions into hundreds of individual jar files. I
>>>> gave
>>>>>> up after a while. I guess if I could find a tool that could convert
>>> all
>>>>>> these jars into one "super jar" then I could put that jar in the maven
>>>>>> repo. I'm not sure that Oracle's licensing rules would allow it
>>> though.
>>>>>> 
>>>>>> Dropping support like this because you don't think it's the best way
>>> to
>>>>>> handle things will not give you a loyal user base. We need to solve
>>>> these
>>>>>> kind of issues somehow. Before you remove support you must provide an
>>>>>> alternate solution. Requiring that hundreds of proprietary jars have
>>> to
>>>> be
>>>>>> put in the maven repo (and updated each time we upgrade Weblogic) is
>>>> just
>>>>>> not realistic. I've been searching for a good tool that can traverse
>>> the
>>>>>> manifest classpath's and create a single jar from all individual jars.
>>>> Do
>>>>>> you know of any such tool?
>>>>>> 
>>>>>> The transitive dependency problem is not exactly the way you describe
>>> it
>>>>>> Stephen. I don't need transitive dependencies from a system scoped
>>>>>> dependency but I want the transitive dependencies to work up to the
>>>> system
>>>>>> scoped dependency:
>>>>>> 
>>>>>> If A depends on B that depends on S (via a system scoped dependency),
>>>> then
>>>>>> maven should be able to include S on A's build classpath.
>>>>>> 
>>>>>> The way maven works right now I tend to agree that system scoped
>>>>>> dependencies are useless. This is because their location must be hard
>>>> coded
>>>>>> in the POM. Naturally system scoped dependencies reside in different
>>>> places
>>>>>> in different environments. In our case it resides where the user has
>>>>>> installed Weblogic.
>>>>>> 
>>>>>> /Bengt
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2011/11/11 Stephen Connolly <st...@gmail.com>
>>>>>> 
>>>>>>> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>>>>>>>>> System scoped dependencies are dead. Ignore their zombie like
>>>> walking
>>>>>>>>> about. Stop fighting maven and just install the jars into a repo
>>>>>>>> 
>>>>>>>> I agree, but shouldn't we kill system entirely at some point (I
>>> mean
>>>>>>>> in the code) -- if we see a system-scoped dependency, we just fail
>>>> the
>>>>>>>> build with an appropriate error message? It is a dead concept IMO
>>>> and
>>>>>>>> is simply confusing to users who try to use it.
>>>>>>> 
>>>>>>> Yes I agree... but lets get 3.0.4 out first ;-)
>>>>>>> 
>>>>>>> To answer the OP
>>>>>>> 
>>>>>>> Think of it like this, when you specify a "system" scope dependency
>>>>>>> then you are stating that the system is responsible for providing
>>> that
>>>>>>> dependency _and_ all its dependencies -> transitive stops at system
>>>>>>> 
>>>>>>> Similarly, with provided scope, you are saying that somebody else is
>>>>>>> taking care of providing that dependency at run time, and so
>>> therefore
>>>>>>> maven doesn't have to worry about it or its dependencies.
>>>>>>>> 
>>>>>>>> Wayne
>>>>>>>> 
>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>> 
>>> 
>> 
> 
> ---------------------------------------------------------------------
> 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: Properties in settings.xml does not work for system scoped dependencies

[Benson Margulies <bi...@gmail.com>]

No possible licensing restriction can prevent you from having your own
shared repository with nexus or archiva or artifactory and pushing
whatever you want to it.

For that matter, it's not too hard to write a script that calls
install:install-file on each of a pile of jar files. You can't do this
in the reactor and then use the results (AFAIK), but you can run this
and then run the build.

In other words, anything you can do with system scope you can do with
less headaches with a repo manager or instal:install-file.


On Sat, Nov 12, 2011 at 8:20 AM, Bengt Rodehav <be...@rodehav.com> wrote:
> Last time I went through this I never came all the way to a complete list
> but I do remember there were lots of jars missing. I guess I'll have to
> reiterate this again since system scope doesn't seem to be supported
> anymore.
>
> /Bengt
>
> 2011/11/12 Wayne Fay <wa...@gmail.com>
>
>> What else do you need? Why not full client + some reasonable (small)
>> handful of other dependencies?
>>
>> Wayne
>>
>> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com> wrote:
>> > It works but the full client is not enough for us to be able to build our
>> > application.
>> >
>> > Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>> >>
>> >> Does this no longer work?
>> >> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>> >>  On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>> >>
>> >> > Stephen and Wayne,
>> >> >
>> >> > I agree that using system scope is undesirable. However, there is a
>> > reason
>> >> > why maven has had this  support - it is needed in real life. In my
>> > case, I
>> >> > use Weblogic. When first trying to migrate our old ant based build
>> > system
>> >> > to maven, I started out by trying to put the Weblogic jar:s in the
>> maven
>> >> > repo. It just wasn't doable. They have split the big, all
>> encompassing,
>> > jar
>> >> > file from previous versions into hundreds of individual jar files. I
>> > gave
>> >> > up after a while. I guess if I could find a tool that could convert
>> all
>> >> > these jars into one "super jar" then I could put that jar in the maven
>> >> > repo. I'm not sure that Oracle's licensing rules would allow it
>> though.
>> >> >
>> >> > Dropping support like this because you don't think it's the best way
>> to
>> >> > handle things will not give you a loyal user base. We need to solve
>> > these
>> >> > kind of issues somehow. Before you remove support you must provide an
>> >> > alternate solution. Requiring that hundreds of proprietary jars have
>> to
>> > be
>> >> > put in the maven repo (and updated each time we upgrade Weblogic) is
>> > just
>> >> > not realistic. I've been searching for a good tool that can traverse
>> the
>> >> > manifest classpath's and create a single jar from all individual jars.
>> > Do
>> >> > you know of any such tool?
>> >> >
>> >> > The transitive dependency problem is not exactly the way you describe
>> it
>> >> > Stephen. I don't need transitive dependencies from a system scoped
>> >> > dependency but I want the transitive dependencies to work up to the
>> > system
>> >> > scoped dependency:
>> >> >
>> >> > If A depends on B that depends on S (via a system scoped dependency),
>> > then
>> >> > maven should be able to include S on A's build classpath.
>> >> >
>> >> > The way maven works right now I tend to agree that system scoped
>> >> > dependencies are useless. This is because their location must be hard
>> > coded
>> >> > in the POM. Naturally system scoped dependencies reside in different
>> > places
>> >> > in different environments. In our case it resides where the user has
>> >> > installed Weblogic.
>> >> >
>> >> > /Bengt
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > 2011/11/11 Stephen Connolly <st...@gmail.com>
>> >> >
>> >> > > On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>> >> > > >> System scoped dependencies are dead. Ignore their zombie like
>> > walking
>> >> > > >> about. Stop fighting maven and just install the jars into a repo
>> >> > > >
>> >> > > > I agree, but shouldn't we kill system entirely at some point (I
>> mean
>> >> > > > in the code) -- if we see a system-scoped dependency, we just fail
>> > the
>> >> > > > build with an appropriate error message? It is a dead concept IMO
>> > and
>> >> > > > is simply confusing to users who try to use it.
>> >> > >
>> >> > > Yes I agree... but lets get 3.0.4 out first ;-)
>> >> > >
>> >> > > To answer the OP
>> >> > >
>> >> > > Think of it like this, when you specify a "system" scope dependency
>> >> > > then you are stating that the system is responsible for providing
>> that
>> >> > > dependency _and_ all its dependencies -> transitive stops at system
>> >> > >
>> >> > > Similarly, with provided scope, you are saying that somebody else is
>> >> > > taking care of providing that dependency at run time, and so
>> therefore
>> >> > > maven doesn't have to worry about it or its dependencies.
>> >> > > >
>> >> > > > Wayne
>> >> > > >
>> >> > > >
>> > ---------------------------------------------------------------------
>> >> > > > 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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav <be...@rodehav.com>]

Last time I went through this I never came all the way to a complete list
but I do remember there were lots of jars missing. I guess I'll have to
reiterate this again since system scope doesn't seem to be supported
anymore.

/Bengt

2011/11/12 Wayne Fay <wa...@gmail.com>

> What else do you need? Why not full client + some reasonable (small)
> handful of other dependencies?
>
> Wayne
>
> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> > It works but the full client is not enough for us to be able to build our
> > application.
> >
> > Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
> >>
> >> Does this no longer work?
> >> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
> >>  On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
> >>
> >> > Stephen and Wayne,
> >> >
> >> > I agree that using system scope is undesirable. However, there is a
> > reason
> >> > why maven has had this  support - it is needed in real life. In my
> > case, I
> >> > use Weblogic. When first trying to migrate our old ant based build
> > system
> >> > to maven, I started out by trying to put the Weblogic jar:s in the
> maven
> >> > repo. It just wasn't doable. They have split the big, all
> encompassing,
> > jar
> >> > file from previous versions into hundreds of individual jar files. I
> > gave
> >> > up after a while. I guess if I could find a tool that could convert
> all
> >> > these jars into one "super jar" then I could put that jar in the maven
> >> > repo. I'm not sure that Oracle's licensing rules would allow it
> though.
> >> >
> >> > Dropping support like this because you don't think it's the best way
> to
> >> > handle things will not give you a loyal user base. We need to solve
> > these
> >> > kind of issues somehow. Before you remove support you must provide an
> >> > alternate solution. Requiring that hundreds of proprietary jars have
> to
> > be
> >> > put in the maven repo (and updated each time we upgrade Weblogic) is
> > just
> >> > not realistic. I've been searching for a good tool that can traverse
> the
> >> > manifest classpath's and create a single jar from all individual jars.
> > Do
> >> > you know of any such tool?
> >> >
> >> > The transitive dependency problem is not exactly the way you describe
> it
> >> > Stephen. I don't need transitive dependencies from a system scoped
> >> > dependency but I want the transitive dependencies to work up to the
> > system
> >> > scoped dependency:
> >> >
> >> > If A depends on B that depends on S (via a system scoped dependency),
> > then
> >> > maven should be able to include S on A's build classpath.
> >> >
> >> > The way maven works right now I tend to agree that system scoped
> >> > dependencies are useless. This is because their location must be hard
> > coded
> >> > in the POM. Naturally system scoped dependencies reside in different
> > places
> >> > in different environments. In our case it resides where the user has
> >> > installed Weblogic.
> >> >
> >> > /Bengt
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > 2011/11/11 Stephen Connolly <st...@gmail.com>
> >> >
> >> > > On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> >> > > >> System scoped dependencies are dead. Ignore their zombie like
> > walking
> >> > > >> about. Stop fighting maven and just install the jars into a repo
> >> > > >
> >> > > > I agree, but shouldn't we kill system entirely at some point (I
> mean
> >> > > > in the code) -- if we see a system-scoped dependency, we just fail
> > the
> >> > > > build with an appropriate error message? It is a dead concept IMO
> > and
> >> > > > is simply confusing to users who try to use it.
> >> > >
> >> > > Yes I agree... but lets get 3.0.4 out first ;-)
> >> > >
> >> > > To answer the OP
> >> > >
> >> > > Think of it like this, when you specify a "system" scope dependency
> >> > > then you are stating that the system is responsible for providing
> that
> >> > > dependency _and_ all its dependencies -> transitive stops at system
> >> > >
> >> > > Similarly, with provided scope, you are saying that somebody else is
> >> > > taking care of providing that dependency at run time, and so
> therefore
> >> > > maven doesn't have to worry about it or its dependencies.
> >> > > >
> >> > > > Wayne
> >> > > >
> >> > > >
> > ---------------------------------------------------------------------
> >> > > > 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: Properties in settings.xml does not work for system scoped dependencies

[Wayne Fay <wa...@gmail.com>]

What else do you need? Why not full client + some reasonable (small)
handful of other dependencies?

Wayne

On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> It works but the full client is not enough for us to be able to build our
> application.
>
> Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>>
>> Does this no longer work?
>> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>>  On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>>
>> > Stephen and Wayne,
>> >
>> > I agree that using system scope is undesirable. However, there is a
> reason
>> > why maven has had this  support - it is needed in real life. In my
> case, I
>> > use Weblogic. When first trying to migrate our old ant based build
> system
>> > to maven, I started out by trying to put the Weblogic jar:s in the maven
>> > repo. It just wasn't doable. They have split the big, all encompassing,
> jar
>> > file from previous versions into hundreds of individual jar files. I
> gave
>> > up after a while. I guess if I could find a tool that could convert all
>> > these jars into one "super jar" then I could put that jar in the maven
>> > repo. I'm not sure that Oracle's licensing rules would allow it though.
>> >
>> > Dropping support like this because you don't think it's the best way to
>> > handle things will not give you a loyal user base. We need to solve
> these
>> > kind of issues somehow. Before you remove support you must provide an
>> > alternate solution. Requiring that hundreds of proprietary jars have to
> be
>> > put in the maven repo (and updated each time we upgrade Weblogic) is
> just
>> > not realistic. I've been searching for a good tool that can traverse the
>> > manifest classpath's and create a single jar from all individual jars.
> Do
>> > you know of any such tool?
>> >
>> > The transitive dependency problem is not exactly the way you describe it
>> > Stephen. I don't need transitive dependencies from a system scoped
>> > dependency but I want the transitive dependencies to work up to the
> system
>> > scoped dependency:
>> >
>> > If A depends on B that depends on S (via a system scoped dependency),
> then
>> > maven should be able to include S on A's build classpath.
>> >
>> > The way maven works right now I tend to agree that system scoped
>> > dependencies are useless. This is because their location must be hard
> coded
>> > in the POM. Naturally system scoped dependencies reside in different
> places
>> > in different environments. In our case it resides where the user has
>> > installed Weblogic.
>> >
>> > /Bengt
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2011/11/11 Stephen Connolly <st...@gmail.com>
>> >
>> > > On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>> > > >> System scoped dependencies are dead. Ignore their zombie like
> walking
>> > > >> about. Stop fighting maven and just install the jars into a repo
>> > > >
>> > > > I agree, but shouldn't we kill system entirely at some point (I mean
>> > > > in the code) -- if we see a system-scoped dependency, we just fail
> the
>> > > > build with an appropriate error message? It is a dead concept IMO
> and
>> > > > is simply confusing to users who try to use it.
>> > >
>> > > Yes I agree... but lets get 3.0.4 out first ;-)
>> > >
>> > > To answer the OP
>> > >
>> > > Think of it like this, when you specify a "system" scope dependency
>> > > then you are stating that the system is responsible for providing that
>> > > dependency _and_ all its dependencies -> transitive stops at system
>> > >
>> > > Similarly, with provided scope, you are saying that somebody else is
>> > > taking care of providing that dependency at run time, and so therefore
>> > > maven doesn't have to worry about it or its dependencies.
>> > > >
>> > > > Wayne
>> > > >
>> > > >
> ---------------------------------------------------------------------
>> > > > 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: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav <be...@rodehav.com>]

It works but the full client is not enough for us to be able to build our
application.

Den 11 nov 2011 23:11 skrev "Ryan Connolly" <ry...@gmail.com>:
>
> Does this no longer work?
> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
>  On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:
>
> > Stephen and Wayne,
> >
> > I agree that using system scope is undesirable. However, there is a
reason
> > why maven has had this  support - it is needed in real life. In my
case, I
> > use Weblogic. When first trying to migrate our old ant based build
system
> > to maven, I started out by trying to put the Weblogic jar:s in the maven
> > repo. It just wasn't doable. They have split the big, all encompassing,
jar
> > file from previous versions into hundreds of individual jar files. I
gave
> > up after a while. I guess if I could find a tool that could convert all
> > these jars into one "super jar" then I could put that jar in the maven
> > repo. I'm not sure that Oracle's licensing rules would allow it though.
> >
> > Dropping support like this because you don't think it's the best way to
> > handle things will not give you a loyal user base. We need to solve
these
> > kind of issues somehow. Before you remove support you must provide an
> > alternate solution. Requiring that hundreds of proprietary jars have to
be
> > put in the maven repo (and updated each time we upgrade Weblogic) is
just
> > not realistic. I've been searching for a good tool that can traverse the
> > manifest classpath's and create a single jar from all individual jars.
Do
> > you know of any such tool?
> >
> > The transitive dependency problem is not exactly the way you describe it
> > Stephen. I don't need transitive dependencies from a system scoped
> > dependency but I want the transitive dependencies to work up to the
system
> > scoped dependency:
> >
> > If A depends on B that depends on S (via a system scoped dependency),
then
> > maven should be able to include S on A's build classpath.
> >
> > The way maven works right now I tend to agree that system scoped
> > dependencies are useless. This is because their location must be hard
coded
> > in the POM. Naturally system scoped dependencies reside in different
places
> > in different environments. In our case it resides where the user has
> > installed Weblogic.
> >
> > /Bengt
> >
> >
> >
> >
> >
> >
> > 2011/11/11 Stephen Connolly <st...@gmail.com>
> >
> > > On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> > > >> System scoped dependencies are dead. Ignore their zombie like
walking
> > > >> about. Stop fighting maven and just install the jars into a repo
> > > >
> > > > I agree, but shouldn't we kill system entirely at some point (I mean
> > > > in the code) -- if we see a system-scoped dependency, we just fail
the
> > > > build with an appropriate error message? It is a dead concept IMO
and
> > > > is simply confusing to users who try to use it.
> > >
> > > Yes I agree... but lets get 3.0.4 out first ;-)
> > >
> > > To answer the OP
> > >
> > > Think of it like this, when you specify a "system" scope dependency
> > > then you are stating that the system is responsible for providing that
> > > dependency _and_ all its dependencies -> transitive stops at system
> > >
> > > Similarly, with provided scope, you are saying that somebody else is
> > > taking care of providing that dependency at run time, and so therefore
> > > maven doesn't have to worry about it or its dependencies.
> > > >
> > > > Wayne
> > > >
> > > >
---------------------------------------------------------------------
> > > > 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: Properties in settings.xml does not work for system scoped dependencies

[Ryan Connolly <ry...@gmail.com>]

Does this no longer work?
http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
 On Nov 11, 2011 3:38 PM, "Bengt Rodehav" <be...@rodehav.com> wrote:

> Stephen and Wayne,
>
> I agree that using system scope is undesirable. However, there is a reason
> why maven has had this  support - it is needed in real life. In my case, I
> use Weblogic. When first trying to migrate our old ant based build system
> to maven, I started out by trying to put the Weblogic jar:s in the maven
> repo. It just wasn't doable. They have split the big, all encompassing, jar
> file from previous versions into hundreds of individual jar files. I gave
> up after a while. I guess if I could find a tool that could convert all
> these jars into one "super jar" then I could put that jar in the maven
> repo. I'm not sure that Oracle's licensing rules would allow it though.
>
> Dropping support like this because you don't think it's the best way to
> handle things will not give you a loyal user base. We need to solve these
> kind of issues somehow. Before you remove support you must provide an
> alternate solution. Requiring that hundreds of proprietary jars have to be
> put in the maven repo (and updated each time we upgrade Weblogic) is just
> not realistic. I've been searching for a good tool that can traverse the
> manifest classpath's and create a single jar from all individual jars. Do
> you know of any such tool?
>
> The transitive dependency problem is not exactly the way you describe it
> Stephen. I don't need transitive dependencies from a system scoped
> dependency but I want the transitive dependencies to work up to the system
> scoped dependency:
>
> If A depends on B that depends on S (via a system scoped dependency), then
> maven should be able to include S on A's build classpath.
>
> The way maven works right now I tend to agree that system scoped
> dependencies are useless. This is because their location must be hard coded
> in the POM. Naturally system scoped dependencies reside in different places
> in different environments. In our case it resides where the user has
> installed Weblogic.
>
> /Bengt
>
>
>
>
>
>
> 2011/11/11 Stephen Connolly <st...@gmail.com>
>
> > On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> > >> System scoped dependencies are dead. Ignore their zombie like walking
> > >> about. Stop fighting maven and just install the jars into a repo
> > >
> > > I agree, but shouldn't we kill system entirely at some point (I mean
> > > in the code) -- if we see a system-scoped dependency, we just fail the
> > > build with an appropriate error message? It is a dead concept IMO and
> > > is simply confusing to users who try to use it.
> >
> > Yes I agree... but lets get 3.0.4 out first ;-)
> >
> > To answer the OP
> >
> > Think of it like this, when you specify a "system" scope dependency
> > then you are stating that the system is responsible for providing that
> > dependency _and_ all its dependencies -> transitive stops at system
> >
> > Similarly, with provided scope, you are saying that somebody else is
> > taking care of providing that dependency at run time, and so therefore
> > maven doesn't have to worry about it or its dependencies.
> > >
> > > Wayne
> > >
> > > ---------------------------------------------------------------------
> > > 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: Properties in settings.xml does not work for system scoped dependencies

[Bengt Rodehav <be...@rodehav.com>]

Stephen and Wayne,

I agree that using system scope is undesirable. However, there is a reason
why maven has had this  support - it is needed in real life. In my case, I
use Weblogic. When first trying to migrate our old ant based build system
to maven, I started out by trying to put the Weblogic jar:s in the maven
repo. It just wasn't doable. They have split the big, all encompassing, jar
file from previous versions into hundreds of individual jar files. I gave
up after a while. I guess if I could find a tool that could convert all
these jars into one "super jar" then I could put that jar in the maven
repo. I'm not sure that Oracle's licensing rules would allow it though.

Dropping support like this because you don't think it's the best way to
handle things will not give you a loyal user base. We need to solve these
kind of issues somehow. Before you remove support you must provide an
alternate solution. Requiring that hundreds of proprietary jars have to be
put in the maven repo (and updated each time we upgrade Weblogic) is just
not realistic. I've been searching for a good tool that can traverse the
manifest classpath's and create a single jar from all individual jars. Do
you know of any such tool?

The transitive dependency problem is not exactly the way you describe it
Stephen. I don't need transitive dependencies from a system scoped
dependency but I want the transitive dependencies to work up to the system
scoped dependency:

If A depends on B that depends on S (via a system scoped dependency), then
maven should be able to include S on A's build classpath.

The way maven works right now I tend to agree that system scoped
dependencies are useless. This is because their location must be hard coded
in the POM. Naturally system scoped dependencies reside in different places
in different environments. In our case it resides where the user has
installed Weblogic.

/Bengt






2011/11/11 Stephen Connolly <st...@gmail.com>

> On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
> >> System scoped dependencies are dead. Ignore their zombie like walking
> >> about. Stop fighting maven and just install the jars into a repo
> >
> > I agree, but shouldn't we kill system entirely at some point (I mean
> > in the code) -- if we see a system-scoped dependency, we just fail the
> > build with an appropriate error message? It is a dead concept IMO and
> > is simply confusing to users who try to use it.
>
> Yes I agree... but lets get 3.0.4 out first ;-)
>
> To answer the OP
>
> Think of it like this, when you specify a "system" scope dependency
> then you are stating that the system is responsible for providing that
> dependency _and_ all its dependencies -> transitive stops at system
>
> Similarly, with provided scope, you are saying that somebody else is
> taking care of providing that dependency at run time, and so therefore
> maven doesn't have to worry about it or its dependencies.
> >
> > Wayne
> >
> > ---------------------------------------------------------------------
> > 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: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly <st...@gmail.com>]

On 11 November 2011 16:31, Wayne Fay <wa...@gmail.com> wrote:
>> System scoped dependencies are dead. Ignore their zombie like walking
>> about. Stop fighting maven and just install the jars into a repo
>
> I agree, but shouldn't we kill system entirely at some point (I mean
> in the code) -- if we see a system-scoped dependency, we just fail the
> build with an appropriate error message? It is a dead concept IMO and
> is simply confusing to users who try to use it.

Yes I agree... but lets get 3.0.4 out first ;-)

To answer the OP

Think of it like this, when you specify a "system" scope dependency
then you are stating that the system is responsible for providing that
dependency _and_ all its dependencies -> transitive stops at system

Similarly, with provided scope, you are saying that somebody else is
taking care of providing that dependency at run time, and so therefore
maven doesn't have to worry about it or its dependencies.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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: Properties in settings.xml does not work for system scoped dependencies

[Wayne Fay <wa...@gmail.com>]

> System scoped dependencies are dead. Ignore their zombie like walking
> about. Stop fighting maven and just install the jars into a repo

I agree, but shouldn't we kill system entirely at some point (I mean
in the code) -- if we see a system-scoped dependency, we just fail the
build with an appropriate error message? It is a dead concept IMO and
is simply confusing to users who try to use it.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Properties in settings.xml does not work for system scoped dependencies

[Stephen Connolly <st...@gmail.com>]

System scoped dependencies are dead. Ignore their zombie like walking
about. Stop fighting maven and just install the jars into a repo

On 11 November 2011 16:02, Bengt Rodehav <be...@rodehav.com> wrote:
> We are using maven 3.0.3 and have problems using property values defined in
> our local settings.xml for specifying systemPath values for system-scoped
> dependencies. It seems this possibility has been removed in maven 3.
>
> The system-scoped variable is necessary because we depend directly on a
> third party application server jar file which now has hard coded dependency
> jars listed in its MANIFEST. It is simply not practical to install these
> (several dozen - perhaps hundreds) jars into our remote Maven repository.
>
> The problem is serious because the pom files which use this system-scoped
> dependency do not pass validation when parsed by the reactor, preventing
> any transitive dependencies from being resolved in child projects. The
> current workaround is to define these properties in our parent pom instead,
> but this is not ideal since the values are environment-specific in nature
> and should not be hard coded in the pom.
>
> I wonder why this has changed in maven 3 and what then is the best practice
> to handle a situation like ours (it must be a common scenario)?
>
> As a side note we actually discovered this on computers running maven 2.2.1
> but using m2eclipse. M2eclipse seems to use an embedded snapshot version of
> maven 3  for its dependency resolution (we use m2eclipse
> 12.0.20101115-1102). It has worked perfectly for a long time but just
> recently started to exhibit this behaviour. We don't really know what has
> triggered this but we are guessing that m2eclipse perhaps updated itself
> with a new snapshot version of maven 3 - not really sure have m2eclipse
> works regarding this.
>
> I appreciate any help,
>
> /Bengt
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org