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.
Related
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.
We have a web application that is implemented in Java. It uses Maven to install various dependencies such as JavaMail, Gson, and so on.
Unfortunately, deploying and maintaining the project is a nuisance. We need to be aware that any of those dependencies might issue a security update, which means checking regularly for new versions. To make matters worse, we can't see any way that Maven can distinguish security fixes from other new releases. This means that we end up doing needless updates, which is a waste of time and could break something.
The server itself runs Ubuntu, and the situation there is far better. Apt installs urgent updates, but everything else waits until the next Ubuntu release. That's ideal because it gives us a stable but secure platform that we can build on.
Is there any way of making Maven more like Apt, so we can install security fixes but nothing else? If not, I'd be interested to know what strategies other people use for updating deployed web applications.
(We know about the maven-dependency-plugin. This plugin helps, because it can automatically find and update any dependencies which have newer versions. Unfortunately it can't distinguish security updates from normal feature releases, so we end up updating when we don't strictly need to.)
I did come up with a partial solution to this problem, but it doesn't use Maven directly. I implemented a script which scans the NVD database for new security exposures relating to products we are using. Every morning I get any new ones emailed to me, and I can decide whether they justify an update to our web application.
The downside of this approach is that smaller projects don't always issue CVE numbers for their vulnerabilities. We have to restrict ourselves to products that have a significant following, are backed by a large vendor, or have previously demonstrated a willingness to take part in the CVE process.
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?)
I've read the HornetQ FAQ, but I can't find anything related.
I'm using HornetQ 2.2.5, it contains a bug (yeah, just one ;). According to this post https://community.jboss.org/message/624958?tstart=2 it's been fixed from 2.2.7.Final onward.
On the main download page, http://www.jboss.org/hornetq/downloads the latest version available is 2.2.5.Final. I'm not scared of compiling a newer version myself, but can I consider it stable?
I'd say yes since it's a minor release update, but I'd like some other opinions. Thanks.
This answer uses the 2.3.X branch as an example. Let's skip looking at their Downloads page, and go straight to the artifacts:
http://mvnrepository.com/artifact/org.hornetq/hornetq-pom
You can see that 2.3.X went through Alpha, Beta and CR stages, to finally reach 2.3.0.Final, the Community release. This is what most people in the open source world would end up using, and what you will find available for easy download.
It's also the last version the non-paying customers are intended to use (in the typical JBoss release cycle - see e.g. the JBoss AS/EAP FAQ). Now, from a commerical perspective, 2.3.0.Final would be considered Alpha again. An analogy from the JBoss AS/EAP FAQ which probably applies here too: "The first EAP stage Alpha is of equivalent, or better, quality to a community Final release [...] we don't recommend using it in production" (probably an overly harsh judgement, but anyway.)
After 2.3.0.Final, they fix more bugs (2.3.1.Final, 2.3.2.Final, ...) until they get to a commercial production release (which they bundle into their other commercial products). So, you should be using the latest .Final that you can for production (for the 2.3.X branch, it was 2.3.13.Final).
Do you have to pay for 2.3.13.Final? From what I can tell, you don't. (HornetQ is also not available commercially AFAICT, except when bundled into other products.)
How do you get 2.3.13.Final? You probably won't find a nicely packaged RPM or even zip file. Instead, you will need to get the JARs from public Maven repos (or build from source).
Do you need a postgrad degree in JBoss Versioning and Product Naming to use their products? Perhaps :) - I don't have one, so apologies in advance if I have failed to comprehend the enormous complexity of the beast. But I do wish the HornetQ developers would make it easy to get a stable release of their product, and know that this is what one is using. It's a good product (perhaps the most fully featured of the lot), with an excellent manual, but a snap judgement of the download page and FAQ may make some people look at competing projects instead.
Well, after some more research, I can say yes, it is stable.
In particular, JBoss EAP 5.1.2 package includes HornetQ version 2.2.10.GA.
I wonder why there is no direct link on the HornetQ download page.
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.