Debugging sbt-osgi build

[Brian Topping]

Hi all, not sure where to begin debugging some changes I am making to the Spray build.  Specifically, most of the projects compile and build properly with the proper OSGi manifest, but the project that I have been modifying does not with what appears to be practically the same configuration as the other projects.

When I run "publish" over the build, the generated artifact has only the generated manifest and unmanaged resources, but none of the classes.  This is odd because the project's target/classes directory is fully populated.  

I tried to compare it to a working project in the same build by comparing the output of "inspect tree publish" on both projects.  But the deserialization of the two trees are wildly out-of-order.  Is that expected behavior or are my projects that different?

What I am trying to find out is if there is a better way to compare two projects with debugging output so I can find what I've done wrong.  I'm sure there are infinite potential problems that would tax the resources of the list to go through, what I am trying to find is the path by which other list users would go about comparing two project builds if they were in a similar situation.

Thank you, Brian

[Josh Suereth]

Hey Brian -

A note on the deserealization of inspect tree ->

This is largely dependent on the ordering of settings added to a project.   Are you adding plugins in a different order than each other?  This is usually the biggest cause of a useful setting getting overridden by a default.

Also, the ordering of the dependencies shouldn't matter as immensely as the fact that there *is* a dependency.  Since all tasks are executed concurrently in sbt, there is no guarantee that one task may run before another *unless* there's an explicit dependency relationship between the two tasks.

Hope that helps and sorry I can't offer more.  Perhaps you could post some code?

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simple-build-t...@googlegroups.com.
To post to this group, send email to simple-b...@googlegroups.com.
Visit this group at http://groups.google.com/group/simple-build-tool.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Topping]

Ah great, that helps.  I had forgotten about the parallel execution.  Even if there was some possibility of ordering, it's far less relevant than the dependencies being correct so a task is not executed before a dependency (ad infinitum).  

I honestly don't have an effin clue how this thing works, even after buying Josh Suereth's promising start on "SBT In Action", reading what I can of Mark's pretty excellent xsbt docs and wading through what I could stay awake for of the official docs.  IIRC, dumping the tree provides a lot of opaque object references for objects that don't have toString serializers.  So super relevant stuff like filenames and other important parameters are lost.  Then there are the plugins that don't output anything as far as what they are doing.  They just work or they don't.  And I can't figure out how to get IntelliJ to do the right thing and load source jars (though it doesn't seem to matter as a lot of releases are optimized and without symbolics).

Maven also has this behavior (due to it's declarative nature and early XML parsers having no guarantee of deserialized object order) and it has caused marginally violent consternation for many an Ant lover.  I consider myself to have a relatively open mind and am not working against myself in learning SBT, but the multitude of operators and patterns approaches overload, much less understanding the rest of it and getting it to work.  What worked for Maven is the augmentation of the "-X" option that prints out the input parameters to every plugin execution in human-readable form.  This is probably going to be harder since there's no parameter encapsulation like there is in Maven (a SBT plugin has access to all the property trees), but what other option is there?  It's like there needs to be a Swing-based debugger that takes inspect-tree to level of a graphically browsable log archive (not holding my breath as I wouldn't sign up to develop it either).

As it turns out, one of my colleagues found the problem I originally posted yesterday, it was with sbt-osgi silently failing with no debug output or error when it didn't like it's input.  We spent something like ten man-days trying to find that.  If SBT is the primary ambassador and gateway to the Scala ecosystem, it's seems really inexcusable.  

Again, this isn't to denigrate anyone, I'm just observing my/our experiences, not pointing fingers at really smart people that have invested tens of thousands of hours creating this otherwise interesting tool.