tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Standalone OpenEJB pom (embedded container)
Date Thu, 17 Jun 2010 18:01:06 GMT

On Jun 17, 2010, at 10:35 AM, Stephen Connolly wrote:

> On 17 June 2010 18:13, David Blevins <david.blevins@visi.com> 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


Mime
View raw message