Maven Install Authentication Error

Hello. Trying to do some development and cant seem to get out of the gates. I have tried this on multiple networks so it does not appear to be network related.

When run “mvn clean install” in my newly created workspace, after successfully running “mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate -DarchetypeCatalog=http://maven.clouddev.snaplogic.com:8080/nexus/content/repositories/master

I get the following error.

Failed to read artifact descriptor for com.snaplogic:jutils:jar:4.22: Could not transfer artifact com.snaplogic:jutils:pom:4.22 from/to github (https://maven.pkg.github.com/SnapLogic/Tectonic): Authentication failed for https://maven.pkg.github.com/SnapLogic/Tectonic/com/snaplogic/jutils/4.22/jutils-4.22.pom 401 Unauthorized

Thoughts?

Hi @ronmwhite, yes we are aware of this and are preparing a fix. Unfortunately GitHub public packages still require authentication to download artifacts. We’ll have an update out soon with a corrective action.

1 Like

Hi @ronmwhite. When did you create your new project using the archetype? The 4.22 version of the archetype was just deployed yesterday. Do you recall whether you selected the 4.22 version of the archetype? Did you change anything else in the pom.xml that was created by the archetype?

If you used the 4.22 version of the archetype, and didn’t modify anything of significance in the pom.xml, please capture and share the exact command that you’re using to build and the output of that build.

Yes, I used the archetype and version 4.22 at that. Sorry, I already shared the commands in my original post - not sure what your looking for @ptaylor .

Note I am using the latest download of Maven and running directly from the terminal on my Mac. Per @robin this is a know issue but if you have a workaround please do share.

I think Robin was unaware that I had already updated and deployed the 4.22 Maven archetype.

I meant the command you used to build the project, not the command you used to clone the archetype. Was it just a ‘mvn clean install’ or similar? What I’m more interested in is the full output of that build. Can you please try ‘mvn clean install | tee build.out’ and then post build.out here?

You might first try temporarily using a clean local maven repo cache by doing this:

cd ~/.m2/
mv repository repository.save
mkdir repository

Then try your build.

I tried that yesterday (removing the repository) - trying again at this time. I will post the build.out.

Thank you. Also, please post your pom.xml. I want to make sure it looks right.

Please ignore my last (now deleted) post. I just ran again with -U. Sorry, not sure why I got that pom error. I will attach the latest pom and build.out. It still running at this time.

Thanks. This helps. Can you please check for the existence of two files that are used to access the new repository on github?

Is there a file named settings.xml at the root of the generated project? Does it define one server that looks like this?

  <id>github_SnapLogicDev</id>
  <username>thirdpartysnapdev</username>
  <!-- Public token with `read:packages` scope -->
  <password>&#50;&#53;&#49;&#55;...</password>

Is there a subdirectory named .mvn and a file in that called maven.config containing just this?

-s settings.xml

Here are the real files you asked for the first time along with settings.xml. Archive.zip (71.8 KB)

Ok, thanks. I posted that last reply before I realized you had asked me to ignore the last post.

Sorry, I’m a bit stumped by this and will need some time to find a solution. I appreciate your patience.

What exact command did you use to build the snap project?

I have tried many variations. Last one I did was mvn clean install -U. Before that it was mvn clean install -DskipTests=true. Originally it was just mvn clean install.

I have a basic understanding of the issue but it will take until some time tomorrow (at the earliest) to resolve, as it’s necessary to patch some of the poms associated with our platform dependencies. I’m still not clear on why our testing didn’t encounter the same issue. My apologies for the difficulties, and thanks again for your patience.

@ptaylor I got the build to succeed. To do this, I removed my local Maven (downloaded from Apache originally) and added it again via brew install maven. That did not work by itself.

But then, I changed my JAVA_HOME from adoptopenjdk-11.jdk to the jdk that came with Maven as part of the Brew install - Open JDK 14.0.1. When I did that, mvn clean install -DskipTests=true worked.

Perhaps JDK 14 is somehow required by Maven 3.6.3 (Brew seems to think so in any case). Regardless, thanks for the support here. Note, the Snap Development Documentation still references JDK 8. I am assuming that Adopt Open JDK 11 will work for development tho as that is what we had to install on our snaplex for 4.22 recently.

Let me know if you have any thing to add on that or any additional questions. Thanks again.

That’s very interesting. I’m going to test if switching the Java version makes a difference. I’ve been testing with Java 8.

We did discover some issues with the root pom for the platform artifacts ( com.snaplogic.Tectonic:4.22.8124 at Package com.snaplogic.Tectonic · SnapLogicDev/sdk · GitHub). That was referencing some incorrect versions and repositories. We’ll have a new version of that pom deployed shortly which corrects those issues.

Hi @ronmwhite,

We’ve deployed a set of patches to address this issue. Please update these two properties in your project’s pom:

    <snaplogic.platform.version>4.22.8138</snaplogic.platform.version>
    <snaplogic.snaps.version>4.22.6586</snaplogic.snaps.version>

As for Java version: No, Maven 3.6.3 will definitely work fine with Java 8, and for now, it’s best to build your snap project with Java 8. Yes, most production plexes should now running snaps with Java 11, but won’t really be fully ready to develop snaps with Java 11 until the next release in November.

Please let me know if you have any further questions or concerns.

I just built from scratch using JDK 8 and SnapArchetype version: 4.22.1. No issues to report. Thanks again for the support.

1 Like