Deploy a bundlet and get the dependent bundles from spring EBR - grails

I have a WAR file that was built using grails framework and OSGi plugin. When I try to deploy it in Eclipse Virgo it fails because the related dependencies are not yet deployed.
Is there a way to tell Virgo to fetch the dependency bundles from spring EBR repository for example ?

You can configure Virgo to use a remote repository to provide the missing dependencies automatically. However, there is an issue in using the SpringSource EBR as a remote repository because Spring framework, which is deployed during Virgo startup, has a very large number of optional/transitive dependencies. When these are pulled in from the EBR they include normally exclusive alternatives and the net effect is that Virgo startup fails.
So the recommendation is either to put the dependencies you want locally in repository/usr or, if you need a remote repository, to set up your own Virgo instance to act as a repository server and put the dependencies in the repository hosted by the repository server.

Related

Repository manager that manages binary dll files (Embedded C/C++ project artifacts) and that integrates with Jenkins

Is there any Repository manager that manages the binary dll files and also integrates well with the Jenkins?
Can Nexus be used to manage the dll files as these files are created as a part of Embedded C/C++ Projects and not sure if Nexus Artifact Manager supports/integrates well with such Projects as it mainly supports the Java projects?
Is there a way to automatically manage the upload and download of such project artifacts from Nexus/other artifact managers without the use of POM file?
Suggest in case there are other Artifact Managers that supports binary artifacts.
Artifactory can be used to store any type of binaries.
Starting with Artifactory 4.0, you can create generic repositories which allows uploading packages of any type. You will not need to upload any POM files and Artifactory will not need to calculate any metadata (for example Maven metadata).
To deploy files you can use the REST API or the UI, for example:
curl -uUSER:PASS -T file.dll http://localhost:8081/artifactory/dll-local/path/to/file.dll
If you have a certain layout you would like to use for this repository you can create a custom layout and associate it with the repository. This can be useful for automatic snapshot/integration versions cleanup and other module management tasks.
Disclaimer: I'm affiliated with Artifactory
The Nexus repository manager is java oriented, but can be used to store any files you want. Binaries of all types or even just text configuration files.
To automate the file upload process, you can use maven from command line:
mvn deploy:deploy-file -DgroupId=com.you -DartifactId=file -Dversion=1.0 -Dpackaging=exe -Dfile=c:\out\file.exe -Durl=http://yourserver/nexus/content/repositories/releases -DrepositoryId=releases
Then, to get the file, you should be able to get it directly with the following URL:
wget http://yourserver/nexus/content/repositories/releases/com/you/file/1.0/file-1.0.exe
This is a simple approach to using Nexus as a general artifact repository.
I hope this helps.
The open source version of Nexus (Nexus OSS) is supports many repository formats out of the box including Maven, NuGet, NPM, RubyGems and others. Nexus just runs on Java (e.g. like Jenkins). It is not Java only...
Depending on how you plan to get the DLL files from the repository, different formats might be more or less suited to your usage. You could even use a custom format, but then you rely custom tools.
The scenarios I have seen at many customers are
using a Maven repo and pulling the files in either in a Maven build together with the Maven NAR Plugin (used for native development with C/C++)
using a Maven repo and pulling via plan HTTP GET calls using your scripting language/build tool of choice
using NuGet format and store the DLLs in NuGet packages in the repo and using nuget to retrieve them for the projects
All of these work well.

Best practice for storing dependencies when automating builds for java applications

We are looking into adopting a more CI friendly approach to managing our on premise jar dependency file server or doing away with it entirely for a better alternative. Right now it is just a Linux server with some form of file structure for example:
http://server_name/vault/apache.org/axis/version_number/axis.jar
http://server_name/vault/apache.org/axis/version_number/jaxrpc.jar
http://server_name/vault/apache.org/axis/version_number/axis.jar
Was wondering what type of standard adopted enterprise CI practices for managing these dependencies when you are doing automated builds.
Would storing them in AWS S3 be a good idea?
Are there any applications that help manage the jar dependency library? (Looking for open source solutions preferably). For example something similar to where you simply add a jar you need, and pull it down using an API when doing a build.
Assuming that apache ant is used for building out the project. And if that doesn't play well in the CI realm, what would be a good alternative?
I would recommend using Apache ivy to manage your build's dependencies. Ivy can be configured to pull your dependencies from Maven repositories which is pretty much the defacto standard now for storing Java binaries.
Use public maven repository with ivy
Maven Central is the largest repository of Java binaries. To host your private binaries there are various ready made options: Nexus, Artifactory or Archiva

How to install grails project

I've created new grails plugin with this quick start reference.
How could I install it to local and remote repository to make it available for other plugins to depend on.
Thanks.
If you are creating a grails "plugin", you should be referring to this information instead. The one you are referring is for creating a Grails Application.
Gist:
Grails app (one you are referring to) creates a deployable component which can be deploed to any container and accessed. On the other hand, grails plugins are extension/modules that are created and maintained separately. packaged as zip and are plugged to any Grails Application when required.
If you are creating a grails plugin and want to push it to local/remote repositories, you need to use the release plugin which comes inside a plugin by default.
grails maven-install
The command is taken from release plugin to push your plugin to local maven repositories, if you have any.

Bypassing Grails proxy settings for local repositories

I'm developing a Grails 2.0.x application that of course has several external dependencies. Since I'm sitting behind a corporate firewall I've configurerd my ProxySettings.groovy to allow access to internet, which works as it should.
Now we also need to include dependencies to some local artifacts (from other projects), which can be found in our local Maven repository. Our corporate network setup is to use the proxy only for external sites, not internal ones. So when Grails resolve my dependencies at startup it downloads all the external artifacts fine, but fails when trying to fetch our local dependencies. If I completely remove the content of my ProxySettings.groovy-file, then the opposite is true, Grails can't resolve the external dependencies, but does manage to download the JARs from our local Maven repository.
I've tried to find documentation on how to exclude internal sites from using the proxy-settings in Grails, but failed miserably so far.
One other alternative could perhaps be to remove (or change) the proxy settings programmtically in BuildConfig.groovy before the call to mavenRepo?
Currently we are not using Maven to build our Grails projects (since we previously have had some issues with creating release builds on the build server).
Any help would be much appreciated!
Right now I do not thing there is an easy way to get around this.
There is currently an open bug for being able to switch the Proxy-Setting programmtically
http://jira.grails.org/browse/GRAILS-7658
Another option would be to move the internal dependencies inside your grails project.
or you could just dump everything in BuildConfig.groovy
System.properties.putAll([
"http.proxyHost": "myproxy.hostname.com",
"http.proxyPort": "8080",
"http.proxyUserName": "myUser",
"http.proxyPassword": "myPass"
])
clear it out for the internal dependencies and then you might be good.

Maven repositories

We are using maven in the development process. Maven provides a nice feature of configuring the repositories. Using this feature I have created a remote internal repository and I can download the dependencies from that repository.
The development machines are pointing to this remote internal repository. Each development machine has its own local repository(~/.m2/repository/) and hence the dependencies of the project are downloaded from the remote internal repositor**y to the **local repository(~/.m2/repository/) on each developer machine.
Is there any way that the local repository(~/.m2/repository/) on developer machines can be set to the internal remote repository that we have created and which is used for downloading the dependencies from.
If take a look on Maven Introduction to Repositories first paragraph says:
There are strictly only two types of repositories: local and remote.
There is no way how you could change this behavior.
If you would handle that differently it would cause many problems. E.g. build would take much longer because of downloading file all files, IDE would work not work properly (project dependencies would not be stored local), ...
May I suggest another approach to share dependencies and artifacts. In our projects we use nexus as a proxy and repository for our artifacts. It works well with no issues. A basic configuration I already posted here.
After nexus is running you could also setup continous integration using jenkins and enjoy a fully automated environment.
Is your requirement to avoid each developer from having to download all dependencies to his local repository?
Assuming your remote internal repository has the same format as a maven local repository, you can achieve this by adding the following line in the settings.xml of all your developers.
<localRepository>shared-drive-location-of-remote-repository</localRepository>

Resources