[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787784#comment-17787784
]
Alexander Kriegisch edited comment on XALANJ-2710 at 11/20/23 2:56 AM:
-----------------------------------------------------------------------
[~vladimirsitnikov], It is IMO a big disadvantage for me as a developer that I
need to make sure that my IDE always performs the code generation step before
compilation, if I want to just use an IDE build and not delegate build steps to
Maven, Gradle or Ant. Look at this tiny Maven example, which I have just
created for demonstration purposes:
https://github.com/kriegaex/Maven_GenerateSourcesExample
It implements your favoured approach, utilising Templating Maven Plugin. The
Maven build generates sources from templates, expanding Maven properties like
the version number in the process, then compiles and maybe packages everything.
So far, so good. Now what if we run {{mvn clean}} and then e.g. run an IntelliJ
build via Ctrl-F9? The generated class will no longer be found, the other
example class depending on the generated one cannot be compiled. The same is
true for run configurations. They also trigger an IDE build and are also
failing. Of course, I can configure IntelliJ to delegate builds to Maven, but
that makes builds slower, just like delegating to Gradle is slow if I simply
want to compile or run something from the IDE. OK, this can be fixed easily,
just clicking this button before the IDE build:
!screenshot-1.png!
But I need to know that. To run a Maven build before opening the project in the
IDE, as you suggested, is solving the same problem, but also a usability
nuisance for developers. I strongly favour project setups in which I simply
import my Maven build, and the IDE can do the rest without any additional
tricks.
Arguably, developers could accept that little burden in favour of increased
ease of use for end users of the product. You would have a valid point there,
if repakaging and relocating classes would require additional configuration
steps for users. But in fact, that is not the case, if we, as you might have
missed I suggested, do not put the resource files into META-INF, but right into
the package directories where the classes reading them reside:
{quote}or even in a package directory, e.g.
_org/apache/xalan/version.properties_. I tend to the latter location{quote}
There is also an example for that in the same repository. I also configured
Maven Shade with relocation, and the resource file is relocated automatically
together with the class files. Even the hard-coded path in the class file is
adjusted automatically without any extra transformer configuration. Just clone
the repository and run
{code:none}
$ mvn clean package
(...)
$ java -cp target/Maven_GenerateSourcesExample-2.7.D3-SNAPSHOT.jar
shaded.org.example.Main
FromTemplate Java 2.7.D3-SNAPSHOT
FromResourceFile Java 2.7.D3-SNAPSHOT
{code}
You see, both classes
* {{VersionFromTemplate}} generated by Templating Maven Plugin,
* {{VersionFromResourceFile}} reading the properties file
work beautifully after relocation. The clear advantage for the latter is that
it also runs locally without manually triggering code generation.
was (Author: kriegaex):
[~vladimirsitnikov], It is IMO a big disadvantage for me as a developer that I
need to make sure that my IDE always performs the code generation step before
compilation, if I want to just use an IDE build and not delegate build steps to
Maven, Gradle or Ant. Look at this tiny Maven example, which I have just
created for demonstration purposes:
https://github.com/kriegaex/Maven_GenerateSourcesExample
It implements your favoured approach, utilising Templating Maven Plugin. The
Maven build generates sources from templates, expanding Maven properties like
the version number in the process, then compiles and maybe packages everything.
So far, so good. Now what if we run `mvn clean` and then e.g. run an IntelliJ
build via Ctrl-F9? The generated class will no longer be found, the other
example class depending on the generated one cannot be compiled. The same is
true for run configurations. They also trigger an IDE build and are also
failing. Of course, I can configure IntelliJ to delegate builds to Maven, but
that makes builds slower, just like delegating to Gradle is slow if I simply
want to compile or run something from the IDE. OK, this can be fixed easily,
just clicking this button before the IDE build:
!screenshot-1.png!
But I need to know that. To run a Maven build before opening the project in the
IDE, as you suggested, is solving the same problem, but also a usability
nuisance for developers. I strongly favour project setups in which I simply
import my Maven build, and the IDE can do the rest without any additional
tricks.
Arguably, developers could accept that little burden in favour of increased
ease of use for end users of the product. You would have a valid point there,
if repakaging and relocating classes would require additional configuration
steps for users. But in fact, that is not the case, if we, as you might have
missed I suggested, do not put the resource files into META-INF, but right into
the package directories where the classes reading them reside:
{quote}or even in a package directory, e.g.
_org/apache/xalan/version.properties_. I tend to the latter location{quote}
There is also an example for that in the same repository. I also configured
Maven Shade with relocation, and the resource file is relocated automatically
together with the class files. Even the hard-coded path in the class file is
adjusted automatically without any extra transformer configuration. Just clone
the repository and run
{code:none}
$ mvn clean package
(...)
$ java -cp target/Maven_GenerateSourcesExample-2.7.D3-SNAPSHOT.jar
shaded.org.example.Main
FromTemplate Java 2.7.D3-SNAPSHOT
FromResourceFile Java 2.7.D3-SNAPSHOT
{code}
You see, both classes
* {{VersionFromTemplate}} generated by Templating Maven Plugin,
* {{VersionFromResourceFile}} reading the properties file
work beautifully after relocation. The clear advantage for the latter is that
it also runs locally without manually triggering code generation.
> Use resource files for version numbers
> --------------------------------------
>
> Key: XALANJ-2710
> URL: https://issues.apache.org/jira/browse/XALANJ-2710
> Project: XalanJ2
> Issue Type: New Feature
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Reporter: Alexander Kriegisch
> Assignee: Gary D. Gregory
> Priority: Major
> Attachments: screenshot-1.png
>
>
> The current Ant build uses {{\*.src}} files, replaces placeholders with
> version numbers there, then renames them to {{\*.java}} and copies them to
> their respective destination directories.
> In the current Maven build in branch {{{}xalan-java-mvn-refactored{}}}, this
> should be replaced by simple, standardised Maven resource filtering. The
> values would be written into a properties file, which then in turn will be
> read as normal classpath resources from Java classes that need version
> information.
> Even easier than that would be to simply use the standard
> {{META-INF/maven/[groupId]/[artifactId]/pom.properties}} file generated into
> JARs by Maven anyway. They look like this:
> {code:java}
> artifactId=xalan
> groupId=xalan
> version=2.7.3
> {code}
> The only drawback here is that each corresponding Java file per module would
> need to know its own group and artifact ID in order to locate the resource
> file. But those usually do not change often, and it would be the cheapest
> solution to just hard-code them into the corresponding {{*Version.java}}
> file. Creating extra resource files with a fixed paths would be more work and
> the exact location would also have to be hard-coded into the Java files.
> Outside the JAR file context, e.g. when running tests from an IDE, the file
> would be located in {{{}target/maven-archiver/pom.properties{}}}, i.e. the
> Java classes reading the version numbers would need to try that path as a
> fallback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
