releases contain snapshot components

[jgrivolla]

Some components (see e.g. https://github.com/dkpro/dkpro-core/blob/de.tudarmstadt.ukp.dkpro.core-1.9.2/dkpro-core-io-cermine-gpl/pom.xml) appear to have SNAPSHOT versions even within DKPro releases (at least in 1.9.0, 1.9.1 and 1.9.2). This leads to problems with gitflow which rejects SNAPSHOTS even for components that are only seen through DependencyManagement (when using the JGit Flow Maven Plugin, according to @Jibun).

This seems to be the case for at least dkpro-core-io-nyt-asl, org-dkpro-core-lancaster-asl, and dkpro-core-io-cermine-gpl.

[reckart]

These are modules which are not part of the Maven release - but in the tag on GitHub, they are of course included.

Normally, you wouldn't touch these tags. In order to prepare a PR for a released version, you'd check out e.g. the 1.9.x branch and prepare the PR against that. To prepare release, we use the Maven release plugin.

[reckart]

I have added a section on preparing PRs to the contribution guidelines (scroll to bottom).

[jgrivolla]

Ok. The strange thing is that the JGit-Flow Maven Plugin complains (when building our own components or pipelines) when we include a DependencyManagement section for DKPro, e.g.:

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>de.tudarmstadt.ukp.dkpro.core</groupId>
				<artifactId>de.tudarmstadt.ukp.dkpro.core-asl</artifactId>
				<version>1.9.2</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
			<dependency>
				<groupId>de.tudarmstadt.ukp.dkpro.core</groupId>
				<artifactId>de.tudarmstadt.ukp.dkpro.core-gpl</artifactId>
				<version>1.9.2</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

This may be more of a problem with the plugin overeagerly complaining about things we are not actually using/importing, but we were surprised (and will have to work around it somehow if we keep using the plugin).

[reckart]

The POMs of the release versions may still contain references to SNAPSHOT versions, but they would be in profiles that are not activated by default.

I've been thinking about this. Currently, we have a profile called deps-not-on-maven-central in the ASL and GPL aggregator POMs. By default, this profile is disabled and causes:

• the modules not to be included in releases (to Maven Central)
• the modules not to be included in default builds

The reason is that all software that goes to Maven Central should also depend only on software available through Maven Central.

However, as you noted, this approach may overshoot the goal a bit because it also means that the Maven Release Plugin doesn't update the versions automatically during a release - we always have to set the versions of these modules to the next development version manually after a release.

Since the build shouldn't in general fail for the problematic modules because we include third-party repos in the POM for them, we shouldn't really need to exclude them from the build.

The desired effect of not having them be part of a Maven Release could be achieved by skipping the "deploy" phase for these modules.

However, if we do that, the auto-generated documentation still would include them. That means the documentation would contain references to artifacts not on Maven Central. If we could fix that somehow, then skipping deploy would probably be better than having modules live in a profile.