#36 - Adding the ability to retrieve cached wheel files from poetry cache

[JeffreyRoss]

Orphedomos orchestrates and executes docker builds as part of a maven process. It has a phase where it verifies the docker environment. The goal of this ticket to extend the habushu logic that retrieves cached wheel files into orphedomos for the purpose of establishing python environments within a given docker image. Extending the retrieveWheels logic will allow orphedomos to define wheel dependencies needed for a docker image.

By extending this mojo the following configuration is now available:

wheelDependencies
Optional set of wheel dependencies to retrieve from poetry cache. This allows previously cached external wheel dependencies to be copied into a given target directory if it exists in poetry cache. This logic depends on wheels to have first been cached by cacheWheels habushu-maven-plugin configuration and executes during the VALIDATE maven phase. Warnings will be logged if the specified wheel isn't found.

  <plugin>
      <groupId>org.technologybrewery.orphedomos</groupId>
      <artifactId>orphedomos-maven-plugin</artifactId>
      <version>0.9.0-SNAPSHOT</version>
      <executions>
          <execution>
              <id>retrieve-wheels</id>
              <phase>validate</phase>
              <goals>
                  <goal>retrieve-wheels</goal>
              </goals>
              <configuration>
                  <wheelDependencies>
                      <wheelDependency>
                          <artifactId>foundation-core-python</artifactId>
                          <targetDirectory>${wheelOutputDirectory}</targetDirectory>
                      </wheelDependency>
                  </wheelDependencies>
              </configuration>
          </execution>
      </executions>
  </plugin>

[cpointe-ibllanos]

S: Do we still want this pointing to a snapshot?

[JeffreyRoss]

Yes, the snapshot is the only version that has the functionality needed at this time. This will be updated in the future to a release version when it's published.

[jacksondelametter]

It looks like you are just extending a new mojo in Orphedomos from Habushu but since its identical, why not just use the mojo from Habushu since your not adding any new functionality?

[cpointe-ibllanos]

I imagine this is done to get it to run in the Validate lifecycle

[JeffreyRoss]

Originally Habushu's logic insisted on the calling project's packaging to be "habushu" only in order to execute otherwise it would not run. My particular use cases in aissemble are orphedomos projects. However, the 2nd code change was needed to bypass this packaging logic so actually I think I could probably achieve my goal without this orphedomos change. Let me consider.

[JeffreyRoss]

Yes it looks like it'll be best for this functionality to be extended in orphedomos so i'll leave it here. @cpointe-ibllanos @jacksondelametter

[jacksondelametter]

It might be a good idea to add a property for the version in pom file since I see this changing quite a bit!

[JeffreyRoss]

Under normal circumstances a variable would make sense but this particular instance is the only instance of habushu in orphedomos and once habushu releases the version will be removed.