That's just the project where the test is failing. I've think I've just
found the issue by setting LANG to de_DE and I get a single failure.
We've had issues like this in the past. Tracking it down now.
I'm not sure if SBT has an equivalent for licenses, but it should be
pretty easy to create something similar. That seems like a manageable
way to handle it.
On 4/8/20 12:49 PM, Christofer Dutz wrote:
> Hi Steve,
>
> Isn't "daffodil-test-ibm1 / Test / test" the name of the test that's failing?
>
> Well I can only say how we've previously done it in the Apache Edgent and are
> doing it in PLC4X.
> But we're using Maven so I have no idea what the SBT counterparts are.
>
> Here we're using the maven-remote-resources-plugin which uses the default
> LICENSE, NOTICE, ...
> But if there is something to add to those, you simply create a directory
> "src/remote-resources"
> So if in that directory you create a file NOTICE, the content of that file
> gets added to the NOTICE file in the jar.
>
> So if you add something in 1 module which requires you to add something to
> the LICENSE file, you have to add "src/remote-resources/LICENSE" in that
> module and ideally manually in the root and the build will take care of that.
> So you would create 3-4 little files with just the parts you need in that
> module and it would be included.
>
> And you can also use the maven-remote-resources-plugin to add an incubating
> disclaimer (This is taken from the Edgent build):
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-remote-resources-plugin</artifactId>
> <version>1.5</version><!--$NO-MVN-MAN-VER$-->
> <executions>
> <execution>
> <id>process-resource-bundles</id>
> <goals>
> <goal>process</goal>
> </goals>
> <configuration>
> <resourceBundles>
> <!-- Will generate META-INF/{DEPENDENCIES,LICENSE,NOTICE} -->
>
> <resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
> <!-- Will generate META-INF/DISCLAIMER -->
>
> <resourceBundle>org.apache:apache-incubator-disclaimer-resource-bundle:1.1</resourceBundle>
> </resourceBundles>
> <!-- Content in this directory will be appended to generated
> resources -->
>
> <appendedResourcesDirectory>${remote-resources-maven-plugin.remote-resources.dir}</appendedResourcesDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> The interesting part here is the: apache-incubator-disclaimer-resource-bundle
>
> Hope that helps.
>
> Chris
>
>
> Am 08.04.20, 15:35 schrieb "Steve Lawrence" <slawre...@apache.org>:
>
> Comments inline
>
> On 4/8/20 9:03 AM, Christofer Dutz wrote:
> > Hi all,
> >
> > +0 (binding)
> >
> > would have given a -1, but I'm unsure if this the problem in building
> is sitting in front of the keyboard or if SBT is just not as mature as Maven
> or if there's actually a problem in the project.
> >
> > Source Bundle:
> > [OK] Signatures match
> > [OK] Signatures by apache email address
> > [OK] Hashes match (Both 256 and 512 versions)
> > [OK] Source bundle unpacks correctly
> > [OK] Unpacked sources contain NOTICE, LICENSE, README.md and DISCLAIMER
> > [OK] Year on NOTICE file correct, LICENSE file correctly lists up the
> included passera and UniquenessCache.scala code
> > [NOT OK] When running "sbt compile" actually nothing was compiled, when
> running "sbt -mem 6144 test" it compiled however at least one unit test
> failed:
> > [error] (daffodil-test-ibm1 / Test / test)
> sbt.TestsFailedException: Tests unsuccessful
> > When re-runnning the "sbt -mem 6144 test" command,
> the build is sort of hanging for more than 40 minutes now ... will abort and
> re-try a third time ...
> > Had to do a "sudo sbt clean" as I was getting
> permissions denied from being a normal user
> > When re-running the original build I now got script errors
> ... so I deleted the entire directory, unpacked it again and re-ran the build.
> > Unfortunately same error:
> > [error] (daffodil-test-ibm1 / Test / test)
> sbt.TestsFailedException: Tests unsuccessful
>
> This is really odd. I don't have any issues compiling and running tests
> form the src package. We did update the sbt version, so the first run
> can take a bit of time to download and compile the right sbt version,
> but that shouldn't take that long.
>
> Any chance you can find the name of the test that failed?
>
> > Binaries:
> > [NOT OK] The jars should all contain the DISCLAIMER in
> /META-INF/DISCLAIMER ... it seems they are missing this.
>
> I've created DAFFODIL-2315 to fix this issue.
>
> > [NOT OKisch] The LICENSE files in the jar files all refer to at least
> some files not contained in the jars themselves (Because the same LICENSE
> text is being used for all artifacts)
>
> I'd prefer to not have to maintain a separate license file for each of
> our jars. Seems pretty error prone to keep updated. Do you know how
> other projects handle this?
>
> > [NOT OK] The jars in Nexus don't contain DISCLAIMER files either.
>
> That will be fixed as part of DAFFODIL-2315.
>
> >
> >
> > so after validating your release I do have a few comments:
> >
> > - SHA512 hashes are the default and as far as I recall shorter Hashes
> are considered deprecated (Perhaps drop the SHA265 hashes)
>
> Created DAFFODIL-2316
>
> > - Does the README.md suggestion to edit "/etc/sbt/sbtopts" also apply
> for Mac and Windows?
>
> Created DAFFODIL-2317, I suspect this file is not correct for Mac/Wincows
>
> > - You seem to bundle quite a number of IDE settings files in the
> release, is this intentional?
>
> This is intentional. Our project layout is a bit unique and Eclipse
> can't easily import it, so we actually have a tool to create eclipse
> configuration settings and we include those in the source. DAFFODIL-1983
> is the issue to remove this and make it a more automated process.
>
> > - in the Daffodil-Lib module you bundle some code which is BSD-2, BSD-3
> licensed. You include the license text inside the source directory, in other
> projects we usually have a "licenses" directory containing the license texts
> of bundled software, this makes it easier to find for people.
>
> I've seen it both ways in various Apache projects. I personally prefer
> everything to be in a single file. Does Apache have guideance if one is
> preferred over the other?
>
> > - A number of the test XML files are missing Apache headers even if
> they could contain them
>
> Skimming these, it looks like at least a couple can have the license
> without breaking tests. Created DAFFODIL-2318
>
> > - The .gitignore could use a header.
>
> Created DAFFODIL-2319
>
> >
> >
> >
> > Am 08.04.20, 00:24 schrieb "Olabusayo Kilo" <ok...@tresys.com>:
> >
> > (Resending due to issue with weird formatting/pipes in previous
> message)
> >
> > Hi all,
> >
> > I'd like to call a vote to release Apache Daffodil (incubating)
> 2.6.0-rc1.
> >
> > All distribution packages, including signatures, digests, etc. can
> be
> > found at:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.6.0-rc1/
> >
> > Staging artifacts can be found at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedaffodil-1014/
> >
> > This release has been signed with PGP key 639637FDA8049411,
> corresponding
> > to olabus...@apache.org, which is included in the KEYS file here:
> >
> > https://downloads.apache.org/incubator/daffodil/KEYS
> >
> > The release candidate has been tagged in git with v2.6.0-rc1.
> >
> > For reference, here is a list of all closed JIRAs tagged with 2.0.0:
> >
> > https://s.apache.org/daffodil-issues-2.6.0
> >
> > For a summary of the changes in this release, see:
> >
> > https://daffodil.apache.org/releases/2.6.0/
> >
> > Please review and vote. The vote will be open for at least 72 hours
> > (ends on Friday, 10 April 2020, 3 PM EST).
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > --
> > Best Regards
> > Lola K.
> >
> >
> >
> >
>
>
>
