[proposal] check packages names

[guiguilechat]

Issue

The JDefinedClass constructor checks the validity of the class name, starting here :

https://github.com/phax/jcodemodel/blob/master/src/main/java/com/helger/jcodemodel/JDefinedClass.java#L214

The JPackage constructor, does not, here :

https://github.com/phax/jcodemodel/blob/master/src/main/java/com/helger/jcodemodel/JPackage.java#L116

Proposal

I propose to make the JPackage make a verification test

https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

according to this :

• sName must not be a reserved keyword
• sName must not contain non-alphanumerical value besides the underscore
• sName must not start with a number.
• (optional) sName must not contain an upper-case character.

Implementation

Here is how I personally do :

Reserved keyword

I keep a list from https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html

/** java keywords we can't use as a name for a package or a class */
public static final Set<String> JAVA_RESERVED_KEYWORDS = Collections.unmodifiableSet(new HashSet<>(
		Arrays.asList("abstract", "assert", "boolean", "break", "byte", "case", "catch", "char", "class", "const",
				"continue", "default", "do", "double", "else", "extends", "false", "final", "finally", "float", "for", "goto",
				"if", "implements", "import", "instanceof", "int", "interface", "long", "native", "new", "null", "package",
				"private", "protected", "public", "return", "short", "static", "strictfp", "super", "switch", "synchronized",
				"this", "throw", "throws", "transient", "true", "try", "void", "volatile", "while")));

Then I just check if the name is contained in that set.

All alphanumerical, start with non-numerical

public static final Pattern VALID_PACKAGE_NAME = Pattern.compile("[A-Za-z_][A-Za-z0-9_]*");

Then I just check if sName matches this pattern. It can accept "_" as a package name, not sure if correct.

Optional check lowercase

Add a boolean option in JCodeModel::ensurePackagesLowerCase(). default value should be false.
Then create a new Pattern to match the package name

public static final Pattern VALID_LOWERCASE_PACKAGE_NAME = Pattern.compile("[a-z_][a-z0-9_]*");

To test the name against.

[guiguilechat]

Just saying, this is actually an issue because it generates invalid java code.
Which is then much harder to debug. In my case I had a web API with a resource whose resource path contained assets[raw] or something like that. This crashed much later in the compilation process, when I needed to access the generated classes.

Of course it is not an issue if we accept to generate invalid package names, but then it's an inconsistency because the classes do not allow invalid class names.

[phax]

@guiguilechat Thanks for the very verbose request :)
I agree, it makes sense.
The keyword list is already present in class JJavaName.
I will make the suggestion for lower case optional for backwards compatibility.

[glelouet]

if (isForbiddenPackageNamePart (sPart))
throw new IllegalArgumentException ("The package name '" + sName + "' is invalid");
}

should print the sPart : "The subpackage name " +sPart+" is invalid in package "+sName

??

[glelouet]

// May not be a keyword
try
{
  aCM._package ("org.example.var");
  fail ();
}
catch (final IllegalArgumentException ex)
{}

var is not a reserved keyword.

public static void var.MyClass::main(){var var = 12;}

is correct (just checked)

[glelouet]

sorry I have issues switching accounts.

BTW you can just add "fixed #70" or "fix #70" in the commit and it will auto close the issue ;)

[glelouet]

Let me tell you, sir, about our lord and savior maven.

Release plugin

I would advise you to use the maven release module

mvn clean release:prepare release:perform

which automatically changes the versions, while still working on the snapshot .

However there are a few issues, eg it may break because compilation phases have non-deterministic effect (don't use the mvn clean in that case : instead make two separate calls mvn clean install && mvn release:prepare release:perform .

Other issues is that you may crash and add a tag in local and remote that will later prevent you from actually updating the value to the next version. In that case, delete the tag from local and remote repository with eg mvn release:rollback; git tag -d 1.2.3 && git push --delete origin 1.2.3 if you were at the version 1.2.3-SNAPSHOT before release and you asked to release the 1.2.3 when it failed.

You also need to set your csm to a correct value. Here is mine for Jswagermaker :

<scm>
	<url>https://github.com/glelouet/JSwaggerMaker</url>
	<connection>scm:git:git@github.com:glelouet/JSwaggerMaker</connection>
      <developerConnection>scm:git:git@github.com:glelouet/JSwaggerMaker</developerConnection>
	<tag>HEAD</tag>
</scm>

and the distributionManagement part .

skip javadoc

Also you can ask mvn to not create the javadoc (a single property in the root pom)
Here are a few properties I often use :

<properties>
	<maven.javadoc.skip>true</maven.javadoc.skip>
</properties>

I think it is un necessary when you already export the sources ^^

specify maven version and encoding

<properties>
	<java.version>11</java.version>
	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

java.version is used in the maven-compiler-plugin to enforce the compilation against a specific version.

<build>
	<plugins>
		<plugin>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>3.7.0</version>
			<configuration>
				<release>${java.version}</release>
			</configuration>
		</plugin>

encoding is specified to be sure everybody gets the code correctly even mac users :)

Attach sources on deploy

use the plugin, Luke :

<build>
	<plugins>
		<plugin>
			<artifactId>maven-source-plugin</artifactId>
			<version>3.1.0</version>
			<executions>
				<execution>
					<id>attach-sources</id>
					<goals>
						<!-- -no-fork prevents from compiling twice -->
						<goal>jar-no-fork</goal>
					</goals>
				</execution>
			</executions>
		</plugin>

as written no-fork prevents from doing it both in the compile and release parts or something like that.

Export to an ftp server

you still need the server configuration in your LOCAL pom.

	<extensions>
		<!-- Enabling the use of FTP -->
		<extension>
			<groupId>org.apache.maven.wagon</groupId>
			<artifactId>wagon-ftp</artifactId>
		</extension>
	</extensions>

if it crashes, you need to specify the plugin version in the dependency management.(yeah sometimes maven sucks)

[phax]

haha. Okay, will take 'var' off the list again. And of course I know the release plugin. Give me some time to check the other proposal first ;)

[phax]

Part of 3.3.0 release