Re: How does Maven really treat "bundle" packaging type?
On Mon, Jun 20, 2022 at 11:03 PM Greg Chabala wrote: > > I'm considering uploading any dependencies I do need from JitPack > > directly into my own Artifactory as a workaround, but that's crazy and > > not long term maintainable. > I would counter that is actually the only appropriate action. Who is > JitPack? Will it go away tomorrow? As near as I can tell, it's a one person > operation based in the UK, not something a professional would base their > build process around. > > Configuring your Artifactory as a caching proxy as Thomas suggests is the > easy way to insulate yourself, but I'd recommend trying to avoid JitPack > entirely. Greg, Thomas, thank you very much for your feedback. JitPack is definitely evil, simply based on the fact of what either they are doing or allow to be done on their repository. I've taken a look at their entire list of GitHub issues, and it's a cesspool of spam and unattended problems reports. I doubt we're gonna hear the last of them anytime soon considering how popular it is with Android builds. This all started once I needed to use some code written by Mulesoft, and those guys (a) host their own code on their own repository and (b) use JitPack for their dependencies. I wish people didn't do that, in general, but if wishes were horses. > On Mon, Jun 20, 2022 at 3:27 PM Thomas Broyer wrote: > > > Le lun. 20 juin 2022 à 20:38, Pawel Veselov a > > écrit : > > > > > TL;DR: > > > > > > Is there a way, and what is the correct one if there is, to prevent a > > > package being downloaded from a particular repository (or lock it to > > > being downloaded from a particular one, though I thought the answer to > > > that one is "no")? > > > > > > > Use a repository manager? > > Have everything go through your repo manager (by declaring it as proxying > > `*` in your settings.xml), and manage "filters" there to make sure you only > > get from Jitpack what you expect to get from it (using Nexus, this is done > > through "routing rules", I don't know with Artifactory). > > That's the route we've taken to avoid a few supply chain attacks, including > > dependency confusion like you're seeing here (even though it's probably not > > an "attack") > > > > LR: > > > > > > Maven 3.8.6, JDK 1.8. > > > > > > I've run into this strange problem with > > > com.github.jsonld-java:jsonld-java:0.13.4 > > > The package includes fine as a dependency if it is downloaded from > > > Maven Central: > > > pom.xml: https://pastebin.com/qev5Udp2 > > > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > > > if you want me to attach that) > > > > > > The package fails to download as a dependency if it is downloaded from > > > JitPack: > > > pom.xml: https://pastebin.com/7L2rEWPz > > > Build output: https://pastebin.com/U3StAtMZ > > > > > > AFAIU, there are two things that are "wrong" in this entire thing: > > > a) Developer declared packaging as "bundle" (I'm not entirely sure > > > that's wrong, but I don't see a reason for them to have done so, and > > > it seems to be a contributing factor) > > > b) JitPack/somebody republished the dependency as a virtual package > > > that depends on itself, and broke this entirely. > > > > > > But what I don't understand is why the Maven's behavior is different > > > in these two cases. > > > > > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > > > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > > > explicit dependency statement. There is no such downloadable binary, > > > so the entire process fails. > > > > > > WORKING CASE: The package is found on Central, Maven is asked to get > > > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > > > specification. The packaging specification in the POM is "bundle". But > > > Maven is satisfied with just downloading the JAR > > > > > > Few questions: > > > - How come Maven is OK creating/uploading a package with "bundle" > > > packaging, but without a "bundle" file? > > > - How does Maven decide to download the .jar when the packaging says > > > "bundle" in the POM, and is satisfied with that? > > > > > > > This is done through "artifact handlers" (the 'type' from a 'dependency' is > > technically unrelated to the 'packaging' from the POM). If your dependency > > doesn't declare a 'type', then it defaults to 'jar' (the 'packaging' > > selects a lifecycle that determines how to *build* that project, > > irrespective of how to consume it) > > > > - Is there a way to find out who published a package on JitPack, to > > > get them to fix it? The developer didn't do that, that was done > > > without their consent and/or them being made aware of it > > > > > > Thank you. > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > -- With best of best regards Pawel S. Veselov -
Re: How does Maven really treat "bundle" packaging type?
> > I'm considering uploading any dependencies I do need from JitPack > directly into my own Artifactory as a workaround, but that's crazy and > not long term maintainable. > I would counter that is actually the only appropriate action. Who is JitPack? Will it go away tomorrow? As near as I can tell, it's a one person operation based in the UK, not something a professional would base their build process around. Configuring your Artifactory as a caching proxy as Thomas suggests is the easy way to insulate yourself, but I'd recommend trying to avoid JitPack entirely. On Mon, Jun 20, 2022 at 3:27 PM Thomas Broyer wrote: > Le lun. 20 juin 2022 à 20:38, Pawel Veselov a > écrit : > > > TL;DR: > > > > Is there a way, and what is the correct one if there is, to prevent a > > package being downloaded from a particular repository (or lock it to > > being downloaded from a particular one, though I thought the answer to > > that one is "no")? > > > > Use a repository manager? > Have everything go through your repo manager (by declaring it as proxying > `*` in your settings.xml), and manage "filters" there to make sure you only > get from Jitpack what you expect to get from it (using Nexus, this is done > through "routing rules", I don't know with Artifactory). > That's the route we've taken to avoid a few supply chain attacks, including > dependency confusion like you're seeing here (even though it's probably not > an "attack") > > LR: > > > > Maven 3.8.6, JDK 1.8. > > > > I've run into this strange problem with > > com.github.jsonld-java:jsonld-java:0.13.4 > > The package includes fine as a dependency if it is downloaded from > > Maven Central: > > pom.xml: https://pastebin.com/qev5Udp2 > > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > > if you want me to attach that) > > > > The package fails to download as a dependency if it is downloaded from > > JitPack: > > pom.xml: https://pastebin.com/7L2rEWPz > > Build output: https://pastebin.com/U3StAtMZ > > > > AFAIU, there are two things that are "wrong" in this entire thing: > > a) Developer declared packaging as "bundle" (I'm not entirely sure > > that's wrong, but I don't see a reason for them to have done so, and > > it seems to be a contributing factor) > > b) JitPack/somebody republished the dependency as a virtual package > > that depends on itself, and broke this entirely. > > > > But what I don't understand is why the Maven's behavior is different > > in these two cases. > > > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > > explicit dependency statement. There is no such downloadable binary, > > so the entire process fails. > > > > WORKING CASE: The package is found on Central, Maven is asked to get > > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > > specification. The packaging specification in the POM is "bundle". But > > Maven is satisfied with just downloading the JAR > > > > Few questions: > > - How come Maven is OK creating/uploading a package with "bundle" > > packaging, but without a "bundle" file? > > - How does Maven decide to download the .jar when the packaging says > > "bundle" in the POM, and is satisfied with that? > > > > This is done through "artifact handlers" (the 'type' from a 'dependency' is > technically unrelated to the 'packaging' from the POM). If your dependency > doesn't declare a 'type', then it defaults to 'jar' (the 'packaging' > selects a lifecycle that determines how to *build* that project, > irrespective of how to consume it) > > - Is there a way to find out who published a package on JitPack, to > > get them to fix it? The developer didn't do that, that was done > > without their consent and/or them being made aware of it > > > > Thank you. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: How does Maven really treat "bundle" packaging type?
Le lun. 20 juin 2022 à 20:38, Pawel Veselov a écrit : > TL;DR: > > Is there a way, and what is the correct one if there is, to prevent a > package being downloaded from a particular repository (or lock it to > being downloaded from a particular one, though I thought the answer to > that one is "no")? > Use a repository manager? Have everything go through your repo manager (by declaring it as proxying `*` in your settings.xml), and manage "filters" there to make sure you only get from Jitpack what you expect to get from it (using Nexus, this is done through "routing rules", I don't know with Artifactory). That's the route we've taken to avoid a few supply chain attacks, including dependency confusion like you're seeing here (even though it's probably not an "attack") LR: > > Maven 3.8.6, JDK 1.8. > > I've run into this strange problem with > com.github.jsonld-java:jsonld-java:0.13.4 > The package includes fine as a dependency if it is downloaded from > Maven Central: > pom.xml: https://pastebin.com/qev5Udp2 > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > if you want me to attach that) > > The package fails to download as a dependency if it is downloaded from > JitPack: > pom.xml: https://pastebin.com/7L2rEWPz > Build output: https://pastebin.com/U3StAtMZ > > AFAIU, there are two things that are "wrong" in this entire thing: > a) Developer declared packaging as "bundle" (I'm not entirely sure > that's wrong, but I don't see a reason for them to have done so, and > it seems to be a contributing factor) > b) JitPack/somebody republished the dependency as a virtual package > that depends on itself, and broke this entirely. > > But what I don't understand is why the Maven's behavior is different > in these two cases. > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > explicit dependency statement. There is no such downloadable binary, > so the entire process fails. > > WORKING CASE: The package is found on Central, Maven is asked to get > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > specification. The packaging specification in the POM is "bundle". But > Maven is satisfied with just downloading the JAR > > Few questions: > - How come Maven is OK creating/uploading a package with "bundle" > packaging, but without a "bundle" file? > - How does Maven decide to download the .jar when the packaging says > "bundle" in the POM, and is satisfied with that? > This is done through "artifact handlers" (the 'type' from a 'dependency' is technically unrelated to the 'packaging' from the POM). If your dependency doesn't declare a 'type', then it defaults to 'jar' (the 'packaging' selects a lifecycle that determines how to *build* that project, irrespective of how to consume it) - Is there a way to find out who published a package on JitPack, to > get them to fix it? The developer didn't do that, that was done > without their consent and/or them being made aware of it > > Thank you. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How does Maven really treat "bundle" packaging type?
On Mon, Jun 20, 2022 at 9:03 PM Tamás Cservenák wrote: > > Maybe related? > https://github.com/jitpack/jitpack.io/issues/3779 Definitely. But that means that: * nothing has been done about this in 3 years, not even an acknowledgement from JitPack * there isn't a clear workaround. I'm considering uploading any dependencies I do need from JitPack directly into my own Artifactory as a workaround, but that's crazy and not long term maintainable. > > HTH > Tamas > > On Mon, Jun 20, 2022, 20:38 Pawel Veselov wrote: > > > TL;DR: > > > > Is there a way, and what is the correct one if there is, to prevent a > > package being downloaded from a particular repository (or lock it to > > being downloaded from a particular one, though I thought the answer to > > that one is "no")? > > > > LR: > > > > Maven 3.8.6, JDK 1.8. > > > > I've run into this strange problem with > > com.github.jsonld-java:jsonld-java:0.13.4 > > The package includes fine as a dependency if it is downloaded from > > Maven Central: > > pom.xml: https://pastebin.com/qev5Udp2 > > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > > if you want me to attach that) > > > > The package fails to download as a dependency if it is downloaded from > > JitPack: > > pom.xml: https://pastebin.com/7L2rEWPz > > Build output: https://pastebin.com/U3StAtMZ > > > > AFAIU, there are two things that are "wrong" in this entire thing: > > a) Developer declared packaging as "bundle" (I'm not entirely sure > > that's wrong, but I don't see a reason for them to have done so, and > > it seems to be a contributing factor) > > b) JitPack/somebody republished the dependency as a virtual package > > that depends on itself, and broke this entirely. > > > > But what I don't understand is why the Maven's behavior is different > > in these two cases. > > > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > > explicit dependency statement. There is no such downloadable binary, > > so the entire process fails. > > > > WORKING CASE: The package is found on Central, Maven is asked to get > > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > > specification. The packaging specification in the POM is "bundle". But > > Maven is satisfied with just downloading the JAR > > > > Few questions: > > - How come Maven is OK creating/uploading a package with "bundle" > > packaging, but without a "bundle" file? > > - How does Maven decide to download the .jar when the packaging says > > "bundle" in the POM, and is satisfied with that? > > - Is there a way to find out who published a package on JitPack, to > > get them to fix it? The developer didn't do that, that was done > > without their consent and/or them being made aware of it - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How does Maven really treat "bundle" packaging type?
Maybe related? https://github.com/jitpack/jitpack.io/issues/3779 HTH Tamas On Mon, Jun 20, 2022, 20:38 Pawel Veselov wrote: > TL;DR: > > Is there a way, and what is the correct one if there is, to prevent a > package being downloaded from a particular repository (or lock it to > being downloaded from a particular one, though I thought the answer to > that one is "no")? > > LR: > > Maven 3.8.6, JDK 1.8. > > I've run into this strange problem with > com.github.jsonld-java:jsonld-java:0.13.4 > The package includes fine as a dependency if it is downloaded from > Maven Central: > pom.xml: https://pastebin.com/qev5Udp2 > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > if you want me to attach that) > > The package fails to download as a dependency if it is downloaded from > JitPack: > pom.xml: https://pastebin.com/7L2rEWPz > Build output: https://pastebin.com/U3StAtMZ > > AFAIU, there are two things that are "wrong" in this entire thing: > a) Developer declared packaging as "bundle" (I'm not entirely sure > that's wrong, but I don't see a reason for them to have done so, and > it seems to be a contributing factor) > b) JitPack/somebody republished the dependency as a virtual package > that depends on itself, and broke this entirely. > > But what I don't understand is why the Maven's behavior is different > in these two cases. > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > explicit dependency statement. There is no such downloadable binary, > so the entire process fails. > > WORKING CASE: The package is found on Central, Maven is asked to get > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > specification. The packaging specification in the POM is "bundle". But > Maven is satisfied with just downloading the JAR > > Few questions: > - How come Maven is OK creating/uploading a package with "bundle" > packaging, but without a "bundle" file? > - How does Maven decide to download the .jar when the packaging says > "bundle" in the POM, and is satisfied with that? > - Is there a way to find out who published a package on JitPack, to > get them to fix it? The developer didn't do that, that was done > without their consent and/or them being made aware of it > > Thank you. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
How does Maven really treat "bundle" packaging type?
TL;DR: Is there a way, and what is the correct one if there is, to prevent a package being downloaded from a particular repository (or lock it to being downloaded from a particular one, though I thought the answer to that one is "no")? LR: Maven 3.8.6, JDK 1.8. I've run into this strange problem with com.github.jsonld-java:jsonld-java:0.13.4 The package includes fine as a dependency if it is downloaded from Maven Central: pom.xml: https://pastebin.com/qev5Udp2 Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK if you want me to attach that) The package fails to download as a dependency if it is downloaded from JitPack: pom.xml: https://pastebin.com/7L2rEWPz Build output: https://pastebin.com/U3StAtMZ AFAIU, there are two things that are "wrong" in this entire thing: a) Developer declared packaging as "bundle" (I'm not entirely sure that's wrong, but I don't see a reason for them to have done so, and it seems to be a contributing factor) b) JitPack/somebody republished the dependency as a virtual package that depends on itself, and broke this entirely. But what I don't understand is why the Maven's behavior is different in these two cases. NOT WORKING CASE: The package is found on JitPack, Maven is asked to get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an explicit dependency statement. There is no such downloadable binary, so the entire process fails. WORKING CASE: The package is found on Central, Maven is asked to get com.github.jsonld-java:jsonld-java:0.13.4, without packaging specification. The packaging specification in the POM is "bundle". But Maven is satisfied with just downloading the JAR Few questions: - How come Maven is OK creating/uploading a package with "bundle" packaging, but without a "bundle" file? - How does Maven decide to download the .jar when the packaging says "bundle" in the POM, and is satisfied with that? - Is there a way to find out who published a package on JitPack, to get them to fix it? The developer didn't do that, that was done without their consent and/or them being made aware of it Thank you. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Doxia version 2.0.0-M3 released
The Apache Maven team is pleased to announce the release of the Apache Maven Doxia, version 2.0.0-M3 https://maven.apache.org/doxia/ Release Notes - Maven Doxia - Version 2.0.0-M3 ** Bug * [DOXIA-590] - Either provided element class or default class gets ignored * [DOXIA-619] - Sink.sectionTitle1() creates instead of * [DOXIA-649] - Plexus to Sisu migration missed singleton annotation ** New Feature * [DOXIA-660] - Add ability to hide table rows via CSS ** Task * [DOXIA-650] - Make MarkdownParser to be a text parser with text markup * [DOXIA-652] - Drop build-info.properties in favor of default pom.properties * [DOXIA-656] - Make XHTML5 default implementation of HTML * [DOXIA-657] - Deprecate XHML(4) module ** Dependency upgrade * [DOXIA-651] - Upgrade Flexmark to 0.50.50 * [DOXIA-653] - Upgrade Plexus Utils to 3.4.2 * [DOXIA-654] - Upgrade XML Unit to 2.9.0 * [DOXIA-655] - Upgrade SLF4J to 1.7.36 * [DOXIA-658] - Upgrade test dependencies * [DOXIA-659] - Upgrade Parent to 36 * [DOXIA-661] - Upgrade Commons Text to 1.9 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Toolchains Plugin 3.1.0 released
The Apache Maven team is pleased to announce the release of the Maven Toolchains Plugin version 3.1.0. https://maven.apache.org/plugins/maven-toolchains-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-toolchains-plugin 3.1.0 Release Notes - Maven Deploy Plugin - Version 3.1.0 ** Improvement * [MTOOLCHAINS-31] - Not threadsafe for parallel execution * [MTOOLCHAINS-32] - make build Reproducible ** Task * [MTOOLCHAINS-40] - Update parent to 36, Maven to 3.2.5, make it Java 8 ** Dependency upgrade * [MTOOLCHAINS-33] - set minimum maven version to 3.1 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to tell maven to use https instead of http...
what version of Maven Archetype Plugin do you get? And what is the output before the exception? Regards, Hervé Le dimanche 19 juin 2022, 19:11:27 CEST Stefano Fornari a écrit : > I am trying to create a project from an archetype: > > mvn archetype:generate \ > -DarchetypeGroupId=org.openjfx \ > -DarchetypeArtifactId=javafx-archetype-simple \ > -DarchetypeVersion=0.0.3 \ > -DgroupId=org.openjfx \ > -DartifactId=sample \ > -Dversion=1.0.0 \ > -Djavafx-version=17.0.1 > > > But I am getting the following error: > > rg.apache.maven.wagon.TransferFailedException: Failed to transfer file: > http://repo1.maven.org/maven2. Return code is: 501 , ReasonPhrase:HTTPS > Required. > > Shouldn't maven central be hardcoded in the apache-maven package? How can I > fix it? > > Many thanks in advance. > > Ste - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
