This post is part of a multipart series about creating a graph off all available Maven dependencies.
In the article for the Neo4j extension I described the input for the extension. This article describes the model that is used to create the required JSon. I start of with a small introduction to Vertices and edges before going into the implementation.
Vertices and Edges In mathematics, and more specifically in graph theory, a vertex (plural vertices) or node is the fundamental unit of which graphs are formed: an undirected graph consists of a set of vertices and a set of edges (unordered pairs of vertices), while a directed graph consists of a set of vertices and a set of arcs (ordered pairs of vertices).
This post is part of a multipart series about creating a graph off all available Maven dependencies.
Resolving maven dependencies is something we in general leave to our dependency management system, Maven, Ivvy, …. For the purpose to the application we are developing we required a detailed control on how the the dependencies are resolved and the JSon representation of this sub-graph. I start off with a short intro on where to find documentation on the Maven resolving mechanism and then go into the details for each of the parts that are required to do so.
This post is part of a multipart series about creating a graph off all available Maven dependencies.
This article describes the drivers behind and the implementation of the Unmanaged Neo4j Extension written for our Maven graph analysis.
When a the processing cluster is sending the sub graphs that need to be merged into a single database locking issues will occur. We opted to use a queuing mechanism to prevent. From the choices we had to implement this as a component for the Neo4J server we choose to this as a unmanaged extension.
The latest JAX-WS standards make the implementation of a webservice a breeze. lately i needed to implement a client from which a WSDL is available. That proces is simple, but the client has issues when starting, the WSDL defined in the generated code is not available. In this post i describe a (the) solution to overcome this.
By means of the maven jax-ws plugin it is simple to generate all the required code for the client implementation.
TheMaven Site plugin uses by default theapt format. Although it is a simple and straight forward format I personally prefer the Confluence markup and DocBook. Confluence I use for my personal Wiki and at various projects I use DocBook for the documentation.
Under the hood of theMaven site plugin runs the Doxia plugin. The documentation of the Site plugin is not really clear on this part. I stumbled on this some time ago.
Today I was reading DZone and cam across this article “Maven the Version Number Nazi. First of all I think the word Nazi is inappropriate but that’s besides the point made by the author.
True, the version numbering and using ranges in dependencies in Maven is not ideal but it’s defined and works as documented. The point of his post is that he wants to changes the build numbers to accommodate to his specific needs.
Ever had a project that you want to share with every body and not want them to get your source code, build and install it public repository?
For quite some time there you can do this.
Just visit the url: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide follow all the instructions and within 3 days you are up and running and publishing you own artifact in the maven public repository.
Note:
When using a linux environment with github as a scm read: http://help.