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 <
andreas.waterme...@its-digital.de> 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 and Eclipse is
> quite slow especially on pom updates. Do you close the community module you
> are not responsible for?
>
> 2. What do you do in case your changes on for example GS platform breaks
> community code or community tests. Do you fix them? Or is the maintainer
> expected to jump in?
>
> 3. What is the expectation for the Jakarta EE migration regarding
> extensions and community code?
>
> 4. I wonder if you experience some specific problems, too and how you
> handle them. For example:
>
> 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.
>
> 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
