Neil, Matthias at all,
Let me present a different opinion. I understand the policy that
"compiled code should not be part of the relase (that is: sources that
are used to build the convenience binary).
I suppose the main philosophy behind objections against *compiled code*
is that it is an unknown (potentially) executable sequence that is
hard-to-modify would appear in 'open source' codebase. Or even if not
directly 'executable', the compiled code cannot be (easily) analysed,
inspected, edited. Which sounds rather as a nonsesne in an O/S
ecosystem; it's rational decision to avoid such black boxes in the
codebase. But the JARs which are presented as a big problem for the
release do not fit to that pattern.
With this approach - what should we do, if we had for example PDF or DXF
(autocad) as input for some of our tests ?
Note the wording "compiled code" above. But your effort seems as a fight
against ANY archives. For example, Matthias' list:
./java/maven/test/unit/data/mavenmock/**
./enterprise/payara.common/test/unit/data/nottaDir-4_1_2.jar
...
Please also note that all remaining pre-built binary files are
- tests
- archives
- readable AND writable (= modifiable) by standard CLI or desktop tools
- entries of the binaries have a well defined format and CAN be modified.
There are a NUMBER of counter-examples in other Apache projects that
have "compiled binaries" (ZIPs, JARs or even other binaries) in their
GITs. Just few examples:
- Apache Common Compress: tars (even containing .so !!), ZIPs, 7z
archives, ...
- Apache Tomcat: test resource JARs
- Apache Hadoop: test resources in JARs
...
As part of the crusade against archives, for example,
https://github.com/apache/netbeans/pull/3162/files#diff-e836c4a30a43c7356caff2498fad06d3346e406508a1c724e3ba6a308a03c680R90
replicates what Maven's jar packager does. Sort of. For example META-INF
is not generated (but luckily it's not tested either), which should be
part of any JAR archive.
Let me say that I am not in favour of such ad hoc code. If this is
really an issue (which I personally doubt), then the Harness or NBJUnit
library should be enhanced (just an idea) to process directories that
follow certain naming convention to create test data ZIPs or JARs: It's
IMHO more maintainable to have test data apart from the test code,
file-based and versioned separately.
Regards,
-Svata
Dne 13. 09. 21 v 9:25 Laszlo Kishalmi napsal(a):
I'm sorry for stirring up the waters. I was acting on my memories of
release 10.0.
https://issues.apache.org/jira/browse/NETBEANS-1719
I do not think that the release process shall be hanged upon my +0, it's
not a -1 after all (as the jars does not contain compiled code).
Honestly, I like the idea presented by Matthias in
https://github.com/apache/netbeans/pull/3162 as a way forward in 12.6
On 9/11/21 11:10 AM, Neil C Smith wrote:
On Sat, 11 Sept 2021 at 18:58, Matthias Bläsing
<[email protected]> wrote:
I'm mildly irritated, that trivial JARs are considered a problem for
the 12.5 release, while a huge pile of files is completely excluded
from RAT scanning.
+1, but don't be irritated! :-)
Part of the problem is that we haven't updated our release emails to
cover them, or the branding folders with jar names that have also
caused similar concerns. It's something to look at, along with some
of the other text, before 12.6.
There is IMHO _nothing_ in this, that warrants doubts on the
cleanliness of the release.
+1 I did similar checks for 12.4.
I'll see if I can remove them all all, but for 12.5 IMHO this is out of
scope and also unnessary.
It's unnecessary anyway, except possibly on the point that was made on
legal-disuss about harder to review, and that's minor. And probably
pointless unless we decided to address all the other archive formats?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
