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;
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-lan
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:
- m
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, bu
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
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 runti
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 m
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,
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 list
