I have many projects in my company and every project has its own set of java plugins and versions. Is there a way I better manage the plugins for all my applications to ensure they are all up to date?
The concept is similar to a patch management system, where it stores information about the patch levels for all your servers, and you have a way to uniformly apply the patch across all your machines.
I would like to establish a similar infrastructure for our development environment. Is there a way at all?
You could try using maven as a build system for your projects and set up a central nexus/artifactory server where you set all the needed dependencies.
In your pom.xml you can define which major/minor version you would like to use. (as answered here: How do I tell Maven to use the latest version of a dependency?)
Related
I'm using org.jboss.redhat-fuse/fabric8-maven-plugin in one my project but somehow the latest version is always behind.
Is there any reason why we are encouraged to use org.jboss.redhat-fuse/fabric8-maven-plugin for RH Fuse project? instead of io.fabric8/fabric8-maven-plugin
I'm the maintainer of io.fabric8/fabric8-maven-plugin.
org.jboss.redhat-fuse/fabric8-maven-plugin is Jboss's fork of upstream fabric8 maven plugin i.e io.fabric8/fabric8-maven-plugin. Jboss's fork may contain some jboss related patches as per it's requirements. I think it is used under FUSE internals like for Fuse Online. Usually it's synced with upstream plugin from time to time.
If you want to use plugin as a general purpose Kubernetes/Openshift plugin. I recommend to use upstream Fabric8 Maven Plugin. If you are working around FUSE related stuff, then maybe go with Jboss's fork since it's tried and tested. But I think upstream would also work fine.
From nexus documentation, I can only find osgi related sections in version 2.xx, does osgi support removed in version 3 or it's a builtin feature now?
OBR support is unlikely to come to Nexus Repo 3 any time soon from Sonatype officially, but that shouldn't stop people from doing it themselves.
Here are a few examples of Repo formats implemented in Nexus Repo 3:
https://github.com/sonatype/nexus-repository-r
https://github.com/mpoindexter/nexus-repository-apt
A few more are coming soon, and should provide a good basis for someone who wants to implement OBR.
As for why OBR hasn't been implemented yet, it's mainly due to priorities, we've got a lot of new and old to implement and it's pretty far down the list at the moment.
If anyone has interest in implementing OBR support, feel free to reach out to me and I'll help best I can, that's one of my jobs at Sonatype. You can get in touch with me near real time at: https://gitter.im/sonatype/nexus-developers
There really isn't any need to rely on Nexus plugins in order to get an indexed OSGi repository. In fact I wouldn't recommend it because the version of OBR support in Nexus (in versions of Nexus that support it natively) lags far behind the latest standards.
Instead, use the bnd-indexer-maven-plugin to generate an index for a set of Maven dependencies. The output of this plugin, along with the dependencies themselves, can be deployed to a Nexus repository or any other repository with Maven support.
Nexus 3 support list is here. So no OBR support in Nexus3 yet. Even if the status is "Working on that" it is unlikely it will be there soon.
I was wondering if there is a distribution management entity for java based artifacts, very similar to the way RHEL (or the like) distributes the linux based artifacts. Some of the features that were of interest were:
Source code for the artifacts (should the open source project hosting website goes away)
Security updates related alerts (like if the previous distribution version used a version of struts that is known to have security vulnerabilities, we should get a notice of it proactively)
Secure SSL connections (I know jcenter bintray provides this rather than the non-SSL to maven central)
Licensing related meta-data (because not all maven artifacts use the license-maven-plugin)
Possible whitelisting of artifacts that are approved for use
I am not very sure myself if this can be achieved outside of a repo manager itself, and was hoping that someone might point out the similiarities between this and RHEL for the OS related modules that have similar security updates related alerts. I might be completely off, and would appreciate if someone can point out how these concerns are addressed in the java world.
Thanks in advance!
I would recommend using Bintray.
Bintray is a cloud platform that gives you full control over how you publish, store, promote, and distribute software.
As the most advanced platform for distributing software, Bintray offers:
Private repositories with fine-grained access control.
100% automation.
Stats and logs.
Download speed and reliability.
You can read more details about Bintray features.
For security alerts you should use the JFrog-Artifactory and configure it with the JFrog-Xray. The Xray product allows to add watchers and sign webhooks specific to the configuration you define. You can start your free trial.
Good luck.
I am with JFrog, the company behind bintray and artifactory and xray, see my profile for details and links.
Since upgrading to Eclipse 3.7, the Eclipse PDE plugin wants me to specify an 'API Baseline' for all my Eclipse Plugin projects.
However there seems to be no documentation which actually explains what 'API Baseline' stands for here, and what is it used for.
Could somebody please explain?
API Baseline are intended to help you maintain plugins that others can use. The API Tools help you create compatible API versions. Follow the link that Sumit Singh posted to get an explanation on how to use them.
The Problem:
You create your plugin and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You release version 2 to the public. By mistake you change the API of your plugin.
Millions of people update to the new version and have to adapt their code. Thousands of programs fail. People are sad.
The Solution:
You create your plugin, annotate its API and release version 1 to the public.
Millions of people will use your plugin and create their own code that depends on the API of your plugin.
You declare version 1 of your plugin to be the API-Baseline that your code changes are automatically compared against. Any break in the API is presented to you before you release your plugin or run your tests. You release version 2 without any API changes.
Millions of people can update your plugin in their application, because the new plugin release is binary compatible to the previous one.
You declare version 2 of your plugin ....
Summary
If you develop a plugin just for your personal use and are not interested to maintain a compatible API, you can follow the advices to disable the warnings.
When you develop plugins for a community, e. g. the eclipse plugins themselves, it is essential that you keep API incompatibilities to a minimum. Then you will follow the advice and set the baseline to 4.2 when you develop for 4.3. The API tools will help you make 4.3 an enjoyment for all current 4.2 users.
Please note, that the API Tools are for the developers of the plugins that will be used by others. They are not addressed at the users of those plugins.
From the PDE API Tools User Guide:
An API baseline defines the state you want to compare your development workspace bundles against for the purposes of binary compatibility, bundle version numbers, and #since tags. For example, if you are developing bundles for Eclipse 3.4, you will use Eclipse 3.3 as your baseline.
Ive been using eclipse and my-eclipse to code android and Java projects. I want to be able to back up my code. I know there is a way to back up code so that i can retrieve not only entire projects but changes and old versions but I cant figure out what the software is called and cant find any that are free and easy to implement. Any help would be great!
EDIT:
I don't have a server, can any of these be set up to save locally?
I think you'll want to use version control software. There are great solutions out there - CVS, SVN, Git, Perforce. Most of them integrate nicely into Eclipse.
Developing software without VCS is unthinkable to me.
Any of the plugins mentioned here will do, but I'm using the Subclipse plugin and a free repository at Assembla right now. I only switched from Mercurial because I started using Subversion at work.
If you don't have a server, you can try a free configuration at Assembla.com (http://www.assembla.com/catalog/tag/Free) for either Subversion or Git, and I've used Bitbucket.org in the past for hosting projects with Mercurial. Even the free configurations should be enough for your needs. I divided mine up between multiple projects.
Subversion (at subversion.tigris.org) is one excellent package; there are many others. There are excellent Subversion plugins for Eclipse (google "Subclipse".)
You may look to use the Subclipse package for Eclipse to use it with SVN. It permits you to keep/track/rollback changes and so.
The second option works fine if you need immediate result is to use Dropbox. It is easy to configure and easy to share the folders among multiple computer.
One more vote for using a VCS: in addition to back up you are getting control and some degree of methodology in your project.
Centralized solutions like CVS, SVN and Perforce mostly require setup and maintenance (some of them can run on flat files but these configurations are less popular). I would also consider one of the "Big Tree" distributed VCS Git, Mercurial and Bazaar.
Mercurial seem to have strong Eclipse plugin