http://maven.apache.org/plugins/maven-ejb-plugin/examples/generating-ejb-client.html states it supports clientIncludes elements. See http://maven.apache.org/plugins/maven-ejb-plugin/ejb-mojo.html#clientIncludes
On Fri, May 20, 2016 at 5:01 PM, Eric B <ebenza...@gmail.com> wrote: > @Matthew - good call. I started to modify my stuff in order to use the > shade plugin, but then realized I was still in trouble. I need to generate > an EJB package and the only way I know how to do that with the EJB plugin > is to point to .class files. Which means that I need to unpack my lib to > generate the EJB package and the client EJB. > > I would use the maven-ejb-plugin on the main lib package and append a > classifier, but the problem is that there is no "include" in the ejb-plugin > - only excludes. Which means that I need to manually list every file that > I don't want in that package, which is just too large and complicated. > Instead, I was looking at using the dependenc-plugin to only unpack the > files that I need for my EJB package. > > Unless you have any any suggestions to simplify that? > > Thanks, > > Eric > > > On Thu, May 19, 2016 at 2:13 PM, Matthew Piggott <mpigg...@sonatype.com> > wrote: > >> If all the common code (or all of it, if you want) is in a single library >> you can also filter the contents w/ the shade plugin - >> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#filters >> >> The caveat with this approach is that Eclipse will not consider the >> filtering, thus if the projects are in your workspaces then other projects >> which depend on them will see classes which may be excluded in the final >> build. >> >> On 19 May 2016 at 13:42, Eric B <ebenza...@gmail.com> wrote: >> >>> Apparently, you are right. Unpack seems to only work in post-package >>> phases, I guess due to the way that m2e assembles its build priorities. >>> >>> So, I'm back to the starting point. The problem with the shade plugin >>> is that I am trying to avoid refactoring classes into different packages, >>> mostly because the code base is so fragmented that I'm entirely sure what >>> gets broken when things get moved. Right now, Ant selectively picks and >>> chooses which files to compile/package from the module for each artifact. >>> >>> If I keep all the files in the same module, and then only extract the >>> required files that I want, I can then repackage them using the jar plugin >>> or the ejb-plugin and generate client ejbs based on the selected files >>> (easy to accomplish via the unpack goal). >>> >>> However, like you just pointed out, unpack doesn't work well in Eclipse, >>> so I'm a little back up the proverbial creek. I don't see how the shade >>> plugin will necessarily help out, unless I start refactoring files into >>> separate packages, in which case I can imagine that I might want to augment >>> a jar with files from a previously compiled jar. >>> >>> Unless I'm still looking at this upside down? >>> >>> Thanks, >>> >>> Eric >>> >>> >>> On Wed, May 18, 2016 at 3:24 PM, Matthew Piggott <mpigg...@sonatype.com> >>> wrote: >>> >>>> Unless something has changed unpack won't play nice in Eclipse. >>>> >>>> I don't think you're understanding what I suggested. >>>> >>>> On 18 May 2016 at 15:15, Eric B <ebenza...@gmail.com> wrote: >>>> >>>>> That's kind of what I am trying to do right now as well. The only >>>>> catch to that is that the full "library.jar" file contains extra classes >>>>> that i don't want in it. >>>>> >>>>> So at the moment, my plan is to : >>>>> a) Build library.jar with a classifier DO_NOT_CONSUME which contains >>>>> all the classes. >>>>> b) Use the dependency:unpack in the sub modules to selectively unpack >>>>> the resources I want to have in each module and reassemble them >>>>> accordingly. >>>>> >>>>> It's a very ugly/clunky solution, and wish I had a better option. >>>>> >>>>> If you have any brilliant ideas how to improve, I'd love to hear them. >>>>> >>>>> Thanks, >>>>> Eric >>>>> >>>>> On Wed, May 18, 2016 at 3:09 PM, Matthew Piggott < >>>>> mpigg...@sonatype.com> wrote: >>>>> >>>>>> Have your common code ("library.jar") in one module. Then have the >>>>>> other modules (secured, unsecured, etc) declare it as a dependency, you >>>>>> can >>>>>> use the maven shade plugin >>>>>> <https://maven.apache.org/plugins/maven-shade-plugin/> to bundle the >>>>>> dependencies into the jar. >>>>>> >>>>>> >>>>>> >>>>>> On 18 May 2016 at 14:48, Eric B <ebenza...@gmail.com> wrote: >>>>>> >>>>>>> Hi Matthew, >>>>>>> >>>>>>> Can you please expand on your concept? It is tickling something in >>>>>>> the back of my mind but I just can't seem to grasp it precisely... >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Eric >>>>>>> >>>>>>> On Wed, May 18, 2016 at 1:17 PM, Matthew Piggott < >>>>>>> mpigg...@sonatype.com> wrote: >>>>>>> >>>>>>>> Have one module with the common code then create other modules >>>>>>>> which shade in the common code dep. >>>>>>>> >>>>>>>> On 18 May 2016 at 12:48, Anton Tanasenko <atg.sleepl...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Eric, >>>>>>>>> Every eclipse project must reside in its own dir, it doesn't allow >>>>>>>>> mixing multiple projects in the same directory. >>>>>>>>> Eclipse also doesn't allow storing any of its resources outside of >>>>>>>>> their respective project's dir. >>>>>>>>> >>>>>>>>> So you should definitely convert your project into a proper >>>>>>>>> multimodule build. There is no way your setup will work correctly in >>>>>>>>> eclipse otherwise. >>>>>>>>> >>>>>>>>> 2016-05-18 19:09 GMT+03:00 Eric B <ebenza...@gmail.com>: >>>>>>>>> >>>>>>>>>> Sure - but the problem is that they all use the same sources. >>>>>>>>>> And refactoring the code base into 4 separate modules is not really >>>>>>>>>> an >>>>>>>>>> option. >>>>>>>>>> >>>>>>>>>> Right now I'm playing around with poms in subfolders that use : >>>>>>>>>> <sourceDirectory>${basedir}/..</sourceDirectory> >>>>>>>>>> >>>>>>>>>> but that means I have to override all the defaults in the maven >>>>>>>>>> pom, which is a royal nuissance. And I'm not even convinced that all >>>>>>>>>> plugins will work properly. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Eric >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 18, 2016 at 11:51 AM, Jeff Jensen <jjen...@apache.org >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Best is to move them to 4 separate modules/directory >>>>>>>>>>> structures. Then it will work without issues. >>>>>>>>>>> >>>>>>>>>>> On Wed, May 18, 2016 at 10:36 AM, Eric B <ebenza...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am migrating a legacy app to maven and am having miserable >>>>>>>>>>>> time with one module in particular. The way the Ant script worked >>>>>>>>>>>> is that >>>>>>>>>>>> it built 3 or 4 artifacts from the same code base. >>>>>>>>>>>> - secure-EJB.jar (some subset of classes) >>>>>>>>>>>> - secure-EJB-client.jar (client EJB) >>>>>>>>>>>> - unsecure-EJB.jar (another subset of classes) >>>>>>>>>>>> - library.jar (regular java library with the bulk of classes, >>>>>>>>>>>> apart from the EJB beans/facades) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At first I tried to get Maven to build everything via a single >>>>>>>>>>>> pom, but that was just a recipe for disaster (and broke just about >>>>>>>>>>>> every >>>>>>>>>>>> maven convention I know), so I abandoned the concept altogether. >>>>>>>>>>>> >>>>>>>>>>>> Instead, I ended up with 4 poms - each building to a separate >>>>>>>>>>>> target/ folder: >>>>>>>>>>>> - pom.xml (parent pom, defines all the dependencies required >>>>>>>>>>>> for the build, and includes the 3 next poms as modules) >>>>>>>>>>>> - pom-ejb-secure.xml (inherits pom.xml) >>>>>>>>>>>> - pom-ejb-unsecure.xml (inherits pom.xml) >>>>>>>>>>>> - pom-jar.xml (inherits pom.xml) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> pom.xml (snippet): >>>>>>>>>>>> >>>>>>>>>>>> <modelVersion>4.0.0</modelVersion> >>>>>>>>>>>> <artifactId>ejb-pom</artifactId> >>>>>>>>>>>> <groupId>org.myc</groupId> >>>>>>>>>>>> <packaging>pom</packaging> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <modules> >>>>>>>>>>>> <module>pom-securedEjb.xml</module> >>>>>>>>>>>> <module>pom-unsecuredEjb.xml</module> >>>>>>>>>>>> <module>pom-jar.xml</module> >>>>>>>>>>>> </modules> >>>>>>>>>>>> >>>>>>>>>>>> <properties> >>>>>>>>>>>> <skipTests>true</skipTests> >>>>>>>>>>>> </properties> >>>>>>>>>>>> ... >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From a command line build (ex: mvn clean deploy), everything >>>>>>>>>>>> works properly, and as expected. All artifacts are independently >>>>>>>>>>>> built and >>>>>>>>>>>> deployed, at the cost of recompiling the classes for each pom. >>>>>>>>>>>> >>>>>>>>>>>> However, I have no idea how to load/configure this in >>>>>>>>>>>> Eclipse/m2e such that it sees the different artifacts produced, >>>>>>>>>>>> and more >>>>>>>>>>>> importantly is able to resolve against them when referenced in >>>>>>>>>>>> other open >>>>>>>>>>>> projects (Enable Workspace Resolution). >>>>>>>>>>>> >>>>>>>>>>>> When I import the maven project, it just "loads" the parent >>>>>>>>>>>> pom.xml and does not recognize that there are modules that need to >>>>>>>>>>>> be >>>>>>>>>>>> loaded/resolved as well. >>>>>>>>>>>> >>>>>>>>>>>> Is there anything I can do about this? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Eric >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> m2e-users mailing list >>>>>>>>>>>> m2e-users@eclipse.org >>>>>>>>>>>> To change your delivery options, retrieve your password, or >>>>>>>>>>>> unsubscribe from this list, visit >>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> m2e-users mailing list >>>>>>>>>>> m2e-users@eclipse.org >>>>>>>>>>> To change your delivery options, retrieve your password, or >>>>>>>>>>> unsubscribe from this list, visit >>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> m2e-users mailing list >>>>>>>>>> m2e-users@eclipse.org >>>>>>>>>> To change your delivery options, retrieve your password, or >>>>>>>>>> unsubscribe from this list, visit >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> Anton. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> m2e-users mailing list >>>>>>>>> m2e-users@eclipse.org >>>>>>>>> To change your delivery options, retrieve your password, or >>>>>>>>> unsubscribe from this list, visit >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> m2e-users mailing list >>>>>>>> m2e-users@eclipse.org >>>>>>>> To change your delivery options, retrieve your password, or >>>>>>>> unsubscribe from this list, visit >>>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> m2e-users mailing list >>>>>>> m2e-users@eclipse.org >>>>>>> To change your delivery options, retrieve your password, or >>>>>>> unsubscribe from this list, visit >>>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> m2e-users mailing list >>>>>> m2e-users@eclipse.org >>>>>> To change your delivery options, retrieve your password, or >>>>>> unsubscribe from this list, visit >>>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> m2e-users mailing list >>>>> m2e-users@eclipse.org >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> m2e-users mailing list >>>> m2e-users@eclipse.org >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>>> >>> >>> >>> _______________________________________________ >>> m2e-users mailing list >>> m2e-users@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/m2e-users >>> >> >> >> _______________________________________________ >> m2e-users mailing list >> m2e-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> > > > _______________________________________________ > m2e-users mailing list > m2e-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/m2e-users > -- "Have you tried turning it off and on again" - The IT Crowd And if that fails, then http://goo.gl/tnBgH5
_______________________________________________ m2e-users mailing list m2e-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/m2e-users
