@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
