Home » Eclipse Projects » Oomph » Create mylyn query in user .setup, episode 2
| Create mylyn query in user .setup, episode 2 [message #1392052] |
Tue, 01 July 2014 20:27  |
 cedric
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
I recall my need : setting up a bugzilla query in my user .setup file so
that this query is available in all my eclipse instances.
Step 1 : I tried to create the task WITHOUT installing Oomph tools in me
eclipse instance (see the post : Could not figure out how to create a
mylyn query task). I learnedhow to directly edit the .xmi file to add the
required xmlns to copy/past such query from oomph.setup file. My
underknowledge of EMF engine does not enable me to understand deeply how
this worked but the .setup produced this way was validated...
Step 2 : I created the query in my user.setup using the classical create
child of emf tree editor : now that the oomph tools and oomph mylyn
queries are installed, I guess that the top setup .ecore model has been
extended with new element, which I can add with the tree editor.
Step 3 : test the user.setup - I did this by pushing the "Perform the
setup task..." action (which I suppose relaunch the setup chain
eclipseInstallTasks/projectTasks/userTasks that lead to my running
eclipse)... I probably had an error in my .setup, because I saw only one
variable upon two. For my user setup file, I did not see anything in my
outline view
Step 4 : created a dummy project.setup model, which I populated with the
setup task to create my bugzilla query, along with the two variables I
needed (user and passwd). I dragged this setup on Oomph installer project
catalog, and I saw my two variables prompted for a value : conclusion the
file is OK
Step 5 : I loaded dummy project .setup model as external project in my
user .setup file, and copy pasted bugzilla query in my user. setup and
launched "Perform the setup task..." again, which lead to the following
error below :
Thank you in advance for any help
Cedric, frustrated, but still happy :)
[21:57:55] Executing startup tasks
[21:57:55] Performing setup task Mylyn Queries https://bugs.eclipse.org/
bugs/buglist.cgi?
product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial
(bugzilla)
[21:57:55] Adding bugzilla repository: https://bugs.eclipse.org/bugs/
buglist.cgi?
product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial
[21:57:55] org.eclipse.core.runtime.AssertionFailedException: assertion
failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at
org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal.synchronizeQueries
(TasksUiInternal.java:386)
at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl
$MylynHelperImpl.perform(MylynQueriesTaskImpl.java:595)
at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl.perform
(MylynQueriesTaskImpl.java:474)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.doPerformNeededSetupTasks
(SetupTaskPerformer.java:2288)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.access$0
(SetupTaskPerformer.java:2261)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil$1.run(SetupTaskPerformer.java:2985)
at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:2313)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:2979)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil.access$0(SetupTaskPerformer.java:2977)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performNeededSetupTasks
(SetupTaskPerformer.java:2252)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performTriggeredSetupTasks
(SetupTaskPerformer.java:2236)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.perform
(SetupTaskPerformer.java:2178)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$7.run
(ProgressPage.java:358)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9$1.run
(ProgressPage.java:435)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
[21:57:55] ERROR: org.eclipse.oomph.setup.core code=0 assertion failed:
org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
at
org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal.synchronizeQueries
(TasksUiInternal.java:386)
at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl
$MylynHelperImpl.perform(MylynQueriesTaskImpl.java:595)
at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl.perform
(MylynQueriesTaskImpl.java:474)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.doPerformNeededSetupTasks
(SetupTaskPerformer.java:2288)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.access$0
(SetupTaskPerformer.java:2261)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil$1.run(SetupTaskPerformer.java:2985)
at org.eclipse.core.internal.resources.Workspace.run
(Workspace.java:2313)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:2979)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
$WorkspaceUtil.access$0(SetupTaskPerformer.java:2977)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performNeededSetupTasks
(SetupTaskPerformer.java:2252)
at
org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performTriggeredSetupTasks
(SetupTaskPerformer.java:2236)
at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.perform
(SetupTaskPerformer.java:2178)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$7.run
(ProgressPage.java:358)
at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9$1.run
(ProgressPage.java:435)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
[21:57:55] Took 0 seconds.
[21:57:55] Press Finish to close the dialog.
|
|
|
| Re: Create mylyn query in user .setup, episode 2 [message #1392268 is a reply to message #1392052] |
Wed, 02 July 2014 04:34  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cedric,
Comments below.
On 01/07/2014 10:27 PM, cedric wrote:
> I recall my need : setting up a bugzilla query in my user .setup file so
> that this query is available in all my eclipse instances.
>
> Step 1 : I tried to create the task WITHOUT installing Oomph tools in me
> eclipse instance (see the post : Could not figure out how to create a
> mylyn query task). I learnedhow to directly edit the .xmi file to add the
> required xmlns to copy/past such query from oomph.setup file.
That sounds scary. Certainly we've tried hard to make the XMI human
readable, to the extent one can even reasonably argue that XML in
general ought to be human readable in the first place. E.g., use
singular element names for multi-valued features that have a plural name
in the model, and setting a very narrow line width limit so that
generally each attribute and element is on a separate line, but editing
by hand the text is still very error prone.
> My
> underknowledge of EMF engine does not enable me to understand deeply how
> this worked but the .setup produced this way was validated...
Note that in the latest version we've added a discovery catalog. So
you'll see in the new menu when creating a task, that there an
"Additional Tasks" submenu for models that are registered (in the index)
but not installed. Choosing one of those will bring up the update
wizard, install the associated bundles, and restart the IDE.
>
> Step 2 : I created the query in my user.setup using the classical create
> child of emf tree editor : now that the oomph tools and oomph mylyn
> queries are installed, I guess that the top setup .ecore model has been
> extended with new element, which I can add with the tree editor.
The models contain discovery information, so when you install an IDE,
each task's model is inspected and all bundles needed by all tasks that
will be performed in the launched IDE are installed automatically.
>
> Step 3 : test the user.setup - I did this by pushing the "Perform the
> setup task..." action (which I suppose relaunch the setup chain
> eclipseInstallTasks/projectTasks/userTasks that lead to my running
> eclipse)... I probably had an error in my .setup, because I saw only one
> variable upon two.
Not sure what this means, but note there is a "Show all variables"
checkbox, so you'll generally be prompted for very few things, once
you've been prompted once and those values have been recorded in your
user.setup.
> For my user setup file, I did not see anything in my
> outline view
No, the outline view is only meaning relative to a stream. Although I
suppose we could consider showing an outline relative to an empty stream
of an empty project...
>
> Step 4 : created a dummy project.setup model, which I populated with the
> setup task to create my bugzilla query, along with the two variables I
> needed (user and passwd). I dragged this setup on Oomph installer project
> catalog, and I saw my two variables prompted for a value : conclusion the
> file is OK
:-)
>
> Step 5 : I loaded dummy project .setup model as external project in my
> user .setup file, and copy pasted bugzilla query in my user. setup and
> launched "Perform the setup task..." again, which lead to the following
> error below :
Does your query look like this Oomph one?
<setupTask
xsi:type="mylyn:MylynQueriesTask"
repositoryURL="https://bugs.eclipse.org/bugs"
userID="${bugzilla.id}"
password="${eclipse.user.password}">
<query
summary="Bugs in ${bugzilla.version}"
url="https://bugs.eclipse.org/bugs/buglist.cgi?product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=${bugzilla.version}&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial"/>
<query
summary="Features in ${bugzilla.version}"
url="https://bugs.eclipse.org/bugs/buglist.cgi?product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=${bugzilla.version}&bug_severity=enhancement"/>
<query
summary="Resolved in ${bugzilla.version}"
url="https://bugs.eclipse.org/bugs/buglist.cgi?product=Oomph&bug_status=RESOLVED&resolution=FIXED&version=${bugzilla.version}"/>
<query
summary="Unspecified Version"
url="https://bugs.eclipse.org/bugs/buglist.cgi?product=Oomph&version=unspecified"/>
</setupTask>
Note though that I'm not happy with the current design of prompting for
a password and storing it in secure storage independant of the place
Mylyn normally stores the password. In the past weeks I had to update
my password, and the one stored by Oomph kept getting applied, with no
way for me to update it....
>
>
> Thank you in advance for any help
> Cedric, frustrated, but still happy :)
Include the XML of your task so we can try it out...
>
>
>
> [21:57:55] Executing startup tasks
> [21:57:55] Performing setup task Mylyn Queries https://bugs.eclipse.org/
> bugs/buglist.cgi?
> product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial
> (bugzilla)
> [21:57:55] Adding bugzilla repository: https://bugs.eclipse.org/bugs/
> buglist.cgi?
> product=Oomph&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial
> [21:57:55] org.eclipse.core.runtime.AssertionFailedException: assertion
> failed:
> at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
> at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
> at
> org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal.synchronizeQueries
> (TasksUiInternal.java:386)
> at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl
> $MylynHelperImpl.perform(MylynQueriesTaskImpl.java:595)
> at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl.perform
> (MylynQueriesTaskImpl.java:474)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.doPerformNeededSetupTasks
> (SetupTaskPerformer.java:2288)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.access$0
> (SetupTaskPerformer.java:2261)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil$1.run(SetupTaskPerformer.java:2985)
> at org.eclipse.core.internal.resources.Workspace.run
> (Workspace.java:2313)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:2979)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil.access$0(SetupTaskPerformer.java:2977)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performNeededSetupTasks
> (SetupTaskPerformer.java:2252)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performTriggeredSetupTasks
> (SetupTaskPerformer.java:2236)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.perform
> (SetupTaskPerformer.java:2178)
> at org.eclipse.oomph.setup.ui.wizards.ProgressPage$7.run
> (ProgressPage.java:358)
> at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9$1.run
> (ProgressPage.java:435)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> [21:57:55] ERROR: org.eclipse.oomph.setup.core code=0 assertion failed:
> org.eclipse.core.runtime.AssertionFailedException: assertion failed:
> at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
> at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96)
> at
> org.eclipse.mylyn.internal.tasks.ui.util.TasksUiInternal.synchronizeQueries
> (TasksUiInternal.java:386)
> at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl
> $MylynHelperImpl.perform(MylynQueriesTaskImpl.java:595)
> at org.eclipse.oomph.setup.mylyn.impl.MylynQueriesTaskImpl.perform
> (MylynQueriesTaskImpl.java:474)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.doPerformNeededSetupTasks
> (SetupTaskPerformer.java:2288)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.access$0
> (SetupTaskPerformer.java:2261)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil$1.run(SetupTaskPerformer.java:2985)
> at org.eclipse.core.internal.resources.Workspace.run
> (Workspace.java:2313)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil.performNeededSetupTasks(SetupTaskPerformer.java:2979)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer
> $WorkspaceUtil.access$0(SetupTaskPerformer.java:2977)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performNeededSetupTasks
> (SetupTaskPerformer.java:2252)
> at
> org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.performTriggeredSetupTasks
> (SetupTaskPerformer.java:2236)
> at org.eclipse.oomph.internal.setup.core.SetupTaskPerformer.perform
> (SetupTaskPerformer.java:2178)
> at org.eclipse.oomph.setup.ui.wizards.ProgressPage$7.run
> (ProgressPage.java:358)
> at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9$1.run
> (ProgressPage.java:435)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
>
> [21:57:55] Took 0 seconds.
> [21:57:55] Press Finish to close the dialog.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Create mylyn query in user .setup, episode 2 [message #1392783 is a reply to message #1392268] |
Wed, 02 July 2014 21:14 |
cedric
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
Hello Ed
Thank you for your answer. My answers belox
On Wed, 02 Jul 2014 06:34:56 +0200, Ed Merks wrote :
> Cedric,
>
> Comments below.
>
> On 01/07/2014 10:27 PM, cedric wrote:
>> I recall my need : setting up a bugzilla query in my user .setup file
>> so that this query is available in all my eclipse instances.
>>
>> Step 1 : I tried to create the task WITHOUT installing Oomph tools in
>> me eclipse instance (see the post : Could not figure out how to create
>> a mylyn query task). I learnedhow to directly edit the .xmi file to add
>> the required xmlns to copy/past such query from oomph.setup file.
> That sounds scary. Certainly we've tried hard to make the XMI human
> readable, to the extent one can even reasonably argue that XML in
> general ought to be human readable in the first place. E.g., use
> singular element names for multi-valued features that have a plural name
> in the model, and setting a very narrow line width limit so that
> generally each attribute and element is on a separate line, but editing
> by hand the text is still very error prone.
Ok if it is scary for you, then it is not a recommended way. I can safely
rely on my old habit to use emf tree editor :-)
> Note that in the latest version we've added a discovery catalog. So
> you'll see in the new menu when creating a task, that there an
> "Additional Tasks" submenu for models that are registered (in the index)
> but not installed.
What is this index ? Some EMF internal or a feature/element of Oomph
metamodel ?
>> Step 2 : I created the query in my user.setup using the classical
>> create child of emf tree editor : now that the oomph tools and oomph
>> mylyn queries are installed, I guess that the top setup .ecore model
>> has been extended with new element, which I can add with the tree
>> editor.
> The models contain discovery information, so when you install an IDE,
> each task's model is inspected and all bundles needed by all tasks that
> will be performed in the launched IDE are installed automatically.
Does these discovery informations enable Oomph to install both Oomph
bundles and dependant bundles (example : Oomph mylyn bundle and the
official org.eclipse.mylyn required bundles) ? It should be the best,
because it ensures that the IDE is operational, but looks trickier.
> No, the outline view is only meaning relative to a stream. Although I
> suppose we could consider showing an outline relative to an empty stream
> of an empty project...
In case of creating a user .setup, just for managing many different
eclipses (Topcased, CDT, Customs.. )
> Note though that I'm not happy with the current design of prompting for
> a password and storing it in secure storage independant of the place
> Mylyn normally stores the password. In the past weeks I had to update
> my password, and the one stored by Oomph kept getting applied, with no
> way for me to update it....
That was one of my Questions : how to manage password. At the moment I
have set "store prompted value" to false, but I am not sure that's the
good way.
> Include the XML of your task so we can try it out...
Damn I only created the setuptask, not the query!
I continue my tests :)
|
|
|
| Re: Create mylyn query in user .setup, episode 2 [message #1392974 is a reply to message #1392783] |
Thu, 03 July 2014 04:09 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cedric,
Comments below.
On 02/07/2014 11:14 PM, cedric wrote:
> Hello Ed
>
> Thank you for your answer. My answers belox
>
>
> On Wed, 02 Jul 2014 06:34:56 +0200, Ed Merks wrote :
>
>> Cedric,
>>
>> Comments below.
>>
>> On 01/07/2014 10:27 PM, cedric wrote:
>>> I recall my need : setting up a bugzilla query in my user .setup file
>>> so that this query is available in all my eclipse instances.
>>>
>>> Step 1 : I tried to create the task WITHOUT installing Oomph tools in
>>> me eclipse instance (see the post : Could not figure out how to create
>>> a mylyn query task). I learnedhow to directly edit the .xmi file to add
>>> the required xmlns to copy/past such query from oomph.setup file.
>> That sounds scary. Certainly we've tried hard to make the XMI human
>> readable, to the extent one can even reasonably argue that XML in
>> general ought to be human readable in the first place. E.g., use
>> singular element names for multi-valued features that have a plural name
>> in the model, and setting a very narrow line width limit so that
>> generally each attribute and element is on a separate line, but editing
>> by hand the text is still very error prone.
> Ok if it is scary for you, then it is not a recommended way. I can safely
> rely on my old habit to use emf tree editor :-)
>
>
>> Note that in the latest version we've added a discovery catalog. So
>> you'll see in the new menu when creating a task, that there an
>> "Additional Tasks" submenu for models that are registered (in the index)
>> but not installed.
> What is this index ? Some EMF internal or a feature/element of Oomph
> metamodel ?
The root object that's loaded from which all the information about
products and projects are loaded.
http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup
>
>>> Step 2 : I created the query in my user.setup using the classical
>>> create child of emf tree editor : now that the oomph tools and oomph
>>> mylyn queries are installed, I guess that the top setup .ecore model
>>> has been extended with new element, which I can add with the tree
>>> editor.
>> The models contain discovery information, so when you install an IDE,
>> each task's model is inspected and all bundles needed by all tasks that
>> will be performed in the launched IDE are installed automatically.
> Does these discovery informations enable Oomph to install both Oomph
> bundles and dependant bundles (example : Oomph mylyn bundle and the
> official org.eclipse.mylyn required bundles) ? It should be the best,
> because it ensures that the IDE is operational, but looks trickier.
Yes, and not so tricky. The oomph bundles themselves specify their
dependencies so we need only "discover" the annotations that specify
which additional oomph bundles need to be installed along with a p2 site
to satisfy the Mylyn dependencies it has.
>
>> No, the outline view is only meaning relative to a stream. Although I
>> suppose we could consider showing an outline relative to an empty stream
>> of an empty project...
> In case of creating a user .setup, just for managing many different
> eclipses (Topcased, CDT, Customs.. )
So you're creating tasks that are restricted to certain products or
projects? In the end, only the SetupTaskPerformer interprets the
meaning of the tasks, and it needs a SetupContext that specifies a
ProductVersion and zero or more Streams and the outline must be relative
to those context.
>
>> Note though that I'm not happy with the current design of prompting for
>> a password and storing it in secure storage independant of the place
>> Mylyn normally stores the password. In the past weeks I had to update
>> my password, and the one stored by Oomph kept getting applied, with no
>> way for me to update it....
> That was one of my Questions : how to manage password. At the moment I
> have set "store prompted value" to false, but I am not sure that's the
> good way.
As I mentioned, I don't like the way we currently manage the passwords.
Generally I think we shouldn't manage it. Each technology that needs
passwords already manages that, generally prompting when it needs one
and storing it where it expects to find it again the next time it needs it.
In the latest builds of Oomph, I've enhanced the Preferences model to
include the secure storage preferences so you if install Oomph
Preferences Management you'll see there is an Oomph -> All Preferences
preferences page with an Edit... button. This allows you to inspect all
preferences, including secure preferences, even allowing you to edit
them and save them, also including the ability to set/modify passwords
in the secure storage, or even to inspect them, if you turn on the
advanced filter in the properties view and change the Secure property to
false.
So I imagine using the paths for such secure properties in the
Preferences Task and having the variable for a prompted value being
stored to the secure storage that way.
Can you explain what specifically you need to manage passwords for? The
whole security thing associated with passwords makes me a little
paranoid, so I've been careful that I don't store clear-text secure
values in the Preferences model, but I think we'd need to be equally
paranoid about how their stored in the Setup models so that don't end up
in logs or in outline views, or anywhere else...
>
>
>> Include the XML of your task so we can try it out...
> Damn I only created the setuptask, not the query!
> I continue my tests :)
Hehehe. Looking at an existing example is always a good idea. Note that
the Setup Editor has a new feature, i.e., the tool bar button to show
the whole resource set. When editing the user.setup, you'll generally
see the resource set is full of the entire index, so from there you can
see all the existing projects and can copy their tasks.
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Password secure storage with Oomph [message #1395397 is a reply to message #1392974] |
Sun, 06 July 2014 21:46 |
cedric
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
I moved this part of my post into a new thread, since it is dedicated to
password management.
On Thu, 03 Jul 2014 06:09:38 +0200, Ed Merks wrote :
>>> Note though that I'm not happy with the current design of prompting
>>> for a password and storing it in secure storage independant of the
>>> place Mylyn normally stores the password. In the past weeks I had to
>>> update my password, and the one stored by Oomph kept getting applied,
>>> with no way for me to update it....
>> That was one of my Questions : how to manage password. At the moment I
>> have set "store prompted value" to false, but I am not sure that's the
>> good way.
> As I mentioned, I don't like the way we currently manage the passwords.
> Generally I think we shouldn't manage it. Each technology that needs
> passwords already manages that, generally prompting when it needs one
> and storing it where it expects to find it again the next time it needs
> it.
>
> In the latest builds of Oomph, I've enhanced the Preferences model to
> include the secure storage preferences so you if install Oomph
> Preferences Management you'll see there is an Oomph -> All Preferences
> preferences page with an Edit... button. This allows you to inspect all
> preferences, including secure preferences, even allowing you to edit
> them and save them, also including the ability to set/modify passwords
> in the secure storage, or even to inspect them, if you turn on the
> advanced filter in the properties view and change the Secure property to
> false.
>
> So I imagine using the paths for such secure properties in the
> Preferences Task and having the variable for a prompted value being
> stored to the secure storage that way.
I will have a look at it
>
> Can you explain what specifically you need to manage passwords for? The
> whole security thing associated with passwords makes me a little
> paranoid, so I've been careful that I don't store clear-text secure
> values in the Preferences model, but I think we'd need to be equally
> paranoid about how their stored in the Setup models so that don't end up
> in logs or in outline views, or anywhere else...
I am paranoid too regarding passwords, and to be honest, I think it is the
major reason why I issued such question.
From my point of you, I would not store passwords but rely on each bundle
secure storage. Hence, any variable tagged as "password" shall be input
with special obfuscated text input widget (with * in place of each
character).
cedric
|
|
|
Goto Forum:
Current Time: Wed Apr 24 23:48:01 GMT 2024
Powered by FUDForum. Page generated in 0.03897 seconds |
] 
Search
Help
Register
Login
Home
