[jira] [Resolved] (DAFFODIL-2531) New sbt versions not compatible with TDMLRunner implementations strategy

["Steve Lawrence (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Lawrence resolved DAFFODIL-2531.
--------------------------------------
    Resolution: Not A Problem

> New sbt versions not compatible with TDMLRunner implementations strategy
> ------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2531
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2531
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Infrastructure, TDML Runner
>    Affects Versions: 3.2.0
>            Reporter: Mike Beckerle
>            Priority: Major
>
> Under sbt 1.5.3, the failure describe here happens.
> It doesn't fail this way under sbt 1.3.9
> The CSV dfdl schema has one portable test and two daffodil-only tests in it.
> I am building and testing CSV as a sub-module in a regression test suite that has lots of schemas in it.
> So the command I'm issuing is at a enclosing directory:
> {code:java}
> sbt dfdl-csv/ibm{code}
> That should run the 1 portable test and skip the 2 non-portable tests.
> However, it fails the 2 non-portable tests
> I've instrumented Daffodil 3.2.0-SNAPSHOT a little to show why this is failing.
> {code:java}
> [error] Test suite com.tresys.csv.TestCSV failed with java.lang.ClassNotFoundException: org.junit.AssumptionViolatedException.
>  [error] This may be due to the ClassLoaderLayeringStrategy (ScalaLibrary) used by your task.
>  [error] To improve performance and reduce memory, sbt attempts to cache the class loaders used to load the project dependencies.
>  [error] The project class files are loaded in a separate class loader that is created for each test run.
>  [error] The test class loader accesses the project dependency classes using the cached project dependency classloader.
>  [error] With this approach, class loading may fail under the following conditions:
>  [error] 
>  [error] * Dependencies use reflection to access classes in your project's classpath.
>  [error] Java serialization/deserialization may cause this.
>  [error] * An open package is accessed across layers. If the project's classes access or extend
>  [error] jvm package private classes defined in a project dependency, it may cause an IllegalAccessError
>  [error] because the jvm enforces package private at the classloader level.
>  [error] 
>  [error] These issues, along with others that were not enumerated above, may be resolved by changing the class loader layering strategy.
>  [error] The Flat and ScalaLibrary strategies bundle the full project classpath in the same class loader.
>  [error] To use one of these strategies, set the ClassLoaderLayeringStrategy key
>  [error] in your configuration, for example:
>  [error] 
>  [error] set dfdl-csv / Test / classLoaderLayeringStrategy := ClassLoaderLayeringStrategy.ScalaLibrary
>  [error] set dfdl-csv / Test / classLoaderLayeringStrategy := ClassLoaderLayeringStrategy.Flat
>  [error] 
>  [error] See ClassLoaderLayeringStrategy.scala for the full list of options.
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)