Sorry on the delayed response; PG-1472 should fix the version selector failing for packages with partially missing snapshot metadata, like maven-archetype-plugin, which was used to test.

Maven indexes are for search only, and don't have any sort of sensible ordering, so you won't see packages like you would on npm feeds.

I think your best bet is really going to be to use Universal Packages for this. That's what they're designed for, and the operations are much easier to use for it. We very recently updated our documentation to give some guidance on this: https://inedo.com/support/documentation/proget/core-concepts/packages NuGet is designed for .NET library files to be used in developing .NET-based software. Maven is similar, but Java; you should use Maven for packaging up Java code that Java developers will use to build other JAva applications. The applications themselves should be packaged in a universal format.

Looks like that's the wrong url; any url that starts with "/feeds" is for the UI only. Pl;ease use the "API Endpoint" URL specified on that same page intead.

Sorry but I run the indexer and it fails... Creating C:\ProgramData\ProGet\Packages.maven2\I22 if necessary. Opening C:\ProgramData\ProGet\Packages.maven2\I22\next-index.gz to write feed index. Writing local artifact info to feed index. Writing connector http://xcdeveljees2:8081/artifactory/novagalicia-repository artifacts to feed index. Unabled to open Lucene index for connector 31 Index generation complete.

We do not provide a migration utility or tool, but if you create one we would be happy to share it with the community.

According to the mvn deploy documentation, you'd need this in the POM file for the project: <distributionManagement> <repository> <id>myproget</id> <name>My ProGet Feed</name> <url>http://progethostname/maven2/feedname</url> </repository> </distributionManagement> If the feed requires authentication, you also need this in settings.xml (the <id> values have to match): <server> <id>myproget</id> <username>username</username> <password>password</password> </server> If you want your snapshot versions deployed to a separate feed, you can add a <snapshotRepository> to <distributionManagement> in the same format as <repository> above. After that, the command is just mvn deploy to upload the package to ProGet.

It's been quite a while since I last used Maven, but I think the POM file would look something like this: <project> ... <repositories> <repository> <id>mysite</id> <name>My Site - ProGet</name> <url>http://www.mysite.com/maven2/mf</url> </repository> </repositories> ... <dependencies> <dependency> <groupId>apackages</groupId> <artifactId>new-packages-jar</artifactId> <version>0.0.1</version> </dependency> </dependencies> ... </project>

Maven repositories are traditionally just file systems organized by convention, either local or exposed using a simple web server, so a lot of repos get this "for free" by just enabling directory listings for URLs. ProGet works a bit differently and simulates some of the traditional maven structure, so it's not necessarily trivial for us to implement this; that's not so say we can't do it, just that it wasn't deemed essential. While I don't think that this is formally part of any maven specification, a lot of other repositories do it, so it's been on our "maybe" list for some time; we just haven't had a lot of interest in it so far, so it hasn't made it onto the roadmap. We'll reevaluate what it would take to do it, and add it to the roadmap if we think it's something we can work in soon.

That's actually only a display issue with 4.7.10. The endpoint is still /maven2/. We've logged this as PG-1022.

Ok I figured out what I was doing wrong. I was setting the URL in build.gradle to: http://<user>:<password>@proget-server But it should look like this instead publishing { repositories { maven { credentials { username "$mavenUser" password "$mavenPassword" } url "http://proget-server" } } } With the mavenUser and mavenPassword being defined in ~/.gradle/gradle.properties

Apparently I was an idiot and couldn't do basic auth correctly, because once I did that correctly it worked fine without anonymous access involved. I am using Java 8, and the Authenticator class to set the authentication on my URL globally. Hope this helps the next person coming along.

Thanks for the bug report; this is fixed in v4.5.1, which was just released.

Started new question. Please answer there. Thank you

Thanks for the report - there is a new version available from the Extension Gallery (v4.1) that should resolve this.

It should work exactly as if you were running the command yourself as the user configured in the SSH agent in the working directory supplied in the Execute Command Line Action. What BuildMaster version are you running? We have just released 4.0.6 as a beta, but it's very close to becoming our official 4.0 release if you're interested in upgrading to it. Could you try to fully qualify the path to "asadmin" in the build script?