I ran the ./create_vsix.sh script, and it does create a .vsix file, but
when I unzip that file, this is the contents:
.
|-- [Content_Types].xml
|-- extension
| |-- LICENSE.txt
| |-- NOTICE
| |-- README.md
| |-- build.sbt
| |-- create_vsix.sh
| |-- dist
| | `-- ext
| | `-- extension.js
| |-- images
| | |-- arrow.svg
| | `-- daffodil.jpg
| |-- package.json
| `-- snippets
| |-- dfdl.json
| `-- json-license.txt
`-- extension.vsixmanifest
Seems odd the build.sbt and create_vsix.sh files are in here. Is that a bug?
It looks like all the ts files are combined and minimized into the
single extension.js file. I'm not sure where the dependencies are
though. Maybe they are downloaded dynamically? Or maybe just the parts
that are used are are "statically compiled" into this extension.js? So
we can't easily know which dependencies actually end up in this .vsix file?
Also, the debugger .jar and its dependencies aren't in this vsix file?
Are those distributed/downloaded separately? Seems like they would
wanted to be distributed in the .vsix file so you just need to
distribute/install a single file? Is that possible?
It's important to understand this so we can figure out what
LICENSE/NOTICE information is needed in this .vsix convenience binary.
On 10/13/21 12:22 PM, Adam Rosien wrote:
My understanding is the Typescript code gets "compiled" into Javascript
when built and packaged.
On Wed, Oct 13, 2021 at 9:07 AM Mike Beckerle <mbecke...@apache.org> wrote:
Does the typescript code get compiled to a binary form (e.g., analogous to
a jar) or is it distributed as source (e.g., more like javascript)?
On Wed, Oct 13, 2021 at 11:12 AM John Wass <jwa...@gmail.com> wrote:
Status on Mike's original list
1-4 complete
We have some tweaks that could be added for a 1.0.0, but perhaps we get
an
1.0.0-RC1 out ASAP, and then can improve that with further RCs?
Blockers for an initial RC right now might be
1. Do we know the ASF process for releasing the VSIX and zip to GitHub?
2. Add the actions CI back in for automated release from a tag.
3. Items 5-7 of Mike's original list ?
Sound right?
On Thu, Oct 7, 2021 at 10:23 AM Mike Beckerle <mbecke...@apache.org>
wrote:
+1 on summary + linking to older issue
On Thu, Oct 7, 2021 at 10:15 AM Steve Lawrence <slawre...@apache.org>
wrote:
+1 sounds good to me
On 10/7/21 10:14 AM, John Wass wrote:
Sounds good. I will do that and start to move issues over.
Some of these issues have multiple posts by multiple authors and it
will
be
hard to capture all that context in the new repo. I'm thinking of
generating a summary and then adding a link to the archived issue.
Any
objections there?
On Wed, Oct 6, 2021 at 5:01 PM Mike Beckerle <mbecke...@apache.org
wrote:
No problem. Go ahead. That's a sensible last commit on that repo.
On Wed, Oct 6, 2021 at 5:00 PM John Wass <jwa...@gmail.com>
wrote:
Will there be any problem with updating the readme in the old
repo
to
note
that it is relocated?
On Wed, Oct 6, 2021 at 4:20 PM John Wass <jwa...@gmail.com>
wrote:
Steps 1-7 sound good to me. Some thoughts
1) push to https://github.com/apache/daffodil-vscode
repository.
Who is going to push the code?
2) move over github issues to the new repo issues
It doesn't look like the "transfer issue" function works across
orgs.
So
a manual move it shall be.
3) move wiki pages/doc to the github wiki associated with the
new
repository
Same thing, manual copy. Not as significant as issue moving.
4) archive the old original github repo (for posterity).
Concur. I'd say this happens first to ensure nothing drifts
while
we
are
moving things around.
On Wed, Oct 6, 2021 at 10:41 AM Mike Beckerle <
mbecke...@apache.org
wrote:
With the IP-clearance now complete, next steps (I think) are:
1) push to https://github.com/apache/daffodil-vscode
repository.
I believe the existing repo main branch should be pushed here
as
is,
i.e.,
no need to squash anything.
Note the main branch is named "main", not master.
Tag it at the current point on the main branch. (suggest tag
name
apache-ip-clearance ? or happy-apache-birthday ?)
2) move over github issues to the new repo issues
3) move wiki pages/doc to the github wiki associated with the
new
repository
4) archive the old original github repo (for posterity).
5) update main daffodil-site pages to mention/highlight the new
vscode
debugger and link to its issues and wiki.
6) whatever else I forgot
and....
7) start planning for release 1.0.0.
I am not sure what additional things are needed in order to
meet
Apache
criteria for release, given the vscode marketplace as a means
of
distribution. Perhaps we don't need to solve that yet?
I think we covered almost everything else during the
IP-clearance
process.
If there are things, let's discuss them here on the dev list.
