can some one help me. I want to setup a internal repository for maven. For this i wanted to use Apache Archiva and i'm new to both maven and archiva. My question is what is the exact difference b/w standalone and web archiva installations (i found these 2 ways in archiva documentation).
My intention is to create internal repository to be used by all developers. Every one should get dependencies from there. I have to install archiva in a server with in our organization(LAN). What is the preferable for my situation?
I found steps to install in both ways, but they are little confused as i am new to archiva. Could some one please explain me clearly?
Operating System : Windows
Maven : 3.0.5
Archiva : 1.3.6
Thanks in advance.
The standalone distribution is more easy to install.
The wrapper will restart your instance in case of issues.
The important part is to separate content from installation see http://archiva.apache.org/docs/1.4-M3/adminguide/standalone.html section "Separating the base from the installation"
Related
I am trying to upgrade Jenkins from version 2.176.1 to 2.375.2. I tried two methods and both of them failed.
Method-1: Download the jenkins.war and copy it into /usr/lib/jenkins/ directory by replacing the original one. After copying, when I restart Jenkins, it simply fails to restart.
Method-2: Upgrade Jenkins' RPM using yum update jenkins. This command runs successfully and process exists without any error. But, again when I restart Jenkins, it fails to start.
CentOS version: CentOS-7
First of all - I can only support opinion of Dmitriy Tarasevich about reading upgrade guides. You can find theme here: https://www.jenkins.io/doc/upgrade-guide/
Then - stick to the version upgrade process that you've used previously (or for the first time with installation). If you did install it via .*war, don¨t worry and use your Method-1. On the other hand, if you used yum, stick to that method-2.
Then - such a "big" upgrade at once from 2.176.1 to 2.375.1 is, I'd say, the reason it's failing for you as the version in between contain several major/breaking changes (our team has faced the same problem (we "just" wanted to bump the versions too much after a long time of no upgrading and we've faced several problems we weren't able to solve together). So it was necessary to split it into several independent upgrades which appeared to be doable and we managed to get to LTS 2.375).
To summarize recommended steps - I'd you need to:
1/ Split your upgrade into several steps and upgrade LTS more gradually: try to upgrade to first to some not-current LTS version. I believe something less than or precisely 2.303.3 could work and see if you can start it.
then actually run Jenkins and check administration page,
upgrade your plugins (if you want). FYI: this is recommended officially in Jenkins docs after every Jenkins core upgrade.
check Jenkins administration page and apply necessary changes / manage necessary decision that might appear there (if applicable).
2/ Try to upgrade to a higher LTS version (repeat step 1 with its sub-steps)
To be a very specific and give some examples (although I don't remember everything by hearth):
you skipped a gradually upgrade to version 2.319 LTS that brings a major change of working with master node --> built-in node that needs to be applied (confirmed) from within the administration section of Jenkins (see docs: https://www.jenkins.io/doc/book/managing/built-in-node-migration/ )
version 2.332.1 LTS brings an important change. I would say that you've hit exactly this issue (covered here): https://community.jenkins.io/t/jenkins-cant-find-java-after-update-running-on-centos-7/3615 - exact steps and more resources are within that thread and also here: https://www.jenkins.io/doc/upgrade-guide/2.332/#upgrading-to-jenkins-lts-2-332-1
from version 2.361 LTS Jenkins requires Java 11 or higher (see docs https://www.jenkins.io/doc/upgrade-guide/2.361/ ). So - you will need to ensure that you have a proper Java installed (you already might have it though). Including your agents!. Otherwise you would start your Jenkins but it would not connect any agent (usually undesired state).
Please, try to make some gradual progress and let us know where you managed to get
I'm working in an Erlang environment. I'm looking to establish a dependency manager so that our build server can publish binaries for reuse instead of using source code dependencies. The Hexpm GitHub project implies that it is possible to run it outside of the hex.pm website, but I don't see any instructions for doing so. Specifically, I would like my build server to be able to publish packages either directly (via the filesystem) or via rebar3, and for subsequent rebar3 builds to be able to use those published packages
Is it possible to run Hex on my own server?
If so, where would I find some documentation on how to set it up (or provide the instructions directly)?
If you look at https://github.com/hexpm/hex_web there are instructions in the README.md for both installing and running it. It's a phoenix application, so it should all be relatively familiar ground if you've looked at the phoenix framework before.
As for getting rebar3 to work with your installation, there is documentation here as to the config values to use for setting the URLs to use for hex packages: http://www.rebar3.org/docs/hex-package-management.
HTH.
refresh dependencies fails due to firewall+proxy combonation.
The corporate IT is not going to make an exception. I have found that I can do a recursive wget on the repo url and generate duplicate their folder structure.
What can I do locally so that all developers can use this "mirror" by default?
If the above is not possible, where does grail usually put these files on a windows based installation?
Try adding local repo to your BuildConfig and of course make it accessible over your LAN, or perhaps tell other devs to make their local cloned repos. The path to this local repo could be ENVARIONMENT_VARIABLE, too (that makes it fully customizable)
repositories {
grailsPlugins()
grailsHome()
mavenCentral()
mavenRepo('/path/to/my-local-maven-repo')
}
http://jdpgrailsdev.github.io/blog/2014/02/10/grails_maven_local_repo.html
You have a couple of options here.
First, if it's just a normal proxy than you can configure grails to utilise it. Take note of the following grails commands:
grails add-proxy
grails set-proxy
These in turn will establish a file in your home directory in .grails called ProxySettings.groovy (i.e. ~/.grails/ProxySettings) that is then used by all grails commands for all projects.
However, if you're behind a Microsoft NTLM proxy (as I am) then I'd suggest still doing the above by making use of Java NTLM Proxy.
(Keep in mind though, that the grails wrapper does not use the above ProxySettings.groovy and then you need to use the standard JAVA_OPTS of -Dhttp.proxyPort, -Dhttp.proxyHost, etc.)
But I appreciate maybe you've done all that and you still want to avoid the proxy. I'd suggest the next solution - and one that should be considered anyway - is setting up a corporate/internal Maven repository server with something like Artifactory or Nexus.
Lastly, there is the instruction from MamyKryzysKryzysKryzys with using mavenRepo( <localPath> ). More info on that is available in the grails doco.
Finally, to address your question of "where does grail usually put these files". Under the hood grails is simply using maven so it's stored in your normal maven local repo which is ~/.m2/repository.
Good luck! Proxies make things hard, but once you figure your solution it's a thing of the past. Personally, we now use a combination of the Java NTLM Proxy and an internal Artifactory server.
I am following this tutorial on Grails and Cloudbees And it says :
"to use CloudBees databases locally from your application, you first need to add the CloudBees SDK's appserver.jar file to your grails classpath"
Does anyone know what is this appserver.jar? Where can I find it?
Yes, as mentioned in the comment - you can get that jar file from the SDK you download.
However, it is perfectly find (and possibly better) to use the mysql driver directly as mentioned.
When running on cloudbees, you can bind your app to a database - so that at runtime the right database is injected - using the bees db:bind SDK command.
I have seen this question about deploying to WebSphere using the WAS ant tasks.
Is there a simpler way to do this? In the past I have deployed to Tomcat by dropping a war file into a directory. I was hoping there would be a similar mechanism for WebSphere that doesn't involve calling the IBM libraries or rely on RAD to be installed on your workstation.
Just a hint: if you activate "Log command assistance commands" in System Administration / Console preferences, you will get a logfile in the server log directory that contains the jython scripts for all actions you did on the console. So you can just deploy your stuff per console the first time, and then grab the commands for later and feed them into wsadmin.bat -lang jython "thecommandscomehere" for the next deployment.
There is the concept of WebSphere Rapid Deployment. It's supposed to be the same experience as what you describe for Tomcat.
One way to do it could be using Jython or jacl scripts. See those samples at IBM site.
[EDIT] Especially the wsadminlib.py.zip download near the bottom of the page contains a huge set of examples and helper functions to get you started.
WAS does provide a client jar containing some custom ant tasks. However they seem to be extremely bugy and dont work with remote servers.
IBM ANT TASK Javadoc
Netbeans also has support for was 6 and 6.1 but this again is still quite buggy, however it can be useful for generating some the bindings files etc.