Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
On 11.11.2011 12:43, Michaël Michaud wrote: > - PLUS distribution already includes Batik and JumpFillPattern from > CadPlan. Batik needs to be in lib directory . I'll see if I can change > that, putting it in ext directory seems more logical to me. why exactly? i'd understand lib/ext/ more as the lib folder for oj extensions and their dependencies. as the the extensions using batik are actually in the core i'd put them into lib/ as well. > Now I missed some hints about how to modify the maven files to get > exactly that. > I put the batik-all.jar in the plus directory, but with current > configuration, it will go to ext directory, not lib (which does not work > yet) i'd have to check, but wouldn't put them there anyway. > Currently, batik jar files are defined in pom.xml and are included in > CORE and in PLUS NB as many separated jar files. I don't know how to > include this dependency for PLUS distro only. how to realize that depends if we need batik during compilation already. if yes we would exclude batik during packaging (see bin_core.xml) for CORE and manually include it for PLUS (bin_zip-ext.xml). if not we could remove it as a dependency and simply add it for PLUS packaging only. ..ede > > Any hint ? > Thanks > > Michaël > > > Le 06/11/2011 13:03, Edgar Soldin a écrit : >>> moving batik into a separate folder? - I think we had this once... It's >>> an option. >> it's more organizational than problem solving. >> a) e.g. for geotools i could not make sure that a specific plugin is >> compatible with the version needed by another plugin. >> b) the size stays the same only the lib folder is a bit more ordered >> >>> PS: on the lightness of the core: I tried to download the latest gvSIG >>> version... a) its about 130MB+ and b) I got a download rate of 30 kb/sec >>> = 1h 40min... so I stopped it. But their developer download on SF was >>> much fast.. due to the SF infrastructure. >> that's why i took care that the new snapshots ended up on the mirrored >> sf.net files section >> >>> However, the main point is: if >>> your distribution is 130MB and you have this download rate, you may just >>> loose users because of this. (I am not even sure how one is supposed to >>> download their 1 GB special editions with that speed). >> i think as long as we can use sf.net or similar infrastructure we would be >> safe to even have ultra edition with 1GB, because sf.net has worldwide >> mirrors. >> of course we should still keep a slim core edition for people on slower >> infrastructures. >> >> ..ede >> >>> Am 05.11.11 10:10, schrieb Giuseppe Aruta: >>>> Hi Michael, >>>> I agree with the idea to move Batik (and corresponding tools) out of >>>> core software. Another idea could be to create some extra folders for >>>> big libraries, like OJ/lib/geotools and OJ/lib/batik and use them for >>>> whatever external library developers need to make a plugin. This >>>> probably makes the software structure more clean and we could avoid >>>> duplicates. >>>> I have other ideas for styling, not so complicated to make (I was able >>>> to made them on Jufre) - to have a more flexible OJ. I will get all >>>> ideas and post with more details. >>>> >>>> Giuseppe >>>> >>>> >>>> *Da:* Michaël Michaud >>>> *A:* jump-pilot-devel@lists.sourceforge.net >>>> *Inviato:* Sabato 5 Novembre 2011 11:59 >>>> *Oggetto:* Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style >>>> >>>> Hi Peppe, >>>>> It seems to be solved. >>>>> I think that before the bug somebody moved away from >>>>> com.vividsolution.jump.workbench.ui.images all the JPG ( the ones >>>>> shown into the Style fill pattern from no. 38 to n. 188 by Aquino, 121 >>>>> files - 500 kb), without modifing FillPatternFactory file which >>>>> controls the presence of those images on the menu (see on this file >>>>> lines lines from 72 to 192 which begin with "new >>>>> ImageFillPattern(IconLoader.class, "etc). >>>>> Than the files were put back into >>>>> com.vividsolution.jump.workbench.ui.images folder and the bug >>>>> "magically" had gone. >>>> Ah, OK, thanks, >>>>> On the other hand the idea is still valid, I think >>>>> >>>>> We
Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
Hi, So, I've prepared the code in the following way : - CORE distribution will not include Batik anymore. SaveImageAsSVGPlugIn is still there but inactive (log a message in the log file as ecw or MrSID loaders). Putting batik jar(s) file(s) in lib directory will be enough to make it available again. So if we change our mind, it will be easy to revert. - PLUS distribution already includes Batik and JumpFillPattern from CadPlan. Batik needs to be in lib directory . I'll see if I can change that, putting it in ext directory seems more logical to me. Now I missed some hints about how to modify the maven files to get exactly that. I put the batik-all.jar in the plus directory, but with current configuration, it will go to ext directory, not lib (which does not work yet) Currently, batik jar files are defined in pom.xml and are included in CORE and in PLUS NB as many separated jar files. I don't know how to include this dependency for PLUS distro only. Any hint ? Thanks Michaël Le 06/11/2011 13:03, Edgar Soldin a écrit : >> moving batik into a separate folder? - I think we had this once... It's >> an option. > it's more organizational than problem solving. > a) e.g. for geotools i could not make sure that a specific plugin is > compatible with the version needed by another plugin. > b) the size stays the same only the lib folder is a bit more ordered > >> PS: on the lightness of the core: I tried to download the latest gvSIG >> version... a) its about 130MB+ and b) I got a download rate of 30 kb/sec >> = 1h 40min... so I stopped it. But their developer download on SF was >> much fast.. due to the SF infrastructure. > that's why i took care that the new snapshots ended up on the mirrored sf.net > files section > >> However, the main point is: if >> your distribution is 130MB and you have this download rate, you may just >> loose users because of this. (I am not even sure how one is supposed to >> download their 1 GB special editions with that speed). > i think as long as we can use sf.net or similar infrastructure we would be > safe to even have ultra edition with 1GB, because sf.net has worldwide > mirrors. > of course we should still keep a slim core edition for people on slower > infrastructures. > > ..ede > >> Am 05.11.11 10:10, schrieb Giuseppe Aruta: >>> Hi Michael, >>> I agree with the idea to move Batik (and corresponding tools) out of >>> core software. Another idea could be to create some extra folders for >>> big libraries, like OJ/lib/geotools and OJ/lib/batik and use them for >>> whatever external library developers need to make a plugin. This >>> probably makes the software structure more clean and we could avoid >>> duplicates. >>> I have other ideas for styling, not so complicated to make (I was able >>> to made them on Jufre) - to have a more flexible OJ. I will get all >>> ideas and post with more details. >>> >>> Giuseppe >>> >>> >>> *Da:* Michaël Michaud >>> *A:* jump-pilot-devel@lists.sourceforge.net >>> *Inviato:* Sabato 5 Novembre 2011 11:59 >>> *Oggetto:* Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style >>> >>> Hi Peppe, >>>> It seems to be solved. >>>> I think that before the bug somebody moved away from >>>> com.vividsolution.jump.workbench.ui.images all the JPG ( the ones >>>> shown into the Style fill pattern from no. 38 to n. 188 by Aquino, 121 >>>> files - 500 kb), without modifing FillPatternFactory file which >>>> controls the presence of those images on the menu (see on this file >>>> lines lines from 72 to 192 which begin with "new >>>> ImageFillPattern(IconLoader.class, "etc). >>>> Than the files were put back into >>>> com.vividsolution.jump.workbench.ui.images folder and the bug >>>> "magically" had gone. >>> Ah, OK, thanks, >>>> On the other hand the idea is still valid, I think >>>> >>>> We could modify FillPatternFactory deleting/commentig lines from 72 to >>>> 192 (the lines which begin with "new >>>> ImageFillPattern(IconLoader.class, "etc). >>>> The effect is to not display on Style Fill Patter menu all those JPG file. >>>> Which are the positive things, from my point of view. >>>> 1) all these JPG could be moved into a separate folder. Menu 189 (open >>>> image) on Fill Pattern menu can load them and other raster as a fill >>>> pattern. >>>> 2) CADPlann pl
Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
> > moving batik into a separate folder? - I think we had this once... It's > an option. it's more organizational than problem solving. a) e.g. for geotools i could not make sure that a specific plugin is compatible with the version needed by another plugin. b) the size stays the same only the lib folder is a bit more ordered > > PS: on the lightness of the core: I tried to download the latest gvSIG > version... a) its about 130MB+ and b) I got a download rate of 30 kb/sec > = 1h 40min... so I stopped it. But their developer download on SF was > much fast.. due to the SF infrastructure. that's why i took care that the new snapshots ended up on the mirrored sf.net files section >However, the main point is: if > your distribution is 130MB and you have this download rate, you may just > loose users because of this. (I am not even sure how one is supposed to > download their 1 GB special editions with that speed). i think as long as we can use sf.net or similar infrastructure we would be safe to even have ultra edition with 1GB, because sf.net has worldwide mirrors. of course we should still keep a slim core edition for people on slower infrastructures. ..ede > > Am 05.11.11 10:10, schrieb Giuseppe Aruta: >> Hi Michael, >> I agree with the idea to move Batik (and corresponding tools) out of >> core software. Another idea could be to create some extra folders for >> big libraries, like OJ/lib/geotools and OJ/lib/batik and use them for >> whatever external library developers need to make a plugin. This >> probably makes the software structure more clean and we could avoid >> duplicates. >> I have other ideas for styling, not so complicated to make (I was able >> to made them on Jufre) - to have a more flexible OJ. I will get all >> ideas and post with more details. >> >> Giuseppe >> >> -------- >> *Da:* Michaël Michaud >> *A:* jump-pilot-devel@lists.sourceforge.net >> *Inviato:* Sabato 5 Novembre 2011 11:59 >> *Oggetto:* Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style >> >> Hi Peppe, >>> It seems to be solved. >>> I think that before the bug somebody moved away from >>> com.vividsolution.jump.workbench.ui.images all the JPG ( the ones >>> shown into the Style fill pattern from no. 38 to n. 188 by Aquino, 121 >>> files - 500 kb), without modifing FillPatternFactory file which >>> controls the presence of those images on the menu (see on this file >>> lines lines from 72 to 192 which begin with "new >>> ImageFillPattern(IconLoader.class, "etc). >>> Than the files were put back into >>> com.vividsolution.jump.workbench.ui.images folder and the bug >>> "magically" had gone. >> Ah, OK, thanks, >>> On the other hand the idea is still valid, I think >>> >>> We could modify FillPatternFactory deleting/commentig lines from 72 to >>> 192 (the lines which begin with "new >>> ImageFillPattern(IconLoader.class, "etc). >>> The effect is to not display on Style Fill Patter menu all those JPG file. >>> Which are the positive things, from my point of view. >>> 1) all these JPG could be moved into a separate folder. Menu 189 (open >>> image) on Fill Pattern menu can load them and other raster as a fill >>> pattern. >>> 2) CADPlann plugin JumpFillPattern.jar would be more visible, if >>> installed. >>> For users who don't know about this plugin. It shows on Fill Patter >>> menu whatever raster or vector (WKT and SVG) file as a pattern for >>> polygon items. >>> Users can draw their own patters with Inkscape or other draw software >>> and then use it as a fill pattern. WKT files made using OJ can be used >>> too. >>> Actually all pattern loaded by JumpFillPattern.jar are displayed at >>> the lowestmost part of the Fill Pattern menu (after position 189) and >>> so it is not visible the potential of this plugin. >> Just checked your proposal. I don't use much styling and always learn >> something from your suggestions :-) >> I agree with your argument. I'd like to hear from others though. >> I wondered if we should ask Geoff to include JumpFillPattern in the core >> distribution in this case. >> But it depends on Batik jar file. I checked what are the dependencies to >> Batik and just found SaveImageAsSVG plugin. Batik being a 3 Mo >> dependency, I would be tempted to move all Batik-dependant plugins >> (SaveImageAsSVG and Cadplan extensions) to the PLUS distribution to keep >
Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
mhm.. could go into OJ Plus. Not sure how many people use the SVG option. I do fairly often - but not sooo often. moving batik into a separate folder? - I think we had this once... It's an option. on the fill-pattern proposal by Pepper: Why not. agreed (without having actually a look at it). stefan PS: on the lightness of the core: I tried to download the latest gvSIG version... a) its about 130MB+ and b) I got a download rate of 30 kb/sec = 1h 40min... so I stopped it. But their developer download on SF was much fast.. due to the SF infrastructure. However, the main point is: if your distribution is 130MB and you have this download rate, you may just loose users because of this. (I am not even sure how one is supposed to download their 1 GB special editions with that speed). Am 05.11.11 10:10, schrieb Giuseppe Aruta: > Hi Michael, > I agree with the idea to move Batik (and corresponding tools) out of > core software. Another idea could be to create some extra folders for > big libraries, like OJ/lib/geotools and OJ/lib/batik and use them for > whatever external library developers need to make a plugin. This > probably makes the software structure more clean and we could avoid > duplicates. > I have other ideas for styling, not so complicated to make (I was able > to made them on Jufre) - to have a more flexible OJ. I will get all > ideas and post with more details. > > Giuseppe > > > *Da:* Michaël Michaud > *A:* jump-pilot-devel@lists.sourceforge.net > *Inviato:* Sabato 5 Novembre 2011 11:59 > *Oggetto:* Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style > > Hi Peppe, >> It seems to be solved. >> I think that before the bug somebody moved away from >> com.vividsolution.jump.workbench.ui.images all the JPG ( the ones >> shown into the Style fill pattern from no. 38 to n. 188 by Aquino, 121 >> files - 500 kb), without modifing FillPatternFactory file which >> controls the presence of those images on the menu (see on this file >> lines lines from 72 to 192 which begin with "new >> ImageFillPattern(IconLoader.class, "etc). >> Than the files were put back into >> com.vividsolution.jump.workbench.ui.images folder and the bug >> "magically" had gone. > Ah, OK, thanks, >> On the other hand the idea is still valid, I think >> >> We could modify FillPatternFactory deleting/commentig lines from 72 to >> 192 (the lines which begin with "new >> ImageFillPattern(IconLoader.class, "etc). >> The effect is to not display on Style Fill Patter menu all those JPG file. >> Which are the positive things, from my point of view. >> 1) all these JPG could be moved into a separate folder. Menu 189 (open >> image) on Fill Pattern menu can load them and other raster as a fill >> pattern. >> 2) CADPlann plugin JumpFillPattern.jar would be more visible, if >> installed. >> For users who don't know about this plugin. It shows on Fill Patter >> menu whatever raster or vector (WKT and SVG) file as a pattern for >> polygon items. >> Users can draw their own patters with Inkscape or other draw software >> and then use it as a fill pattern. WKT files made using OJ can be used >> too. >> Actually all pattern loaded by JumpFillPattern.jar are displayed at >> the lowestmost part of the Fill Pattern menu (after position 189) and >> so it is not visible the potential of this plugin. > Just checked your proposal. I don't use much styling and always learn > something from your suggestions :-) > I agree with your argument. I'd like to hear from others though. > I wondered if we should ask Geoff to include JumpFillPattern in the core > distribution in this case. > But it depends on Batik jar file. I checked what are the dependencies to > Batik and just found SaveImageAsSVG plugin. Batik being a 3 Mo > dependency, I would be tempted to move all Batik-dependant plugins > (SaveImageAsSVG and Cadplan extensions) to the PLUS distribution to keep > Core as light as possible. > > Any other advice on the topic ? > > Michaël > >> >> I made this modification on my version of OJ Jufre, if you want to see >> it the effects, I added to this mail 2 shots >> >> Peppe >> >> *Da:* Michaël Michaud >> <mailto:michael.mich...@free.fr> >> *A:* OpenJump develop and use >> <mailto:jump-pilot-devel@lists.sourceforge.net> >> *Inviato:* Venerdì 4 Novembre 2011 8:44 >> *Oggetto:* [JPP-Devel] Bug I 2688602 : Bugs on Change Style >> >> Hi Peppe, >> >> in 2009, yo
Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
Hi Michael, I agree with the idea to move Batik (and corresponding tools) out of core software. Another idea could be to create some extra folders for big libraries, like OJ/lib/geotools and OJ/lib/batik and use them for whatever external librarydevelopers need to make a plugin. This probably makes the software structure more clean and we could avoid duplicates. I have other ideas for styling, not so complicated to make (I was able to made them on Jufre) - to have a more flexible OJ. I will get all ideas and post with more details. Giuseppe Da: Michaël Michaud A: jump-pilot-devel@lists.sourceforge.net Inviato: Sabato 5 Novembre 2011 11:59 Oggetto: Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style Hi Peppe, It seems to be solved. >I think that before the bug somebody moved away from >com.vividsolution.jump.workbench.ui.images all the JPG ( the ones shown into >the Style fill pattern from no. 38 to n. 188 by Aquino, 121 files - 500 kb), >without modifing FillPatternFactory file which controls the presence of those >images on the menu (see on this file lines lines from 72 to 192 which begin >with "new ImageFillPattern(IconLoader.class, "etc). >Than the files were put back into com.vividsolution.jump.workbench.ui.images >folder and the bug "magically" had gone. > Ah, OK, thanks, On the other hand the idea is still valid, I think > > > >We could modify FillPatternFactory deleting/commentig lines from 72 to 192 >(the lines which begin with "new ImageFillPattern(IconLoader.class, "etc). >The effect is to not display on Style Fill Patter menu all those JPG file. > >Which are the positive things, from my point of view. >1) all these JPG could be moved into a separate folder. Menu 189 (open image) >on Fill Pattern menu can load them and other raster as a fill pattern. > >2) CADPlann plugin JumpFillPattern.jar would be more visible, if installed. > >For users who don't know about this plugin. It shows on Fill Patter menu >whatever raster or vector (WKT and SVG) file as a pattern for polygon items. > >Users can draw their own patters with Inkscape or other draw software and then >use it as a fill pattern. WKT files made using OJ can be used too. >Actually all pattern loaded by JumpFillPattern.jar are displayed at the >lowestmost part of the Fill Pattern menu (after position 189) and so it is not >visible the potential of this plugin. Just checked your proposal. I don't use much styling and always learn something from your suggestions :-) I agree with your argument. I'd like to hear from others though. I wondered if we should ask Geoff to include JumpFillPattern in the core distribution in this case. But it depends on Batik jar file. I checked what are the dependencies to Batik and just found SaveImageAsSVG plugin. Batik being a 3 Mo dependency, I would be tempted to move all Batik-dependant plugins (SaveImageAsSVG and Cadplan extensions) to the PLUS distribution to keep Core as light as possible. Any other advice on the topic ? Michaël > >I made this modification on my version of OJ Jufre, if you want to see it the >effects, I added to this mail 2 shots > > >Peppe > > >________ >Da: Michaël Michaud >A: OpenJump develop and use >Inviato: Venerdì 4 Novembre 2011 8:44 >Oggetto: [JPP-Devel] Bug I 2688602 : Bugs on Change Style > >Hi Peppe, > >in 2009, you described the following bug, can you tell me if it's solved >or if it happens on a particular os/jre... >I could not reproduc eit on Vista/Jre6 > >>bugs on Change Style>Fill pattern. > >>1) Fill patters shows 36 fill patterns: >>From 1 to 13 pattern it is possible to select the pattern and change >it afterward. >>From 14 pattern to 36, once choosen a pattern, it is not possible to >change it. > >>2) Opening the fill pattern display, the sidebar can go down easly >untill the last pattern (36), afterward it moves with difficulties until >it freeze the window. The user has to >close the Style window and reopen >it to change the style > >Michaël > >-- >RSA(R) Conference 2012 >Save $700 by Nov 18 >Register now >http://p.sf.net/sfu/rsa-sfdev2dev1 >___ >Jump-pilot-devel mailing list >Jump-pilot-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > >-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rs
Re: [JPP-Devel] Bug I 2688602 : Bugs on Change Style
Hi Peppe, It seems to be solved. I think that before the bug somebody moved away from com.vividsolution.jump.workbench.ui.images all the JPG ( the ones shown into the Style fill pattern from no. 38 to n. 188 by Aquino, 121 files - 500 kb), without modifing FillPatternFactory file which controls the presence of those images on the menu (see on this file lines lines from 72 to 192 which begin with "new ImageFillPattern(IconLoader.class, "etc). Than the files were put back into com.vividsolution.jump.workbench.ui.images folder and the bug "magically" had gone. Ah, OK, thanks, On the other hand the idea is still valid, I think We could modify FillPatternFactory deleting/commentig lines from 72 to 192 (the lines which begin with "new ImageFillPattern(IconLoader.class, "etc). The effect is to not display on Style Fill Patter menu all those JPG file. Which are the positive things, from my point of view. 1) all these JPG could be moved into a separate folder. Menu 189 (open image) on Fill Pattern menu can load them and other raster as a fill pattern. 2) CADPlann plugin JumpFillPattern.jar would be more visible, if installed. For users who don't know about this plugin. It shows on Fill Patter menu whatever raster or vector (WKT and SVG) file as a pattern for polygon items. Users can draw their own patters with Inkscape or other draw software and then use it as a fill pattern. WKT files made using OJ can be used too. Actually all pattern loaded by JumpFillPattern.jar are displayed at the lowestmost part of the Fill Pattern menu (after position 189) and so it is not visible the potential of this plugin. Just checked your proposal. I don't use much styling and always learn something from your suggestions :-) I agree with your argument. I'd like to hear from others though. I wondered if we should ask Geoff to include JumpFillPattern in the core distribution in this case. But it depends on Batik jar file. I checked what are the dependencies to Batik and just found SaveImageAsSVG plugin. Batik being a 3 Mo dependency, I would be tempted to move all Batik-dependant plugins (SaveImageAsSVG and Cadplan extensions) to the PLUS distribution to keep Core as light as possible. Any other advice on the topic ? Michaël I made this modification on my version of OJ Jufre, if you want to see it the effects, I added to this mail 2 shots Peppe *Da:* Michaël Michaud *A:* OpenJump develop and use *Inviato:* Venerdì 4 Novembre 2011 8:44 *Oggetto:* [JPP-Devel] Bug I 2688602 : Bugs on Change Style Hi Peppe, in 2009, you described the following bug, can you tell me if it's solved or if it happens on a particular os/jre... I could not reproduc eit on Vista/Jre6 >bugs on Change Style>Fill pattern. >1) Fill patters shows 36 fill patterns: >From 1 to 13 pattern it is possible to select the pattern and change it afterward. >From 14 pattern to 36, once choosen a pattern, it is not possible to change it. >2) Opening the fill pattern display, the sidebar can go down easly untill the last pattern (36), afterward it moves with difficulties until it freeze the window. The user has to >close the Style window and reopen it to change the style Michaël -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net <mailto:Jump-pilot-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Bug I 2688602 : Bugs on Change Style
Hi Peppe, in 2009, you described the following bug, can you tell me if it's solved or if it happens on a particular os/jre... I could not reproduc eit on Vista/Jre6 >bugs on Change Style>Fill pattern. >1) Fill patters shows 36 fill patterns: >From 1 to 13 pattern it is possible to select the pattern and change it afterward. >From 14 pattern to 36, once choosen a pattern, it is not possible to change it. >2) Opening the fill pattern display, the sidebar can go down easly untill the last pattern (36), afterward it moves with difficulties until it freeze the window. The user has to >close the Style window and reopen it to change the style Michaël -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
