You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by or...@io7m.com on 2015/12/01 17:16:11 UTC
Extracting classes from a separate project?
Hello.
I'm intending to use some classes from the fastutil package[0]. Due
to the size of the artifact(s), it's assumed that anyone using the
package will use ProGuard on their application to remove unneeded
classes. However:
1. I'm writing a library.
2. I'm using the fastutil classes in a way that does not expose them
in the public API of the library.
3. I do not want everyone that uses my library to have to use something
like ProGuard to reduce the resulting size increases caused by
a dependency on fastutil.
Therefore, I feel like the correct way to proceed is to create
a module in my project that solely exists to extract a few classes
from fastutil an expose them to the other modules that need them.
One way to do this would be to use the maven-dependency-plugin to
extract sources from the fastutil package and treat them as "generated
sources" so that they're compiled and packaged as part of the artifact.
However! This would obviously then result in conflicts (duplicate
classes) if someone using my library also used the fastutil package.
It seems like the maven-shade-plugin is capable of moving classes
into different packages, but it seems as though it's only capable
of working with compiled classes and therefore may not play nicely
with IDEs.
Does anyone have a better/preferred way to achieve this?
M
[0] http://fastutil.di.unimi.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Extracting classes from a separate project?
Posted by or...@io7m.com.
On 2015-12-01T17:56:15 +0000
<or...@io7m.com> wrote:
>
> On 2015-12-01T10:45:16 -0600
> Curtis Rueden <ct...@wisc.edu> wrote:
> > Why not just make your single-module library artifact an "uber-JAR" consisting
> > only of its own sources plus the relocated+minimized fastutil classes, using
> > <minimizeJar>true</minimizeJar>?
>
> The project is actually a multi-module project, with several modules
> requiring access to the fastutil classes. My main concern is how well
> IDEs will be able to cope with this...
The answer turend out to be "very poorly", so I've gone with your
original suggestion:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<minimizeJar>true</minimizeJar>
<artifactSet>
<includes>
<include>it.unimi.dsi:fastutil</include>
</includes>
</artifactSet>
<relocations>
<relocation>
<pattern>it.unimi.dsi</pattern>
<shadedPattern>com.io7m.jcanephora.jogl.fastutil</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
This replaces the default jar produced by the project with one that
contains only the required classes, and moves them into their own
package to prevent later conflicts. The it.unimi.dsi:fastutil artifact
is made 'optional' - I tried to use a 'provided' scope, but for some
reason this prevented the shade plugin from seeing the dependency
at all, even with the 'keepDependenciesWithProvidedScope' flag enabled.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Extracting classes from a separate project?
Posted by or...@io7m.com.
'Lo,
On 2015-12-01T10:45:16 -0600
Curtis Rueden <ct...@wisc.edu> wrote:
> Great question!
>
> I see a couple of approaches:
>
> 1) Technical solution: I think you are on the right track to use the
> maven-shade-plugin. But you shouldn't need the maven-dependency-plugin. The
> shade plugin is pretty powerful. Why not just make your single-module
> library artifact an "uber-JAR" consisting only of its own sources plus the
> relocated+minimized fastutil classes, using <minimizeJar>true</minimizeJar>?
The project is actually a multi-module project, with several modules
requiring access to the fastutil classes. My main concern is how well
IDEs will be able to cope with this...
> 2) Social solution: start a discussion with the fastutil team about
> modularizing their library for a future (breaking) release. Right now the
> packages are divided by primitive type, which seems backwards to me. Better
> would be to divide by data structure, with all primitive types in each data
> structure package. Then you could cherry pick only the needed data
> structure(s) of interest. Obviously this is a longer-term solution.
I expect I will approach them, but as you say, that is a longer-term
solution and doesn't help right now.
>
> 3) Punt. Just depend on fastutil and make no apologies. 16MB is really not
> that big of a deal these days. Is slimming ~10MB from your footprint really
> worth the developer time investment of mucking around with shade etc.?
Unfortunately, when it comes to network bandwidth, that is still a big
deal here and in other parts of the world.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Extracting classes from a separate project?
Posted by Curtis Rueden <ct...@wisc.edu>.
Great question!
I see a couple of approaches:
1) Technical solution: I think you are on the right track to use the
maven-shade-plugin. But you shouldn't need the maven-dependency-plugin. The
shade plugin is pretty powerful. Why not just make your single-module
library artifact an "uber-JAR" consisting only of its own sources plus the
relocated+minimized fastutil classes, using <minimizeJar>true</minimizeJar>?
2) Social solution: start a discussion with the fastutil team about
modularizing their library for a future (breaking) release. Right now the
packages are divided by primitive type, which seems backwards to me. Better
would be to divide by data structure, with all primitive types in each data
structure package. Then you could cherry pick only the needed data
structure(s) of interest. Obviously this is a longer-term solution.
3) Punt. Just depend on fastutil and make no apologies. 16MB is really not
that big of a deal these days. Is slimming ~10MB from your footprint really
worth the developer time investment of mucking around with shade etc.?
Regards,
Curtis
On Tue, Dec 1, 2015 at 10:16 AM, <or...@io7m.com> wrote:
> Hello.
>
> I'm intending to use some classes from the fastutil package[0]. Due
> to the size of the artifact(s), it's assumed that anyone using the
> package will use ProGuard on their application to remove unneeded
> classes. However:
>
> 1. I'm writing a library.
> 2. I'm using the fastutil classes in a way that does not expose them
> in the public API of the library.
> 3. I do not want everyone that uses my library to have to use something
> like ProGuard to reduce the resulting size increases caused by
> a dependency on fastutil.
>
> Therefore, I feel like the correct way to proceed is to create
> a module in my project that solely exists to extract a few classes
> from fastutil an expose them to the other modules that need them.
>
> One way to do this would be to use the maven-dependency-plugin to
> extract sources from the fastutil package and treat them as "generated
> sources" so that they're compiled and packaged as part of the artifact.
>
> However! This would obviously then result in conflicts (duplicate
> classes) if someone using my library also used the fastutil package.
>
> It seems like the maven-shade-plugin is capable of moving classes
> into different packages, but it seems as though it's only capable
> of working with compiled classes and therefore may not play nicely
> with IDEs.
>
> Does anyone have a better/preferred way to achieve this?
>
> M
>
> [0] http://fastutil.di.unimi.it/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>