Home » Eclipse Projects » Oomph » Import project formatter profile
|
| Re: Import project formatter profile [message #1480953 is a reply to message #1480913] |
Thu, 20 November 2014 16:28   |
 Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Marco,
Comments below.
On 20/11/2014 4:49 PM, Marco Descher wrote:
> If I import a formatter profile, the resp. actions are presented and
> added to the user profile. So I could, I think, add the single
> configuration parameters into the setup file.
Yes. Though generally such things are best maintained as
project-specific preferences so that different projects in the same
workspace can happily co-exist. But that's hard to maintain. I've
worked on an Oomph Project Config tool that will help manage that, and
it's mostly complete, but needs more testing. The idea is that you can
identify a project has having a preference profile for some set of
preference and can define rules for the other projects to which they
should propagate. So you'd define one your Java projects having such a
profile, and then define a rule that says all other projects in the same
repository that also have Java nature should receive those properties.
A preference listener detects changes and automatically propagates them
to all the other projects...
But it needs more work and there's so little time...
>
> Is there, however, an action that allows me to directly reference the
> formatter.xml and perform the import?
No, that would need to be some special task that would do all the things
that are done when you use the button in the preference dialog...
>
> thanks!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Import project formatter profile [message #1517028 is a reply to message #1516303] |
Fri, 19 December 2014 07:47 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Eric,
Comments below.
On 18/12/2014 9:09 PM, Eric Rizzo wrote:
> Ed,
> If I understand correctly the question and Oomph's capability (I might
> not understand either), I think there is still a gap. While it's true
> that we can store the selection of a formatter profile in
> project-specific settings, I think the actual profiles are still only
> stored at the workspace level.
The key here is "I think" because goodness knows how it's really
supposed to work (or actually does work).
> At least, I've never been able to save a profile with a project and
> share it without doing so workspace-wide; it's always bothered me,
> this apparent gap in Eclipse's project-specific settings.
No, it's more of an anomaly of where and what exactly is this profile?
> Would Oomph be able to handle this be managing both the
> (workspace-stored) profiles *and* the project-specific selection of
> which profile to use?
It sort of becomes irrelevant because in the end, only the specific
settings on the project matter and if those are managed via the project
configuration tool you can change them and be sure that all projects
will have the same settings.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Import project formatter profile [message #1517406 is a reply to message #1517028] |
Fri, 19 December 2014 13:26 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote on Fri, 19 December 2014 07:47Eric,
Comments below.
On 18/12/2014 9:09 PM, Eric Rizzo wrote:
> Ed,
> If I understand correctly the question and Oomph's capability (I might
> not understand either), I think there is still a gap. While it's true
> that we can store the selection of a formatter profile in
> project-specific settings, I think the actual profiles are still only
> stored at the workspace level.
The key here is "I think" because goodness knows how it's really
supposed to work (or actually does work).
> At least, I've never been able to save a profile with a project and
> share it without doing so workspace-wide; it's always bothered me,
> this apparent gap in Eclipse's project-specific settings.
No, it's more of an anomaly of where and what exactly is this profile?
> Would Oomph be able to handle this be managing both the
> (workspace-stored) profiles *and* the project-specific selection of
> which profile to use?
It sort of becomes irrelevant because in the end, only the specific
settings on the project matter and if those are managed via the project
configuration tool you can change them and be sure that all projects
will have the same settings.
Ed,
My point is that, in the very specific case of formatter profiles, the project-specific setting isn't enough. That's because the project settings only contain a reference to a profile, not the profile itself. So if the specified profile doesn't exist in the workspace, it does no good.
Do you know if those statements are true? That's what I've observed over the years but I've never dived into the details to verify that's how it is intended to work.
|
|
|
| Re: Import project formatter profile [message #1517427 is a reply to message #1517406] |
Fri, 19 December 2014 13:45 |
|
Hi, Eric,
It's working for Papyrus. We have 284 distinct
org.eclipse.jdt.core.formatter.* settings in the
..settings/org.eclipse.jdt.core.prefs file of every source project.
http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core/.settings/org.eclipse.jdt.core.prefs
Cheers,
Christian
On 2014-12-19 13:26:39 +0000, Eric Rizzo said:
> Ed Merks wrote on Fri, 19 December 2014 07:47
>> Eric,
>>
>> Comments below.
>>
>> On 18/12/2014 9:09 PM, Eric Rizzo wrote:
>>> Ed,
>>> If I understand correctly the question and Oomph's capability (I might
>>> not understand either), I think there is still a gap. While it's true
>>> that we can store the selection of a formatter profile in
>>> project-specific settings, I think the actual profiles are still only
>>> stored at the workspace level.
>>
>> The key here is "I think" because goodness knows how it's really
>> supposed to work (or actually does work).
>>
>>> At least, I've never been able to save a profile with a project and
>>> share it without doing so workspace-wide; it's always bothered me, this
>>> apparent gap in Eclipse's project-specific settings.
>>
>> No, it's more of an anomaly of where and what exactly is this profile?
>>
>>> Would Oomph be able to handle this be managing both the
>>> (workspace-stored) profiles *and* the project-specific selection of
>>> which profile to use?
>>
>> It sort of becomes irrelevant because in the end, only the specific
>> settings on the project matter and if those are managed via the project
>> configuration tool you can change them and be sure that all projects
>> will have the same settings.
>
>
> Ed,
> My point is that, in the very specific case of formatter profiles, the
> project-specific setting isn't enough. That's because the project
> settings only contain a reference to a profile, not the profile itself.
> So if the specified profile doesn't exist in the workspace, it does no
> good.
> Do you know if those statements are true? That's what I've observed
> over the years but I've never dived into the details to verify that's
> how it is intended to work.
|
|
|
| Re: Import project formatter profile [message #1517496 is a reply to message #1517427] |
Fri, 19 December 2014 14:42 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Christian,
I was excited to see that those formatter settings are stored in the project, but it doesn't appear to work. I imported the org.eclipse.papyrus.infra.core plugin project into my workspace, noted that it refers to a formatter profile ("Papyrus") that doesn't exist in my workspace. So I edited one of the files, moved the opening curly brace to a new line which is against what the project settings show me (the project settings indicate that all opening braces are to be on the same line). But when I invoked Source > Format on my changed file, it did not apply the formatter rule to move the curly brace back. I think there are some bugs in Eclipse's handling of formatter settings when the specified profile doesn't exist. Try it on a clean workspace, without the Papyrus formatter profile, and see what you observe. Maybe I'm doing something wrong...although if so, there's some serious usability issues.
Tying this back to Oomph, I don't know if or how it can correctly manage formatter settings if these are indeed bugs in the underlying JDT functionality.
|
|
|
| Re: Import project formatter profile [message #1518889 is a reply to message #1517496] |
Sat, 20 December 2014 09:57 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Eric,
We make heavy use of this in Oomph itself, e.g., automated cleanup
actions, including formatting, whenever we save and that does work well,
even if the preference does say "unmanaged profile". This is purely
driven from project specific settings.
On 19/12/2014 3:42 PM, Eric Rizzo wrote:
> Christian,
> I was excited to see that those formatter settings are stored in the
> project, but it doesn't appear to work. I imported the
> org.eclipse.papyrus.infra.core plugin project into my workspace, noted
> that it refers to a formatter profile ("Papyrus") that doesn't exist
> in my workspace. So I edited one of the files, moved the opening curly
> brace to a new line which is against what the project settings show me
> (the project settings indicate that all opening braces are to be on
> the same line). But when I invoked Source > Format on my changed file,
> it did not apply the formatter rule to move the curly brace back. I
> think there are some bugs in Eclipse's handling of formatter settings
> when the specified profile doesn't exist. Try it on a clean workspace,
> without the Papyrus formatter profile, and see what you observe. Maybe
> I'm doing something wrong...although if so, there's some serious
> usability issues.
>
> Tying this back to Oomph, I don't know if or how it can correctly
> manage formatter settings if these are indeed bugs in the underlying
> JDT functionality.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Import project formatter profile [message #1522277 is a reply to message #1517496] |
Mon, 22 December 2014 07:57 |
|
Hi Eric,
Le 19/12/2014 15:42, Eric Rizzo a écrit :
> Christian,
> I was excited to see that those formatter settings are stored in the
> project, but it doesn't appear to work. I imported the
> org.eclipse.papyrus.infra.core plugin project into my workspace, noted
> that it refers to a formatter profile ("Papyrus") that doesn't exist in
> my workspace.
You can add a ResourceCreation task in Oomph to create the specific file
corresponding to the info needed by the workspace to "know" the profile.
For Sirius project, I added something like
Resource Creation:
* Target URL =
${workspace.location|uri}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
* Content =
cleanup_profile=_Sirius
org.eclipse.jdt.ui.cleanupprofiles=<?xml version\="1.0"... <-- Copy this
from an existig workspace
formatter_profile=_Sirius
org.eclipse.jdt.ui.formatterprofiles=<?xml version\="1.0"... <-- Copy
this from an existig workspace
The Oomph setup file for Sirius is not yet public because we are just
starting to try Oomph. But the formatter and cleanup work well.
So I edited one of the files, moved the opening curly
> brace to a new line which is against what the project settings show me
> (the project settings indicate that all opening braces are to be on the
> same line). But when I invoked Source > Format on my changed file, it
> did not apply the formatter rule to move the curly brace back. I think
> there are some bugs in Eclipse's handling of formatter settings when the
> specified profile doesn't exist. Try it on a clean workspace, without
> the Papyrus formatter profile, and see what you observe. Maybe I'm doing
> something wrong...although if so, there's some serious usability issues.
>
> Tying this back to Oomph, I don't know if or how it can correctly manage
> formatter settings if these are indeed bugs in the underlying JDT
> functionality.
Regards,
Laurent - Obeo
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
| Re: Import project formatter profile [message #1522403 is a reply to message #1522277] |
Mon, 22 December 2014 09:39 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Laurent,
That's a good idea. I hadn't yet investigated where these profiles are
saved...
On 22/12/2014 8:57 AM, Laurent Redor wrote:
> Hi Eric,
>
> Le 19/12/2014 15:42, Eric Rizzo a écrit :
>> Christian,
>> I was excited to see that those formatter settings are stored in the
>> project, but it doesn't appear to work. I imported the
>> org.eclipse.papyrus.infra.core plugin project into my workspace, noted
>> that it refers to a formatter profile ("Papyrus") that doesn't exist in
>> my workspace.
>
> You can add a ResourceCreation task in Oomph to create the specific
> file corresponding to the info needed by the workspace to "know" the
> profile. For Sirius project, I added something like
>
> Resource Creation:
> * Target URL =
> ${workspace.location|uri}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
>
> * Content =
> cleanup_profile=_Sirius
> org.eclipse.jdt.ui.cleanupprofiles=<?xml version\="1.0"... <-- Copy
> this from an existig workspace
> formatter_profile=_Sirius
> org.eclipse.jdt.ui.formatterprofiles=<?xml version\="1.0"... <-- Copy
> this from an existig workspace
>
> The Oomph setup file for Sirius is not yet public because we are just
> starting to try Oomph. But the formatter and cleanup work well.
>
> So I edited one of the files, moved the opening curly
>> brace to a new line which is against what the project settings show me
>> (the project settings indicate that all opening braces are to be on the
>> same line). But when I invoked Source > Format on my changed file, it
>> did not apply the formatter rule to move the curly brace back. I think
>> there are some bugs in Eclipse's handling of formatter settings when the
>> specified profile doesn't exist. Try it on a clean workspace, without
>> the Papyrus formatter profile, and see what you observe. Maybe I'm doing
>> something wrong...although if so, there's some serious usability issues.
>>
>> Tying this back to Oomph, I don't know if or how it can correctly manage
>> formatter settings if these are indeed bugs in the underlying JDT
>> functionality.
>
> Regards,
>
> Laurent - Obeo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Import project formatter profile [message #1522476 is a reply to message #1522277] |
Mon, 22 December 2014 10:32 |
|
I forgot to mention that I also added this
> <item
value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
key="org.eclipse.jdt.ui.importorder.loadpath"/>
> <item
value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
key="org.eclipse.jdt.ui.cleanup.loadpath"/>
> <item
value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
key="org.eclipse.jdt.ui.codeformatter.loadpath"/>
in the existing resource creation task for
${workspace.location|uri}/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml
Le 22/12/2014 08:57, Laurent Redor a écrit :
> Hi Eric,
>
> Le 19/12/2014 15:42, Eric Rizzo a écrit :
>> Christian,
>> I was excited to see that those formatter settings are stored in the
>> project, but it doesn't appear to work. I imported the
>> org.eclipse.papyrus.infra.core plugin project into my workspace, noted
>> that it refers to a formatter profile ("Papyrus") that doesn't exist in
>> my workspace.
>
> You can add a ResourceCreation task in Oomph to create the specific file
> corresponding to the info needed by the workspace to "know" the profile.
> For Sirius project, I added something like
>
> Resource Creation:
> * Target URL =
> ${workspace.location|uri}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
>
> * Content =
> cleanup_profile=_Sirius
> org.eclipse.jdt.ui.cleanupprofiles=<?xml version\="1.0"... <-- Copy this
> from an existig workspace
> formatter_profile=_Sirius
> org.eclipse.jdt.ui.formatterprofiles=<?xml version\="1.0"... <-- Copy
> this from an existig workspace
>
> The Oomph setup file for Sirius is not yet public because we are just
> starting to try Oomph. But the formatter and cleanup work well.
>
> So I edited one of the files, moved the opening curly
>> brace to a new line which is against what the project settings show me
>> (the project settings indicate that all opening braces are to be on the
>> same line). But when I invoked Source > Format on my changed file, it
>> did not apply the formatter rule to move the curly brace back. I think
>> there are some bugs in Eclipse's handling of formatter settings when the
>> specified profile doesn't exist. Try it on a clean workspace, without
>> the Papyrus formatter profile, and see what you observe. Maybe I'm doing
>> something wrong...although if so, there's some serious usability issues.
>>
>> Tying this back to Oomph, I don't know if or how it can correctly manage
>> formatter settings if these are indeed bugs in the underlying JDT
>> functionality.
>
> Regards,
>
> Laurent - Obeo
Laurent Redor - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
| |
| Re: Import project formatter profile [message #1522909 is a reply to message #1522476] |
Mon, 22 December 2014 16:14 |
|
Thanks, Laurent!
This works well for Papyrus. With your solution, I can create a vastly
different formatting profile and set it as my workspace default.
Papyrus projects are formatted using the Papyrus profile registered in
the JDT preferences, whereas other projects are obviously using my
workspace default.
The only concern that I have now, of course, is the problem of trying
to assemble a workspace that imports more than one project that all try
to create the same JDT preferences file. For example, if I import
Papyrus and, say, EMF, what kind of JDT dialog settings file will I end
up with? But I've started a new thread to discuss that question ...
Cheers,
Christian
On 2014-12-22 10:32:05 +0000, Laurent Redor said:
> I forgot to mention that I also added this
>
> > <item
> value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
> key="org.eclipse.jdt.ui.importorder.loadpath"/>
> > <item
> value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
> key="org.eclipse.jdt.ui.cleanup.loadpath"/>
> > <item
> value="${git.clone.sirius.location}/releng/org.eclipse.sirius.settings"
> key="org.eclipse.jdt.ui.codeformatter.loadpath"/>
>
> in the existing resource creation task for
> ${workspace.location|uri}/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml
>
>
> Le 22/12/2014 08:57, Laurent Redor a écrit :
>> Hi Eric,
>>
>> Le 19/12/2014 15:42, Eric Rizzo a écrit :
>>> Christian,
>>> I was excited to see that those formatter settings are stored in the
>>> project, but it doesn't appear to work. I imported the
>>> org.eclipse.papyrus.infra.core plugin project into my workspace, noted
>>> that it refers to a formatter profile ("Papyrus") that doesn't exist in
>>> my workspace.
>>
>> You can add a ResourceCreation task in Oomph to create the specific file
>> corresponding to the info needed by the workspace to "know" the profile.
>> For Sirius project, I added something like
>>
>> Resource Creation:
>> * Target URL =
>> ${workspace.location|uri}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
>>
>>
>> * Content =
>> cleanup_profile=_Sirius
>> org.eclipse.jdt.ui.cleanupprofiles=<?xml version\="1.0"... <-- Copy this
>> from an existig workspace
>> formatter_profile=_Sirius
>> org.eclipse.jdt.ui.formatterprofiles=<?xml version\="1.0"... <-- Copy
>> this from an existig workspace
>>
>> The Oomph setup file for Sirius is not yet public because we are just
>> starting to try Oomph. But the formatter and cleanup work well.
>>
>> So I edited one of the files, moved the opening curly
>>> brace to a new line which is against what the project settings show me
>>> (the project settings indicate that all opening braces are to be on the
>>> same line). But when I invoked Source > Format on my changed file, it
>>> did not apply the formatter rule to move the curly brace back. I think
>>> there are some bugs in Eclipse's handling of formatter settings when the
>>> specified profile doesn't exist. Try it on a clean workspace, without
>>> the Papyrus formatter profile, and see what you observe. Maybe I'm doing
>>> something wrong...although if so, there's some serious usability issues.
>>>
>>> Tying this back to Oomph, I don't know if or how it can correctly manage
>>> formatter settings if these are indeed bugs in the underlying JDT
>>> functionality.
>>
>> Regards,
>>
>> Laurent - Obeo
|
|
|
Goto Forum:
Current Time: Thu Dec 26 21:59:26 GMT 2024
Powered by FUDForum. Page generated in 0.04755 seconds |
] 
Search
Help
Register
Login
Home
