Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
How to implement other Processing libraries in the right way?
I'm working on a Processing library that makes use of the oscP5 library and I'm now unsure how to implement it in the best way.
The description of the Processing Library Template for Eclipse recommends to ship the library including all other jars being used. While looking through a couple of other libraries I couldn't find one that ships with another Processing library.
So is it still a good recommendation in this case? I wonder if this might clash with other instances of oscP5 that users might use in their sketches? How can I avoid this? Is it a better idea to pass a reference of the sketches oscP5 instance from the sketch into the library, similiar to what's mostly being done with the parent PApplet?
Thanks a lot!
Answers
Toxiclibs is a kind of an example, it ships as a suite of independent libraries. However many of the the libraries are kind of dependent on each other. As are many of the included examples. A dependency on a third party library is kind of tricky if you can live with the current version of that library you are OK (until the other developer has a rethink and totally refactors it that is...).
Thanks for your answer! I can live with the current version of oscP5. So your recommendation is simply to include the oscP5.jar into my library? I don't need to worry about major problems with other oscP5 instances?
If I keep a copy of the ocp5.jar in the library folder of my library I get this error:
Duplicate libraries found for oscP5.So should I just not ship the library with the current oscp5 version and add a note that oscP5 has to be installed separately?