Generally, when publishing a library, do we need both sources.jar and javadoc.jar? I don't really understand the purpose of javadoc.jar.If it's about the code documentation, the IDE can show it from sources.jar itself.
Example:
Please note, this is not a duplicate of What are the differences between javadoc.jar, sources.jar and .jar?. I am looking for what javadoc.jar can do, that sources.jar can't.
Let me address the questions one by one:
Why does javadoc.jar even exist if sources.jar can be used?
This question basically addresses the developers. If the sources can't be shared (e.g. it might be proprietary) sharing the documentation is still going to help.
Why do developers provide both?
A very simple reason might be because that's the default for Maven, Gradle etc.
Another reason might be that some organizations don't allow access to source code for security reasons (or others) or can't/don't want to build the HMTL files themselves but rather just host them.
Why do I as a developer need to import javadoc.jar into my IDE if I can use sources.jar?
I'd say you shouldn't need to. As a dev I often find it very useful to have the sources available for debugging etc. so I'd prefer source.jar.
The sources JAR and the Javadoc JAR serve fundamentally different purposes.
The sources JAR will allow the IDE to present solutions for code completion, lists of required and optional arguments with their corresponding types, etc. EXAMPLE: Source for Jenkins server
The Javadoc JAR provides a Web-based encyclopedia of the API being used. So if one is curious about all the various constructor invocations, one can read about it. If one is curious about the inheritance hierarchy, they can jump through documentation pretty easily in HTML format. Notably, an IDE might provide Javadoc as documentation excerpted and linked to source solutions but does not show interrelationships or details as well. EXAMPLE: Javadoc for Jenkins server
A complete representation of the product that is developed against should include both source and javadoc for the precise explanatory reasons detailed above.
Many years ago via java.net I made an opensrc project available on Maven Central, it was difficult. I tried to make a newer version available after java.net folded and I couldn't get it working, I gave up. Many years later the project is still going strong but the maven repository has not been updated, I am always being asked to do it but I really don't know how to progress.
So please are there some complete steps to deploy a java lib to maven central repository so I can get this resolved.
As #khmarbaise indicated in his comment above, you should follow Sonatype's guide to publishing content to Maven Central.
(Part of the reason why they "cant…make it easier" is that whatever content you push has to be provably owned by you and will live, hopefully, forever in Maven Central under what will be eternal coordinates. That's a deliberately high barrier to entry. It is also what makes the facility so powerful.)
I have a system consisting of multiple web applications (war) and libraries (jar). All of them are using maven and are under my control (source code, built artifacts in Nexus,...). Let say that application A is using library L1 directly and L2 indirectly (it is used from L1). I can easily check the dependency tree top-down from the application, using maven's dependency:tree or graph:project plugins. But how can I check, who's using my library? From my example, I want to know, whether A is the only application (or library) using L1 and that L2 is used from L1 and from some other application, let say B. Is there any plugin for maven or nexus or should I try to write some script for that? What are your suggestions?
If you wish to achieve this on a repository level, Apache Archiva has a "used by" feature listed under project information
.
This is similar to what mvnrepository.com lists under its "used by" section of an artifact description.
Unfortunately, Nexus does not seem to provide an equivalent feature.
Now I suppose it would be a hassle to maintain yet another repository just for that, but then it would probably easier than what some other answers suggestions, such as writing a plugin to Nexus. I believe Archiva can be configured to proxy other repositories.
Update
In fact, there's also a plugin for Nexus to achieve the "used by" feature.
As far as I know nothing along these lines exists as an open source tool. You could write a Nexus plugin that traverses a repo and checks for usages of your component in all other components by iterating through all the pom's and analyzing them. This would be a rather heavy task to run though since it would have to look at all components and parse all the poms.
In a similar fashion you could do it on a local repository with some other tool. However it probably makes more sense to parse the contents of a repo manager rather than a local repository.
I don't think there's a Maven way to do this. That being said, there are ways of doing this or similar things. Here's a handful examples:
Open up your projects in your favorite IDE. For instance Eclipse will help you with impact analysis on a class level, which most of the time might be good enough
Use a simple "grep" on your source directory. This sounds a bit brusk (as well as stating the obvious), perhaps, but we've used this a lot
Use dependency analysis tools such as Sonargraph or Lattix
I am not aware of any public libraries for this job, so I wrote a customized app which does it for me.
I work with a distribution which involves more than 70 artifacts bundled together. Many times after modifying an artifact, I want to ensure changes are backward compatible (i.e. no compilation errors are introduced in dependent artifacts). To achieve this, it was crucial to know all dependents of modified artifact.
Hence, I wrote an app which scans through all artifacts under a directory(/subdirectories), extracts their pom.xml and searches (in dependency section of pom) for occurrence of modified artifact.
(I did this in java although shell/windows script can do this even more compactly.)
I'll be happy to share code on github, if that could be of any help.
One way that might suit your needs are to create a master-pom with all your maven projects. Then you run the following command on the master-pom:
mvn dependency:tree -DoutputType=graphml -DoutputFile=dependency.graphml
Open the generated file in yEd.
Used the instructions found here:
http://www.summa-tech.com/blog/2011/04/12/a-visual-maven-dependency-tree-view/
More interesting is probably: what would you do with this information? Inform the developers of A not to use library L1 or L2 anymore, because it has a critical bug?
In my opinion you should be able to create a blacklist of dependencies/parents/plugins on your repository manager. Once a project tries to deploy/upload itself with a blacklisted artifact, it should fail. I'm saying uploading and not downloading, because that might break a lot of projects. As far as I know, this is not yet available for any repository-manager.
One of the ways to approach this problem is outside Java itself : write an OS-level monitoring script that tracks each case of fopen() on the jar file under question! Assuming this is in a corporate environemnt, you might have to wait for a few weeks (!) to allow all using processes to access the library at least once!
On Windows, you might use Sysinternals Process Monitor to do this:
http://technet.microsoft.com/en-us/sysinternals/bb896645
On Unix variants, you would use DTrace or strace.
IMHO and also from my experience, looking for a technical solution for such a problem is often an overkill. If the reason why you want to know who is using your artifact(library) is because you want to ensure backward compatibility when you change an artifact or something similar, I think it is best done by communicating your changes using traditional channels and also encourage other teams who might be using your library to talk about it (project blogs, wiki, email, a well known location where documentations are put, Jour fixe etc.).
In theory, you could write a script that crawls though each project in your repository and then parses the maven build.xml (assuming they all use maven) and see whether they have defined a dependency to your artifact. If all the projects in your organization follows the standard maven structure, it should be easy to write one such script (though if any of those projects have a dependency to your artifact via a transitive dependency, things can get a bit more tricky).
I was wondering about this. I'm planning to employ jackrabbit in a ECM project and it seems that OCM is dying or what, it is a different fork that the rest of the project. In maven repos there are old jackrabbit-ocm-nodemanagement jackrabbit-ocm versions, otherwise the project itself is downloadable via a referenced zip archive in reference documentation.
org.springmodules.jcr didn't make it to the official spring source base. It got abandoned. Even though it was a great glue for jackrabbit OCM and the project looks great. I absolutely don't understand why they decided to leave such an important specification !?!?!?
It currently resides here as some sort of conservation.
Also there is a jcr spring extension that the same thing I suppose. It has its Jira section, but everything seems abandoned to me. If I got into problems with some nasty bug, any support wouldn't get to me.
Please if you have brighter information than I do, let me know.
We have multiple maven projects depending on on our own common libraries.
When we upgrade a library it would be useful to quickly find out which projects have a dependency on the library (and might need to use the new version)
Obviously I can manually look in all the pom files or write a script to do it but this is less than ideal.
Are there any tools that provide this functionality. e.g. a hudson plugin, Nexus, artifactory etc?
EDIT:
Some clarifications:
I don't want to upgrade all projects at once. The regression testing and release effort makes this impractical and often unnecessary (even with automated testing and releasing). I just want a report showing me what may projects may need to have the library upgraded...
Many answers focus around the project itself flagging what version is used. Ideally the solution would work so that for a given library I can ask what uses this. This looks like what the Nexus issue below is talking about.
Hudson does something similar with automated downstream maven builds. I may look into extending this with a hudson plugin.
I know that albeit being a good tool for managing poms and jars, Artifactory has no such feature you're asking :(
You might want to check this StackOverflow question: Look for new versions of dependencies
Alternatively you might want to check Versions Maven Plugin. Among other things, it allows you to scan trough project's dependencies and produce a report of those dependencies which have newer versions available.
A quite usual practice is to declare all the versions in dependencyManagement of the parent module and reference dependencies without versions everywhere else. In this case you'll only need to update only one POM.
I solved this issue by using dependency version ranges to fetch the newest versions automatically.
<dependency>
<groupId>foo.xyzzy</groupId>
<artifactId>bar</artifactId>
<version>[1.0.0,2.0.0)</version>
</dependency>
It might make sense to use a version range such as [1.0,) to include the newest version after 1.0.
The trick to make this work is to have dev and prod profiles that include and exclude the snapshot repos for your commons and to use hudson to automatically build projects when a dependency is re-built.
Not exactly what you're asking for but the Dependency Convergence report might be helpful. Here are some examples.
Update: I'm aware that I'm not exactly answering the question with my suggestion but doing it the other way (finding all projects that reference a given artifact) would require gathering all POMs of all projects and I'm not aware of a solution currently offering such a referenced by feature (a corporate repository would be the perfect candidate to implement this though).
My search is over: http://www.sonarsource.org/sonar-2-1-in-screenshots/
Sonar now provides this.