Re: [Geoserver-devel] -EXT-Re: build.geoserver geoserver-main-app-schema-online job maintenance / discussion.

[Lahr-Vivaz, Emilio]

Have you guys considered using testcontainers[1] for this type of test? The 
only requirement is a local docker install. I've found it very useful for 
testing postgis in a repeatable manner, both in CI and locally.

Thanks,

[1] https://java.testcontainers.org/modules/databases/postgres/

Emilio Lahr-Vivaz
General Atomics, CCRi

From: Andrea Aime 
Sent: Tuesday, July 9, 2024 4:19 AM
To: Jody Garnett 
Cc: Geoserver-devel 
Subject: -EXT-Re: [Geoserver-devel] build.geoserver 
geoserver-main-app-schema-online job maintenance / discussion.


WARNING:  This message is from an external source.  Evaluate the message 
carefully BEFORE clicking on links or opening attachments.

And oh, my local postgis database has the postgis extensions installed.


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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 Tue, Jul 9, 2024 at 10:18 AM Andrea Aime 
mailto:andrea.a...@geosolutionsgroup.com>> 
wrote:
Hi Jody,
the same way you run other online test cases in GeoTools.
For postgis, locally I have the following file in ~/.geoserver:

> cat postgis.properties
#This is an example fixture. Update the values and remove the .example suffix 
to enable the test
#Mon Jan 23 12:28:28 CET 2023
password=mysecret
database=app-schema
driver=org.postgresql.Driver
passwd=mysecret
port=5432
host=localhost
dbtype=postgisng
user=myuser
url=jdbc\:postgresql\://localhost/app-schema

And then with maven in the path:

cd extension/app-schema/app-schema-postgis-test/
mvn clean install  -Ponline -nsu -fae

If you had everything properly set up, the build should end with:

[INFO] Results:
[INFO]
[WARNING] Tests run: 319, Failures: 0, Errors: 0, Skipped: 1

I don't have an Oracle ready for usage but the postgis ones already provide a 
good coverage of
the common cases.



Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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 Tue, Jul 9, 2024 at 8:29 AM Jody Garnett 
mailto:jody.garn...@gmail.com>> wrote:
Niels,

How do you run the app-schema tests?


  1.  I create a ~/.geoserver/postgis.properties with connection parameters 
including a database name
  2.  And then run with:
mvn clean install -Papp-schema-online-test

When I run I get errors such as:

[ERROR] testNoPrimaryKey(org.geoserver.test.onlineTest.WfsOnlinePostgisTest)  
Time elapsed: 0.294 s  <<< ERROR!

Re: [Geoserver-devel] Thinking about community modules packaging

[Lahr-Vivaz, Emilio]

Apologies - since the upstream CVEs are already public, I didn't realize it was 
necessary to keep the discussion private.

Thanks,

Emilio Lahr-Vivaz
General Atomics, CCRi


From: Jody Garnett 
Sent: Thursday, May 30, 2024 11:14 AM
To: Lahr-Vivaz, Emilio 
Cc: GeoServer ; Andrea Aime 
; Gabriel Roldan 

Subject: Re: [Geoserver-devel] Thinking about community modules packaging

That is an email best sent to geoserver-security email list (where we figure 
out such stuff).

For more information please see our security policy 
https://github.com/geoserver/geoserver/security
--
Jody Garnett


On May 30, 2024 at 8:00:00?AM, "Lahr-Vivaz, Emilio" 
mailto:emilio.lahr-vi...@ga-ccri.com>> wrote:
Hey guys,

I don't want to put any additional work on anyone, but if anyone is feeling 
inspired, netty 4.1.41.Final has several high-severity CVEs out against it[1] 
(current latest is 4.1.110.Final).

Thanks,

Emilio Lahr-Vivaz
General Atomics, CCRi

[1]: https://github.com/netty/netty/security


From: Andrea Aime 
mailto:andrea.a...@geosolutionsgroup.com>>
Sent: Thursday, May 30, 2024 10:45 AM
To: Gabriel Roldan 
mailto:gabriel.rol...@camptocamp.com>>
Cc: GeoServer 
mailto:geoserver-devel@lists.sourceforge.net>>
Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Gabriel,
my plan would be to split the COG module into sub-parts, because when one needs 
to deploy on AWS, the azure libraries are not needed,
and vice versa. So make a packaging looking like:

  *   cog-core (http support)
  *   cog-aws
  *   cog-azure
  *   cog-google

That should hopefully solve the issue, because cog-azure uses the 
azure-storage-blob v11, just like the blobstore.


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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, May 30, 2024 at 4:38?PM Gabriel Roldan 
mailto:gabriel.rol...@camptocamp.com>> wrote:
I'm afraid this would solve the packaging issue but not the problem of 
deploying both the COG and the Azure blobstore extensions, as you'd end up with 
duplicate netty dependencies with incompatible versions.

In GeoServer Cloud I had to deal with this specific issue, using the 
"dependencyConvergence" maven enforcer plugin rule [1], and ensuring a single 
version of each duplicate dependency is in place. With the additional overhead 
of ensuring the plugins whose dependencies are overridden still work.

For the specific case of the netty version, I'm pegging it to 4.1.41.Final. 
Both COG and Azure blobstore work with that one.
The libs are in the pom's "dependencyConvergence" maven profile [3].

So probably we could do something similar in geoserver to ensure a single 
version of each dependency is ever present.
Though that'd probably open its own can of worms. Perhaps just making sure both 
COG and Azure blobstore carry over netty 4.1.41.Final would suffice for the 
time being, without a rewrite of the Azure blobstore?

[1] https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L904
[2] https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L30-L32
[3] 
https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L1070-L1124
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Gabriel Roldán
Geospatial Developer



On Wed, May 29, 2024 at 12:35?PM Lahr-Vivaz, Emilio 
mailto:emilio.lahr-vi...@ga-ccri.com>> wrote:
Sounds good, dependency sets do provide include/exclude filtering[1] (or if the 
pom already has things correctly scoped as provided vs compile then you can 
easily filter out provided), but I'm all 

Re: [Geoserver-devel] Thinking about community modules packaging

[Lahr-Vivaz, Emilio]

Hey guys,

I don't want to put any additional work on anyone, but if anyone is feeling 
inspired, netty 4.1.41.Final has several high-severity CVEs out against it[1] 
(current latest is 4.1.110.Final).

Thanks,

Emilio Lahr-Vivaz
General Atomics, CCRi

[1]: https://github.com/netty/netty/security


From: Andrea Aime 
Sent: Thursday, May 30, 2024 10:45 AM
To: Gabriel Roldan 
Cc: GeoServer 
Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Gabriel,
my plan would be to split the COG module into sub-parts, because when one needs 
to deploy on AWS, the azure libraries are not needed,
and vice versa. So make a packaging looking like:

  *   cog-core (http support)
  *   cog-aws
  *   cog-azure
  *   cog-google

That should hopefully solve the issue, because cog-azure uses the 
azure-storage-blob v11, just like the blobstore.


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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, May 30, 2024 at 4:38?PM Gabriel Roldan 
mailto:gabriel.rol...@camptocamp.com>> wrote:
I'm afraid this would solve the packaging issue but not the problem of 
deploying both the COG and the Azure blobstore extensions, as you'd end up with 
duplicate netty dependencies with incompatible versions.

In GeoServer Cloud I had to deal with this specific issue, using the 
"dependencyConvergence" maven enforcer plugin rule [1], and ensuring a single 
version of each duplicate dependency is in place. With the additional overhead 
of ensuring the plugins whose dependencies are overridden still work.

For the specific case of the netty version, I'm pegging it to 4.1.41.Final. 
Both COG and Azure blobstore work with that one.
The libs are in the pom's "dependencyConvergence" maven profile [3].

So probably we could do something similar in geoserver to ensure a single 
version of each dependency is ever present.
Though that'd probably open its own can of worms. Perhaps just making sure both 
COG and Azure blobstore carry over netty 4.1.41.Final would suffice for the 
time being, without a rewrite of the Azure blobstore?

[1] https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L904
[2] https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L30-L32
[3] 
https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L1070-L1124
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Gabriel Roldán
Geospatial Developer



On Wed, May 29, 2024 at 12:35?PM Lahr-Vivaz, Emilio 
mailto:emilio.lahr-vi...@ga-ccri.com>> wrote:
Sounds good, dependency sets do provide include/exclude filtering[1] (or if the 
pom already has things correctly scoped as provided vs compile then you can 
easily filter out provided), but I'm all for easy wins!

Thanks,

Emilio

[1]: 
https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html

Emilio Lahr-Vivaz
General Atomics, CCRi

From: Andrea Aime 
mailto:andrea.a...@geosolutionsgroup.com>>
Sent: Wednesday, May 29, 2024 11:15 AM
To: Lahr-Vivaz, Emilio 
mailto:emilio.lahr-vi...@ga-ccri.com>>
Cc: Jody Garnett mailto:jody.garn...@gmail.com>>; 
GeoServer 
mailto:geoserver-devel@lists.sourceforge.net>>
Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Emilio,
I'm aware of it, but there are issues... one one side, we want to package in 
the zip file only the jars that are not already covered by core.
The other bit is, even if there was a way to achieve the above, all 74 
community module packaging files would have to be individually rewritt

Re: [Geoserver-devel] Thinking about community modules packaging

[Lahr-Vivaz, Emilio]

Sounds good, dependency sets do provide include/exclude filtering[1] (or if the 
pom already has things correctly scoped as provided vs compile then you can 
easily filter out provided), but I'm all for easy wins!

Thanks,

Emilio

[1]: 
https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html

Emilio Lahr-Vivaz
General Atomics, CCRi

From: Andrea Aime 
Sent: Wednesday, May 29, 2024 11:15 AM
To: Lahr-Vivaz, Emilio 
Cc: Jody Garnett ; GeoServer 

Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Emilio,
I'm aware of it, but there are issues... one one side, we want to package in 
the zip file only the jars that are not already covered by core.
The other bit is, even if there was a way to achieve the above, all 74 
community module packaging files would have to be individually rewritten.

What I'm proposing is simple, mechanical, and can be at least partially 
automated, which means, it fits a small budget.
If we can party up with several people and attempt a technically better 
approach, so that my isolated effort is more or less the same,
I'm all for it!


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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 Wed, May 29, 2024 at 5:06 PM Lahr-Vivaz, Emilio 
mailto:emilio.lahr-vi...@ga-ccri.com>> wrote:
If it's helpful, the maven assembly plugin has a concept of 'dependencySets', 
which could replace some of the fileSets and allow you to avoid running 
dependencies:dependency-copy.

Thanks,

Emilio


From: Andrea Aime 
mailto:andrea.a...@geosolutionsgroup.com>>
Sent: Wednesday, May 29, 2024 10:40 AM
To: Jody Garnett mailto:jody.garn...@gmail.com>>
Cc: GeoServer 
mailto:geoserver-devel@lists.sourceforge.net>>
Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Jody.
yes each module would have the assembly configuration local, besides its 
pom.xml.
I've made a small experiment, on the COG module alone, this should work:


  cog-plugin
  
zip
  
  false
  

  target/dependency
  
  
annotations-2.*.jar
auth-2.*.jar
aws-*-2.*.jar
azure-storage*.jar
checksums-*2*.jar
client-runtime*.jar
crt-core-*-2*.jar
endpoints-spi-2*.jar
gs-cog*.jar
http-auth-*2*.jar
http-client-spi-2*.jar
http*-osgi*.jar
imageio-ext-*rangereader*.jar
identity-spi*.jar
jackson-datatype*.jar
jackson-module*.jar
kotlin-stdlib*.jar
metrics-spi-2.*.jar
*netty*.jar
okhttp*.jar
okio*.jar
profiles-2.*.jar
protocol-core-2.*.jar
reactive-streams*.jar
regions-2.*.jar
rxjava*.jar
s3-2.*.jar
sdk-core-2.*.jar
utils-2.*.jar
  


  target
  
  
gs-cog*.jar
  

  


To work, it still requires dependencies:dependency-copy to run, which we can 
either have running
subject to a flag, or move it as part of the explicit build instructions.


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

---

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezi

Re: [Geoserver-devel] Thinking about community modules packaging

[Lahr-Vivaz, Emilio]

If it's helpful, the maven assembly plugin has a concept of 'dependencySets', 
which could replace some of the fileSets and allow you to avoid running 
dependencies:dependency-copy.

Thanks,

Emilio


From: Andrea Aime 
Sent: Wednesday, May 29, 2024 10:40 AM
To: Jody Garnett 
Cc: GeoServer 
Subject: Re: [Geoserver-devel] Thinking about community modules packaging

Hi Jody.
yes each module would have the assembly configuration local, besides its 
pom.xml.
I've made a small experiment, on the COG module alone, this should work:


  cog-plugin
  
zip
  
  false
  

  target/dependency
  
  
annotations-2.*.jar
auth-2.*.jar
aws-*-2.*.jar
azure-storage*.jar
checksums-*2*.jar
client-runtime*.jar
crt-core-*-2*.jar
endpoints-spi-2*.jar
gs-cog*.jar
http-auth-*2*.jar
http-client-spi-2*.jar
http*-osgi*.jar
imageio-ext-*rangereader*.jar
identity-spi*.jar
jackson-datatype*.jar
jackson-module*.jar
kotlin-stdlib*.jar
metrics-spi-2.*.jar
*netty*.jar
okhttp*.jar
okio*.jar
profiles-2.*.jar
protocol-core-2.*.jar
reactive-streams*.jar
regions-2.*.jar
rxjava*.jar
s3-2.*.jar
sdk-core-2.*.jar
utils-2.*.jar
  


  target
  
  
gs-cog*.jar
  

  


To work, it still requires dependencies:dependency-copy to run, which we can 
either have running
subject to a flag, or move it as part of the explicit build instructions.


Regards,

Andrea Aime


==
GeoServer Professional Services from the experts!

Visit 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://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_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 Wed, May 29, 2024 at 4:35?PM Jody Garnett 
mailto:jody.garn...@gmail.com>> wrote:
I would like to see each module contains its own assembly, it would make things 
more normal.

Initially we made the release module to force assembly to occur at the end, and 
to avoid taking the time to build download artifacts during day to day 
development.

We could keep the release profile and only build zip download bundles when it 
is used.
--
Jody Garnett


On Wed, May 29, 2024 at 1:15?AM Andrea Aime 
mailto:andrea.a...@geosolutionsgroup.com>> 
wrote:
Hi all,
I've got reports that the COG community module packaged zip bundles are not 
working any
longer. Looking into it, it seems there are conflicting versions of 
dependencies that are causing the trouble.

As you probably know, the packaging is currently done this way:

  *   A "release" module depends on all the modules that want to be packages
  *   The release module dumps all these module dependencies into a single 
directory
  *   Each module packaging descriptor picks from that pile of jars using globs

Now, we already had some issues with incompatible dependency versions, but we 
more or less managed. Now there is a group of 3 different community modules 
that depend, in turn, to AWS and Azure  cloud libraries, which in turn depend 
on Netty. Unfortunately, two different and incompatible versions of it.
Ideally, we could just upgrade the Azure blob storage library in GWC, but that 
amounts to a rewrite of the module.

Rather than doing that, I'd suggest to untangle community module packaging in 
the simplest possible way:

  *   Have each module collect its own dependencies in target/dependencies when 
a specific profile is used (e.g., -Passembly?)
  *   Have the assembly descriptor point at its own module
  *   Get rid of the "release" module

Ideally we could do that for extensions as well, but I'd try that with 
community modules first.

Thoughts?


Regards,

Andrea Aime


==

Re: [Geoserver-devel] -EXT-Re: Jakarta EE upgrade support

[Lahr-Vivaz, Emilio]

Hi Jody!

I'm still trying to work through approval for us to do the work, so we can't 
firmly commit to anything quite yet. But with that understanding, if our 
participation helps attract others, then that would be great! We'll probably be 
able to commit (or not) to something in June. At any rate, it looks like there 
is definitely work we could do, so that should help with getting approval. I'll 
stay in touch over the next few weeks until we can firm up a plan.

Thanks,

Emilio Lahr-Vivaz
General Atomics, CCRi

From: Jody Garnett 
Sent: Monday, May 13, 2024 12:17 PM
To: Lahr-Vivaz, Emilio 
Cc: geoserver-devel@lists.sourceforge.net 

Subject: -EXT-Re: [Geoserver-devel] Jakarta EE upgrade support


WARNING:  This message is from an external source.  Evaluate the message 
carefully BEFORE clicking on links or opening attachments.

Hello Emilio!

It is really nice to hear from CCRi thank you for contacting us.  It would be 
*very* helpful, while a fair amount of work is outlined (planning ahead) only a 
few activities are moving.

It is always a risk sharing roadmap information for an open source project from 
a funding perspective.

I am going to write an update Q2 roadmap blog post focusing just on:

  *   Goals that are in progress now - Wicket Update
  *   Goals that are actionable now - Spring-security update/rewrite for OAuth2 
client / ImageN
  *   Upcoming activities that have attracted in-kind or financial support

Thus far we have not gotten sufficient financial / inkind response response to 
do planning, but at least folks are talking :)​

If it is okay with you I will list CCRi as committed for spring-framework 
update 'in-kind" activity in the hopes of attracting greater participation:

  *   My understanding is if we add some Java startup parameters to "open 
javax" this activity could be worked ahead of ImageN availability.
  *   Even if spring-framework upgrade cannot be worked on directly in July - 
some of the actives will be available and unblocked
  *   If I know CCRi is available I can work with my employer GeoCat to be 
available in July-September timeframe


Thanks
--
Jody Garnett


On Mon, May 13, 2024 at 7:07 AM Lahr-Vivaz, Emilio 
mailto:emilio.lahr-vi...@ga-ccri.com>> wrote:
Hello,

My company is interested in running GeoServer with Spring 6, and considering if 
we can provide development support to help with that upgrade. I see from the 
roadmap<https://github.com/geoserver/geoserver/wiki/Jakarta-EE> that there is a 
fair amount of work in progress, and a lot left to do. Would development work 
in the July-September time frame be helpful, and if so are there any particular 
tasks we could sign up for?

Thanks,

Emilio

Emilio Lahr-Vivaz
General Atomics, CCRi
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Jakarta EE upgrade support

[Lahr-Vivaz, Emilio]

Hello,

My company is interested in running GeoServer with Spring 6, and considering if 
we can provide development support to help with that upgrade. I see from the 
roadmap that there is a 
fair amount of work in progress, and a lot left to do. Would development work 
in the July-September time frame be helpful, and if so are there any particular 
tasks we could sign up for?

Thanks,

Emilio

Emilio Lahr-Vivaz
General Atomics, CCRi
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel