[
https://issues.apache.org/jira/browse/SLING-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-6175:
-----------------------------------
Description:
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.
was:
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).
Since {{content-packages}} are quite different from {{war}} projects I would
propose to only add those natures/facets if this is explicitly
configured/requested. Otherwise 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.
> Sling IDE: Don't configure WTP natures by default for content-package projects
> ------------------------------------------------------------------------------
>
> Key: SLING-6175
> URL: https://issues.apache.org/jira/browse/SLING-6175
> Project: Sling
> Issue Type: Bug
> Components: IDE
> Affects Versions: Sling Eclipse IDE 1.1.0
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
>
> 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
(v6.3.4#6332)
