Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #39751
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2022-03-25 00:06 -0700 |
| References | <24661170-8a5b-44a9-9e3e-aff788e65e13n@googlegroups.com> <623cb629$0$704$14726298@news.sunsite.dk> <9345bbbb-3412-49a0-9a95-92cdcb7c034dn@googlegroups.com> <623cbd23$0$696$14726298@news.sunsite.dk> |
| Message-ID | <ed117164-53d2-4412-9fac-7fcdbc455d3fn@googlegroups.com> (permalink) |
| Subject | Re: Get away from dependency hell in maven possible |
| From | mike <mikaelpetterson@hotmail.com> |
torsdag 24 mars 2022 kl. 19:49:21 UTC+1 skrev Arne Vajhøj: > On 3/24/2022 2:24 PM, e.d.pro...@gmail.com wrote: > >> You can only do what you can do. > >> > >> You can switch to a model with multiple micro-services that makes > >> network calls to each other. > >> > >> Or you can stay with a single application and Java calls. > >> > >> If you chose the latter then the way to support different versions > >> of libraries it to switch to a model where each module is loaded by > >> separate classloaders from separate classpaths. > >> > >> There are a few options for that. You can go custom. There is OSGi. > >> Etc.. > > > > Deploy an app as multiple war files, each gets it's own classpath. > > They can share code from a common module which packages a copy of a > > jar into each war. If they need to share each other's code, it's http > > calls, which is normal in the front end code. > A servlet engine also provide the different classloaders, but if > a switch from Java calls to HTTP calls is warranted then SpringBoot > micro-services is a bit more modern. > > Arne Thanks for all the hints! Current project is maven modules. Then modules has dependencies to inner-source libraries that can in turn use open source libraries :-) Users write test code like: XX myXXResource = Resource.getXXResource(); myXXResource.connect(); myXXResource.upgrade(); //helpers to poll for a ready state on the resource before we can continue. So end-users have their own repo (git) and creates a dependency to our framework and then write testcases using similar code as above. The problem as I see it is that we deploy one large jar (monolith) but only a portion is really needed by each test repo. And besides, as mentioned in the heading of this message, we have the same dependency in multiple places which makes it hard to upgrade. OSGI seems interesting... In an ideal world when test code is running in a user repo we should only load components that are actually used and not more. I appreciate all your thoughts and ideas and experienced input for an open discussion. //mike
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Get away from dependency hell in maven possible mike <mikaelpetterson@hotmail.com> - 2022-03-24 07:46 -0700
Re: Get away from dependency hell in maven possible Eric Sosman <esosman@comcast-dot-net.invalid> - 2022-03-24 13:16 -0400
Re: Get away from dependency hell in maven possible mike <mikaelpetterson@hotmail.com> - 2022-03-24 23:31 -0700
Re: Get away from dependency hell in maven possible "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2022-03-24 10:32 -0700
Re: Get away from dependency hell in maven possible Arne Vajhøj <arne@vajhoej.dk> - 2022-03-24 14:19 -0400
Re: Get away from dependency hell in maven possible "e.d.pro...@gmail.com" <e.d.programmer@gmail.com> - 2022-03-24 11:24 -0700
Re: Get away from dependency hell in maven possible Arne Vajhøj <arne@vajhoej.dk> - 2022-03-24 14:49 -0400
Re: Get away from dependency hell in maven possible mike <mikaelpetterson@hotmail.com> - 2022-03-25 00:06 -0700
csiph-web