I am currently using JitPack to access my GitHub repository via Maven. I used to love JitPack, but their servers seem to be overwhelmed, they have terrible technical support, so all in all I'd like to stop using it. Does anyone have a suggestion on what is a good way to achieve a similar result? In other words, I'd like to be able to push a change to my GitHub repo, tag it, and be able to use it in my maven builds immediately.
My follow up question is: why is there even a need for a third party server to host these jars? Is there any way to simply have maven pull these github repos, compile them locally, storing cache in ~/.m2, and that's it. For most of my development effort, this would be enough. I find myself constantly at the mercy of JitPack's crappy servers and poor service that drive me crazy.
Related
I have an external Nexus Open Source version repository, that is connected to an internal one trough proxy repository.
I want to automatically sync the repo with the latest releases and latest snapshots without the need to request them trough a build.
I know there is a capability "Smart Proxy feature" but I can't enable it as we are not using the professional version.
Can you suggest other "smart" and "clean" ways to achieve this?
I was thinking I can create a Jenkins job running every 5 minutes that requests the dependencies thorugh a build using placeholders such as latest release and latest snaphost but i want to know if there is any easier and cleaner way to achieve this.
If my question is not clear please let me know.
Same question asked here but no useful replies.
We run a Nexus 2.14 with a site repository. At the moment, we deploy the sites using DAV, which is at times quite a burden for the server because a lot of small files are transferred separately.
SCP would probably be a better alternative, but I found no information whether this is supported by Nexus and if so, what I need to do to use it.
The Sonatype support told that this is not possible.
We recently brought Golang into the company that I work in for general use, but we hit a snag in the roll out because Go can use the go get command to get packages from the internet. Typically when we roll out Java and Python we are able to limit where the developer can pull packages from by pointing them to our internal artifactory.
So with Python we can change where they pull from by altering the pip command to pull from our internal artifactory, and with Java we can alter their settings.xml and pom.xml to point to our internal packages.
I know that during development you can fetch and pull in dependencies into your local then compile them into a standalone binary. What i am looking for is some mechanism that stops people from going out and pulling from the open internet.
Does something like this exist in Go? Can I stop people from going to the internet and go get 'ing packages?
Any help would be greatly appreciated.
It depends on your definition of "roll out", but typically there are three stages:
Development - at this point you can't prevent arbitrary go get calls, apart from putting the development machines behind restrictive proxies or similar technical measures.
Deployment - since Go programs can (should) be deployed as single binaries, go get is not used at all during deployment.
Building deployment artefacts - this is probably your issue:
The usual approach is not to fetch dependencies when building Go programs. Instead, dependencies are fetched during development, and made part of the source tree using vendoring, for example by using the dep tool.
At this point, the build step no longer needs to fetch any dependencies. The choice of which dependencies are allowed now becomes part of the rest of your process, such as code reviews.
Well, this is kind of embarrassing. I am in the process of mavenizing our build processes and just don't know how the access the result of a build. I build, let's say, a jar file and mvn deploy it. So it ends up as some blah-0.1.2.jar in our company maven repository, which is just a webdav share. Now how would you pass that on to someone else to use? Just pry it from target/blah-0.1.2.jar can't be the answer. I found several suggestions to use variants of mvn dependency:get but they were all just close and didn't feel right. There must be a way to use all those nice versions of blah-*.jar that end up in the repository for purposes other than a maven dependency. Preferably from the command line and maybe even without maven. Hm, a webdav client doesn't look too bad except for snapshots. What would you suggest?
Creating a script that makes a dependency:get call is probably going to be closest to your desired outcome. You can specify the destination of your downloaded jar this way.
If you are looking for an easy way to share builds between people in/outside of your company then you can look into setting up some automated build software like Bamboo or something similar. A new build gets triggered any time a commit is made to the section where your project resides in whatever version control system you use. An artifact is then made available for each successful build and are available via Bamboo's web interface. Bamboo can be configured to run with your maven pom's.
While they can bit a bit of pain to set up, going the automated build route will take a lot of the sting out of sharing your builds in the future.
I am researching the pros/cons of Artifactory and Nexus.
There is a feature in Nexus that I like very much -- the procurement suite. It provides GUI to define the procurement rule. After the procured repository is populated with all the artifacts needed for the build, the admin can choose to stop the procurement and the procured repository is reverted back to be a local repository. As I understand, Artifactory provides includes/excludes pattern definition in the remote repository to achieve similar control, but it is far more rudimentary than what Nexus offers. I am not an expert on Artifactory. Does Artifactory offers something more advanced to tight control the artifacts used in the build, like the procurement suite does?
BTW, I like Artifactory's Watch feature, sending email when a add/delete/update happens in a watched repository. Nexus does not offer email notification, though it provides RSS feed. Artifactory does not support RSS feed now, but it says this feature is in development. Sometimes I just wish there is one product that can offer all these features combined. :-)
Ok. The JFrog folks gave me the official answer and would like to share with everyone. Theincludes/excludes pattern I mentioned in my original question is the main mechanism Artifactory uses to control the access the artifacts in the build. Besides that, Artifactory also offers something called License Control Addon in their Pro version. It basically allows you to manage and get alerted for unauthorized licenses of 3rd party libraries and dependencies when they are getting deployed from your CI server. It does not directly apply to my use case, but it is good to know. Also they pointed out that as a user, I can use their User plugin API to do whatever I want. That's also good to know, but at least for now, I am not interested in developing a plugin for Artifactory myself.
It's been a while since I used artifactory, but I think when you configure a repo, you have the option on applying a regex to the artifacts that it will pull. That might do what you need/want.