You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@netbeans.apache.org by "ebarboni (via GitHub)" <gi...@apache.org> on 2023/04/27 13:09:47 UTC
[GitHub] [netbeans] ebarboni opened a new pull request, #5893: small move to a more explicit "protocol" for libraries
ebarboni opened a new pull request, #5893:
URL: https://github.com/apache/netbeans/pull/5893
This is a lot's of files changes pr but the only intention is to explicit mark the protocol we use.
It's a rewrite according 2 protocol of binaries-lists files
using
"MC" maven central
"LEGACY" osuol link
others ideas;
"MAVEN" not implemented, intend is to later add a more complex maven part to be able to have repository link apache snapshots or staged like launcher/ installer to be built on master for better testing. (keeping it Apache so it's on our control staged have controled lifecycle, apache snapshots are volatile but jobs build them on a controled way (each day minimum)) (SAFE to perma build, but should not be present on final release)
"NPM" I see that maybe we could have npm artefacts instead of putting the zip to osuosl
Maybe others like sourceforge, github download but not sure the policy of them having lots of build download.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] mbien commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1544027192
> For local testing, we could also consider making hash check just a warning for local file: URL? That can't accidentally work elsewhere.
this would be great. A lot of weird things happened when I tried to *not* use binaries-list for local testing. E.g the build failed because complaining that jars had the same name but different content or something similar. So I ended up writing a script which uploads a jar somewhere so that i can use continue using binaries-list.
Ideally I want to point it at the jar in the target folder of a maven project and it should be picked up for local testing. I might be doing something wrong but It never worked properly for me.
any ideas for making library upgrades less manual work?
https://github.com/apache/netbeans/pull/5679/commits/d7118e8ff41bc27db071aa5a48269e51933706ee
this is too much IMO. This all has to be updated manually and someone has to review this too. (speaking of which: a new maven release just went out today.
Why does it have to be: properties + xml + binaries-list? Can't it be only the xml for the easy cases? (I understand that a zip is a special case which would require an extra step)
I also don't understand why we have to check the hashes of the zip, and then again for every jar.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1564265164
thanks for the feedback. I close this one and may later use some info on the website.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] neilcsmith-net commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "neilcsmith-net (via GitHub)" <gi...@apache.org>.
neilcsmith-net commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1543983416
> purl or xml could be done. I've no preference. purl parsing could be implemented as replacement of current parsing with more adhoc restriction. Not every protocol, not every repo.
Definitely only the packagers we want to support, and we'd need a resolver for each.
Making everything a URL is a plus, as we can parse everything as a URI as first step. I'm happy to look at writing resolution for Maven (well, reusing what I already have), if that's where we do want to go?
> Concerning maven, I don't understand the need to put hash aside as they are in repo.
So we'd need to special case downloading the hash file as well to check the download? And we'd lose the other benefits of the hash being stored at our end - extra check for security, developer using local repo, etc.?
> At the moment, to have launcher fix, or installer fix you need to fix hash for every adjustment.
Yes, but why is that a problem? Add new hash and direct file link in to draft PR each time we need to need to test an update. It's how nb-javac and other PRs have been tested. We can provide `ci:dev-build` for additional testing.
For local testing, we could also consider making hash check just a warning for local `file:` URL? That can't accidentally work elsewhere.
Neither of those should ever get near the master branch - master should always be in a releasable state.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] matthiasblaesing commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "matthiasblaesing (via GitHub)" <gi...@apache.org>.
matthiasblaesing commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1528030926
If we really touch the format of the binaries-list file format, we should also make it extensible regarding supported hashing algorithms. @emilianbold started the work here, but never finished:
https://github.com/apache/netbeans/pull/1260
We could switch to XML (yeah I know, clunky, but at least not the latest hot shit, established in the code base, extensible).
For the download location we need to be careful:
a) for the two main sources (maven central and netbeans.osuosl.org) you can override the download server and use a local proxy for example
b) the current URLs and download location are pretty stable, we should not add unnecessary download locations, where we can't predict stability
The purl-spec looks intersting, of course it leaves enough room for breakage, not specifying how to handle different repositories (we may assume `maven` === `maven central`).
For SNAPSHOTS: It is not true, that snapshots change hash (at least on the sonatype staging repository). Consider this:
https://oss.sonatype.org/content/repositories/snapshots/net/java/dev/jna/jna/5.12.0-SNAPSHOT/jna-5.12.0-20220609.181817-3.jar
this is the third snapshot I created for the then upcoming 5.12.0 version. Of course this is only as stable as your repository makes it. So IMHO this is already a fixed case.
The
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] matthiasblaesing commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "matthiasblaesing (via GitHub)" <gi...@apache.org>.
matthiasblaesing commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1526053981
I'll look into this later, but at this point in time, you can trivially use an URL in binaries-list. We support three different sources:
- download from osuosl (simple name entry)
- download from maven central (groupid, artifactid, version, type seperated by colon)
- download with a full url (URL + local filename)
The final case was added because the gradle zip is not available from central: https://github.com/apache/netbeans/blob/690b4271020b307ec3a4bcb056230f7a01a955ae/extide/gradle/external/binaries-list#L18
This was already successfully tested when I updated the httpparser for example. I pushed the new http parser binary to my private server and then let github action download it from there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] mbien commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1526047678
being able to use apache staging would be useful in some cases. I had a few situations when someone asked me something like "the change is in the staged upstream lib, can you test it?". And the "easiest" way to test it was to build it locally, remove the entry from binaries-list and load it from disk. Would have been nice to open a draft lib-update PR (add the dev-build label) and simply run tests with it (but before merge, wait for GA and change the dependency to central obviously).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] matthiasblaesing commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "matthiasblaesing (via GitHub)" <gi...@apache.org>.
matthiasblaesing commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1544561716
Regarding library updates:
Yes they suck, but not because you need to update two or three files. You have to check licenses and notices anyway, so changing our integration only slightly lightens the burden. The files are also not all equal:
- `*-licenses.txt`, `*-notice.txt`: They need to be check on _every_ update
- `binaries-list`: covers downloads, nothing more. These might be bundled libraries, but often enough they are also compile time dependencies that are not bundled
- `project.properties`: References files that are to be copied by the build system. These are not necessarily downloaded, but also could be part of regular sources
- `project.xml`: The project file is independed of the build system, but tied to the ant based project type, so we can't tie it to the binaries list
- `build.xml`: This is highly dependend on the project type. Some project rebundle files or fix issues in downloaded binaries, so little sharing there
- `ignoried-overlaps`: Well, we can discuss whether or not this helps
- `binariesembedded-list`: If I remember correctly this is, so that we don't push our binaries to maven central and instead reference the maven bits.
So all in, there is little to gain and the referenced (embedded maven) is very near a worst case scenario. Yes it is not nice, but also less painful, than changing the bits, that make up this net.
The hashes in `binaries-list` have to stay as they double as integrity checks.
If the need is to create a list of all URLs that would be downloaded, it would IMHO better to create a task for that in the build system, as that would also be able to consider the cluster that is being build and thus giving "the right" list.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] neilcsmith-net commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "neilcsmith-net (via GitHub)" <gi...@apache.org>.
neilcsmith-net commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1528074660
> The purl-spec looks intersting, of course it leaves enough room for breakage, not specifying how to handle different repositories (we may assume `maven` === `maven central`).
This is covered at https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst#known-qualifiers-keyvalue-pairs
It also has a standard key value for checksums.
Not saying it's necessarily the right way, but if we're looking to encode for different package sources, it would be good to look at existing and fairly widely used options. I've been using for a while in something else.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1527560459
Well for SNAPSHOT on snapshots repos you can't rely on hash, you should have different way. A reviewer looking for PR the next day will have a different hash. And it could be fine to build !release branch with some identified snapshots for having time to review.
non maven central dependencies with some triage but not yes finished
https://cwiki.apache.org/confluence/display/NETBEANS/dependencies
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] mbien commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1526103555
one little annoyance with the current system is that the version numbers are everywhere, in the project xml, in the properties path, in the binaries-list file, + more.
even simple lib upgrades have to touch a lot of files:
https://github.com/apache/netbeans/pull/5751/commits/ea4e57043db5332b359de3b315c3735ae2994e47
but I don't know an elegant way to improve this without putting too much time into this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] mbien commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1527956147
(in my case it wasn't about SNAPSHOT, it was about a staged library during a vote, before it would go GA)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1544295284
This was to remove 20-30 artefacts that were republished on external maven subfolder because of unlisted hash
(i.e maven 3.0.5 arftefact https://netbeans.apidesign.org/maven2/org/netbeans/external/ or 3.3.9 )
Some are republished because we alter them some are osuol repackage.
I do not remember exacly but nb-javac was a jar in PR until release. Doing the same for launcher will cost a vote if I understand completly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni closed pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni closed pull request #5893: small move to a more explicit "protocol" for libraries
URL: https://github.com/apache/netbeans/pull/5893
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] neilcsmith-net commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "neilcsmith-net (via GitHub)" <gi...@apache.org>.
neilcsmith-net commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1544087458
> Ideally I want to point it at the jar in the target folder of a maven project and it should be picked up for local testing. I might be doing something wrong but It never worked properly for me.
At the moment the only scheme supported for URLs is https I believe.
You can `mvn install` and prefer the local repo though - see #2710
> any ideas for making library upgrades less of a chore? [d7118e8](https://github.com/apache/netbeans/commit/d7118e8ff41bc27db071aa5a48269e51933706ee) this is too much IMO. This all has to be updated manually and someone has to review this too. (speaking of which: a new maven release just went out today.
>
> Why does it have to be: properties + xml + binaries-list? Could we inline everything into the project.xml, so that only one place needs updates? (I understand that a zip is a special case which would require an extra step)
Possibly worth looking at #2043 Any change of Maven coordinate syntax will have to take that into account I guess @ebarboni ? I would have thought the zip contents file could be generated by the build though?
The classpath XML is a pain - have that in another project - maybe we could introduce wildcard support in that?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1543872907
purl or xml could be done. I've no preference. purl parsing could be implemented as replacement of current parsing with more adhoc restriction. Not every protocol, not every repo.
Concerning maven, I don't understand the need to put hash aside as they are in repo.
As mentioned snapshot dependent on state of repo (hash may change)
staged repo are fixed tag hash is fixed
central repo hash is fixed.
At the moment, to have launcher fix, or installer fix you need to fix hash for every adjustment. At the end you need a staged repo to make it works and vote need to pass before release otherwise you are out for next build.
This is more a concern for native launcher,installer + profiler. They are our code, but cannot be osuol as it's should be released.
Maybe others externals may benefit of that.
And maybe npm could help for node related stuff.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] neilcsmith-net commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "neilcsmith-net (via GitHub)" <gi...@apache.org>.
neilcsmith-net commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1525743340
Personally, if we're looking to make a change like this I'd move everything to use URL's. And use package URL for Maven, NPM, etc.
See https://github.com/package-url/purl-spec You can see them in use on the central search - eg. https://central.sonatype.com/artifact/org.netbeans.api/org-openide-nodes/RELEASE170 has pkg:maven/org.netbeans.api/org-openide-nodes@RELEASE170
I'm wary of using Maven snapshots in that way - direct download URL or using the Maven repo setting might be better?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[GitHub] [netbeans] ebarboni commented on pull request #5893: small move to a more explicit "protocol" for libraries
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni commented on PR #5893:
URL: https://github.com/apache/netbeans/pull/5893#issuecomment-1525993732
Nice idea.
Not sure to have the understanding of npm, as some modules like typescript-editor generate subfolder in netbeans.
But they are not taken into modules nbm a bit confused at the moment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists