You can find the latest file here.

Add support for native installers and executables

1JPM automatically resolves parent and child projects

See project.isAutoParentsAndChildren.
If true updates current pom, all parent and all child pom.xml
files with the respective parent details, adding seamless multi-module/project support.

This expects that the parent pom is always inside the parent directory,
otherwise a performant search is not possible since the entire disk would need to be checked.

1JPM helps porting your multi-module project

Add JPM.java to your root project directory and add JPM.portChildProjects(); before building.
This is going to download and copy the latest JPM.java file into all child projects it can find
in this directory, and also run it to generate an initial pom.xml for that child project.
The child projects name will be the same as its directory name.

A child project is detected
if a src/main/java folder structure exists, and the parent folder of src/ is then used as child project root.
Note that a child project is expected to be directly inside a subdirectory of this project.

Now project.isAutoParentsAndChildren will work properly, since all needed pom.xml files should exist.

• improve dir structure and move ThisProject class so that it is accessible from outside
• add sync run config and .vscode tasks run configs

made various properties public

(ChatGPT) Here's a summary list for the diff:

1. Imports Updated:

   • Replaced BiConsumer with Consumer.

2. ThisProject Class:

   • Moved the forceImplementation comment.
   • Added comments for adding additional plugins.
   • Rearranged and clarified dependency addition comments.

3. Class Removed:

   • Removed Plugins class definition.

4. ThirdPartyPlugins Class:

   • Added instantiation in static block of JPM class to ensure plugins are added.

5. Dependency Class:

   • Added fromGradleString static method.
   • Added excludedDependencies and type attributes.
   • Added exclude methods.
   • Updated toString and toXML methods to handle new attributes.

6. Repository Class:

   • Added isSnapshotsAllowed attribute.
   • Updated toXML method to handle isSnapshotsAllowed.

7. XML Class:

   • Renamed getOrCreateElement to getElementOrCreate.
   • Added remove and rename methods.
   • Added getElementOrNull helper method.

8. Plugin Class:

   • Updated beforeToXMLListeners to use Consumer<Details>.
   • Removed configuration, executions, and dependencies fields.
   • Added Details inner class to encapsulate plugin details and manage configuration, executions, and dependencies.
   • Updated toXML method to use Details.

9. Execution Class:

   • Updated toXML method to handle optional id.

10. Project Class:

    • Defaulted plugins to JPM.plugins.
    • Added profiles attribute and related methods.
    • Updated testImplementation, implementation, addDependency, and forceImplementation methods to return Dependency.
    • Added putPlugin method for plugin management.
    • Added addProfile and toXML methods.
    • Updated generatePom to use toXML.

11. Profile Class:

    • Added Profile class extending Project.
    • Overridden toXML method for profiles.

• fix goals being put not added
• made plugin api nicer to work with

✅ Production ready

At least working here: https://github.com/Osiris-Team/AutoPlug-Client/blob/master/src/main/java/JPM.java

• multiple fixes
• allow plugins access to complete pom xml

• fix not all dependencies being added
• enhanced template structure

1JPM is now a Maven pom.xml generator, since the complexity as a fully independent build tool
(see version 1.0.3) was too high for a single file.

• fix classpath incorrect format
• moved third-party plugins to top, to make upgrading 1JPM easier
• start supporting transitive dependencies
• caching of dependencies in local .m2 repository
• concurrent downloads
• checksum download
• dependency report gen
• dependency conflicts: The handleDependencyConflicts method detects and resolves version conflicts by keeping the latest version of each dependency (this might be an issue in itself thus the default should be throwing an exception if a conflict was detected and prompt the user to resolve this by explicitly adding that dependency with the wanted version to the build config).