* Attempt to set publication date to last modified time, if the stars align
* Issue warning about undefined resolution behavior otherwise
* Add scripted test which exercises the NPE issue in resolving -SNAPSHOTs.
* Commit scalariform style edit in Act.scala
* After parsing and transforming the pom, check for pub date.
* If we don't have a pub date, try to grab lastModified from the URL
* If we can't do anything, issue a warning about the problem artifact.
When dealing with Java APIs (Java reflection in case of ClassToAPI), one
should always go through Option.apply that performs null check.
This is supposed to fix NPE reported in #1617. We don't have a reproduction
so this is just an educated guess.
The optimization, and therefore the change in the behavior
of Relation, is now needed by the class Logic, and cannot
be reverted.
This patch (written by Josh) therefore changes the
implementation of setAll() so that _1s is no longer used.
This represents a sketch of the idea that we can abstract over details
of a specific dependency kind. The goal would that only a few
implementations of methods in incremental would be sensitive to specific
dependency kind:
1. Dependency extraction logic
2. Implementation of Relations which adds dependencies to specific
relations (or abstract over specific relations)
3. Invalidation algorithm (Incremental.scala) which has different
of each kind of dependency
4. TextAnalysisFormat
In particular, adding a new dependency kind would not affect signatures
of existing methods.
What needs to be done:
- finish refactoring so the code compiles again and previous semantics
are preserved
- introduce deprecated overloads that preserve old method signatures
(this is required for preserving binary compatibility)
The previous implementation of TextAnalysisFormat contained the list
of all the existing relations that sbt knew of, and used this
information to write to and read from the disk the persisted analyses.
In this knew implementation, TextAnalysisFormat gets from the
Relations object what are the existing relations, and then persists
them to disk.
The previous situation was not optimal since it meant that, in order
to add a new dependency kind, one had to modify both the Relations
and TextAnalysisFormat.
Using this new implementation, no change to TextAnalysisFormat is
required whenever a new dependency kind is added.