[JBoss JIRA] (JBDS-3384) Investigate how the terminal changes in Mars will/should affect us
by Lars Heinemann (JIRA)
[ https://issues.jboss.org/browse/JBDS-3384?page=com.atlassian.jira.plugin.... ]
Lars Heinemann commented on JBDS-3384:
--------------------------------------
thats what Paul told me, yep.
> Investigate how the terminal changes in Mars will/should affect us
> -------------------------------------------------------------------
>
> Key: JBDS-3384
> URL: https://issues.jboss.org/browse/JBDS-3384
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Task
> Components: build, forge, openshift
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 9.0.0.Beta2
>
>
> Terminal (console) support in eclipse mars is changing and we should
> make sure we adjust for it.
> Some changes this is doing at eclipse is documented at https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03448.html
> Hopefully this can be used to remove redundant/duplicate terminals and just have *one* instead of the 2.5 we got now.
> This *probably* going to affect not only packaging of JBDS (remove old terminals, add the new one), but Forge ([~koen.aers]) probably could benefit from this and Fuse ([~lhein]) should stop extending the old terminals and use the new.
> As we find what it entails we should link those issues to this jira.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBIDE-18377) Automatically add the dependencies specified in jboss-deployment-structure.xml to build path
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18377?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-18377.
---------------------------------
Resolution: Done
Hi: This should work now. Just as we read manifest.mf files to find deps, we now also can read a project's jboss-deployment-structure.xml. Support is only for the most typical usecases, such as declaring a dep on a module or module+slot combination. We do not respect the various other xml attributes such as includes / excludes, re-export of deps, etc.
> Automatically add the dependencies specified in jboss-deployment-structure.xml to build path
> --------------------------------------------------------------------------------------------
>
> Key: JBIDE-18377
> URL: https://issues.jboss.org/browse/JBIDE-18377
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Reporter: Gary Hu
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
>
> I am deploying a dynamic web project to EAP 6 using JBDS 6+. My project's build path includes the JRE System Library, EAP 6 Runtime, and Web App Libraries (the WEB-INF/lib folder). I also have a jboss-deployment-structure.xml file that defines additional module dependencies such as the following:
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="org.slf4j" />
> <module name="org.apache.log4j" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> The problem is, the slf4j and log4j modules are not included in the project's build path. While the server resolves them correctly at runtime because of the jboss-deployment-structure.xml file, Eclipse doesn't include them. So the following declaration in the Java code would result in a build error because org.apache.log4j cannot be resolved to a type:
> private static final org.apache.log4j.Logger log = org.apache.log4j.Logger.getLogger(Example.class);
> Please note that the project has configured correctly the JBoss Server Runtime which points to a valid JBoss directory, and the module dependencies are properly installed in the server.
> The dependencies specified in the jboss-deployment-structure.xml are some private modules installed at the server side but not included in the server runtime by default.
> So, is there a way to automatically add the jboss-deployment-structure module dependencies to the Eclipse build path? So far, I've been unable to find a way to do this.
> I have found a few workarounds, but none of them are ideal, and they seem to completely miss the point of module-based dependencies:
> - Customize the Default Classpath Entries for the server runtime. This is not acceptable because it must be done in each developer's workspace – and possibly per project since projects may have different, conflicting dependencies.
> - Add the libraries to WEB-INF/lib. This is not acceptable because it defeats the purpose of server modules.
> - Add the libraries to a user library for the project. This could work, but it's very inconvenient, because each developer on the team would have to add the jars to the user libraries in their workspaces.
> Here can find the discussion of exact same issue https://developer.jboss.org/thread/203309?tstart=0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBIDE-19905) Connection token and authentication scheme are not saved
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19905?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-19905:
---------------------------------------
[~adietish] the latest update to the PR should resolve the issues you mentioned above
> Connection token and authentication scheme are not saved
> --------------------------------------------------------
>
> Key: JBIDE-19905
> URL: https://issues.jboss.org/browse/JBIDE-19905
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Assignee: Jeff Cantrill
> Fix For: 4.3.0.Beta1
>
> Attachments: after-refresh-no-token.png, after-refresh-no-username-pw.png, edit-after-username-pw-provided.png, unauthorized.png
>
>
> Fix saving of a user's token and the auth scheme for a server. Might consider setting the username for a connection to user.getName() instead of user.getFullName()
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBIDE-19905) Connection token and authentication scheme are not saved
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19905?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-19905:
---------------------------------------
[~adietish] I jumped the gun on this a little and have been working on fixing the basic auth save. I will push a new commit.
> Connection token and authentication scheme are not saved
> --------------------------------------------------------
>
> Key: JBIDE-19905
> URL: https://issues.jboss.org/browse/JBIDE-19905
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Jeff Cantrill
> Assignee: Jeff Cantrill
> Fix For: 4.3.0.Beta1
>
> Attachments: after-refresh-no-token.png, after-refresh-no-username-pw.png, edit-after-username-pw-provided.png, unauthorized.png
>
>
> Fix saving of a user's token and the auth scheme for a server. Might consider setting the username for a connection to user.getName() instead of user.getFullName()
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBIDE-19446) Completion proposal computers implementations should check content type before doing other computations
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19446?page=com.atlassian.jira.plugi... ]
Alexey Kazakov closed JBIDE-19446.
----------------------------------
Resolution: Done
> Completion proposal computers implementations should check content type before doing other computations
> -------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-19446
> URL: https://issues.jboss.org/browse/JBIDE-19446
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: batch, cdi
> Affects Versions: 4.3.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Fix For: 4.3.0.Beta1
>
>
> BeansXmlCompletionProposalComputer should do computations only for beans.xml.
> BatchJobCompletionProposalComputer should do computations only for batch job xml.
> These computers are registered for different content types because Eclipse may bind any matching content type to file, including any xml content type. Implementation should start with the check if current xml file is relevant.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBIDE-19605) Avoid need for multiple javax.servlet
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19605?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-19605:
------------------------------------
We forgot to remove the IUs from the target platform, too.
https://github.com/jbosstools/jbosstools-target-platforms/pull/151
This also removes some additional IUs that appear to be no longer needed.
> Avoid need for multiple javax.servlet
> -------------------------------------
>
> Key: JBIDE-19605
> URL: https://issues.jboss.org/browse/JBIDE-19605
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: target-platform, webservices
> Affects Versions: 4.3.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Brian Fitzpatrick
> Fix For: 4.3.0.Beta1
>
> Attachments: org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElement11ChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelChangedProcessorTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessingTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs11ElementFactoryTestCase.txt, org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.Jaxrs20EndpointTestCase.txt
>
>
> We currently use 2 different version of javax.servlet bundle. We'd rather decide on sticking to 1.
> {code}
> On 04/15/2015 11:56 PM, Nick Boldt wrote:
> > Just wondering if anyone knows WHY we include javax.servlet 3.0.0 and
> > 3.1.0 in JBDS.
> > More importantly... SHOULD we be including both? Or can we just include
> > 3.1.0 and drop 3.0.0?
> I have JBDS installed from installer, which basically ran a p2 director. And I get jetty 3.0.0 and jetty 3.1.0. Than means that while resolving what to installed, p2 has to keep both versions of javax.servlet. That's definitely a sign that our dependency chain currently need both (or p2 wouldn't have installed both).
> So I've tried the ultimate test:
> $ cd jbdevstudio-9.0.0.Alpha2/studio
> $ rm plugins/javax.servlet_3.0.0*
> $ ./jbdevstudio
> And saw
> !ENTRY org.jboss.tools.ws.ui 4 0 2015-04-16 10:35:49.110
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: org.jboss.tools.ws.ui [967]
> Unresolved requirement: Import-Package: javax.servlet; version="[2.4.0,3.0.0)"
> at org.eclipse.osgi.container.Module.start(Module.java:434)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> Fun thing is that the javax.servlet_3.0.0 actually exports packages in version 2.6.0, whereas javax.servlet_3.1.0 exports them in version 3.1.0.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBDS-3373) Remove org.eclipse.jst.server.generic.jonas plugin from JBDS
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3373?page=com.atlassian.jira.plugin.... ]
Nick Boldt resolved JBDS-3373.
------------------------------
Resolution: Done
PR merged to master. Closing.
To verify, just install a build from master branch >=3310 and check that org.eclipse.jst.server.generic.jonas is not installed, nor does it cause any weird problems in error console, in WTP, etc.
> Remove org.eclipse.jst.server.generic.jonas plugin from JBDS
> ------------------------------------------------------------
>
> Key: JBDS-3373
> URL: https://issues.jboss.org/browse/JBDS-3373
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Components: updatesite
> Affects Versions: 9.0.0.Alpha1
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 9.0.0.Beta1
>
>
> com.jboss.devstudio.core.feature/feature.xml declares
> {quote}
> <import plugin="org.eclipse.jst.server.generic.jonas"/>
> {quote}
> I can't see *any* reason why we'd do that in 2015.
> [~burrsutter], [~ldimaggio], [~maxandersen] : is there any client requirement about JOnAS support?
> [~rob.stryker] does WTP require that plugin in any way?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months
[JBoss JIRA] (JBDS-3373) Remove org.eclipse.jst.server.generic.jonas plugin from JBDS
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3373?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-3373:
-----------------------------
CDW release: + (was: ?)
> Remove org.eclipse.jst.server.generic.jonas plugin from JBDS
> ------------------------------------------------------------
>
> Key: JBDS-3373
> URL: https://issues.jboss.org/browse/JBDS-3373
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Components: updatesite
> Affects Versions: 9.0.0.Alpha1
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Priority: Optional
> Fix For: 9.0.0.Beta1
>
>
> com.jboss.devstudio.core.feature/feature.xml declares
> {quote}
> <import plugin="org.eclipse.jst.server.generic.jonas"/>
> {quote}
> I can't see *any* reason why we'd do that in 2015.
> [~burrsutter], [~ldimaggio], [~maxandersen] : is there any client requirement about JOnAS support?
> [~rob.stryker] does WTP require that plugin in any way?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 3 months