[Proposals] Rename jars file, release 1.7.0

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2
Hi,

I would like to propose two changes:

(1) Rename archetype produced by Maven and happens 'grizzly' for the
jar, e.g.:

http-1.7.0.jar would becomes grizzly-http-1.7.0.jar
framework-1.7.0 would becomes grizzly-framework-1.7.0.jar
etc.

(2) Pending Scott proposal and Jruby/DoS issues we are currently
discussing, I would like to cut 1.7.0 release tomorrow or Monday. We
have added significant numbers of new features as an official release is
probably required :-) Based on Ken proposal, I would like to jump from
1.6.1 to 1.7.0. I would then integrate 1.7.0 in a variety of products
like GlassFish v3, Sailfin, Jersey, Jetty, etc. I will be on the road
for the next two weeks and having an official release to demonstrate for
  the Grizzly's Javapolis talk will be nice :-)

What peoples thinks? Everybody (not only commiters) can talk!

-- Jeanfrancois

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Alan Williamson
prefixing "grizzly" is a nice bonus, and gives confidence we are
actually downloading the right beast!

Jeanfrancois Arcand wrote:
> Hi,
>
> I would like to propose two changes:
>
> (1) Rename archetype produced by Maven and happens 'grizzly' for the
> jar, e.g.:
> What peoples thinks? Everybody (not only commiters) can talk!
>
> -- Jeanfrancois

--
Alan Williamson
  "a wiki -and- a blog" @ http://www.Blog-City.com/

  b: http://alan.blog-city.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

charlie hunt-4
+1

Do we currently include a release number of Grizzly within the grizzly
jar file(s) ?

charlie ...

Alan Williamson wrote:

> prefixing "grizzly" is a nice bonus, and gives confidence we are
> actually downloading the right beast!
>
> Jeanfrancois Arcand wrote:
>> Hi,
>>
>> I would like to propose two changes:
>>
>> (1) Rename archetype produced by Maven and happens 'grizzly' for the
>> jar, e.g.:
>> What peoples thinks? Everybody (not only commiters) can talk!
>>
>> -- Jeanfrancois
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2


charlie hunt wrote:
> +1
>
> Do we currently include a release number of Grizzly within the grizzly
> jar file(s) ?

The maven artifact (jar) contains, under the META-folder, that
information. Do you think that's enough?

-- Jeanfrancois

>
> charlie ...
>
> Alan Williamson wrote:
>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>> actually downloading the right beast!
>>
>> Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> I would like to propose two changes:
>>>
>>> (1) Rename archetype produced by Maven and happens 'grizzly' for the
>>> jar, e.g.:
>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>
>>> -- Jeanfrancois
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Alan Williamson

Jeanfrancois Arcand wrote:
>> Do we currently include a release number of Grizzly within the grizzly
>> jar file(s) ?
>
> The maven artifact (jar) contains, under the META-folder, that
> information. Do you think that's enough?

is there any milage in making that information available via a class call?

public class Grizzly {
   public static int Grizzly.getMajorVersion(){ return 1; }
   public static int Grizzly.getMinorVersion(){ return 7; }
}

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

charlie hunt-4
In reply to this post by Jeanfrancois Arcand-2
Jeanfrancois Arcand wrote:
> charlie hunt wrote:
>> +1
>>
>> Do we currently include a release number of Grizzly within the
>> grizzly jar file(s) ?
>
> The maven artifact (jar) contains, under the META-folder, that
> information. Do you think that's enough?

Yes :-)

charlie ...

>
> -- Jeanfrancois
>
>>
>> charlie ...
>>
>> Alan Williamson wrote:
>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>> actually downloading the right beast!
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Hi,
>>>>
>>>> I would like to propose two changes:
>>>>
>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>> the jar, e.g.:
>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>
>>>> -- Jeanfrancois
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Harsha Godugu
In reply to this post by Jeanfrancois Arcand-2
Jeanfrancois Arcand wrote:

>
>
> charlie hunt wrote:
>> +1
>>
>> Do we currently include a release number of Grizzly within the
>> grizzly jar file(s) ?
>
> The maven artifact (jar) contains, under the META-folder, that
> information. Do you think that's enough?
May not be enough :-)
Can we make it a bit simpler. Like providing a script or runtime api to
know the current version of Grizzly.
(This should check the checksum of the said Grizzly jar and then if and
only if the checksum is matches the released/promoted jar , it should
output the current version of Grizzly at that instant. Else, it should
say fingerprints do not match !)

-hg

>
> -- Jeanfrancois
>
>>
>> charlie ...
>>
>> Alan Williamson wrote:
>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>> actually downloading the right beast!
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Hi,
>>>>
>>>> I would like to propose two changes:
>>>>
>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>> the jar, e.g.:
>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>
>>>> -- Jeanfrancois
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2
In reply to this post by Alan Williamson


Alan Williamson wrote:

>
> Jeanfrancois Arcand wrote:
>>> Do we currently include a release number of Grizzly within the
>>> grizzly jar file(s) ?
>>
>> The maven artifact (jar) contains, under the META-folder, that
>> information. Do you think that's enough?
>
> is there any milage in making that information available via a class call?
>
> public class Grizzly {
>   public static int Grizzly.getMajorVersion(){ return 1; }
>   public static int Grizzly.getMinorVersion(){ return 7; }
> }

That's a good idea and simple to implement. Let me work on that.

-- Jeanfrancois

>
>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

charlie hunt-3
In reply to this post by Alan Williamson
Alan Williamson wrote:

> Jeanfrancois Arcand wrote:
>>> Do we currently include a release number of Grizzly within the
>>> grizzly jar file(s) ?
>>
>> The maven artifact (jar) contains, under the META-folder, that
>> information. Do you think that's enough?
>
> is there any milage in making that information available via a class
> call?
>
> public class Grizzly {
>   public static int Grizzly.getMajorVersion(){ return 1; }
>   public static int Grizzly.getMinorVersion(){ return 7; }
> }

I think this idea has some merit to it.

I could see a case where an application may want to do something
different based on the version of Grizzly.  Having this information
available in a class would probably save some ugly implementation from a
user of Grizzly.

Perhaps we should consider adding another API that compares a major
version / minor version with the current version of Grizzly? i.e.

public class Grizzly {
  final private static int major = 1;
  final private static int minor = 7;
  public static int Grizzly.getMajorVersion(){
    return this.major;
  }
  public static int Grizzly.getMinorVersion(){
    return minor;
  }
  public static boolean equalVersion(int major, int minor) {
    if (minor == this.minor && major == this.major) {
      return true;
    return false;
}

charlie ...

>
>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--

Charlie Hunt
Java Performance Engineer

<http://java.sun.com/docs/performance/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2
In reply to this post by Harsha Godugu


Harsha Godugu wrote:

> Jeanfrancois Arcand wrote:
>>
>>
>> charlie hunt wrote:
>>> +1
>>>
>>> Do we currently include a release number of Grizzly within the
>>> grizzly jar file(s) ?
>>
>> The maven artifact (jar) contains, under the META-folder, that
>> information. Do you think that's enough?
> May not be enough :-)
> Can we make it a bit simpler. Like providing a script or runtime api to
> know the current version of Grizzly.
> (This should check the checksum of the said Grizzly jar and then if and
> only if the checksum is matches the released/promoted jar , it should
> output the current version of Grizzly at that instant. Else, it should
> say fingerprints do not match !)

That requires a lot of works (Maven does that BTW when downloading the
jars) :-) Would you volunteer to do it? I'm all for it :-) At least can
you file an RFE so we don't forget?

Thanks!

-- Jeanfrancois


>
> -hg
>>
>> -- Jeanfrancois
>>
>>>
>>> charlie ...
>>>
>>> Alan Williamson wrote:
>>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>>> actually downloading the right beast!
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to propose two changes:
>>>>>
>>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>>> the jar, e.g.:
>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>
>>>>> -- Jeanfrancois
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Harsha Godugu
Jeanfrancois Arcand wrote:

>
>
> Harsha Godugu wrote:
>> Jeanfrancois Arcand wrote:
>>>
>>>
>>> charlie hunt wrote:
>>>> +1
>>>>
>>>> Do we currently include a release number of Grizzly within the
>>>> grizzly jar file(s) ?
>>>
>>> The maven artifact (jar) contains, under the META-folder, that
>>> information. Do you think that's enough?
>> May not be enough :-)
>> Can we make it a bit simpler. Like providing a script or runtime api
>> to know the current version of Grizzly.
>> (This should check the checksum of the said Grizzly jar and then if
>> and only if the checksum is matches the released/promoted jar , it
>> should output the current version of Grizzly at that instant. Else,
>> it should say fingerprints do not match !)
>
> That requires a lot of works (Maven does that BTW when downloading the
> jars) :-) Would you volunteer to do it? I'm all for it :-) At least
> can you file an RFE so we don't forget?
Ok, I will file an RFE and can volunteer for this work. (with a Priority
p3). I will check with Ken C too.

For now, the other proposed code (by Alan W) seems like easy. But, we
shouldn't hard code the version numbers. These should be generated
during the build time. And the proposed class file should read that
information from (say) a build file and then use that data to let the
user know the current version.

Thanks,
Harsha

>
> Thanks!
>
> -- Jeanfrancois
>
>
>>
>> -hg
>>>
>>> -- Jeanfrancois
>>>
>>>>
>>>> charlie ...
>>>>
>>>> Alan Williamson wrote:
>>>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>>>> actually downloading the right beast!
>>>>>
>>>>> Jeanfrancois Arcand wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I would like to propose two changes:
>>>>>>
>>>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>>>> the jar, e.g.:
>>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>>
>>>>>> -- Jeanfrancois
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

charlie hunt-3
Harsha Godugu wrote:

> Jeanfrancois Arcand wrote:
>> Harsha Godugu wrote:
>>> Jeanfrancois Arcand wrote:
>>>> charlie hunt wrote:
>>>>> +1
>>>>>
>>>>> Do we currently include a release number of Grizzly within the
>>>>> grizzly jar file(s) ?
>>>>
>>>> The maven artifact (jar) contains, under the META-folder, that
>>>> information. Do you think that's enough?
>>> May not be enough :-)
>>> Can we make it a bit simpler. Like providing a script or runtime api
>>> to know the current version of Grizzly.
>>> (This should check the checksum of the said Grizzly jar and then if
>>> and only if the checksum is matches the released/promoted jar , it
>>> should output the current version of Grizzly at that instant. Else,
>>> it should say fingerprints do not match !)
>>
>> That requires a lot of works (Maven does that BTW when downloading
>> the jars) :-) Would you volunteer to do it? I'm all for it :-) At
>> least can you file an RFE so we don't forget?
> Ok, I will file an RFE and can volunteer for this work. (with a
> Priority p3). I will check with Ken C too.
>
> For now, the other proposed code (by Alan W) seems like easy. But, we
> shouldn't hard code the version numbers. These should be generated
> during the build time. And the proposed class file should read that
> information from (say) a build file and then use that data to let the
> user know the current version.

I don't particularly like the idea of reading from a file at runtime.  
That could become a performance issue.

I'd rather see the version number get populated in the java source file
at build time as part of the grizzly build procedure.  Perhaps that's
the place where a version number is read from a file, (at grizzly build
time, not runtime)?  I think maintaining the version number should be
something that is part of the release procedure.

charlie ...

>
> Thanks,
> Harsha
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>>
>>> -hg
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>>
>>>>> charlie ...
>>>>>
>>>>> Alan Williamson wrote:
>>>>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>>>>> actually downloading the right beast!
>>>>>>
>>>>>> Jeanfrancois Arcand wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to propose two changes:
>>>>>>>
>>>>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>>>>> the jar, e.g.:
>>>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>>>
>>>>>>> -- Jeanfrancois
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--

Charlie Hunt
Java Performance Engineer

<http://java.sun.com/docs/performance/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2


charlie hunt wrote:

> Harsha Godugu wrote:
>> Jeanfrancois Arcand wrote:
>>> Harsha Godugu wrote:
>>>> Jeanfrancois Arcand wrote:
>>>>> charlie hunt wrote:
>>>>>> +1
>>>>>>
>>>>>> Do we currently include a release number of Grizzly within the
>>>>>> grizzly jar file(s) ?
>>>>>
>>>>> The maven artifact (jar) contains, under the META-folder, that
>>>>> information. Do you think that's enough?
>>>> May not be enough :-)
>>>> Can we make it a bit simpler. Like providing a script or runtime api
>>>> to know the current version of Grizzly.
>>>> (This should check the checksum of the said Grizzly jar and then if
>>>> and only if the checksum is matches the released/promoted jar , it
>>>> should output the current version of Grizzly at that instant. Else,
>>>> it should say fingerprints do not match !)
>>>
>>> That requires a lot of works (Maven does that BTW when downloading
>>> the jars) :-) Would you volunteer to do it? I'm all for it :-) At
>>> least can you file an RFE so we don't forget?
>> Ok, I will file an RFE and can volunteer for this work. (with a
>> Priority p3). I will check with Ken C too.
>>
>> For now, the other proposed code (by Alan W) seems like easy. But, we
>> shouldn't hard code the version numbers. These should be generated
>> during the build time. And the proposed class file should read that
>> information from (say) a build file and then use that data to let the
>> user know the current version.
>
> I don't particularly like the idea of reading from a file at runtime.  
> That could become a performance issue.
>
> I'd rather see the version number get populated in the java source file
> at build time as part of the grizzly build procedure.  Perhaps that's
> the place where a version number is read from a file, (at grizzly build
> time, not runtime)?  I think maintaining the version number should be
> something that is part of the release procedure.

+1 (as the 'releaser' :-))

-- Jeanfrancois

>
> charlie ...
>>
>> Thanks,
>> Harsha
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>> -hg
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>>
>>>>>> charlie ...
>>>>>>
>>>>>> Alan Williamson wrote:
>>>>>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>>>>>> actually downloading the right beast!
>>>>>>>
>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to propose two changes:
>>>>>>>>
>>>>>>>> (1) Rename archetype produced by Maven and happens 'grizzly' for
>>>>>>>> the jar, e.g.:
>>>>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>>>>
>>>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Harsha Godugu
In reply to this post by charlie hunt-3
charlie hunt wrote:

> Harsha Godugu wrote:
>> Jeanfrancois Arcand wrote:
>>> Harsha Godugu wrote:
>>>> Jeanfrancois Arcand wrote:
>>>>> charlie hunt wrote:
>>>>>> +1
>>>>>>
>>>>>> Do we currently include a release number of Grizzly within the
>>>>>> grizzly jar file(s) ?
>>>>>
>>>>> The maven artifact (jar) contains, under the META-folder, that
>>>>> information. Do you think that's enough?
>>>> May not be enough :-)
>>>> Can we make it a bit simpler. Like providing a script or runtime
>>>> api to know the current version of Grizzly.
>>>> (This should check the checksum of the said Grizzly jar and then if
>>>> and only if the checksum is matches the released/promoted jar , it
>>>> should output the current version of Grizzly at that instant. Else,
>>>> it should say fingerprints do not match !)
>>>
>>> That requires a lot of works (Maven does that BTW when downloading
>>> the jars) :-) Would you volunteer to do it? I'm all for it :-) At
>>> least can you file an RFE so we don't forget?
>> Ok, I will file an RFE and can volunteer for this work. (with a
>> Priority p3). I will check with Ken C too.
>>
>> For now, the other proposed code (by Alan W) seems like easy. But, we
>> shouldn't hard code the version numbers. These should be generated
>> during the build time. And the proposed class file should read that
>> information from (say) a build file and then use that data to let the
>> user know the current version.
>
> I don't particularly like the idea of reading from a file at runtime.  
> That could become a performance issue.
Agree.
>
> I'd rather see the version number get populated in the java source
> file at build time as part of the grizzly build procedure.  Perhaps
> that's the place where a version number is read from a file, (at
> grizzly build time, not runtime)?  I think maintaining the version
> number should be something that is part of the release procedure.
+1.

thanks..

>
> charlie ...
>>
>> Thanks,
>> Harsha
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>> -hg
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>>
>>>>>> charlie ...
>>>>>>
>>>>>> Alan Williamson wrote:
>>>>>>> prefixing "grizzly" is a nice bonus, and gives confidence we are
>>>>>>> actually downloading the right beast!
>>>>>>>
>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to propose two changes:
>>>>>>>>
>>>>>>>> (1) Rename archetype produced by Maven and happens 'grizzly'
>>>>>>>> for the jar, e.g.:
>>>>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>>>>
>>>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Shing Wai Chan
In reply to this post by Jeanfrancois Arcand-2
Jeanfrancois Arcand wrote:

>
>
> charlie hunt wrote:
>> Harsha Godugu wrote:
>>> Jeanfrancois Arcand wrote:
>>>> Harsha Godugu wrote:
>>>>> Jeanfrancois Arcand wrote:
>>>>>> charlie hunt wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> Do we currently include a release number of Grizzly within the
>>>>>>> grizzly jar file(s) ?
>>>>>>
>>>>>> The maven artifact (jar) contains, under the META-folder, that
>>>>>> information. Do you think that's enough?
>>>>> May not be enough :-)
>>>>> Can we make it a bit simpler. Like providing a script or runtime
>>>>> api to know the current version of Grizzly.
>>>>> (This should check the checksum of the said Grizzly jar and then
>>>>> if and only if the checksum is matches the released/promoted jar ,
>>>>> it should output the current version of Grizzly at that instant.
>>>>> Else, it should say fingerprints do not match !)
>>>>
>>>> That requires a lot of works (Maven does that BTW when downloading
>>>> the jars) :-) Would you volunteer to do it? I'm all for it :-) At
>>>> least can you file an RFE so we don't forget?
>>> Ok, I will file an RFE and can volunteer for this work. (with a
>>> Priority p3). I will check with Ken C too.
>>>
>>> For now, the other proposed code (by Alan W) seems like easy. But,
>>> we shouldn't hard code the version numbers. These should be
>>> generated during the build time. And the proposed class file should
>>> read that information from (say) a build file and then use that data
>>> to let the user know the current version.
>>
>> I don't particularly like the idea of reading from a file at
>> runtime.  That could become a performance issue.
>>
>> I'd rather see the version number get populated in the java source
>> file at build time as part of the grizzly build procedure.  Perhaps
>> that's the place where a version number is read from a file, (at
>> grizzly build time, not runtime)?  I think maintaining the version
>> number should be something that is part of the release procedure.
>
> +1 (as the 'releaser' :-))
The ant task replace should be able to accomplish this.

>
> -- Jeanfrancois
>
>>
>> charlie ...
>>>
>>> Thanks,
>>> Harsha
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>>
>>>>> -hg
>>>>>>
>>>>>> -- Jeanfrancois
>>>>>>
>>>>>>>
>>>>>>> charlie ...
>>>>>>>
>>>>>>> Alan Williamson wrote:
>>>>>>>> prefixing "grizzly" is a nice bonus, and gives confidence we
>>>>>>>> are actually downloading the right beast!
>>>>>>>>
>>>>>>>> Jeanfrancois Arcand wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I would like to propose two changes:
>>>>>>>>>
>>>>>>>>> (1) Rename archetype produced by Maven and happens 'grizzly'
>>>>>>>>> for the jar, e.g.:
>>>>>>>>> What peoples thinks? Everybody (not only commiters) can talk!
>>>>>>>>>
>>>>>>>>> -- Jeanfrancois
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Oleksiy Stashok
In reply to this post by Jeanfrancois Arcand-2
+1 for renaming.
I also noticed, that let's say framework.jar is not perfect name, when
it's used outside project Grizzly scope :)

WBR,
Alexey.

Jeanfrancois Arcand wrote:

> Hi,
>
> I would like to propose two changes:
>
> (1) Rename archetype produced by Maven and happens 'grizzly' for the
> jar, e.g.:
>
> http-1.7.0.jar would becomes grizzly-http-1.7.0.jar
> framework-1.7.0 would becomes grizzly-framework-1.7.0.jar
> etc.
>
> (2) Pending Scott proposal and Jruby/DoS issues we are currently
> discussing, I would like to cut 1.7.0 release tomorrow or Monday. We
> have added significant numbers of new features as an official release
> is probably required :-) Based on Ken proposal, I would like to jump
> from 1.6.1 to 1.7.0. I would then integrate 1.7.0 in a variety of
> products like GlassFish v3, Sailfin, Jersey, Jetty, etc. I will be on
> the road for the next two weeks and having an official release to
> demonstrate for  the Grizzly's Javapolis talk will be nice :-)
>
> What peoples thinks? Everybody (not only commiters) can talk!
>
> -- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

sdo
Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

sdo

> > (2) Pending Scott proposal and Jruby/DoS issues we are currently
> > discussing, I would like to cut 1.7.0 release tomorrow or Monday. We
> > have added significant numbers of new features as an official release
> > is probably required :-) Based on Ken proposal, I would like to jump
> > from 1.6.1 to 1.7.0. I would then integrate 1.7.0 in a variety of
> > products like GlassFish v3, Sailfin, Jersey, Jetty, etc. I will be on
> > the road for the next two weeks and having an official release to
> > demonstrate for  the Grizzly's Javapolis talk will be nice :-)

Given Kristoffer's comments (and pending info from Harsha), I think
there are changes still to be made to the protocol parsing proposal. So
I don't think that can be incorporated today or Monday -- but maybe you
can rev anyway (keeping what's there) for Javapolis.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Proposals] Rename jars file, release 1.7.0

Jeanfrancois Arcand-2


Scott Oaks wrote:

>>> (2) Pending Scott proposal and Jruby/DoS issues we are currently
>>> discussing, I would like to cut 1.7.0 release tomorrow or Monday. We
>>> have added significant numbers of new features as an official release
>>> is probably required :-) Based on Ken proposal, I would like to jump
>>> from 1.6.1 to 1.7.0. I would then integrate 1.7.0 in a variety of
>>> products like GlassFish v3, Sailfin, Jersey, Jetty, etc. I will be on
>>> the road for the next two weeks and having an official release to
>>> demonstrate for  the Grizzly's Javapolis talk will be nice :-)
>
> Given Kristoffer's comments (and pending info from Harsha), I think
> there are changes still to be made to the protocol parsing proposal. So
> I don't think that can be incorporated today or Monday -- but maybe you
> can rev anyway (keeping what's there) for Javapolis.

Thanks. But I think 1.7.0 deserve such improvement so let's delay the
release until next week (JavaPolis is from 12/10 to 12/14). I want to
make sure the DoS reported by Alan is fixed (because if there is an
issue, it means GlassFish next release have it as well :-(). I also want
to look at the Jruby issue Changshin is reporting because I'm giving a
talk at 'Paris on Rails' (http://paris.onrails.info/) on that extension
and want to make sure it works as it should :-)

Let's try to have something by the end of next week if possible.

-- Jeanfrancois


>
> -Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]