[jbosstools-issues] [JBoss JIRA] (JBIDE-15392) Add api in server needed for source lookup

[Snjezana Peco (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801206#comment-12801206 ] 

Snjezana Peco commented on JBIDE-15392:
---------------------------------------

{quote}
1) why doesn't your requirements need the "client" folder for AS <= 6.x? We add the client folder to all of our as<=6.x providers.
{quote}

Client jars aren't included in the server classpath.

{quote}
2) I have not found any distribution which has a server/default/deploy/lib. So I'm not sure why you'd need that folder
{quote}

If so, "server/default/deploy/lib" can be removed. If you add a non-existing file/folder, nothing will happen.

{quote}
3) Why do you need jboss-modules.jar? Do you think it should also be added a dynamic web project's classpath as well? 
{quote}

All the jars that server uses need to be included into the search lookup. That isn't related either to a dynamic or any other project within Eclipse.

{quote}
> common, lib, server , server/default/lib, server/default/deploy/lib, server/default/deployers, server/default/deploy/jbossweb.sar for AS <= 6.x.

I note that you say it should use server/default/lib, but, often times, the chosen server or runtime is not in default mode. This seems a very bad assumption. Current code in as.classpath makes sure to factor in the current configuration (server/all, server/default, server/default2, etc)
{quote}

We don't know a server configuration when debugging. server/default/lib is the best assumption we can make.
We only know a server home directory so we have to recognize directories/jars based on that directory. That's why I mean this method should be added to JBossServerType which is also used in the runtime detection plugin.

{quote}
I think we should discuss any and all discrepencies between what the current classpath code does and the jars you are looking for. Is there a valid use case reason why any one jar would belong to your result set but NOT to my result set (or vice versa?) Or should the two result sets basically be identical? 
{quote}

For example, only some of the org and javax modules are included in the JBoss AS 7.1 classpath. The Source Lookup plugin requires all jars/modules (asm, org, com, javax, net ...)

{quote}
Here's a summary of the use cases as Fred and I understand them. Please correct any information that seems wrong so that I can proceed with the patch:
{quote}

JBIDE-13581 is related to the Java search lookup. The PR provides creating a specific Java project that includes all AS jars (filtered by the Source Lookup preferences) and adds them to the Java Search. 
That's all. The Java Search Lookup engine doing everything we need.
The PDE search lookup uses this technique.

                
> Add api in server needed for source lookup
> ------------------------------------------
>
>                 Key: JBIDE-15392
>                 URL: https://issues.jboss.org/browse/JBIDE-15392
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: maven, server
>            Reporter: Max Rydahl Andersen
>            Assignee: Rob Stryker
>
> As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes.
> We need to define a stable api that can be used here.
> lets outline what api is actually needed and then subjiras for the specifics.
> For me it looks like server lookup needs a few things:
> 0. know exact version of server
> 1. know the file structure of a certain server
> 2. get dir or directories that contain jar that is the "runtime"
> My guess is that #2 might just be sufficient for source code lookup.
> Any comments ? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira