All versions of struts1 have multiple vulnerabilities
CVE-2016-1182
CVE-2015-0899
CVE-2016-1181
CVE-2014-0114
CVE-2012-1007
I need to use a patched version but apache did not release patches for struts1 since it's well beyond its EOL, and as far as I know, only Redhat provided fixes for these vulnerabilities.
I need to use this version in my Maven project but I am not sure how to include an RPM dependency in the project? and how to even test it since I am using windows?
I looked at RPM maven plugin but all the usage scenarios on the official website seem to be centered around using it to produce an RPM from a Maven project, not the other way around, using an RPM in a Maven project.
Edit:
I also considered installing the package using yum and then use system scope and specify the location using systemPath but I am not sure if this is the best approach.
Related
I am in a bit of a jam.
I am working on upgrading our software to have Kettle 6.1. Specifically, we need the feature of S3FileOutput. Meanwhile, our application was already using the aws-sdk for other things.
So I am running into a problem: Pentaho Kettle requires version 1.0.something of aws-sdk. Our application, on the otherhand needs 1.9.6 of the aws-sdk.
To give more details, the feature of Kettle we require is in the pentaho-big-data-legacy plugin. Even if I upgrade to the latest version of Kettle, pentaho-big-data-legacy still uses the old version of the aws-sdk.
I've read a bit about plugins having special classloaders, so one option I was considering is that maybe I am not downloading the right dependency. However, when I tried downloading pentaho-big-data-plugin instead of pentaho-big-data-legacy, I got weird errors, so I stopped going down this path.
I was wondering if there is any way I could put the Kettle Libs in one folder, and my application libs in another folder, and then set some sort of a PENTAHO environment variable to pick up the libraries from the alternative folder.
Another option is if I could somehow set the pentaho classloader, but I don't know if this is possible.
What are my options for having 2 versions of the aws-sdk in my application, with regards to Kettle?
Maven can do much more than download dependencies.
The Maven Shade plugin can help with your current predicament. During a build, it can rename packages.
You would make a project that builds a "fat jar" (or "uber jar") with Pentaho Kettle and its version of the aws-sdk re-packaged as appropriate. That dependency would be handled before your project is built, so you are free to use whatever version of aws-sdk you like since there is no longer a conflict on package names.
I recently found the library Libsodium and was glad that there are also Bindings for Java. Unfortunately, the libraries don't appear to work with Windows because they were developed for other systems.
How can I use the libraries under Windows (if possible)?
Are there any alternative libraries for Java?
On that page for other bindings, you find the Java binding is called Kalium. You'll see it requires Apache Maven. So I went and got that (at the bottom it explains how to install maven, but basically you just add some environment variables).
Now on to kalium, I got it from their abstract on github. I needed mvn clean install from the directory in order to install it in Maven. After changing directory to the unzipped Kalium folder I ran the specified command (which is telling Maven to get the files and install Kalium). This will handle the rest of the set-up.
Then it's just a matter of adding it as a dependency in your Maven projects as per the Kalium readme. As for libsodium: it is a library that works with MinGW, and VisualStudio in Windows. So if you want to do C/C++ coding you can use that instead. But for the Java binding it seems you'll have deploy it using Maven.
What's the best way to download remote maven artifact from within a maven plugin while also supporting maven 2.2.x1), 3.0.x, 3.1.x and newer?
Aether seems a good candidate but it changed package namespace between 3.0.5 and 3.1 breaking compatibility.
There's pieces of information around,
some pointing towards maven-dependency-tree (as suggested in this SO post) (how?)
yet another to jcbi,
Another SO post which I think uses Aether underneath and presumably suffers from the same version incompatibility problem
Try to manually force your version of Ather based on the ResolveArtifact example
Try to port the really complex solution reflection solution from Apache Karaf
Some other util from maven-shared ?
So what's the correct, or at least working, way to go on about this?
1) Where Maven 2.2.x is a nice to have as pointed out by #khmarbaise is EoL
If you're in a plugin and want to have another plugin invoked, the best solution - by far - is to use Mojo Executor. This way, you won't rewrite the maven-dependency-plugin ...
Considering the maven version issues, well, I guess you should indeed give up on maven 2.* support.
I am developing a web-app and use maven for dependency management (duh). Some of the needed jars are already available in the server lib folder, but do not match the "maven naming scheme", ie missing the version suffix.
I would like to use them for development and deployment, but..
1. i cant point maven to them because maven seem to need a version suffix. I cant omit it in the pom.
2. If i define the dependency outside maven then maven is obviously unable to build.
3. Renaming the files inside the server distribution sounds like a kludge.
What would Brian Boitano do? I mean, there sure is an elegant solution that im not aware of, or at least a good argument for one of the three solutions above.
Thank you
PS. i am using jboss 5.1 and maven 2.2.1 atm, but its subject to change
You can provide those jars as a dependency with a system scope if you want explicitly to identify where they live. For more info have a look here
IF those are not proprietary libs you are using, I'd recommend you use official versions of those from maven repository.
If they are proprietary you can manually install jar to your local repository using maven(you can use your version, suffixes, group names, artifactid etc) and then use them in your pom.
Warning: I have just picked up Maven, so things mentioned might be wrong or not best practice.
I have a medium size open source project that I am migrating to Maven from the basic
NetBeans project management. This is not a developer team sharing the same room, this is 1-5 people over the internet sharing a SVN repo. Reading over the how-tos on dependencies, it seems that the only way to get dependencies is to get them from an online repo or install them locally.
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons including portability (anybody can pass by, check out the repo, build, and use; all that simply without manual adding to local repo's and whatnot), getting newer versions (discussed below), and manual versioning.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
So
How can I force all dependencies to come from /lib for example
On a related note, can mvn build from library's SVN repo directly? Just curious
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
FYI, this is a Java project with 3 modules, project global dependencies and module specific dependencies.
Bonus points if it can work with the bundled version of Maven that comes with NetBeans.
Not a duplicate of
Maven: add a dependency to a jar by relative path - Not wanting to install to local repository
maven compile fails because i have a non-maven jar - Don't think a System dependency is the right answer
maven look for new versions of dependencies - Still uses(?) repository, just the latest (old) version
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons (...)
I will come back on this but the solution I described in Maven: add a dependency to a jar by relative path (using a file-based repository) allows to implement such a solution.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
It looks like mvnbrowser indices are totally out of date (making it useless as repository search engine) because the maven central repository does have logback-core-0.9.24.jar (the logback project is doing what has to be done to make this happen) but only has an old pircbot-1.4.2.jar. Why? Ask the pircbot team. Anyway, you're right, the central repository might not always have ultimate versions.
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
Yeah, this happens too.
How can I force all dependencies to come from /lib for example
As previously hinted, you should re-read carefully the solution suggested in Maven: add a dependency to a jar by relative path. This solution is not about installing libraries to the local repository but is about using a file-based repository (that could thus be stored in SVN). You might have missed the point, this matches your use case. And also check Brett's answer for a variation.
On a related note, can mvn build from library's SVN repo directly? Just curious
Didn't get that one. Can you clarify?
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Maven supports version ranges and you could use a syntax allowing to use "any version greater than X". But I do NOT recommend using version ranges at all, for the sake of build reproducibility. You don't want the build to suddenly fail because of some automatic update that happened on your back. Only upgrade if you need bug fixes or new features, but do it explicitly (if it ain't broke, don't fix it).
You might also find mentions of the LATEST and RELEASE version markers. I don't recommend them neither for the same reasons as above and even less since they're removed from Maven 3.x.
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
Can't say for Ivy. But in the Maven land, if you can't host up a "corporate" repository for your project (Nexus, Archiva, Artifactory), then the file-based repository is IMO the best approach.
Setup your own Maven repository.
http://archiva.apache.org/