Is there any doc to setup the code for "geoserver-2.X-mongodb-plugin"?
Found the source code here but not in project structure,
https://dev.spidasoftware.com/artifactory/list/boundlessgeo/org/geotools/gt-mongodb/21.2/
.
Where we can find the git location for the same?
The mongodb store is part of the GeoTools project, here:
https://github.com/geotools/geotools/tree/master/modules/plugin/mongodb
Generally speaking, anything that's not protocol specific, like feature and coverage stores, cascading support, rendering, referencing, style languages and so on, they are all found in GeoTools, while GeoServer has the protocols implementations and automation machinery (e.g., WMS, WFS, importer, output formats and the like).
The GeoServer docs can be found at https://docs.geoserver.org/latest/en/user/extensions/mongodb/index.html
Related
We've been looking into solutions to keep our API documentation accurate and up-to-date. This has led me down this rabbit hole of various solutions using standards such as OpenAPI and a whole universe of open source tools for integrating API documentation into your build pipeline, setting up mock servers, failing the build when APIs change or no longer match the documentation, etc. Right now, I'm fairly overwhelmed so to avoid having this question closed as "Too Broad", I'd like to narrow things down to a key piece of the puzzle that I'm a bit lost on. In simple terms, how do you connect the auto-generated Swagger JSON to the fully documented and detailed version of the spec (most likely as a bunch of YAML files and Markdown files)?
Right now, we have the ability to generate Swagger JSON based on our compiled code, but it's sparse and doesn't contain any information that can't be obtained through the code itself. Obviously I'd want to fill in details such as longer descriptions of each API, sample code, etc. From what I can tell, it's standard practice to generate your OpenAPI specs using a tool that can import directly from Swagger, then you use an editor (such as Swagger Editor) to fill in all the details. This gets bundled up as a bunch of YAML files, MD files, etc which get checked into Github, and then there's various tools that could build that into some portal for your users to go to (Redoc does this sort of thing).
However, how do changes to your original "auto-generated JSON" get merged into the "final product"? My guess would be there's some build step that runs some sort of diff tool that compares the autogenerated JSON from the current build to the "published" OpenAPI spec and then somehow alerts the team if there's new APIs that have to be documented or existing APIs that have changed and need their documentation update. Is this kinda on track or is there a big part I'm missing. Thanks!
Recently I saw that mgo was no longer going to be maintained and I have a recent project with mgo. My question is if there is a problem with that? There are no risks?
Basically you may continue to use it, but since it's not maintained anymore, that means bugs discovered in it will not be fixed, and new features of MongoDB servers will not get added to it.
If you read the README of the github project (https://github.com/go-mgo/mgo), it lists your options.
The first suggests to use the community supported fork: github.com/globalsign/mgo. This is maintained, support for new features are being added, and it has the same API as the original package.
Since globalsign/mgo has identical API, there is no reason not to switch to it. It will most likely only take to change your imports.
Also note that there is an official MongoDB Go driver under development, it was announced here: Considering the Community Effects of Introducing an Official MongoDB Go Driver. It's project and source code is available here: github.com/mongodb/mongo-go-driver. It's currently in alpha phase, so it's nowhere near production ready (and they don't even have an estimated date when it will be ready). If you need a driver now, globalsign/mgo is the best option at the moment.
Do note that both the official driver and globalsign/mgo are getting support for newest features and additions of the MongoDB server, as an example, both support change streams (it wasn't in the original mgo driver). For details, see: Watch for MongoDB Change Streams
There will be problems if:
You want to get some new features in mongodb and current mgo library doesn't support
There is a bugs/security issue in mgo library.
That's one of the reason why i'm not using mgo.
There will be an Official MongoDB Go Driver.
GitHub: mongo-go-driver
Forum: mongodb-go-driver
Considering the Community Effects of Introducing an Official MongoDB Go Driver
I need to write and build easy maintainable, goodlooking, esay to change documentation in pdf and html 5 format. The source format must be easy to edit. This maven plugin has to support my company organziation theam(fonts, colors, pictures etc.), TOC generation, separation of chapters in different files, integration of images files, easy way to put code snipets in the documentation. I have Maven build and I was wondering what is the current best descision to do that?
I was investigate two options:
Doxia - using md(markdown) as input format. There is WSWG md free
editor, support a lot of the aforemention stuffs, etc. Need external repo for its artifacts.
Asciidoctor - use asdcii doc as input format. Support templating using fragments etc.
What are the advantages and disadvantaes of using this plugins?
Are there any other good solutions?
From my attempts to build the documentation first with Doxia and then with AsciiDoc I realised that Asciidoc is the better. It allows
Easy styling using yaml files. Default styling is also very good.
Asciidoc as a mark-up language is very good documented: Uder Guide AsciiDoc
Has good online editors and the language is more powerful than markdown for example, and easier to write in comparison to the xml format.
Good examples when using with Maven and ascii doc and easy to understand configurations.
Ruby has a few good document generators like Yard, rDoc, even Glyph. The thing is that Sphinx does websites, PDF's, epub, LaTex...etc. It does all these things in restructuredtext.
Is there an alternative to this in the Ruby world? Maybe a combination of programs? If I could use Markdown as well that would be even better.
Since version 1.0, Sphinx has had a concept of "domains" which are ways of marking up code entities (like method calls, objects, functions, whatever) from lannguages other than Python and/or C.
There is a ruby domain, so you could just use Sphinx itself. The only thing you would be missing (I think) is Sphinx's ability to create documentation from source automatically using the autodoc extension, which works specifically on Python code.
If you want to use Markdown, you might check out JDoc, which is a very simple, Ruby-based documentation framework that lets you use widely-supported markup and put it under source control. It lets you edit the documentation in your text editor of choice, and it supports:
Markdown or Textile
syntax highlighting
easy internal links
a hierarchical documentation structure (useful for large projects)
customizable styling and structure (but it looks nice out of the box, too)
It generates static HTML, so the resulting documentation is easy to host and doesn't have much of an impact on your server load.
To see it in action, check out wpmvc.org.
Another couple of options would be to use Middleman which is a static site generator that accepts either Kramdown or Markdown as input.
There are also frameworks that are designed specifically for technical documentation that use Middleman (both of which are on GitHub) including lord/slate and pnerger/dpslate (the later is a fork of the former and provides some enhancements that were not appropriate for pulling). The Slate format provides a format for documentation that includes many of the features of Sphinx with some additional enhancements. It features a three-pane view of a document which includes an automatically generated Table of Contents, a Main center body, and then sample code panel to the right. Like Sphinx the sample code has syntax highlighting.
I am looking for documentation on the XML parser in ItextSharp, I heard there was a dtd years ago but this seems to be defunt. Does anyone know where I can find out all the valid tags and references?
I am using ItextSharp with Spark
Thanks
When in doubt, use the source. Poking around in my copy of the current iText source, I see that the only SimpleXMLDocHandler available is HTMLWorker.
And if you look at the source for HtmlTags.cs, you'll see all the tag and attribute constants HTMLWorker uses.
It's not exactly comprehensive, but is going to be getting some Enhancement in the immediate future.
I don't see a 4.1.2 tag, but there's one for 4.1.6 in the iTextSharp project on SF. It shows ITextHandler using a bunch of constants from ElementTag in HandleStartingTags(). It also uses ElementFactory to build the various supported tags. Looking at the source for each function will tell you which attributes it supports.