Failure to download sources and javadocs should be a warning, not an error.

[GoogleCodeExporter]

What steps will reproduce the problem (please be specific)?

Run 'update' in a build with multiple subprojects, using managed dependencies, 
some of which use 'withSources'. A failure to download sources for dependencies 
of one sub-project is an error, and update is not run in subsequent modules.

Example:

{{{
[warn]  ==== Scala-Tools Maven2 Repository: tried
[warn]    
http://scala-tools.org/repo-releases/com/efgfp/thirdparty/jyz3d/0.7.1/jyz3d-0.7.
1-sources.jar
[warn]      ::::::::::::::::::::::::::::::::::::::::::::::
[warn]      ::              FAILED DOWNLOADS            ::
[warn]      :: ^ see resolution messages for details  ^ ::
[warn]      ::::::::::::::::::::::::::::::::::::::::::::::
[warn]      :: org.scalanlp#scalala_2.8.0;0.4.0!scalala_2.8.0.jar(sources)
[warn]      :: 
com.googlecode.scalaz#scalaz-core_2.8.0;5.0!scalaz-core_2.8.0.jar(sources)
[warn]      :: com.efgfp.thirdparty#jyz3d;0.7.1!jyz3d.jar(sources)
[warn]      ::::::::::::::::::::::::::::::::::::::::::::::
[info] 
[info] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
[error] sbt.ResolveException: download failed: 
org.scalanlp#scalala_2.8.0;0.4.0!scalala_2.8.0.jar(sources)
[error] download failed: 
com.googlecode.scalaz#scalaz-core_2.8.0;5.0!scalaz-core_2.8.0.jar(sources)
[error] download failed: com.efgfp.thirdparty#jyz3d;0.7.1!jyz3d.jar(sources)
[info] == analytics-test-support / update ==
[error] Error running update: sbt.ResolveException: download failed: 
org.scalanlp#scalala_2.8.0;0.4.0!scalala_2.8.0.jar(sources)
[error] download failed: 
com.googlecode.scalaz#scalaz-core_2.8.0;5.0!scalaz-core_2.8.0.jar(sources)
[error] download failed: com.efgfp.thirdparty#jyz3d;0.7.1!jyz3d.jar(sources)
[info] 
[info] Total time: 9 s, completed Oct 30, 2010 11:18:36 AM
}}}

This can happen if: 1) I have added withSources to all dependencies in the hope 
they are published, or 2) I had deployed the sources for a public dependency to 
a private repository, but I am now running SBT on a laptop that is disconnected 
from that private repo.

What is the expected behavior? What do you see instead?

SBT should treat these as warning, and run update in subsequent subprojects.

What versions of the following are you using?

sbt: 0.7.4

Please provide any additional information below.

Original issue reported on code.google.com by jzaugg on 30 Oct 2010 at 9:29

[GoogleCodeExporter]

Workaround is to run update from each sub-project.

Original comment by jzaugg on 30 Oct 2010 at 9:33

[GoogleCodeExporter]

Running update for all projects might be reasonable regardless of failure, but 
making missing sources/javadocs a warning instead of an error is dependent on 
Ivy, which I don't think supports it.

This is unlikely to be implemented before some point in 0.9.x.  You can write a 
withSources wrapper that can easily be disabled or you can do something like:
  override def updateAction = super.updateAction dependsOn( allUpdates )

where allUpdates is something like:
  topologicalSort.dropRight(1).map { case mp: ManagedProject => mp.update }
but with the details properly handled.

Original comment by dmhar...@gmail.com on 1 Nov 2010 at 2:57

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Weird that Ivy doesn't support it since it's the default behaviour for Maven 
plugins that download sources and javadocs. I also ran into this issue a while 
ago and added a quick and dirty workaround (a hardcoded list of dependencies 
for which withSources is not added).

Original comment by ismaelj on 14 Nov 2010 at 1:49

[GoogleCodeExporter]

Aggregation has been implemented for 0.9.  I've made it so that if project A 
has an aggregate dependency on B and you run task T in A, both T in A and T in 
B are scheduled to be executed, but without T in A depending on T in B.  (Does 
that make sense?)

This fixes the issue concerning running update in all projects regardless of 
failure (and it will also address the issue concerning 'test' that I think was 
mentioned on the mailing list).

Original comment by dmhar...@gmail.com on 22 Feb 2011 at 12:50

[GoogleCodeExporter]

To be clear, "without T in A depending on T in B" means that T in A will not 
fail if T in B fails?

Original comment by ismaelj on 22 Feb 2011 at 8:03

[GoogleCodeExporter]

Correct.  The overall build will fail, though.

Original comment by dmhar...@gmail.com on 22 Feb 2011 at 11:46

[GoogleCodeExporter]

I see. I think that works well enough for interactive usage (a failed build 
during update is close to harmless in that scenario if it runs to completion), 
but it would still be an issue for usage in a CI like Hudson. I guess one could 
make withSources conditional on something that is not true in the CI build. 
That is an improvement over what can be done now then.

Original comment by ismaelj on 22 Feb 2011 at 3:56

[GoogleCodeExporter]

To clarify, I wasn't trying to say that this will resolve the original issue, 
only alleviate it in the interactive case, as you say.  I will look at sources 
and javadocs handling.  It would help if you could state precisely what 
behavior you expect or want related to sources/docs handling.  Transitive 
downloads, invoke as a separate action or configure as part of normal 
dependency specification, etc...

Thanks,
Mark

Original comment by dmhar...@gmail.com on 22 Feb 2011 at 4:28

• Changed state: Accepted
• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Possibly of interest:
http://code.google.com/p/simple-build-tool/issues/detail?id=92#c5

Original comment by dmhar...@gmail.com on 14 Mar 2011 at 3:55

[GoogleCodeExporter]

Implemented as update-classifiers command in 0.9.2.  No error is generated if 
download of some sources/javadocs fails.

https://github.com/harrah/xsbt/commit/4a8e79befbb53f85e53423d24cad431b72b7f341

Original comment by dmhar...@gmail.com on 16 Mar 2011 at 2:18

• Changed state: Fixed

[GoogleCodeExporter]

Great stuff Mark. Thanks! Looking forward to 0.9.2. Would you say that it's a 
good time to port relatively complex multi-module projects from 0.7.x or still 
a bit early?

Original comment by ismaelj on 16 Mar 2011 at 2:26

[GoogleCodeExporter]

Hey Ismael,

I think the implementation is almost there but the documentation is not.  
Additionally, there are no plugins yet, I'm not sure what I'm doing with the 
jetty support, and error handling is poor.

If you want, list the main features you will need or link to your build 
definition, and I'll make a guess.  Otherwise, let's say 0.9.3 or 0.9.4.  At 
least error handling should be more reasonable by then.

-Mark

Original comment by dmhar...@gmail.com on 16 Mar 2011 at 2:33

[GoogleCodeExporter]

Thanks Mark, very useful information. I don't want to take your time, so I'll 
briefly play with 0.9.2 with the understanding that it may still be early and 
that I may not complete the port until 0.9.3 or 0.9.4. And sorry for hijacking 
the bug. :)

Original comment by ismaelj on 16 Mar 2011 at 2:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Trying out 0.9.2 isn't necessarily discouraged and certainly not feedback on 
it.  It is just that a complex multi-module project is likely to run into 
issues, including lack of documentation.  I mean these only as 
expectation-lowering comments and not discouraging anyone from taking my time.  
I need feedback to get 0.9.x stable and so ongoing feedback from porting 
efforts is valuable to me.

Thanks,
Mark

Original comment by dmhar...@gmail.com on 17 Mar 2011 at 2:56