Giter VIP home page Giter VIP logo

bintray-maven-plugin's Introduction

Bintray Maven Plugin

A Bintray plugin to deploy Maven artifacts and upload Eclipse repositories.

Project License Travis Status Lines of Code

Production Release Development Release
Install
Central Bintray

Similar plugins

Plugin features

  • proxy authentication
  • bintray target package removal
  • create bintray target package on-demand
  • automatic cleanup of old bintray target versions
  • preservation of selected versions from cleanup by regex
  • upload folder content, such as eclipse p2 repository, to fixed path
  • automatic cleanup of previous eclipse p2 repository resources by regex

Maven goals

Usage examples

bintary:deploy - deploy maven artifacts:

mvn clean deploy -P distro-bintray
        <profile>
            <id>distro-bintray</id>
            <build>
                <plugins>

                    <!-- Disable default deployer. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-deploy-plugin</artifactId>
                        <configuration>
                            <skip>true</skip>
                        </configuration>
                    </plugin>

                    <!-- Enable alternative deployer. -->
                    <plugin>
                        <groupId>com.carrotgarden.maven</groupId>
                        <artifactId>bintray-maven-plugin</artifactId>
                        <configuration>
                            <skip>false</skip>

                            <!-- Bintray oranization name. -->
                            <subject>random-maven</subject>

                            <!-- Bintray target repository. -->
                            <repository>maven</repository>

                            <!-- Bintray credentials in settings.xml. -->
                            <serverId>distro-bintary</serverId>

                        </configuration>
                        <executions>
                            <!-- Activate "bintary:deploy" during "deploy" -->
                            <execution>
                                <goals>
                                    <goal>deploy</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

bintary:upload - upload eclipse p2 repository

mvn clean deploy -P upload-bintray
        <profile>
            <id>upload-bintray</id>
            <build>
                <plugins>

                    <!-- Disable default deployer. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-deploy-plugin</artifactId>
                        <configuration>
                            <skip>true</skip>
                        </configuration>
                    </plugin>

                    <!-- Enable alternative deployer. -->
                    <plugin>
                        <groupId>com.carrotgarden.maven</groupId>
                        <artifactId>bintray-maven-plugin</artifactId>
                        <configuration>
                            <skip>false</skip>

                            <!-- Bintray oranization name. -->
                            <subject>random-eclipse</subject>

                            <!-- Bintray target repository. -->
                            <repository>eclipse</repository>

                            <!-- Nominal permanent bintray identity. -->
                            <!-- Actual remote content will mirror local dir. -->
                            <!-- These coordinates must be rotated to work around bintray policy. -->
                            <bintrayPackage>tracker</bintrayPackage>
                            <bintrayVersion>release</bintrayVersion>

                            <!-- Local folder content to sync to the remote repo. -->
                            <sourceFolder>${project.build.directory}/repository</sourceFolder>
                            <!-- Remote folder for local content upload, relative path. -->
                            <targetFolder>repository</targetFolder>

                            <!-- Bintray credentials in settings.xml. -->
                            <serverId>distro-bintary</serverId>

                        </configuration>
                        <executions>
                            <!-- Activate "bintary:upload" during "deploy" -->
                            <execution>
                                <goals>
                                    <goal>upload</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

Build yourself

cd /tmp
git clone [email protected]:random-maven/bintray-maven-plugin.git
cd bintray-maven-plugin
./mvnw.sh clean install -B -P skip-test

bintray-maven-plugin's People

Contributors

adamretter avatar andrei-pozolotin avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar

bintray-maven-plugin's Issues

Enhancement: Add functionality and configuration option to clean a Bintray target folder before uploading

When needing to re-spin a release, the release files (a P2 repository) get new timestamps in their file names.

When uploading the files as is, the previously uploaded files stay in the Bintray repository and need to be manually removed (which is somewhat cumbersome).

An idea for enhancement of this plugin would be to add code and configuration option to optionally clean the upload target folder before uploading OR to have an addition new clean goal.

upload goal does not work behind proxy requiring authentication

When sitting behind a http proxy requiring authentication the upload goal fails.

Proxy settings in settings.xml or via -D parameters (-Dhttps.proxyHost=*** -Dhttps.proxyPort=*** -Dhttps.proxyUser=*** -Dhttps.proxyPassword=***) seem not to be honored correctly.

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.carrotgarden.maven:bintray-maven-plugin:1.1.20171202224405:upload (upload-update-site-package) on project net.sf.eclipsecs-updatesite: Execution error
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: Execution error
    at com.carrotgarden.maven.bintray.BaseExecute.execute (BaseExecute.scala:28)
    at com.carrotgarden.maven.bintray.BaseExecute.execute$ (BaseExecute.scala:16)
    at com.carrotgarden.maven.bintray.UploadMojo.execute (UploadMojo.scala:17)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.io.IOException: Failed to authenticate with proxy
    at okhttp3.internal.connection.RealConnection.createTunnel (RealConnection.java:380)
    at okhttp3.internal.connection.RealConnection.connectTunnel (RealConnection.java:211)
    at okhttp3.internal.connection.RealConnection.connect (RealConnection.java:152)
    at okhttp3.internal.connection.StreamAllocation.findConnection (StreamAllocation.java:256)
    at okhttp3.internal.connection.StreamAllocation.findHealthyConnection (StreamAllocation.java:134)
    at okhttp3.internal.connection.StreamAllocation.newStream (StreamAllocation.java:113)
    at okhttp3.internal.connection.ConnectInterceptor.intercept (ConnectInterceptor.java:42)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:147)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:121)
    at okhttp3.internal.cache.CacheInterceptor.intercept (CacheInterceptor.java:93)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:147)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:121)
    at okhttp3.internal.http.BridgeInterceptor.intercept (BridgeInterceptor.java:93)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:147)
    at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept (RetryAndFollowUpInterceptor.java:125)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:147)
    at okhttp3.internal.http.RealInterceptorChain.proceed (RealInterceptorChain.java:121)
    at okhttp3.RealCall.getResponseWithInterceptorChain (RealCall.java:200)
    at okhttp3.RealCall.execute (RealCall.java:77)
    at com.carrotgarden.maven.bintray.BintrayApi.hasPackage (BintrayApi.scala:261)
    at com.carrotgarden.maven.bintray.BintrayApi.hasPackage$ (BintrayApi.scala:258)
    at com.carrotgarden.maven.bintray.UploadMojo.hasPackage (UploadMojo.scala:17)
    at com.carrotgarden.maven.bintray.BintrayApi.ensurePackage (BintrayApi.scala:329)
    at com.carrotgarden.maven.bintray.BintrayApi.ensurePackage$ (BintrayApi.scala:328)
    at com.carrotgarden.maven.bintray.UploadMojo.ensurePackage (UploadMojo.scala:17)
    at com.carrotgarden.maven.bintray.UploadMojo.perform (UploadMojo.scala:99)
    at com.carrotgarden.maven.bintray.BaseExecute.execute (BaseExecute.scala:26)
    at com.carrotgarden.maven.bintray.BaseExecute.execute$ (BaseExecute.scala:16)
    at com.carrotgarden.maven.bintray.UploadMojo.execute (UploadMojo.scala:17)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
```

Enhancement: Allow configuration for uploading single files OR excludes/includes on folders

Currently it is a bit complicated to upload a single file from an otherwise populated directory using this plugin.

Please check this setup: https://github.com/checkstyle/eclipse-cs/blob/master/net.sf.eclipsecs-updatesite/pom.xml

The second execution (upload-update-site-archive) uploads a single archive file to a different path in the Bintray repo. Since the archive file is being created in a directory containing other stuff as well I cannot upload it directly, since the plugin only allows for configuration of source folders, which are uploaded completely.

So in order to make it work for this case I needed an additional Ant task, which copies the single file to a new directory, which is then uploaded.

My setup would be less complicated if the plugin either allowed for configuration of single source files OR for configuration of the typical exclude/include mechanics for the source folder.

Usage question - how is bintray package name determined?

I've been struggling to find a reliable way to deploy the artifacts from a multi-module maven project to a bintray repository such that I can also mirror those artifacts to JCenter (and eventually to maven central). The jcenter requirement apparently comes at a cost... for the jcenter mirroring to work, I apparently must deploy each module's files (pom, jar, etc.) to a module-specific package within my bintray repository. Note that this one-module-per-bintray-package requirement is never mentioned in the multi-module maven example provided by bintray (ugh).

I've tried using the default maven-deploy-plugin but of course that causes all files associated with all my modules to be deployed to the single bintray repo and package that are identified in the repository URL specified in the distributionManagement section. Unfortunately, that prevents me from being able to mirror/link the files to JCenter.

I was excited to discover this git repo with the bintray maven plugin. I want to give it a try, but just curious... do you use the maven coordinates (e.g. :) to determine the name of the bintray package where each module's files should be uploaded?
And... do I need to pre-create the bintray package associated with each module in my project or will the plugin create bintray packages on the fly within the configured bintray repo?

Thanks in advance!

Feature request: add optional "sync to maven central step" to bintray-maven-plugin

I've been using the bintray-maven-plugin successfully in a multi-module maven project (https://github.com/IBM/platform-services-java-sdk) for a few releases now.
My artifacts are published to my bintray repo and those artifacts are also exposed on JCenter.

There's one more step that I need to add to my build, and that is to sync the artifacts from JCenter to Maven Central.

In another (single-module) project, I do this via a shell script that uses curl to invoke the bintray "maven_central_sync" REST API. After the "deploy" phase of the build publishes the artifacts on the bintray repo, the shell script is executed to sync those artifacts to MC.

I was going to adapt this shell script to work in my new project, but was thinking that it would be great if the bintray-maven-plugin could support this "sync to MC" functionality as an additional optional step after deploying the artifacts to the bintray repo, perhaps controlled either by a new boolean flag (e.g. performMCSync) or perhaps a specific goal could be exposed which could be triggered after depoy (e.g. mvn bintray:syncMC).

Any chance this could be added as a new feature?

If you feel this would be a worthwhile addition to the project, I could try to submit a PR with the changes.

Thanks,
Phil

Question re: interactions between bintray-maven-plugin and eclipse m2e plugin

I've introduced the use of bintray-maven-plugin into my project located at (https://github.com/IBM/platform-services-java-sdk). It is working fine when the "deploy" goal is built as part of my Travis builds.

I have a separate issue, however. In my local sandbox development environment, I use Eclipse as my Java IDE. Each of the modules in my project have been imported as a separate Eclipse "project", which is the normal way to represent modules of a maven project in Eclipse. When managing maven projects in Eclipse, from time to time it is necessary to trigger the "Maven -> Update Project" action, which (among other things) refreshes Eclipse's view of jar dependency information from the current set of pom.xml files (i.e. the parent and the module poms).

When I trigger the "Maven -> Update Project" action on one or more of my projects, I see errors in the "Problems" window that indicate that the "deploy" goal was triggered.
Here is an example error message from one of the projects:

Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to deploy artifacts: Could not transfer artifact com.ibm.cloud:global-catalog:jar:99-20200508.153213-1 from/to bintray (https://bintray.com/api/v1/maven/ibm-cloud-sdks/platform-services-java-sdk/com.ibm.cloud:global-catalog): Failed to transfer https://bintray.com/api/v1/maven/ibm-cloud-sdks/platform-services-java-sdk/com.ibm.cloud:global-catalog/com/ibm/cloud/global-catalog/99-SNAPSHOT/global-catalog-99-20200508.153213-1.jar. Error code 400, Bad Request

I'm not surprised by the fact that an error occurred since I don't have the correct creds set up in my local environment, and I am not deploying snapshot releases to bintray in any event. In fact, I don't want the deploy goal to be triggered at all in my local sandbox.

I have opened an issue against the m2e plugin to try to determine why the "deploy" goal is triggered in my local environment when a simple "package" or "install" goal would suffice. But, I thought I would check here to see if you have encountered this issue before with other Eclipse users. Perhaps there is something unique about the bintray-maven-plugin in how the m2e plugin interacts with it. I have never encountered this issue with the maven-deploy-plugin.
As an additional data point, I flipped the bintray-maven-plugin's "skip" config property to true temporarily and, as expected, the error doesn't occur. Flipping the skip property back to false, will cause the error to re-appear as soon as I perform the "Maven -> Update Project".
So for now, I can leave "skip" set to true in the parent pom, but then override it in my "mvn" command within my Travis build since that's the only environment where I want to do deployments.

Thanks in advance for any info you might have about this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.