Giter VIP home page Giter VIP logo

deps-deploy's Introduction

Clojars Project

deps-deploy

A Clojure library to deploy your stuff to clojars with clj or clojure. It's a very thin wrapper around Chas Emericks pomegranate library.

It will read your Clojars username/token from the environment variables CLOJARS_USERNAME and CLOJARS_PASSWORD, and it will get your artifact-name and version from the pom.xml

Usage

To deploy to Clojars, simply merge

{:deploy {:extra-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
          :exec-fn deps-deploy.deps-deploy/deploy
          :exec-args {:installer :remote
                       :sign-releases? true
                       :artifact "deps-deploy.jar"}}}

into your deps.edn, have a pom.xml handy (you can generate one with clj -Spom), and deploy with

$ env CLOJARS_USERNAME=username CLOJARS_PASSWORD=clojars-token clj -X:deploy

to deploy to Clojars.

It is also possible to override the default Clojars URL by supplying your own. For example:

$ env CLOJARS_URL=https://internal/repository/maven-releases CLOJARS_USERNAME=username CLOJARS_PASSWORD=password clj -A:deploy

This facilitates deploying artefacts to an internal repository - perhaps a proxy service that is running locally that is used to hold private JARs etc...

If you want to sign using another key than the default key, you can specify the signing key id:

{:deploy {:extra-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
          :exec-fn deps-deploy.deps-deploy/deploy
          :exec-args {:installer :remote
                       :sign-releases? true
                       :sign-key-id "1C33430999AA1C3C243A302689CACBAD9979E3C5"
                       :artifact "deps-deploy.jar"}}}

You can use gpg --list-secret-keys --with-subkey-fingerprints to find the key ids that are known on your system.

Deploy to private s3 buckets

To deploy to private s3 buckets, you first need to specify the :repository key in your deps.edn alias with :exec-args as:

:exec-args {:repository {"releases" {:url "s3p://my/bucket/"}}}

Then, when deploying, you need to provide credentials which is done either by:

  1. setting the env vars: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

  2. providing them via java system properties aws.accessKeyId and aws.secretKey or

  3. via an AWS credential profile, in the file ~/.aws/credentials with the AWS_PROIFLE env var used to specify which profile to use (or the [default] profile).

[default]
aws_access_key_id = AKIAXXXXX
aws_secret_access_key = SECRET_KEY

For more details see s3-wagon-provider and if you need to know how to configure an S3 bucket see here.

A note on Clojars tokens

As of 2020-06-27, Clojars will no longer accept your Clojars password when deploying. You will have to use a token instead. Please read more about this here

Long story short, just go find yourself a token and use it in lieu of your password and you're done.

Install locally

deps-deploy also supports installing to your local .m2 repo, by invoking install instead of deploy:

{:install {:extra-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
           :exec-fn deps-deploy.deps-deploy/deploy
           :exec-args {:installer :local
                       :artifact "deps-deploy.jar"}}

Signing

If you want to have your artifacts signed, add "true" as the last element of the :main-opts vector like so:

:main-opts ["-m" "deps-deploy.deps-deploy" "install"
            "path/to/my.jar" "true"]

If you don't want to use the default key for signing, you can specify the key id:

:main-opts ["-m" "deps-deploy.deps-deploy" "install"
            "path/to/my.jar" "true" "1C33430999AA1C3C243A302689CACBAD9979E3C5"]

License

Copyright ยฉ 2018-2021 Erik Assum

Distributed under the Eclipse Public License either version 1.0 or (at your option) any later version.

deps-deploy's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

deps-deploy's Issues

README suggest deploying using the classpath

In the README, it is suggested that the correct use of the dependency is

{:deploy {:extra-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
          :exec-fn deps-deploy.deps-deploy/deploy
          :exec-args {:installer :remote
                      :sign-releases? true
                      :artifact "deps-deploy.jar"}}}

But since the project classpath is not necessary for deploying an artifact that's already been built, I would argue that a better usage with improved performance and less possibility for dependency conflict would be achieved by using :replace-deps (which is the same as :deps in the context of aliases but is more precise):

{:deploy {:replace-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
          :exec-fn deps-deploy.deps-deploy/deploy
          :exec-args {:installer :remote
                      :sign-releases? true
                      :artifact "deps-deploy.jar"}}}

CVE-2022-31159 via Amazon AWS SDK dependency

CVE-2022-31159 affects deps-deploy, via the com.amazonaws/aws-java-sdk-s3 v1.12.49 dependency.

Even without this CVE, v2.0 of the AWS Java SDK was released over 5 years ago, so it's probably time to upgrade deps-deploy to the latest & greatest.

Prints out a `nil` if no username is set.

For deployments, if no username is set for the repository (especially for those that use role based authentication to AWS), the library prints out this:

Deploying foo.bar/worker-0.3.45 to repository releases as nil

If there is no username, it shouldn't print out a nil.

-=david=-

Track releases in GitHub

Would be great to have release tags in GitHub that correspond to release versions. I recently was tracking down the source of an error I was seeing, and the line numbers didn't match up w/ the latest unreleased code. I had to track down the git SHA of the latest release from Clojars and then switch to that. If the release had been in GitHub, I could have gone straight to that.

Remove dependency on org.springframework.build/aws-maven?

deps-deploy indirectly depends on org.springframework.build/[email protected], via s3-wagon-private/[email protected], but this is problematic for a couple of reasons:

  1. The org.springframework.build/aws-maven project was deprecated in 2019
  2. It has a vulnerability via its dependencies - CVE-2017-5929, and the last released version (5.0.0-RELEASE) has more
  3. This library includes a logback.xml file in the deployed JAR (a nasty anti-pattern), which interferes with downstream consumers who wish to provide their own LogBack configuration

I don't know enough about s3-wagon-private/s3-wagon-private to be able to suggest alternatives, but perhaps it has a newer version that uses a less problematic dependency?

Forbidden - no checksums provided for signatures

Thanks @slipset for contacting me for live support on Slack!

Caused by: org.eclipse.aether.transfer.MetadataTransferException: Could not transfer metadata unbroken-promises:unbroken-promises/maven-metadata.xml from/to clojars (https://clojars.org/repo): Access denied to: https://clojars.org/repo/unbroken-promises/unbroken-promises/maven-metadata.xml, ReasonPhrase: Forbidden - no checksums provided for unbroken-promises-0.1.9.xml.asc.
    at org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed(MetadataTransportListener.java:52)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:364)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.put(BasicRepositoryConnector.java:297)
    at org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:320)
    ... 30 more
Caused by: org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: https://clojars.org/repo/unbroken-promises/unbroken-promises/maven-metadata.xml, ReasonPhrase: Forbidden - no checksums provided for unbroken-promises-0.1.9.xml.asc.
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:625)
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:557)
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:539)
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:533)
    at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:513)
    at org.eclipse.aether.transport.wagon.WagonTransporter$PutTaskRunner.run(WagonTransporter.java:653)
    at org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:436)
    at org.eclipse.aether.transport.wagon.WagonTransporter.put(WagonTransporter.java:419)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask(BasicRepositoryConnector.java:519)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:359)
    ... 32 more

This is what I receive now that all the gpg things + Clojars coordinates are in place.

Support writing a supplied version number into the pom.xml

It would be very useful to allow overriding the version number in pom.xml with one a user or CI system can supply as :exec-args or via the command line.

This will allow CI systems etc to easily generate build numbers into the deployed artifacts.

Dependencies are getting out of date

I noticed the recent Maven settings stuff brings in an old version of tools.deps.alpha so I ran antq on your repo and this is what it reported:

|    :file |                             :name |                                 :current |                                  :latest |
|----------+-----------------------------------+------------------------------------------+------------------------------------------|
| deps.edn |         com.cognitect/test-runner | 76568540e7f40268ad2b646110f237a60295fa3c | dd6da11611eeb87f08780a30ac8ea6012d4c05ce |
|          |   com.github.seancorfield/depstar |                                  2.0.211 |                                  2.1.297 |
|          |              org.clojure/data.xml |                             0.2.0-alpha5 |                             0.2.0-alpha6 |
|          |      org.clojure/tools.deps.alpha |                                  0.9.863 |                                0.12.1036 |
|          | s3-wagon-private/s3-wagon-private |                                    1.3.2 |                                    1.3.4 |
|  pom.xml |              org.clojure/data.xml |                             0.2.0-alpha5 |                             0.2.0-alpha6 |
|          |      org.clojure/tools.deps.alpha |                                  0.9.863 |                                0.12.1036 |
|          | s3-wagon-private/s3-wagon-private |                                    1.3.2 |                                    1.3.4 |

Available diffs:

GPG passphrase always refused

Hi again!

It seems like there could be a problem with keys/subkeys because every time I insert my gpg passphrase I receive a:

gpg passphrase: 
Exception in thread "main" java.lang.Exception: gpg: signing failed: Bad passphrase
gpg: signing failed: Bad passphrase

	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at clojure.lang.Reflector.invokeConstructor(Reflector.java:305)
	at deps_deploy.gpg$sign_BANG_.invokeStatic(gpg.clj:52)
	at deps_deploy.gpg$sign_BANG_.invoke(gpg.clj:45)
	at deps_deploy.deps_deploy$sign_BANG_.invokeStatic(deps_deploy.clj:53)
	at deps_deploy.deps_deploy$sign_BANG_.invoke(deps_deploy.clj:51)
	at deps_deploy.deps_deploy$all_artifacts.invokeStatic(deps_deploy.clj:62)
	at deps_deploy.deps_deploy$all_artifacts.invoke(deps_deploy.clj:60)
	at deps_deploy.deps_deploy$_main.invokeStatic(deps_deploy.clj:87)
	at deps_deploy.deps_deploy$_main.doInvoke(deps_deploy.clj:83)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.main$main_opt.invokeStatic(main.clj:491)
	at clojure.main$main_opt.invoke(main.clj:487)
	at clojure.main$main.invokeStatic(main.clj:598)
	at clojure.main$main.doInvoke(main.clj:561)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.main.main(main.java:37)

Is there any additional setting for gpg signing?

Everything else works fine so I exclude a setup problem in my bash variables for gpg.

Outdated deps/NVD security issues

In light of the log4j CVE, I've been running NVD checks against my projects and against some things I depend on. It showed quite a few issues in deps-deploy which are mostly (but not completely) mitigated by bumping the dependencies:

diff --git a/deps.edn b/deps.edn
index f131021..824fd12 100644
--- a/deps.edn
+++ b/deps.edn
@@ -1,17 +1,17 @@
 {:paths ["src"]
  :deps {org.clojure/clojure {:mvn/version "RELEASE"}
         clj-commons/pomegranate {:mvn/version "1.2.1"}
-        s3-wagon-private/s3-wagon-private {:mvn/version "1.3.4"}
+        s3-wagon-private/s3-wagon-private {:mvn/version "1.3.5"}
         org.clojure/data.xml {:mvn/version "0.2.0-alpha6"}
-        org.clojure/tools.deps.alpha {:mvn/version "0.12.1036"}
-        org.apache.maven/maven-settings {:mvn/version "3.8.2"}
-        org.apache.maven/maven-settings-builder {:mvn/version "3.8.2"}
+        org.clojure/tools.deps.alpha {:mvn/version "0.12.1090"}
+        org.apache.maven/maven-settings {:mvn/version "3.8.4"}
+        org.apache.maven/maven-settings-builder {:mvn/version "3.8.4"}
         org.slf4j/slf4j-nop {:mvn/version "RELEASE"}
         org.sonatype.plexus/plexus-sec-dispatcher {:mvn/version "1.4"}}
 
  :aliases {:test {:extra-deps {com.cognitect/test-runner
                                {:git/url "https://github.com/cognitect-labs/test-runner"
-                                :sha "dd6da11611eeb87f08780a30ac8ea6012d4c05ce"}}
+                                :sha "cc75980b43011773162b485f46f939dc5fba91e4"}}
                   :extra-paths ["test"]
                   :exec-fn cognitect.test-runner.api/test}

Those were versions that https://github.com/liquidz/antq identified as outdated.

Support signing without passphrase

I've noticed that deps-deploy uses read-passphrase when signing, but I think this should be optional (and perhaps not even the default), as GPG often has its own mechanisms for managing authentication that this overrides.

On the MacOS GPG suite, for example, when a passphrase is required it will pop up a dialog asking for it, and it has the option to save the passphrase to the MacOS keychain, or remember it for a set period of time. Because deps-deploy asks for the passphrase itself, it bypasses all of this.

Leiningen also has support for signing releases, but by default it leaves getting the password up to GPG.

Too much of my previous pull request was applied

Unfortunately I had to change deps.edn to build and test my pull request, but a few of these lines should not have been accepted:

  :mvn/group-id    com.dcj
  :mvn/version     "2.0.999-SNAPSHOT"

  :deploy {:extra-deps {com.dcj/deps-deploy {:mvn/version "2.0.999-SNAPSHOT"}}

  :install {:extra-deps {com.dcj/deps-deploy {:mvn/version "2.0.999-SNAPSHOT"}}

Sorry...

crash when the value of the key :repository is a string and it's not in ~/.m2/settings.xml

I was trying out the :repository is a string feature, putting :username and :password in the map directly, and I get this NPE. Note that I do not have any ~/.m2/settings.xml file.

Execution error (NullPointerException) at deps-deploy.deps-deploy/get-repo-settings (deps_deploy.clj:131).

It's probably better to use ~/.m2/settings.xml file but it seems like the code ought to allow me to specify things locally or in my ~/.clojure/deps.edn.

Improve command line usability

Having to type EDN at the command-line is a bit of a pain. How about having an alternative way to invoke -main that accepts three plain string arguments path/to/my.jar group-id/artifact-id x.y.z?

Can't open 'deps-deploy.deps-deploy' error

Hi ๐Ÿ˜„

So now that I have the gpg setup going, with the following:

clojure -A:deploy -m deps-deploy.deps-deploy deploy unbroken-promises.jar true

I receive:

Exception in thread "main" java.lang.Exception: gpg: can't open 'deps-deploy.deps-deploy': No such file or directory
gpg: signing failed: No such file or directory

	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at clojure.lang.Reflector.invokeConstructor(Reflector.java:305)
	at deps_deploy.gpg$sign_BANG_.invokeStatic(gpg.clj:52)
	at deps_deploy.gpg$sign_BANG_.invoke(gpg.clj:45)
	at deps_deploy.deps_deploy$sign_BANG_.invokeStatic(deps_deploy.clj:53)
	at deps_deploy.deps_deploy$sign_BANG_.invoke(deps_deploy.clj:51)
	at deps_deploy.deps_deploy$all_artifacts.invokeStatic(deps_deploy.clj:62)
	at deps_deploy.deps_deploy$all_artifacts.invoke(deps_deploy.clj:60)
	at deps_deploy.deps_deploy$_main.invokeStatic(deps_deploy.clj:87)
	at deps_deploy.deps_deploy$_main.doInvoke(deps_deploy.clj:83)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.main$main_opt.invokeStatic(main.clj:491)
	at clojure.main$main_opt.invoke(main.clj:487)
	at clojure.main$main.invokeStatic(main.clj:598)
	at clojure.main$main.doInvoke(main.clj:561)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:705)
	at clojure.main.main(main.java:37)

Support activating maven profiles activation via option

Maven has support for profiles https://maven.apache.org/guides/introduction/introduction-to-profiles.html .

maven-settings ns does not support this unfortunately.

IMO, a user should have the ability to specify extra active profiles in addition to the ones in settings.xml .
https://maven.apache.org/guides/introduction/introduction-to-profiles.html#details-on-profile-activation

This will affect maven-settings/active-profiles and friends.

This is going to be a breaking change IMO.
I can try to add new fn instead of changing the existing ones to mitigate api breakage.

Provide a secure-by-default mechanism for reading credentials

A few options immediately spring to mind in implementing this:

  1. Read a GPG encrypted file. I would strongly consider not even offering a way to load them unencrypted from this file.
  2. Read ~/.m2/settings.xml, which supports encrypted parameters. This might be useful in enterprise settings, but I'm not sure.
  3. Provide a GPG-less encrypted file option? I would punt this down the road, but I can understand that not everyone uses GPG.
  4. I've seen mail clients that allow you to run any shell command in order to provide the password. This is particularly neat if you use a password manager, as you can provide a command like pass show clojars.org and the user runs on whatever encryption they please.

Option 4 allows you to implement 1 very easily, while also handling a large number of people who would want 3.

There's a great opportunity here to redefine the security level for deploying jars, which has historically been quite weak.

The short & medium term future of library packaging in the tools.deps ecosystem

Hi @slipset I started writing a slack message to you, but figured I should probably open a public issue to discuss it instead. This isn't so much a single issue though, it involves how we should organise and arrange a variety of libraries in the tools.deps tools eco system to better support packaging and deploying libraries (and applications).

In the microcosm the problems are motivated by where to put the code in my PR #21. My feeling is that it doesn't currently belong in deps-deploy because the pom should really be created prior to it being packaged in the jar in the first place.

My initial reaction was then to push it into depstar, however after speaking to @seancorfield he thought that would be complecting things, and that he's essentially of the opinion that tools.build will eventually better solve these problems, so he's not willing to invest much time fixing things in this area.

My view here is slightly different to sean's in that depstar is already complected, but along the wrong axis. i.e. it complects uberjarring (an application concern) with library making, and that most of the constraints about how depstar needs to be managed are to ensure no 3rd party deps are included on the classpath when uberjarring.

So I think there are a few ways to try and resolve this:

  1. Do the simple decomplected thing, and move my PR for updating the pom into a separate project. Users wishing to deploy libraries then need to complect (tie) the pom generation, library generation and deployment together themselves in their own code.
  2. Do the easy complected thing that I suspect most of the community would like, which is to complect library-making concerns together, in a way that is untangled from uberjarring. i.e. create a new "lib-maker" project that can update a pom, generate a library jar containing the appropriate assets, and deploy it to either clojars or a private s3 bucket.

My feeling is that it might be best to persue 1 first and either leave enough signposts for others or our future selves to fill in the gaps and implement 2. Hopefully by then tools.build will be done, but if it's not the community might have a better option than the current state of affairs.

Anyway I thought I'd write this up incase you or others have useful things to say on the matter.

Many thanks.

Feature ideas

As of 2.0.next, depstar allows the value of any exec argument to be a keyword which is then looked up as an alias in the full project basis (including your user deps.edn file).

This can be helpful in keeping a deps.edn file DRY (things are only defined once)
IMHO it would be nice if deps-deploy supported this convention as well.
Furthermore, I use private maven repos, which are already defined in my deps.edn under the :mvn/repos key, when specifying the :repository exec-arg to deps-deploy, it would be DRYer if I could specify a string that matched a key in the existing :mvn/repos map.
I am not sure what the best way to get the credentials for this repository. ATM, the credentials are in the ~/.m2/settings.xml file, is there a way that deps-deploy could get them from there? The current CLOJARS_ environment variables are not looked up when not using the default-repository. I suppose another alternative would be to look up other env vars for non-default repos, but ATM I don't love that idea.
What do you think of all this?
Would you consider a pull request on this?

Multiple artifacts with classifiers?

See clojure-doc/clojure-doc.github.io#68 and this Slack thread: https://clojurians.slack.com/archives/C0H28NMAS/p1705364966218609

Per Alex: multiple artifacts with different classifiers all share the same pom and usually they are uploaded as part of the same deployment (with normal maven deploy plugin).

Is this something that deps-deploy might want to support?

If not, is validating the JAR name (to be artifact-version.jar) or renaming it to that during uploading something that deps-deploy might want to handle (to avoid the issue in the thread above)?

No deps-deploy.jar found

Getting this error when running default deployment described in readme.md

Execution error at deps-deploy.gpg/sign! (gpg.clj:53).
gpg: can't open 'deps-deploy.jar': No such file or directory
gpg: signing failed: No such file or directory

Username and password not read from environment vars when deploying to non-clojars repository

When deploying to a non-clojars maven repository the readme suggests using the environment variables CLOJARS_URL, CLOJARS_USERNAME and CLOJARS_PASSWORD. This works as expected.

However - the readme also mentions the possibility to set the repository url in the :exec-args map in the deploy alias in deps.edn like this:

:exec-args {:repository {"releases" {:url "https://internal/repository/maven-releases"}}}

When doing this, the username and password will no longer be read from the CLOJARS_* environment variables (nor from ~/.m2/settings.xml) as one would expect. Adding :username and :password fields to the :repository map does work, but one would most likely want to avoid that.

Remove the need to specify jar file

Leverage the data read from the pom file to locate the Jar file. Current solution is a bit fragile as it requires specifying the same info (like version) twice.

Generate pom with proper artefact information

While using the pom.xml generated by clj -Spom is a reasonable start it also has a few shortcomings:

  • Needs to be checked into version control to maintain artifact coordinates
    • this may cause drift between deps.edn and the pom.xml if developers don't always call clj -Spom after changing deps.edn
  • Manual adjustments cause a poor UX in general

Potentially deps-deploy could also provide tooling to generate a pom.xml?

Boot's pom generation is fairly straightforward and may serve as a good base for this

(~via cljdoc/cljdoc#206)

GPG passphrase asked in unexpected moment

Hi @slipset!

It looks like the signature generation is too aggressive ๐Ÿ˜„

$ clojure -A:deploy -m deps-deploy.deps-deploy -h
Checking out: https://github.com/slipset/deps-deploy.git at 6f872abc0e1e82f037519e15ddd71eb0ea2759b6
Downloading: com/cemerick/pomegranate/maven-metadata.xml from https://repo1.maven.org/maven2/

gpg passphrase:

Maybe just a small tweak, I will try to have a look as well.

Thank you for the package if I haven't thanked you already!

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.