From: Frank C. <fc...@pu...> - 2004-11-24 20:41:42
|
Hi J devs: J is a very nice program editor. I'm now using it daily to edit Java and Python scripts. Congratulations on a great open-source editor project. I am maintainer of an open-source test tool named TestMaker. Details are found at http://www.pushtotest.com. TestMaker embeds Jython as its scripting language. The TestMaker GUI environment offers a simple text editor that is home grown. It worked fine when my test scripts were a few dozen lines long but is now having problems with 500+ line scripts. It seems to me that J would make a good replacement. I'm wondering if anyone has tried to embed J into an Java application? Are there things for me to be concerned about in doing so? Thanks, in advance, for your consideration of my question. -Frank --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |
From: Peter G. <pe...@ar...> - 2004-11-25 03:50:09
|
On Wed, 24 Nov 2004 at 12:37:02 -0800, Frank Cohen wrote: > Hi J devs: J is a very nice program editor. I'm now using it daily to > edit Java and Python scripts. Congratulations on a great open-source > editor project. > > I am maintainer of an open-source test tool named TestMaker. Details > are found at http://www.pushtotest.com. TestMaker embeds Jython as its > scripting language. The TestMaker GUI environment offers a simple text > editor that is home grown. It worked fine when my test scripts were a > few dozen lines long but is now having problems with 500+ line scripts. > It seems to me that J would make a good replacement. > > I'm wondering if anyone has tried to embed J into an Java application? > Are there things for me to be concerned about in doing so? I'm not aware of any project that has actually embedded j in another application up to now, so I don't really have any information on the technical challenges this may pose. There is, however, potentially a licensing issue. J is GPLed, so it can only be embedded in GPLed applications. It appears that TestMaker has an Apache-style license, so on the face of it, embedding j in TestMaker would be a violation of j's license, unless TestMaker were to switch to the GPL. -Peter |
From: Frank C. <fc...@pu...> - 2004-11-25 14:52:25
|
Hi Petere: Thanks for the response - and happy Turkey Day. I'm working with the code now to see how easy/difficult it will be to embed J as TestMaker's script editor. So far I've been impressed with the code, nice job. About the licensing issue, I'm not opposed to changing the TM license to GPL. My choice of the Apache license was that it was the simplest of the licenses I found. However, there may be another way to go. My hope is that I can use the existing j.jar file unmodified and include the J GPL license in the TM distribution - I would refer TM users wanting to make J improvements to the J project. If I do need to make changes to the code then I would submit these as patches to J. It's just an idea at this point. I still need to see if this is technically feasible. -Frank On Nov 24, 2004, at 7:49 PM, Peter Graves wrote: > On Wed, 24 Nov 2004 at 12:37:02 -0800, Frank Cohen wrote: >> Hi J devs: J is a very nice program editor. I'm now using it daily to >> edit Java and Python scripts. Congratulations on a great open-source >> editor project. >> >> I am maintainer of an open-source test tool named TestMaker. Details >> are found at http://www.pushtotest.com. TestMaker embeds Jython as its >> scripting language. The TestMaker GUI environment offers a simple text >> editor that is home grown. It worked fine when my test scripts were a >> few dozen lines long but is now having problems with 500+ line >> scripts. >> It seems to me that J would make a good replacement. >> >> I'm wondering if anyone has tried to embed J into an Java application? >> Are there things for me to be concerned about in doing so? > > I'm not aware of any project that has actually embedded j in another > application up to now, so I don't really have any information on the > technical challenges this may pose. > > There is, however, potentially a licensing issue. J is GPLed, so it can > only be embedded in GPLed applications. It appears that TestMaker has > an Apache-style license, so on the face of it, embedding j in TestMaker > would be a violation of j's license, unless TestMaker were to switch to > the GPL. > > -Peter > > --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |
From: Frank C. <fc...@pu...> - 2004-11-26 06:26:59
|
I took a look at the J source with an eye to see how I could embed J into TestMaker. It seems to me that the easiest way would be for me to encapsulate TM's functions and gui into a Java bean that extends a JPanel. The panel would appear below the Editor and above the StatusBar. TM would use the J Main class to start-up, open the Editor, and assign the Frame, then init and show the TM panel. I'm wondering if you would be open to my patching Frame to have a second initializer method that takes the TM JPanel. If this init method is used the StatusBar would be added to a new border layout panel and appear in the South position. The TestMaker bean would appear in the center position. What do you think about the approach? -Frank On Nov 24, 2004, at 7:49 PM, Peter Graves wrote: > On Wed, 24 Nov 2004 at 12:37:02 -0800, Frank Cohen wrote: >> Hi J devs: J is a very nice program editor. I'm now using it daily to >> edit Java and Python scripts. Congratulations on a great open-source >> editor project. >> >> I am maintainer of an open-source test tool named TestMaker. Details >> are found at http://www.pushtotest.com. TestMaker embeds Jython as its >> scripting language. The TestMaker GUI environment offers a simple text >> editor that is home grown. It worked fine when my test scripts were a >> few dozen lines long but is now having problems with 500+ line >> scripts. >> It seems to me that J would make a good replacement. >> >> I'm wondering if anyone has tried to embed J into an Java application? >> Are there things for me to be concerned about in doing so? > > I'm not aware of any project that has actually embedded j in another > application up to now, so I don't really have any information on the > technical challenges this may pose. > > There is, however, potentially a licensing issue. J is GPLed, so it can > only be embedded in GPLed applications. It appears that TestMaker has > an Apache-style license, so on the face of it, embedding j in TestMaker > would be a violation of j's license, unless TestMaker were to switch to > the GPL. > > -Peter > > --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |
From: Peter G. <pe...@ar...> - 2004-11-26 15:51:49
|
On Thu, 25 Nov 2004 at 22:22:14 -0800, Frank Cohen wrote: > I took a look at the J source with an eye to see how I could embed J > into TestMaker. It seems to me that the easiest way would be for me to > encapsulate TM's functions and gui into a Java bean that extends a > JPanel. The panel would appear below the Editor and above the > StatusBar. TM would use the J Main class to start-up, open the Editor, > and assign the Frame, then init and show the TM panel. > > I'm wondering if you would be open to my patching Frame to have a > second initializer method that takes the TM JPanel. If this init method > is used the StatusBar would be added to a new border layout panel and > appear in the South position. The TestMaker bean would appear in the > center position. > > What do you think about the approach? No. If you want to GPL TM, you can do this sort of thing without even asking, and you're perfectly welcome to. You'd end up with (essentially) a fork of j that would work with TM. The big advantage of this is that you could choose some particular snapshot of j as a starting point, test that thoroughly with your changes, and ship the whole thing as a single package. It sounds to me like the approach you're suggesting is more along the lines of "embed TM in j" than vice versa. This is not necessarily a bad way to go, but it involves certain assumptions about the way j's UI works, which may not be true today (what about split windows? paired buffers?) and are even less likely to be true in the future, as j continues to evolve (note that j has a leading "0." in its version number). -Peter |
From: Frank C. <fc...@pu...> - 2004-11-29 16:55:44
|
Thanks for the feedback. Unless I hear some big pushback from my community then I'm going to change TM to the GPL. I'll consider your advice about taking a snapshot of J as opposed to offering a patch to make J embeddable. (making up works now. hehe) In my experience branches are less productive for an open source project. Thanks for your time. I'll let you know what I wind-up doing. BTW, the more I use J the more I like it. -Frank On Nov 26, 2004, at 7:51 AM, Peter Graves wrote: > On Thu, 25 Nov 2004 at 22:22:14 -0800, Frank Cohen wrote: >> I took a look at the J source with an eye to see how I could embed J >> into TestMaker. It seems to me that the easiest way would be for me to >> encapsulate TM's functions and gui into a Java bean that extends a >> JPanel. The panel would appear below the Editor and above the >> StatusBar. TM would use the J Main class to start-up, open the Editor, >> and assign the Frame, then init and show the TM panel. >> >> I'm wondering if you would be open to my patching Frame to have a >> second initializer method that takes the TM JPanel. If this init >> method >> is used the StatusBar would be added to a new border layout panel and >> appear in the South position. The TestMaker bean would appear in the >> center position. >> >> What do you think about the approach? > > No. > > If you want to GPL TM, you can do this sort of thing without even > asking, and you're perfectly welcome to. > > You'd end up with (essentially) a fork of j that would work with TM. > > The big advantage of this is that you could choose some particular > snapshot of j as a starting point, test that thoroughly with your > changes, and ship the whole thing as a single package. > > It sounds to me like the approach you're suggesting is more along the > lines of "embed TM in j" than vice versa. This is not necessarily a > bad way to go, but it involves certain assumptions about the way j's UI > works, which may not be true today (what about split windows? paired > buffers?) and are even less likely to be true in the future, as j > continues to evolve (note that j has a leading "0." in its version > number). > > -Peter > > > > --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |
From: Frank C. <fc...@pu...> - 2004-12-07 18:43:07
|
Hi Peter: I changed org.armedbear.j.Frame to be an interface and I changed Editor so that it uses reflection to find an implementation of Frame. By default the reflection finds your original implementation of Frame, now named FrameImpl. I now can pass-in the name of my Frame implementation to embed J in TestMaker. At this point the changes are in place and appear to work. I'm wondering if you want me to contribute the changes to J? I would like that to happen so that I don't have to maintain a branch. Also, perhaps this will benefit other developers wanting to write their own Frame classes. Who knows?! -Frank On Nov 29, 2004, at 8:51 AM, Frank Cohen wrote: > Thanks for the feedback. > > Unless I hear some big pushback from my community then I'm going to > change TM to the GPL. > > I'll consider your advice about taking a snapshot of J as opposed to > offering a patch to make J embeddable. (making up works now. hehe) In > my experience branches are less productive for an open source project. > > Thanks for your time. I'll let you know what I wind-up doing. > > BTW, the more I use J the more I like it. > > -Frank > > > > On Nov 26, 2004, at 7:51 AM, Peter Graves wrote: > >> On Thu, 25 Nov 2004 at 22:22:14 -0800, Frank Cohen wrote: >>> I took a look at the J source with an eye to see how I could embed J >>> into TestMaker. It seems to me that the easiest way would be for me >>> to >>> encapsulate TM's functions and gui into a Java bean that extends a >>> JPanel. The panel would appear below the Editor and above the >>> StatusBar. TM would use the J Main class to start-up, open the >>> Editor, >>> and assign the Frame, then init and show the TM panel. >>> >>> I'm wondering if you would be open to my patching Frame to have a >>> second initializer method that takes the TM JPanel. If this init >>> method >>> is used the StatusBar would be added to a new border layout panel and >>> appear in the South position. The TestMaker bean would appear in the >>> center position. >>> >>> What do you think about the approach? >> >> No. >> >> If you want to GPL TM, you can do this sort of thing without even >> asking, and you're perfectly welcome to. >> >> You'd end up with (essentially) a fork of j that would work with TM. >> >> The big advantage of this is that you could choose some particular >> snapshot of j as a starting point, test that thoroughly with your >> changes, and ship the whole thing as a single package. >> >> It sounds to me like the approach you're suggesting is more along the >> lines of "embed TM in j" than vice versa. This is not necessarily a >> bad way to go, but it involves certain assumptions about the way j's >> UI >> works, which may not be true today (what about split windows? paired >> buffers?) and are even less likely to be true in the future, as j >> continues to evolve (note that j has a leading "0." in its version >> number). >> >> -Peter >> >> >> >> > --- > Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 > Author of "Java Testing and Design: From Unit Tests to Automated Web > Tests" > from Prentice Hall, details at http://thebook.pushtotest.com > > --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |
From: Peter G. <pe...@ar...> - 2004-12-07 21:02:33
|
On Tue, 7 Dec 2004 at 10:39:12 -0800, Frank Cohen wrote: > Hi Peter: I changed org.armedbear.j.Frame to be an interface and I > changed Editor so that it uses reflection to find an implementation of > Frame. By default the reflection finds your original implementation of > Frame, now named FrameImpl. I now can pass-in the name of my Frame > implementation to embed J in TestMaker. > > At this point the changes are in place and appear to work. I'm > wondering if you want me to contribute the changes to J? I would like > that to happen so that I don't have to maintain a branch. Also, perhaps > this will benefit other developers wanting to write their own Frame > classes. Who knows?! I think you're better off just maintaining a patch, at this point. -Peter |
From: Frank C. <fc...@pu...> - 2005-01-03 21:07:29
|
Thanks Peter. I created a branch that I labeled j-0-1.21-tmbranch and make available through cvs.pushtotest.com. Details on my cvs are found at http://www.pushtotest.com/FAQ/faq.html#CVS. So far J is being well received by TestMaker developers. I love it! Thanks for the good work. -Frank On Dec 7, 2004, at 1:02 PM, Peter Graves wrote: > On Tue, 7 Dec 2004 at 10:39:12 -0800, Frank Cohen wrote: >> Hi Peter: I changed org.armedbear.j.Frame to be an interface and I >> changed Editor so that it uses reflection to find an implementation of >> Frame. By default the reflection finds your original implementation of >> Frame, now named FrameImpl. I now can pass-in the name of my Frame >> implementation to embed J in TestMaker. >> >> At this point the changes are in place and appear to work. I'm >> wondering if you want me to contribute the changes to J? I would like >> that to happen so that I don't have to maintain a branch. Also, >> perhaps >> this will benefit other developers wanting to write their own Frame >> classes. Who knows?! > > I think you're better off just maintaining a patch, at this point. > > -Peter > > --- Frank Cohen, PushToTest, http://www.PushToTest.com, phone: 408 374 7426 Author of "Java Testing and Design: From Unit Tests to Automated Web Tests" from Prentice Hall, details at http://thebook.pushtotest.com |