Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Started adding custom artifact support to ivy-publish plugin (based on maven-publish support) - Added IvyArtifact and IvyArtifactSet - Replaced use of PublishArtifact with IvyArtifact - Added IvyPublication.artifact(source) and IvyPublication.artifact(source, config) - Added IvyArtifactNotationParser and various implementations of IvyArtifact for file/archive/publishArtifact

  1. … 29 more files in changeset.
Cleaned up configuration of descriptorFile on IvyPublication - Can no longer specify descriptorFile directly on publication, this is done by setting destination on GenerateIvyDescriptor task - Default destination is configured directly on GenerateIvyDescriptor task - GenerateIvyDescriptor task supplies ivy descriptor to IvyPublication as a PublishArtifact

  1. … 6 more files in changeset.
Codenarc fix

DefaultIvyModuleDescriptor is no longer Buildable - Wire generator task directly into DefaultIvyPublication - All dependencies of PublishToIvyRepository are managed via IvyPublication.getPublishableFiles()

  1. … 7 more files in changeset.
Moved XmlTransformer to a dedicated package.

  1. … 33 more files in changeset.
Replaced IvyModuleDescriptor.file with IvyPublication.descriptorFile

  1. … 6 more files in changeset.
Change the ivy module descriptor task name pattern to “generate«Publication-name»IvyModuleDescriptor”, using "" if the publication name is “ivy”.

  1. … 1 more file in changeset.
Don't have the IvyArtifactRepository create the IvyPublisher, use the DependencyResolver from it instead to create it.

This removes any trace of the new publishing stuff from core/coreImpl and allows some simplification.

We may find over time that this leads to some awkward duplication, but for the time being I'm favouring touching as little as possible in existing code.

  1. … 15 more files in changeset.
Some minor improvements too the thing that creates descriptor generation tasks for ivy publications.

    • -0
    • +95
    ./gradle/api/publish/ivy/tasks/internal/IvyPublicationDynamicDescriptorGenerationTaskCreatorTest.groovy
  1. … 1 more file in changeset.
Hoist the generation of the Ivy module descriptor up to a separate task.

  1. … 28 more files in changeset.
Rename “IvyRepositoryPublish” task to “PublishToIvyRepository”.

    • -0
    • +143
    ./gradle/api/publish/ivy/tasks/PublishToIvyRepositoryTest.groovy
  1. … 4 more files in changeset.
Change ivy-publish plugin to not create “main” things, and to use a different task naming strategy.

Changes:

1. The implicit publication is named “ivy” (reversion)

2. No repository is created by default (reversion)

3. Dynamically created tasks are named “publish«PUBLICATION NAME»PublicationTo«REPOSITORY NAME»Repository.

The task name leaves something to be desired.

  1. … 18 more files in changeset.
Add “publish” lifecycle task in “publishing” plugin for concrete publish tasks to hang off.

  1. … 8 more files in changeset.
Cleaned up the new ivypublish sample and test.

Also cleaned up some of the ivy test fixtures.

    • -0
    • +143
    ./gradle/api/publish/ivy/tasks/IvyRepositoryPublishTest.groovy
  1. … 18 more files in changeset.
Rename “IvyPublish#to” -> “IvyPublish#repo”.

  1. … 2 more files in changeset.
Move tests to live in the same package as what they test.

    • -143
    • +0
    ./gradle/api/publish/ivy/IvyPublishTest.groovy
    • -0
    • +143
    ./gradle/api/publish/ivy/tasks/IvyPublishTest.groovy
  1. … 4 more files in changeset.
Revert "Don't use a RepositoryHandler for publishing.repositories, use a named object container of ArtifactRepository."

This reverts commit 2a45f47d88797f4fe68e8953a340898d8a6ef29c (change rejected by review).

  1. … 9 more files in changeset.
Revert "Don't use a RepositoryHandler for publishing.repositories, use a named object container of ArtifactRepository."

This reverts commit 2a45f47d88797f4fe68e8953a340898d8a6ef29c.

Reverted due to failing test.

  1. … 9 more files in changeset.
Don't use a RepositoryHandler for publishing.repositories, use a named object container of ArtifactRepository.

This avoids a bunch of awkwardness that stems from the name of the repository being far more important in publication than consumption. It also avoids propagating the RepositoryHandler API to a new place.

When just the “publishing” plugin is applied, repositories cannot be created. When the “ivy-publish” plugin is applied, the container creates instances of IvyArtifactRepository. This is ok for the initial release because that's the only type that we can deal with. Looking forward, we'll need to expand the domain container stuff to be polymorphic.

  1. … 10 more files in changeset.
Don't use a RepositoryHandler for publishing.repositories, use a named object container of ArtifactRepository.

This avoids a bunch of awkwardness that stems from the name of the repository being far more important in publication than consumption. It also avoids propagating the RepositoryHandler API to a new place.

When just the “publishing” plugin is applied, repositories cannot be created. When the “ivy-publish” plugin is applied, the container creates instances of IvyArtifactRepository. This is ok for the initial release because that's the only type that we can deal with. Looking forward, we'll need to expand the domain container stuff to be polymorphic.

  1. … 9 more files in changeset.
Change the naming strategy for publish tasks to optimise for the common 1 publication 1 repository case.

Previously, the default publish task was named “publishIvyToIvy”, because the default publication was named “ivy” and the default repository was named “ivy”. This is pretty awkward.

The naming strategy has been changed to have the default publish task name be “publishToRepo”.

The pattern for publish tasks is “publish«capitalised publication name»To«capitalised repository name»Repo”, but where the name of a publication or repo is omitted if its name is “main”. This seems to work pretty well. See DefaultIvyPublishTaskNameCreatord for examples of how this plays out.

This relies on the “default” publication and repository being named “main”. This is a simple change for the publication (and makes sense), but gets complicated for the repository because of our whack RepositoryHandler DSL. An upcoming commit will attempt to deal with this.

This change also changes the semantics of the “ivy-publish” plugin. This will now be a framework plugin, where the framework is: “This project has a main publication of type Ivy that is published to a main Ivy repository”. At a later time, we will likely add an “ivy-publish-base” plugin that provides factories for creating IvyPublication objects etc. without being so presumptuous.

  1. … 16 more files in changeset.
Fix up how the Ivy publication expresses its publishable files and dependencies.

  1. … 1 more file in changeset.
Add package cycle checking to “ivy” and “publish” modules, and break up cycles.

  1. … 20 more files in changeset.
Rename IvyPublish#repository to “to” in accordance with the spec.

publish(type: IvyPublish) {

publication publishing.publications.something

to publishing.repositories.somewhere

}

  1. … 3 more files in changeset.
Add group and description values to automatically created IvyPublish tasks.

  1. … 1 more file in changeset.
Automatically create IvyPublish tasks for any compatible Ivy publication/repository pair.

It's a bit awkward that this means the task most people use will be called “publishIvyToIvy”.

  1. … 3 more files in changeset.
Some tweaks to the public API of the IvyPublication stuff to make it more coherent in the DSL.

  1. … 7 more files in changeset.
Remove generic Publish task, replaced with IvyPublish that is restricted to Ivy stuff.

This removed the need for any kind of abstract protocol for matching up things that can publish with certain publications (because we know the publication/repository combination is valid) so a bunch of interfaces that enabled this were removed.

    • -0
    • +142
    ./gradle/api/publish/ivy/IvyPublishTest.groovy
  1. … 20 more files in changeset.
Reuse the DependencyMetaDataProvider service, instead of ProjectBackedModuleFactory to get the Module for the Ivy publication.

There's a slight functional change here in that ProjectBackedModuleFactory was live WRT to changes in the project's values. However, the contract of the publication stuff is that a normalised publication is realised so this doesn't actually matter.

  1. … 4 more files in changeset.
Introduce an "ivy-publish" plugin that creates publishing.publications.ivy, hardwired to publish the “archives” configuration.

This is not the end game. Some of the remaining issues (for initial release):

- The Publish task is not created by the plugin

- The publishing semantics are the same as “uploadArchives” (not the long term goal)

    • -0
    • +68
    ./gradle/api/publish/ivy/IvyPublishPluginTest.groovy
  1. … 16 more files in changeset.