Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Artifactory publishing without the maven product info in the path #198

Open
tabboud opened this issue Mar 16, 2021 · 2 comments · May be fixed by #346
Open

Support Artifactory publishing without the maven product info in the path #198

tabboud opened this issue Mar 16, 2021 · 2 comments · May be fixed by #346

Comments

@tabboud
Copy link
Contributor

tabboud commented Mar 16, 2021

What happened?

The Artifactory publisher only allows publishing to a destination that includes the full Maven product info as part of the path

https://artifactory.p.b/artifactory/<publish-repo>/<group>/<product>/<version>/<artifact>

Link to source where this is gathered:

productPath := publisher.MavenProductPath(productTaskOutputInfo, groupID)

The group-id is also a required argument, but I assume the reason it is required is due to the fact that it's always included in the destination path, as seen above.

groupID, err := publisher.GetRequiredGroupID(flagVals, productTaskOutputInfo)

What did you want to happen?

It should be possible to publish artifacts to artifactory with just the desired publish-repo rather than force the destination path to include the Maven product info.

Possible Solution

We can introduce another flag to the Artifactory publisher that allows it to publish to a flat hierarchy rather than inject the product info in the path.

https://artifactory.p.b/artifactory/<publish-repo>/<artifact>

By default, this flag can be false in that the existing behavior would be used. If set to true, then we would no longer inject the product info and just concatenate the desired published-repo with the artifact name.
We can continue to keep the group-id required in both situations, but it would only be used in the existing code path.

@nmiyake
Copy link
Contributor

nmiyake commented Mar 16, 2021

Thanks for documenting this -- definitely understand the issue, and I'm actually encountering something similar with the GitHub publisher.

I think there are basically 2 high-level approaches:

  1. Add flags/modes that cover the scenarios we want (as described above, flag would control whether or not group ID is included)
  2. Take an approach like we do for resolvers where we accept a template string that is appended after the base upload URL and allows users to basically specify how the URL is constructed and expose things like "group ID", "product" and "version"

We could also add both, although then we may have to make some decisions about how the different flags/settings interact with each other (or just support invocation in one mode versus another).

Given that historically we've seen good returns from standardization/locking down customization to some degree, the first approach (which aligns with what you suggested as well) may make more sense, although the second approach does provide more flexibility in scenarios where users may want more control over the naming/destination of their uploads.

@bmoylan
Copy link
Contributor

bmoylan commented Mar 29, 2023

@nmiyake @tabboud I've opened #346 with a proposed resolution: a flat-dir boolean option which omits the maven directories. Let me know what you think!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants