You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 21, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: README.adoc
+72-2Lines changed: 72 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,17 @@ This extension provides support for https://pulsar.apache.org/[Apache Pulsar^] i
25
25
- Start, stop, restart, delete function
26
26
- Start, stop function instances
27
27
- Delete function
28
+
- Create new function**
29
+
- Auto sense a function manifest and show deploy shortcuts**
30
+
- Auto sense a function manifest and show runtime package options
31
+
+
32
+
----
33
+
py: choose .py file or choose a folder to (automatically) zip
34
+
java: choose .jar or .nar file
35
+
go: choose go executable
36
+
----
37
+
38
+
**{sp}This feature is not compatible with Pulsar 3.0
28
39
29
40
== Getting Started
30
41
@@ -60,10 +71,69 @@ If you work with a managed provider of Apache Pulsar, let's create a provider fo
60
71
61
72
Not all providers are created the same. Some use tokens some don't. Some managed version of Pulsar don't support all the features of an OSS cluster. This extension tries to be as flexible as possible to support all the different providers, while still giving the consumer a consistent experience.
62
73
63
-
== Contributing
74
+
== Output for debugging
64
75
65
-
All contributors are welcome! It helps if you are familiar with Typescript (that's what the extension is written in), but it's not required. If you are interested in contributing, please reach out to us.
76
+
While using the extension you may want to see output of what is going on in the background. To do this, open the VSCode output panel and select the 'Develop for Apache Pulsar' output channel. This will show you the logs from the extension.
66
77
67
78
== Roadmap of your ideas
68
79
69
80
We've got high hopes for this extension. If you have an idea of a feature that would make it even better, please open an issue and let's discuss it! You can review the current roadmap in https://github.com/orgs/develop-for-apache-pulsar/projects/1[the GitHub project].
81
+
82
+
== Contributing
83
+
84
+
All contributors are welcome! It helps if you are familiar with Typescript (that's what the extension is written in), but it's not required. If you are interested in contributing, please reach out to us.
85
+
86
+
=== Project Structure
87
+
88
+
Let's use the folder structure of the project to explain how things are laid out.
89
+
90
+
==== images
91
+
92
+
This is a folder for images used in the README and other documentation. All features that include icons and images should respect the chosen theme. If you are adding a new feature, please add a light and dark version of the image. No matter where the image in used in code, it should be referenced from this folder. VSCode is picky about svg's sometimes, so if you are having trouble with an image, try converting it to a png.
93
+
94
+
==== scripts
95
+
96
+
This is a folder for javascript used in webpanels. A webpanel is just a mini browser serving up html, with support for javascript actions. VSCode provides workers to do messaging between the browser and the background process. No matter where the javascript is used, it should be references from this folder.
97
+
98
+
==== src
99
+
100
+
**common** - holds .ts classes that are commonly used throughout the project. Currently, it's just the constants.
101
+
102
+
**controllers** - think of this in the same way a microservice's folders are laid out. The public facing functions (endpoints) are the controllers. The endpoints declared in a controller have no logic. They just marshall request/response actions. Like cancellation tokens, global libs, and translating exceptions to response statuses.
103
+
104
+
In this project, a controller is allowed to reference the (global) vscode lib but all lower classes that the controller depends on can not import vscode. If something is needed (like a context value), the contoller needs to handle getting that info to the dependent lib.
105
+
106
+
The execution of a controller almost always traces back to a declared VSCode command.
107
+
108
+
TODO: Controllers are fire and forget
109
+
110
+
**providers** - these are extensions of VSCode objects. Typically, when an extension wants to implement a given feature of VSCode (like a folder tree or a document editor) it uses the provided interface from the vscode lib. Each folder in this folder represent an implementation of the given object.
111
+
112
+
**pulsarAdminProviders** - this is specific to this extension. The idea is to make adding providers as easy and clear as possible. Each provider is a folder within this folder. There are 2 required files in a given provider's folder. +
113
+
114
+
- provider.ts: this is the provider's implementation of pulsar admin. Typically it's going to take a signature of:
115
+
+
116
+
[source, typescript]
117
+
====
118
+
export class Provider extends BaseProvider implements TPulsarAdmin {}
119
+
====
120
+
121
+
- settings.ts: this is the provider's declaration of its service (icon, display name, etc). Nested in this class is the provider's onboarding implementation. That is how one discovers their pulsar clusters hosted with the provider and saves a reference in this extension.
122
+
123
+
There is also a 'base' provider. Most providers will extend the base and override functions when needed.
124
+
125
+
**services** - these are classes that are used throughout the project. They hold the logic of how the given function is completed while interacting with a Pulsar cluster. They are not dependent on vscode so testing should be quite easy.
126
+
127
+
**test** - this is where... you guess it, tests are located. Testing VSCode extensions are notoriously hard. But the founder of this project is a big believer in test driven development, so a compromise had to be met. The 'integration' folder holds tests that use the recommended electron approach. Attempting to run VSCode in memory and test an extension's features. The 'unit' folder holds smaller bite size tests that don't need VSCode. Remember the design of controllers and providers? Their dependent classes don't import vscode which makes them very testable.
128
+
129
+
**types** - all declared typescript types in this project live here. For the most part, interfaces are not used. Instead, they are a 'type'.
130
+
131
+
**utils** - simple utility classes used throughout the project.
132
+
133
+
**wizards** - certain actions (like creating a topic or discovering new clusters) have multiple steps for completion. These wizards are used throughout the project.
134
+
135
+
**extension.ts** - VSCode's activation of the extension and all it's features.
136
+
137
+
==== styles
138
+
139
+
A complement to the scripts folder, holding styles used in webpanels. Same rules apply.
Copy file name to clipboardExpand all lines: README.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,5 +22,16 @@ This extension provides support for [Apache Pulsar](https://pulsar.apache.org/)
22
22
- Start, stop, restart, delete function
23
23
- Start, stop function instances
24
24
- Delete function
25
+
- Create new function**
26
+
- Auto sense a function manifest and show deploy shortcuts**
27
+
- Auto sense a function manifest and show runtime package options
28
+
29
+
```
30
+
py: choose .py file or choose a folder to (automatically) zip
31
+
java: choose .jar or .nar file
32
+
go: choose go executable
33
+
```
34
+
35
+
** This feature is not compatible with Pulsar 3.0
25
36
26
37
Once installed you'll notice a new Pulsar icon in the activity bar. Click it to activate the extension and see the option to save your providers' configuration.
0 commit comments