The git repo checks out and builds. All the tags appear to be present.
Gary
On Fri, Jul 8, 2016 at 11:28 AM, Gary Gregory
wrote:
> On Fri, Jul 8, 2016 at 11:08 AM, Kristian Rosenvold <
> kristian.rosenv...@gmail.com> wrote:
>
>> Maybe if you switch the url from commons-cvs to commons-csv :)
>>
Great - thanks for all the suggestions. I will investigate on Monday.
Mark
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Friday, July 08, 2016 4:18 PM
> To: Commons Developers List
> Subject: Re: How tell which BCEL release?
>
> Accessible from java.l
Accessible from java.lang.Package
Gary
On Fri, Jul 8, 2016 at 4:10 PM, sebb wrote:
> The Commons Parent pom includes various items in the jar manifest,
> including the following:
>
> Implementation-Version:
> Specification-Version:
>
> These are both set from project.version.
>
>
>
> On 8 July
The Commons Parent pom includes various items in the jar manifest,
including the following:
Implementation-Version:
Specification-Version:
These are both set from project.version.
On 8 July 2016 at 23:49, dbrosIus wrote:
> Typicaly one puts the version in the manifest
>
> Original me
Yes, the manifest. Or you can do a
class.getPackage().getImplementationVersion() IIRC.
Gary
On Jul 8, 2016 3:49 PM, "dbrosIus" wrote:
> Typicaly one puts the version in the manifest
>
> Original message
> From: Mark Roberts
> Date: 7/8/16 6:43 PM (GMT-05:00)
> To: 'Commons D
Typicaly one puts the version in the manifest
Original message
From: Mark Roberts
Date: 7/8/16 6:43 PM (GMT-05:00)
To: 'Commons Developers List'
Subject: How tell which BCEL release?
Now that BCEL 6.0 looks close, I'm wondering how a client can tell -
programmatically -
Now that BCEL 6.0 looks close, I'm wondering how a client can tell -
programmatically - which version of BCEL he is running against in order to
verify it is correct. Currently, we at PLSE add an extra, dummy class to the
release in order to do this. Our goal is to stop shipping our own versi
sebb wrote:
[snip]
> But longer term it might be better to release the JNI binaries
> separately from the Java binaries.
> This would allow new OSes to be added without having to re-release
> everything.
This one might help: http://maven-nar.github.io/
I've used a very old version of it several
On Fri, Jul 8, 2016 at 11:08 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> Maybe if you switch the url from commons-cvs to commons-csv :)
>
> https://git-wip-us.apache.org/repos/asf?p=commons-csv.git
>
> I was seing if you were paying attention! :-)
TY!
Gary
> K
>
>
> 2016-07-
On 8 July 2016 at 18:56, Gary Gregory wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul
> wrote:
>
>> On Fri, Jul 8, 2016 at 11:37 AM, sebb wrote:
>> > On 8 July 2016 at 18:31, Gary Gregory wrote:
>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin
>> wrote:
>> >>
>> >>> Answering ba
On Fri, Jul 8, 2016 at 10:56 AM, Gary Gregory wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul
> wrote:
>> One option could be to go the Eclipse way, the way they handle SWT
>> distributions which have native components[1].
>>
> Yeah, that seems like a more normal way to go.
It's fine t
Maybe if you switch the url from commons-cvs to commons-csv :)
https://git-wip-us.apache.org/repos/asf?p=commons-csv.git
K
2016-07-08 17:40 GMT+02:00 Gary Gregory :
> I notice that commons-compress is here:
>
> https://git-wip-us.apache.org/repos/asf/commons-compress.git
>
> But there is no
>
>
On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul
wrote:
> On Fri, Jul 8, 2016 at 11:37 AM, sebb wrote:
> > On 8 July 2016 at 18:31, Gary Gregory wrote:
> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin
> wrote:
> >>
> >>> Answering based on old knowledge of this code, but I don't believe it
On Fri, Jul 8, 2016 at 11:37 AM, sebb wrote:
> On 8 July 2016 at 18:31, Gary Gregory wrote:
>> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin wrote:
>>
>>> Answering based on old knowledge of this code, but I don't believe it
>>> has changed...
>>>
>>> On Fri, Jul 8, 2016 at 9:36 AM, Gary Grego
On Fri, Jul 8, 2016 at 10:37 AM, sebb wrote:
> On 8 July 2016 at 18:31, Gary Gregory wrote:
> > On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin
> wrote:
> >
> >> Answering based on old knowledge of this code, but I don't believe it
> >> has changed...
> >>
> >> On Fri, Jul 8, 2016 at 9:36 AM, G
On 8 July 2016 at 18:31, Gary Gregory wrote:
> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin wrote:
>
>> Answering based on old knowledge of this code, but I don't believe it
>> has changed...
>>
>> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory
>> wrote:
>> > The delivered jar file contains a n
On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin wrote:
> Answering based on old knowledge of this code, but I don't believe it
> has changed...
>
> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory
> wrote:
> > The delivered jar file contains a native .so file, and this .so file is
> > _extracted_ an
Answering based on old knowledge of this code, but I don't believe it
has changed...
On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory wrote:
> The delivered jar file contains a native .so file, and this .so file is
> _extracted_ and _installed_ on the user's machine at runtime? See
> NativeCodeLoader
Hi All,
This might be OK for 1.0 (with no Windows support) but I want to make sure
we are all on the same page because it seems incredibly complicated and
perhaps too clever.
The delivered jar file contains a native .so file, and this .so file is
_extracted_ and _installed_ on the user's machine
I notice that commons-compress is here:
https://git-wip-us.apache.org/repos/asf/commons-compress.git
But there is no
https://git-wip-us.apache.org/repos/asf/commons-cvs.git
?
Gary
On Thu, Jul 7, 2016 at 11:33 PM, Benedikt Ritter wrote:
> Hi all,
>
> the migration has been processed. Infra
2016-07-08 7:17 GMT+01:00 MBCRAFT :
> I don't know if it depends from the ftp server : i'm using vsftpd.
>
> I've followed that example, more or less, and i even didn't missed the
>
> FTP.NON_PRINT_TEXT_FORMAT , FTP.STREAM_TRANSFER_MODE , and
> FTP.FILE_STRUCTURE are the only supported formats, tra
21 matches
Mail list logo
