1. 08 Jul, 2014 10 commits
  2. 07 Jul, 2014 4 commits
  3. 03 Jul, 2014 3 commits
    • Andy Wilkinson's avatar
      Further enhancements to Gradle repackaging logic · 1ffdc90f
      Andy Wilkinson authored
      This commit refines the changes made under 4be688aa. 4be688aa made the
      default jar task a special case which broke repackaging of the archive
      produced by the default war task.
      
      This commit refines RepackageTask’s logic so that, when it’s enabled,
      it will repackage a jar task’s archive if:
      
      - The jar task is equal to RepackageTask.withJarTask
      - The name of the jar task is equal to RepackageTask.withJarTask
      - RepackageTask.withJarTask is null, the jar task is not referenced
        by another RepackageTask’s withJarTask, and the jar task has an
        empty classifier
      
      The last of these three is the default case and ensures the, when the
      Spring Boot plugin is applied, default jar and war artifacts are
      repackaged. The classifier check is required to prevent default source
      and javadoc artifacts from being repackaged.
      
      Fixes #1204
      1ffdc90f
    • Andy Wilkinson's avatar
      Ensure that spring-boot-starter-ws pulls in the right version of Spring · fdc3d70c
      Andy Wilkinson authored
      Prior to this commit, when used with Gradle, spring-boot-starter-ws was
      pulling in the versions of spring-jms, spring-oxm, and spring-tx that
      Spring WS depends upon, rather than using the Boot’s Spring version.
      It’s ok at the moment as both Boot and Spring WS depend on Spring 4.0.5
      but will cause problems if we upgrade to 4.0.6 before Spring WS does.
      
      This commit adds explicit dependencies on spring-jms and spring-oxm so
      that Gradle pulls in the correct version (as long as a transitive
      dependency doesn’t pull in a version that’s greater than the version
      Boot’s using).
      fdc3d70c
    • Andy Wilkinson's avatar
      Fix Gradle repackaging so it is only performed on the desired jars · 4be688aa
      Andy Wilkinson authored
      The logic that determined whether or not the repackaging action should
      be applied to a particular jar task was broken and caused problems
      when a custom RepackageTask was used in a project's build.
      
      This commit updates the logic so that repackaging will be applied:
      
       - To the default jar task if RepackageTask.withJarTask is null
       - To a jar task if it is equal to RepackageTask.withJarTask
       - To a jar task if its name is equal to RepackageTask.withJarTask
      
      Repackaging is not applied if:
      
       - RepackageTask.enabled is false
      
      Numerous integration tests have been added to verify the repackaging
      behaviour.
      
      Fixes #1204
      4be688aa
  4. 02 Jul, 2014 8 commits
  5. 01 Jul, 2014 5 commits
  6. 30 Jun, 2014 1 commit
  7. 28 Jun, 2014 1 commit
  8. 27 Jun, 2014 8 commits