Hi again, after reading my previous e-mail I believe maybe an example would make it clearer. Let's go by the ImageN crop example (although the same argumentation is valid also for the other two (jiffle and vectorize)).
So let's assume at first that both ImageN and JAI work well individually with the two mechanisms of registration: the (JAI/ImageN) registryFile and Java ServiceLoader. Then, let's look at crops's resources on the ImageN main branch. We have: RegistryFile: modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments): --------------------------------------------------------------------------------------------------------------------------- descriptor org.eclipse.imagen.media.crop.CropDescriptor rendered org.eclipse.imagen.media.crop.CropCRIF org.eclipse.imagen.media Crop Crop and we have the Java ServiceLoader definition: modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi: --------------------------------------------------------------------------------------------------------------------------- org.eclipse.imagen.media.crop.CropSpi The most obvious thing here is that the Java ServiceLoader definition is wrong, because CropSpi does not implement the javax.media.jai.OperationRegistrySpi interface. If we use only ImageN in our application, we will not notice the problem. ImageN is simply ignoring that ServiceLoader definition, because the interface is unknown to ImageN. BUT this will crash JAI, because ServiceLoader in JAI throws a ClassCastException given that definition. Now, as proposed, we could (and should) fix this by renaming modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi to modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi. That now pleases JAI, because JAI does not know that new (ImageN) interface. Great! So now all should be good? NO! Because now we have this: RegistryFile: modules/crop/src/main/resources/META-INF/registryFile.jai (stripped of comments): --------------------------------------------------------------------------------------------------------------------------- descriptor org.eclipse.imagen.media.crop.CropDescriptor rendered org.eclipse.imagen.media.crop.CropCRIF org.eclipse.imagen.media Crop Crop and we have the fixed Java ServiceLoader definition: modules/crop/src/main/resources/META-INF/services/org.eclipse.imagen.OperationRegistrySpi: --------------------------------------------------------------------------------------------------------------------------- org.eclipse.imagen.media.crop.CropSpi Technically everything looks fine, BUT ImageN will no longer initialize, because we apply the two types of registration schemes at once. With this, what happens is that the Crop operation gets registered once using registryFile, and then ImageN tries again using ServiceLoader, because now the definition is no longer ignored. And this is the core problem. The wrong ServiceLoader definition files on main branch are simply hiding the problem, because ImageN will ignore them, but if we fix them to be correct, then ImageN will fail to initialize, because Crop is already there. The same argumentation goes for jiffle and vectorize, because those two also have (wrong) Java ServiceLoader definitions. So fixing them too, will result in the same problem of failing initialization. And last but not least, the reason for all other libraries to not fail, is that none of the other libraries have Java ServiceLoader definitions at all. That as the reason why my initial PR#119 simply removed the three ServiceLoader definitions from crop, jiffle and vectorize. Does that better illustrate the problem? ==== Now another topic: should we rename registryFile.jai --> registryFile.imagen ======= Maybe it should be done to make a more explicit distinction between ImageN and JAI registration. It should be noted though that the renaming is a breaking change for everyone using ImageN, because for example GeoTools/GeoServer and other applications that have their own ImageN operators implemented will have to switch to that new naming scheme. But, yeah, maybe it's worth the effort - I don't know. What I want to emphasize though is that I have tried locally with the wrong ServiceLoader definitions removed from ImageN. I ran GeoServer 2.28.0 that is now based on ImageN with some of our custom JAI operators that are still based on JAI 1.1.3. First, now both ImageN and JAI initialized correctly and I was able to successfully run WMS queries (which should prove that ImageN is working correctly) and I could also verify that our own custom JAI operators are working as well. My assumption based on that test is that it does not seem to matter too much how these registry files are named. It seems both, ImageN as well as JAI can cope with either and probably filtering the operations by the definitions they support. Of course I can currently not prove that by the same names, both work correctly, but that was my first try. Maybe a JAI/ImageN interoperability Test-case could prove. I don't know. But to summarize the current discussion. Whether or not the registry files should be renamed, does not relate to that other issue I presented in the first part of the e-mail. I hope, by this report, my argumentation becomes clearer. Sorry for that long wall of text. Thanks! Sören -----Ursprüngliche Nachricht----- Von: Kalesse Sören <[email protected]> Gesendet: Mittwoch, 5. November 2025 10:55 An: Jody Garnett <[email protected]> Cc: GeoTools Users <[email protected]> Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine Hi Jody, Ok, I can make a PR, but with that all renaming happening, it'll be quite some big change and probably PRs needed for GeoTools and GeoServer as well, right? ... and all other libs that are already using ImageN. I am very sorry but I really need to emphasize again, that the registry files are not the problem here! ImageN and JAI seem to be able to cope with them even though they have the same name (registryFile.jai). I have tested it locally running ImageN and JAI in the same application and they do not interfere at all. I was able to run GeoServer 2.28.0 that uses ImageN and still use our own JAI operators based on JAI core 1.1.3 without any problems at all. Really, the problem here are those invalid Java ServiceLoader definitions. modules/crop/src/main/resources/META-INF/services/javax.media.jai.OperationRegistrySpi modules/jiffle/jt-jiffle-op/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi modules/vectorize/src/main/resources/META-INF/services/javax.media.jai.OperationsRegistrySpi The first one (crop) tries registering at JAI operation registry, which is wrong. This will cause a ClassCastException in JAI. The other two (jiffle and vectorize) try the same thing but even worse, the interface names are wrong --> OperationsRegistrySpi vs. OperationRegistrySpi. So these two will simply be ignored, because that interface does not exist. I could fix the names of the ServiceLoader definitions --> org.eclipse.imagen.OperationRegistrySpi. That would please Java at least. So that's good, but ImageN will no longer work, because as mentioned earlier, ImageN registry cannot currently not deal with two mechanisms being in place at the same time. Fixing the names will do this (Example taken from the Jiffle test cases): [ERROR] org.eclipse.imagen.media.jiffleop.NoSourceTest.createSequentialImage -- Time elapsed: 0 s <<< ERROR! java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.imagen.ImageN at org.eclipse.imagen.media.jiffleop.NoSourceTest.reset(NoSourceTest.java:82) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalArgumentException: A descriptor is already registered against the name "Jiffle" under registry mode "rendered" [in thread "main"] at org.eclipse.imagen.DescriptorCache.addDescriptor(DescriptorCache.java:144) at org.eclipse.imagen.OperationRegistry.registerDescriptor(OperationRegistry.java:580) at org.eclipse.imagen.ThreadSafeOperationRegistry.registerDescriptor(ThreadSafeOperationRegistry.java:156) at org.eclipse.imagen.media.jiffleop.JiffleSpi.updateRegistry(JiffleSpi.java:73) at org.eclipse.imagen.OperationRegistry.registerServices(OperationRegistry.java:1556) at org.eclipse.imagen.ThreadSafeOperationRegistry.registerServices(ThreadSafeOperationRegistry.java:529) at org.eclipse.imagen.OperationRegistry.initializeRegistry(OperationRegistry.java:311) at org.eclipse.imagen.ImageN.<clinit>(ImageN.java:351) The descriptor cache does not allow an operation to be registered twice. That is why I am saying that fixing the ServiceLoader definitions won't help at all. The only options I see is: 1. make descriptor cache support registry definitions coming from multiple places at the same time ---> I am not sure if that's really a good idea 2. remove the ServiceLoader definitions from those three libs I am wondering anyway, why is it that only those three libs do have ServiceLoader files at all? What about the other libs? Not a single other lib has any ServiceLoader definition at all. My PR#119 did exactly that. It removed the ServiceLoader definitions from those three libs. That's all it did and that fixed it all. No renaming of registryFile.jai required. To summarize: ============ I can make a PR that renames all registryFile.jai --> registryFile.imagen and changes the ImageN registry to use those instead - no problem. But that will not help with the initial problem, we need to deal with those ServiceLoader files - fixing their names to match the correct interface will not help. On the contrary, it will make it worse, because ImageN will no longer initialize, because it cannot handle both (registryFile.[jai|imagen] and ServiceLoader) at the same time. My proposal is to go by the initial PR and remove the ServiceLoader files all together for these three modules that have them (crop, jiffle, vectorize). What do you think? Thanks Sören -----Ursprüngliche Nachricht----- Von: Jody Garnett <[email protected]> Gesendet: Mittwoch, 5. November 2025 02:47 An: Kalesse Sören <[email protected]> Cc: GeoTools Users <[email protected]> Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine So ideally we should fix the invalid definitions, and rename the files to end with “imagen”. If you make a PR I am willing to do a 0.9.1 relate; and Gabe offered to make a geotools release on schedule next week. - - Jody Garnett On Mon, Nov 3, 2025 at 11:12 PM Kalesse Sören <[email protected] <mailto:[email protected]> > wrote: Hi Andrea, That's exactly my point. I do assume that it was not intended for these two to coexist, but it should just work fine because there are two different registries and the operations interfaces are different, so in theory these two do not collide at all. That gives all users a good "workaround" to live with until applications and libraries have succeeded to migrate. And that's also exactly where my PR comes in. The three mentioned ImageN libraries (and only those three!) contain ServiceLoader definitions that are wrong. The register the ImageN operations at the JAI registry. That leads to class cast exceptions (wrong interfaces). That's the point that must definitely be fixed whatsoever. Now that fixed, here arises the second aspect: Right now you cannot mix standard ImageN and ServiceLoader registration. ImageN does not support that. It will fail to initialize if one operation had already been registered by that other means. So you must decide: either support multiple ways of registration in the ImageN core or decide upon one and let it go. Therefore my PR removes the three ServiceLoader definitions: 1) because they were wrong and 2) because that is the least invasive fix to make ImageN initialize correctly. The PR#119 was tested locally running GeoServer 2.2.8.0 and another application that uses JAI and it worked just fine. I hope you can agree that this is a proper fix and should be part in one of the next releases. For us it is a show-stopper for upgrading to GT 33.x / GS 2.28.x. Thanks! Sören -----Ursprüngliche Nachricht----- Von: Andrea Aime <[email protected] <mailto:[email protected]> > Gesendet: Freitag, 31. Oktober 2025 15:25 An: Kalesse Sören <[email protected] <mailto:[email protected]> > Cc: GeoTools Users <[email protected] <mailto:[email protected]> > Betreff: Re: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine Hi, I second what Jody said, there was no plan to make the coexist, it's an upgrade path. However... I believe that a coexistence could be possible, the java packages are different, so by having ImageN use a different file name for the registry files in META-INF, from registryFile.jai to registryFile.imagen, a coexistence might be possible, even if likely wasteful (two separate image processing caches in memory are not the greatest of ideas). A coexistence is just not in our plans, but since ImageN is not yet available as 1.0, if DWD wants to put the development effort to get it done, I would not be against it. I see this applicable to the GeoServer 3.0 series. I would recommend switching existing software to ImageN though, we prepared migration scripts that should help in the endeavor. Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us> for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszP2s2ODk/Nm04PGs2b29vODk6Oj1tNj5rOG9tbG1qOG9sbDtqaG06aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0bTs+Ozo+bDtqajtqMDsxPT1qOmg5PD49MDE+Omwwam0xMWprbzE4Oy99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Ozs6OjQ2MTAyM2Y1MDU1NjQxZzFiOzUwMWA0ZjAwZzQwNzA6ZTY2NCV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fwww.geosolutionsgroup.com%2f> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszNmpqbG1sO2g5ajhsOT1rOjo9PG0+PW9sbWw2PW06PW06Oz88ajo5aCh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zPTkoZmpiMz4=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWg9bW1obzFqaGpsPz5sbToxa2xrPjA9PW06PDBobDk5bG09a2s5bS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0Oj4vYW1lNDk=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+MDplNTQ7ZzM6YTozNmU7NGY1OjtmZzdnYTIzYjIwYmJmNGU2MDBgZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+MDQla2dvPjM=&url=http%3a%2f%2ftwitter.com%2fgeosolutions_it> ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail On Thu, Oct 30, 2025 at 5:29 PM Kalesse Sören <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > > wrote: Hi, thanks for the new release! We have noticed a problem though, that deals with environments where GeoTools (and now ImageN) and JAI are used at the same time. I have documented the issue at https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszb2tqOmw5bDo6Nz45OWhoPTc7PjY/PT89ajo+Pjo5a285azttPD8/bSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0MDs9azlvOT0+bT1oa2s7aGgwamxqPzAwbDs8OmxrPj88MD4+azo9PS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+NDE1YDExNTs1ZjpnNTEwZzIyZmU7NmE7O2ZmZWFgYjJnMzA0NmY1NSV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fissues%2f118> and there is a PR attached https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszOmxrOTdqams6Ozk/OTs3PGg7PTo9Oj1qN2s2Nm84Pms2OTw2Pm0/PSh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0ajxsOGtoaj9sbzs9ODhvOG1qaDFqbTowPTg8Pzs4PWhoOzs/OT1vPi99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZmVgNDplZTRlYWY0NWUzZ2BlMjA3M2UzZTU1MGdmNjQ6Zzc1MGdnNyV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2fgithub.com%2feclipse-imagen%2fimagen%2fpull%2f119> . I wonder if there's any chance the problem can be solved soon as it currently prevents us from upgrading to GeoServer 2.28.x. Thanks and Best Regards Sören -----Ursprüngliche Nachricht----- Von: Jody Garnett <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > > Gesendet: Mittwoch, 22. Oktober 2025 20:57 An: GeoTools Users <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > > Betreff: [Geotools-gt2-users] GeoTools 34.0 released for Java 17 with Eclipse ImageN processing engine The GeoTools team is pleased to announce the release <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwazk7bj5uNG8+Oj5saW5ub2s4NT5raW5paWg+bGw+bjs0OT41azw9PCt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wNT0rZWlhMD0=&url=https%3a%2f%2fgeotoolsnews.blogspot.com%2f2025%2f10%2fgeotools-340-release.html> of the latest stable version of GeoTools 34.0 <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbDU1azU5OWhpaT9sbG5rPTRuPmw9ND9rOWg7NGhuPDU9Oz88aWtsOit5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fsourceforge.net%2fprojects%2fgeotools%2ffiles%2fGeoTools%252034%2520Releases%2f34.0%2f> . This release is available from the repo.osgeo.org <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PWtvPTBobDk6Pjs/MDloPDg7aGhsbTs4bTBsaz9sOjkxPWxoaGw5bC99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=http%3a%2f%2frepo.osgeo.org> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+YGFhNzE3MmAxNDM1YmJlNjNhOzpiYTpiYjc6NGU6N2BiNTRiOjQyZiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=http%3a%2f%2frepo.osgeo.org> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwbGw0Pms+O2g7NDs/aD84NT47PjloPj48O2g6PGw7OGxpbDg+aG44byt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=http%3a%2f%2frepo.osgeo.org> and is made in conjunction with ImageN 0.9.0, ImageIO-Ext 2.0.0, GeoWebCache 1.28.0, and GeoServer 2.28.0. This is a major update: * The library now requires Java 17, ending support for Java 11 * Upgrade from Java Advanced Imaging Library 1.1.3 to Eclipse ImageN 0.9.0. * Library now provides a maven bill-of-materials import for both library modules and third-party-dependences making it considerably easier for downstream projects to synchronize dependences when upgrading GeoTools * For more information please see upgrade instructions <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVE3PDg8Nyt7MD8jPStkaTA9PDc9PCt+ZGpjbHl4f2gwNDk1bjo7P2s0bms0OTk9aTo+a287a2k8PzlvbjhuaTw9PjtoPj81NSt5MDw6Ozw8ODQ1OjsrfGRpMDg0QEc5bGFpPT85NDs4IDg0QEc5bGFoPT85NDs4K39ufXkwXmJof2hjI0ZsYWh+fmhNaXppI2loK24wOD8rZWlhMD0=&url=https%3a%2f%2fdocs.geotools.org%2fstable%2fuserguide%2fwelcome%2fupgrade.html> in the user manual Thanks to Jody Garnett (GeoCat) for making this release, Gabriel Roldan (Camptocamp) for all the build improvements, and Andrea Aime (GeoServer) for working so hard on the Eclipse ImageN migration. These major library updates were undertaken as part of the GeoServer 3 activities, and we would like to the crowdfunding sponsors their financial support. _______________________________________________ GeoTools-GT2-Users mailing list [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]> > https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVs5MjYyOSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+Zmc0OmBnYDViNTA1NDdmMzMyNTQ6ZmIxYmcxNTJnNTMyNGJiNDU2NiV3PjI0NTI6MTM0OzolcmpnPjY6VUZSV3FGMzEyMTswLjY6VUZSV3FFMzEyMTswJXFgc3c+UGxmcWZtLUhib2ZwcGZDZ3RnLWdmJWA+NjEla2dvPjM=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> _______________________________________________ GeoTools-GT2-Users mailing list [email protected] <mailto:[email protected]> https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users <https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVUzODw4My9/NDsnOS9gbTQ5ODM5OC96YG5naH18e2w0PG88aDw7OW05Pj5rPGs5MTgwMG8xOTs/MG87Pj86aD4/PD86bTtqOS99NDg+Pzs6OT47MDkveGBtNDxIPDhkSGN5OTg/Pj46JDxIPDhkSGN4OTg/Pj46L3tqeX00WmZse2xnJ0JoZWx6emxJbX5tJ21sL2o0PDsvYW1lNDk=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users> _______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://ofcsg2dvf1.dwd.de/fmlurlsvc/?fewReq=:B:JVA0Pzs/NCh4MzwgPihnajM+PzQ+Pyh9Z2lgb3p7fGszPjZvNj46OTw7OTc/Ozs4aDc+PDttO21oPDxrPmg7OGpvazdob283Pyh6Mz85ODw9PTg4PToof2dqMztPOzd4S1pmPjw8PD85IztPOzd4S1pnPjw8PD85KHxtfnozXWFrfGtgIEVvYmt9fWtOanlqIGprKG0zOzwoZmpiMz4=&url=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fgeotools-gt2-users _______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
