Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize project directory structure #30

Closed
desruisseaux opened this issue Apr 28, 2018 · 2 comments
Closed

Reorganize project directory structure #30

desruisseaux opened this issue Apr 28, 2018 · 2 comments
Assignees

Comments

@desruisseaux
Copy link
Contributor

desruisseaux commented Apr 28, 2018

Current directory structure is (simplified, e.g. omitting the test directories):

  geoapi
   ├─ geoapi
   │   └─ src
   │       └─ main
   │           ├─ java
   │           │   └─ org
   │           │       └─ opengis
   │           │           └─ metadata, etc.
   │           └─ python
   │               └─ ogc
   │                   └─ metadata, etc.
   ├─ geoapi-pending
   ├─ geoapi-conformance
   ├─ geoapi-java-python
   ├─ geoapi-examples
   ├─ geoapi-netcdf
   ├─ geoapi-proj4
   ├─ geoapi-gdal
   └─ src
       └─ main
           └─ asciidoc
               └─ specification.adoc

This layout has many issues:

  • No clear separation between standard parts, bridges and examples.
  • Incompatible with Java 9 modularization (Jigsaw) using --module-path.
  • Files related to the same language (Java or Python) are spread far to each other.
  • Difficult to find code examples because of explosion in amount of folders.

We also need to reorganize the specification in ASCIIDoc format to match the OGC standard template. A proposal is available on the restructuring branch:

geoapi
 ├─ pom.xml
 ├─ standard
 │   ├─ pom.xml
 │   ├─ asciidoc
 │   │   └─ specification.adoc
 │   ├─ java
 │   │   ├─ org.opengis.geoapi
 │   │   │   ├─ classes
 │   │   │   │   └─ org
 │   │   │   │       └─ opengis
 │   │   │   │           ├─ metadata
 │   │   │   │           └─ referencing
 │   │   │   └─ tests
 │   │   │       └─ org
 │   │   │           └─ opengis
 │   │   │               ├─ metadata
 │   │   │               └─ referencing
 │   │   ├─ org.opengis.geoapi.conformance
 │   │   └─ org.opengis.geoapi.bridge.python
 │   └─ python
 │       ├─ ogc
 │       │   ├─ metadata.py
 │       │   ├─ referencing.py
 │       │   └─ bridge
 │       │       └─ java.py
 │       └─ test_metadata.py
 └─ examples
     ├─ pom.xml
     ├─ java
     │   ├─ org.opengis.geoapi.examples
     │   ├─ org.opengis.geoapi.wrapper.netcdf
     │   ├─ org.opengis.geoapi.wrapper.proj4
     │   └─ org.opengis.geoapi.wrapper.gdal
     └─ python
         └─ ogc
             └─ wrapper
                 └─ gdal.py

Notes:

  • This restructuring abandons the Maven standard directory layout, since I have been unable to meet above-cited goals with that layout. For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (MJAVADOC-449).
  • Insertion of Jigsaw modules (org.geoapi.foo directories) under src/main/java is not Maven-standard, but those directories are Java-standard since JDK 9 when using Java tools with --module-path option. This is an incompatibility between Maven conventions and Jigsaw conventions which is one reason why we abandon Maven contentions.
  • Not everything in the standard directory is normative. In particular the org.opengis.geoapi.pending module shall not be included in any OGC standard. It is there only during development, for making easier to experiment new features.
  • The org.opengis.geoapi.bridge.python module is required for running org.opengis.geoapi.conformance on a Python implementation.
@desruisseaux
Copy link
Contributor Author

desruisseaux commented Aug 28, 2018

Created a new branch for experimenting the directory layout reorganization:

This branch does not compile yet and will probably be rebased often. It is provided only for discussion and experimentation purposes.

Also created a project and wiki page for changes in Maven plugins:

desruisseaux added a commit that referenced this issue Aug 30, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 1, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 5, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 6, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 8, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 10, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 16, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 19, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Sep 19, 2018
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue Jan 1, 2019
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
desruisseaux added a commit that referenced this issue May 1, 2019
  - better separation between standard parts, bridges and examples;
  - better compatibility with Java 9 modularization (Jigsaw);
  - move closer the files related to the same language (Java or Python);
  - make easier to find code examples (reduce the explosion of folders).

This restructuration forces us to abandon the Maven standard directory layout, as I have been unable to meet above-cited goals with that layout.
For example there is still no way to generate satisfying aggregated Javadoc with Maven on Jigsaw (https://issues.apache.org/jira/browse/MJAVADOC-449).
This commit moves files and modifies some configurations, but many hard-coded paths are not yet changed (pending evaluation of this restructuration proposal).
Consequently the project at this commit is known to not build yet. To make the project buildable will require modifications of some Maven plugins.
The "pom-foo.xml" files are temporary; they may move again or be replaced by work performed by modified Maven plugins.

See #30 for more information.
@desruisseaux desruisseaux self-assigned this Jun 23, 2019
@desruisseaux
Copy link
Contributor Author

Deleted restructuring branch. It has not been updated for 4 years. We abandon the plan to deviate from Maven conventions in this project. Instead, the problems raised in this issue are partially resolved by moving demonstration implementations to separated projects, in particular:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant