Home » Eclipse Projects » Virgo » Expected timeframe of 'real' Virgo release?
Expected timeframe of 'real' Virgo release? [message #549370] |
Mon, 26 July 2010 14:17 |
Ric Klaren Messages: 13 Registered: July 2010 |
Junior Member |
|
|
Hi,
My apology for nagging
I was wondering if some timeframe is already known for a Virgo 2.1.0 release?
We currently have the option of upgrading our product to Spring DM 2.2.0, or wait for a real Virgo release, or is the milestone expected to be stable enough?
Cheers,
Ric
[Updated on: Mon, 26 July 2010 15:05] Report message to a moderator
|
|
|
Re: Expected timeframe of 'real' Virgo release [message #549410 is a reply to message #549370] |
Mon, 26 July 2010 15:16 |
|
Hi,
Thanks for the interest. I would not recommend going in to production on a milestone, they are pretty good but still milestones.
We are aiming to get 2.1.0.RELEASE out by the end of the year but it will still be on Spring DM 1.2.1. We will have Eclipse Gemini Blueprint when we get version 3 of Virgo out next year. Blueprint is the Spring DM donation to Eclipse.
http://www.eclipse.org/gemini/
Chris.
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
|
|
| |
Re: Expected timeframe of 'real' Virgo release [message #549870 is a reply to message #549561] |
Wed, 28 July 2010 09:47 |
|
Hi,
The end of year release will have some significant changes, not enough to warrant a major version release but certainly more than a re-branding. Apart from the usual collection of bug fixes we have had to drop back to the equinox console from our own due to IP reasons. Quite a few components will have been upgraded to newer versions such as Tomcat, Spring, Logback etc... There have been some significant performance improvements made. (Performance improvements are talked about here, http://blog.springsource.com/2010/07/08/5x-startup-performan ce-boost-in-virgo-milestone-m02/)
We would love to gain more committers and if they were to work on things for the release we would progress quicker. It dose take time to progress someone to committer status though. A first step would be to get involved on the forums and to start submitting patches for us to apply. Once we get to know and like you we can recommend committer status to Eclipse for you. Check out the relevant section of our wiki for more. http://wiki.eclipse.org/Virgo/Community
It would be great to know your use case for Virgo, if you are considering vanilla OSGi for production I guess you don't need the web support, are you aware of the Kernel version of Virgo that has many of the benefits of Virgo without the Web stuff on top. Happy to talk off line.
Chris.
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
|
|
|
Re: Expected timeframe of 'real' Virgo release [message #550410 is a reply to message #549870] |
Fri, 30 July 2010 09:48 |
Ric Klaren Messages: 13 Registered: July 2010 |
Junior Member |
|
|
Christopher Frost wrote on Wed, 28 July 2010 05:47 | We would love to gain more committers and if they were to work on things for the release we would progress quicker. It dose take time to progress someone to committer status though. A first step would be to get involved on the forums and to start submitting patches for us to apply. Once we get to know and like you we can recommend committer status to Eclipse for you. Check out the relevant section of our wiki for more. http://wiki.eclipse.org/Virgo/Community
|
Stands to reason. We shall see how things develop. Is there an overview somewhere (bugzilla?) of things that need to be done for the release? Then we can check if things coincide with things we are interested in.
Quote: | It would be great to know your use case for Virgo, if you are considering vanilla OSGi for production I guess you don't need the web support, are you aware of the Kernel version of Virgo that has many of the benefits of Virgo without the Web stuff on top. Happy to talk off line.
|
We currently use a hibernate, wicket stack (and one bundle with legacy pre-osgi parts of our framework which we are slowly stripping down/porting to our new stack). Large functional parts are separated out in bundles and are hot pluggable (or configurable over a reboot) So for different customers we can deploy different sets of bundles to have bits of functionality (UI and domain) appear. Also we can split out reporting functionality to a differently configured DM Server so load of big reports can be off-loaded of the normal flow.
As a result of our pluggability we are starting to dislike web.xml, it forces us to have explicit dependencies our 'web' bundle does not need. We particularly miss something like the OSGi HTTP Service. The snaps/slices stuff could be useful but it feels a bit heavy for what we need. Also the fact that it uses custom headers in manifests is something that makes us careful. We looked around a bit and found some of the ideas of Pax Web appealing. We didn't have time yet to investigate both of them in depth so this is all based on first impressions.
Another interest of ours is monitoring that all bundles that need to be running are indeed running. I think a framework like virgo would benefit of some kind of watchdog functionality, I guess this would have to integrate/interact with the plan deployer.
We currently hate the way we have to kludge around DM server zip files during installs and CI. We would really love to be able to specify maven/ivy artifacts that should be glued together into an installer so we can make our install process smoother (and less error prone) and make it easier to say create a server installer with an upgraded spring framework/logback/whatever. We have some ideas to move our maven build to gradle which can interact with maven and/or ivy repositories and seems to have a more 'getting things done' approach. Maven gets in the way of being productive too often, also gradles input is much more concise than the bloated maven XML.
Cheers,
Ric
PS I will be away the next week, so I will probably not be checking the forum in that time.
|
|
|
Re: Expected timeframe of 'real' Virgo release [message #550424 is a reply to message #550410] |
Fri, 30 July 2010 10:40 |
|
Hi Ric,
There are a lot of things to talk about here and our team leader will be back from holiday on Monday and I'm keen to get his opinion for you. We will send a full reply next week while you are away.
Thanks, Chris.
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
|
|
| | | |
Re: Expected timeframe of 'real' Virgo release [message #592810 is a reply to message #592785] |
Wed, 28 July 2010 09:47 |
|
Hi,
The end of year release will have some significant changes, not enough to warrant a major version release but certainly more than a re-branding. Apart from the usual collection of bug fixes we have had to drop back to the equinox console from our own due to IP reasons. Quite a few components will have been upgraded to newer versions such as Tomcat, Spring, Logback etc... There have been some significant performance improvements made. (Performance improvements are talked about here, http://blog.springsource.com/2010/07/08/5x-startup-performan ce-boost-in-virgo-milestone-m02/)
We would love to gain more committers and if they were to work on things for the release we would progress quicker. It dose take time to progress someone to committer status though. A first step would be to get involved on the forums and to start submitting patches for us to apply. Once we get to know and like you we can recommend committer status to Eclipse for you. Check out the relevant section of our wiki for more. http://wiki.eclipse.org/Virgo/Community
It would be great to know your use case for Virgo, if you are considering vanilla OSGi for production I guess you don't need the web support, are you aware of the Kernel version of Virgo that has many of the benefits of Virgo without the Web stuff on top. Happy to talk off line.
Chris.
--
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
|
|
|
Re: Expected timeframe of 'real' Virgo release [message #594339 is a reply to message #592810] |
Fri, 30 July 2010 09:48 |
Ric Klaren Messages: 13 Registered: July 2010 |
Junior Member |
|
|
Christopher Frost wrote on Wed, 28 July 2010 05:47
> We would love to gain more committers and if they were to work on things for the release we would progress quicker. It dose take time to progress someone to committer status though. A first step would be to get involved on the forums and to start submitting patches for us to apply. Once we get to know and like you we can recommend committer status to Eclipse for you. Check out the relevant section of our wiki for more. http://wiki.eclipse.org/Virgo/Community
Stands to reason. We shall see how things develop. Is there an overview somewhere (bugzilla?) of things that need to be done for the release? Then we can check if things coincide with things we are interested in.
Quote:
> It would be great to know your use case for Virgo, if you are considering vanilla OSGi for production I guess you don't need the web support, are you aware of the Kernel version of Virgo that has many of the benefits of Virgo without the Web stuff on top. Happy to talk off line.
We currently use a hibernate, wicket stack (and one bundle with legacy pre-osgi parts of our framework which we are slowly stripping down/porting to our new stack). Large functional parts are separated out in bundles and are hot pluggable (or configurable over a reboot) So for different customers we can deploy different sets of bundles to have bits of functionality (UI and domain) appear. Also we can split out reporting functionality to a differently configured DM Server so load of big reports can be off-loaded of the normal flow.
As a result of our pluggability we are starting to dislike web.xml, it forces us to have explicit dependencies our 'web' bundle does not need. We particularly miss something like the OSGi HTTP Service. The snaps/slices stuff could be useful but it feels a bit heavy for what we need. Also the fact that it uses custom headers in manifests is something that makes us careful. We looked around a bit and found some of the ideas of http://wiki.ops4j.org/display/paxweb/Pax+Web appealing. We didn't have time yet to investigate both of them in depth so this is all based on first impressions.
Another interest of ours is monitoring that all bundles that need to be running are indeed running. I think a framework like virgo would benefit of some kind of watchdog functionality, I guess this would have to integrate/interact with the plan deployer.
We currently hate the way we have to kludge around DM server zip files during installs and CI. We would really love to be able to specify maven/ivy artifacts that should be glued together into an installer so we can make our install process smoother (and less error prone) and make it easier to say create a server installer with an upgraded spring framework/logback/whatever. We have some ideas to move our maven build to gradle which can interact with maven and/or ivy repositories and seems to have a more 'getting things done' approach. Maven gets in the way of being productive too often, also gradles input is much more concise than the bloated maven XML.
Cheers,
Ric
PS I will be away the next week, so I will probably not be checking the forum in that time.
|
|
|
Re: Expected timeframe of 'real' Virgo release [message #594348 is a reply to message #550410] |
Fri, 30 July 2010 10:40 |
|
Hi Ric,
There are a lot of things to talk about here and our team leader will be back from holiday on Monday and I'm keen to get his opinion for you. We will send a full reply next week while you are away.
Thanks, Chris.
--
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
------------------------------------------------
Chris Frost, Twitter @cgfrost
Springsource, a divison of VMware.
|
|
| | |
Goto Forum:
Current Time: Sat Apr 27 16:36:06 GMT 2024
Powered by FUDForum. Page generated in 0.04929 seconds
|