[
https://issues.apache.org/jira/browse/MDEPLOY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453588#comment-17453588
]
Michael Osipov commented on MDEPLOY-289:
----------------------------------------
Well, we don't have the content type and likely will not. I will explain why:
Maven hands off all logical repo interaction of artifacts to Resolver. Resolver
in turn uses an implementation-agnostic approach with Wagon where the actual
transport is completely opaque to Resolver. Read, it does not know that it is
HTTP, SFTP, S3, etc. Wagon provides a generic API to upload and download files.
All it receives is a target path on the repository, and
{{File}}/{{InputStream}}/{{byte[]}}. No additional attribution. Now consider
that the developer is able to attach *any* kind of files to the build which
Resolver + Wagon. There is no way to have this kind of metadata from the POM
down to Resolver and Wagon. Maybe Wagon could receive an API change which would
receive generic metadata which every transport *could* process according to its
protocol. But at the end, it might always boil down to
{{application/octet-stream}} and you are back to the same situation as before.
A completely different approach would be is to modify the Wagon HTTP provider
in a way that you could plug in your content type resolver and provide that
kind of information back to the provider. See also
https://github.com/apache/maven-wagon/pull/72.
[~hiljusti], was is the actual benefit from having the content type in your
case?
> No "Content-Type" header in PUT requests when deploying.
> --------------------------------------------------------
>
> Key: MDEPLOY-289
> URL: https://issues.apache.org/jira/browse/MDEPLOY-289
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
> Affects Versions: 2.8.2
> Environment: Mac/Linux
> Reporter: J.R. Hill
> Priority: Minor
>
> Heya folks!
>
> I work with Amazon/AWS as a build engineer. I'm researching how much effort
> it would take to give our developers the option to build with Apache Maven.
> (opposed to other tools like Gradle)
>
> Right now we are blocked from an easy usage of Apache Maven because no
> "Content-Type" header is sent in requests, and it violates some expectations
> of our proxies. We use clones of maven repositories so we can have some
> governance controls across our codebase and services.
>
> We have ways we could work around around it - we could consider loosening our
> proxies, or adding special handling. We could also build our own plugin that
> does things the way we want. That said, I'd prefer to use off-the-shelf
> tools, and to be able to contribute to open source projects where possible.
>
> I looked a bit into how this plugin is performing deployments. I see it's
> using Aether for the deploy action, and see what looks like some complicated
> history there between Sonatype and Eclipse around the Aether project. I'm not
> sure if this is possible to fix this _in_ the Maven Deploy Plugin or if it'd
> have to go deeper into the Aether code base.
>
> Any pointers? I'd love to take a crack at something here.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
