stevedlawrence commented on a change in pull request #48: All SDW have WarnIDs
to support suppression of warnings.
URL: https://github.com/apache/incubator-daffodil/pull/48#discussion_r171118147
##########
File path: project/Dependencies.scala
##########
@@ -18,7 +18,15 @@
import sbt._
object Dependencies {
- lazy val common = core ++ infoset ++ test
+
+ // Note cli added to commmon on purpose.
+ // Due to some obscure bug, updateClassifers was not pulling the
+ // dependencies for the daffodil-cli module into lib_managed properly.
+ // (It found the source jars and javadoc jars, but not the regular code jar
for
+ // Scallop aka org.rogach.)
+ // So compilation would fail for daffodil-cli from missing org.rogach
library.
+ // Added to here forces these dependencies to be resolved.
+ lazy val common = core ++ infoset ++ test ++ cli
Review comment:
Unfortunately, I'm not sure SBT has a good to way to disable aggregation of
a specified command for a subproject. You can either have "do not aggregate
this entire subproject" or "do not aggregate a specified command for all
subprojects", but you can't combine the two.
However, SBT does have a builtin "integration" test concept. Basically, you
put integration tests in ``src/it/{scala,java,resources}``, and then all
integration tests can be run via ``sbt it`` or something. This is sortof
similar to what we had with the scala-cli stuff, except CLI tests don't share
scala/java/resources directories like they did before and can now, but I don't
think that really matters with our current usage. There isn't any sharing going
on. Also, I'm not sure CLI tests are really "integration" tests, but I'm not
sure that really matters. I'm also not sure if we can make it work with debug,
which was one of the reasons for getting rid of the scala-cli stuff.
I'll create a bug to look into if this wold work as a better alternative,
and allow us to reenable aggregation and avoid these types of issues.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services