Re: [VOTE] Releasing FtpServer 1.0.1
+1 Julien +1 Sai Pullabhotla www.jMethods.com On Wed, May 13, 2009 at 3:56 PM, Niklas Gustavsson nik...@protocol7.comwrote: Hey, since 1.0.0 some issues has been reported in FtpServer. Now is therefore a good time to get 1.0.1 out. You can find the binaries and Maven artifacts here: http://people.apache.org/~ngn/ftpserver/1.0.1/http://people.apache.org/%7Engn/ftpserver/1.0.1/ These files was built from the following code: https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.1 The bugs fixed are: https://issues.apache.org/jira/browse/FTPSERVER/fixforversion/12313619 Get those bugs squashed? [ ]: +1, Release FtpServer 1.0.1 [ ]: 0, Abstain [ ]: -1, Don't release FtpServer 1.0.1 /niklas
Re: About MINA 2.0.0-M4 tarballs
Ok, guys, one of the steps was FU. The assembly pluging is buggy, and the patch proposed on JIRA about it simply does not work anymore : https://issues.apache.org/jira/browse/DIRMINA-616 One more thing we have to fix for 2.0.0-RC1, I guess. Sadly, I don't have time this morning to get this fixed for the current M4, but if someone can check what's going on... I'm stuck in step 3 of this doc : http://cwiki.apache.org/confluence/display/MINA/Developer+Guide Not sure that it's important, as the duplicated files are soucres, AFAIK, but this is, to say the least, painful. Btw, this doco has also to be reviewed, it's not anymore compliant with what we need to do in order to get a release done : I had to 'hack' the commands more than once... More to come later... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org Hi I'm not sure you need this specific Maven version, just setting the duplicate file behaviour. Anyway if you follow the MASSEMBLY jira link you will prolly find the solution. Good luck, Julien
Re: [Vote] Release MINA 2.0.0-M4
Hi guys, we have released 2.0.0-M3 a few weeks ago (nov, 8th). I think it's time for the last milestone before RC1 now. We still have a few issues to fix (7), but so far, the API won't change now. I would call this release the API freeze release. Once release, we should work on 2.0-RC1, fixing the last bugs, and more important, adding documentation to the project. Hopefully, we can get a 2.0-RC1 by the very beginning of 2009, and a 2.0-GA a few weeks later, if everything goes right. So now, let's open the vote : [X] +1, let's release 2.0.0-M4 and freeze the API [ ] +/- 0, abstain [ ] -1 : we are not ready, let's wait a bit more. Julien
Re: MINA 1.1.7 MD5 and SHA1 hashes do not match downloads
On Fri, Jul 11, 2008 at 10:37 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Yes, they have to be in sync. Make me realize that I didn't added my key in this file :) I've updated the KEYS file in www.apache.org/dist/mina and added a note to the file to remind future updaters to do the same. /niklas perhaps we can delete it and replace the link on the website to a link to the svn file ? Julien
added o.a.asyncweb.common.codec and Mutable interfaces
Hi, I moved some class related to HTTP message encoding/decoding from o.a.asyncweb.common to o.a.asynweb.common.codec. So there is less crowd in the package. I thought about another simplification : for a simple Http Message you have this heritance tree : DefaultHttpResponse extends DefaultHttpMessage implements MutableHttpResponse DefaultHttpMessage implements MutableHttpMessage MutableHttpMessage extends HttpMessage MutableHttpResponse extends MutableHttpMessage, HttpResponse HttpResponse extends HttpMessage MutableHttpMessage extends HttpMessage As far as I understand it, fr http messages the interfaces was splited in two, the getters and the setters (mutable part). After looking around I see no real utilisation for that since all the conrecte implemenations are Mutables. By removing the Mutable interface we will greatly simplify the structure of those messages. WDYT ? Julien
Javadoc commits
Hi, If you are following the commit log, everybody is urging for getting more and more code covered with Javadoc and internal code documentation. Actually there was a couple of files and whole packages commited with *no* javadoc at all or even without licenses headers. We are far of discussing about @inerhitDoc tags or small details, so modules take lot of effort to be understood and back-documented. I would like thanks all the pals who are working to sort those issues backward. We need to avoid going to review-then-commit mode, so please take a look at other commit and yell hard when you see something without the minimum of doc for making the code maintenable. I think we don't need to have every commit with enormous javadoc with inline examples, but at least a comment for each public method and for each class header. Julien
Re: svn commit: r659372 - /mina/branches/buffer/core/src/main/java/org/apache/mina/queue/Default ByteBufferQueue.java
On Fri, May 23, 2008 at 1:04 PM, Stefano Bagnara [EMAIL PROTECTED] wrote: Emmanuel Lecharny ha scritto: Now, considering your attitude : your are sometime just behaving like a stubborn childish person. You are interpreting the ASF rules at your own advantage, with no respect for person around you. Like it or not, this is not the way it works. When I asked you to revert the code, this is because we reached a point where we have to discuss the portion of code you have committed, it was not a punishment. But you took it as if I wanted to personally insult you, and you insulted me in return. I will swallow the insult, because it's just totally irrelevant to the discussion. My opinion is that you behaved very bad too. There was a discussion in place, and there was no need to veto this until every solution was evaluated. You didn't try to understand the why, propose something different, evaluate pros/cons of what have been done and what you proposed before vetoing it. This is only my opinion as an ASF committer have only a user role in mina. No one asked for your precious opinion. You don't have a grasp of the situation at all. So stop adding to the fire. LET THE THREAD DIE! We need to move on. Alex Hi, Until it's on a public mailing list I don't see the problem with everybody expressing his opinion, it's the purporse. Julien
Re: MINA + Grizzly discussion
Hi, no prob between 7-17 UTC. Julien Either email or IRC works for me. I am EDT (GMT-4). On Sat, May 17, 2008 at 10:30 PM, ì´í¬ì¹ (Trustin Lee) [EMAIL PROTECTED] wrote: I've just came to think that we might be able to make this discussion occur via e-mail exchange, by cross posting to [EMAIL PROTECTED] and grizzly dev list. It will make the conversation more transparent and let more people get involved. WDYT? PS: I'm on UTC+9 ;) On Sun, 18 May 2008 08:38:09 +0900, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Guys, last week, Trustin was in SF for Java One. He met Jean-François Arcand, and had some interesting convo there. Here is a copy of is mail about it : Hi, I met Jean-francois Arcand, the Grizzly lead last week in JavaOne, and he showed his interest in joining the effort to build better network application framework together. I suggested an IRC chat at #mina, and he agreed. We could talk about: * the possibility of merging two projects in the future (not sure this will happen) * the regular exchange of each other's knowledge at least * and anything you want to talk about, probably except for offending each other's framework? :) It would be nice if we can have this chat next week. Please let me know when you are available, so I can tell them what date and time we prefer. Cheers, As he is suggesting a chat session with JF, please fill free to tell when would be the best timing for such an IRC meeting (keep in mind that Trustin is UTC-7 and that it is really important to have him around. Just push your best timeframe, not forgetting your UTC increment/decrement. Thanks ! -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [VOTE] Release Apache MINA 1.0.10 and 1.1.7
Hi, We all know it's the current branche code ;) Just checkout and test it ! Julien +1 for the release I also like the idea of specifying the revision number for the releases... Thanks, Sangjin On Fri, Apr 11, 2008 at 8:14 AM, ÀÌÈñ½Â (Trustin Lee) [EMAIL PROTECTED] wrote: Emmanuel Lecharny wrote: Niklas Gustavsson wrote: Hi, On Fri, Apr 11, 2008 at 12:28 PM, ÀÌÈñ½Â (Trustin Lee) [EMAIL PROTECTED] wrote: All fixes have been applied to both branch without any difference. The two releases we are going to cut are basically backward-compatible bug fix releases, so I don't see any reason to postpone them. Let's hope this is the last vote for 1.x releases. :) Are the binaries available for review? If possible, I would prefer to be able to review the binaries before casting my vote. /niklas Yeah, that would be cool to have. Also David Jencks on Directory project suggested that every vote should be related to at least a revision number, otherwise we have no way to be sure what we are working on. I know we never did it before, but I just mention it because it seems sane to do so. wdyt ? Yeah, I also tried that approach once, but was too lazy to do it once again. :) Let me upload snapshot build and specify revision number soon... Thanks, -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [Asyncweb][Client] Can we quiet down this logging in the client?
The AHC seems to be logging profusely. Could we reduce that output? I was going to throw a log4j.properties file into the test/resources area but seems like the project is using another logger. Alex Hi Alex, the server is quite INFO verbose too, a lot of logging statement need to be moved to DEBUG, IMHO. Julien
Re: [AsyncHttpClient] On bringing the code bases and communities together
Hi, Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? I think it's a good idea. The first thing to do is to freeze the g-ahc-v1 to avoid endless porting between the two branches. The main problem for the migration back to Asyncweb is the codec, it was modified a lot ? Julien Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
sorry for double post,I'm out of my office and using webmail which is really bugged :( Sorry for the inconvenience, Julien
Re: [AsyncHttpClient] On bringing the code bases and communities together
Hi Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on). - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? I think it's a good way, the first thing is probably to freeze the g-ahc-v1 for avoid more porting. The main problem for migrate to mina-ahc is the new Asynweb state based codec. You think a lot of feature are missing from mina http codec from the g-ahc one ? Julien (not sure to be clear) Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: Any thoughts on this new network library
Wondering if anyone used or tried this library here: http://xsocket.sourceforge.net/ Someone pointed me over to it and I have not had any time to take a closer look. Thanks, Alex Hi, it's not really new, it's perhaps as old as MINA. Take a look at the tutorial : http://xsocket.sourceforge.net/core/tutorial/V2/TutorialCore.htm IMHO the API is quite peculiar.. Julien
