I am interested in showing private members in javadoc for only certain packages. For the all other packages only show public and protected members in javadoc. The show tag is for configuration, but not for the group.
Thank You
According to Apache Maven Javadoc Plugin it uses javadoc - The Java API Documentation Generator. I'm not aware of an option in javadoc for changing access modifiers for indivdual packages with the standard doclet. You could write your own doclet, of course.
I can also imagine the following hack:
create a "main" JavaDoc with a certain access modifier and assign the desired packages
create a second JavaDoc with a different access modifier and assign the desired packages
create a third ...
Now the hacker's part:
merge the second JavaDocs' allclasses-[frame|noframe].html (All Classes) into main's allclasses-[frame|noframe].html
merge the second JavaDocs' overview-frame.html (Packages) into main's overview-frame.html
merge the third ...
merge the third ...
Related
In the gradle doc: https://docs.gradle.org/current/userguide/custom_plugins.html#sec:custom_plugins_standalone_project
The code block is:
gradlePlugin {
plugins {
create("simplePlugin") {
id = "org.example.greeting"
implementationClass = "org.example.GreetingPlugin"
}
}
}
I noticed it calls create method. And I looked the source code. It says:
Creates a new item with the given name, adding it to this container,
then configuring it with the given action.
What does it mean? Is it actually used anywhere? Or it can be any name does not really matter?
gradlePlugin.plugins is a NamedDomainObjectContainer - which are used by Gradle to hold multiple objects, each with a name.
The documentation on plugin development goes into more detail on the usage of NamedDomainObjectContainers.
Sometimes you might want to expose a way for users to define multiple, named data objects of the same type.
[...]
It’s very common for a plugin to post-process the captured values within the plugin implementation e.g. to configure tasks.
Since the elements of a NamedDomainObjectContainer can be any type, there's no specific usage for one. Generally they are used to configure the Gradle project, for example creating specific tasks, configuring source code locations.
My setup includes 2 Jenkins pipeline libraries, e.g. lib_generic and lib_specialized, where the second one depends on the first one (will call classes and global vars from the first one).
I have to write my Jenkinsfile with the #library header that includes both:
#Library(['lib_generic', 'lib_specialized']) _
or
#Library(['lib_generic#v1', 'lib_specialized#v2']) _
In other words, the Jenkinsfile has to declare the transitive dependencies of the pipeline libraries it uses. I would like to hide that implementation detail.
Ideally, I would like my second library itself to specify its dependency on the library lib_generic, and then have the Jenkinsfile only declare the library lib_specialized.
#Library(['lib_specialized#v2']) _
Is there a known way to do this?
I would like to add a couple comments:
I realize that what I'm asking for, forces me to choose the version of the first library explicitly in the second one, OR delegate to the Global settings, so I probably won't be able to overwrite anything in the Jenkinsfile. I am okay with that (it's an implementation detail!).
I could use "Load implicitly" for the first library when defining it in the Global Settings. But again, seems like an implementation detail.
The dynamic library loading feature should be possible, but this seems impractical to me as I would need to declare and import the library over and over in all Classes and global var for the second library. Unless there is a better way?
I am completely new to Groovy, trying to learn it, but stymied because I can't parse the syntax well enough to even know where to look in the documentation. I am using Groovy in Gradle. There are many places where examples are given, but no explanation on what it means, so I just need a few pointers.
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'com.xxx.yyy'
artifactId = 'zzz'
from components.java
}
}
repositories {
mavenLocal();
}
}
The main build code is referring to things on the project class. On that class, I can find a property called publishing, and it is a class PublishingExtension. It appears then that the curly brace starts a closure with code in it. The documentation says this syntax:
publishing { }
configures the PublishingExtension. What I want to understand is what it means (i.e. what is actually happening) when I specify what looks like a property and follow that with a Closure. In the Groovy documentation I could not find any syntax like this, nor explanation. I sure it is something simple but I don't know enough to even know what to look for.
If I visit the Project Class API Docs there is no method there named publishing. Nor is there a property defined by the method getPublishing. Apparently this magic capability is enabled by the publishing plugin. If I visit the Publishing Plugin API Doc there is no description of this publishing property either or how it modifies the base project.
Similarly, drilling down a little more, that closure starts with a symbol publications and in the documentation for the PublishingExtension I find a property which is of type PublicationContainer which is read only. I also find a method named publications which does not accept a closure, but instead a configuration of type Action<? super PublicationContainer>. Again, I don't know how the contents of the curly braces are converted to an Action class instance. How does this object get constructed? Action is an interface, and the only method is execute however it is completely unclear how this action gets constructed.
The block that defines the Action starts with symbol mavenJava that looks like a method, but actually that first symbol is declaring a name of a new object of type MavenPublication named mavenJava. Either this is magically constructed (I don't know the rules) or there is a method called, but which method? What is it about PublicationContainer that allows it to know that an arbitrary mavenJava command is supposed to create an object instance. Then again, the curly braces that follow this, is that a closure, a configuration, or something even more exotic?
So as you can see, I am missing a little info on how Groovy works. So far I can't find documentation that explains this syntax, however it might be there if I knew what to look for. Can anyone explain what the syntax is really doing, or refer me to a site that can explain it?
publishing is called to configure the PublishingExtension.
In PublishingExtension there is a publications method accepting an Action which is usually coerced from a Closure. In Groovy a Closure is automatically converted to an interface with a single method.
mavenJava is a non-existent DSL method, which is passed by Gradle DSL builder to the create method of PublicationContainer:
publishing.publications.create('mavenJava', MavenPublication) {
// Configure the maven publication here
}
groupId and artifactId are properties of MavenPublication and are being set here.
from is the from(component) of MavenPublication and is written using Groovy simplified method call literal without brackets.
In general Gradle uses a root DSL builder which calls the nested DSL builders provided by plugins. Hence sometimes it's difficuilt (also for the IDE) to find proper references of all parts of the build.gradle file.
If my pom is a child a hierarchy of other poms, is there a way to show exactly which parent pom contains the definition of a plugin?
Short answer is most probably: No.
According to the way Maven builds its model before executing a certain build, the Maven Builder Model:
In phase 1 the hierarchy of poms is resolved
In phase 2 model normalization and plugins configurations are further resolved
But only at the end of phase 2 the effective model validation is performed, which is done on the final effective pom.xml file, as a result of merges, overriding, profiling, injections (of properties) and so on.
To have a look at the full pom, the effective-pom goal of the maven-help-plugin is definitely the right tool. It will show (or write to a given file) the final effective pom a build is gonna use.
The full definition of a plugin (its executions, its global configuration and so on) can only be created once we have the effective pom, because:
the pluginManagement section in any point in the hierarchy can influence a certain plugin
The plugin section in any point in the hierarchy can also influnce it
profiles declared in any point in the hierarchy can also influence it
properties, if used as placeholders, can also play an important role
Having a look at the official Maven POM reference, we can see many entry point to influence a certain plugin definition, which will only be effective to our build once merged through the whole pom hierarchy. A definition per se would not help much since it can then be overriden/influenced further on on the hierarchy chain.
Think about the inherited element of a plugin:
true or false, whether or not this plugin configuration should apply to POMs which inherit from this one. Default value is true.
Or merging of plugin configuration sections:
The default behavior is to merge the content of the configuration element according to element name. If the child POM has a particular element, that value becomes the effective value. if the child POM does not have an element, but the parent does, the parent value becomes the effective value.
You can control how child POMs inherit configuration from parent POMs by adding attributes to the children of the configuration element. The attributes are combine.children and combine.self. Use these attributes in a child POM to control how Maven combines plugin configuration from the parent with the explicit configuration in the child.
Or further down per execution of a plugin:
inherited: Like the inherited element above, setting this false will supress Maven from passing this execution onto its children. This element is only meaningful to parent POMs.
The overall management can then be influenced by pluginManagement:
Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
As such, the plugin definition at a certain point of the pom hierarchy may not be meaningful to the final effective build.
Is it possible to do string and math operations on properties in maven 2?
I have a property ${version} that has a value of something like 5.3.0-SNAPSHOT, now I'd like to extract the 5 and do some math on it, say subtract 3 from it. So my new property would get the value 2.
You may want to look at the parse-version goal of build helper maven plugin. As the example in this page indicates, once this goal is run, it makes available a bunch of propeties which can be used to do subsequent operations.
parsedVersion.majorVersion
parsedVersion.minorVersion
parsedVersion.incrementalVersion
parsedVersion.qualifier
parsedVersion.buildNumber
There is an example here (http://ronalleva.com/groovy/maven/programming/2008/01/23/using-the-groovy-maven-plugin-to-do-magic.html) which embeds groovy into your plugin. Further in the example he sets a property in the maven project.