[jira] [Closed] (SLING-6175) Sling IDE: Allow to disable WTP natures/facets for content-package projects

["Robert Munteanu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu closed SLING-6175.
----------------------------------

> Sling IDE: Allow to disable WTP natures/facets for content-package projects
> ---------------------------------------------------------------------------
>
>                 Key: SLING-6175
>                 URL: https://issues.apache.org/jira/browse/SLING-6175
>             Project: Sling
>          Issue Type: Improvement
>          Components: IDE
>    Affects Versions: Sling Eclipse IDE 1.1.0
>            Reporter: Konrad Windszus
>            Assignee: Robert Munteanu
>            Priority: Major
>             Fix For: Sling Eclipse IDE 1.2.0
>
>         Attachments: SLING-6175_v01.patch
>
>
> With the configurator being added in SLING-3100 there is always WTP natures and according facets added for {{content-package}} projects. This is not always desired.
> It e.g. leads to the fact that a META-INF/MANIFEST.MF is automatically generated below the jcr_root folder (https://wiki.eclipse.org/M2E-WTP_FAQ#What_is_this_web_resources_folder.3F & http://stackoverflow.com/questions/14659891/m2e-wtp-error-path-target-m2e-wtp-web-resources-meta-inf-manifest-mf-no-such).
> Another drawback is that some validators (e.g. for javascript) are not working reliably (because one package is not an autonomous piece of code and often references code from outside the content package which is invisible to Eclipse).
> Since {{content-packages}} are quite different from {{war}} projects I would propose to only add those natures/facets if this is explicitly configured/requested. Instead we should only add the native Sling IDE natures/facets.
> The original idea behind making a {{content-package}} similar to a {{war}} was to support code assist in JSPs better (i.e. for tag libraries). This never reliably worked and therefore we should rather get rid of that approach.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)