On Jun 17, 2010, at 10:35 AM, Stephen Connolly wrote:
> On 17 June 2010 18:13, David Blevins <[email protected]> wrote:
>
>>
>> On Jun 17, 2010, at 1:06 AM, Yvan wrote:
>>
>>>
>>> Well I don't know how you manage to get all you need with only one core
>> jar
>>> but just in case someone else uses the openejb-standalone container's
>>> libraries as depedencies of his project, here is the full pom.xml
>>> dependencies section to get the jars needed in the above mentioned
>>> 3.2-SNAPSHOT:
>>
>> Maven will automatically pull in the dependencies of your dependencies,
>> recursively, till all dependencies are collected.
>>
>> Looks like you need web services, so if you replaced your openejb-core
>> dependency with the openejb-cxf module, you'll get everything listed. Try
>> just listing this jar:
>>
>> <dependency>
>> <groupId>org.apache.openejb</groupId>
>> <artifactId>openejb-cxf</artifactId>
>> <version>${openejb.version}</version>
>> <optional>true</optional>
>>
>
> I would recommend against specifying optional=true unless the depenency
> truely is optional.
>
> IMHO most people fail to understand what <optional> is actually for... and
> it never does what its supposed to do anyway ;-) [i.e. an optional
> dependency is one which is not required but nice to have... but the way
> maven works, it will just go ahead and download it anyway... it's in reality
> a hack for projects which are too lazy to refactor into mix-in modules.
>
> for example, log4j has an optional dependency on javax.mail
>
> <dependency>
> <groupId>javax.mail</groupId>
> <artifactId>mail</artifactId>
> <version>1.4.1</version>
> <optional>true</optional>
> </dependency>
>
> The reality is that when you use log4j:log4j:1.2.16, you will always pull
> javax.mail:mail onto your classpath because maven will see the dependency,
> and see that it can get the dependency, and so add it to your classpath for
> you...
>
> if log4j did not ship an uberjar, but instead split the classes that depend
> on javax.mail into a log4j-mail module then there would be no need for the
> optional dependency, people who need the mail support will just add a
> dependency on the log4j-mail artifact and get the javax.mail added to their
> classpath because they actually need it.
>
> there are worse examples out there, for example, at one time one version of
> log4j that I saw in a repo other than central had an optional dependency on
> the Windows NT event logging support classes... and don't get me started on
> the crazy fools who use profile activation based on OS to add dependencies
> so that when you build on Windows you get one set of dependencies while
> building on linux gives another (so that when I build on linux for a windows
> machine my build fails!)
>
> so, to end my rant... you never really want to specify
> <optional>true</optional> you actually want to split the code that has that
> dependency into it's own module...
>
> thankfully what I've seen of openejb follows this pattern ;-)
Good catch. Copied that from the email itself. Here's how we have it in our
examples:
<!--
The <scope>test</scope> guarantees that none of your runtime
code is dependent on any OpenEJB classes.
-->
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-cxf</artifactId>
<version>3.2-SNAPSHOT</version>
<scope>test</scope>
</dependency>
-David
