Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maven Repo is shut down: bean-test not available anymore #29

Open
StefanKock opened this issue Jul 27, 2022 · 6 comments
Open

Maven Repo is shut down: bean-test not available anymore #29

StefanKock opened this issue Jul 27, 2022 · 6 comments

Comments

@StefanKock
Copy link

StefanKock commented Jul 27, 2022

This week the repo where bean-test is hosted was shut down. This lets users hanging around without able to automatically download bean-test anymore.

There is already a start with 9cb29eb to publish the artifact on Github Packages but it's not finished.

Possible Solution

Please provide the existing artifact info.novatec:bean-test:0.2.Final on a publicly available repository like Maven Central (howto: https://dzone.com/articles/how-to-publish-artifacts-to-maven-central).

Workarounds for users

Summary possible workaround (partly under investigation).

1. Deploy to Maven Central as fork

Looks straightforward, but probably only Novatec can do this for the original artifact due to Maven Central checking ownership over the groupId. So it would be needed to fork, rewrite the groupId and then deploy to Maven Central.

2. Use Github Packages

Was started with 9cb29eb (thanks for that), can also be done with a self-maintained fork. But a downside is that Github Packages requires token authentication also for public repos (doc here: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry). Setting secrets in every users settings.xml might not be ideal.

A workaround would be to write credentials into the pom.xml

<repository>
   <id>BeanTest</id>
   <name>BeanTest Repository</name>
   <url>https://username:[email protected]/OWNER/REPO</url>
   <!-- Contains access token to download from Github Packages (and only for that use case) -->
</repository>

Update: The approach with username:accesstoken is prevented by Github (actually, a good sign that hardcoded credentials don't work on Gihub :-) ): A recent scan found a valid GitHub Personal Access Token linked to your GitHub account in commit at ...

3. Provide bean-test with system scope

Upload the existing jar into a maven project and link it with

			<dependency>
				<groupId>info.novatec</groupId>
				<artifactId>bean-test</artifactId>
				<version>0.2.Final_Local</version>
				<scope>system</scope>
				<systemPath>${project.basedir}/../sormas-base/dependencies/bean-test-0.2.Final.jar</systemPath>
				<!-- Changed scope "test" to "system" as workaround for currently no publicly available maven artifact -->
			</dependency>

			<!-- Dependencies of bean-test that are missing without the POM -->
			<dependency>
				<groupId>org.jboss.weld.se</groupId>
				<artifactId>weld-se</artifactId>
				<version>2.1.2.Final</version>
				<scope>test</scope>
			</dependency>
			<dependency>
				<groupId>org.apache.deltaspike.core</groupId>
				<artifactId>deltaspike-core-impl</artifactId>
				<version>1.2.1</version>
				<scope>test</scope>
			</dependency>
			<dependency>
				<groupId>org.apache.deltaspike.cdictrl</groupId>
				<artifactId>deltaspike-cdictrl-weld</artifactId>
				<version>1.2.1</version>
				<scope>test</scope>
			</dependency>

Problem with this approach: Changing the scope lets transitive dependencies like deltaspike or weld not be part of the Classpath because there is no POM linked to lookup dependencies. I documented dependencies that I needed to add, but in depends on the use case.

Doc: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#system-dependencies

@carlosbarragan
Copy link
Member

Hi @StefanKock

sorry that this happened to you. We were not aware that the project was being used in this way. Actually I am positively surprised that the project is being used nowadays as its general purpose back then was only to showcase an alternative for testing Java EE applications.

The bad news is that our maven repo will be offline forever. We decided to shut it down for good.

The good news is that, as you could already see, we started working to provide another alternative. I cannot tell you a timeline when this will be ready. BTW, we are open to contributions in that regard 😉

Regards,
Carlos

@StefanKock
Copy link
Author

Hi @carlosbarragan,

thanks for you quick try, I saw it and we followed up on it. We made the approach with Github Packages running, see hzi-braunschweig@8f0cb57 to publish version 0.2.0.Final . But the inconvenience with mandatory credentials is too annoying, and hardcoding the login to basically all public Github Packages repositories is probably a bit too extreme.

My current approach is to deliver a workaround for my project, but I would really appreciate a publicly hosted artifact under the original maven coordinates.

@StefanKock
Copy link
Author

We now went with the system scope approach as workaround.

@carlosbarragan
Copy link
Member

carlosbarragan commented Jul 28, 2022

We are still evaluating whether we publish it to maven or we follow the approach of using GitHub as a maven Repository: https://gist.github.com/fernandezpablo85/03cf8b0cd2e7d8527063

I also noticed some dependencies are really old and have vulnerabilities so it would be a good idea to update them. I also think that JDK 11 as baseline would be appropriate. However, I don't know if Java 11 and the dependencies update could affect your project because of version conflicts etc.

@StefanKock
Copy link
Author

The idea to use the Github repo tree as Maven Repository looks as an option (if it works but looks like it), but still less straight forward than Maven Central.

I think updating to JDK 8 is probably a must if one would go into the topic updating dependencies. If JDK 11 is mandatory on the update path than it may be. But it would probably be helpful to publish a version compatible to 0.2.Final and keep dependency updates indipendent for a follow-up version.

@carlosbarragan
Copy link
Member

The "problem" with Maven Central is that it takes longer because of the requirements that need to be fulfilled. Besides, I don't know if they would easily accept an artefact that contains old dependencies with vulnerabilities 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants