Re: Remove Artifact Commons-Lang Dependency?
Am 2019-12-31 um 17:18 schrieb Mark James: On 01/01/2020 01:13, Michael Osipov wrote: 2. In ArtifactUtils.notBlank, replacing Validate.notBlank( str, message ); with for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); These are not equivalient. Validate#notBlank throws NPE on null input, those alternatives don't do. I'd has to be interface specification equal. M Thanks Michael for picking that up. So should be if (str != null) for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str == null || str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); Not, that is still wrong. null results in NullPointerException, not IAE. You need two if statements. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remove Artifact Commons-Lang Dependency?
Karl, I'd like users of my JAR to have to install just this one JAR file (so no un-archiving required), and not have to ask them to also install the Maven package to their classpaths. To do this I'm compiling parts of Maven into my JAR, as allowed by the Apache Licence, eliminating the commons-lang3 dependencies so I don't have to also compile that in. It's great that you're currently working on dependency reduction. Mark On 31/12/2019 23:45, Karl Heinz Marbaise wrote: > hi Mark, > > On 31.12.19 12:54, Mark James wrote: >> Karl, I'd like to embed Maven version string comparison in my JAR so my >> users don't have to install both Maven and Commons-Lang. > > > Users don't have to install Maven and commons-lang3. They will get it > with their installation package (Download from maven.apache.org) in the > lib directory... > > I'm currently checking and working on removing dependencies which are > not really needed[1]. > > Maybe you can explain more in details what you are trying to do or > helping (of course appreciated)... > > cause at the moment I don't understand which way you are walking? > > > Maybe related to the post we have a misunderstanding ? > > Kind regards > Karl Heinz Marbaise > > [1]: https://issues.apache.org/jira/browse/MNG-6829 > > >> But I'd like to >> do this in a way that my JAR isn't an order-of-magnitude bigger. >> >> I've found I can embed just >> >> org.apache.maven.artifact >> org.apache.maven.artifact.handler >> org.apache.maven.artifact.metadata >> org.apache.maven.artifact.repository >> org.apache.maven.artifact.repository.layout >> org.apache.maven.artifact.repository.metadata >> org.apache.maven.artifact.resolver >> org.apache.maven.artifact.resolver.filter >> org.apache.maven.artifact.versioning >> org.apache.maven.repository >> org.apache.maven.repository.legacy.metadata >> >> as long as I make the small mods I posted to remove the Commons-Lang >> dependency. >> >> Should I keep these mods as a custom fork, or would they be a worthwhile >> patch to the distribution? >> >> Mark >> >> On 26/11/2019 05:01, Karl Heinz Marbaise wrote: >>> Hi Mark, >>> >>> can you tell us on which part of Maven you are referencing? Or do you >>> reference your own project? >>> >>> Maven Core ? a particular plugin ? >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> On 25.11.19 03:08, Mark James wrote: Hello, Is there any chance of removing the dependency of Artifact on Commons-Lang? Something nine times bigger is pulled in just to reference the String utility functions isNotEmpty, notBlank, and isNumeric. I understand the advantages of libraries, but this comes at more of a cost in Java because common Java libraries are less likely to be on the system than native libraries, and so must be either specified as a dependency (that must be downloaded and added to build and class paths), distributed with the using JAR (requiring an installation expansion), or embedded into using JARs (defeating the space-saving advantage). Semi-automated dependency resolution probably makes this easier, but many such as myself aren't familiar with it. I'd like to be able to distribute my package as a single JAR, with Artifact but not Commons-Lang embedded. But this currently needs the following changes: 1. Replacing StringUtils.isNotEmpty in DefaultArtifact with a not-null + positive-length test. 2. In ArtifactUtils.notBlank, replacing Validate.notBlank( str, message ); with for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); and 3. Copying StringUtils.isNumeric as DefaultArtifact.isDigits. It would be nice if Java had a directive to do such copies at build-time, removing run-time dependencies while preventing code duplication. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Doxia test flakiness
reviewing the list of repositories to archive, I find 8 ready to archive: - maven-plugins - maven-shared - maven-doxia-tools (after all, we can archive now and decide later for book*) - maven-pom - maven-artifact - maven-mercury - maven-app-engine - maven-repository-tools and last 3 to decide: - maven-resources - maven-sandbox - maven-doxia-ide Regards, Hervé Le mardi 31 décembre 2019, 09:27:13 CET Hervé Boutemy a écrit : > removing, probably not, but archiving would probably be appropriate once > full Git migration has been done > for example, the 2 most important https://github.com/apache/maven-plugins/ > and https://github.com/apache/maven-shared/ are ready to be archived > perhaps it's just about asking infra > > Regards, > > Hervé > > Le lundi 30 décembre 2019, 23:14:19 CET Elliotte Rusty Harold a écrit : > > Also, should we remove those old SVN mirror repos so no one else > > stumbles across them by mistake? > > > > On Tue, Dec 24, 2019 at 6:01 AM Robert Scholte wrote: > > > I think something went wrong here. > > > This project use to be the aggregator project in subversion. > > > In the early days there were read-only repos in github of our subversion > > > repos. However, when we moved everything to gitbox every module should > > > have gotten their own repository. > > > > > > https://github.com/apache/maven-doxia-tools > > > [https://github.com/apache/maven-doxia-tools] > > > > > > > > > for some reason only the doxia-converter and doxia-linkchecker got their > > > own repo, the doxia-book-renderer and doxia-book-maven-plugin not. > > > > > > Before having a look at this, we need to know the status of it. > > > > > > thanks, > > > Robert > > > > > > On 23-12-2019 23:38:43, Elliotte Rusty Harold > > > wrote: > > > Anyone working on Doxia these days? If so, your review of > > > https://github.com/apache/maven-doxia-tools/pull/3 would be > > > appreciated. This PR effectively disables a flaky autogenerated test. > > > > > > This was the best I could come up with on short notice to unblock some > > > other bugs in Doxia. However if anyone can figure out how to fix the > > > autogenerated test instead that would be even better. Details at > > > > > > https://issues.apache.org/jira/browse/DOXIATOOLS-64 > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remove Artifact Commons-Lang Dependency?
Am 2019-11-25 um 03:08 schrieb Mark James: Hello, Is there any chance of removing the dependency of Artifact on Commons-Lang? Something nine times bigger is pulled in just to reference the String utility functions isNotEmpty, notBlank, and isNumeric. I understand the advantages of libraries, but this comes at more of a cost in Java because common Java libraries are less likely to be on the system than native libraries, and so must be either specified as a dependency (that must be downloaded and added to build and class paths), distributed with the using JAR (requiring an installation expansion), or embedded into using JARs (defeating the space-saving advantage). Semi-automated dependency resolution probably makes this easier, but many such as myself aren't familiar with it. I'd like to be able to distribute my package as a single JAR, with Artifact but not Commons-Lang embedded. But this currently needs the following changes: 1. Replacing StringUtils.isNotEmpty in DefaultArtifact with a not-null + positive-length test. 2. In ArtifactUtils.notBlank, replacing Validate.notBlank( str, message ); with for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); These are not equivalient. Validate#notBlank throws NPE on null input, those alternatives don't do. I'd has to be interface specification equal. M - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remove Artifact Commons-Lang Dependency?
Karl, I'd like to embed Maven version string comparison in my JAR so my users don't have to install both Maven and Commons-Lang. But I'd like to do this in a way that my JAR isn't an order-of-magnitude bigger. I've found I can embed just org.apache.maven.artifact org.apache.maven.artifact.handler org.apache.maven.artifact.metadata org.apache.maven.artifact.repository org.apache.maven.artifact.repository.layout org.apache.maven.artifact.repository.metadata org.apache.maven.artifact.resolver org.apache.maven.artifact.resolver.filter org.apache.maven.artifact.versioning org.apache.maven.repository org.apache.maven.repository.legacy.metadata as long as I make the small mods I posted to remove the Commons-Lang dependency. Should I keep these mods as a custom fork, or would they be a worthwhile patch to the distribution? Mark On 26/11/2019 05:01, Karl Heinz Marbaise wrote: > Hi Mark, > > can you tell us on which part of Maven you are referencing? Or do you > reference your own project? > > Maven Core ? a particular plugin ? > > Kind regards > Karl Heinz Marbaise > > On 25.11.19 03:08, Mark James wrote: >> Hello, >> >> Is there any chance of removing the dependency of Artifact on Commons-Lang? >> Something nine times bigger is pulled in just to reference the String utility >> functions isNotEmpty, notBlank, and isNumeric. >> >> I understand the advantages of libraries, but this comes at more of a cost in >> Java because common Java libraries are less likely to be on the system than >> native libraries, and so must be either specified as a dependency (that must >> be >> downloaded and added to build and class paths), distributed with the using >> JAR >> (requiring an installation expansion), or embedded into using JARs (defeating >> the space-saving advantage). Semi-automated dependency resolution probably >> makes >> this easier, but many such as myself aren't familiar with it. >> >> I'd like to be able to distribute my package as a single JAR, with Artifact >> but >> not Commons-Lang embedded. But this currently needs the following changes: >> >> 1. Replacing StringUtils.isNotEmpty in DefaultArtifact with a not-null + >> positive-length test. >> >> 2. In ArtifactUtils.notBlank, replacing >> >> Validate.notBlank( str, message ); >> >> with >> >> for (int i=0; i < str.length(); i++) if >> (!Character.isWhitespace(str.charAt(i))) return; >> throw new IllegalArgumentException(message); >> >> or, using Java 8 code, >> >> if (str.chars().allMatch(Character::isWhitespace)) throw new >> IllegalArgumentException(message); >> >> and 3. Copying StringUtils.isNumeric as DefaultArtifact.isDigits. >> >> It would be nice if Java had a directive to do such copies at build-time, >> removing run-time dependencies while preventing code duplication. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remove Artifact Commons-Lang Dependency?
Hi Mark, On 31.12.19 14:12, Mark James wrote: Karl, I'd like users of my JAR to have to install just this one JAR file (so no un-archiving required), and not have to ask them to also install the Maven > package to their classpaths. The maven packages or Maven itself is not needed during runtime of an application?... Lets us start from the beginning. So you are developing a an application which a user should be using in sense downloading it and starting it via "java -jar ..." ? Correct? To do this I'm compiling parts of Maven into my JAR, as allowed by the Apache Licence, eliminating the commons-lang3 dependencies so I don't have to also compile that in. It's not a question of License of course can you do that it's open source ... But I don't understand why you are compiling parts of Maven into your JAR ? Kind regards Karl Heinz Marbaise It's great that you're currently working on dependency reduction. Mark On 31/12/2019 23:45, Karl Heinz Marbaise wrote: hi Mark, On 31.12.19 12:54, Mark James wrote: Karl, I'd like to embed Maven version string comparison in my JAR so my users don't have to install both Maven and Commons-Lang. Users don't have to install Maven and commons-lang3. They will get it with their installation package (Download from maven.apache.org) in the lib directory... I'm currently checking and working on removing dependencies which are not really needed[1]. Maybe you can explain more in details what you are trying to do or helping (of course appreciated)... cause at the moment I don't understand which way you are walking? Maybe related to the post we have a misunderstanding ? Kind regards Karl Heinz Marbaise [1]: https://issues.apache.org/jira/browse/MNG-6829 But I'd like to do this in a way that my JAR isn't an order-of-magnitude bigger. I've found I can embed just org.apache.maven.artifact org.apache.maven.artifact.handler org.apache.maven.artifact.metadata org.apache.maven.artifact.repository org.apache.maven.artifact.repository.layout org.apache.maven.artifact.repository.metadata org.apache.maven.artifact.resolver org.apache.maven.artifact.resolver.filter org.apache.maven.artifact.versioning org.apache.maven.repository org.apache.maven.repository.legacy.metadata as long as I make the small mods I posted to remove the Commons-Lang dependency. Should I keep these mods as a custom fork, or would they be a worthwhile patch to the distribution? Mark On 26/11/2019 05:01, Karl Heinz Marbaise wrote: Hi Mark, can you tell us on which part of Maven you are referencing? Or do you reference your own project? Maven Core ? a particular plugin ? Kind regards Karl Heinz Marbaise On 25.11.19 03:08, Mark James wrote: Hello, Is there any chance of removing the dependency of Artifact on Commons-Lang? Something nine times bigger is pulled in just to reference the String utility functions isNotEmpty, notBlank, and isNumeric. I understand the advantages of libraries, but this comes at more of a cost in Java because common Java libraries are less likely to be on the system than native libraries, and so must be either specified as a dependency (that must be downloaded and added to build and class paths), distributed with the using JAR (requiring an installation expansion), or embedded into using JARs (defeating the space-saving advantage). Semi-automated dependency resolution probably makes this easier, but many such as myself aren't familiar with it. I'd like to be able to distribute my package as a single JAR, with Artifact but not Commons-Lang embedded. But this currently needs the following changes: 1. Replacing StringUtils.isNotEmpty in DefaultArtifact with a not-null + positive-length test. 2. In ArtifactUtils.notBlank, replacing Validate.notBlank( str, message ); with for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); and 3. Copying StringUtils.isNumeric as DefaultArtifact.isDigits. It would be nice if Java had a directive to do such copies at build-time, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remove Artifact Commons-Lang Dependency?
hi Mark, On 31.12.19 12:54, Mark James wrote: Karl, I'd like to embed Maven version string comparison in my JAR so my users don't have to install both Maven and Commons-Lang. Users don't have to install Maven and commons-lang3. They will get it with their installation package (Download from maven.apache.org) in the lib directory... I'm currently checking and working on removing dependencies which are not really needed[1]. Maybe you can explain more in details what you are trying to do or helping (of course appreciated)... cause at the moment I don't understand which way you are walking? Maybe related to the post we have a misunderstanding ? Kind regards Karl Heinz Marbaise [1]: https://issues.apache.org/jira/browse/MNG-6829 But I'd like to do this in a way that my JAR isn't an order-of-magnitude bigger. I've found I can embed just org.apache.maven.artifact org.apache.maven.artifact.handler org.apache.maven.artifact.metadata org.apache.maven.artifact.repository org.apache.maven.artifact.repository.layout org.apache.maven.artifact.repository.metadata org.apache.maven.artifact.resolver org.apache.maven.artifact.resolver.filter org.apache.maven.artifact.versioning org.apache.maven.repository org.apache.maven.repository.legacy.metadata as long as I make the small mods I posted to remove the Commons-Lang dependency. Should I keep these mods as a custom fork, or would they be a worthwhile patch to the distribution? Mark On 26/11/2019 05:01, Karl Heinz Marbaise wrote: Hi Mark, can you tell us on which part of Maven you are referencing? Or do you reference your own project? Maven Core ? a particular plugin ? Kind regards Karl Heinz Marbaise On 25.11.19 03:08, Mark James wrote: Hello, Is there any chance of removing the dependency of Artifact on Commons-Lang? Something nine times bigger is pulled in just to reference the String utility functions isNotEmpty, notBlank, and isNumeric. I understand the advantages of libraries, but this comes at more of a cost in Java because common Java libraries are less likely to be on the system than native libraries, and so must be either specified as a dependency (that must be downloaded and added to build and class paths), distributed with the using JAR (requiring an installation expansion), or embedded into using JARs (defeating the space-saving advantage). Semi-automated dependency resolution probably makes this easier, but many such as myself aren't familiar with it. I'd like to be able to distribute my package as a single JAR, with Artifact but not Commons-Lang embedded. But this currently needs the following changes: 1. Replacing StringUtils.isNotEmpty in DefaultArtifact with a not-null + positive-length test. 2. In ArtifactUtils.notBlank, replacing Validate.notBlank( str, message ); with for (int i=0; i < str.length(); i++) if (!Character.isWhitespace(str.charAt(i))) return; throw new IllegalArgumentException(message); or, using Java 8 code, if (str.chars().allMatch(Character::isWhitespace)) throw new IllegalArgumentException(message); and 3. Copying StringUtils.isNumeric as DefaultArtifact.isDigits. It would be nice if Java had a directive to do such copies at build-time, removing run-time dependencies while preventing code duplication. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Doxia test flakiness
removing, probably not, but archiving would probably be appropriate once full Git migration has been done for example, the 2 most important https://github.com/apache/maven-plugins/ and https://github.com/apache/maven-shared/ are ready to be archived perhaps it's just about asking infra Regards, Hervé Le lundi 30 décembre 2019, 23:14:19 CET Elliotte Rusty Harold a écrit : > Also, should we remove those old SVN mirror repos so no one else > stumbles across them by mistake? > > On Tue, Dec 24, 2019 at 6:01 AM Robert Scholte wrote: > > I think something went wrong here. > > This project use to be the aggregator project in subversion. > > In the early days there were read-only repos in github of our subversion > > repos. However, when we moved everything to gitbox every module should > > have gotten their own repository. > > > > https://github.com/apache/maven-doxia-tools > > [https://github.com/apache/maven-doxia-tools] > > > > > > for some reason only the doxia-converter and doxia-linkchecker got their > > own repo, the doxia-book-renderer and doxia-book-maven-plugin not. > > > > Before having a look at this, we need to know the status of it. > > > > thanks, > > Robert > > > > On 23-12-2019 23:38:43, Elliotte Rusty Harold wrote: > > Anyone working on Doxia these days? If so, your review of > > https://github.com/apache/maven-doxia-tools/pull/3 would be > > appreciated. This PR effectively disables a flaky autogenerated test. > > > > This was the best I could come up with on short notice to unblock some > > other bugs in Doxia. However if anyone can figure out how to fix the > > autogenerated test instead that would be even better. Details at > > > > https://issues.apache.org/jira/browse/DOXIATOOLS-64 > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Doxia test flakiness
nothing really went wrong: there are a few cases I did not migrate because I was convinced that classical migration to 1 git repo each was not appropriate, but I did not know really what to do better (and was tired doing the migration on the many "easy" cases) correponding repositories are listed here as "svn2git": https://github.com/apache/maven-sources/blob/master/default.xml#L140 even more important than doxia-book-renderer and doxia-book-maven-plugin, there are maven-resources corresponding to https://maven.apache.org/apache-resource-bundles/ Perhaps it's time to finish the migration job on the last 5%... Regards, Hervé On 2019/12/24 11:01:42, "Robert Scholte" wrote: > I think something went wrong here. > This project use to be the aggregator project in subversion. > In the early days there were read-only repos in github of our subversion > repos. > However, when we moved everything to gitbox every module should have gotten > their own repository. > > https://github.com/apache/maven-doxia-tools > [https://github.com/apache/maven-doxia-tools] > > > for some reason only the doxia-converter and doxia-linkchecker got their own > repo, the doxia-book-renderer and doxia-book-maven-plugin not. > > Before having a look at this, we need to know the status of it. > > thanks, > Robert > > On 23-12-2019 23:38:43, Elliotte Rusty Harold wrote: > Anyone working on Doxia these days? If so, your review of > https://github.com/apache/maven-doxia-tools/pull/3 would be > appreciated. This PR effectively disables a flaky autogenerated test. > > This was the best I could come up with on short notice to unblock some > other bugs in Doxia. However if anyone can figure out how to fix the > autogenerated test instead that would be even better. Details at > > https://issues.apache.org/jira/browse/DOXIATOOLS-64 > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
