On Mon, Apr 1, 2019 at 11:27 AM Mark Struberg <strub...@yahoo.de.invalid> wrote:
> We have also previously already checked those files and also have the > sources at hand afaict. > So they should be perfectly fine - as they have been in older NB releases > (where we had the question as well). > I think this is the biggest problem with the incubator -- the fact that one constantly needs to re-litigate decisions and agreements that have already been made in previous releases. Pointing to a list of issues, or a Wiki where these items are listed, is clearly not a solution -- the fact that we have been making use of Apache Rat from the very beginning and that we have a Rat exclusions file was also missed, a whole thread was started to bring our intransigence to the attention of the world was started, etc etc. So, I don't see a solution here and it is the IPMC vote that -- while being immensely valuable for being the most detailed -- that invariable causes the most confusion and wasting of time in re-litigating things. So, though I'd like to bring a solution to this, I do not have one. Gj > > LieGrue, > strub > > > > Am 30.03.2019 um 07:23 schrieb Wade Chandler <wadechand...@apache.org>: > > > > On Fri, Mar 29, 2019, 21:43 Justin Mclean <jus...@classsoftware.com> > wrote: > > > >> > >> Theres are the binary inclusions that seem to contain compiled code, an > >> ASF release should not include this: > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/com-example-testmodule-cluster.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-brokendepending.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-depending.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-depending_on_new_one_engine.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-engine-1-1.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-engine-1-2.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-engine.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-executable-permissions.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-fragment.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-independent-1-1.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-independent.nbm > >> B > >> > ./platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/org-yourorghere-refresh_providers_test.nbm > >> > > > > To be clear, this is test data; not binary dependencies. Note the names > of > > those files. NetBeans has a module system, and those have nbm extensions. > > These nbms are made to test very specific things that can be wrong in > > modules. This would be like having tests for C/C++ linkers and object > files > > etc where you just want to validate the linking not rebuilding object > files > > for tests; rebuilding those every test run adds build time for no gain. > > Make sense, and Ok? > > > > Thanks > > > > Wade > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
