Re: [Geoserver-devel] Eclipse Setup

[Jody Garnett]

Everyone does what they like - we have build tools to keep formatting
consistent (which makes life easier for everyone).

Personally I use both IntelliJ and maven+text editor as the situation
warrants. I use eclipse for large refactoring - although we did the last
refactoring using scripts so it was crazy.

I believe you can get Eclipse to work if that is your preferred choice. I
would focus on maven integration and ignore the rest.

Note: in IntelliJ I have to turn off a lot of the spring framework and
JavaEE helpers because geoserver is split across so many modules the IDE
produces warnings and confusion.
--
Jody Garnett


On Sat, Feb 3, 2024 at 8:54 AM Watermeyer, Andreas <
andreas.waterme...@its-digital.de> wrote:

> Hi Jody,
>
> thanks for your explanations, that helps me.
>
> Regarding the IDE:
> Has the project agreed on the use of a different IDE or does everyone
> follow their personal preference?  What do you think is used by the
> majority?
>
> --
> Andreas Watermeyer
>
>
>
>ITS Digital Solutions GmbH
>Dillenburger Str. 77 | 51105 Köln
> 
>+49 231 222 49 370
>andreas.waterme...@its-digital.de
>www.its-digital.de
>
>
>
> Sitz der Gesellschaft: Dortmund, Amtsgericht Dortmund, HRB 28563
> Geschäftsführer: Ludger Schulte, Gunnar Haack, Ralf Petersilka, Raimund
> Schipp, Heinrich Toben
>
> Von: Jody Garnett 
> Gesendet: Samstag, 3. Februar 2024 05:52
> An: Watermeyer, Andreas 
> Cc: geoserver-devel@lists.sourceforge.net
> Betreff: Re: [Geoserver-devel] Eclipse Setup
>
> [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful
> when opening links and attachments.
> It has been a couple years since I used Eclipse IDE personally.  I found
> it was important to do one run on the command line to make the generated
> code directories so the IDE could see them.
>
> For community modules we try and respect that they are experiments and
> ensure they compile (so take part in any refactoring) - but we do not offer
> them CPU cycles for testing on our build server (they are not stable enough
> to always pass tests).
>
> We know for the work ahead that OAuth community plugins need to be
> rewritten; if possible I would like to have one release cycle where new
> community module for OIDC is made alongside the older one to allow folks to
> migrate. But really for such an important component it difficult to
> understand why they have not attracted funding to be stable.
>
> So goal is:
> 1. include community module in refactor with the goal of compiling
> 2. Include community module in dependency upgrade with goal of compiling
> 3. When dependency upgrade cannot even compile (sigh) spend a few minuets
> to determine why, comment the plugin of the “release” profile, and notify
> the developer
>
> 1. How do you handle the extensions and the community modules
>
> Yes it does, I think this is why I stopped using Eclipse.
>
> 2. What do you do in case your changes on for example GS platform breaks
> community code or community tests.
>
> The priority is the code: do whatever you can to make it compile.
> If you really cannot get it to compile (say due to a dependency change)
> drop it from the build.
> The tests are not a priority at all, they are not included in the build.
>
> Your time as a volunteer is to be respected.
>
> 3. What is the expectation for the Jakarta EE migration regarding
> extensions and community code?
>
> Extensions are part of the GeoServer application and will be migrated.
> They are only optional to download, not optional to the GeoServer story.
> The module maintainer put enough enough tests to help us as maintainers
> just for situations like this.
> (We experienced this first hand with the big bad geotools refactor last
> year, the test coverage for GeoServer is really good and it makes the code
> much more maintainable).
>
> Community modules are experiments, and to be treated as such. There tests
> do not need to pass, or even be run.
>
> We have to respect our time as volunteers.
>
> 4. I wonder if you experience some specific problems, too and how you
> handle them
>
> a) In geofence: "The package javax.xml.namespace is accessible from more
> than one module: , java.xml". This causes a chain of compiler
> errors for me in Eclipse. Similar in other projects.
>
> During the api change last year we had to make a branch on the geofence
> project and work in parallel.
> The same for geowebcache, and mapfish-print-v2.
>
> b) Eclipse has trouble with "GeoServerTestSupport" because it is
> referenced tests of dependent projects, but it resides in
> gs-main/src/test/java, where it is not avaible for reuse. Normally it would
> expect that GeoServerTestSupport is in src/main/java of a test project or
> gs-main is an additional "test-jar" dependency. How do you handle that?
>
> I remember being able to add a test dependency or something in eclipse. It
> is unusual but 

Re: [Geoserver-devel] Eclipse Setup

[Watermeyer, Andreas]

Hi Jody,

thanks for your explanations, that helps me.

Regarding the IDE: 
Has the project agreed on the use of a different IDE or does everyone follow 
their personal preference?  What do you think is used by the majority?

--
Andreas Watermeyer



   ITS Digital Solutions GmbH
   Dillenburger Str. 77 | 51105 Köln
   +49 231 222 49 370
   andreas.waterme...@its-digital.de
   www.its-digital.de



Sitz der Gesellschaft: Dortmund, Amtsgericht Dortmund, HRB 28563
Geschäftsführer: Ludger Schulte, Gunnar Haack, Ralf Petersilka, Raimund Schipp, 
Heinrich Toben

Von: Jody Garnett  
Gesendet: Samstag, 3. Februar 2024 05:52
An: Watermeyer, Andreas 
Cc: geoserver-devel@lists.sourceforge.net
Betreff: Re: [Geoserver-devel] Eclipse Setup

[Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when 
opening links and attachments.
It has been a couple years since I used Eclipse IDE personally.  I found it was 
important to do one run on the command line to make the generated code 
directories so the IDE could see them. 

For community modules we try and respect that they are experiments and ensure 
they compile (so take part in any refactoring) - but we do not offer them CPU 
cycles for testing on our build server (they are not stable enough to always 
pass tests).

We know for the work ahead that OAuth community plugins need to be rewritten; 
if possible I would like to have one release cycle where new community module 
for OIDC is made alongside the older one to allow folks to migrate. But really 
for such an important component it difficult to understand why they have not 
attracted funding to be stable.

So goal is:
1. include community module in refactor with the goal of compiling
2. Include community module in dependency upgrade with goal of compiling
3. When dependency upgrade cannot even compile (sigh) spend a few minuets to 
determine why, comment the plugin of the “release” profile, and notify the 
developer

1. How do you handle the extensions and the community modules

Yes it does, I think this is why I stopped using Eclipse.

2. What do you do in case your changes on for example GS platform breaks 
community code or community tests.

The priority is the code: do whatever you can to make it compile.
If you really cannot get it to compile (say due to a dependency change) drop it 
from the build.
The tests are not a priority at all, they are not included in the build.

Your time as a volunteer is to be respected.

3. What is the expectation for the Jakarta EE migration regarding extensions 
and community code?

Extensions are part of the GeoServer application and will be migrated. They are 
only optional to download, not optional to the GeoServer story.
The module maintainer put enough enough tests to help us as maintainers just 
for situations like this.
(We experienced this first hand with the big bad geotools refactor last year, 
the test coverage for GeoServer is really good and it makes the code much more 
maintainable).

Community modules are experiments, and to be treated as such. There tests do 
not need to pass, or even be run.

We have to respect our time as volunteers.

4. I wonder if you experience some specific problems, too and how you handle 
them

a) In geofence: "The package javax.xml.namespace is accessible from more than 
one module: , java.xml". This causes a chain of compiler errors for me 
in Eclipse. Similar in other projects.

During the api change last year we had to make a branch on the geofence project 
and work in parallel. 
The same for geowebcache, and mapfish-print-v2.

b) Eclipse has trouble with "GeoServerTestSupport" because it is referenced 
tests of dependent projects, but it resides in gs-main/src/test/java, where it 
is not avaible for reuse. Normally it would expect that GeoServerTestSupport is 
in src/main/java of a test project or gs-main is an additional "test-jar" 
dependency. How do you handle that?

I remember being able to add a test dependency or something in eclipse. It is 
unusual but maven supports doing so.

c) Eclipse: Cannot nest 
"gs-rest-openapi-generated-feign-client/target/generated-sources/openapi/src/main/java"
 inside "gs-rest[...]".

I would talk to Gabe about that - it looks very cool.  I assume it is an 
integration test. A generated maven project that eclipse has picked up?
I do not think you edit that code directly, somehow ignore it from Eclipse and 
trust the command line to run that integration test.

Have a good weekend yourself.

--
Jody Garnett


On Fri, Feb 2, 2024 at 10:23 AM Watermeyer, Andreas 
 wrote:
Hi community,

I am trying to setup Eclipse 2023-12 with JDK 11 for the GeoServer project to 
support in the Jakarta EE migration. I use the main branch and I pretty much 
followed the developer guide. I have a couple of questions though:

1. How do you handle the extensions and the community modules: The workspace 
gets pretty big having all those projects open