-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
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: |
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Deleted |
Current directory structure is (simplified, e.g. omitting the
test
directories):This layout has many issues:
--module-path
.We also need to reorganize the specification in ASCIIDoc format to match the OGC standard template. A proposal is available on the restructuring branch:
Notes:
org.geoapi.foo
directories) undersrc/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.standard
directory is normative. In particular theorg.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.org.opengis.geoapi.bridge.python
module is required for runningorg.opengis.geoapi.conformance
on a Python implementation.The text was updated successfully, but these errors were encountered: