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

[jira-importer]

raymond domingo opened MDEPLOY-131 and commented

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

---

Attachments:

• DeployFileMojo.java (14.57 kB)
• maven-deploy-useProjectRepo-20170319.patch (2.78 kB)
• patch_deploy_file_mojo.diff (3.98 kB)

4 votes, 9 watchers

[jira-importer]

Stephen Connolly commented

I am -1 on the currently attached patch for the following reason

It mandates that the deploy:deploy-file be run in a directory that has a pom.xml

There are a lot of people who use deploy:deploy-file to get their non-maven projects deployed to maven repositories. These people may not have a pom.xml (and while I agree that they should they are currently not required to do so), or they may not call the pom file pom.xml rather someartifact.pom

For that reason I am against the currently attached patch.

A patch which has test cases and does not require the user to do

mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom -f someartifact.pom

but instead lets them do

mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom

rather than the current

mvn deploy:deploy-file -Dfile=someartifact.jar -DpomFile=someartifact.pom -Durl=...

if someartifact.pom contains the deployment url

would seem like a good improvement

[jira-importer]

Darshak Thakore commented

i agree that the patch shouldn't force existing behavior, however the need to let deploy-file use the default repositories from the repositoryManagement section is also very important. Specifically since the deploy goal does not allow specifying secondary artifacts (eg. a zip file)

[jira-importer]

Dave Roberge commented

Hey, I'm attempting to implement this, and am hoping to get some feedback. I ran into an issue when writing a test in DeployFileMojoTest. I created a plugin-config.xml file similar to the others for deploy-file goal, it looks like:

<project>
  <distributionManagement>
    <repository>
      <uniqueVersion>false</uniqueVersion>
      <id>deploy-test</id>
      <name>Test Repository</name>
      <url>file://${basedir}/target/remote-repo/deploy-file-dist-mgmt</url>
      <layout>default</layout>
    </repository>
  </distributionManagement>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-deploy-plugin</artifactId>
        <configuration>
          ...
          <pomFile>${basedir}/src/test/resources/unit/deploy-file-dist-mgmt/plugin-config.xml</pomFile>
          ...
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

The problem is that basedir variable in distribution management section is not interpolated when being read in so it installs the artifact at the root of the filesystem. Does anyone have ideas on how fix that, or should I look for alternative approaches?

[jira-importer]

Arne Brix commented

I have a similar usecase. We use the replacer plugin to modify our pom file (using a jenkins env-variable) before it is being deployed.
With the old deploy plugin we could simply set the pomFile property to specify the path of the changed pom for deploy:deploy but now we must use deploy:file and that's not really practical if one has different repositories for releases and snapshots.
So please let deploy:deploy honor the pomFile property as before or add automatic repository selection to deploy:file.

[jira-importer]

Robert Scholte commented

Arne Brix, that's a different issue which I'm not going to change or fix. Read http://markmail.org/message/mvorlh6cg6yi3zbg to understand why this has been changed. If you want to know more, use the user mailinglist.

[jira-importer]

Richard Sand commented

This thread has been inactive for a couple of years, but I'm guessing that the need for deploy-file to be able to use the existing project's default repositories is still out there. I've attached a very simple patch to enable this without changing the existing behavior of any current deployments. See the attachment "maven-deploy-useProjectRepo-20170319.patch"

The patch adds a new configuration parameter called "useProjectRepository" (default false of course). When set to true, it will use the project's default artifactresolver. It changes "url" from required to optional, but throws an error if "url" is missing and "useProjectRepository" isn't explicitly set to true, so it won't disrupt any current behavior.

I've used this new parameter in two of my company's projects to good effect. I use it in combination with maven shade plugin, to create multiple permutations of a shaded jar that includes different log capabilities (e.g. one has slf4j and slf4j-jcl, another has slf4j and jcl-over-slf4j, one has only slf4j, etc). I allow the shade plugin to create the dependency reduced pom, then deploy-file to attach the alternate jar and pom to a different artifact ID. It works great!

-Richard

[jira-importer]

Richard Sand commented

Adds new optional (default false) parameter "useProjectRepository". Code is commented and passes junit tests, checkstyle etc.

[jira-importer]

Karl Heinz Marbaise commented

This is an example for using a classifier which can be configured in pom by multiple executions of the maven-shade-plugin and no need for deploy-file...and of course not for using a different artifactId.

<plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-shade-plugin</artifactId>
       <configuration>
         <shadedArtifactAttached>true</shadedArtifactAttached>
       </configuration>
       <executions>
         <execution>
           <id>test</id>
           <phase>package</phase>
           <goals>
             <goal>shade</goal>
           </goals>
           <configuration>
             <shadedClassifierName>test</shadedClassifierName>
           </configuration>
         </execution>
         <execution>
           <id>dev</id>
           <phase>package</phase>
           <goals>
             <goal>shade</goal>
           </goals>
           <configuration>
             <shadedClassifierName>dev</shadedClassifierName>
           </configuration>
         </execution>
         <execution>
           <id>prod</id>
           <phase>package</phase>
           <goals>
             <goal>shade</goal>
           </goals>
           <configuration>
             <shadedClassifierName>prod</shadedClassifierName>
           </configuration>
         </execution>
       </executions>
     </plugin>

In any of the configurations you can change the things you would to include/transform etc.

[jira-importer]

Richard Sand commented

Hi Karl - thanks for the quick reply, but the example you posted doesn't address the use case I've described. I'm not building different dev-vs-prod artifacts. I need all of the artifacts to be in our repo, the original jar and the shaded uber-jars, and they cannot be under the same artifact ID otherwise they have the same POM and same dependencies. Each shaded artifact produced needs to be deployed along with it's unique dependency-reduced-pom.

[jira-importer]

Richard Sand commented

In other words, I'm not replacing the default artifact or default pom, but using shade to create alternative variants with different dependencies and using deploy-file to deploy them all

[jira-importer]

Karl Heinz Marbaise commented

It was just an example having different artifacts attached to the same build without deploy-file...If you really need having shaded using different dependencies you need simply make different modules of them.
Apart from that using slf4j means you only define a dependency to slf4j-api and the user of that lib/jar decides what is really being used in the end. So maybe I misunderstand a thing but it sounds like the other created jars could be omitted and are not really needed...

[jira-importer]

Richard Sand commented

Hi Karl - I could make a multi-module project, but why when there is a very simple capability that can let me avoid that and have 1 POM build everything I need? If you take a look at the patch its hardly anything at all and adds a capability that is useful and that others have requested.

Regarding the slf4j - there are situations where my customers want a single jar that can be dropped into their application without a single other dependency, which is really the use case for shaded jars in the first place. And they are not familiar with slf4j, so I provide a shaded jar that has slf4j and for example slf4j-jcl or slf4j-jul, so that they can continue to run with whatever log framework they're already using without needing any other jar than the single that our product provides.

[jira-importer]

Karl Heinz Marbaise commented

Have you bound deploy plugin in your pom with the deploy-file goal several times which means you can call simply mvn clean deploy and that's it?
If so you are violating the separation of concerns of a pom file cause a single pom file should have only one concern which means produce a single artifact (identified by groupId, artifactId, version) or maybe several but having the same dependencies...If you need to have different dependencies this means you should have different pom files.
Sorry to say if your customers are not familiar with slf4j than they should read the manual...but I can understand that you like to offer them a convenient solution which can simply being done by using different pom's with a single concern which in result produces a multi module build.

Based on others requests..This issue is open for a long time and last comment is of 2014..more than two years silence so it couldn't be real big problem..apart from that there clean solutions for this which I already described...

[jira-importer]

Richard Sand commented

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.

-Richard

[jira-importer]

Robert Scholte commented

Hi Richard,

I think we need to cool down things. When reading your story for the first time I had the same idea as Karl Heinz. I consider suggesting a solution which matches the current Maven behavior as a great help.
Reading your situation over again, I see your situation:
1 sourceproject results in multiple artifacts (jar + pom), meaning different artifactIds.

I think the situation is too rare to apply the patch. A custom plugin makes more sense.
Maybe there's good news: stephenconnolly is working on a proposal for the next major version of Maven. And one of the suggestions is to have a pom for every uploaded artifact. Mapping this to your situation you could attach every artifact with the same artifactId, but with a separate classifier.
Another option I'm thinking of right is to have multiple pom-files if the root of your project. Maybe even with an aggregator

pom.xml (aggregator with modules pointing to every pom below)
pom-default.xml
pom-jcl.xml
pom-jul.xml

this way there's no need for multiple separate calls, no need for separate commandline arguments.