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

Drop the sample extension #2300

Closed
wetneb opened this issue Jan 27, 2020 · 9 comments · Fixed by #6484
Closed

Drop the sample extension #2300

wetneb opened this issue Jan 27, 2020 · 9 comments · Fixed by #6484
Assignees
Labels
maintainability Making it easier to maintain OpenRefine maven Configuration of our build system using Maven

Comments

@wetneb
Copy link
Sponsor Member

wetneb commented Jan 27, 2020

We have a sample extension which is meant to demonstrate the basic scaffolding to get a minimalistic extension to work.

This is not super useful since we already have quite a lot other extensions in the repository, which are actually maintained since they expose functionality that people use. There is a risk is that this extension does not get updated (because breaking it does not actually break anything for users).

Also, as an extension developer, I generally want to develop my extension in its own repository, with its own build system. The Maven set up for extensions included in this repository is not easy to translate to extensions developed outside the repository, since our own set up relies on the main OpenRefine classes being present in the reactor at build time.

Once #2254 is done, it should be easier to propose a clean Maven setup for external extensions. We could move the sample extension to a dedicated repository, which was created a long time ago but remained empty:
https://github.com/OpenRefine/refine-sample-extension

@wetneb wetneb added maintainability Making it easier to maintain OpenRefine maven Configuration of our build system using Maven labels Jan 27, 2020
@darecoder
Copy link
Member

@wetneb: Hi, I would like to work on this issue if it's not already taken. Thanks.

@wetneb
Copy link
Sponsor Member Author

wetneb commented Mar 12, 2020

Concerning rearranging the source into new modules and namespaces, I have done that in 4.x and was thinking about keeping the 3.x release series with the current architecture. But I guess we could already publish the main module on Maven to make this issue easier. What do you think?

@darecoder
Copy link
Member

Sounds good to me. It will be easier after the release is published to Maven central.

@darecoder
Copy link
Member

@wetneb Are we still waiting for the release to start working on this?

@wetneb
Copy link
Sponsor Member Author

wetneb commented Mar 12, 2020

Unless you have ideas about how to do this without releasing to Maven, I would wait for this, yes.

@darecoder
Copy link
Member

@wetneb: I suggest for a nightly release for this to proceed. Otherwise, I can release a snapshot that can be replaced later.

@wetneb
Copy link
Sponsor Member Author

wetneb commented Mar 13, 2020

Sure, go for it then :)

@wetneb wetneb changed the title Migrate sample extension to own repository Drop the sample extension Mar 26, 2024
@wetneb
Copy link
Sponsor Member Author

wetneb commented Mar 26, 2024

Changing the title of this issue to reflect the opinion I voiced in #6426 (comment)

@wetneb wetneb self-assigned this Mar 26, 2024
wetneb added a commit to wetneb/OpenRefine that referenced this issue Mar 26, 2024
@wetneb
Copy link
Sponsor Member Author

wetneb commented Apr 24, 2024

I think it would still be useful to have a basic scaffold that people could use to start their own extensions, so I copied the sample extension to a dedicated repository here:
https://github.com/OpenRefine/sample-extension

tfmorris pushed a commit that referenced this issue May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintainability Making it easier to maintain OpenRefine maven Configuration of our build system using Maven
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants