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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@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
Re: Some guidance using EJB client dependencies
Hi Alexander, Don't have answers for you, as I stopped using ejb-clients because of similar problems. I believe specifying type ejb and classifier client worked. For me the biggest problem is that an ejb-client artifact cannot declare that it only has a subset of the ejb's dependencies. Regards, Marcel - Original Message From: Alexander Sack [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Tuesday, May 29, 2007 3:17:00 AM Subject: Some guidance using EJB client dependencies As per: http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html This does not seem to work for me. I'm using compiler 2.0.2 and EJB 2.1plugins. The compiler does generate client jars for me but I can't seem to use it as a dependency of type ejb. Everytime I try to use it I get it can't find the artifact of type ejb-client:client:version etc. I'm using ejb version 3.0. Is there anything I need to do special? Is the doc incorrect? I just want to get some general guidance before posting any pom stuff. Thanks guys! -aps -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some guidance using EJB client dependencies
Hi, I think it's related to http://jira.codehaus.org/browse/MNG-2921 Rémy
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 [EMAIL PROTECTED] 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
Re: Some guidance using EJB client dependencies
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 [EMAIL PROTECTED] To: Maven Users List users@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- What lies behind us and what lies in front of us is of little concern to what lies within us. -Ralph Waldo Emerson
Re: Some guidance using EJB client dependencies
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.ear contains 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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- What
Re: Some guidance using EJB client dependencies
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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org; Marcel Schutte [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Maven Users List users@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
