Re: [QUESTION] KIE - NPM package names
Thanks for the additional information, Tison! Really appreciate it. Certainly right after the release this will be a top priority for me. The Apache KIE project publishes a lot of artifacts to a lot of different places, so this is all a little bit overwhelming to do for a first release. I'm glad the incubator allows for it to be done at a slower pace. I already adjusted the names of all our VS Code and Chrome extensions, and they all will contain a DISCLAIMER at the end of their descriptions. The publisher names will change from "KIE" to "Apache KIE™ (incubating)", and point to https://kie.apache.org/. The WebJar's groupId unfortunately is not something we can change, as the "WebJars" project is an automated thing that will take packages from NPM and publish them to Maven. I guess for the next releases we can either 1) Stop using this "WebJars" mechanism altogether and publish a regular jar; or 2) Change our NPM package name to "apache-kie-sonataflow-deployment-webapp" (Can't use scopes on this one). This would produce the "org.webjars.npm:apache-kie-sonataflow-deployment-webapp:[version]" GAV. I'd rather do option 1, though. As for the VS Code Extensions themselves, absolutely we can use this deprecation strategy. It's a shame we'll lose the download counts (again), as these extensions started being published by Red Hat, then moved to KIE, and now are moving to Apache :) Nothing that a good README and nice deprecation messages can't help solve, though, I hope. Regarding the NPM packages, I guess that @apache/kie-*, @apache-kie/*, or apache-kie-* all are idiomatic enough. It's a common thing that projects start from an "unscopped" name to later on have a lot of packages and therefore start using a scope. Since we already have a fair amount of them, I guess we can really take advantage of the scopes from the beginning, except for those package that absolutely can't have a scope, like VS Code Extensions. Sorry for the lengthy email, and thanks again for the messages you sent. Really helped build our confidence in going for a first release. Regards, Tiago Bento On Thu, May 16, 2024 at 5:42 PM tison wrote: > > Hi Tiago, > > > How? Every package we ever published to NPM under KIE is owned by > > https://www.npmjs.com/~kie-tools-bot now (some of them were > > removed/renamed). We can give control to the ~theasf user, no problem. > > You can open an INFRA JIRA ticket like [1]. > > [1] https://issues.apache.org/jira/browse/INFRA-25325 > > > if this could be postponed to the next release, it would be great. > > I listed the suggestion in priority (desc order), so it's OK that your > first release keeps this @kie namespace, especially since Kie's trademark > is (to be) transferred to the ASF. However, @apache/kie-xxx is more > appropriate and I'll appreciate it if you can arrive there in the following > releases. You may think of ASF Java packages that are released with > org.apache. group id. I hope the NPM scope is the idiom that > accomplishes the same thing on that platform. > > > Renaming it would mean essentially creating new extensions, without any > relationship to the old ones whatsoever. > > From my experience using VS Code extensions, it should be possible to > deprecate the old extension and suggest a successor extension in the README. > > If you'd release those VS Code extensions under the existing name for now, > I'd suggest the following things to improve: > > 1. State the relationship between the extension and Apache KIE™ > (Incubating) in the README. > 2. Update the description and the display name of the owner account "KIE" > [2]. > > I may prefer to work with ASF INFRA to register an official ASF account to > own these extensions, but the INFRA team may have a different opinion since > they may not manage all the accounts among all release channels. You should > try to reach out to them. > > [2] https://marketplace.visualstudio.com/publishers/kie-group > > To be clear, these are the first few improvement items that came to mind. > But they may not be all you can or should do. > > > If you type "sonataflow" in the search input at the right-hand-side > > you'll see that a JAR was published based on the NPM package. See > > I think it's generally possible to move the group ID to org.apache.kie. > > Best, > tison. > > > Tiago Bento 于2024年5月17日周五 03:55写道： > > > Thanks all for the replies. > > > > I'll try to postpone renaming the packages we have today, so we'll > > start the release vote without this renaming. All packages will > > include the DISCLAIMER in their README files. E.g., > &
Re: [QUESTION] KIE - NPM package names
Thanks all for the replies. I'll try to postpone renaming the packages we have today, so we'll start the release vote without this renaming. All packages will include the DISCLAIMER in their README files. E.g., https://github.com/apache/incubator-kie-tools/blob/main/packages/dmn-editor/README.md I hope that's ok for a first incubator release. We'll address any feedback we receive on the voting thread. Of course, for the next release I'll have a plan for renaming all Apache KIE (incubating) NPM packages and for publishing them under ~theasf, and @apache or @apache-kie scopes. Thanks again for your input. Regards, Tiago Bento On Wed, May 15, 2024 at 4:36 PM Dave Fisher wrote: > > Here’s my 2 cents. > > Incubation is a journey, and if there are parts that are yet to be compliant > that should be fine. In the end all will be squared away. > > For the IPMC - should we have something like DISCLAIMER-WIP for binary > convenience packaging? > > Best, > Dave > > > On May 15, 2024, at 1:13 PM, Tiago Bento wrote: > > > > Tison, > > > > Thanks for the reply! > > > > On Wed, May 15, 2024 at 1:43 PM tison > <mailto:wander4...@gmail.com>> wrote: > >> > >> We have an official account on NPM [1] and the associated org [2] (cc @Mark > >> Thomas IIRC who manages this account). > >> > >> [1] https://www.npmjs.com/~theasf > >> [2] https://www.npmjs.com/org/apache > >> > >> Both of these associations can improve the verification and brand for your > >> release, while you may use the @apache scope in your package's name to > >> replace the handy apache- prefix that isn't endorsed by NPM's mechanism. > >> > >> For the name and branding topic, I would suggest (in priority): > >> > >> 1. State your display name as Apache KIE™ (incubating) on the release page > >> (README). > > Ok. > > > >> 2. Build an association with our official NPM organization, following NPM's > >> mechanism. > > How? Every package we ever published to NPM under KIE is owned by > > https://www.npmjs.com/~kie-tools-bot <https://www.npmjs.com/~kie-tools-bot> > > now (some of them were > > removed/renamed). We can give control to the ~theasf user, no problem. > > > >> 3. Change your package name (handle) to @apache/kie-xxx. > > This is what I'd like to avoid, as it's going to be major work on our > > side due to the number of packages we have, delaying our release even > > more... I see OpenDAL has some packages published under the `opendal` > > and `@opendal/*` names, which is kind of analogous to what we'd have > > without renaming. Of course we can move everything to @apache/kie-* or > > @apache-kie/* to comply with the guidelines and requirements, but if > > this could be postponed to the next release, it would be great. > >> > >> As for the VS Code Extensions, I'm unfamiliar with this scope, but it seems > >> there are other names like "kogito". What are the relations between them > >> and KIE? > > Drools, jBPM, SonataFlow, OptaPlanner, Kogito, and Tools are all > > components inside KIE. All KIE VS Code Extensions are already > > published under these names I listed. Renaming it would mean > > essentially creating new extensions, without any relationship to the > > old ones whatsoever. Example: > > https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension > > > > <https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension> > > > >> > >> As for the WebJar, I'm unfamiliar with this scope also. And I don't find an > >> entry called sonataflow-deployment-webapp on the page you linked. > > If you type "sonataflow" in the search input at the right-hand-side > > you'll see that a JAR was published based on the NPM package. See > > https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp > > > > <https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp> > > > >> > >> The official name of an ASF project is always Apache Foo [3], and we should > >> use this name when possible. > > Ok. > > > >> > >> [3] https://www.apache.org/foundation/marks/guide > >> > >> Best, > >> tison. > >> > >> > >> Tiago Bento 于2024年5月16日周四 00:43写道： > >> > >>> Shawn, > >>> > >>> Does that mean you didn't publish an
Re: [QUESTION] KIE - NPM package names
Tison, Thanks for the reply! On Wed, May 15, 2024 at 1:43 PM tison wrote: > > We have an official account on NPM [1] and the associated org [2] (cc @Mark > Thomas IIRC who manages this account). > > [1] https://www.npmjs.com/~theasf > [2] https://www.npmjs.com/org/apache > > Both of these associations can improve the verification and brand for your > release, while you may use the @apache scope in your package's name to > replace the handy apache- prefix that isn't endorsed by NPM's mechanism. > > For the name and branding topic, I would suggest (in priority): > > 1. State your display name as Apache KIE™ (incubating) on the release page > (README). Ok. > 2. Build an association with our official NPM organization, following NPM's > mechanism. How? Every package we ever published to NPM under KIE is owned by https://www.npmjs.com/~kie-tools-bot now (some of them were removed/renamed). We can give control to the ~theasf user, no problem. > 3. Change your package name (handle) to @apache/kie-xxx. This is what I'd like to avoid, as it's going to be major work on our side due to the number of packages we have, delaying our release even more... I see OpenDAL has some packages published under the `opendal` and `@opendal/*` names, which is kind of analogous to what we'd have without renaming. Of course we can move everything to @apache/kie-* or @apache-kie/* to comply with the guidelines and requirements, but if this could be postponed to the next release, it would be great. > > As for the VS Code Extensions, I'm unfamiliar with this scope, but it seems > there are other names like "kogito". What are the relations between them > and KIE? Drools, jBPM, SonataFlow, OptaPlanner, Kogito, and Tools are all components inside KIE. All KIE VS Code Extensions are already published under these names I listed. Renaming it would mean essentially creating new extensions, without any relationship to the old ones whatsoever. Example: https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension > > As for the WebJar, I'm unfamiliar with this scope also. And I don't find an > entry called sonataflow-deployment-webapp on the page you linked. If you type "sonataflow" in the search input at the right-hand-side you'll see that a JAR was published based on the NPM package. See https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp > > The official name of an ASF project is always Apache Foo [3], and we should > use this name when possible. Ok. > > [3] https://www.apache.org/foundation/marks/guide > > Best, > tison. > > > Tiago Bento 于2024年5月16日周四 00:43写道： > > > Shawn, > > > > Does that mean you didn't publish anything to NPM as part of your > > releases while in the incubator? > > > > On Wed, May 15, 2024 at 12:31 PM Shawn Yang > > wrote: > > > > > > Hi Tiago, > > > > > > From the current incubator release policy, you need to rename all npm > > > packages to apache-xxx before releasing. The packages released before > > > should be on to left intact. > > > > > > I came across same issue when we release apache fury. In your case, most > > > packages starts with kie. Fury has similar rules which starts with > > furyjs. > > > Rename to apache-xxx has many works to do and breaks the compatibility > > with > > > downstreams. So fury just skipped release binary packages for fury > > > JavaScript. > > > > > > I was wondering whether the incubator release policy remove such name > > > rules. It does introduce extra work and confusion to podlings. And It's > > not > > > idiomatic in npm. Similar confusion exists for Python wheels. In Python, > > > the naming needs to be consise and be as short as possible. We barely > > see a > > > wheel in a organization name wheel as $orgname-xxx. > > > > > > > > > > > > On Wednesday, May 15, 2024, Tiago Bento wrote: > > > > > > > Hi general@incubator, > > > > > > > > The distribution guidelines [1] say packages published to NPM should > > > > be named `apache-`, however, at KIE, we have a somewhat big > > > > set of packages that are published under these scopes: > > > > - @kie-tools/* > > > > - @kie-tools-core/* > > > > - @kie-tools-scripts/* > > > > > > > > There are also some VS Code Extensions (which can't have a scope): > > > > - yard-vscode-extension > > > > - swf-vscode-extension > > > > - pmml-vscode-extension > > &
Re: [QUESTION] KIE - NPM package names
Shawn, Does that mean you didn't publish anything to NPM as part of your releases while in the incubator? On Wed, May 15, 2024 at 12:31 PM Shawn Yang wrote: > > Hi Tiago, > > From the current incubator release policy, you need to rename all npm > packages to apache-xxx before releasing. The packages released before > should be on to left intact. > > I came across same issue when we release apache fury. In your case, most > packages starts with kie. Fury has similar rules which starts with furyjs. > Rename to apache-xxx has many works to do and breaks the compatibility with > downstreams. So fury just skipped release binary packages for fury > JavaScript. > > I was wondering whether the incubator release policy remove such name > rules. It does introduce extra work and confusion to podlings. And It's not > idiomatic in npm. Similar confusion exists for Python wheels. In Python, > the naming needs to be consise and be as short as possible. We barely see a > wheel in a organization name wheel as $orgname-xxx. > > > > On Wednesday, May 15, 2024, Tiago Bento wrote: > > > Hi general@incubator, > > > > The distribution guidelines [1] say packages published to NPM should > > be named `apache-`, however, at KIE, we have a somewhat big > > set of packages that are published under these scopes: > > - @kie-tools/* > > - @kie-tools-core/* > > - @kie-tools-scripts/* > > > > There are also some VS Code Extensions (which can't have a scope): > > - yard-vscode-extension > > - swf-vscode-extension > > - pmml-vscode-extension > > - dmn-vscode-extension > > - bpmn-vscode-extension > > - vscode-extension-kogito-bundle > > - vscode-extension-kie-ba-bundle > > - vscode-extension-dashbuilder-editor > > > > And a one-off package that is later then transformed into a Maven > > WebJar [2] (which can't have a scope either) > > - sonataflow-deployment-webapp > > > > Those do not conform with the guidelines, but have been published > > under these scopes/names for quite some time now, before KIE became a > > podling. > > > > My question is: Are we required to rename everything prior to > > releasing? Or are we able to pass a vote with the current package > > names? Asking because that's a substantial amount of work prior to > > releasing, and also because renaming everything would mean consumers > > would have to manually "migrate" to the new package names. > > > > Thanks a lot in advance! > > > > Regards, > > > > Tiago Bento > > > > > > [1] https://incubator.apache.org/guides/distribution.html#npm > > [2] https://www.webjars.org/ > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[QUESTION] KIE - NPM package names
Hi general@incubator, The distribution guidelines [1] say packages published to NPM should be named `apache-`, however, at KIE, we have a somewhat big set of packages that are published under these scopes: - @kie-tools/* - @kie-tools-core/* - @kie-tools-scripts/* There are also some VS Code Extensions (which can't have a scope): - yard-vscode-extension - swf-vscode-extension - pmml-vscode-extension - dmn-vscode-extension - bpmn-vscode-extension - vscode-extension-kogito-bundle - vscode-extension-kie-ba-bundle - vscode-extension-dashbuilder-editor And a one-off package that is later then transformed into a Maven WebJar [2] (which can't have a scope either) - sonataflow-deployment-webapp Those do not conform with the guidelines, but have been published under these scopes/names for quite some time now, before KIE became a podling. My question is: Are we required to rename everything prior to releasing? Or are we able to pass a vote with the current package names? Asking because that's a substantial amount of work prior to releasing, and also because renaming everything would mean consumers would have to manually "migrate" to the new package names. Thanks a lot in advance! Regards, Tiago Bento [1] https://incubator.apache.org/guides/distribution.html#npm [2] https://www.webjars.org/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: KIE - Question about "staging" binaries/artifacts
Thank you for the prompt responses. We're aware that for Maven artifacts we could "promote" them after publishing them to a staging repo. But for container images, for example, I'm not sure I understand how such process would look like. Prior to being in Apache, we used to push images to Quay.io under a "[version]-prerelease" tag for "staging". Then we would have a completely new build when we would be ready for a actual release. I guess for other kinds of artifacts, like the NPM packages, live websites, and Chrome and VS Code Extensions, I also still don't understand very well how this could be achieved... Any advice? It's hard to tell what "promoting" those would look like, as for example, one of our live websites is hosted in GitHub Pages. Thanks again! Regards, Tiago Bento On 2024/05/13 20:35:35 PJ Fanning wrote: > For Java jars, the ASF has repository.apache.org - a Nexus instance that > can be used to stage and later release jars. > The login credentials are the same credentials you use to access other ASF > resources. > > > On Mon, 13 May 2024 at 21:28, Enrico Olivelli wrote: > > > Tiago, > > > > > > Il Lun 13 Mag 2024, 22:11 Tiago Bento ha scritto: > > > > > Hello general@incubator, > > > > > > My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the > > > committers of the KIE project of the incubator. > > > > > > We’re gearing towards our first release under Apache, and we’re very > > > excited to be approaching this important milestone. > > > > > > Some resources [1] [2] that we found already guided us in the right > > > direction, but still, some questions remain about the release process > > > itself. > > > > > > We understand that in Apache, releases are done from the source code > > > perspective, not the binaries/artifacts’. However, we still don’t > > > understand very clearly how Apache verifies signatures and checksums > > > of the binaries that are eventually published. > > > > > > > It is better that in case you provide binaries to your users those binaries > > are released together with the sources during the same VOTE. > > > > Having reproducible builds would help a lot, but that's not always easy to > > do. > > > > In your VOTE you should stage all the sources and binaries, signed with the > > same signature (by the release manager) and the same artifacts will be > > promoted in case of a successful VOTE. > > > > The PMC can at least verify the signatures and any digests that are staged > > as part of the VOTE. > > > > Please note that if you don't have a reproducible build the PMC will never > > be able to verify that the binaries match the sources. > > > > > > > The KIE project has three main types of consumable artifacts: Maven > > > modules, Container images, and NPM packages; and we also maintain some > > > live web pages like https://sandbox.kie.org, and extensions for Chrome > > > [3] and VS Code [4]. > > > > > > For the release to be voted, we understand we have to provide a .zip > > > file containing the source code along with instructions on how to > > > build it. Once/if approved, our understanding is that the exact same > > > approved source code could be used to build and publish > > > binaries/artifacts of any sort to public registries/repositories. > > > > > > I’m laying out all the information I could gather so someone can > > > correct me if somehow I got the wrong idea of any part of the process. > > > > > > I guess the main question I have at the moment is: Are we able to pass > > > the release vote only with the sources (without any published > > > artifacts) so that once/if approved, we could publish definitive > > > binaries/artifacts to public registries/repositories? > > > > > > > You can do it. But you should state it very clearly in the downloads pages > > and in any repository. > > > > Also it is better to leverage as much as possible the ASF infra to build > > automatically such derived artifacts. > > > > Foe instance in Apache BookKeeper we build the docker images using a docker > > bot that is handled by the ASF infra > > > > > > > This question comes from the fact that we’re not sure how such a > > > “staging” environment could be created for artifacts/binaries that are > > > not Maven modules. We started a thread [5] on Slack several hours ago, > > > but no luck g
KIE - Question about "staging" binaries/artifacts
Hello general@incubator, My name is Tiago Bento (@tiagobento on GitHub), and I’m one of the committers of the KIE project of the incubator. We’re gearing towards our first release under Apache, and we’re very excited to be approaching this important milestone. Some resources [1] [2] that we found already guided us in the right direction, but still, some questions remain about the release process itself. We understand that in Apache, releases are done from the source code perspective, not the binaries/artifacts’. However, we still don’t understand very clearly how Apache verifies signatures and checksums of the binaries that are eventually published. The KIE project has three main types of consumable artifacts: Maven modules, Container images, and NPM packages; and we also maintain some live web pages like https://sandbox.kie.org, and extensions for Chrome [3] and VS Code [4]. For the release to be voted, we understand we have to provide a .zip file containing the source code along with instructions on how to build it. Once/if approved, our understanding is that the exact same approved source code could be used to build and publish binaries/artifacts of any sort to public registries/repositories. I’m laying out all the information I could gather so someone can correct me if somehow I got the wrong idea of any part of the process. I guess the main question I have at the moment is: Are we able to pass the release vote only with the sources (without any published artifacts) so that once/if approved, we could publish definitive binaries/artifacts to public registries/repositories? This question comes from the fact that we’re not sure how such a “staging” environment could be created for artifacts/binaries that are not Maven modules. We started a thread [5] on Slack several hours ago, but no luck getting definitive answers. I apologize if I’m lacking obvious information, and appreciate any resource or reply that would put us closer to a successful release. Regards, Tiago Bento [1] https://lists.apache.org/thread/ropp09n8m75rl6hlvnmpwcv85oyq5op9 [2] https://www.apache.org/info/verification.html [3] https://chromewebstore.google.com/detail/bpmn-dmn-test-scenario-ed/mgkfehibfkdpjkfjbikpchpcfimepckf [4] https://marketplace.visualstudio.com/items?itemName=kie-group.vscode-extension-kie-ba-bundle [5] https://the-asf.slack.com/archives/CBX4TSBQ8/p1715605377484379 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
