[JBoss JIRA] (JBIDE-19757) Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19757?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19757:
-----------------------------------
Priority: Minor (was: Major)
> Use jbosstools aggregate site instead of special webtools-site for WTP's AS server discovery
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-19757
> URL: https://issues.jboss.org/browse/JBIDE-19757
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, server
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> With https://bugs.eclipse.org/bugs/show_bug.cgi?id=434185 , WTP Server Discovery mechanism was granted a new strategy which allows to rely on regular p2 metadata instead of a site.xml.
> Support for this was already merged in server ( https://github.com/jbosstools/jbosstools-server/commit/2d3cc63a9b67753ad9... )
> In order to save an artifact to manage (the webtools p2 repository), we could use this mechanism and consider contributing directly the main JBT URL to webtools discovery.
> However, server discovery also keeps older strategies and since we produce invalid site.xml files, this is currently failing
> {code}
> !ENTRY org.eclipse.equinox.p2.updatesite 2 0 2015-05-04 09:40:58.088
> !MESSAGE Error parsing feature stream. The unique identifier or the version is null or empty for the State: "Category": unique identifier="minimal-json" version="null".
> {code}
> because we are lines specifying bundle but no version in the site.xml.
> [~nickboldt] What are those site.xml useful for? Could we get rid of them?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19798) include buildinfo.json files inside source zips
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19798?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-19798:
-----------------------------------
Priority: Minor (was: Major)
> include buildinfo.json files inside source zips
> -----------------------------------------------
>
> Key: JBIDE-19798
> URL: https://issues.jboss.org/browse/JBIDE-19798
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> Max asked: {quote}
> [W]here are the build-info.json files to provide the info you were initially partially encoding into the file names ?
> {quote}
> I replied: {quote}
> Adding json files will take more work as they're produced in a different mojo (GenerateRepositoryFacadeMojo.java, not FetchSourcesFromManifests.java), and I'm a bit hesitant to have one mojo depend on another.
> Do you want that the FetchSourcesFromManifests will also FetchJSONFromUpstreamLatestBuildsFolders (hoping that no respins have happened between the start of the aggregate job and the time when the fetch starts) ? Or should I just include target/fullSite/all/repo/buildinfo.json into target/fullSite/all/jbosstools-src.zip ?
> It's already included in the generated update site + update site zip, so I don't have a problem adding it to the src.zip too... except for the fact that we'll have cross-mojo dependencies. This will mean that the aggregate builds (JBT & JBDS) will depend on BOTH mojos, and that they can only be configured to run in a SPECIFIC order. Is that acceptable?
> {quote}
> (From JBIDE-19756)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-18772) Include publish steps in pom files
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18772?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18772:
----------------------------------------
Progress for that was reported by error to JBIDE-13835 . The following change was applied: https://github.com/jbosstools/jbosstools-build-sites/pull/185
{quote}
PR for aggregates was merged, so we can now deploy them with "mvn deploy" (it will invoke rsync.sh under the hood). Next step is to update CI jobs for JBoss Tools.
Nick Boldt pointed that since discovery sites are currently shared between JBT and JBDS ( JBIDE-19025 ), we'll still need some extra steps to deploy central and EA snapshots.
{quote}
> Include publish steps in pom files
> ----------------------------------
>
> Key: JBIDE-18772
> URL: https://issues.jboss.org/browse/JBIDE-18772
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Max Rydahl Andersen
> Assignee: Mickael Istria
> Priority: Critical
> Fix For: 4.3.0.Beta1
>
> Attachments: jbds-publish-to-snapshots.png
>
>
> instead of relying to publish.sh being on master, we should use a versioned publish.sh (or maybe even mojo) that the build then uses.
> suggestion:
> publish.sh (or mojo) gets released to our maven repo, use it in the pom.xml to perform publishing.
> What this helps with is:
> a) can do changes to publish mechanism without affecting every past builds.
> b) more movable build system
> c) isolated testing possible
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19795) Bower support
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19795?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-19795:
----------------------------------------
What's the benefit of working on a fully parallel implementation ? If Ilya plans to contribute his work to JSDT, it will make that JSDT will have 2 Bower supports? I don't think that's desirable for users and for us.
> Bower support
> -------------
>
> Key: JBIDE-19795
> URL: https://issues.jboss.org/browse/JBIDE-19795
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Affects Versions: 4.3.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Final
>
>
> Need to have initial [Bower|http://bower.io/] tools support:
> *The gist*
> Bower tooling should initially support several bower API commands :
> |Command||Description|
> | *bower init* |creates a *bower.json* file|
> |*bower install <package>*|installs packages to *bower_components* folder|
> |*bower uninstall <package>*|uninstalls a package locally from *bower_components* directory|
> |*bower update* |updates installed packages to their newest version according to *bower.json*|
> Basically, the main idea of the implementation is the following:
> Eclipse plugin that will execute *external* bower commands - implementation will fall back on *native* bower installation via *ILaunchConfiguration*
> Native bower tools must be preinstalled
> *The main questions & proposals:*
> 1. https://github.com/jbosstools/jbosstools-playground is probably the best place for initial implementation of bower stuff (infrastructure / build etc.)
> 2. UI. should it be ILaunchShortcuts ("bower init" / "bower update" etc.) + launch configuration enabled for projects with js nature?
> 3. Implementation details:
> - the way of detecting bower? Should user point to it's installation dir and this location will be used for IExternalToolConstants.ATTR_LOCATION (windows case: *\user\AppData\Roaming\npm\node_modules\bower* )
> - if bower was not detected / installed - "Error message with a link to the bower website with installation details depending on the platform"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19720) NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19720?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich edited comment on JBIDE-19720 at 5/18/15 7:16 PM:
------------------------------------------------------------------------
I have added an issue to Eclipse bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=467532 to know what they think of this situation.
was (Author: scabanovich):
I have added an issue to Eclipse bugzilla is created https://bugs.eclipse.org/bugs/show_bug.cgi?id=467532 to know what they think of this situation.
> NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19720
> URL: https://issues.jboss.org/browse/JBIDE-19720
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.2.3.Final
> Environment: Mac OS X 10.10.3, java full version "1.8.0_25-b17"
> Reporter: Valentin Baciu
> Assignee: Viacheslav Kabanovich
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> at org.jboss.tools.common.model.util.EclipseResourceUtil.updateLibs(EclipseResourceUtil.java:535)
> at org.jboss.tools.common.model.util.EclipseResourceUtil.createObjectForResource(EclipseResourceUtil.java:417)
> at org.jboss.tools.jst.web.model.helpers.InnerModelHelper.createXModel(InnerModelHelper.java:40)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.init(ClassPathMonitor.java:60)
> at org.jboss.tools.jst.web.kb.internal.KbProject.setProject(KbProject.java:202)
> at org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
> at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
> at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:71)
> at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:38)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.getKbProjects(ClassPathMonitor.java:193)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:143)
> at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolve(KbProject.java:330)
> at org.jboss.tools.jst.web.kb.internal.KbProject.addKbProject(KbProject.java:216)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:154)
> at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> at org.jboss.tools.jst.web.kb.internal.KbBuilder.build(KbBuilder.java:100)
> at org.jboss.tools.jst.web.kb.KbProjectFactory$1KbBuilderEx.build(KbProjectFactory.java:107)
> at org.jboss.tools.jst.web.kb.KbProjectFactory$1.run(KbProjectFactory.java:122)
> at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
> Another code path:
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> at org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.update(AbstractClassPathMonitor.java:73)
> at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.build(JSF2ProjectBuilder.java:116)
> at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.<init>(JSF2ProjectBuilder.java:71)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.load(JSF2Project.java:261)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolveStorage(JSF2Project.java:247)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolve(JSF2Project.java:254)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project$1.run(JSF2Project.java:172)
> at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19795) Bower support
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19795?page=com.atlassian.jira.plugi... ]
Victor Rubezhny edited comment on JBIDE-19795 at 5/18/15 4:51 PM:
------------------------------------------------------------------
[~mickael_istria] No, it's the fully parallel implementation. Exactly as Ilya said.
was (Author: vrubezhny):
[~mickael_istria] No, it's the fully parallel implementation. As Ilya said.
> Bower support
> -------------
>
> Key: JBIDE-19795
> URL: https://issues.jboss.org/browse/JBIDE-19795
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Affects Versions: 4.3.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Final
>
>
> Need to have initial [Bower|http://bower.io/] tools support:
> *The gist*
> Bower tooling should initially support several bower API commands :
> |Command||Description|
> | *bower init* |creates a *bower.json* file|
> |*bower install <package>*|installs packages to *bower_components* folder|
> |*bower uninstall <package>*|uninstalls a package locally from *bower_components* directory|
> |*bower update* |updates installed packages to their newest version according to *bower.json*|
> Basically, the main idea of the implementation is the following:
> Eclipse plugin that will execute *external* bower commands - implementation will fall back on *native* bower installation via *ILaunchConfiguration*
> Native bower tools must be preinstalled
> *The main questions & proposals:*
> 1. https://github.com/jbosstools/jbosstools-playground is probably the best place for initial implementation of bower stuff (infrastructure / build etc.)
> 2. UI. should it be ILaunchShortcuts ("bower init" / "bower update" etc.) + launch configuration enabled for projects with js nature?
> 3. Implementation details:
> - the way of detecting bower? Should user point to it's installation dir and this location will be used for IExternalToolConstants.ATTR_LOCATION (windows case: *\user\AppData\Roaming\npm\node_modules\bower* )
> - if bower was not detected / installed - "Error message with a link to the bower website with installation details depending on the platform"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19795) Bower support
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19795?page=com.atlassian.jira.plugi... ]
Victor Rubezhny commented on JBIDE-19795:
-----------------------------------------
[~mickael_istria] No, it's the fully parallel implementation. As Ilya said.
> Bower support
> -------------
>
> Key: JBIDE-19795
> URL: https://issues.jboss.org/browse/JBIDE-19795
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Affects Versions: 4.3.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Final
>
>
> Need to have initial [Bower|http://bower.io/] tools support:
> *The gist*
> Bower tooling should initially support several bower API commands :
> |Command||Description|
> | *bower init* |creates a *bower.json* file|
> |*bower install <package>*|installs packages to *bower_components* folder|
> |*bower uninstall <package>*|uninstalls a package locally from *bower_components* directory|
> |*bower update* |updates installed packages to their newest version according to *bower.json*|
> Basically, the main idea of the implementation is the following:
> Eclipse plugin that will execute *external* bower commands - implementation will fall back on *native* bower installation via *ILaunchConfiguration*
> Native bower tools must be preinstalled
> *The main questions & proposals:*
> 1. https://github.com/jbosstools/jbosstools-playground is probably the best place for initial implementation of bower stuff (infrastructure / build etc.)
> 2. UI. should it be ILaunchShortcuts ("bower init" / "bower update" etc.) + launch configuration enabled for projects with js nature?
> 3. Implementation details:
> - the way of detecting bower? Should user point to it's installation dir and this location will be used for IExternalToolConstants.ATTR_LOCATION (windows case: *\user\AppData\Roaming\npm\node_modules\bower* )
> - if bower was not detected / installed - "Error message with a link to the bower website with installation details depending on the platform"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19795) Bower support
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19795?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-19795:
-------------------------------------
[~mickael_istria] well, frankly I'm not very into bower support that is in JSDT right now. So, it does not rely on it. I'm planning to do all implementation including UI from scratch and contribute it in the short run (this week) to playground and in the long run (JBDS 9) to Tools. Probably, when this support will be mature enough it will be contributed to JSDT but for now we are targeting only Tools / Studio 9
> Bower support
> -------------
>
> Key: JBIDE-19795
> URL: https://issues.jboss.org/browse/JBIDE-19795
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Affects Versions: 4.3.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.3.0.Final
>
>
> Need to have initial [Bower|http://bower.io/] tools support:
> *The gist*
> Bower tooling should initially support several bower API commands :
> |Command||Description|
> | *bower init* |creates a *bower.json* file|
> |*bower install <package>*|installs packages to *bower_components* folder|
> |*bower uninstall <package>*|uninstalls a package locally from *bower_components* directory|
> |*bower update* |updates installed packages to their newest version according to *bower.json*|
> Basically, the main idea of the implementation is the following:
> Eclipse plugin that will execute *external* bower commands - implementation will fall back on *native* bower installation via *ILaunchConfiguration*
> Native bower tools must be preinstalled
> *The main questions & proposals:*
> 1. https://github.com/jbosstools/jbosstools-playground is probably the best place for initial implementation of bower stuff (infrastructure / build etc.)
> 2. UI. should it be ILaunchShortcuts ("bower init" / "bower update" etc.) + launch configuration enabled for projects with js nature?
> 3. Implementation details:
> - the way of detecting bower? Should user point to it's installation dir and this location will be used for IExternalToolConstants.ATTR_LOCATION (windows case: *\user\AppData\Roaming\npm\node_modules\bower* )
> - if bower was not detected / installed - "Error message with a link to the bower website with installation details depending on the platform"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JBIDE-19720) NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19720?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-19720:
-----------------------------------------------
I have added an issue to Eclipse bugzilla is created https://bugs.eclipse.org/bugs/show_bug.cgi?id=467532 to know what they think of this situation.
> NPE in org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath
> ----------------------------------------------------------------------------
>
> Key: JBIDE-19720
> URL: https://issues.jboss.org/browse/JBIDE-19720
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.2.3.Final
> Environment: Mac OS X 10.10.3, java full version "1.8.0_25-b17"
> Reporter: Valentin Baciu
> Assignee: Viacheslav Kabanovich
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
>
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> at org.jboss.tools.common.model.util.EclipseResourceUtil.updateLibs(EclipseResourceUtil.java:535)
> at org.jboss.tools.common.model.util.EclipseResourceUtil.createObjectForResource(EclipseResourceUtil.java:417)
> at org.jboss.tools.jst.web.model.helpers.InnerModelHelper.createXModel(InnerModelHelper.java:40)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.init(ClassPathMonitor.java:60)
> at org.jboss.tools.jst.web.kb.internal.KbProject.setProject(KbProject.java:202)
> at org.eclipse.core.internal.resources.NatureManager.createNature(NatureManager.java:234)
> at org.eclipse.core.internal.resources.Project.getNature(Project.java:448)
> at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:71)
> at org.jboss.tools.jst.web.kb.KbProjectFactory.getKbProject(KbProjectFactory.java:38)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.getKbProjects(ClassPathMonitor.java:193)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:143)
> at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolve(KbProject.java:330)
> at org.jboss.tools.jst.web.kb.internal.KbProject.addKbProject(KbProject.java:216)
> at org.jboss.tools.jst.web.kb.internal.scanner.ClassPathMonitor.validateProjectDependencies(ClassPathMonitor.java:154)
> at org.jboss.tools.jst.web.kb.internal.KbProject.load(KbProject.java:347)
> at org.jboss.tools.jst.web.kb.internal.KbProject.resolveStorage(KbProject.java:315)
> at org.jboss.tools.jst.web.kb.internal.KbBuilder.build(KbBuilder.java:100)
> at org.jboss.tools.jst.web.kb.KbProjectFactory$1KbBuilderEx.build(KbProjectFactory.java:107)
> at org.jboss.tools.jst.web.kb.KbProjectFactory$1.run(KbProjectFactory.java:122)
> at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
> Another code path:
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.common.model.util.EclipseResourceUtil.getJREClassPath(EclipseResourceUtil.java:711)
> at org.jboss.tools.common.model.filesystems.impl.Libs.getNewPaths(Libs.java:141)
> at org.jboss.tools.common.model.filesystems.impl.Libs.update(Libs.java:108)
> at org.jboss.tools.common.model.project.ext.AbstractClassPathMonitor.update(AbstractClassPathMonitor.java:73)
> at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.build(JSF2ProjectBuilder.java:116)
> at org.jboss.tools.jsf.jsf2.bean.build.JSF2ProjectBuilder.<init>(JSF2ProjectBuilder.java:71)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.load(JSF2Project.java:261)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolveStorage(JSF2Project.java:247)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project.resolve(JSF2Project.java:254)
> at org.jboss.tools.jsf.jsf2.bean.model.impl.JSF2Project$1.run(JSF2Project.java:172)
> at org.jboss.tools.common.model.XJob.runInWorkspace(XJob.java:192)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months