TestInterface and base-package

[tsdh]

The setProgramLocation(String path) tells a solution which java program to be parsed and createProgramGraph(String path) is called by ARTE and should return the program graph.

Where's the difference between the two path parameters? Is the path of createProgramGraph(String path) actually the base-package of the part of the java program we can assume as writeable and should be considered by the refactorings? (If I remember correctly, you've said that we may assume that all user-classes will be contained in some common base package.)

[SvenPeldszus]

There is no difference between the two parameters. The different methods are just for internal reasons.

In the basic challenge the method createProgramGraph(String path):Boolean can return any value as this should not be called.

In the extended challenge an empty implementation of setProgramLocation(String path) is suitable.

The String path points always to a folder, which always contains a src\ folder. In this src\ folder the packages are represented as a tree of folders.

In the example below path will be \absolute_path_to tmp\project\. The namespace of all user defined classes will start with base_package and there is no not user defined class used in the program whose namespace begins with base_package.

Paths to java files:

\absolute_path_to tmp\project\src\base_package\a\b\c\Foo.java
\absolute_path_to tmp\project\src\base_package\a\d\Bar.java
\absolute_path_to tmp\project\src\base_package\e\Qux.java

Java program

package base_package.a.b.c;

public class Foo{};

package base_package.a.d;

public class Bar{};

package base_package.e;

public class Qux{};

The location path points to is writable as the changes have to be written to this location.

[tsdh]

Ah, so I can assume that user-defined classes are contained directly or indirectly in a package with qualified name base_package and that is hard-coded, right?

[SvenPeldszus]

Yes, user-defined classes are contained directly or indirectly within the base package.

The base package can have any name.

However, as soon as during a refactoring classes with different base packages are detected the refactoring is not possible. There will be no refactoring which takes entirely place on a library.

[tsdh]

Then I don't understand. How can I determine the base package name from the path given to setProgramLocation() or createProgramGraph()?

[SvenPeldszus]

The name of the base package it self is not relevant in the case. We guarantee there is always at least one user defined class which has to be changed (maybe this change is not allowed) part of a refactoring. Therefore it is sufficient to check if all classes which will be changed have the same base package.

My self I search for all java files in the src\ located at the path and derive the names from the package declarations. Thereby I assume all java files are editable. Per definition all classes contained in this files have the same base package and the name of the base package is the first entry of the packages the classes are located in.

If you want to get the package names from the path this is also possible.

As all user defined classes have the same base package there is at the path always only a single folder with the name of this base package in the src\ folder. This folder contains then folders representing the subpackages and finally the java files in the according folders.

[tsdh]

Ok. The reason I'm picky about that is that I use JaMoPP to parse the sources, and JaMoPP generates classes not only for the parsed sources but also for the classes the sources use, e.g., the jamopp model also contains classes for, e.g., java.lang.String or foo.bar.Baz in case the source uses some foo.bar-17.3.jar library, and then I can't distinguish which classes came from sources and which from jars.

So do I get it correctly that I get a path like /tmp/programX/ I can assume that there is some /tmp/programX/src/ folder containing, e.g., /tmp/programX/src/quux/Quux.java and thus quux is the base package?

[SvenPeldszus]

Yes, for our programs you can always assume this.

[tsdh]

Perfect, thanks.