[Meta] Mechanism to publish the plugin zips to maven repo. #1916

prudhvigodithi · 2022-04-06T12:46:55Z

Is your feature request related to a problem? Please describe

With current setup the plugins zips that are used as dependencies cannot be downloaded dynamically during runtime, as they are not part of version controlled maven system. Only the respective Java jars are available to download using maven coordinates.
More details on #716

Describe the solution you'd like

Publish the release candidate zips, distribution build zips (snapshots) to maven repo, so that a user who is dependent on the plugin zip, can download using maven coordinates. There needs to be a process implemented for uploading zips to snapshot and release repos

Proposed Solution [1]:
With the current build system the plugin zips are stored under builds/plugins/, these are not stored or ordered in maven folders, so that maven can publish them with right artifactID, groupID and version.

for each plugin use install:install-file to create the maven coordinates and publish them to local file system maven repo, passing the right artifactID, groupID and version along with proper qualifier if required.
Then from local file system publish them to respective snapshot or release repos, adhering to existing workflows.

To achieve this integrate this solution with existing CI.

Proposed Solution [2]: ---> (The chosen one)
Add a gradle sub-project in each component, so that root gradle project can include them, that converts the zips generated inside distribution folder to maven format, then publish them to local maven repo and staging repo, this way all the maven coordinate's (groupID, artifactID, version) generation and other maven heavy lifting is done at component (plugin) level and using CI with already existing code, publish them to maven nexus repo.

Additional context

For Proposed Solution [1]:
Need to come up with an idea to add either a python script, a groovy shared library or a gradle sub tasks for publishing the zips.

Snapshot zips:

Upload the snapshot plugin zips to https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/plugin/
<plugin_name>/-SNAPSHOT/<.zip_file>
Edit the plan https://github.com/prudhvigodithi/opensearch-build/blob/slack-publish-v1/jenkins/opensearch/distribution-build.jenkinsfile#L82 to upload zips to nexus maven repo

Release zips:
The Release candidates will be signed before staging to make sure files are unaltered.

Also there needs to be an additional tags inside the POM as example for the zips pom file
https://aws.oss.sonatype.org/service/local/repositories/releases/content/org/opensearch/common-utils/1.0.0.0/common-utils-1.0.0.0.pom
Create a staging repo nexus-staging:rc-open this will create a new new staging repository on the remote Nexus
Upload zips from the local filesystem to a staging repository using plugin in built deploy-staged-repository
Close the created staging repo nexus-staging:rc-close

For Proposed Solution [2]:
Add the gradle subproject to each repo and include in root project, for the generated zip to get published to local staging maven repo.

Implementation tasks

Associated Issues

Publish plugin distribution ZIPs to Maven, get rid of checked in snapshot builds #716

Issue with integrating the gradle java custom plugin:

[BUG] Integrating gradle custom plugin, does not get pickup by downstream repos. OpenSearch#3025

opensearch-plugin-template-java jdk and gradle version version upgrade

[FEATURE] Upgrade gradle version to 7.3.3 and java version to 17 opensearch-plugin-template-java#30

Document Create

[FEATURE] Add Readme doc with details about gradle custom plugins. opensearch-plugins#143

Campaign Issues:

Associated PR's

With custom plugin:

Plugin design and usage doc

Add details for gradle custom plugin. opensearch-plugins#144

opensearch-plugin-template-java jdk and gradle version version upgrade

Upgrade gradle version to 7.3.3 and java version to 17 opensearch-plugin-template-java#29

opensearch-plugin-template-java add opensearch.pluginzip details to template

Added opensearch.pluginzip plugin opensearch-plugin-template-java#31

Related Plugin Issues

SQL plugin [BUG] Configure project name for gradle subproject in plugin/ folder. sql#660

The text was updated successfully, but these errors were encountered:

dblock · 2022-04-06T13:57:57Z

Looks like a dup of #716

prudhvigodithi · 2022-04-06T14:10:00Z

Hey @dblock, since there are two aspects for this maven publish, one for snapshots repo and other for actual release repo, the two repo workflows are not constant, as release repo has more wider process, like pre staging, promoting, signing, additional maven tags and then releasing, so I have created a meta issue #1916 that expands with more details based on the issue #716.
Right now the snapshot zips for maven snapshot repo, does not have an enforced workflow to publish a zip, unlike the actual release repo, so I have separated into two tasks for snapshot plugin zips and release plugin zips and together tracked in #1916.

dblock · 2022-04-06T18:53:02Z

The proposal in this issue is attempting to re-create a separate maven publishing process for any set of ZIPs. This may not be what we want.

Each plugin already publishes artifacts to maven. For example, job-scheduler publishes job-scheduler-spi.jar. This is done following these instructions. It seems to make sense to extend the publication of the JAR to include other artifacts, such as the distribution ZIP. This can be accomplished by adding artifact to https://github.com/opensearch-project/job-scheduler/blob/main/spi/build.gradle#L106. Running ./gradlew publishShadowPublicationToStagingRepository will include the artifact in the output in build/local-staging-repo/org/opensearch/opensearch-job-scheduler-spi/2.0.0.0-alpha1-SNAPSHOT (I tried with a dummy file). That output already gets picked up by the distribution process and makes it to maven. The missing parts are 1) assemble (produce ZIP) before publishing, 2) add all the distribution ZIPs created as artifacts. This isn't necessarily trivial (seems to introduce a circular dependency in tasks).

@mch2 @reta have mucked with all of this quite a bit, maybe you have better ideas?

prudhvigodithi · 2022-04-06T19:26:09Z

Thanks @dblock, more over looks to me your solution is like working backward, with this we need to add this logic across all repo components to have the zips published in same way, but it will ease of not re-doing the mvn publishing process again.

reta · 2022-04-06T20:05:53Z

@dblock I am hesitating a bit to acknowledge that publishing plugin ZIPs to Maven repositories is a good idea (it is certainly possible - no doubts). But from other side - how people are supposed to use it? It looks to me we should align the publishing (at least, of the standard plugins) with the opensearch-plugin tooling: the plugin ZIP (snapshot / release / ...) should end up in the catalog and be downloadable from there.

In scope of this issue, if you need those dependencies in Maven projects - the direct URL to the catalog could be used along with plugin (fe [1]), they should not be only artifacts. Also, it covers well external 3rd party plugins, often hosted on Github and not published to Maven repos (afaik).

Hope I didn't introduce the confusion, what do you think?

[1] https://github.com/maven-download-plugin/maven-download-plugin

dblock · 2022-04-06T21:29:49Z

@reta I think as a consumer I would ideally want to do something like this in Gradle:

dependencies {
    opensearchPlugin 'org.opensearch.job-scheduler:2.0-SNAPSHOT'
}

Latest snapshot build job-scheduler-2.0-SNAPSHOT.zip would be downloaded from Maven and automatically installed into an integration test cluster before I run integTest. All this support would be implemented in Gradle in OpenSearch min.

Is this crazy?

Something like maven-download-plugin works well as a middle-ground solution, but @prudhvigodithi it looks like you chose the maven route, I imagine you have a clear idea of how those artifacts will be used?

And yes, #1823 is waaay less work for similar effect where you just download from a latest URL similar to opensearch-project/anomaly-detection#487, "by hand".

prudhvigodithi · 2022-04-06T21:48:42Z

Hey @dblock, I see this PR overrides the requirement to download a zip in a maven way, it uses directly GET protocol to download the latest zip, also as suggested by @reta maven-download-plugin download different files on different protocol and this can connect with above change, a user can download straight from URL without giving maven coordinates as

        <uri>https://example.com/file1.zip</uri>
        <uri>https://example.com/file2.zip</uri>
        <uri>https://example.com/file3.zip</uri>
        <!-- and so on -->
    </uris>

So from consumer perspective if we can document this we can skip zips publish to maven, else once its in maven a user can always download using maven coordinates as well as with GET protocols.
@bbarani @peterzhu1992

dblock · 2022-04-06T22:03:38Z

Once ZIPs are published to maven the URL will be changing every time, you'll need to be able to resolve something like https://aws.oss.sonatype.org/service/local/repositories/snapshots/content/org/opensearch/opensearch-job-scheduler-spi/2.0.0.0-alpha1-SNAPSHOT/opensearch-job-scheduler-spi-2.0.0.0-alpha1-20220406.220005-79.zip (here's the jar published today). So the solution in that PR doesn't work. It does look like maven-download-plugin does this, but I've never used it in gradle.

reta · 2022-04-06T22:10:51Z

@reta I think as a consumer I would ideally want to do something like this in Gradle:
dependencies {
    opensearchPlugin 'org.opensearch.job-scheduler:2.0-SNAPSHOT'
}
Latest snapshot build job-scheduler-2.0-SNAPSHOT.zip would be downloaded from Maven and automatically installed into an integration test cluster before I run integTest. All this support would be implemented in Gradle in OpenSearch min.

Is this crazy?

No, it is not, but:

what about Maven / SBT / ... build tools?
where the opensearch-plugin downloads plugins from?

Something like maven-download-plugin works well as a middle-ground solution, but @prudhvigodithi it looks like you chose the maven route, I imagine you have a clear idea of how those artifacts will be used?

There are plenty of projects which use this route (publishing ZIP/TAR/...), it is on the table for sure and it works. BUT that would mean, very likely, we have to ask all external plugin authors to do that for their plugins (and as such, they would have to look for publishing options).

prudhvigodithi · 2022-04-06T22:11:29Z

@dblock I dont see date format is added to zips with current setup, the plugins are just dumped as regular files without date, so you are saying if we add ./gradlew publishShadowPublicationToStagingRepository it will add date as well to the zip, just like it adds for jar ?, but gradle should always pull the latest if we pass org.opensearch.job-scheduler:2.0-SNAPSHOT even though there are multiple date formatted zips, also I guess it would be better to add plugins under https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/plugin/

dblock · 2022-04-06T22:17:29Z

@dblock I dont see date format is added to zips with current setup, the plugins are just dumped as regular files without date, so you are saying if we add ./gradlew publishShadowPublicationToStagingRepository it will add date as well to the zip, just like it adds for jar ?, but gradle should always pull the latest if we pass org.opensearch.job-scheduler:2.0-SNAPSHOT even though there are multiple date formatted zips, also I guess it would be better to add plugins under https://aws.oss.sonatype.org/content/repositories/snapshots/org/opensearch/plugin/

Yes, it will add the date to the file name, that's how maven works for snapshots. Take a look at https://aws.oss.sonatype.org/service/local/repositories/snapshots/content/org/opensearch/opensearch-job-scheduler-spi/2.0.0.0-alpha1-SNAPSHOT/, that's all the artifacts for many snapshot builds. To find out what the latest one is, maven looks in this file. Regardless of how you publish to maven, SNAPSHOT builds will end up having a date/time in the filename. While you can disable it, there's no folder called "latest", so you'd have hard time getting a direct download URL to the latest build.

When we publish a final released version of 2.0, there's only 1, so maven doesn't need to append the date or anything.

dblock · 2022-04-06T22:20:05Z

> > Is this crazy?

No, it is not, but:

what about Maven / SBT / ... build tools?

Maven could use maven-download-plugin, etc. Either way we're only debating whether ZIPs are published like JARs in maven, or they are published as ZIPs somewhere else. We can do both and let people decide what they like.

where the opensearch-plugin downloads plugins from?

It piggybacks on maven repository resolution 100%. It's effectively a fancy wrapper over (the equivalent of) maven-download-plugin, a syntax sugar that knows to install the plugin into an OpenSearch cluster before running integ tests.

But maybe that's just over-engineering ...

reta · 2022-04-06T22:39:19Z

@dblock sounds good, as far as different tools pull ZIPs consistently using same conventions, we could use Maven as the distribution mechanism.

prudhvigodithi · 2022-04-07T19:57:07Z

Hey @dblock, I have tested the idea to work backward from individual repo, to be able to add assembled zip's also to maven format just like how the jars are added. I was able to do this Draft. Please check the following implementation steps

Directly publishing the plugins zips in to current maven repo(the place where the jars are published ), would cause some problem, as it appends with -spi suffix, but the distribution zip (actual plugin does not create this way), we should actually separate the maven coordinates for the plugins, rather that having same maven articatID, groupID and version just like the jar files. Example taking the zip as default and passing it as another zip artifact in line

Now separating out the maven coordinates for plugin Zips, Since we are using shadow plugin to publish, as per the functionality it will publish both the sourcesJar and the javadocJar (along with the shadowjars), along with the zip ----> we need to remove those 2 jars as it will duplicate the sourcesJar and the javadocJar,
Example if seen the below screenshot, we are seeing the sourcesJar and the javadocJar are pushed twice

Since we dont need those sourcesJar and the javadocJar files for zip's, and we since we also cant exclude in with shadow publishing, I have added a quick shortcut, to clean them using find cli, this will not update the metadata.xml file generate for the local repo.

Now with this a user should be able to download opensearch-job-scheduler plugin zip with maven coordinates as

  <groupId>org.opensearch.plugin</groupId>
  <artifactId>opensearch-job-scheduler</artifactId>
  <version>2.0.0.0-alpha1-SNAPSHOT</version>

The above values of groupId, artifactId, version are all inherited from default job-scheduler build system, as all heavy lifting is already been done here.
@bbarani @peterzhuamazon @reta

reta · 2022-04-07T20:43:08Z

Thanks for the update @prudhvigodithi ,

Now separating out the maven coordinates for plugin Zips, Since we are using shadow plugin to publish, as per the functionality it will publish both the sourcesJar and the javadocJar (along with the shadowjars), along with the zip ----> we need to remove those 2 jars as it will duplicate the sourcesJar and the javadocJar,
Example if seen the below screenshot, we are seeing the sourcesJar and the javadocJar are pushed twice

I think there should be a way to strip those artifacts (javadoc and sources) from ZIP publishing without CLI scripting. May be we should strip them by default and only configure with JAR publisher?

dblock · 2022-04-07T20:44:46Z

I like the draft! I obviously dislike the custom elimination of sources and jar, which is hopefully something that can be disabled in shadow. Then, job scheduler has this spi vs. non-spi build gradle so this may be muddying the waters. Should this be going into root buld.gradle? Should this be in the distribution gradle? A new subfolder dedicated to publishing the zip to maven?

I think you should iterate on a PR into job-scheduler for this and let's see if we can merge something?

prudhvigodithi · 2022-04-08T12:35:06Z

@reta, yes we can directly push them with jar, then all the zips, jar javadoc and sources jars's will be under same maven location, which could confuse users to use those zip plugins, hence I wanted to separate the maven location for plugin zips, there already exists plugin prefix.

ya thats a good point @reta I have this question as well, do we actually use these javadoc and sources jars's ? @dblock @bbarani @reta
If not we dont need to publish them, I see for example opensearch-ml-client does not have these javadoc and sources jars's (it depends on app to app as well).

@dblock I liked the idea for a new subfolder, let me explore this and yes my idea was 1st once we have the job-scheduler working, then we can have the same implementation for other components as well. 👍

reta · 2022-04-08T12:40:12Z

ya thats a good point @reta I have this question as well, do we actually use these javadoc and sources jars's ?

they are useful for developers (for example if you develop a plugin which depends on another plugin), so it is better to have them published.

@dblock I liked the idea for a new subfolder, let me explore this and yes my idea was 1st once we have the job-scheduler working, then we can have the same implementation for other components as well.

We could actually follow the other projects and publish ZIPs as -distribution artifacts, fe [1]

[1] https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.4.9.v20180320/

prudhvigodithi · 2022-04-08T12:43:47Z

Cool, thanks for the info @reta
I found something, I actually dont see these javadoc and sources jars's for opensearch-job-scheduler as well, but I so see them on my local when I build them.

prudhvigodithi · 2022-04-08T12:58:14Z

I see whats happening so this block of code eliminates from uploading them :)
So I guess its useful @reta but looks like the main jar is itself built with all dependancies, please correct me if i'm wrong
@dblock @reta

reta · 2022-04-08T13:13:38Z

@dblock @prudhvigodithi since I am lacking the context here, sorry for possible derailing, but using custom made scripts for publishing artifacts is not what the community (since we are discussing the plugins) would expect: gradle publish (and its variations) should be enough and the only way (imho)

mch2 · 2022-04-08T19:09:06Z

Wanted to chime in with a few callouts & questions.

@dblock @prudhvigodithi since I am lacking the context here, sorry for possible derailing, but using custom made scripts for publishing artifacts is not what the community (since we are discussing the plugins) would expect: gradle publish (and its variations) should be enough and the only way (imho)

Agree 100%. This stems from a current limitation with our signing process not wired into gradle. So the build system builds and pushes the artifacts that are then after the fact picked up, signed, and promoted with these scripts.

I see whats happening so this block of code eliminates from uploading them :)

We've had an issue out for killing this script for a while. We should be pushing directly from gradle publish. It doesn't look like we are signing every snapshot build so we don't have the limitation there. I'm thinking maybe we can update the opensearch publish plugin to automatically give all plugins a task to push snapshots, and they only have to define their maven publication.

As far as placing maven publications in the same group/artifact id with different packaging. I'm hesitant about this because I'm not sure the jars produced by each plugin match the produced plugin zips that are installed today. Job-scheduler-spi vs job-scheduler as an example. Meaning the artifact is inherently different and not simply differentiated by packaging type. If this is the case I think we should treat them as two separate artifacts under the same group ID.

I would also explore updating the publish plugin with a task where all plugins need to specify is the output path of the zip and any plugin specific fields required in the pom (scm etc). That task could then generate the pom and publish in one go. This would make it easier to onboard and less custom logic in each plugin script.

prudhvigodithi · 2022-04-08T21:41:46Z

Hey @dblock, @reta, please check this Draft, I have modified to add the zip publish task to root gradle project. With this I see the maven coordinates for zip plugin being created as Example

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.opensearch.plugin</groupId>
  <artifactId>opensearch-job-scheduler</artifactId>
  <version>2.0.0.0-alpha1-SNAPSHOT</version>
  <packaging>zip</packaging>
  <name>OpenSearch Job Scheduler Plugin zip</name>
  <url>https://github.com/prudhvigodithi/job-scheduler.git</url>
  <scm>
    <url>https://github.com/prudhvigodithi/job-scheduler.git</url>
  </scm>
  <inceptionYear>2021</inceptionYear>
  <licenses>
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>
  <developers>
    <developer>
      <name>OpenSearch</name>
      <url>https://github.com/opensearch-project/job-scheduler</url>
    </developer>
  </developers>
</project>

Since this is added as part of root project, we call a task publishAllPublicationsToStagingRepository that by default checks for all maven publish tasks.
I have also added a flag ext.publish = 'skip', just in case in future if a user wants to disable to publish the zips to maven

So my plan is to get this merged to job-scheduler and with no other code change we should be see job-scheduler plugin zips under nexus maven repo plugin location.

prudhvigodithi · 2022-04-08T21:46:23Z

As far as placing maven publications in the same group/artifact id with different packaging. I'm hesitant about this because I'm not sure the jars produced by each plugin match the produced plugin zips that are installed today. Job-scheduler-spi vs job-scheduler as an example. Meaning the artifact is inherently different and not simply differentiated by packaging type. If this is the case I think we should treat them as two separate artifacts under the same group ID.

Hey @reta, thats true, we should not use same groupID for different package types, I have separated the zips's as

  <groupId>org.opensearch.plugin</groupId>
  <artifactId>opensearch-job-scheduler</artifactId>
  <version>2.0.0.0-alpha1-SNAPSHOT</version>

downsrob · 2022-05-17T21:23:33Z

@prudhvigodithi dB looks to be blocking that PR until all plugins get this change in to avoid adding custom logic to the default build script, but that would mean introducing a custom build script in every plugin, then changing the default build script and then removing the custom build script from each plugin. I would prefer to only add the publishing zip task for plugins with the default build script, and then once all plugins have onboarded, the default build script can change to introduce the change without requiring an interim build script for all plugins.

dblock · 2022-05-18T12:35:49Z

What @downsrob is proposing works fine as well - get all plugins to onboard without adding a custom build script, then change the default to enable it for everyone.

prudhvigodithi · 2022-05-18T14:00:07Z

Hey @dblock @downsrob, if I understood correct, 1st make sure all plugins use the gradle plugin opensearch.pluginzip (make all changes in build,.gradle file as per document) without executing the task publishPluginZipPublicationToZipStagingRepository and then make change to default build.sh to add publishPluginZipPublicationToZipStagingRepository, is that what the suggestion is ? if this is the case, the zip's wont be published, as the task publishPluginZipPublicationToZipStagingRepository should be called out to ensure the zips are published.

dblock · 2022-05-18T14:48:20Z

Hey @dblock @downsrob, if I understood correct, 1st make sure all plugins use the gradle plugin opensearch.pluginzip (make all changes in build,.gradle file as per document) without executing the task publishPluginZipPublicationToZipStagingRepository and then make change to default build.sh to add publishPluginZipPublicationToZipStagingRepository, is that what the suggestion is ?

Yes

if this is the case, the zip's wont be published, as the task publishPluginZipPublicationToZipStagingRepository should be called out to ensure the zips are published.

i am not sure i understand what you’re saying :) once you’ve added the task to the default build.sh without conditionals it will work for all plugins

Note that the default script is still used for older versions, so we may not be able to modify it after all

prudhvigodithi · 2022-05-18T15:10:25Z

I'm fine until all plugins are onboarded to use opensearch.pluginzip and then include in default build.sh file (Each plugin team should test publishPluginZipPublicationToZipStagingRepository locally and merge the PR), but the catch here is the plugins team should also backport the changes to older versions if not it would break the old versions when the default build.sh is called that has new added task publishPluginZipPublicationToZipStagingRepository.
The other better way is create a build.sh file to each plugin and manage the assemble and publish tasks, this could be a starting point for this change, but it would benefit long term as each plugin team can manage the set of tasks to run during build process and we can keep the generic default build.sh for infrastructure automations, thoughts? @downsrob @dblock @bbarani @peterzhuamazon

downsrob · 2022-05-18T17:00:22Z

If you want a published zip of the older versions anyways, say, for BWC testing, then I can see the merit in backporting the task to all versions and moving on. However, it seems natural that eventually the default build.sh would no longer encompass all versions, if not from this change, maybe the next. What do you think about versioning the default script on the infra side?

dblock · 2022-05-18T18:29:34Z

If you want a published zip of the older versions anyways, say, for BWC testing, then I can see the merit in backporting the task to all versions and moving on. However, it seems natural that eventually the default build.sh would no longer encompass all versions, if not from this change, maybe the next. What do you think about versioning the default script on the infra side?

That's proposed in #1975, add your comments there.

I want to make sure we don't try to solve the kitchen sink at the same time, so maybe cloning the default build script for your plugin is the most expedient path?

prudhvigodithi · 2022-07-08T18:55:00Z

Starting with release 2.1.0, we now have plugin zips in maven repo
Moving forward plugin zips can be fetched for dependencies using maven coordinates.
alerting
anomaly-detection
asynchronous-search
reports-scheduler
index-management
job-scheduler
k-NN
performance-analyzer
security
sql
observability
cross-cluster-replication
ml-commons

Thank you

prudhvigodithi · 2022-07-21T20:18:29Z

Closing this META as associated tasks are marked as complete, please feel free to re-open this issue if required. :)
Thank you

@dblock @CEHENKLE @bbarani

prudhvigodithi added enhancement New Enhancement untriaged Issues that have not yet been triaged labels Apr 6, 2022

prudhvigodithi self-assigned this Apr 6, 2022

prudhvigodithi removed the untriaged Issues that have not yet been triaged label Apr 6, 2022

This was referenced Apr 6, 2022

Sign and Upload the release plugin zips to nexus maven release repo. #1918

Closed

Upload the distribution snapshot plugin zips to nexus maven snapshot repo. #1917

Closed

martin-gaievski mentioned this issue May 18, 2022

Use custom plugin to publish zips to maven opensearch-project/k-NN#400

Merged

1 task

Zhangxunmt mentioned this issue Jun 10, 2022

Use custom plugin to publish zips to maven opensearch-project/ml-commons#343

Merged

This was referenced Jun 13, 2022

Publish plugin ZIPs to artifacts.opensearch.org #1823

Closed

Automate publishing plugins zips to artifacts repository #184

Closed

This was referenced Jun 16, 2022

publish releases to maven aparo/opensearch-analysis-ik#1

Open

publish releases to maven Aiven-Open/prometheus-exporter-plugin-for-opensearch#64

Open

lukas-vlcek mentioned this issue Jun 22, 2022

[BUG] Custom POM configuration for ZIP publication produces duplicit tags (url, scm) opensearch-project/OpenSearch#3649

Closed

This was referenced Jun 24, 2022

[BUG] zipGroup is hardcoded to "org.opensearch.plugin" opensearch-project/OpenSearch#3692

Closed

[BUG] Configure project name for gradle subproject in plugin/ folder. opensearch-project/sql#660

Closed

tlfeng mentioned this issue Jul 13, 2022

[BUG] Set language to Chinese opensearch-project/OpenSearch-Dashboards#1898

Open

prudhvigodithi closed this as completed Jul 21, 2022

prudhvigodithi mentioned this issue Jul 24, 2022

OpenSearch Plugin zips in maven repo opensearch-project/project-website#929

Closed

prudhvigodithi mentioned this issue Aug 9, 2022

Use the project.group value for Zip POM groupId value opensearch-project/OpenSearch#4156

Merged

5 tasks

prudhvigodithi mentioned this issue Aug 29, 2022

[Campaign] opensearch.opensearchplugin add groupID field to org.opensearch.plugin #2521

Closed

19 tasks

reta mentioned this issue Sep 15, 2022

[FEATURE] How does one release a generic plugin? opensearch-project/opensearch-plugin-template-java#36

Open

jmazanec15 mentioned this issue Oct 5, 2022

Add dependency on k-NN plugin opensearch-project/neural-search#10

Merged

3 tasks

prudhvigodithi mentioned this issue Dec 31, 2023

[FEATURE] Publish opensearch-knn jar opensearch-project/k-NN#1351

Closed

rursprung mentioned this issue Nov 15, 2024

[Feature Request] publish core plugin ZIPs also to maven opensearch-project/OpenSearch#16656

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Meta] Mechanism to publish the plugin zips to maven repo. #1916

[Meta] Mechanism to publish the plugin zips to maven repo. #1916

prudhvigodithi commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

dblock commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

reta commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

prudhvigodithi commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

reta commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

dblock commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

reta commented Apr 6, 2022

prudhvigodithi commented Apr 7, 2022 •

edited

Loading

reta commented Apr 7, 2022

dblock commented Apr 7, 2022

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

reta commented Apr 8, 2022

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

reta commented Apr 8, 2022

mch2 commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022

downsrob commented May 17, 2022

dblock commented May 18, 2022

prudhvigodithi commented May 18, 2022

dblock commented May 18, 2022 •

edited

Loading

prudhvigodithi commented May 18, 2022 •

edited

Loading

downsrob commented May 18, 2022

dblock commented May 18, 2022

prudhvigodithi commented Jul 8, 2022 •

edited

Loading

prudhvigodithi commented Jul 21, 2022

[Meta] Mechanism to publish the plugin zips to maven repo. #1916

[Meta] Mechanism to publish the plugin zips to maven repo. #1916

Comments

prudhvigodithi commented Apr 6, 2022 • edited Loading

Is your feature request related to a problem? Please describe

Describe the solution you'd like

Additional context

Associated Issues

Associated PR's

dblock commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

dblock commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

reta commented Apr 6, 2022 • edited Loading

dblock commented Apr 6, 2022 • edited Loading

prudhvigodithi commented Apr 6, 2022 • edited Loading

dblock commented Apr 6, 2022 • edited Loading

reta commented Apr 6, 2022

prudhvigodithi commented Apr 6, 2022

dblock commented Apr 6, 2022 • edited Loading

dblock commented Apr 6, 2022 • edited Loading

reta commented Apr 6, 2022

prudhvigodithi commented Apr 7, 2022 • edited Loading

reta commented Apr 7, 2022

dblock commented Apr 7, 2022

prudhvigodithi commented Apr 8, 2022 • edited Loading

reta commented Apr 8, 2022

prudhvigodithi commented Apr 8, 2022 • edited Loading

prudhvigodithi commented Apr 8, 2022 • edited Loading

reta commented Apr 8, 2022

mch2 commented Apr 8, 2022 • edited Loading

prudhvigodithi commented Apr 8, 2022 • edited Loading

prudhvigodithi commented Apr 8, 2022

downsrob commented May 17, 2022

dblock commented May 18, 2022

prudhvigodithi commented May 18, 2022

dblock commented May 18, 2022 • edited Loading

prudhvigodithi commented May 18, 2022 • edited Loading

downsrob commented May 18, 2022

dblock commented May 18, 2022

prudhvigodithi commented Jul 8, 2022 • edited Loading

prudhvigodithi commented Jul 21, 2022

prudhvigodithi commented Apr 6, 2022 •

edited

Loading

reta commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

prudhvigodithi commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

dblock commented Apr 6, 2022 •

edited

Loading

prudhvigodithi commented Apr 7, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

mch2 commented Apr 8, 2022 •

edited

Loading

prudhvigodithi commented Apr 8, 2022 •

edited

Loading

dblock commented May 18, 2022 •

edited

Loading

prudhvigodithi commented May 18, 2022 •

edited

Loading

prudhvigodithi commented Jul 8, 2022 •

edited

Loading