| Upgrading 3.9 to 3.10 almost ok [message #1404083] |
Tue, 29 July 2014 13:59  |
 Nejc Gasper
Messages: 55
Registered: July 2014 |
Member |
|
|
Since there is a bug present (using tab to navigate editable tables does not submit values) and that bug is fixed in 3.10 I have decided to try and migrate.
I managed that by adding rap 2.0, scout 3.10 and orbit software sites to ScoutRAP.target, while keeping the old 3.9 on-disk repositories (needed for org.eclipse.ui imports)
I currently have these problems:
* org.eclipse.scout.rt.shared.legacy.texts.fragment_3.9.2.20131003-1323 is dependant on org.eclipse.scout.rt.shared_[3.9.2,3.10.0); I have removed this, but I think this might be causing the text services to stop working. Any suggestions?
Edit: I have to reiterate, apparently text service works for default language, but not for German in my case. I have set one of my machines to german language (the "About" dialog states german language is set). Some default menu items are properly translated (system translation?), while none of my translations from the german props file are applied. I am using TEXTS.get("x"). Might have nothing to do with the library problems after all.
Edit2: Uh, read this: https://wiki.eclipse.org/Scout/Concepts/Texts, so you have to set language manually. How would I set that programatically?
* [SWT] org.eclipse.e4.ui.css.core_0.10.100.v20130515-1857.jar is depenadant on org.apache.batik.css_[1.6.0,1.7.0). While I have been able to solve this issue by changing the run configuration to include batik 1.6 instead of 1.7, the run configuration itself is regenerated in a wrong manner every time I use the "Scout Object Properties" panel to run the project. I have manually edited <plugins> section of the .product file and added version="1.6.0.v201011041432" (I know for a fact these artifact are available) to every batik bundle. GUI will still override run config and try to use 1.7 versions by default. Any way to change this behaviour?
I have managed to fix dependancy missing regarding org.w3c.dom.events and others where needed by simply adding those to .product files. GUI will correctly fix the run configuration in this case, but not in the above case. I guess it does not consider versions at all.
* is there an easy way to check versions? or maybe a repo for missing things so I don't need to include local folders...
--
Other than this things mostly work now and the bug I had problems with is fixed, thanks to this thread: http://www.eclipse.org/forums/index.php/t/593010/ 
[Updated on: Tue, 29 July 2014 14:26] Report message to a moderator |
|
|
| Re: Upgrading 3.9 to 3.10 almost ok [message #1404091 is a reply to message #1404083] |
Tue, 29 July 2014 14:58  |
Jeremie Bresson
Messages: 1252
Registered: October 2011 |
Senior Member |
|
|
Just to be clear about 3.10. This version was'nt officially released by Eclipse. Because in February 2014 we decided to create a scout version 4.0 for the Luna release train.
The Luna release train goes like this:
Luna M1 -> Scout 3.10.0-M1
Luna M2 -> Scout 3.10.0-M2
Luna M3 -> Scout 3.10.0-M3
Luna M4 -> Scout 3.10.0-M4
Luna M5 -> Scout 3.10.0-M5
Changed the Scout version for the luna release train :
Luna M6 -> Scout 4.0.0-M6
Luna M7 -> Scout 4.0.0-M7
Luna RC1 -> Scout 4.0.0-RC1
Luna RC2 -> Scout 4.0.0-RC2
Luna RC3 -> Scout 4.0.0-RC3
Luna RC4 -> Scout 4.0.0-RC4
From the Eclipse release process point of view we dropped the scout 3.10 release.
So the Scout 3.10.0 Version is: Scout Luna-M5 + some bug fixes.
We have productive application out there with Scout 3.10.0 so you can use it.
Nejc Gasper wrote on Tue, 29 July 2014 15:59I currently have these problems:
* org.eclipse.scout.rt.shared.legacy.texts.fragment_3.9.2.20131003-1323 is dependant on org.eclipse.scout.rt.shared_[3.9.2,3.10.0); I have removed this, but I think this might be causing the text services to stop working. Any suggestions?
How old is your application, because I think that "org.eclipse.scout.rt.shared.legacy.texts.fragment" was introduced in 3.8 with the introduction of TextProviderServices.
Nejc Gasper wrote on Tue, 29 July 2014 15:59Edit2: so you have to set language manually. How would I set that programatically?
You can set the language as startup argument only if you want to change the default.
I am not sure to understand what you want to do. Are you reading the language from a user profile stored in database or LDAP?
I think this as been already discussed in the forum.
I think it has nothing to do with the scout version upgrade.
Nejc Gasper wrote on Tue, 29 July 2014 15:59[SWT] org.eclipse.e4.ui.css.core_0.10.100.v20130515-1857.jar is depenadant on org.apache.batik.css_[1.6.0,1.7.0). While I have been able to solve this issue by changing the run configuration to include batik 1.6 instead of 1.7, the run configuration itself is regenerated in a wrong manner every time I use the "Scout Object Properties" panel to run the project. I have manually edited <plugins> section of the .product file and added version="1.6.0.v201011041432" (I know for a fact these artifact are available) to every batik bundle. GUI will still override run config and try to use 1.7 versions by default. Any way to change this behaviour?
I know we did a batik update because of the underlying Eclipse Platform.
https://wiki.eclipse.org/Scout/NewAndNoteworthy/3.10#Upgrade_to_org.apache.batik_1.7_in_Scout_RT_Feature
Because of batik we have some incompatibilities with Luna (Scout 3.10 and Scout 4.0):
https://wiki.eclipse.org/Scout/Release/Luna#Eclipse_Platform
Scout 3.10 is not compatible with the Eclipse Platforms "Juno (4.2)" and "Kepler (4.3)". What is your Eclipse Runtime?
Nejc Gasper wrote on Tue, 29 July 2014 15:59
* is there an easy way to check versions? or maybe a repo for missing things so I don't need to include local folders...
Not sure to know what you are looking for.
We have different update sites where you can find the different versions.
--
To fix the whole dependencies and version problem this is how I do.
I take an eclipse IDE corresponding to the Scout RT version I want to use. I create an empty Worspace and create a new Scout Project named like the application I want to update.
After this I diff the old application and the new project.
Often you do not have a lot of code in the <your app>.ui.<technology>, so you can use all the changes comming from the new project.
I hope this helps.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.86692 seconds
] 
Search
Help
Register
Login
Home
