Add support for maven-dependecies inside eclipse-pde target files

[laeubi]

The eclipse-pde target files (extension .target, content is xml) supports for a while to also mention maven dependencies. An example could be found here.

It would be good if dependabot can suggest updates for these embedded maven dependencies as it does for maven pom.xml the following way:

1. parse the content as xml
2. search for <dependencies> sections and examine them as it does for maven pom.xml
3. if it founds and update create a PR for the file with the updated versions as it does for maven pom.xml

As we are using the maven syntax here my expectation is that it won't be that complex but I'm not familiar with how dependabot works to guess the complexity. I'll post this issue also on the eclipse-mailinglist in the hope that we might get someone with ruby-skills to maybe even provide a PR for this.

[ConradGroth]

Very interesting proposal. I looked into CONTRIBUTING.md, where they state that they don't accept new ecosystems. Although a lot of code from the maven PackageManager can be reused, parsing and updating a target file is a new ecosystem.

[laeubi]

@ConradGroth I'm not sure if "we have paused" means "the dependabot contributors have paused" at laest they state

If you are an ecosystem maintainer and are interested in integrating with Dependabot, and are willing to help provide the expertise necessary to build and support it, please open an issue and let us know.

That's why I hope someone from the eclipse-eco system might take a look and share some insights about the actual effort. From my limited understanding of the code, it might even be possible to make a .product file just an alias for pom.xml and maybe adjust some smaller parts so we not strictly needing a complete new ecosystem.

And even if I think parsing+update is smaller effort compared to adding support for a complete new PackageManager.

e.g. if I look at

dependabot-core/maven/lib/dependabot/maven/file_parser.rb

Lines 19 to 28 in 9fe65f9

	# The following "dependencies" are candidates for updating:
	# - The project's parent
	# - Any dependencies (incl. those in dependencyManagement or plugins)
	# - Any plugins (incl. those in pluginManagement)
	# - Any extensions
	DEPENDENCY_SELECTOR = "project > parent, "\
	"dependencies > dependency, "\
	"extensions > extension"
	PLUGIN_SELECTOR = "plugins > plugin"
	EXTENSION_SELECTOR = "extensions > extension"

it seems any xml file that uses the maven-syntax should be already covered by the parser.

[mickaelistria]

I'm not sure "Maven dependencies expressed in another format" qualifies as "a new ecosystem", and agree with @laeubi interpretation that it seems like just tweaking the parser to support new files could work.

[jeffwidman]

👋 sorry for the slow response.

If the tweaks are primarily just adding a new file extension and then passed to the existing parser, we might be open to accepting a PR. If it's a whole 'nother ecosystem, then we're not ready to accept it... although we know this is painful and we hope to have a better story around how to extend Dependabot with new ecosystems.

I'm not an expert in Java, so if you're interested in this, then before submitting a PR could you explain:

1. Is this literally just accepting a new file extension, and using the existing parser on it or are there further tweaks that would be needed?
2. How popular is this file type? What is it used for?

[laeubi]

@jeffwidman thanks for the reply and considerations, as far as I understand an "ecosystem" describes how artifacts are fetched, how versions are found, where repositories might be located and so on, so this is not required, we want exactly the same what maven does, probably even a bit simpler as target files do not support a parent or do not have support for version placeholders. So even no knowledge of java is really required, if one knows maven/pom.xml it will be very familiar for them, we actually even use the maven libs to process the data under the hood.

I have made a little table to highlight some differences regarding to a pom.xml

	Maven	Targets
File Names	extensions.xml, pom.xml	*.target
Usual number of files	One per module	One per repository
File Type	xml (UTF-8)	xml (UTF-8)
Selectors	project > parent, dependencies > dependency, extensions > extension, plugins > plugin, extensions > extension	dependencies > dependency
Variables in versions	yes	no

Here is an example file:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/771fb288a06bbb7a07f1e745300aad43c6ed1ca7/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L143-L148

As you can see this is just a one-to-one like maven pom.xml does (for example):
https://github.com/apache/maven/blob/f9ea10688c7bff04665b2d41f548c63d10a53c63/pom.xml#L207-L211

Target files are the main source of dependencies (like a bom in maven) when developing Eclipse IDE (and Plugins) and its underlying RCP Platform: https://eclipseide.org/ and the maven support added there is getting more and more interest lately so people started to ask for dependabot support because they already familiar with that in their maven builds and really appreciate it there.

If you need further information let me know.

[deivid-rodriguez]

Based on the explanation, I tagged this as a feature request for the maven ecosystem. Feel free to play around with the dry-run script or the CLI to figure out the changes we need to start supporting this kind of file, I'll be happy to review a PR 👍.

[laeubi]

@deivid-rodriguez I have now created a first draft here that shows how I think it would work to enhance the parser/fetcher:

• Add support for updating dependencies in target files #6913

It would be great if you can take a look and give some hints how to enhance the test-cases, I'm quite new to ruby and currently try to understand how all the stuff works so any help would be appreciated!

[ruspl-afed]

How popular is this file type? What is it used for?

It is used in dozens of Eclipse-based open source projects by hundreds of developers to configure the dependencies. Support from dependabot could save incredible amount of time and let us focus on functionality instead of release engineering tasks.

[akurtakov]

What is the status of this one? It would be tremendous help if dependabot handles this proper.