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

Add support for ij.plugins.path #64

Closed
ctrueden opened this Issue May 1, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@ctrueden
Copy link
Member

commented May 1, 2014

ImageJ 1.x has a plugins.dir system property that controls the directory from which plugins are discovered. In ImageJ2 we will expand this feature to support multiple directories via an ij.plugins.path property or similar.

As an added bonus, this will aid in mitigating certain Eclipse limitations with plugin discovery. We can do a brute force scan of any JAR files that are A) present in ij.plugins.path; and B) missing up-to-date SezPoz metadata. In this way, we can avoid brute force scanning the entire Java classpath, which would be prohibitively slow.

Migrated-From: http://trac.imagej.net/ticket/1208

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented May 1, 2014

See the original ticket for additional commentary.

@dscho

This comment has been minimized.

Copy link
Member

commented May 2, 2014

Actually, I think this ticket can be closed. ImageJ2's plugin concept needs nothing in addition to the class path (because the annotation indices are discovered via the class path), and in the legacy part, we support ij1.plugin.dirs already...

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented May 6, 2014

OK, fine, I give up arguing for this feature. I will make a case for it again the first time a valid, concrete use case arises that needs it. Which I still suspect it will, but let's not put the cart before the horse.

@ctrueden ctrueden closed this May 6, 2014

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2014

@dscho

This comment has been minimized.

Copy link
Member

commented Jun 6, 2014

We do support ij1.plugin.dirs (falling back to $HOME/.plugins/) already in the launcher now. So: we're fine. Of course, if @carandraug has a good idea how to improve it, and preferably even offers a pull request, who am I to decline? ;-)

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2014

Thanks @dscho, I CCed @carandraug so he has a reference to the discussion and documentation on how to try the ij1.plugins.dirs option to meet his goal (which is a system-wide installation updatable by the admin, with user plugins in each user's home dir somewhere). We agreed that he would follow up later with a report on his experiences (and any questions, ideas for improvement, PRs, etc.).

@dscho

This comment has been minimized.

Copy link
Member

commented Jun 6, 2014

Well, I just want to prevent the idea that this is magically going to happen. I poured a massive amount of work into supporting ij1.plugin.dirs already. It is time for those who actually wanted this feature to step in and do a little bit of work themselves...

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2014

Don't worry; @carandraug and I had a couple of long chats and he definitely understands and appreciates that things do not magically happen. And besides, this issue is closed anyway. It would only be reopened if, as I said above, he offers a compelling use case for why it is needed, after trying the existing options and finding that they fall short.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.