Hello,
The Jasper plugin is in need of some updating, and I think that that updating could be more easily facilitated (and discussed) on Servoy forge. It was agreed some time ago that the plugin space would move from Google code to Servoy Forge, but that conversation seems to have stalled.
When can we expect to see it moved?
Thanks
Hi Jeff,
what is so urgent that it needs updating? The next release should be soon if the beta 3 works ok from examining the google code pages.
What is better in your opinion when hosted on ServoyForge compared to google code?
Is there any one else out there who would like to see a formal plan of migration from google code to Servoy Forge?
I personally support the move although I am hesitant when the testing is becoming more complex with the three types of plugins now available.
Jeff, which version are you proposing to update? Basic, Chart or Advanced (or all?).
I am sure Servoy has some unpublished reasons to not migrate just yet…
The main purpose of ServoyForge is to be the one stop shop for every Open Source projects related to Servoy, I think that’s a good reason to put the jasper reports plugin there too.
As to which version should be moved, I would say that it’s high time that a consolidated version of these 3 “types” of plugin get worked on, because no one really have a clear idea how these 3 versions really compare and which one does what, apart from you Tom
Hi,
First of all: I do not see any reason why moving the plugin forward would be hold back by a move to Servoyforge or not: Google code of the ServoyForge stack offer similar functionality.
Second: Moving the plugin over to SF is on the todo list, no specific reason why it hasn’t happened, other than priorities.
Paul
Hi Tom,
what is so urgent that it needs updating?
Well actually, my primary concern was related to issue 26. That issue was reported in May, but not closed/fixed until July. And to be perfectly honest until I looked at the site this AM, I didn’t even realize the issue was closed with the July release, so my sense of urgency is somewhat lessened. I’m going to try to ditch my own fork of the plugin, which included fixes for issue 26 and other enhancements in favor of the July release. If it works as expected then I don’t have an immediate need for new features/updates.
What is better in your opinion when hosted on ServoyForge compared to google code?
FYI, this was convered in great detail in a Google Wave w/ Servoy corp and OS developers a little while back. There are quite a lot of great reasons for ServoyForge and for moving any and all OS plugins to forge, from their current spaces. I won’t reiterate all of that here.
Is there any one else out there who would like to see a formal plan of migration from google code to Servoy Forge?
There were many folks involved in the Wave that pushed for this, and see the value in moving code from other spaces to Forge. Again, b/c this was covered in such great detail already, I wouldn’t expect much traction on your unofficial poll.
Jeff, which version are you proposing to update? Basic, Chart or Advanced (or all?).
There is no substantial difference as far as I am concerned. The only difference is what 3P libs are included + jnlp file creation and config. to help control the memory footprint of the plugin for client distribution. Unless I’ve missed something??
Thanks for the reply.
First of all: I do not see any reason why moving the plugin forward would be hold back by a move to Servoyforge or not: Google code of the ServoyForge stack offer similar functionality.
Second: Moving the plugin over to SF is on the todo list, no specific reason why it hasn’t happened, other than priorities.
Hi Paul,
I’m a little surprised by your response as you seemed to recognize the importance/benefit of moving code to forge during our Wave. Forge absolutely can catalyze and facilitate development and enhancement of plugins and other servoy-related components through [in part] exposure and collaboration that is lacking elsewhere.
But with that said, I guess the message from you and friends is to fly in a holding pattern for now, so that is what I will do.
[wrist slapped]
Hi Jeff,
You seem to interpret my point a bit wrong: When I say that the project being on Google Code still shouldn’t hold the further development of the plugin back, because GC and SF offer the same functionality I mean that in both cases you can access the code, send in patches, create cases and discuss stuff.
We do recognize the importance/benefits etc., hence our commitment to SF and our commitment to move this plugin (and more…) to SF. Just bare with us until we get around to it, that is all.
Paul