Hi,
On 27.09.23 12:54, Neil C Smith wrote:
The workflow appears to be missing a source bundle that we could use
for voting purposes, ...
Its a bit unfortunate that we have to set up releases for something what
is only consumed by NB. I feel this project has enough to do during
release already.
However, since the main build doesn't produce those artifacts (and
likely can't), we do have to version and upload them somewhere so that
the main build can treat them as regular dependency and be somewhat
reproducible.
The libs look fairly stable to me so this probably doesn't have to
happen often - so it might not add a lot overhead to the release process
after all?
Looking further I'm inclined to keep in this repo and adapt the GitHub
workflow to include a source zip, and to release via dist.apache.org
rather than Maven
Sounds good to me. I slightly prefer dist.apache.org for internal
artifacts which are only consumed by NB, maven central is also fine it
just feels a bit wrong to use it for this. We should consider marking
them as internal.
Publishing binaries via Maven doesn't seem viable for this given
cross-OS build needed, so possibly looking at dist.a.o instead.
(I assume you mean maven central the repo and not mvn the build system)
Out of curiosity, why is it a problem? I used to put native libs into
jars back when I wrote Java OpenCL bindings for example.
best regards,
-mbien
Thoughts?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
