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 > <https://www.google.com/maps/search/Dillenburger+Str.+77+%7C+51105+K%C3%B6ln?entry=gmail&source=g> > +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 <jody.garn...@gmail.com> > Gesendet: Samstag, 3. Februar 2024 05:52 > An: Watermeyer, Andreas <andreas.waterme...@its-digital.de> > 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: <unnamed>, 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 <mailto: > 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: <unnamed>, 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 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? > > c) Eclipse: Cannot nest > "gs-rest-openapi-generated-feign-client/target/generated-sources/openapi/src/main/java" > inside "gs-rest[...]". > > Thank you for your support and have a nice weekend! > > Andreas > > > > ITS Digital Solutions GmbH > Dillenburger Str. 77 | 51105 Köln > <https://www.google.com/maps/search/Dillenburger+Str.+77+%7C+51105+K%C3%B6ln?entry=gmail&source=g> > +49 231 222 49 370 > mailto:andreas.waterme...@its-digital.de > http://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 > > > > _______________________________________________ > Geoserver-devel mailing list > 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
