$ref generates classes in wrong package

[LitschiW]

Hi there,

love the project so far, but I just ran into a weird problem.
The issue is rather similar to #410, which was closed some years ago. However, I'm still experiencing a very similar issue using the maven plugin version 1.2.1.

When having 3 sibling directories, of which 2 references the third, running jsonschema2pojo will generate the classes of the third (dependencyless) directory in the package of the first reference.

---

Example

Input:

• parent_dir
  • dir1
    • schema1.json
  • dir2
    • schema2.json
  • dir3
    • schema3.json

Schemas 1 and 2 have a $ref to ../dir3/schema3.json#.

Output:

• parent_dir
  • dir1
    • schema1.java
    • schema3.java
    • ... (all other by-product classes of schema1 and schema3)
  • dir2
    • schema2.java

The Imports are resolved correctly and this compiles fine. However, I would expect schema3 to be generated in a package dir3.
Also note that the existence of dir2 is not relevant to demonstrate the problem, but rather to show that the classes will be generated in the same package as their first reference.

---

I have the following plugin configuration:

 <plugin>
                <groupId>org.jsonschema2pojo</groupId>
                <artifactId>jsonschema2pojo-maven-plugin</artifactId>
                <version>1.2.1</version>
                <configuration>
                    <sourceDirectory>${basedir}/../../schemas</sourceDirectory>
                    <includes>
                        <include>**/*.json</include>
                    </includes>
                    <outputDirectory>${basedir}/src/main/java/</outputDirectory>

                    <targetPackage>dqualizer.dqlang.types</targetPackage>
                    <removeOldOutput>false</removeOldOutput>
                    <useTitleAsClassname>true</useTitleAsClassname>

                    <useOptionalForGetters>true</useOptionalForGetters>
                    <usePrimitives>true</usePrimitives>

                    <includeSetters>false</includeSetters>
                    <includeGetters>false</includeGetters>


                    <includeConstructors>true</includeConstructors>
                    <includeConstructorPropertiesAnnotation>true</includeConstructorPropertiesAnnotation>
                    <includeAllPropertiesConstructor>true</includeAllPropertiesConstructor>
                    <includeCopyConstructor>true</includeCopyConstructor>


                    <includeJsr303Annotations>true</includeJsr303Annotations>
                    <includeJsr305Annotations>true</includeJsr305Annotations>

                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

---

If you want to see this in practice, you can take a look at our repository. By now we have moved away from jsonschema2pojo but you can still reproduce the bug:

git clone -b Insturmentation_Definition git@github.com:dqualizer/dqlang.git
cd dqlang
git checkout tags/v0.3.1 generators/java && cd generators/java && mvn compile && cd ../..

After that, you can see that there is a schemas/architecture/service.json files which uses $ref to references (transitively) all schemas from schemas/instrumentation. The generation output which is under generators/java/src/main/java/dqualizer/dqlang/types then contains an architecture package that includes ServiceDescription.java (as expected) but also all classes generated from the schemas of schemas/instrumentation which I would expect to be in a package instrumentation.
If you want to play around further with this; add a ref to the instrumentation schema to a schema in the adapter folder and see that the classes are now generated in the adapter package, but will be referenced correctly from the classes that reside in the architecture package.

[unkish]

Hi

If you want to see this in practice, take a look at https://github.com/dqualizer/dqlang/tree/Insturmentation_Definition/generators/java (be aware that this is not the main branch.)

Not quite sure what to look at as there are a lot of schemas that end up generating 58 files.

[LitschiW]

Hi there. Sry I forgot to point out these details. I Updated the description accordingly.

[unkish]

I think that #410 may have been closed as solution was to use javaType extension property to make output predictable/deterministic.
There's a good explanation of how/why it works like that here as well as suggestion how to change the behavior:

For now though, you can see that without javaType you can get some unexpected results