Programatically getting an effective POM using Maven Resolver Provider - java

What do I want to do?
Given a POM file on the local filesystem.
I want to programmatically obtain the effective POM of that POM file. Specifically I want to do the following:
Resolve the POMs dependencies
Ensure that all parent POMs are processed
Obtain the list of dependencies of the fully resolved POM
And so on...
I don't need to obtain transitive dependencies.
What works?
I'm using Maven Resolver Provider which sort of works. However
I have to use a package private class org.apache.maven.repository.internal.DefaultModelResolver
Here a GitHub link to a sample Maven project that you can run: https://github.com/sahilm/maven-resolver-test
The example program does the following:
Downloads the latest spring boot POM from Maven Central.
Prints out it's direct dependencies (with parent deps included)
You can run the the program with:
mvn exec:java -Dexec.mainClass="com.sahilm.maven_resolver_test.Test"
What I need help with?
I need help with understanding why I have to use a package private class to get stuff to work.
Is there another way to get the information I need?

You can create (in your project) a public class under the package: org.apache.maven.repository.internal that extends the package-accessibility class. Just use a class name that is not possible to be used in the furutre by the vendor.
package org.apache.maven.repository.internal;
public class VisibleDefaultModelResolver extends DefaultModelResolver{
public VisibleDefaultModelResolver(RepositorySystemSession session, RequestTrace trace, String context, ArtifactResolver resolver, VersionRangeResolver versionRangeResolver, RemoteRepositoryManager remoteRepositoryManager, List<RemoteRepository> repositories) {
super(session, trace, context, resolver, versionRangeResolver, remoteRepositoryManager, repositories);
}
}
Then your code becomes:
ModelResolver modelResolver = new VisibleDefaultModelResolver(session, requestTrace, "context", artifactResolver, versionRangeResolver, remoteRepositoryManager, repos);

Maybe you can use ProjectModelResolver. Here's a code snippet,
DefaultRepositorySystem repositorySystem =
new DefaultRepositorySystem();
repositorySystem.initService(locator);
ModelResolver modelResolver =
new ProjectModelResolver(session, requestTrace,
repositorySystem, remoteRepositoryManager, repos,
ProjectBuildingRequest.RepositoryMerging.POM_DOMINANT,
null);
I've included a working code here.

Related

Getting the resource path of the java project from a custom gradle plugin

Trying to create a custom gradle plugin in java, how do i get the resources path from inside the task class?
public class MyCustomPlugin implements Plugin<Project> {
#Override
public void apply(Project project) {
project.getTasks().register("doStuff", CustomTask.class);
}
}
public class CustomTask extends DefaultTask {
// How do I get java project resources dir from here?
#Inject
public CustomTask(ProjectLayout projectLayout) {
directoryProperty = projectLayout.getBuildDirectory();
}
#TaskAction
public void execute() {
...
}
}
I would recommend to not get the directory inside the task, because the plugin that provides it might not be applied. Instead I would do it from within your plugin that registers the task, this way you can also ensure that the necessary plugin is actually applied. Gradle will display an error if the task is used without a value being assigned to the input that explains that nothing was assigned.
With the kotlin-dsl:
#CacheableTask
abstract class CustomTask : DefaultTask() {
#get:InputFiles
abstract val resources: FileCollection
//...
}
I cannot answer if #InputFiles is the right annotation for your use case, because I don't know what you want to do with the resource. Refer to the Gradle documentation for more information on the available annotations, and what they do.
plugins {
java
}
tasks.register<CustomTask>("customTask") {
resources.set(sourceSets.main.map { it.resources })
}
Notice the map {} which ensures that our task has a dependency on the processResources task, this is done automatically for us because we stick to the provider API of Gradle for everything.
Note that the resources are by default in one directory, but they don't have to be. This is why the resources are defined as SourceDirectorySet and not as Provider<Directory>. The same is true for anything that originates from the SourceSetContainer. It is easier to explain with Java source code: imagine you have Java and Kotlin, then you will have src/main/java and src/main/kotlin, hence, 2 directories. The former will have a **/*.java include filter, whereas the latter has a **/*.kt includes filter. If we just want to get all sources then we use sourceSets.main.map { it.java.sourceDirectories }, and if we want to get one of both it gets complicated. 😝
First, you'd have to ensure this is a Java project: either applying the "java" plugin from your plugin (project.getPluginManager().apply("java")), or only registering the task when the "java" plugin has been applied by the user (project.getPluginManager().withPlugin("java", ignored -> { project.getTasks().register(…); });).
You could then get the resources from the main source set:
SourceSetContainer sourceSets = project.getExtensions().getByType(SourceSetContainer.class);
// Use named() instead of get() if you prefer/need to use providers
SourceSet mainSourceSet = sourceSets.get(SourceSet.MAIN_SOURCE_SET_NAME);
SourceDirectorySet resources = mainSourceSet.getResources();
BTW, the best practice is to have tasks only declare their inputs and outputs (e.g. I need a set of directories, or files, as inputs, and my outputs will be one single file, or in one single directory) and have the actual wiring with default values be done by the plugin.
You could have the plugin unconditionally register the task, then conditionally when the "java" plugin is applied configure its inputs to the project resources; or conditionally register the task or unconditionally apply the "java" plugin, as I showed above.
You can access the sources through the project.sourceSets.
#Inject
public CustomTask(Project project) {
directoryProperty = project.projectLayout.getBuildDirectory();
sourceSet = project.sourceSets.main
}
See also the reference documentation here: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_project_layout

Load classpath of project gradle plugin is applied to

I am writing a custom gradle plugin, which will generate some code for me, based on the code it finds in the project it is applied to.
For this I need to find all classes that extend a specific class.
The problem is that the class, that is extended, is not loaded in the classpath, since it is a dependency of the other project.
Currently I got this for my custom Task
public class GenerateCodeTask extends DefaultTask {
#TaskAction
public void generateCode() throws MalformedURLException, ClassNotFoundException {
File buildDir = new File(getProject().getBuildDir(), "classes/main");
File root = new File(getProject().getProjectDir(), "src/main/generated");
URLClassLoader classLoader = new URLClassLoader(new URL[]{buildDir.toURL()});
Class itemClass = classLoader.loadClass("net.minecraft.item.Item");
Reflections reflections = new Reflections(classLoader);
Set<Class<?>> items = reflections.getSubTypesOf(itemClass);
}
}
And this for the plugin
public class EasymodsPlugin implements Plugin<Project> {
#Override
public void apply(Project p) {
Task t = p.getTasks().create("generateCode", GenerateCodeTask.class);
t.dependsOn(p.getTasks().getByPath("compileJava"));
}
}
This is the error I am getting
java.lang.ClassNotFoundException: net.minecraft.item.Item
I know that the problem is that the library containing the class is not loaded, and that causes the exception.
What I want is to be able to load all dependencies of my project into the classloader, so I can use reflections to find all "items" in the project (which I need to generate code)
Greetings Failender
I think you almost got it.
You need the compileClasspath property. I pass it as an input parameter to my task, and build the Class Loader from it:
In plugin:
Set<File> ccp = project.getConfigurations().getByName("compileClasspath").getFiles();
task.classpath = ccp;
In task:
#InputFiles
Iterable<File> classpath;
What this property is adding is:
the path to the classes on projects it depends on that are generated under project_id/build dir. ( So no need to build the path manually )
All library deps for your project. That i think you were missing.
So, in the case your class is of type 1:
It is better if you have different subprojects: the one that has the original classes and the other with the generated ones.
So the second depends on the first:
dependencies {
compile project(':my_project_with_classes_to_extend')
}
In the case is the second one, you can just add the library as a dep to your project and it will find the class.
And rewire the tasks so you are sure the fist project is built before calling your task (just on root level of your 2nd project build.gradle):
I think that´s the part that wasn't really working for you, apparently, compileJava and build are not exactly the same. Or at least, compileJava wasnt working for me either.
myGeneratorTask.dependsOn( ":my_project_with_classes_to_extend:build" )
compileJava.dependsOn( "myGeneratorTask" )

SPI with Guice error

So I've been making some kind of plugins API for a Java project (to load JAR files externally) and well, I wanted to be able to add any Guice module inside any plugin to my project's dependency graph.
What I did was have a PluginsModule and in the configure method scan for other modules in plugins and install them using Java's ServiceLoader.
I made a test plugin and made a module for it, I confirmed it did get installed. No problems at this point. The problems appear when I do anything inside that module, for example I bound some interface to an implementation in that plugin (just to clear this up, I did the same thing without the plugin and it worked so it's not a binding problem) and tried to inject it, configuration errors saying there was no implementation for that interface appear.
public enum StandardGuiceModuleScanningStrategy implements GuiceModuleScanningStrategy {
INSTANCE;
#Override
public Set<Module> scan(Path directory) throws IOException {
File directoryAsFile = directory.toFile();
File[] childrenFiles = directoryAsFile.listFiles();
if (!directoryAsFile.isDirectory()
|| childrenFiles == null
|| childrenFiles.length == 0) {
return Collections.emptySet();
}
Set<Module> modules = new HashSet<>();
for (File childrenFile : childrenFiles) {
ClassLoader directoryClassLoader = new URLClassLoader(
new URL[]{childrenFile.toURI().toURL()});
ServiceLoader<Module> moduleServiceLoader = ServiceLoader.load(
Module.class, directoryClassLoader);
moduleServiceLoader.forEach(modules::add);
}
return modules;
}
In that implementation of my GuiceModuleScanningStrategy, as I mentioned before, I did use ServiceLoader. Anyways, I also tried other stuff, like scanning the JAR file and checking for a Module, and seeing if it has a specific annotation.
All Guice Modules annotated with #GuiceModule, will be installed into a child Injector. All classes annotated with #AutoBind will be bound to all inherited interfaces. You can also name it, which would lead to a named binding and overwrite the interfaces, which should be used. And if you don't want to use all Features, just overwrite the StartupModule and bind only the Features you want or your own.

Use Errai Ui with GWT

I'd really like to use Errai UI(3.2.4) in my GWT (2.8) application. I already have one setup with an EntryPoint implementation and an onModuleLoad. I have restGWT setup and interacting with my server (which uses Jersey).
All of the documentation I find assumes that you are building a full-on Errai project, starting from scratch using the forge addon thing. I'm not. I just want to use the templating stuff and data-binding. I'm working with a barebones setup and I can't even make a label show in my app.
I have this GWT entry point:
public class App implements EntryPoint
{
#Inject
private ApplicationContainer applicationContainer;
public void onModuleLoad()
{
RootPanel.get("root").add(applicationContainer);
}
}
And the ApplicationContainer:
#Templated
public class ApplicationContainer extends Composite
{
#DataField
private Element applicationContainer = DOM.createDiv();
#PostConstruct
public void init()
{
GWT.log("Initializing");
}
}
And it's accompanying template:
<div id="applicationContainer" data-field="applicationContainer">
Application Container
</div>
I should see "Application Container" in the browser, but I get this error in the browser console:
ComplexPanel.java:96 Uncaught TypeError: Cannot read property 'removeFromParent_0_g$' of undefined
The widget and the template are named the same and in the same package. My widget is created just like the documentation shows: http://erraiframework.org/getting-started/index.html#ErraiUIPage
Can someone tell me what I'm missing here? Examples for this are very minimal, and they all assume a complete Errai project. Do I still need an #EntryPoint? Do I need #PostConstruct? Is Errai even designed to work like this?
Thanks for any help.
Yes, the #EntryPoint annotation is important and I'm not sure you'll be able to mix up part of this framework with some other approach. It doesn't mean you need to use all the modules, but you should rather follow the Errai's guidelines if about the part you use.
Please see example entry point here:
https://github.com/errai/errai/blob/3.2.4.Final/errai-demos/errai-jpa-demo-todo-list/src/main/java/org/jboss/errai/demo/todo/client/local/ClientEntryPoint.java
You'll find also more examples from the path .../3.2.4.Final/errai-demos/
Above is about Errai 3.x.
Please also note that Errai 4.x brings some changes if it is just about the Errai UI. It's nicely described here:
http://errai-blog.blogspot.com/2016/04/errai-400beta1-released.html
Now your #Templated bean do not need to extend Composite. The root element of the template is accessible as a #DataField etc.
Hope you'll find it helpful. Good luck!
The answer to your questions is here: https://github.com/errai/errai-tutorial
You basically need to migrate your app to use Maven so you get the dependencies right first, then use the POM in this project and snap it in your project.
Then you can include a Bootstrap file to add a #EntryPoint class however this is not necessary you can just add a Page in the client path e.g.:
com.mycompany.app.client
-->MyPage.html
-->MyPage.java
Where the java file here contains the default page, i.e.
#Dependent
#Templated
#Page(role = DefaultPage.class)
public class MyPage extends Composite{}

Nullpointerexception at org.springframework.data.mongodb.core.convert.DefaultDbRefResolver.<c linit>(DefaultDbRefResolver.java:57)

As I have looked for an answer to this exception, but didn't find it anywhere, I'll leave this post here for future reference. So if anyone else runs into this problem, you are welcome.
I'm using the maven shade plugin to create a runnable jar together with org.springframework.data:spring-data-mongodb:1.4.0.RELEASE
I was running into the exception in the title, after creating the jar and running it with java -jar Foo-0.0.1-SNAPSHOT.jar
And the answer:
The error is here: https://github.com/spring-projects/spring-data-mongodb/blob/master/spring-data-mongodb/src/main/java/org/springframework/data/mongodb/core/convert/DefaultDbRefResolver.java
in this line:
private static final boolean IS_SPRING_4_OR_BETTER = SpringVersion.getVersion().startsWith("4");
SpringVersion.getVersion returns null if it cannot retrieve the version number from the package. As the dependencies are extracted in the shaded jar, there is no package to retrieve the version number from and .startsWith("4") throws a NullPointerException.
To solve this issue (well it's kind of a quick and dirty solution, but it works), create a package org.springframework.core in your source folder and create the following class (I am using the springframework in version 4.0.2-RELEASE):
package org.springframework.core;
/**
* for spring data mongodb
* it can't determine the springversion in the shaded jar
*/
public class SpringVersion {
public static String getVersion() {
return "4.0.2-RELEASE";
}
}
The class will overwrite the original SpringVersion class file.
Like #mininme mentioned in his answer, the problem arises in 4.0.2.RELEASE because of
SpringVersion.getVersion().startsWith("4").
For now it means, that if you have such a problem, you should probably try a more recent version of Spring. At version 4.3.0.RELEASE of Spring there in no such problem anymore.

Categories