On the maven centrral, I can see several other Repositories available for some of the libraries. For example - Apache Common BeanUtils is available in Central, Redhat GA, JBoss 3rd-party etc. The library name changes as well. For example, Maven CCentral has versions like 1.9.4, however Redhat GA has versions like - 1.9.3.redhat-1.
Click on this URI to see the details.
https://mvnrepository.com/artifact/commons-beanutils/commons-beanutils
My question is - What is the difference between Repo marked as Central and "Redhat GA"?
Attaching an image of :Maven GA; repo as well here.
Re:
My question is - What is the difference between Repo marked as Central and "Redhat GA"?
From here: https://access.redhat.com/maven-repository
"Redhat GA" is the general availability JBoss Enterprise Maven Repository.
And the page also mentions:
Artifacts in the repository do not receive automated security patches as Maven requires that artifacts be immutable. As a result, artifacts that are missing patches for known security flaws will remain in the repository to avoid breaking builds that depend on them. Patched artifacts have their version number incremented.
If you checkout the README at the repository: https://maven.repository.redhat.com/ga/README.md
This archive contains Maven repository artifacts for JBoss WFK 2. This is meant
to be used as additional Maven repository in development environment with
JBoss EAP 6 Maven repository.
So it seems Redhat GA versions are patched versions of Maven Central artifacts, specifically to support JBoss WFK.
My guess is that the patches correct security flaws in the base Maven Central artifact.
Re:
For example, Maven CCentral has versions like 1.9.4, however Redhat GA has versions like - 1.9.3.redhat-1.
For this example, my guess is that 1.9.3.redhat-1 is a security patched version of 1.9.3 from Maven Central.
Re: (comment above)
how safe is to use version of a library from other Repos (for example-Redhat in this case) than Central? Or what are the scenarios when an Enterprise application should use a library from other Repos than Maven Central?
If you need a security-hardened version of a specific Maven Central version, but you can't upgrade to a later version from Maven Central (for any reason: risk, incompatibilities, one does not exist, etc) - the Red Hat version might be a solution.
As to whether it's safe, it's up to whether you trust RedHat vs Maven vs any other organization providing open source.
Related
The situation:
We have several apps, which use a library developed by ourselves. All app projects as well as the library are under constant development.
Our goal is to have a local maven repository, which allows us to always build the apps with the latest library version, like all those dependencies listet in the Android-Studio dependency chooser here
We don´t want to use the central maven repository, as it makes our code public.
Is there any chance to have a lokal maven repository which is going to be fully compatible with Android Studio and Gradle or is there any other (easy) alternative?
Yes, you can use a local Maven repository manager, which will let you maintain a set of private artifacts for your organization. There's some documentation here: http://maven.apache.org/repository-management.html but the brief explanation is that you can set up a repository that's similar to Maven Central except it's private. There are various repository manager software packages, including Apache Archiva, Artifactory, and Sonatype Nexus.
JBox2d is at version 2.3.1-SNAPSHOT ..
https://github.com/jbox2d/jbox2d/blob/master/jbox2d-library/pom.xml
However the latest version of the library at Maven repository is 2.2.1.1 ..
http://mvnrepository.com/artifact/org.jbox2d/jbox2d-library
Is there a way that I can upload this newer version of JBox2d to the central repo for everyone's use?
In short, no. Without the current maintainer's permission you can't upload a new artifact with the same groupId/artifactId. To quote from the Guide to uploading artifacts to the Central Repository FAQ:
I have a patched version of the foo project developed at foo.com, what groupId should I use?
When you patch / modify a third party project, that patched version becomes your project and therefore should be distributed under a groupId you control as any project you would have developed, never under com.foo. See above considerations about groupId.
Either pick a new groupId, for what is effectively your fork of the project, or collaborate with the current maintainers to get the newer version into Central with their permission.
I'm trying to include hadoop-core from a maven repository, and there are two repositories that contain it, maven central and the cloudera maven repository. Is there a reason to choose one over the other? They use different versioning too - in maven central, hadoop core is at 1.2.1 and in cloudera there are versions like hadoop-core-0.20.2-cdh3u6.
I can't seem to figure out what the differences are here. Any guidance?
In most cases maven central have released versions only. The case you mentioned seems like that cloudera is also having intermediate/classified versions as well.
Whenever possible it is good to use maven centeral because otherwise your build will be looking in multiple repos for artifacts.
I have various questions regarding Maven 3 and Nexus repository. At our nexus repository I would like to resolve only timestamp dependencies. That is to say I would like to prevent downloading timestapped dependencies to my local repository. And also at my nexus configuration having only latest snapshot jar for a version is totally fine.
My question is regarding timestamped dependencies at nexus and local repository.
Is having only latest Snapshot at repository a good practice? Why or why not?
I have done at my plugin management section of the parent pom of the deploy plugin <uniqueVersion>false</uniqueVersion> but at hudson I still continue to see timestamps at jar like this bundle-service-client-1.0-20110209.145744-25
I have came across a comment at another question,
The timestamped artifacts should never be see inside your local
(~/.m2/repository) repository. If they are, something is wrong.
Why?
Quoting from the relevant section in Maven 3.x Compatibility Notes
The setting false for a distribution
repository has no effect in version 3.x, snapshot artifacts will
always be deployed using a timestamped version.
Also, look at the comments in this nexus jira bug on a nice explanation to your other questions.
I have a following problem. We have a central maven repository hosted on our company server. Our team is working on a project. Everyone here uses that repository to get the required artifacts. If something is missing at the moment and is required for the task that the developer is currently dealing with, he installs this artifact manually to the central repository, so that his commits don't break the automated builds.
Now, each developer also has Glassfish v2 installed on his machine. That is for testing and debugging purposes. Before committing the changes, developer makes the .ear for the project with Maven help. However, after the developer deploys the ear to it's local glassfish, frequent errors arise, because the set of glassfish libraries may not contain all the latest dependencies of the central company repository.
Right now in case of the error the developer simply reads the log and looks what exactly is missing. After that he manually copies the required jar inside his local $GLASSFISH_HOME$/lib dir. But that seems a little bit frustrating. How can this be done automatically?
Right now we are trying to implement the following solution. The developer has to synchronize his local maven repository gathering all the artifacts from the central one that are required by the project. This local repository has to be placed on the java classpath, so that glassfish would also see it. Is that a correct approach? Maybe there is a way to install directly all the required artifacts from the central repository inside $GLASSFISH_HOME$/dir and this can be done automatically during deploy?
About having to install dependencies. If the developers need to install dependencies missing from public maven repositories, take into account that usually maven proxies have the ability to cache public repos. For instance, archiva has a proxying cache. If the dependencies are your own project deliverables you should consider releasing and deploying with maven to your company repo.
About latest versions. You need to specify maven what version of dependencies should use. I would prefer editing my poms manually, anyway there's a variety of ways to achieve that.
The libraries should be part of the project, I think. If not standard libraries of glassfish, they should be included, for instance, in your war file as part of your project. If not standard but not part of your project (not the regular approach) consider managing this glassfish as a project on its own (own git/svn repo, own pom, own versions, own everything).
Good luck.