Create a 'maven-p2-site' plugin

[laeubi]

See #114 for some more details.

This mojo produces a true maven p2 update site, that means that

1. The update-site metadata itself is deployable as a maven artifact and could be consumed as such
2. All the artifacts itself are not stored in the update-site but only contain references to maven GAVs
3. The artifact files are thus stored, managed and cached by maven itself and not duplicated in the deployed site or any other place
4. All the default maven techniques like mirrors, proxies and so on are appllied

Such a site might be consumed in a tycho build like this:

<repositories>
	<repository>
		<id>jetty</id>
		<url>mvn:org.eclipse.jetty:bom:10.0.1:zip:p2site</url>
		<layout>p2</layout>
	</repository>
</repositories>

[laeubi]

I have now added support to include even managed dependencies, that way it is possible to create an 'self-contained' updatesite for a BOM the following way:

<?xml version="1.0" encoding="UTF-8"?>
<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.eclipse.tycho</groupId>
	<artifactId>mvnp2site</artifactId>
	<packaging>pom</packaging>
	<version>1.0.0-SNAPSHOT</version>
	<properties>
		<tycho-version>2.4.0-SNAPSHOT</tycho-version>
	</properties>
	<build>
		<plugins>
			<plugin>
				<groupId>org.eclipse.tycho.extras</groupId>
				<artifactId>tycho-p2-extras-plugin</artifactId>
				<version>${tycho-version}</version>
				<executions>
					<execution>
						<configuration>
							<categoryName>Jetty Bundles</categoryName>
							<includeManaged>true</includeManaged>
							<includeDependencies>true</includeDependencies>
						</configuration>
						<id>maven-p2-site</id>
						<phase>package</phase>
						<goals>
							<goal>maven-p2-site</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.eclipse.jetty</groupId>
				<artifactId>jetty-bom</artifactId>
				<version>11.0.2</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>
</project>

With <includeDependencies>false</includeDependencies> only the directly declared jetty bundles are included

[laeubi]

I have now added an option to optionally specify a category.xml if one does not likes the default generated one or likes more sophisticated filtering rules. For advanced filtering, I also added the maven information as capabilities to the p2 unit.

[laeubi]

If there are not concerns I'll merge this next week, we can change/improve later then.

[akurtakov]

I haven't looked in details but we shouldn't (strongly discouraged) name it maven-p2-plugin as per https://maven.apache.org/guides/plugin/guide-java-plugin-development.html

[laeubi]

Good point what so at least tycho-maven-p2-plugin or maybe p2-maven-plugin what do you think?

[sparsick]

I would prefer tycho-maven-p2-plugin to prevent misunderstanding with this p2-maven-plugin.

[mickaelistria]

Tycho already has a tycho-p2-repository-plugin that seems to fit very well. This should just be a new assemble-repository-from-maven-deps mojo in the existing plugin.
Also, is the support for categories mandatory at that stage? I'd rather see it removed because it seems relatively weak compared to what's offered by category.xml (see how those are used by Orbit for instance), and repos generated from Maven deps are typically intermediary build artifacts that are not meant to be used by end-users.

[laeubi]

Tycho already has a tycho-p2-repository-plugin that seems to fit very well.

I can place the mojo there of course if you think it fits there...

Also, is the support for categories mandatory at that stage?

Otherwise it is hard to use in a target-file as PDE otherwise do not offer anything to select

it seems relatively weak compared to what's offered by category.xml

a user can always provide a category.xml if more control over generated categories is desired.

repos generated from Maven deps are typically intermediary build artifacts that are not meant to be used by end-users

Actually I think they are perfect to be consumed by end-users and are not intermediary at all

[laeubi]

relocated and renamed to assemble-p2-maven-site

[laeubi]

Any more comments on this?

[mickaelistria]

I still find the name assemble-p2-maven-site both not explicit enough (what does it actually assemble?) and redundant (we're in tycho-p2-repsitory-plugin, so the p2 segment seems useless in the mojo). What about assemble-maven-artifacts or assemble-maven-dependencies ?

[laeubi]

I still find the name assemble-p2-maven-site both not explicit enough (what does it actually assemble?) and redundant

It assembles a p2-maven-site that is a p2 site only containing references to maven artifacts :-)

hat about assemble-maven-artifacts or assemble-maven-dependencies

I find this misleading as it does not assemble any artifacts nor dependencies, it just takes what is already there...

[mickaelistria]

So what about publish-maven-artifacts ?

[laeubi]

This does not publish any artifacts, I think we should really keep the name descriptive.

[mickaelistria]

This name is not descriptive of what it does or what's it's intended to. I'll keep thinking about it and will change it when I find something better.

[laeubi]

Sure we can improve the name (I just don't like to delay this more just because of the name), but maybe it would help to explain why you think it is 'not descriptive of what it does or what's it's intended to' as it is descriptive and describes exactly what it does to me.

So maybe its me (as I'm not a native english speaker) getting it wrong, or we have a different understanding of the scope of this feature?

[mickaelistria]

If I read "assemble-p2-maven-site" with basic knowledge of Maven or p2, I don't know what to expect nor really have a clue about what it does.
"assemble-from-maven-deps" or "maven-deps-to-p2-repo" are more explicit.

[laeubi]

I think we can't explain the whole story in the mojo-name. That's why I added a longer explanation in the javadoc that should show up in the site-docs then.
For me "assemble-from-maven-deps" or "maven-deps-to-p2-repo" is not more explicit anyways and confusing because its not clear what is "assembles" or what will happen with the "maven-deps" because actually it does nothing with the dependencies itself (e.g. it does not copy and/or aggregates them somewhere). Beside that I like to avoid any "dependencies" in the naming as I'm sure to make this really useful for external project we have to support some kind of "reactor project" scope (as there where request for this in the past)..

So a good name for me should state that:

1. the 'artifact' it produces is a P2 (site/repository) and the content targetting maven artifact coordinates (that's why I came up with 'p2-maven-site')
2. it does not copy, aggregates or alter anything (thus the 'assemble-...' in my suggested name)
3. restricts itself by the name to a specific technique how it gathered the necessary information (thus no further qualification in the suggested name so we are open to enhance this if requested)

[mickaelistria]

the 'artifact' it produces is a P2 (site/repository)

That's already implied by the plugin name (tycho-p2-repository-plugin).
And actually, this plugin would be worth being extended to also append maven references to pre-existing p2 repositories.
So it could be something like tycho-p2-repository-plugin:reference-maven-artifacts

[laeubi]

this plugin would be worth being extended to also append maven references to pre-existing p2 repositories

I'm not sure if I understand what you have in mind here, but must confess that I don't like to bend the task of a mojo too much with many of config options to distinguish between different use-cases... It might be better to have a dedicated mojo for such use-cases and handling existing repositories seems a bit out of scope..

If you think p2 is implied I would suggest simply assemble-maven-site

[mickaelistria]

I'm not sure if I understand what you have in mind here

I imagine that if we have a pre-existing p2 repo, this mojo could be used to just add references to the existing repo, extending it.

assemble-maven-site

"maven site" is a dedicated term that's entirely unrelated in the maven world. We mustn't use this. And I think we should really avoid creating a new concept of a "maven site", after all, it's just a p2 repo, which happens reference maven artifacts.
If you're willing to keep the assemble part, it could be something like assemble-maven-references-repository

[laeubi]

I imagine that if we have a pre-existing p2 repo, this mojo could be used to just add references to the existing repo, extending it.

I'm not sure if this will work well...

"maven site" is a dedicated term that's entirely unrelated in the maven world

And repository as well ;-) I don't think that 'site' or 'repository' are any terms could be exclusive dedicated to maven, and putting the 'references' is just more confusing IMO... thats why we have invented namespaces and tycho could use names in his namespace that might have a different meaning in another namespace (maven).

From a users-perspective I already find tycho very confusing with all its different plugins and counter intuitive mojo names so one needs to lookup how the thing is named all the time ... so probably we better name the mojos from their bug numbers and simply use tycho-p2-repository-plugin:mojo-114 :-)

[mickaelistria]

And repository as well

Right, but repository is a p2 term as well, so although it's confusing, it's not new and is semantically strong. "site" means nothing in p2 world, so let's not introduce a new meaningless and confusing term.

From a users-perspective I already find tycho very confusing with all its different plugins and counter intuitive mojo names so one needs to lookup how the thing is named all the time ... so probably we better name the mojos from their bug numbers and simply use tycho-p2-repository-plugin:mojo-114 :-)

If you use a good pom editor, it can suggest the mojo via fuzzy search. So the question is "what would a Tycho user type if they want to build a p2 repository made of references to maven artifacts". Maybe "assemble" because it's used in other, maybe "repository" because it's used in the standard "assemble-repository" mojo. And what else?

[laeubi]

If repository is fine for you what about assemble-maven-repository then? I know about the autocomplete, but this first needs me to find out in what plugin the think is in, if I have found out that I don't need any fuzzy search anymore ;-)

But for the sake of completeness, I would defiantly type 'maven' as a first guess for sure...

[mickaelistria]

If repository is fine for you what about assemble-maven-repository then?

I find it a bit weak (not very explicit about it being only referencing artifacts and not including them) and confusing (I read "maven-repository" as "Maven Repository" exactly the opposite of the meaning of repository here). That said, it's better than the current name. I'll start a PR to adopt that name.
We can keep chatting about a better name in the meantime.

[laeubi]

Thats the problem that p2 and maven share some names but I have no idea... and artificial intelligence seems not to help here either...