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: [email protected]
For additional commands, e-mail: [email protected]
