You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Rémy Sanlaville <re...@gmail.com> on 2007/06/01 09:19:20 UTC

Re: Some guidance using EJB client dependencies

Hi Alexander and Marcel,

A good news for us, the patch for the issue 2921 (
http://jira.codehaus.org/browse/MNG-2921) is applied.
I haven't try it.

Regards,
Rémy

2007/5/29, Marcel Schutte <ms...@yahoo.co.uk>:
>
> Alexander,
>
> Your suggestion of using scope provided will work I guess, but I just
> can't bring myself to duplicating an artifacts' dependencies: it invalidates
> the whole idea of transitive dependencies where I define an artifacts'
> dependencies in the pom that is used to build it and nowhere else.
>
> Separating out the ejb interfaces into a another artifact would certainly
> do the trick and enable me to declare just their dependencies. When
> following this path you could forget about ejb-client types altogether.
>
> Does anyone else have some thoughts on this issue?
>
> Regards,
> Marcel
> ----- Original Message ----
> From: Alexander Sack <pi...@gmail.com>
> To: Maven Users List <us...@maven.apache.org>; Marcel Schutte <
> marcel@schutte.name>
> Sent: Tuesday, May 29, 2007 5:59:46 PM
> Subject: Re: Some guidance using EJB client dependencies
>
> Marcel,
>
> Okay, classical manifest examples (straight out of the spec too).  Well
> you
> can get around that with some pom configuration (i.e. you can use provided
> in the B.ear pom for all the transitive dependencies you inherit from the
> E.jar, etc., I think that would work).  I'm a JBoss guy at heart so
> typically what I do (and per their funky classloader hierarchy), I will
> separate those common interfaces into a jar file that gets deployed
> outside
> the EAR so they can both share the same file.  Not sure how that works on
> other platforms though so I can't say that is a best practice.
>
> Alright, seems like Maven needs to handle these scenarios better.  I think
> definitely ejb-client support would help...
>
> -aps
>
> On 5/29/07, Marcel Schutte <ms...@yahoo.co.uk> wrote:
> >
> > Hi Alexander,
> >
> > Exactly, I don't want the ejb dependencies to automatically become the
> > ejb-client dependencies. Perhaps you don't run into this problem because
> the
> > artifact that depends on your ejb-client is in the same ear as the ejb
> is.
> >
> > I have a situation where A.ear contains the ejb module E.jar and
> B.earcontains some artifact
> > X.jar that depends on E-client.jar. Now, B.ear will contain all of the
> > dependencies of E.jar (for instance hibernate and all its transitive
> > dependencies if you remember my previous example).
> >
> > A solution for this would be some configuration in the pom.xml for the
> ejb
> > and ejb-client that uses includes or excludes to indicate which
> dependencies
> > you need for the ejb-client. Typically, this won't be very much.
> >
> > Regards,
> > Marcel
> >
> > ----- Original Message ----
> > From: Alexander Sack <pi...@gmail.com>
> > To: Maven Users List <us...@maven.apache.org>; Marcel Schutte <
> > marcel@schutte.name>
> > Sent: Tuesday, May 29, 2007 5:22:44 PM
> > Subject: Re: Some guidance using EJB client dependencies
> >
> > Marcel:
> >
> > So you have a situation where you have a bunch of dependencies in your
> > core
> > EJB jar and you don't want them to leak into your EJB client
> > jar?  Something
> > like that?  Only reason why I ask is that I don't run into this problem
> > and
> > I'm trying to figure out why? :D!
> >
> > I think the reason is that any dependencies of my EJB module goes into
> the
> > EAR (/lib) with a corresponding Class-Path manifest entry which  doesn't
> > effect the EJB client jar at all.  To be honest though, most of my
> > projects
> > have very sparse EJB client jars with not a whole lot minus some local
> > client interfaces (and potentially a domain object or two...).
> >
> > -aps
> >
> > On 5/29/07, Marcel Schutte <ms...@yahoo.co.uk> wrote:
> > >
> > > Hi Alexander,
> > >
> > > What I mean is that an ejb-client artifact normally has far less
> > > dependencies than the ejb artifact. A typical ejb in our case uses
> > hibernate
> > > for its persistence, but of course an application that wants to call
> > this
> > > ejb by using the ejb-client doesn't want this (and all transitive
> > > dependencies) on its classpath. The problem is that both are built
> from
> > the
> > > same pom.xml.
> > >
> > > I am not sure whether your suggestion with scope provided and manifest
> > > configuration could solve this. I can't use scope provided because for
> > the
> > > ejb I need the dependencies to be packaged in the containing ear.
> > >
> > > Regards,
> > > Marcel
> > > ----- Original Message ----
> > > From: Alexander Sack <pi...@gmail.com>
> > > To: Maven Users List <us...@maven.apache.org>
> > > Sent: Tuesday, May 29, 2007 4:03:51 PM
> > > Subject: Re: Some guidance using EJB client dependencies
> > >
> > > Remy and Marcel: Thanks!
> > >
> > > I saw the JIRA below and feel this is royally bad for 2.0.6.  Guys,
> how
> > > the
> > > heck am I suppose to use Maven for projects that need to define
> > > ejb-clients?  Right now I would have to write some ugly ANT code to do
> > all
> > > the heavy lifting.
> > >
> > > When is 2.0.7 due out?  I really need this fix badly.  I'm getting
> > around
> > > this in pure maven by just changing the packaging schemes which is not
> > > what
> > > I wanted architecturally (including the ejb-jar in the EAR in order to
> > > avoid
> > > classpath issues).
> > >
> > > Marcel, can you be a little bit more specific in terms of what you
> want
> > > out
> > > of the ejb-client dependencies functionality?  I'm curious on what you
> > > mean.  Are you having problems with Maven including all of the
> > > dependencies
> > > in your ejb-client jar instead of subset?  Why not just specify in the
> > > project that some of those are scope provided and then use the
> manifest
> > > configuration stuff to specify an exact Class-Path, etc.?  Again, just
> > > curious....
> > >
> > > Thanks!
> > >
> > > -aps
> > >
> > > On 5/29/07, Rémy Sanlaville <re...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I think it's related to http://jira.codehaus.org/browse/MNG-2921
> > > >
> > > > Rémy
> > > >
> > >
> > >
> > >
> > > --
> > > "What lies behind us and what lies in front of us is of little concern
> > to
> > > what lies within us." -Ralph Waldo Emerson
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________________________________Get
> > > the free Yahoo! toolbar and rest assured with the added security of
> > spyware
> > > protection.
> > > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > "What lies behind us and what lies in front of us is of little concern
> to
> > what lies within us." -Ralph Waldo Emerson
> >
> >
> >
> >
> >
> >
> >
> >
> ____________________________________________________________________________________
> > Moody friends. Drama queens. Your life? Nope! - their life, your story.
> > Play Sims Stories at Yahoo! Games.
> > http://sims.yahoo.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> --
> "What lies behind us and what lies in front of us is of little concern to
> what lies within us." -Ralph Waldo Emerson
>
>
>
>
>
>
>
> ____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>