[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aether-users] Deploying and resolving compressed artifacts
|
Shahim Essaid wrote:
I have files (the artifacts) that are very large but compress to a
relatively small size. I would like to deploy these files as "primary"
artifacts with the standard Maven/Aether coordinates but deploy them in a
compressed form. The artifact naming would follow the standard Maven
naming conversions but be suffixed with *.zip, *.gz, etc. if they they are
deployed as compressed files.
So given an artifact with artifactId=foo, version=1 and extension=bar,
the filename in the remote repo would be foo-1.bar.gz, do I understand
this correctly?
In my client, I would like Aether to automatically consider the compressed
versions if the uncompressed version does not exist. Also, when stored in
the local repository, they should be uncompressed. Can Aether support
this?
There is nothing in Aether that transparently supports (un-)compressing
artifacts out of the box.
It could be implemented on the client-side via your own
org.eclipse.aether.spi.connector.RepositoryConnectorFactory. Given some
artifacts, a repository connector is responsible to get their bytes from
the remote repo and is in charge of locating/transferring those bytes.
This extension point is powerful enough to solve your case but also
comes with quite a burden regarding implementation.
With that in mind, did you consider to implement the (un-)compressing on
the server-side? This might be easier and would work for any client tool.
I will also want to enable this behavior during a Maven build of a
project that depends on such artifacts. I will provide the custom project
build type as an extension and I think I can enable this behavior in Maven
as long as I know how to do it in Aether.
If you go down the path of a client-side solution, just keep in mind
that even Maven 3.2.x uses older versions of Aether, so be sure to pick
the proper version of the SPI to implement.
Benjamin
