Home » Eclipse Projects » Oomph » -Dosgi.requiredJavaVersion=1.7 generated multiple times in eclipse.ini and other questions/issues
| -Dosgi.requiredJavaVersion=1.7 generated multiple times in eclipse.ini and other questions/issues [message #1535197] |
Mon, 29 December 2014 15:08  |
 Joerg Reichert
Messages: 80
Registered: July 2009
Location: Leipzig |
Member |
|
|
Hi,
I've just started Oomphying my GitHub projects.
I'm documenting the steps I've done so far here:
https://github.com/joergreichert/oomph-catalogue#example-for-creating-a-new-oomph-setup
This guide includes also some usage hints for myself (but maybe useful for anyone else, too).
I think, Oomph is a really helpful tool.
Still there are some open questions / issues:
1. My Oomph setups use Java 1.8 but I get after every start an entry
-Dosgi.requiredJavaVersion=1.7
in the eclipse.ini. Where is the generation of that entry controlled? There is no config statement with .1.7 neither in the user.setup nor in the actual Oomph setup.
Is it imported by the preconfigured Platform.setup?
2. How does the setup:LinkLocationTask work? I would have expected an entry in Preferences->General/Workspace/Linked Resources.
A work around is using a PreferenceTask
<setup:PreferenceTask
key="/instance/org.eclipse.core.resources/pathvariable.local_setups"
value="${user.home}/.eclipse/org.eclipse.oomph.setup/setups"/>
and then a ResourceCreationTask to create .project file with a linkedResources entry referencing this linked location variable.
3. I tried to create TextModify task that should run after the Git clone task by setting the predecessor to the id of the Git clone task, but the modify task was still executed as last step of the IDE setup phase. Has this something to do with the scope type set fixed to "Project" for the TextModify task or with the trigger configuration "BOOTSTRAP STARTUP MANUAL"?
4. I had an issue with the Git authentication, but I found the reason - my Git user name contains an '@' sign with must be escaped to %40 when used in the https Git connection URL. But that means I cannot use ${github.user.id} there but use the (escaped) username directly. Maybe Oomph should apply the escaping directly.
5. The Repository explorer view is very useful, but I experienced several times it hanging endlessly with the "Analyzing..." job, especially for larger P2 update site like http://download.eclipse.org/releases/luna
6. You have to be aware of that the setup file imports the org.eclipse.setup file provided by Oomph itself, so there is already EMF and Luna update sites preconfigured, so that Oomph is always installed. But that means you cannot lower the version bound for EMF in your own Oomph setup.
7. For the targlets some validation would be helpful to check if the selected features can be resolved (e.g. you need to add the http://download.eclipse.org/releases/luna site, so that the planner can resolve dependencies of own selected features, http://download.eclipse.org/eclipse/updates/4.4 isn't enough here).
8. Is there a way to configure a Nexus URL in Oomph? Of course you can define a Repository List containing only the URL of your Nexus server, but then the setup file wouldn't be portable anymore.
Best regards,
Joerg
--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
|
|
|
| Re: -Dosgi.requiredJavaVersion=1.7 generated multiple times in eclipse.ini and other questions/issue [message #1535273 is a reply to message #1535197] |
Mon, 29 December 2014 16:07  |
|
Hi Joerg,
Comments below..
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 29.12.2014 um 16:08 schrieb Joerg Reichert:
> Hi,
>
> I've just started Oomphying my GitHub projects.
>
> I'm documenting the steps I've done so far here:
> https://github.com/joergreichert/oomph-catalogue#example-for-creating-a-new-oomph-setup
>
> This guide includes also some usage hints for myself (but maybe useful for anyone else, too).
Very nice!
>
> I think, Oomph is a really helpful tool.
>
> Still there are some open questions / issues:
>
> 1. My Oomph setups use Java 1.8 but I get after every start an entry
>
> -Dosgi.requiredJavaVersion=1.7
>
>
> in the eclipse.ini. Where is the generation of that entry controlled? There is no config statement with .1.7 neither
> in the user.setup nor in the actual Oomph setup.
> Is it imported by the preconfigured Platform.setup?
That entry does not come from Oomph. I think some of the plugins (IUs) you're installing have p2 touchpoint instructions
that create that entry.
In the end requiredJavaVersion=1.7 means 1.7 or later. So your actual 1.8 should be fine.
>
> 2. How does the setup:LinkLocationTask work? I would have expected an entry in Preferences->General/Workspace/Linked
> Resources.
> A work around is using a PreferenceTask
>
>
> <setup:PreferenceTask
> key="/instance/org.eclipse.core.resources/pathvariable.local_setups"
> value="${user.home}/.eclipse/org.eclipse.oomph.setup/setups"/>
>
>
> and then a ResourceCreationTask to create .project file with a linkedResources entry referencing this linked location
> variable.
The LinkLocationTask (granted, the name seems confusing now) is not related to workspace linked resources. Instead it
links an Eclipse Extension Location, i.e., a location of your disk that has features/plugins folders, into the
installation you're going to create. See
https://wiki.eclipse.org/FAQ_Can_I_install_plug-ins_outside_the_main_install_directory%3F .
>
> 3. I tried to create TextModify task that should run after the Git clone task by setting the predecessor to the id of
> the Git clone task, but the modify task was still executed as last step of the IDE setup phase. Has this something to
> do with the scope type set fixed to "Project" for the TextModify task or with the trigger configuration "BOOTSTRAP
> STARTUP MANUAL"?
"predecessor" does not mean "direct predecessor". You may want to combine it with setting the successor to the task that
should execute *after* your TextModify task.
>
> 4. I had an issue with the Git authentication, but I found the reason - my Git user name contains an '@' sign with
> must be escaped to %40 when used in the https Git connection URL. But that means I cannot use ${github.user.id} there
> but use the (escaped) username directly. Maybe Oomph should apply the escaping directly.
That sounds reasonable to me. Please submit a bugzilla.
>
> 5. The Repository explorer view is very useful, but I experienced several times it hanging endlessly with the
> "Analyzing..." job, especially for larger P2 update site like http://download.eclipse.org/releases/luna
That shouldn't happen. I've spent considerable effort to make everything asynchronous and as fast as possible with the
underlying technologies. Can you describe in more detail what "hanging" means? Are there error log entries?
Please note that the Repository Explorer can make use of Oomph's offline mode. If the repository metadata is already
cached then network access is avoided entirely.
>
> 6. You have to be aware of that the setup file imports the org.eclipse.setup file provided by Oomph itself, so there
> is already EMF and Luna update sites preconfigured, so that Oomph is always installed. But that means you cannot lower
> the version bound for EMF in your own Oomph setup.
Why do you want to use an old EMF?
>
> 7. For the targlets some validation would be helpful to check if the selected features can be resolved (e.g. you need
> to add the http://download.eclipse.org/releases/luna site, so that the planner can resolve dependencies of own
> selected features, http://download.eclipse.org/eclipse/updates/4.4 isn't enough here).
What exactly do you have in mind?
>
> 8. Is there a way to configure a Nexus URL in Oomph? Of course you can define a Repository List containing only the
> URL of your Nexus server, but then the setup file wouldn't be portable anymore.
I'm not familiar with Nexus. Can you explain in more detail what you want to achieve?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: -Dosgi.requiredJavaVersion=1.7 generated multiple times in eclipse.ini and other questions/issue [message #1535595 is a reply to message #1535273] |
Mon, 29 December 2014 20:24 |
Joerg Reichert
Messages: 80
Registered: July 2009
Location: Leipzig |
Member |
|
|
Hi Eike,
to 1.) Ok, could be an IU that adds this entry and every time you execute the Oomph installer overriding an existing IDE location (via checkbox "Overwrite" at wizard page "Confirmation"), the entry is added without checking if it is already in eclipse.ini.
to 2.) This explains the strange error messages in the log file:
org.eclipse.equinox.p2.core.ProvisionException: No repository found at file:/C:/Users/Reichert/.eclipse/org.eclipse.oomph.setup/setups/
It was tried to resolve the given path as repository instead of using it as linked location. Maybe this issue is also causing the problem with Repository Explorer, although I cannot reproduce it today.
to 3.) Actually the TextModify task was planned to be the last task of the workspace setup and it wasn't required that the task is a direct successor of the Git clone task, it only should be assured that the Git clone task is executed before the TextModify task. But what was happen is, that TextModify was executed as last task of the IDE setup and so before the Git clone task that is part of the Workspace setup phase and so no projects were cloned yet and the TextModify task wasn't able to find the file to modify. (I see the install process as two phases - IDE setup when the product is installed, a default TextModify task is used here to modify the eclipse.ini, and a second phase, when the product starts and the workspace is set up).
to 4.) https://bugs.eclipse.org/bugs/show_bug.cgi?id=456286
to 5.) Thanks for the hint with the offline mode, I cannot reproduce the issue anymore, today it's really in offline and online mode, but maybe Eclipse infrastructure was slow at the weekend. Nevertheless I've attached the log, maybe you can see something suspicious.
to 6.) I had an project with an old Xtext and wasn't sure if it would be compatible with a newer EMF version. But it seems to work with the newer version.
to 7.) I don't know how Oomph works internally but if you get the provisioning plan from the org.eclipse.equinox.p2.planner.IPlanner (for a given provisioning context and profile change request) you can get the status via org.eclipse.equinox.p2.engine.IProvisioningPlan.getStatus(). This could be realized as context menu action either of the hole setup file (resp. its root in the editor) and/or for the P2 task nodes and targlet task nodes. So you could see if all selected IUs can be resolved (or if an IU is missing a dependency that isn't resolvable in the current provisioning context) while editing the setup file.
to 8.) You can configure Nexus to support P2 repositories (http://skmit.wordpress.com/2012/04/25/set-up-a-proxy-p2-repository-with-nexus-oos/) and then you can create P2 repositories proxies (http://books.sonatype.com/nexus-book/reference/_proxy_p2_repositories.html) and even group them (http://books.sonatype.com/nexus-book/reference/_grouping_p2_repositories.html). For the respositories you can define how long they should be cached (http://books.sonatype.com/nexus-book/reference/confignx-sect-manage-repo.html), usually one day. If you then use the Nexus URL (e.g. https://yournexushost/content/repositories/releases/.meta/p2,) instead of the direct P2 update site URLs the artifacts are resolved from Nexus and depending on your caching policy Nexus only polls once a day for new versions in the remote P2 repositories avoiding unnecessary Internet traffic. (see also https://support.sonatype.com/entries/42303763-P2-Repository-FAQ)
Cheers,
Joerg
--
Need professional support for Xtext and EMF?
Go to: http://xtext.itemis.com
[Updated on: Mon, 29 December 2014 20:37] Report message to a moderator |
|
|
Goto Forum:
Current Time: Sun Dec 08 08:58:00 GMT 2024
Powered by FUDForum. Page generated in 0.02563 seconds |
] 
Search
Help
Register
Login
Home
