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.
Related
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
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.
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?)
We are planning to use IBM Web Experience Factory for our future enhancements. From the project management point of view we are thinking of using Maven. But due to no online help available for using both the things together we are not able to move ahead.
Please let me know if anyone can provide inputs.
We did a web application that needed to be deployed on IBM Websphere and we learned a couple of things. Maybe they can help you:
If your application depends on certain IBM API's (like Virtual Member Manager), you should declare that dependency as provided and let the container manage it for you. For compilation purposes, you should add the required JARS to your Maven Repository (in our case, Archiva).
For deployment you should relay on Jython scripts to do the Job. The execution of the scripts can be done with was6-maven-plugin (they say that they can handle the EAR deployment, but it can only be donde through Jython and wsadmin. Maybe you're more lucky than us)
There is no direct maven integration for the IBM Web Experience factory.
Your best shot is using maven and ant. There are some guides on build automation in the Web Experience Factory Wiki.
You have to do some preparations and afterwards you can generate the war.
You can integrate those tasks with Maven AntRun.
We tried generating the war files with ant, however even though everthing compiled and the war looked good, we encountered problems within the application that stopped us continuing with this approach. It wasn't reliable enough.
For the point Maven i don't understand how you get to say "no online help available" ...despite the official books http://sonatype.com/Support/Books you can read many things online on http://maven.apache.org/ furthermore there some other books which can be bought via Amazon or take a look at http://maven.apache.org/articles.html for an overview. Or for a starting point you can read at http://maven.apache.org/users/index.html. Last but not least you should take a look at the mailing lists for Maven. If you are searching for particular help about IBM WebSphere Portlet factory in relationship with Maven you should be more specific about the problem.