I can not find any link related with 2.1.5 from SourceForge. I wonder whether I can still use this version as a third party component in my product.
Any comment would be appreciated very much!
Sure you can. Search the web and you will find that version easily (e.g. here or here) It is a different question however whether you should still use that version. It is quite old and lots of bugs have been fixed and new functionality has been added. So do the following:
check the license restrictions (LGPL vs. AGPL)
if you don't have a problem with a GPL based license then use the latest 5.X version
if you can't use APGL buy a commercial license or use at least version 2.1.7
if you go the 2.1.7 route do some testing - in many cases it will do its job still fine. If not you'll probably have to fix it by yourself
Update: I would now use openPDF which is a maintained fork based on 2.1.7.
Related
I'd like to use ag-grid community in plain JS project, which could be commercial soon. I don't know much about license policies.
From documentation I could suggest that community library is stored here?
src="https://unpkg.com/ag-grid/dist/ag-grid.min.noStyle.js
Further, I'm intersted in Tree Data (Legacy) feature, which is free. But it's source library looks like:
src="https://unpkg.com/ag-grid-enterprise#18.1.1/dist/ag-grid-enterprise.min.js
Am I breaking the license rules using this feature? How should I use it correctly? What if I use enterprise lib in non-commercial project, would it work?
You can indeed use the old tree data implementation without the enterprise version, there's a quote I didn't notice before which sums it up:
https://www.ag-grid.com/javascript-grid-tree-data/
How Tree Data is managed in ag-Grid was changed in ag-Grid v14. This
page presents the new way of working with Tree Data. The old way was
part of ag-Grid free, the new way is part of ag-Grid Enterprise. The
old way is deprecated but you can still use it, but we will not be
enhancing it. For documentation on the older version of the grid prior
to v14 see Tree Data (Legacy).
In their demo of old tree data, the JavaScript file used should really be the "community" version instead of the enterprise one. They just use the enterprise version in all demos to make it easier.
downloaded a book from the below link
https://www.owasp.org/images/7/79/ESAPI_Book.pdf
The book is depended on the esapi-3.10 version. But i am not able to find esapi-3.1.0.jar.
Where can find the respective jar.
Thank you.
~Shyam
Actually, it probably was a typo, but more likely it was supposed to say ESAPI 1.3 rather than 3.1. That's even about a year before I got involved with ESAPI. If you notice the date for this was 2008 and I just checked and release 1.3 was made available in Sept 2008.
So, in other words, this ESAPI book is really ancient history. And the previous answer is correct in that the latest official release is 2.1.0. The 2.1.1 release is almost done but because of other commitments (e.g., GSoC), it will likely be awhile until it is released unless I get some volunteers to assist.
-kevin
Notify OWASP. The most recent version of esapi is 2.1.0. This is a typo.
I am using iTextSharp version 4.1.2 and cannot update to newer version because iText changed
their licence agreement.
I am very satisfied with this version and it's working fine for me.
I can't find anywhere how to produce pie or bar or columns graphs and charts
with that version and looks like all documentation over the internet been removed.
If you are using older version and by the chance you have documentation can you please share
or point me to the source, or explain how?
iText doesn't have built-in support for charts or graphs. Instead you are encouraged to use a 3rd-party library to generate these and then add them as either graphics or PDFs.
Another option as outlined in this post is to use the iTextSharpExtensions. Please note that although it has the word "iText" in it is in no way endorsed by the makers of iText.
Also, as a quick side note, please read FAQ, specifically the "Why shouldn't I use iText 2.x (or iTextSharp 4.x)?" explaining some of the myths of the license of the version you are using.
TortoiseCVS comes with bundled CVSNT binaries.
The older version(s) came with CVSNT 2.5.03, which turned out to have a security vulnerability.
The latest version (1.12.5) comes with CVSNT 2.5.05 that has several issues:
It nags with pop-ups that urge you to buy the commercial version.
It inserts advertisements into commit notes.
It has a bug that leaves Windows command-line consoles in a messed-up state.
The sources (GPL) are not easily obtainable.
Some references:
- What is going on with CVSNT?
- Batch scripts no longer work?
Recently, somebody posted this to the TortoiseCVS mailing list:
i found the sources and made the following fixes
version_fu.h - set the "suite" flag to avoid popups and advertisement
win32.cpp - saved the original codepage and restored it on exit
take it from http://www.mediafire.com/?ys93oh4bdj1auby
only the cvsnt.dll needs to be compiled
I downloaded the sources and tried compiling them. Unfortunately they seem to need quite a number of other packages (openssl, iconv, mysql, postgres, etc... I lost count) that are open source but still need to be hunted for...
Combined with my limited time and the lack of tools (I don't have VS2008) I gave up on the effort to build it myself.
I tried contacting the author of the message, but he is in a similar position (and does not use CVSNT anymore).
Contacting the TortoiseVCS maintainer also proved fruitless:
That is not a project I am going to undertake.
TortoiseCVS is very low on my list of priorities these days.
If anybody is willing to build the "fixed" CVSNT.DLL from the provided sources, and make it available, I would greatly appreciate it!
Thanks,
Alex.
Sure - you can get it here - compiled in a single installer which includes TortoiseCVS and the latest CVSNT code with lots of bug fixes:
http://march-hare.com/cvsnt/features/tortoise/
The small fee we charge is to cover our costs of developing and distributing the software including the license fees for MSDN and financial contributions to related projects such as the TortoiseCVS project, Bugzilla project, FSF etc. etc. The source code is included in the price.
Remember that Free Software is about Freedom (like the Free Press) not about price:
http://www.gnu.org/philosophy/free-sw.html
I am on Linux(Ubuntu) with OpenCV 2.4 installed. I am try to use Eclipse to create an opencv project. When I build the project, I got collect2: ld returned 1 exit status error which I guess is caused by missing libs. Then I put libraries in this project, but I find every lib has three very similar brothers, like:
libopencv_highgui.so
libopencv_highgui.so.2.4
libopencv_highgui.so.2.4.0
So, which one should I add to project libraries? And what's the different between them?
Best Regards.
libopencv_highgui.so and libopencv_highgui.so.2.4 are probably symbolic links to libopencv_highgui.so.2.4.0.
Libraries frequently do this so that software that needs to link against specific versions can while keeping the generic library also exposed.
This is mainly useful when a program to be linked against a major or minor version of a library. Consider if a legacy application needed to link against version 1.2 of libopencv_highgui. The program couldn't link against libopencv_highgui.so because that's not guaranteed to be the correct version. However, the program could link against libopencv_highgui.so.1.2. libopencv_highgui.so.1.2 may be a symbolic link to libopencv_highgui.so.1.2.3, but that would be ok since the third number usually means a minor bug fix that won't break compatibility.
So this brings up which file you should link against. This really depends. Unless you need to depend on some bug or quirk of a specific minor revision, I would definitely avoid linking against the 2.4.0 one. That ties your program specifically to version 2.4.0. When 2.4.1 gets released (or trickles down your distro's package manager), it probably won't break your program.
If you link against libopencv_highgui.so and then 2.5 is installed as the main lib (and then libopencv_highgui.so links to libopencv_highgui.so.2.5.0), there is a chance that your program will not link correctly since the second number does sometimes mean compatibility changes.
So in short, if it's a personal project, just link to whatever you want. libopencv_highgui.so is probably safe if it's personal. If it's going to be distributed, figure out what versions of the library your code will link properly against and then use the vaguest one possible. For example, if your code works with 2.2, 2.3 and 2.4, you should go ahead and link to libopencv_highgui.so. If it only works specifically with 2.4.0, you should link with libopencv_highgui.so.2.4.0. If it will work with any sub revision of 2.4, you should go with libopencv_highgui.so.2.4.
Basically you have to make a choice about what you think will link properly on the most people's setups.
I think I make some mistake here. What I need is these libraries, But when I add them into project libraries. YOU SHOULD USE THESE NAMES, for the library I mentioned in the question, we should add opencv_highgui in to eclipse libraries dependency but libopencv_highgui.so.2.4. For the future use, I write these stuff here.