Is there a plugin in gradle which can generate maven site similar thing? It would be great if it was compatible with current maven site apt format file.
It seems that there are two plugins, this and this. The first one was committed four years ago, I know nothing about the second. So it seems that these plugins will not be helpful.
I just wrote one as part of Gradle Fury. The primary plugin(s) (it's really just a collection of scripts) for Gradle-Fury is to enhance/fix many of the gradle short comings on publishing, android stuff, pom stuff, etc. Since there's pretty much no standard way for most things in gradle, we jam most of those configurations in the gradle.properties file. That said, the site plugin does depend on those settings to correctly stylize the site.
In short, to apply to your project...
put this in your root build.gradle file
apply from 'https://raw.githubusercontent.com/gradle-fury/gradle-fury/master/gradle/site.gradle'
Next edit your gradle.properties file and use this link as a template for your pom settings....
https://github.com/gradle-fury/gradle-fury/blob/master/gradle.properties
Create a src/site/ directory.
Make a src/site/index.md file as your home page
Copy/clone following files/folders from https://github.com/gradle-fury/gradle-fury/tree/master/src/site
css
images
img
js
template.html
Finally, build the site with gradlew site. Default output is to rootDir/build/site
Don't like the way it looks? (it looks like the Apache Fluido theme from the maven site plugin). Just edit template.html to meet your needs.
I'm currently working on a mechanism to bootstrap the site plugin which will remove a few of these steps, but that's what it is right now. More info and complete feature list is at the wiki
One last note, should run gradlew site after all of your check tasks, but it's not wired up to depend on it. Basically, anything that produces reports for your modules should be ran before site since it's aggregated into the site package, including javadocs and much more. The rest of the fury scripts help automate much of the painful configuration steps. Worth checking out (see the quality and maven-support plugins)
Disclaimer: I'm one of the authors.
Edit: site preview: http://gradle-fury.github.io/gradle-fury/
Edit: We just cut an updated version that makes manual creation of src/site and all the copy/clone tasks from the master repo unnecessary. Just run gradlew site while internet connected and it'll do the rest for you.
Related
I'm looking for possibilities for generating documentation using DocBook as part of my Maven build process. What I'm finding is everyone is suggesting docbkx-maven-plugin over Doxia. The problem is that it seems docbkx is no longer maintained or at least they've moved and left no forwarding address for where to look at the source code. According to the plugin's website the repository is on googlecode.com which of course hasn't existed for many years now. The last update I found of the plugin was back in 2016. This leads me to believe that the plugin is no longer maintained. Does anyone have any news to the contrary, or a different option for generating DocBook output during a maven build?
The source is available here: https://github.com/mimil/docbkx-tools
It does look like the project is no longer maintained, having seen no commits since 2015.
You don't actually need the plugin. If you have a working DocBook toolchain, you can use Maven to invoke it. The plugin could make certain aspects easier, but it also adds a limitation in that it only supports HTML output.
Background: we are migrating an application and have to adopt some new structures so the autmatic installation process works at our customers site.
Until now we are using maven-classifiers to build 3 different flavours of the same module (say flavours A, B and C). The problem is the automatic installation process at our customers site can't handle this as we expect. While downloading from the nexus, the 3 artifacts overwrite each other and only the last is actually there.
There is absolutely no way, that we can fix this issue from the customer side (although it would be trivial!). Actually, our customer won't change absolutely anything on his site - we have no control whatsover of the enviornment on our customers site.
So the proposed solution to make this work, to deploy 3 artifacts with different artifactIds. I.e. modA, modB and modC
My question is: how to achieve this in the 'most elegant way'?
We don't want to restructure the whole project as truly triplicating the number of modules would be horrendous.
My ideas so far of which I'm not even sure if they would work:
Use antrun plugin to copy/rename files and generate the corresponding pom files from a template and then use deploy-file to upload to the nexus.
Using assemblies? How?
Creating new submodules with the corresponding pom files (and in there the GAV the costumer requires) inside each one of the modules which should be deployed, but each of these submodules would basically only copy the artifacts from targetA/app--, targetB/... and targetC/... This way I hope at least having a more or less clean deploy step (without using a deploy-file to deploy a WAR and a pom). The pom files would be minimal and viewed from the root-module we would still see only one module 'mod' and hide the ugliness inside this rather than having 3 modules 'modA', 'modB' and 'modC'. This way we would also decouple the devs-view and the deployments-view on the project. Devs could continue the way they are used to and integrators would take care of the 'putting things in the way the customer wants it'-part. Now here my question is: how can I create a maven project where the 'complete build' is actually nothing more than copying a war?
It is clear to me, that all these choices are horrible. If you know of the 'right way' to solve my problem I would really appreciate it. Otherwise I would really just like to know how to achieve the 'copying a war' part.
We are using IntelliJ idea in order to develop our product.
till now, we saved the iml/ipr files in a version control in order to share the same configuration among developers (and also between different versions of our product).
however, since idea changes those iml files a lot, it is an exhausted task to resolve its conflicts, and actually feels a bit wrong.
Moreover, idea 15 is no longer checks-out iml/ipr automatically.
I tried the maven-idea-plugin which suppose to generate the iml/ipr based on the pom.xml and it looks promising (except for some minor issues) but it's obsolete and there many stackoverflow posts advise against it.
I also undestand that the "correct way" to load our project is by loading the e pom.xml directly in idea.
The problem with that loading the pom.xml is that each user has to reconfigure idea (such as exclude directories, set the run configuration, plugins, maven version, JDK location etc.)
every time he download the code from the version control, which happens quite often.
So, my question is what is the best way to use intellij idea with our project.
my goal is that once a developer download the code he will be able run idea without manually configure a thing.
Thanks,
Meir
I am using Intellij 15.0.3 Community edition.
In our current project we do not add *.iml to Git.
For shure we do add pom.xml to Git.
I did not add any special plugins or configure idea in the way you described
(such as exclude directories, set the run configuration, plugins, maven version, JDK location etc.)
So I am using Idea out of the box, only the plugin 'Maven integration' is activated. I initially cloned the Git repository in a new folder.
In Idea I choosed File| New | 'Project from existing sources '
and selected the folder with the pom.xml.
Thats all, works perfectly. I can build in Idea or on the command line.
I can use Git in Idea or on the command line.
Everything works perfect.
So I can asure you that its absolutely possible without having *.iml under version controle.
I am working on a project and using Maven to build it. The project is a quite big Java web application and it is supposed to work with both Mysql and Oracle databases.
The problem is that there are some specific annotations related to either of the two databases in the source code, plus some other differences, so that I am forced to manually comment/uncomment part of the code before building the application for one of the two databases.
Basically what I would like to achieve is to have my build script, maybe via a Maven profile, to automatically switch the source classes before building depending on the database I want my war to work against.
Putting it simply, the idea is to have MyClass.oracle and MyClass.mysql, and depending on my build profile I should move one of the two in the source dir, rename it MyClass and build. This should be done for some packages, classes, and also configuration files.
Is there any way I can achieve it via "pure" Maven? The only solution I came across till now is to use an antrun plugin and reference an Ant build.xml inside of it.
Thank you,
Mattia
A pure maven solution would be to develop your own maven plugin. Depending on your requirements this can be an overkill, however it is not hard at all, you can see how to achieve this here.
This is a limitation of Maven. One of Maven's purposes is to not have a build script. You should simply use the plugins as available, and setup your project the right way, and magically, everything will build!
There is one solution: Use Ant. Well, not to redo your whole project with Ant, but with the antrun plugin, you can run a few Ant tasks at various phases of your Maven build life cycle.
It's been a long, long time since I've used this, so I am not going to try to write a test pom.xml, but I don't remember it being very difficult to use.
Of course, the correct Maven solution is to divide your project up into "common core" code, and then a separate Oracle and MySql client that uses the "common core". By the way, I hope you're not patching source code. Instead, you're using a properties file to do this for you.
I have seen many questions concerning this issue, but I'm new to this topic and I have to convert previously written project (standard, Eclipse Java EE project) into Maven.
My first problem is that I'm completely new to Maven. Second - I can't change the directory layout. And third - I'm running out of time.
Some of topics I've read covered few of my questions, but I need it clearer.
I have 3 modules connected with each other:
* Main one with catalogues: .settings, db-schema, EarContent,
* EJB with .settings, bin, build, ejbModule
* WEB with .settings, build, src, WebContent.
As far as I know (correct me if I'm wrong) there is just one 'mapping' when I have single catalogue with source code and it looks like this:
<build>
<sourceDirectory>ejbModule</sourceDirectory>
...
But what if I have two catalogues? I mean the WEB module - src and WebContent.
What else do I need to change if don't use standard directory layout?
What with the main module with EarContent? - There is no source code, but there is an -ds.xml file which (I guess) I have to put somewhere.
In main POM.xml I know that I have to add tags, but is there anything else I should do?
Sorry for (maybe) not precise and wide questions, but I've started today and I have to do it fast. So far I've found Sonatype site and managed to get one of their pdfs, but I'm reading it quite too slow and need 'some' help doing it. I've also downloaded the archetype for nexus repository and I'm trying to understand it.
Try to use add-source goal of build-helper-maven-plugin.