Community
Participate
Working Groups
With the support for initial provisioning Virgo's folder structure will be slightly changed. I'll test if that change is incompatible with the Virgo tooling and propose a patch if that's the case.
Just wanted to check on the status on this. Do you anticipate any major changes? Just wanted to coordinate with you in case you did as I may be doing some significant refactorings in the next little while.
I haven't got time to look into this. The changes are the following: - the /config and /lib directories are merged into /configuration - /configuration now contains the java.profile and config.ini along with the *.properties files - config.ini is the new equivalent of the org.eclipse.virgo.kernel.launch.properties file - /lib/kernel is now in /plugins - /lib itself contains only jars that are set in the classpath - slight changes in the startup scripts Overall it's nothing radical. I plan to target looking into the tooling compatibility for 3.5.0.M03. Note we should also ensure some kind of mechanism that allows the tooling to support both 3.5.0 and earlier versions. That is an incremental step and would probably require some new development so I would target it for 3.5.0.RELEASE.
(In reply to comment #1) > Just wanted to check on the status on this. Do you anticipate any major > changes? Just wanted to coordinate with you in case you did as I may be doing > some significant refactorings in the next little while. Miles: one way to avoid conflicts is for you to do the changes in coordination with Borislav. That would also have the benefit of sensitising you to the tooling requirements for Virgo 3.5.0.
Please take care that we need to support different versions of the Virgo runtime with the same tooling installation, maybe with different server adaptors or so.
This bug is all that is preventing us merging the nano branch into master, something I would like to achieve as soon as possible. Martin: please could you provide a rough idea of what is involved in implementing this bug. If it's a few person days, I may argue that we should merge the nano branch early.
The branch comment made me realize that I should ensure that I'm building and testing against the current development branch for all of the repos. Is Nano the only case where there are significant changes in a branch that I should handle? > Miles: one way to avoid conflicts is for you to do the changes in coordination with Borislav. That would also have the benefit of sensitising you to the tooling requirements for Virgo 3.5.0. A limitation is that until I have committer rights, we can't really coordinate commits. I'm going to be working off of a github fork and then Leo will be committing those contributions. So the best thing to avoid a lot of later misery with merging would be for me to just avoid the areas that Borislav is working on until he finishes up w/ any majo changes, if he thinks they might be wrapped soon. Borislav, the current most relevant issues are bug 13739 bug 368580 bug 368582. From comment 2 it looks like your changes might solve some of these issues. (BTW, if you ever want to chat, send me an email and I'll send you my skype id.)
(In reply to comment #4) > Please take care that we need to support different versions of the Virgo runtime > with the same tooling installation, maybe with different server adaptors or so. Thanks for the reminder Martin, this requirement could significantly impact the bugs above as well. What is the earliest Runtime that we'll need to support? I'm till wrapping my head around the various levels of dependencies for libraries, runtimes etc. so I'm not yet sure how significantly this will affect the refactorings mentioned above.
(In reply to comment #6) > The branch comment made me realize that I should ensure that I'm building and > testing against the current development branch for all of the repos. Is Nano > the only case where there are significant changes in a branch that I should > handle? The directory layout changes apply for every Virgo distribution, so that would be Nano, Kernel, Tomcat and Jetty. > > Borislav, the current most relevant issues are bug 13739 bug 368580 bug 368582. > From comment 2 it looks like your changes might solve some of these issues. > (BTW, if you ever want to chat, send me an email and I'll send you my skype > id.) It looks like the Virgo update site that is now produced as part of the 3.5.0 milestones could help you build the IDE parts against it.
(In reply to comment #7) > What is the earliest Runtime that we'll need to support? I think it would be reasonable for the Virgo tooling to kiss SpringSource dm Server a fond farewell and support Virgo 2.0 as its earliest runtime.
(In reply to comment #9) > (In reply to comment #7) > > What is the earliest Runtime that we'll need to support? > > I think it would be reasonable for the Virgo tooling to kiss SpringSource dm > Server a fond farewell and support Virgo 2.0 as its earliest runtime. +1
(In reply to comment #5) > Martin: please could you provide a rough idea of what is involved in > implementing this bug. If it's a few person days, I may argue that we should > merge the nano branch early. Miles and Leo should take a look and answer this question and/or coordinate the work with Borislav, if he is the person merging the nano branch and maybe also making the necessary tooling changes.
The issue seems to be chronological days, not person days, right? If that's the case, I don't even have a running test environment yet; there are a number of outstanding bugs with testing greenpages and similar stuff. So until I get my head around that and making sure this stuff under testing, building consistently and that most importantly I understand the overall architecture more, I don't feel comfortable making what look to me to be significant changes in runtime organization, especially given that we have to continue to work with old structure as well. So on the outside it could be as much as 2-3 weeks until we can make these changes. Of course, if this has a significant impact on the larger picture as a whole, we'll do whatever needs to be done to help. Put another way, it seems that there are two approaches to moving forward; stabilize the current version, builds and so on and then make changes, or set the new 3.5.0 as the primary target and organize our efforts around that, back-filling as necessary to restore broken backward compatibility. My sense form above is that people are anxious not to break anything that is working now with earlier virgo runtime targets, so that argues for taking the first, more conservative, approach.
(In reply to comment #12) I'd favour the more conservative approach. We can live on a (non-master) branch for another month if necessary.
OK, great. I'll continue to build off of master for now. FWIW I'm feeling a little better about where we are today than I was yesterday, esp. as Steffen has all of the unit tests going. Thanks again, Steffen! I'm going to have a look at deployment tests as well. We'll want to consider setting up a testing environment that has at least the three runtime targets -- 2.1, circa 3.5.0 pre-reorg structure and 3.5.0 post restructure -- if we don't have that already. Or maybe it's overkill to do all of that.
(In reply to comment #14) > OK, great. I'll continue to build off of master for now. FWIW I'm feeling a > little better about where we are today than I was yesterday, esp. as Steffen > has all of the unit tests going. Thanks again, Steffen! > > I'm going to have a look at deployment tests as well. We'll want to consider > setting up a testing environment that has at least the three runtime targets -- > 2.1, circa 3.5.0 pre-reorg structure and 3.5.0 post restructure -- if we don't > have that already. Or maybe it's overkill to do all of that. The Virgo runtime project is blessed by an extensive unit and integration test suite and it's primarily that which helps us bring on newcomers and maintain project velocity. So I don't think adding those tests would be overkill, unless they are inordinately expensive to develop.
+1 for adding a Virgo 3.5 server adapter. Another +1 for removing the dm Server adapters. We could do a little bit of XML cleaning and code consolidation before diving into the 3.5 additions.
XML setup: http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?id=727d5a407cf8311a7cd753fb36e2baa86657103b Some relevant house-cleaning in bug 369993: http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?id=9f948ffd2583b0fd364d3ec1139199c9871d4aac I started to hack away at Server and ServerBehaviour to try and pull that code up into VirgoServer and VirgoServerbehaviou. It looks like the tools treat Server as API and I didn't want to be modifying too many classes, so I nixed that plan. So we have this interesting structure where all the Server* classes are derived from the original dm Server tooling, and the VirgoServer* classes are the base for Virgo 2.1, but they don't do much differently over dm Server 2.0. That's where Virgo 3.5 will probably be a little different ;-) Borislav, this code is in a state now where you can create & launch a Virgo 3.5 runtime from the servers dialog, distinct from Virgo 2.1. If you start by creating a new IServerVersionHandler or extending the ServerVirgo35Handler, you'll have to hook it up in the ServerVersionHelper class. I've already added a SERVER_VIRGO_35 constant referencing the Virgo 3.5 runtime, just drop your class in. If you find you need to extend VirgoServer, VirgoServerBehaviour, or VirgoServerRuntime, you'll have to update the runtimeType and/or serverType definition in plugin.xml to point to your new classes. Cheers!
Created attachment 210567 [details] patch for 3.5 compatibility With these changes I was able to successfully start VTS 3.5 and deploy a simple bundle on it. Oddly when I built the ide project the generated update site didn't work and I had to go in debug mode to get my stuff running. I got the feeling the update site isn't updated. Can someone give this patch a spin too?
I'll look at this today.
Hello Bobby Looks good to me. I was able to deploy the formtags sample application successfully to Virgo Server 3.5M02. Will you commit your code, or do you want me to? If you commit your changes, remember to give yourself attribution for ServerVirgo35Handler!
Thanks Leo! Pushed with commit a3958dc in the IDE repo. I'm marking this as FIXED. If we encounter any hidden problems we'll open a new bug.
Leo, isn't there actually still an open issue on this? (I'm changing to Resolved form Closed as even if this has been fixed we haven't really verified against a full suite. I'm not going to re-open as I don't think the remaining issue is actually part of this bug. IIRC, we need some changes from the non-tooling side to resolve the remaining dir name issue.)
I pushed a fix to bug 371034 late last week that adopts the latest kernel-tools jar. Glyn provided the classes we needed to maintain compatibility with Virgo 3.5 and pre-3.5 https://bugs.eclipse.org/bugs/show_bug.cgi?id=371034#c19
Cool, I missed notification on that one somehow. Probably because we shuffled it over to server.
