[Commented] (MDEPLOY-131) use default repository when no url specified

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Commented] (MDEPLOY-131) use default repository when no url specified

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931934#comment-15931934 ]

Richard Sand commented on MDEPLOY-131:

Hi Karl - my customers are using COTS products and often don't even have in-house Java developers. They don't know or care what slf4j is. If you want to tell them to read the slf4j docs feel free to :-).

But to answer your question, yes I am using 3 different executions of shade, install-file, and deploy-file in my POM to build the different variations of the main artifact.

I am truly baffled by the maven project's philosophy that it is not acceptable for organizations to use maven tools as those orgs see fit. I've hit this barrier before in the maven community with something as trivial as adding a "skip" parameter to one of the few plugin goals that actually didn't have one. Instead of looking at the feature at face value and deciding if it is useful, instead the response is "well why do you need that? stop doing things the way you are and instead do them as we prescribe".

I avoid multi-module projects whenever I can. My company has used maven exclusively for its projects since 2010. I invite you to take over writing and maintaining all of our POMs, documenting them, educating our developers, etc. Would you do that for me? :-)

Otherwise, can you tell me why you would reject this patch on its face value, rather than making me justify why I'd dare ask about it and submit such a patch?

I've never opened an issue on Jira simply asking for some feature - every ticket I've opened over the years has been accompanied by a patch. I don't expect others to just do work for me - I contribute where I can. I follow every e-mail on the maven-dev and users list. I know the hell that the project has gone through with 3.4/3.5 and some of the soul-searching that has gone on within the maven team. I love this tool, but I think the maven team killing itself by trying to dictate to users the one-and-only way it should be used, and rejecting updates by telling users they can re-tool how they do things rather than accept a 10-line patch. I've contributed to other open source projects in the past, including Apache projects, and never had such negativity towards submissions. I truly do not understand it. Maybe the "silence" on the Jira isn't a good thing?

I now maintain 4 different plugins in my company's repo for trivial patches that make our company's maven implementation stronger, but I've given up getting dragged into philosophical arguments and having to justify how we've done things. Sorry for the rant.


> use default repository when no url specified
> --------------------------------------------
>                 Key: MDEPLOY-131
>                 URL: https://issues.apache.org/jira/browse/MDEPLOY-131
>             Project: Maven Deploy Plugin
>          Issue Type: Improvement
>          Components: deploy:deploy-file
>            Reporter: raymond domingo
>              Labels: contributers-welcome
>         Attachments: DeployFileMojo.java, maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff
> When using the deploy goal there is no need to specify the url of the repository.
> When using deploy-file you DO need to specify the url. This is a problem, because during development I like to deploy to snapshot repository and when releasing i deploy to release repository and I can't add this logic to the pom.
> Thas is why I like the url paramter to become optional (backwards compatible) and add default behaviour when it is null. It should just like the deploy plugin use the default repository. Snapshot for snapshots and release for none snapshot versions.
> I added a patch file fixing this.
> I also added complete source of patched Mojo

This message was sent by Atlassian JIRA