I am using AEM 6.1 with Maven to manage dependencies. I can see the bundle com.adobe.granite.poi version 2.0.0 being shipped along with the AEM instance. But I cant seem to find a maven dependency for the library in both Adobe public repository as well as Maven central repository.
I have checked the uber-jar dependency uber-jar-6.1.0-obfuscated-apis and could not locate it there as well.
I can find version 1.0.2 and 1.1.0 of com.adobe.granite.poi in the Adobe public nexus. I would prefer to avoid using a older version if possible. How would you manage this problem.
you can find granite poi 2.0.0 here - http://nexus.citytech.ctmsp.com/content/groups/public/com/adobe/granite/com.adobe.granite.poi/2.0.0/
BTW, I have had this experience with a couple of apis whose newer version are not available on adobe's maven repository, but they are shipped with AEM. what my understanding is that if its not available on adobe-public, its not (or not any longer) a public api and you are not supposed to use it. you may want to find an alternative.
Related
I need to do Amazon PA API Migration on March.
I'm trying to find a Maven public repository where is published the 'PA API 5.0 sdk'.
This is the official documentation : link
It says :
Download paapi5-java-sdk-and-samples archive and unzip it.
Open the project in any editor of your preference.
Add all jars present in dependencies folder to the build path.
It's not professional and not maintainable doing like this..
Also many of these jars are old versions (2016 like).
I've tried to contact AWS PA API support but I've got generic response (read documentation etc.)
Suggestions? Do you know Java unofficial libraries? Thanks
Same here. There is only an old maven sdk available. I cannot even import correctly the jar on intellij idea. The IDE is able to find alle the classes needed by the examples, but on building it says: "error: package com.amazon.paapi5.v1 does not exist". I added the jar with this procedure
I have the same problem and totally agree that it's not professional and not maintainable at all.
My current workaround is just to integrate manually the paapi5-java-sdk-1.0.0.jar and then figure out what other dependencies were missing, and which one I don't need (for example junit-4.12.jar does not make not much sense for me when I just want to use it in production).
You might already having some dependencies in place that you don't need to add. For example you might already have Jackson. So don't add this to your pom.
All other dependencies that you need, instead of using the jar files, just add the offical repo of them to your pom as usual with the same version as you find in the zip file. That way you have the least manual dependencies as currently possible and are sure all additional dependencies work fine with the Amazon SDK.
In my case I just had to add okhttp, okio, gson, gson-fire and threetenbp from the offical repo.
You can use mvn install to install downloaded jar into your local repository. See here
https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
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.
I have installed a fresh version of IntellIJ Idea (2018.1.2) and JDK 10.0.1. Maven 3.0 seems to come bundled with IntellIJ, but I have additionally downloaded and successfully installed it. In my pom file, there is a javafx dependency, and I am getting this:
Updating indices and reimporting doesn't help. What simple thing that will make it work am I too dumb to understand?
This artifact is not on maven central. (see https://search.maven.org/#search%7Cga%7C1%7Ccom.oracle%20javafx)
Maybe you have to configure a repository in your maven configuration where you can find your missing artifacts.
I think you are trying to use JavaFX as a Maven dependency. However, JavaFX is not available in a public Maven repository. JavaFX does not need to be hosted in a Maven repository as it is included as part of the underlying Java runtime.
I am adding IC integration with IBM SBT SDK (Java) into an existing project which still uses xerces 2.4.0 (as of March 2009).
Using IBM SBT SDK 1.0.x did not cause any problems here, but the XML serialization implementation of 1.1.0 completely relies on org.w3c.xml.ls.DOMImplementationLS and such stuff which was introduced after moving xerces to "xercesImpl" about 2004.
However the project contains much code working with XML based on xerces and xml-apis, and it looks dangerous to move too fast to "more current" versions of these libraries. Thus I want to move "no further than absolutely required".
Thanks to maven no one can directly see which version of any artifact is loaded if it is not directly referenced in the pom.xml. Thus my question:
Which version of xercesImpl is "really" required by IBM SBT SDK 1.1.0? 2.4.0 is not sufficient, as some methods used in the SBT SDK are not yet implemented there...
xerces version in the dependency would be 2.9.0; looking at the DOMUtil.java#loadDriver() class however there are workarounds to avoid the SBTK to use xerces altogether:
if your container allows to control the classpath tree, shadowing the xerces library from the toolkit will have it default to some other driver. In alternative you can provide your own XercesDriver class compatible with old xerces versions and leverage the classloader to have it loaded in place of ours.
if you are in a osgi container you can also make sure the host application manifest declares a dependency to a version <=2.4.0 and load both xerces versions letting the container fix the dependencies for you
anyway, to answer the question, using:
mvn dependency:list
I get version 2.9.0 for xerces:
The following files have been resolved:
com.ibm.sbt:com.ibm.commons:eclipse-plugin:9.0.0:provided
p2.eclipse-plugin:javax.servlet:jar:3.0.0.v201112011016:system
p2.eclipse-plugin:javax.xml:jar:1.3.4.v201005080400:system
p2.eclipse-plugin:org.apache.xalan:jar:2.7.1.v201005080400:system
p2.eclipse-plugin:org.apache.xerces:jar:2.9.0.v201101211617:system
p2.eclipse-plugin:org.apache.xml.resolver:jar:1.2.0.v201005080400:system
p2.eclipse-plugin:org.apache.xml.serializer:jar:2.7.1.v201005080400:system
p2.eclipse-plugin:org.eclipse.core.contenttype:jar:3.4.200.v20120523-2004:system
p2.eclipse-plugin:org.eclipse.core.jobs:jar:3.5.300.v20120912-155018:system
p2.eclipse-plugin:org.eclipse.core.runtime:jar:3.8.0.v20120912-155025:system
p2.eclipse-plugin:org.eclipse.equinox.app:jar:1.3.100.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.equinox.common:jar:3.6.100.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.equinox.preferences:jar:3.5.1.v20121031-182809:system
p2.eclipse-plugin:org.eclipse.equinox.registry:jar:3.5.200.v20120522-1841:system
p2.eclipse-plugin:org.eclipse.osgi:jar:3.8.2.v20130124-134944:system
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/