The .xed extension descriptors in the WAR contain the repository list at build time
The descriptor indeed probably contain the repository where it was found, but not the entire list of repositories. But I agree that in the specific case of embedded XED files at build time, this optimization should be avoided.
But it would not make much sense to remove the repositories that are coming from the poms.
Further, user.name leaks in via third-party POM interpolation: Grizzly's scm URL is ssh://${user.name}@git.java.net/… which is replaced at build time
That one is a bit more complex to deal with. What is converted is the effective pom, and at this level we don't really have any idea what is context dependent or not. It's honestly very weird stuff to put in a pom in the first place too...
Thomas Mortagne on 14/Aug/26 09:46
bq. The .xed extension descriptors in the WAR contain the repository list at build time
The descriptor indeed probably contain the repository where it was found (as an optimization to search for dependency in that repository first), but not I don't see why it would contain the entire list of repositories you have in your Maven settings. But I agree that in the specific case of embedded XED files at build time, this optimization should be avoided.
ButOf course, it would not make much sense to remove the repositories that are coming from the poms.
bq. Further, user.name leaks in via third-party POM interpolation: Grizzly's scm URL is ssh://${user.name}@git.java.net/… which is replaced at build time
That one is a bit more complex to deal with. What is converted is the effective pom, and at this level we don't really have any idea what is context dependent or not. It's honestly very weird stuff to put in a pom in the first place too...
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
