stevedlawrence commented on a change in pull request #486:
URL: https://github.com/apache/incubator-daffodil/pull/486#discussion_r568740275
##########
File path: build.sbt
##########
@@ -177,7 +182,18 @@ lazy val usesMacros = Seq(
// ignores files such a META-INFA/LICENSE and NOTICE that are duplicated and
// would otherwise cause a conflict
mappings in (Compile, packageBin) ++= mappings.in(macroLib, Compile,
packageBin).value.filter { case (f, _) => f.isDirectory ||
f.getPath.endsWith(".class") },
- mappings in (Compile, packageSrc) ++= mappings.in(macroLib, Compile,
packageSrc).value
+ mappings in (Compile, packageSrc) ++= mappings.in(macroLib, Compile,
packageSrc).value,
+
+ // The sbt eclipse plugin does not addd the macroLib project as a dependency
+ // in .classpath files because macroLib isn't actually an sbt dependncy.
+ // Instead, sbt does the above stuff to copy macro lib files into those
Review comment:
Yep, that page describes exactly what we're doing, and probably where we
got the idea to do this, and I think is the "right" way to handle internal
macros. We don't really need to publish a jar of macros since they are internal
to Daffodil. So we disabling publishing that jar, and copy the macro code into
projects that use macros.
I can adjust the comment to make this distinction.
Yeah, it does sound like a bug in eclipse. Unfortunately, sbt eclipse plugin
hasn't been updated for two years, so I'm not sure how likely we are to get
this bug fixed. I imagine the fix is for eclipse to just treat these
compile-internal dependencies as if they were compile dependencies (which is
basically what we're doing)--I'm not sure if eclispe has a concept of
"compile-internal"
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
