[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787609#comment-17787609
]
Vladimir Sitnikov commented on XALANJ-2710:
-------------------------------------------
{quote}The templating approach Ant uses would have to be recreated for Maven,
which would not be hard to do, but IMO it just has too many
disadvantages.{quote}
I must be missing the disadvantages. Could you please list them?
I've used a templating approach for version files for Apache Calcite, and
pgjdbc for quite some time already, and I think it was great.
Well, there were some Maven-related disadvantages:
1) The file was not generated when opening a project in IDE. The common wisdom
was to "mvn clean install" before opening the project. I think Maven might have
improved a lot since then (it was ~5 years ago). Sure thing Gradle does not
have "missing files when opening project in IDE" issue
2) Maven resource-processing caused recompilation of every file every time:
MRRESOURCES-91. It took Maven committers four years to merge my PR. Sure thing
should not be relevant
I know no other disadvantages.
{quote} Leaving files as-is is not fine, because currently in the Maven branch
the version numbers{quote}
I am afraid we understand different "current" and different "as is".
If someone "randomly removes files from jar", then we should not discuss it
here. You said "some users might indeed think that those files are superfluous
and can be removed from shaded JARs - this is not a reason to decline the
issue", and I agree we should not decline the issue if someone thinks some
files are superfluous.
Sorry for being unclear. I meant "if the only thing that is needed for the
shading jar is to keep the files in the jar as is, then it is relatively easy
for the ones who shade". However, if a proper relocation requires renaming
files or changing its contents, then it becomes complicated for the ones who
shade.
For instance, Maven has several resource transformers for exactly the case of
mering "resource files" when shading:
https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
I do not see a transformer there that would properly rename/merge the files
META-INF/maven you suggest.
{quote}Vladimir: The key issue I highlight here is that users would have to
rename the file and adjust its usage when they repackage Xalan.
Alexander: Why would they?{quote}
The key reason for shading/repackaging is to isolate third-party dependencies
to avoid version conflicts.
Suppose I develop a library Foo and I want to use Xalan. Suppose I take Xalan
2.7.4. I might want to isolate the users of Foo from clashes among org.xalan...
classes. Then I would relocate xalan classes under
com.example.foo.shaded.org.xalan..
Of course, if I would like to isolate the users from Xalan, I would need to
rename the special version property file otherwise users might get two
different property file with the same name in a single classpath.
{quote} It is still there and is still public{quote}
Exactly. My point is that the file is there, so we discuss if changing the
implementation details is worth the trouble or not.
I never said, and I never meant you broke the backward compatibility with your
PR.
I mean the class will have to stay, so the only question is "what is the
purpose of changing the implementation details?"
{quote}because it is not exactly how you envision it to be.{quote}
There's no point in insisting on a particular solution.
What I say is that "templating approach" causes fewer issues for the users,
while "resource-based approach" causes more issues for the users. The
implementation complexity is comparable, so I would prefer if the team selected
approaches that cause fewer issues for the users.
> 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
>
> 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
