microsoft / vscode-maven

VSCode extension "Maven for Java"
https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-maven
Other
183 stars 89 forks source link

Remove hardcode reference to maven central for offline use #410

Open scandinave opened 5 years ago

scandinave commented 5 years ago

Suggestion

Add an option to use archetype from a custom private repo like nexus.

Use Cases

Working offline, i'm unable to generate project from archetype inside VSCode

criskurtin commented 5 years ago

This one would be very useful. I just built a custom archetype and tried using it from scratch (removing it from .m2 and pulling it from nexus), but then I realized I can't add custom archetype catalog URL.

Eskibear commented 5 years ago

A setting (e.g. maven.archetype.catalogUrl) would work, with a default value of the maven central.

Note that according to current implementation, metadata of archetypes are retrieved and saved to a local .json file. After you change the value, you have to run "Update archetype catalog" to fetch and generate the metadata. And that means you cannot list archetypes of two catalogs together (e.g. maven central and your private nexus repo).

I imagine that a setting maven.archetype.catalogUrls (supporting multiple catalogs), would be more help, if possible.

Eskibear commented 4 years ago

First thank @scandinave for creating PR #412 , providing the solution with the new setting mentioned above.

After I add a nexus repo into the vscode settings, it does list the archetypes from a custom catalog. But I cannot simply create a project because the nexus repo is not specified in my settings.xml. And if there's inconsistency between vscode settings and Maven settings.xml, things would get wired, especially for a user who's not as experienced as you guys.

So I'm thinking if we should read the available catalogs from Maven settings.xml, e.g. by executing mvn help:effective-settings. So there would be only one source of truth. @polardegausser @scandinave what do you guys think? which one would be more helpful?

criskurtin commented 4 years ago

Hi,

I created the PR :) I think that the approach with Maven's settings.xml file is a good path to follow. I did the #412 as a quickfix since I needed this feature for my job and I definitely don't want to fallback to Eclipse just because of this missing link. I like the simple workflow I set up for myself in VSCode for Java.

I can try implementing this by iterating through repositories from settings.xml (I assume most of the logic for doing this is already available in the current source) and downloading archetype catalog from every [repo_url]/archetype-catalog.xml. This way users won't need to specify anything separately, instead we can rely on maven. Of course, the question is then, does the user want to see archetypes from all of the remote repositories? For example, I might have some additional repos added for dependencies but not for their archetypes, the list might get very large.

Eclipse, for example, also has these two things decoupled. Repos are listed in settings.xml, but remote archetype catalogs need to be added separately in Window -> Preferences -> Maven -> Archetypes. The only thing that might be different (I need to verify this) is that Eclipse does this through GUI dialog box which might not let you save a catalog for which an artifact cannot be reached.

scandinave commented 4 years ago

@Eskibear i think only one source of truth is the right way. But this need to be well documented, so user can quickly understand how this work.

Eskibear commented 4 years ago

@polardegausser Sorry I mentioned the wrong guy. For the moment, I'm ok with the "quickfix" implementation you created, as long as you guys think it unblocks you and it's helpful enough. My only concern is that, if we add the setting and remove in later versions, how to ensure the users not to suffer from a regression issue? (e.g. you've add an extra vscode setting for custom catalogs, and later after upgrading the extension, it suddenly doesn't work because you haven't added them in settings.xml)

the question is then, does the user want to see archetypes from all of the remote repositories? For example, I might have some additional repos added for dependencies but not for their archetypes, the list might get very large.

Users can simply type some keywords to filter the archetypes, I think "the archetype is not in the list" is blocking, but "there are so many items that it's hard for me to find what I need" is not blocking. Currently the list is already very large as it lists all archetypes from Maven Central, and I don't think additional repos are as large as the Central. And since the list is already very large, users always have to type some keywords first ...

thandy1212 commented 4 years ago

This should also be expanded into dependency autocomplete, so when your settings.xml has a mirror to force all downloads to from a specific repository (e.g. internal company repository manager) the autocomplete suggestions only correspond to dependencies in the mirror.

eiki25 commented 3 years ago

A setting (e.g. maven.archetype.catalogUrl) would work, with a default value of the maven central.

Note that according to current implementation, metadata of archetypes are retrieved and saved to a local .json file. After you change the value, you have to run "Update archetype catalog" to fetch and generate the metadata. And that means you cannot list archetypes of two catalogs together (e.g. maven central and your private nexus repo).

I imagine that a setting maven.archetype.catalogUrls (supporting multiple catalogs), would be more help, if possible.

A setting (e.g. maven.archetype.catalogUrl) would work, with a default value of the maven central.

Note that according to current implementation, metadata of archetypes are retrieved and saved to a local .json file. After you change the value, you have to run "Update archetype catalog" to fetch and generate the metadata. And that means you cannot list archetypes of two catalogs together (e.g. maven central and your private nexus repo).

I imagine that a setting maven.archetype.catalogUrls (supporting multiple catalogs), would be more help, if possible.

Update Maven Archetype Catalog creates a 1kb archetypes.json with no entries. When is new achetypes.json released?

Eskibear commented 3 years ago

@eiki25 It's a regression issue also reported in https://github.com/microsoft/vscode-maven/issues/611 . We'll fix it in next release, and update embedded archetypes.json to lastest version.

Doctornunu commented 3 years ago

@eiki25 It's a regression issue also reported in #611 . We'll fix it in next release, and update embedded archetypes.json to lastest version.

Second this. There's no issue creating a project from third party archetypes via the built in terminal window, but no way to do it through the gui. This becomes a problem for our engineers that write very simple projects and are used to coding in Eclipse (IE, never touched a terminal)

@polardegausser Sorry I mentioned the wrong guy. For the moment, I'm ok with the "quickfix" implementation you created, as long as you guys think it unblocks you and it's helpful enough. My only concern is that, if we add the setting and remove in later versions, how to ensure the users not to suffer from a regression issue? (e.g. you've add an extra vscode setting for custom catalogs, and later after upgrading the extension, it suddenly doesn't work because you haven't added them in settings.xml)

the question is then, does the user want to see archetypes from all of the remote repositories? For example, I might have some additional repos added for dependencies but not for their archetypes, the list might get very large.

Users can simply type some keywords to filter the archetypes, I think "the archetype is not in the list" is blocking, but "there are so many items that it's hard for me to find what I need" is not blocking. Currently the list is already very large as it lists all archetypes from Maven Central, and I don't think additional repos are as large as the Central. And since the list is already very large, users always have to type some keywords first ...

I don't see an issue with appending locally specified archetypes to the drop down list, searching with keywords makes it easy enough.