Re: Next-level packaging of curl for Windows
On Fri, 18 Dec 2020, Ray Satiro via curl-library wrote: What is the issue tracking this? I think the wiki should link to that issue. This is probably the best one: https://github.com/curl/curl/issues/5424 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Next-level packaging of curl for Windows
On 12/17/2020 4:30 PM, Daniel Stenberg via curl-library wrote: The curl project received the suggestion to package the official curl binary we produce for Windows in a signed installer. In the long term this package could be used by Microsoft to ship our official curl binary instead of a custom build which lacks features and stays behind in terms of changes and fixes. If you want to help out making this happen, we'll appreciate your help as this project is right now pretty much stallling. More details here: https://github.com/curl/curl/wiki/Packaging-for-Windows What is the issue tracking this? I think the wiki should link to that issue. I couldn't find it searching. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Next-level packaging of curl for Windows
On 12/17/2020 3:30 PM, Daniel Stenberg via curl-library wrote: Hello! The curl project received the suggestion to package the official curl binary we produce for Windows in a signed installer. In the long term this package could be used by Microsoft to ship our official curl binary instead of a custom build which lacks features and stays behind in terms of changes and fixes. If the project is already tooled to create .msi installers, then its easy, just by adding an extra step you create the MSIX from the MSI (using MS provided tools). If you want to help out making this happen, we'll appreciate your help as this project is right now pretty much stallling. I have experience with packaging my application. Started with open source tools, but ended with a commercial tool made free to open sourced projects. More details here: https://github.com/curl/curl/wiki/Packaging-for-Windows Seems a complete description, and a good plan to follow. The signing key used to be free to open source projects, haven't checked but myself ended paying a little for one (special price for OSS). -- R.Berber --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Next-level packaging of curl for Windows
Hello! The curl project received the suggestion to package the official curl binary we produce for Windows in a signed installer. In the long term this package could be used by Microsoft to ship our official curl binary instead of a custom build which lacks features and stays behind in terms of changes and fixes. If you want to help out making this happen, we'll appreciate your help as this project is right now pretty much stallling. More details here: https://github.com/curl/curl/wiki/Packaging-for-Windows -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: packaging
On Thu, 04 Jun 2009 11:18:39 +0200, Patrick Monnerat wrote: In any event, I ran into some path problems in building the RPM because, to get the latest Java code, I used: wget http://dev.gknw.com/viewvc/curl-java-root.tar.gz Thufir, I think you are mixing RPMs, tarballs and SVN: 1) The URL Guenter gave you is not the one above. If you really want to use tarball dynamic generation feature of ViewVC directly from wget, use URL http://dev.gknw.com/viewvc/curl-java-root.tar.gz?root=curl-javaparent=1 view=tar. But be aware this is definitely not a distribution tarball. In particular, it contains the whole SVN directory structure and buildconf has not yet been applied to the contents. 2) You are trying to use the old spec file with the new non-distro tarball. I didn't know what the mismatch, but wanted to get the new JAR. Thanks, it seems to have worked out: [r...@arrakis i386]# [r...@arrakis i386]# rpm -ivh curl-java-0.2.3.SVN-2.i386.rpm Preparing...### [100%] 1:curl-java ### [100%] [r...@arrakis i386]# [r...@arrakis i386]# [r...@arrakis i386]# rpm -qa curl-java-0.2.3.SVN-2.i386 [r...@arrakis i386]# jar -tf /usr/share/java/curljava.jar META-INF/ META-INF/MANIFEST.MF net/ net/haxx/ net/haxx/curl/ net/haxx/curl/CurlGlue.class net/haxx/curl/CurlIO.class net/haxx/curl/CurlRead.class net/haxx/curl/CurlWrite.class I'll play around with it later :) -Thufir
RE: packaging
Guenter wrote: shouldnt we now also re-organize the files in SVN into subdirs to reflect the new structure? I don't think so. I managed the makefiles to avoid using the directory tree in usage with java, keeping the configure+make+make install strategy, because we (i.e.: non-java programmers) are all more familiar with this gnu approach. In particular, I would avoid using things like ant and/or eclipse for compiling this little thing ! You probably have to tune the non-automake makefiles a little bit, but I took care about them without being able to test ! Patrick
RE: packaging
Daniel Stenberg wrote: is there a reason that the Java classes don't belong to a package? I now assume you speak about a java binding to libcurl. They all make their own packages and releases of their projects. I don't think the java one is any different. Just make a package and put it somewhere. If you tell us about it we can link to it from the libcurl/java page on the curl site. Daniel, I think you've misunderstand what Thufir speeks about when he writes package: in this context, this word does not mean a collection like a rpm or deb file, but rather the java package feature: this is a code structure above the class, and a java reserved word (Thufir, correct me if I'm wrong). The problem with the current curl-java bindings is: if the called class (CurlGlue) is not packaged (in the sense of java package), then the calling class cannot be packaged. The reverse is not true. This problem is particularly annoying because most java development platforms (like eclipse) requires you to package your classes. I already have prepared a (java-)packaged version of the java bindings for curl, and sent them to Guenter for evaluation (this was months ago: I think he's very busy); this version works properly here and I'm waiting for Guenter's green light to commit it. But this is a major change, since it breaks what we can call the Java ABI. I'm not a java specialist, but I had to deal with this problem for java people at our office, as the local libcurl maintainer ;-) Patrick P.S.: Guenter, if you have some time...
Re: packaging
On Tue, 02 Jun 2009 09:00:44 +0200, Daniel Stenberg wrote: On Tue, 2 Jun 2009, Thufir wrote: is there a reason that the Java classes don't belong to a package? I now assume you speak about a java binding to libcurl. Yes, I believe so. All the bindings to libcurl for all languages except the native C one are products and projects that are written and maintained outside of the core cURL project. There are well over 30 different ones at this time. Some are very advanced and capable, while some are very barebones and rough. They all make their own packages and releases of their projects. I don't think the java one is any different. Just make a package and put it somewhere. If you tell us about it we can link to it from the libcurl/java page on the curl site. From what I know, some people have tried to get a javacurl project in the past at several occasions but none of the efforts ever took off particularly well. The 'javacurl' project at sourceforge being one such example. Ah, right. I think it makes the most sense to do the binding work within a context of people who use the language you're doing the binding for. In this case that would be java people. You don't typically find that kind of people here, on this list. Ok, I understand that this isn't a Java list :) I'm not entirely sure that I follow the other aspects of your reply. the Java code seems to invoke curl.h, from the comments, which is fine. So, in a sense, it's just a wrapper to provide an API for Java? Specifically, [thu...@arrakis Desktop]$ tar -xf curl-java-0.2.3.tar.gz [thu...@arrakis Desktop]$ [thu...@arrakis Desktop]$ head -n 13 curl-java-0.2.3/MakeCurlGlue.java /* ** Ugly hack from a Java newbie to fetch the curl defines from the ** curl.h header for creating a list inside the CurlGlue JNI class. ** Reads a preprocessed compiler output from STDIN and parses with ** a regex for the wanted defines, then writes them to STDOUT. ** Initial version 2008-01-26 hacked by Guenter. ** ** $Id: MakeCurlGlue.java 42 2008-10-20 09:27:21Z patrick $ */ import java.io.*; import java.util.regex.*; public class MakeCurlGlue [thu...@arrakis Desktop]$ between the import statements and class declaration generally there's generally a package declaration, as: package net.gknw.curl; I'm no Java expert, but by not specifying a package, effectively putting classes into the default package, seems to make it difficult to import these classes and use the API (at least for my skill level). Specifically, looking at Test.java, there are no import statements (or, rather, they're commented out). Perhaps I'll look into checking out the Java bindings from CVS and tweak them a bit, I think it simply needs a package declaration. -Thufir
RE: packaging
Guenter wrote: Thufir: once Patrick has checked into SVN you can checkout here: http://dev.gknw.com/viewvc/?root=curl-java as you can see ViewVC offers to download tarballs directly from SVN; but you can also checkout directly via https: https://dev.gknw.com/repos/curl-java/trunk/ The update is commited. Thufir, you can checkout now. The java package is named net.haxx.curl, so you have to update your calling classes to import net.haxx.curl.* Remember that files, jar and libraries are not compatible with the previous version: you have then to recompile and reinstall all objects from the curl-java package. Please also note that the configure script (if you use it) requires the Sun JDK. In particular, it does not work (yet) with the Fedora-installed java development environment. Good luck. Patrick
Re: packaging
On Tue, 02 Jun 2009 19:00:33 +0200, Guenter wrote: the Java class hack was my idea mainly for Win32 platform where we dont want to have the Java developers install Perl only for building the libcurl binding; the original script was writen in Perl: http://dev.gknw.com/viewvc/trunk/MakeCurlGlue.pl? view=markuprevision=42root=curl-java #!/usr/bin/perl # Hack to create CurlGlue.java from curl.h Pardon, but is this code supposed to generate a .java file? At least, this is how I read the comment. Just curious, if so it's an unconventional approach. -Thufir
Re: packaging
On Tue, Jun 2, 2009 at 10:26 PM, Thufir hawat.thu...@gmail.com wrote: [...] I'm not clear on the flow chart here. Previously I (somewhat randomly) built and installed an RPM which in turn installed a JAR onto my system (Fedora). However, I *think* that I'm only really after the JAR so that I can use the ABI in my Java code as I would any other Java library. This is not line any other Java library. Most Java libraries do not rely on JNI to talk to native code. Since curl-java is a Java wrapper for the cURL library (which is a C library) it uses JNI. This is why you need those .so files as well. As I said in the other thread, the Jar file by itself is not enough. That test.java class looks exactly like what I'm after. I'll probably rebuild the RPM, not that big of a deal, but I don't really understand the point of making an RPM out of cURL as cURL is already This is not an RPM of cURL, it's an RPM of curl-java (including the Jar and the .so files it depends on.) The RPM packages them all up together so that they can be installed/uninstalled/upgraded as a unit. installed via the package manager (for me, yum). It seems that the purpose of the Java JAR was to obviate the need to install Perl on Windows to use cURL? Wheras, I'm just after the JAR for the ABI (I think). -- Michael Wood esiot...@gmail.com
Re: packaging
Hi, Thufir schrieb: I'll probably rebuild the RPM, not that big of a deal, but I don't really understand the point of making an RPM out of cURL as cURL is already installed via the package manager (for me, yum). It seems that the purpose of the Java JAR was to obviate the need to install Perl on Windows to use cURL? Wheras, I'm just after the JAR for the ABI (I think). you're mixing things up a bit. MakeCurlGlue.java is a helper class only needed during build, and this was hacked by me in order to avoid installing Perl on Win32 platforms where its not always just there as it is on Linux. This helper class has nothing to do with the jar, nor with the binding itself, it just creates the java file during build process. The jar is good for dealing with only one file; its nothing more than a zip-like archive or the classes. Gün.
Re: packaging
Hi Patrick, Patrick Monnerat schrieb: The update is commited. Thufir, you can checkout now. shouldnt we now also re-organize the files in SVN into subdirs to reflect the new structure? Gün.
packaging
is there a reason that the Java classes don't belong to a package? -Thufir
