Re: Do we want a GUI installer?
The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Windows look and feel, Metal, GTK+, whatever, I'm no expert, I just know that Java apps can look prettier. And it is important that it look reasonably pretty if this is going to be someone's first sight of Cocoon. Regards, Upayavira I'm surfing the web looking for more lookfeel layout, I found this site [1] with lot of free lf. I'd like many liquid [2], but there are many themes very nice. Can we go ahead for this way? WDYT? [1] http://javootoo.l2fprod.com/ [2] https://liquidlnf.dev.java.net/ -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
Daniele Madama wrote: The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Windows look and feel, Metal, GTK+, whatever, I'm no expert, I just know that Java apps can look prettier. And it is important that it look reasonably pretty if this is going to be someone's first sight of Cocoon. Regards, Upayavira I'm surfing the web looking for more lookfeel layout, I found this site [1] with lot of free lf. I'd like many liquid [2], but there are many themes very nice. Can we go ahead for this way? WDYT? [1] http://javootoo.l2fprod.com/ [2] https://liquidlnf.dev.java.net/ I speak as someone who's Swing experience doesn't go beyond learning exercises. Do we need to include a libary to achieve a better LF? What is the current way in the Java world? If we do, we need to make sure that we choose one that is licenced in a compatible way to ASL. Thus, [2], which is LGPL, is not compatible. I know JGoodies is BSD, but don't know if it is any good. Any Java Swing gurus here who can give a little guidance? Regards, Upayavira
Re: Do we want a GUI installer?
Upayavira wrote: ... Do we need to include a libary to achieve a better LF? What is the current way in the Java world? If we do, we need to make sure that we choose one that is licenced in a compatible way to ASL. Thus, [2], which is LGPL, is not compatible. I know JGoodies is BSD, but don't know if it is any good. Any Java Swing gurus here who can give a little guidance? IMHO, if a GUI feels ugly, the first thing to do is to rethink the layout. From teh screenshots I saw here it's not qhat I would call a standard layout. Then set the look and feel of the native platform (please no metal), add icons, set the spacing between components, use SwingWorker to manage long-running actions... and thing will start to look nice. Other things can be done like setting rollover images for buttons, using more advanced components for some parts of the UI (swinglabs and l2fprod), using progress bars and statusbar for more info to the user, add a splash, tweak font, etc. Only *then* one can think of changing the lf, but usually it's not needed. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Do we want a GUI installer?
Upayavira wrote: ... Do we need to include a libary to achieve a better LF? What is the current way in the Java world? If we do, we need to make sure that we choose one that is licenced in a compatible way to ASL. Thus, [2], which is LGPL, is not compatible. I know JGoodies is BSD, but don't know if it is any good. Any Java Swing gurus here who can give a little guidance? IMHO, if a GUI feels ugly, the first thing to do is to rethink the layout. From teh screenshots I saw here it's not qhat I would call a standard layout. Then set the look and feel of the native platform (please no metal), add icons, set the spacing between components, use SwingWorker to manage long-running actions... and thing will start to look nice. Other things can be done like setting rollover images for buttons, using more advanced components for some parts of the UI (swinglabs and l2fprod), using progress bars and statusbar for more info to the user, add a splash, tweak font, etc. Only *then* one can think of changing the lf, but usually it's not needed. Make sense, I'm new on UI programming and for me is more easy to change lf than think a good layout :D. Thanks for the lesson ;) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
Daniele Madama wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. My installer is similar to this, but it is written in SWING. It has a selection of blocks (read and pre-selected from [local.]blocks.properties) with their description (read from gump.xml) and it will have a selection from principal build.properties (like samples, javadoc, and more). I hope to have time to finish some feature and donate it, if you want and if you think that it was useful. ;) Since the scope of the work required of the AntInstaller and yours isn't that different, I'd be interested to see yours. Thanks for your interest, I really hope this small application might serve the needs of the cocoon community. If you think the application might suit your needs, I'll gladly post the source to bugzilla. To try it out: http://www.pronetics.it/transfer/cbuilder-0.1-idea.jar For execute: 1) put the jar in $COCOON_HOME 2) backup your local.blocks.properties ;) 3) java -jar cbuilder-0.1-idea.jar this work only on BRANCH_2_1_X version, if you have an older version, execute it with 'java -cp lib/endorsed/x*.jar org.apache.cocoon.builder.CocoonBuilder'. I'm waiting for your hints or opinion. Regards Daniele Interesting to see that you use the descriptions from gump.xml. I put those there when I was planning to do build this installer, for the very purpose you are using them for! Regards, Upayavira -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
Daniele Madama wrote: Daniele Madama wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. My installer is similar to this, but it is written in SWING. It has a selection of blocks (read and pre-selected from [local.]blocks.properties) with their description (read from gump.xml) and it will have a selection from principal build.properties (like samples, javadoc, and more). I hope to have time to finish some feature and donate it, if you want and if you think that it was useful. ;) Since the scope of the work required of the AntInstaller and yours isn't that different, I'd be interested to see yours. Thanks for your interest, I really hope this small application might serve the needs of the cocoon community. If you think the application might suit your needs, I'll gladly post the source to bugzilla. To try it out: http://www.pronetics.it/transfer/cbuilder-0.1-idea.jar For execute: 1) put the jar in $COCOON_HOME 2) backup your local.blocks.properties ;) 3) java -jar cbuilder-0.1-idea.jar this work only on BRANCH_2_1_X version, if you have an older version, execute it with 'java -cp lib/endorsed/x*.jar org.apache.cocoon.builder.CocoonBuilder'. I'm waiting for your hints or opinion. Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? I like the idea of what we have here. I'd be all for adding it to the Cocoon 2.1.X codebase. What do others think? Regards, Upayavira P.S. My (Unix) command to invoke it was: java -cp lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar:lib/endorsed/xml-apis.jar:lib/endorsed/xercesImpl-2.7.1.jar:cbuilder-0.1-idea.jar org.apache.cocoon.builder.CocoonBuilder Windows would be: java -cp lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar;lib/endorsed/xml-apis.jar;lib/endorsed/xercesImpl-2.7.1.jar;cbuilder-0.1-idea.jar org.apache.cocoon.builder.CocoonBuilder
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Daniele Madama wrote: Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? I'll add #5 then: adding a Jetty control pane to start/stop the webapp. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Daniele Madama wrote: Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? I'll add #5 then: adding a Jetty control pane to start/stop the webapp. That would be great. Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) WDYT? Upayavira
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) Hmmm... you're the guy who presented the SVNClassLoader at ApacheCon, right? Well, it shows. :-)) Anyway, yeah, that sounds great indeed, and definitely no rocket science. My take would be grabbing the current source code, commit it and start hacking on it. How about it? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) Hmmm... you're the guy who presented the SVNClassLoader at ApacheCon, right? Well, it shows. :-)) Oh, infamy already? ;-( Anyway, yeah, that sounds great indeed, and definitely no rocket science. My take would be grabbing the current source code, commit it and start hacking on it. How about it? Sounds great. Although do I detect some suggestion that I might be doing some of that coding? :-) Really, before we commit it, we need some buy in from a number of people who are prepared to develop it/keep an eye upon it. For myself, I'm starting to take using 2.2 more seriously, and expect my efforts to go there. Regards, Upayavira
Re: Do we want a GUI installer?
Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? Points 2 and 3 already are in my TODO list :D. For point 4 I think that any people with a little of SWING experience (isn't my case) could do a very well work. Any volunteer? :D I like the idea of what we have here. I'd be all for adding it to the Cocoon 2.1.X codebase. What do others think? Regards, Upayavira P.S. My (Unix) command to invoke it was: java -cp lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar:lib/endorsed/xml-apis.jar:lib/endorsed/xercesImpl-2.7.1.jar:cbuilder-0.1-idea.jar org.apache.cocoon.builder.CocoonBuilder Windows would be: java -cp lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar;lib/endorsed/xml-apis.jar;lib/endorsed/xercesImpl-2.7.1.jar;cbuilder-0.1-idea.jar org.apache.cocoon.builder.CocoonBuilder -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Daniele Madama wrote: Idea is simple, but works. I like the fact that it respects the dependency information. That will ease people's lives a lot. My Ant based installer didn't do that. Here's a few thoughts: 1. Could you show the dependency information in the right hand pane? It isn't always clear as to why a block's tick is grayed out. 2. Could you add a page/tab for the basic options in build.properties? 3. Could you add a pane that actually invokes Ant? If you could do that, and added a 'welcome' pane, you'd have written a full installer, which would be excellent. All it would need to do is set stdout to an output stream that gets written to a list box or text box, and has a cancel button. 4. Could you make it use a more modern UI style? I'll add #5 then: adding a Jetty control pane to start/stop the webapp. Yeah! And launch the rocket too. :D Seriously, with this feature it became a complete installer. I will start the coding of points 2 and 3, and then add this feature ;) I'm very happy that this little application like to the community (2 people for this time :D) Daniele -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: On 9/22/05, Upayavira [EMAIL PROTECTED] wrote: Now, pushing this a little further - a pane to enter details of a single mount that can be added automatically into the root sitemap - or to create a mounttable file. That way, you run this app, select your blocks, tell it where your own site is, click 'configure', click 'run' and you're away. Then, you realise you need an extra block, you click 'stop', you click to select your block, you click start, it says I need to rebuild, hang on, and it rebuilds. Then it starts the webapp, with your app mounted already, and we're all really happy :-) Hmmm... you're the guy who presented the SVNClassLoader at ApacheCon, right? Well, it shows. :-)) Oh, infamy already? ;-( Nh, sound respect to a bright mind: we need dreamers. :-) Anyway, yeah, that sounds great indeed, and definitely no rocket science. My take would be grabbing the current source code, commit it and start hacking on it. How about it? Sounds great. Although do I detect some suggestion that I might be doing some of that coding? :-) Really, before we commit it, we need some buy in from a number of people who are prepared to develop it/keep an eye upon it. Well, I for one, would be glad to back this effort and provide oversight as well as some code (well, not that I've been doing much coding in Cocoonland lately, but I have a few things simmering on my hard drive...including a Jetty stop/start panel. I just wish I had 48hrs days). In any case, while I have great expectations for 2.2, I also think that increasing the user experience even for the time being could be a good thing, and this small tool might help people in their first impact with Cocoon. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
Il giorno 22/set/05, alle 21:32, Upayavira ha scritto: 4. Could you make it use a more modern UI style? What do you mean by modern? Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Do we want a GUI installer?
Ugo Cei wrote: Il giorno 22/set/05, alle 21:32, Upayavira ha scritto: 4. Could you make it use a more modern UI style? What do you mean by modern? The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Windows look and feel, Metal, GTK+, whatever, I'm no expert, I just know that Java apps can look prettier. And it is important that it look reasonably pretty if this is going to be someone's first sight of Cocoon. Regards, Upayavira
Re: Do we want a GUI installer?
Il giorno 22/set/05, alle 23:49, Upayavira ha scritto: The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Oh, well, on my Mac it has the Aqua look, so it looks rather pretty, but I agree that it could be much prettier. Actually, before I helped Daniele tweak the UI just a little, it looked *really* ugly ;-). If I remember correctly, selecting the default platform LF is quite simple and this would give Windows users a more familiar UI, so I'm +1 on that. As for Linux/Unix people, they are accustomed to ugly, inconsistent GUIs so they shouldn't care much ;-) Besides I think GTK is the default platform LF on Linux starting with JDK 1.5. Personally, I prefer Metal, but that's just me. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Do we want a GUI installer?
Ugo Cei wrote: Il giorno 22/set/05, alle 23:49, Upayavira ha scritto: The application has the default Java swing look, which isn't very exciting. So, anything that looks a little prettier... Oh, well, on my Mac it has the Aqua look, so it looks rather pretty, but I agree that it could be much prettier. Actually, before I helped Daniele tweak the UI just a little, it looked *really* ugly ;-). :-) If I remember correctly, selecting the default platform LF is quite simple and this would give Windows users a more familiar UI, so I'm +1 on that. Great. As for Linux/Unix people, they are accustomed to ugly, inconsistent GUIs so they shouldn't care much ;-) Dah. Not on Ubuntu. On Ubuntu, everything is pretty! Besides I think GTK is the default platform LF on Linux starting with JDK 1.5. Personally, I prefer Metal, but that's just me. I'm really not fussed what it is, just want it to be prettier! I've attached a screenshot, FYI. Upayavira
Re: Do we want a GUI installer?
Daniele Madama wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. My installer is similar to this, but it is written in SWING. It has a selection of blocks (read and pre-selected from [local.]blocks.properties) with their description (read from gump.xml) and it will have a selection from principal build.properties (like samples, javadoc, and more). I hope to have time to finish some feature and donate it, if you want and if you think that it was useful. ;) Since the scope of the work required of the AntInstaller and yours isn't that different, I'd be interested to see yours. Interesting to see that you use the descriptions from gump.xml. I put those there when I was planning to do build this installer, for the very purpose you are using them for! Regards, Upayavira
Re: Do we want a GUI installer?
Joerg Heinicke wrote: On 14.04.2005 11:15, Upayavira wrote: In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant. Did anything result from this thread? http://marc.theaimsgroup.com/?t=11134702705r=1w=4 I'ld say we put this off until the situation with m2 and osgi has stabilized. Heck, maybe our osgi implementation will provide a builtin solution like [1] , meaning we wouldn't have to do much if anything at all to have this. Jorg [1] http://www.knopflerfish.org/desktop.html
Re: Do we want a GUI installer?
Jorg Heymans wrote: Joerg Heinicke wrote: On 14.04.2005 11:15, Upayavira wrote: In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant. Did anything result from this thread? http://marc.theaimsgroup.com/?t=11134702705r=1w=4 I'ld say we put this off until the situation with m2 and osgi has stabilized. Heck, maybe our osgi implementation will provide a builtin solution like [1] , meaning we wouldn't have to do much if anything at all to have this. I'd probably agree, now. As background, I saw this installer that looked like it would make a decent front end for the 2.1 build process. I looked into using it for some of my own work. However, it turned out not to have the range of functionality I needed (but would still have suited Cocoon well) - I had to drop it and learn NSIS (which, whilst powerful, is ghastly in terms of its scripting - scripting as if writing C, with pre-processing instructions etc, gaahh) - hence I didn't find the time to complete what I proposed for Cocoon. If someone is still interested, I'll happily give pointers/ideas, maybe even find the time to revisit and implement it myself. However, things with OSGi/blocks are much clearer now than they were. Do we still need to improve the user experience of building 2.1? What do people think? Regards, Upayavira
Re: Do we want a GUI installer?
On 9/20/05, Upayavira [EMAIL PROTECTED] wrote: If someone is still interested, I'll happily give pointers/ideas, maybe even find the time to revisit and implement it myself. However, things with OSGi/blocks are much clearer now than they were. Do we still need to improve the user experience of building 2.1? What do people think? I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
* Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ Screenshot.png Description: PNG image
Re: Do we want a GUI installer?
On 9/20/05, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. If I ever needed another reason to praise the FreeBSD guys, here it is... however, I fear that tool is less than portable, given it requires make and ncurses/dialog/whatever. My take is that a minimal Swing app able to deal with dependencies might be a good step forward anyway. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Do we want a GUI installer?
* Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. My installer is similar to this, but it is written in SWING. It has a selection of blocks (read and pre-selected from [local.]blocks.properties) with their description (read from gump.xml) and it will have a selection from principal build.properties (like samples, javadoc, and more). I hope to have time to finish some feature and donate it, if you want and if you think that it was useful. ;) Daniele -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/ -- The box said Requires Windows 95/98/Me/Nt/2k/XP or better so I installed Linux ! -o=|=o- Daniele Madama Pro-netics s.r.l. Via Elio Lampridio Cerva 127/c Roma Tel. 0651530849 http://www.pronetics.it
Re: Do we want a GUI installer?
Gianugo Rabellino wrote: On 9/20/05, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: * Gianugo Rabellino: I think so, Cocoon 2.1 is here to stay for a while. FWIW, a colleague of mine (Daniele Madama) wrote a small GUI to manage blocks selection (think make xconfig for the linux kernel). If you deem it useful, my take is Daniele would be glad to contribute it. On FreeBSD, there is a Cocoon installer that has such a GUI. See attached screenshot. This is based on a BSD Makefile. If I ever needed another reason to praise the FreeBSD guys, here it is... however, I fear that tool is less than portable, given it requires make and ncurses/dialog/whatever. My take is that a minimal Swing app able to deal with dependencies might be a good step forward anyway. Well, here is where the Ant installer [1] would suit you. It's config file could be generated with a single XSLT from gump.xml (I did have a version of it working). IIRC it would add around 900K to our download. Only downside: http://antinstaller.sourceforge.net/roadmap.html says Support for JDK1.3. I don't know how hard it would be to add it, although I guess I could have a go. Upayavira [1] http://antinstaller.sourceforge.net/
Re: Do we want a GUI installer?
On 14.04.2005 11:15, Upayavira wrote: In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant. Did anything result from this thread? http://marc.theaimsgroup.com/?t=11134702705r=1w=4 Jörg
Re: Do we want a GUI installer?
Jorg Heymans wrote: Upayavira wrote: I can see this being useful for first time cocooners. What if the cocoon build switches to maven (as rumoured a few times already)? Can the tool be extended to handle this? Will you need seperate logic to handle the 2.2 block configuration? If it can be done from Ant, it can be done with this tool. All it does is collects properties and delivers them to Ant. Overall, IMO the potential effort of maintaining such a tool isn't worth the benefit. Maybe. Which is why I was asking! The effort to maintain for 2.1 is pretty minimal - it would just be a single XSLT on gump.xml and a few jars in the repo. For 2.2, well, we'll need to see what that is before we can decide! Well if it's no effort i don't see why it couldn't be added to the next release as an experiment (pending license issues ofcourse). As long as you make sure that the users know it's just a toy-experiment and nothing more there should be no harm. Actually, will/should Lepido provide anything like this? Any Lepido'ers care to comment? Sorry for the late answer. The list is very busy lately and me too ;-) Yes, an installer, or more specifically a new project wizard, is one the goals of Lepido. However, I may seem overkill for a newcomer that just wants to try out Cocoon to add another huge download to the alreay large Cocoon distro. So this effort is welcome. The licence problem seems to be a blocker though, since a graphical installer is supposed to make people's life easier, and having to download the installer libraries separately is definitely not easy! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Do we want a GUI installer?
Sylvain Wallez wrote: Jorg Heymans wrote: Upayavira wrote: I can see this being useful for first time cocooners. What if the cocoon build switches to maven (as rumoured a few times already)? Can the tool be extended to handle this? Will you need seperate logic to handle the 2.2 block configuration? If it can be done from Ant, it can be done with this tool. All it does is collects properties and delivers them to Ant. Overall, IMO the potential effort of maintaining such a tool isn't worth the benefit. Maybe. Which is why I was asking! The effort to maintain for 2.1 is pretty minimal - it would just be a single XSLT on gump.xml and a few jars in the repo. For 2.2, well, we'll need to see what that is before we can decide! Well if it's no effort i don't see why it couldn't be added to the next release as an experiment (pending license issues ofcourse). As long as you make sure that the users know it's just a toy-experiment and nothing more there should be no harm. Actually, will/should Lepido provide anything like this? Any Lepido'ers care to comment? Sorry for the late answer. The list is very busy lately and me too ;-) Yes, an installer, or more specifically a new project wizard, is one the goals of Lepido. However, I may seem overkill for a newcomer that just wants to try out Cocoon to add another huge download to the alreay large Cocoon distro. So this effort is welcome. The licence problem seems to be a blocker though, since a graphical installer is supposed to make people's life easier, and having to download the installer libraries separately is definitely not easy! The author has since identified that the LGPL licenced jars are either his own (and can be relicensed) or inessential. So there doesn't seem to be a problem, which is good. (I did find some ant tasks (Roxes) for creating windows shortcuts,etc, which are cool, but they are GPL :-( ) The question is, how deeply would we want to integrate this installer into our release processes, etc. E.g. whenever someone adds a new block, they'll need to rebuild the installer config to take it into account (an XSLT on gump.xml), and all documentation would need to be rewritten to take it into account. Also, a little blurb put into the gump.xml file so that the installer can say This block does XYZ. Anyway, I'll take this a little further - first I'll get the code relicensed so I can do a better demo, then I'll work out how to do the gump XSLT, and then I'll demo it. Regards, Upayavira
Re: Do we want a GUI installer?
Upayavira wrote: Sylvain Wallez wrote: snip/ Yes, an installer, or more specifically a new project wizard, is one the goals of Lepido. However, I may seem overkill for a newcomer that just wants to try out Cocoon to add another huge download to the alreay large Cocoon distro. So this effort is welcome. The licence problem seems to be a blocker though, since a graphical installer is supposed to make people's life easier, and having to download the installer libraries separately is definitely not easy! The author has since identified that the LGPL licenced jars are either his own (and can be relicensed) or inessential. So there doesn't seem to be a problem, which is good. (I did find some ant tasks (Roxes) for creating windows shortcuts,etc, which are cool, but they are GPL :-( ) The question is, how deeply would we want to integrate this installer into our release processes, etc. E.g. whenever someone adds a new block, they'll need to rebuild the installer config to take it into account (an XSLT on gump.xml), and all documentation would need to be rewritten to take it into account. Also, a little blurb put into the gump.xml file so that the installer can say This block does XYZ. As long as the necessary information exists in gump.xml (and yes, some descriptive text would be useful) generating the installer file can be part of the release process. It can even be actually part of the installer launch process. Anyway, I'll take this a little further - first I'll get the code relicensed so I can do a better demo, then I'll work out how to do the gump XSLT, and then I'll demo it. Great! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Do we want a GUI installer?
Simon Mieth wrote: On Thu, 14 Apr 2005 20:49:33 +0200 Daniel Fagerstrom [EMAIL PROTECTED] wrote: Upayavira wrote: If the user can get all the way to start Jetty with our demos through a simple GUI, I find it a good idea. Even if I'm perfectly able to read a README and run ant or make when I evaluate some new software, IMO the sooner I can start to evaluate what it does the better. The easier we can make using Cocoon, the better IMO. Cocoon is an excelent tool for complicted stuff, my goal is to help making simple things simple ;) So if you can fix the licence problems you have my +1 at least. /Daniel Hi all, sorry for the noise, I have written a little GUI tool for Offline-Processing with Cocoon, that includes now Jetty and an Installer (available separate and as webstart) under ASL 2.0. http://sourceforge.net/projects/hawron Hi Simon, Thanks for this. Does this installer install Hawron specifically? Or is it about installing and configuring Cocoon? I suspect these two are mutually complementary. Regards, Upayavira
Re: Do we want a GUI installer?
On Fri, 15 Apr 2005 11:40:49 +0100 Upayavira [EMAIL PROTECTED] wrote: Hi Simon, Thanks for this. Does this installer install Hawron specifically? Or is it about installing and configuring Cocoon? I suspect these two are mutually complementary. Regards, Upayavira Hi Upayavira, the installer will install only Cocoon. You can used it from Hawron or as single application/webstart application (independent from Hawron). The installer could be build without hawron, with little work on the build-file. It can download/unpack/configure blocks/building a cocoon-release. You can point to an existing Cocoon source installation and skip the download/unpack parts, so you can configure the blocks and do a rebuilding of Cocoon. Internally there is simple an InstallManager, which handles InstallComponents (the step-panels: welcome, download, ant ...) and can be configured with an xml file. Adding/repalcing of components from other should be easy. The localization is done by property-files, so someone can add or edit language-files. On the website the installer available as webstart. http://ww.mieth-xml.de/openproject/hawron/download/webstart/installer/installer.jnlp I personally think a good block-editor is needed for building the other step are quite simple. If there is interest, I would move this installer out from hawron to whatever. Best Regards, Simon
Do we want a GUI installer?
In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant. To demonstrate what we _could_ do, if we wanted to, I've knocked up an example of how it might work. You can download it from here: http://www.odoko.co.uk/installer.zip Just unzip this in the root of your 2.1.X checkout, and run either gui.sh or gui.cmd. Some notes about this installer: 1) It won't actually run Ant yet. It isn't likely to be much to make it do it, but I haven't given it the time yet. 2) In its current state, it is GPL licenced. The author has said he's happy to change licence 3) It includes GPL libraries. I'd need to see if the author is prepared to remove these from it 4) The block selection is pretty laborious now. I would extend the installer app so that we can have a single selection box, where we tick/untick each block, and scroll down. 5) I haven't tested the gui.cmd script, but it should work, as the settings are the same as the Unix script. The installer home is at antinstaller.sourceforge.net. Thoughts? Regards, Upayavira
Re: Do we want a GUI installer?
Upayavira wrote: 1) It won't actually run Ant yet. It isn't likely to be much to make it do it, but I haven't given it the time yet. 2) In its current state, it is GPL licenced. The author has said he's happy to change licence 3) It includes GPL libraries. I'd need to see if the author is prepared to remove these from it 4) The block selection is pretty laborious now. I would extend the installer app so that we can have a single selection box, where we tick/untick each block, and scroll down. 5) I haven't tested the gui.cmd script, but it should work, as the settings are the same as the Unix script. (gui.cmd works) I take it that antinstall-config.xml is (will be) autogenerated from the blocks configuration files? Thoughts? I can see this being useful for first time cocooners. What if the cocoon build switches to maven (as rumoured a few times already)? Can the tool be extended to handle this? Will you need seperate logic to handle the 2.2 block configuration? Overall, IMO the potential effort of maintaining such a tool isn't worth the benefit. Regards, Jorg
Re: Do we want a GUI installer?
Jorg Heymans wrote: Upayavira wrote: 1) It won't actually run Ant yet. It isn't likely to be much to make it do it, but I haven't given it the time yet. 2) In its current state, it is GPL licenced. The author has said he's happy to change licence 3) It includes GPL libraries. I'd need to see if the author is prepared to remove these from it 4) The block selection is pretty laborious now. I would extend the installer app so that we can have a single selection box, where we tick/untick each block, and scroll down. 5) I haven't tested the gui.cmd script, but it should work, as the settings are the same as the Unix script. (gui.cmd works) I take it that antinstall-config.xml is (will be) autogenerated from the blocks configuration files? This time round it was generated from the blocks.properties with a Perl script. In future it would come from an XSLT on the gump.xml file. Yes. Thoughts? I can see this being useful for first time cocooners. What if the cocoon build switches to maven (as rumoured a few times already)? Can the tool be extended to handle this? Will you need seperate logic to handle the 2.2 block configuration? If it can be done from Ant, it can be done with this tool. All it does is collects properties and delivers them to Ant. Overall, IMO the potential effort of maintaining such a tool isn't worth the benefit. Maybe. Which is why I was asking! The effort to maintain for 2.1 is pretty minimal - it would just be a single XSLT on gump.xml and a few jars in the repo. For 2.2, well, we'll need to see what that is before we can decide! Regards, Upayavira
Re: Do we want a GUI installer?
Upayavira wrote: I can see this being useful for first time cocooners. What if the cocoon build switches to maven (as rumoured a few times already)? Can the tool be extended to handle this? Will you need seperate logic to handle the 2.2 block configuration? If it can be done from Ant, it can be done with this tool. All it does is collects properties and delivers them to Ant. Overall, IMO the potential effort of maintaining such a tool isn't worth the benefit. Maybe. Which is why I was asking! The effort to maintain for 2.1 is pretty minimal - it would just be a single XSLT on gump.xml and a few jars in the repo. For 2.2, well, we'll need to see what that is before we can decide! Well if it's no effort i don't see why it couldn't be added to the next release as an experiment (pending license issues ofcourse). As long as you make sure that the users know it's just a toy-experiment and nothing more there should be no harm. Actually, will/should Lepido provide anything like this? Any Lepido'ers care to comment? Jorg
Re: Do we want a GUI installer?
Le 14 avr. 05, à 11:15, Upayavira a écrit : ...In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant... I remember a discussion a while ago about building a WebStart-based installer. People were strongly against it, the point being that it's better for people to fail early rather than erroneously believe that Cocoon is a point-and-click tool I think the need to manually edit some config files remains a good way of showing people what kind of skillset and mindset is needed to use Cocoon today - I wouldn't bother about GUI config tools unless they're integrated in a cohesive IDE. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Do we want a GUI installer?
Bertrand Delacretaz wrote: Le 14 avr. 05, à 11:15, Upayavira a écrit : ...In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant... I remember a discussion a while ago about building a WebStart-based installer. People were strongly against it, the point being that it's better for people to fail early rather than erroneously believe that Cocoon is a point-and-click tool I think the need to manually edit some config files remains a good way of showing people what kind of skillset and mindset is needed to use Cocoon today - I wouldn't bother about GUI config tools unless they're integrated in a cohesive IDE. No probs. I'll just keep this tool in my personal toolbox then. Regards, Upayavira
Re: Do we want a GUI installer?
On Jue, 14 de Abril de 2005, 10:20, Upayavira dijo: Bertrand Delacretaz wrote: Le 14 avr. 05, à 11:15, Upayavira a écrit : ...In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant... I remember a discussion a while ago about building a WebStart-based installer. People were strongly against it, the point being that it's better for people to fail early rather than erroneously believe that Cocoon is a point-and-click tool I think the need to manually edit some config files remains a good way of showing people what kind of skillset and mindset is needed to use Cocoon today - I wouldn't bother about GUI config tools unless they're integrated in a cohesive IDE. No probs. I'll just keep this tool in my personal toolbox then. What about an sourceforge project? The only problem I see here are the (L)GPL-ed libs used. AFAIK an SF project is better than a personal toolbox. ;-) People will use it and try it if this is avaliable. We we gladly can add a link in cocoon website. WDYT? Best Regards, Antonio Gallardo
Re: Do we want a GUI installer?
I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. Skip -- Dr. Everett (Skip) Carter Phone: 831-641-0645 FAX: 831-641-0647 Taygeta Scientific Inc.INTERNET: [EMAIL PROTECTED] 1340 Munras Ave., Suite 314WWW: http://www.taygeta.com Monterey, CA. 93940
Re: Do we want a GUI installer?
Antonio Gallardo wrote: On Jue, 14 de Abril de 2005, 10:20, Upayavira dijo: Bertrand Delacretaz wrote: Le 14 avr. 05, à 11:15, Upayavira a écrit : ...In the work I've been doing with Snapbridge recently, I came across a rather neat GUI installer, that basically provides a front end to Ant... I remember a discussion a while ago about building a WebStart-based installer. People were strongly against it, the point being that it's better for people to fail early rather than erroneously believe that Cocoon is a point-and-click tool I think the need to manually edit some config files remains a good way of showing people what kind of skillset and mindset is needed to use Cocoon today - I wouldn't bother about GUI config tools unless they're integrated in a cohesive IDE. No probs. I'll just keep this tool in my personal toolbox then. What about an sourceforge project? The only problem I see here are the (L)GPL-ed libs used. AFAIK an SF project is better than a personal toolbox. ;-) People will use it and try it if this is avaliable. We we gladly can add a link in cocoon website. WDYT? The installer itself is on Sourceforge. My installer is just a single config file for that. If I were to commit this to Cocoon, I'd talk to the developer to get licenses changed. But it seems that people aren't that keen anyway. And I'm not really interested in maintaining this elsewhere. So, doesn't seem to be a go-er. Regards, Upayavira
Re: Do we want a GUI installer?
Skip Carter wrote: I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. There is no way that such an installer would replace the current system, merely augment it. This installer is nothing more than a wrapper around our existing Ant scripts anyway. After all, many Cocoon installations are on headless servers. The intention was to smooth over that early stage of usage when someone is at the beginning of learning Cocoon. Throwing them into having to copy and edit text files when they first start IMO introduces complexity that they could well do with learning a little later in their involvement with Cocoon. But, having said that, it doesn't seem like people are that keen on the idea anyway. Regrards, Upayavira
Re: Do we want a GUI installer?
On 4/14/05, Upayavira [EMAIL PROTECTED] wrote: Skip Carter wrote: I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. There is no way that such an installer would replace the current system, merely augment it. This installer is nothing more than a wrapper around our existing Ant scripts anyway. After all, many Cocoon installations are on headless servers. The intention was to smooth over that early stage of usage when someone is at the beginning of learning Cocoon. Throwing them into having to copy and edit text files when they first start IMO introduces complexity that they could well do with learning a little later in their involvement with Cocoon. But, having said that, it doesn't seem like people are that keen on the idea anyway. I think without the license problems people might be in favour or least neutral. Perhaps you could include the config script with Cocoon with a pointer to the Source Forge project? Alternately, maybe you could donate the config file to the Source Forge project and include something in the Cocoon docs... -- Peter Hunsberger
Re: Do we want a GUI installer?
Upayavira wrote: Skip Carter wrote: I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. There is no way that such an installer would replace the current system, merely augment it. This installer is nothing more than a wrapper around our existing Ant scripts anyway. After all, many Cocoon installations are on headless servers. The intention was to smooth over that early stage of usage when someone is at the beginning of learning Cocoon. Throwing them into having to copy and edit text files when they first start IMO introduces complexity that they could well do with learning a little later in their involvement with Cocoon. But, having said that, it doesn't seem like people are that keen on the idea anyway. If the user can get all the way to start Jetty with our demos through a simple GUI, I find it a good idea. Even if I'm perfectly able to read a README and run ant or make when I evaluate some new software, IMO the sooner I can start to evaluate what it does the better. The easier we can make using Cocoon, the better IMO. Cocoon is an excelent tool for complicted stuff, my goal is to help making simple things simple ;) So if you can fix the licence problems you have my +1 at least. /Daniel
Re: Do we want a GUI installer?
Daniel Fagerstrom wrote: Upayavira wrote: Skip Carter wrote: I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. There is no way that such an installer would replace the current system, merely augment it. This installer is nothing more than a wrapper around our existing Ant scripts anyway. After all, many Cocoon installations are on headless servers. The intention was to smooth over that early stage of usage when someone is at the beginning of learning Cocoon. Throwing them into having to copy and edit text files when they first start IMO introduces complexity that they could well do with learning a little later in their involvement with Cocoon. But, having said that, it doesn't seem like people are that keen on the idea anyway. If the user can get all the way to start Jetty with our demos through a simple GUI, I find it a good idea. Even if I'm perfectly able to read a README and run ant or make when I evaluate some new software, IMO the sooner I can start to evaluate what it does the better. The easier we can make using Cocoon, the better IMO. Cocoon is an excelent tool for complicted stuff, my goal is to help making simple things simple ;) So if you can fix the licence problems you have my +1 at least. That's my thinking too. If we want to put complexity in front of people to scare them away, we just need to put Cocoon in front of them :-) Regards, Upayavira
Re: Do we want a GUI installer?
Peter Hunsberger wrote: On 4/14/05, Upayavira [EMAIL PROTECTED] wrote: Skip Carter wrote: I'd rather not see one. At least if one is developed, there needs remain to be a way to install from the command line. ALL of my cocoon installations are on headless systems, and some of them are remote, so a GUI is not really very practical. There is no way that such an installer would replace the current system, merely augment it. This installer is nothing more than a wrapper around our existing Ant scripts anyway. After all, many Cocoon installations are on headless servers. The intention was to smooth over that early stage of usage when someone is at the beginning of learning Cocoon. Throwing them into having to copy and edit text files when they first start IMO introduces complexity that they could well do with learning a little later in their involvement with Cocoon. But, having said that, it doesn't seem like people are that keen on the idea anyway. I think without the license problems people might be in favour or least neutral. Perhaps you could include the config script with Cocoon with a pointer to the Source Forge project? Alternately, maybe you could donate the config file to the Source Forge project and include something in the Cocoon docs... Without a fix to the licencing problems, I ain't taking this any further. The author is willing to relicense, it is just a question of how embedded his other jars are into his code. Regards, Upayavira
Re: Do we want a GUI installer?
On Thu, 14 Apr 2005 20:49:33 +0200 Daniel Fagerstrom [EMAIL PROTECTED] wrote: Upayavira wrote: If the user can get all the way to start Jetty with our demos through a simple GUI, I find it a good idea. Even if I'm perfectly able to read a README and run ant or make when I evaluate some new software, IMO the sooner I can start to evaluate what it does the better. The easier we can make using Cocoon, the better IMO. Cocoon is an excelent tool for complicted stuff, my goal is to help making simple things simple ;) So if you can fix the licence problems you have my +1 at least. /Daniel Hi all, sorry for the noise, I have written a little GUI tool for Offline-Processing with Cocoon, that includes now Jetty and an Installer (available separate and as webstart) under ASL 2.0. http://sourceforge.net/projects/hawron Best Regards, Simon
Re: Do we want a GUI installer?
Hi, On 14 Apr 2005, at 19:21, Upayavira wrote: But it seems that people aren't that keen anyway. And I'm not really interested in maintaining this elsewhere. Yeah, not much point maintaining it elsewhere. Something that's supposed to make it easier to use shouldn't be difficult to get hold of. So, doesn't seem to be a go-er. I dunno, I'd like to see it in the sandbox at least. Whilst I agree Cocoon is no point and click tool, I really don't see why we shouldn't provide things that make it easier for those that just want to get on and work. Now a lot of us use Macs, we're allowed to condone GUIs, aren't we? :-) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
