I have my JDK documentation path set so that I can hit Cntrl J (osx) to get 'quick documentation lookup' for core java libraries. If I try with non-core libraries like Spring or Hibernate, I only get the method signature. How do I go about getting the documentation for these libraries too?
Attach documentation directory or specify external documentation URL, or attach sources.
If you're using Maven, you can use the Maven goal :
mvn dependency:resolve -Dclassifier=javadoc .
This goal resolves the project dependencies from the repository. The classifier specify to look for javadocs. All documentation will be downloaded inside your maven local repository, generally ~/.m2 .
After that, IntelliJ is able to find all javadoc for Spring, Hibernate, if not, check your settings inside Project Structure.
Related
If I understand it properly, SpringSource has a public OBR which contains OSGi bundles for many third party jars. I would like to use it in Eclipse, but I can't get Eclipse to connect to it.
I have tried:
http://ebr.springsource.com
It hangs there for ages, and returns as error:
Error reading update site http://ebr.springsource.com.
The XML stream is not a valid default "site.xml" file.
The root tag is not site.
And I have tried:
http://ebr.springsource.com/repository
Which returns quickly as error:
No repository found at http://ebr.springsource.com/repository.
So, what URL am I meant to use?
[EDIT] Made some research after getting my first answer. I found this site which claims to have a list of public OBR repositories:
OSGi Bundle Repository:
http://www.osgi.org/obr/browse?cmd=repository&_xml=1
Spring Enterprise Bundle Repository:
http://sigil.codecauldron.org/spring-external.obr
http://sigil.codecauldron.org/spring-release.obr
But none of them work with Eclipse either. I'm just more confused now.
What I (think I) understand is:
1) SpringSource EBR is a Repository of OSGi Bundles, without being a "OSGi Bundle Repository". This makes no sense to me. What's the point?
2) An "OSGi Bundle Repository" is just a XML file that defines the configuration of a Repository of OSGi Bundles.
So, If I give http://sigil.codecauldron.org/spring-external.obr to Eclipse, instead of http://ebr.springsource.com, I would expect Eclipse to use the content of that file to access http://ebr.springsource.com, but it doesn't work either.
So which one of the possible reason is it:
1) http://sigil.codecauldron.org/spring-external.obr is outdated or wrong
2) http://sigil.codecauldron.org/spring-external.obr is not compatible with Eclipse (apparently, it works with Apache Felix)
3) An "Eclipse Update Site" is NOT an OBR (and neither is it a Maven Repository), although it should also contain OSGi bundles. If that is the case, then it wouldn't make much sense either, since Eclipse is OSGi-based.
SpringSource EBR is not an Eclipse Update Site, so it cannot be used this way. It is also not an OBR, at least currently. But Eclipse PDE doesn't use OBR anyway (though Bndtools does).
You can use it as a Maven repository, I think.
I've been fighting with this for a while and reading a lot of docs pages and other questions but still can't get it to work.
In my ORMLite project, I have a ormlite-core project which has core functionality and then a -jdbc and -android projects (with more planned). Each of these sub-projects include the core functionality but add per-architecture implementations. I want to release a single set of jars for both the -jdbc and -android versions -- i.e. I want to copy the -core javadocs and sources into the resulting jars.
For the javadocs, it was cake with the includeDependencySources config entry set to true. However, I've been fighting for a while now on how to get the source jars released by the -android package to include the -core sources. I've tried the maven-dependency-plugin to copy and unpack the dependency sources to target/sources but I see no easy way to get them to be included in the source jar -- with the appropriate paths. I've gone over the maven-source-plugin and maven-assembly-plugin docs but I'm still in the dark.
If someone has figured out the magic maven fu to get this done, can they please share the appropriate working pom.xml examples? Thanks much.
I've reviewed the following similar questions among others. I've also looked at the Sonatype Maven manual and read a bunch web pages posing similar questions.
Delivering a single jar with a Maven project
Maven - 'all' or 'parent' project for aggregation?
While not an answer to the question, a possible reason why a parameter like <includeDependencySources> is not present for maven source plugin is because, while javadocs can be generated from a jar containing classes, the sources cannot be. The plugin cannot assume that the sources of the dependencies are available to it since they do not get installed by default.
I guess the best answer to this question at this time is "you can't get there from here". This requires extensions to the maven-source-plugin.
I ended up determining that combining these sub-projects into the same jar was not a good idea and now I release 3 separate jars.
How to convert a Ant project to Maven project? A sample project that would link (a Wicket project)
Thanks
The nice part of using maven is that most standard stuff works automatically once you do things the maven way. For a simple webapp:
Create a pom with groupId, artifactId and version (packaging: war)
Add the required dependencies to the pom
move the
java sources to src/main/java,
resources to src/main/resources,
webapp content to src/main/webapp,
test content to src/test/java and src/test/resources
set the compiler compliance version using the maven compiler plugin
That should get you up 'n' running.
http://www.sonatype.com/people/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/
I don't know what your ant script looks like, but assuming its a basic script for building, you will need to create a pom.xml file for your project, add your dependencies, and then build it via maven.
For anyone who lands here in future, there is an easier way to find dependencies for maven using the file hashes. So, you won't have to guess artifact versions.
As per the below article, the idea is to generate a SHA1 checksum of the dependency that you want to find the information, then do a reverse search in Nexus repository manager using that hash. For the checksum generation, you can use Microsoft's FCIV (free) utility.
https://devreads.xyz/ant-to-maven-conversion-the-painless-method/
I'm new to Maven and have skimmed over the documentation as I am following the Hibernate tutorial at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#tutorial-firstapp-mvn.
I have installed Maven and successfully setup a web-app but this does not contain all of the standard directories mentioned in the tutorial. Am I going mad?
When building my Maven project I am using the maven-archetype-webapp. This gives me the arh-webapp\src\main\resources and arh-webapp\src\main\webapp directories but I'm missing quite a few directories mentioned on the link http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html.
Surely I don't have to manually add these? If not then the Hibernate documentation does not mention what archetype to use in order to achieve the directory structure used in their tutorial. Please can someone enlighten me.
What archetype do I need to use in order to have the above directory plus the src/main/java directory? If there is no such archetype then can easily append these using Maven? and how?
Surely you'll have to manually add these.
Just create those directories that according to the Maven convention are missing. Remember, a Maven Archetype is just a starting point to save you time configuring your workspace. After encountering many problems in some Archetypes myself I've been accustomed to just use a basic-web-app-archetype and then customize it myself, as a beginner with Maven you'll be better off doing that, and will learn a lot.
Regards.
Not all the directories mentioned are required for your standard web application. In fact, the reason behind the presence of the src/main/java, src/main/resources and the src/main/webapp directories is due to the archetype that you've used.
IMHO, the book titled "Better Builds with Maven" will serve you better; the Sonatype books on Maven might also help. The complete Maven documentation is also available as a PDF file, for future reference.
But just in case, you need some clarity on the terms used, here's some:
Archetype: A pattern for projects. Simple web applications (with no dependencies on other frameworks/libraries) have their own archetypes, so do applications using Spring, Hibernate, Seam, etc. Some archetypes will result in creation of different directories, as they are coded that way. You might be able to change the directory structures in most cases, although I cannot vouch for every archetype. For instance, it is quite possible to place your sources in 'src' instead of 'src/main/java', although this requires additional configuration in the POM.
Lifecycles, Phases and Goals: A Maven build lifecycle is a series of phases, with each phase executing a set of goals. Maven can be commanded to execute a build phase, which results in execution of all phases until and including the specified phase.
Maven plugins: Maven plugins contain one or more goals. Goals need not be bound to phases, but usually you would bind them to particular phases. Plugins are the basis for everything operational in Maven; you're using plugins even though you are just compiling the application (the Maven compiler plugin is a core plugin that is present in the Maven distribution).
I hope the above helps, but I would suggest that the reference books be followed.
In a single-module project, I don't see how to get a 'classified' artifact from the project itself into the descriptor and thus the assembly. Do I list it as a dependency?
Did you try the Build Helper Maven Plugin (I'm thinking to build-helper:attach-artifact)? See Attach additional artifacts to your project in the plugin Usage page.
If it doesn't work, then indeed declare your 'classified' artifact as dependency using one of the advanced identity pattern.