[JBoss JIRA] (JBIDE-24573) Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin
by stefano canu (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24573?page=com.atlassian.jira.plugi... ]
stefano canu commented on JBIDE-24573:
--------------------------------------
Yes i'm using m2e-wtp, the workaround is to mark the ear as deployable and use jrebel, by the wai i attached a fragment of maven project.
[^pfi-test.zip]
> Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin
> ----------------------------------------------------------------------------
>
> Key: JBIDE-24573
> URL: https://issues.jboss.org/browse/JBIDE-24573
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, server, upstream
> Affects Versions: 4.4.4.Final
> Environment: windows 7 eclipse neon maven
> Reporter: stefano canu
> Assignee: Rob Stryker
> Fix For: 4.5.x
>
> Attachments: pfi-test.zip, pom.xml
>
>
> I 'm tryng to deploy to wildfly 10 an ear project (maven) composed by one war and one jar (ejb) project, but the ear deployed with eclipse wildfly connector is different form one present in the target foleder, library in web-inf lib is missing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBIDE-24236) Preferences: "automagically" use the oc that's shipped with the cdk3
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24236?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-24236:
--------------------------------
Story Points: 7
> Preferences: "automagically" use the oc that's shipped with the cdk3
> --------------------------------------------------------------------
>
> Key: JBIDE-24236
> URL: https://issues.jboss.org/browse/JBIDE-24236
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, openshift
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Labels: oc_binary, openshift_v3
> Fix For: 4.5.0.AM2
>
>
> After minishift setup-cdk, the oc command is at %USERPROFILE%\.minishift\cache\oc\v3.4.1.2
> Should our tools help streamline this process for users? I would suggest yes, but needs investigation **how** to do it.
> Another question is, do we need different 'oc' command versions for each openshift connection? Should it really be a workplace setting? Or should it be per-connection?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBIDE-24236) Preferences: "automagically" use the oc that's shipped with the cdk3
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24236?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-24236:
--------------------------------
Fix Version/s: 4.5.0.AM2
(was: 4.5.x)
> Preferences: "automagically" use the oc that's shipped with the cdk3
> --------------------------------------------------------------------
>
> Key: JBIDE-24236
> URL: https://issues.jboss.org/browse/JBIDE-24236
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, openshift
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Labels: oc_binary, openshift_v3
> Fix For: 4.5.0.AM2
>
>
> After minishift setup-cdk, the oc command is at %USERPROFILE%\.minishift\cache\oc\v3.4.1.2
> Should our tools help streamline this process for users? I would suggest yes, but needs investigation **how** to do it.
> Another question is, do we need different 'oc' command versions for each openshift connection? Should it really be a workplace setting? Or should it be per-connection?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBIDE-24519) Ensure SAP tooling is available from within JBT/devstudio
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24519?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-24519 at 6/30/17 1:42 PM:
-------------------------------------------------------------
Had another look into the sources of https://github.com/jbosstools/jbosstools-fuse-extras and the ONLY license mention I see that isn't EPL is this:
{quote}
Copyright (C) 2010 FuseSource, Corp. All rights reserved.
http://fusesource.com
The software in this package is published under the terms of the AGPL license
a copy of which has been included with this distribution in the license.txt file.{quote} -- https://github.com/jbosstools/jbosstools-fuse-extras/blob/master/pom.xml#...
But there's no license.txt file, and the LICENSE file is a copy of the EPL, not a *GPL license.
So... can someone ( [~lhein] ? [~aurelien.pupier] ?) point me to where the non-EPL sources actually are, or where non-EPL stuff is downloaded? If not, I'll update this root pom to replace Copyright FuseSource with the usual Red Hat copyright 2017, with FuseSource as an initial contributor.
was (Author: nickboldt):
Had another look into the sources of https://github.com/jbosstools/jbosstools-fuse-extras and the ONLY license mention I see that isn't EPL is this:
{quote}
Copyright (C) 2010 FuseSource, Corp. All rights reserved.
http://fusesource.com
The software in this package is published under the terms of the AGPL license
a copy of which has been included with this distribution in the license.txt file.{quote} -- https://github.com/jbosstools/jbosstools-fuse-extras/blob/master/pom.xml#...
So... can someone ( [~lhein] ? [~aurelien.pupier] ?) point me to where the non-EPL sources actually are, or where non-EPL stuff is downloaded? If not, I'll update this root pom to replace Copyright FuseSource with the usual Red Hat copyright 2017, with FuseSource as an initial contributor.
> Ensure SAP tooling is available from within JBT/devstudio
> ----------------------------------------------------------
>
> Key: JBIDE-24519
> URL: https://issues.jboss.org/browse/JBIDE-24519
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: build, fuse-tooling
> Affects Versions: 4.5.0.AM1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.5.0.AM2
>
>
> Need to make sure that whatever magic happens today in the IS for supporting the SAP Tooling gets migrated to JBT/devstudio.
> {quote}
> Github = https://github.com/jbosstools/jbosstools-fuse-extras
> CCI PR Build: https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/FuseToo...
> CCI Update SIte Build: https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/FuseToo...
> Update Site CI: http://download.jboss.org/jbosstools/oxygen/snapshots/builds/jbosstools-f...
> SAP data layer: http://fuse-sap.mw.lab.eng.bos.redhat.com/repositories/fuse-sap-data-laye...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBIDE-9356) NLS.bind vs MessageFormat.format
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9356?page=com.atlassian.jira.plugin... ]
Rob Stryker updated JBIDE-9356:
-------------------------------
Fix Version/s: 4.5.0.AM1
> NLS.bind vs MessageFormat.format
> --------------------------------
>
> Key: JBIDE-9356
> URL: https://issues.jboss.org/browse/JBIDE-9356
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cleanup
> Affects Versions: 3.3.0.M3
> Reporter: Rob Stryker
> Assignee: Jeff MAURY
> Fix For: 4.0.x, 4.5.0.AM1
>
>
> A substantial number of classes use NLS.bind(Messages.SomeString, name) to bind message strings. Another subset of the classes use MessageFormat.format(etc).
> I believe NLS.bind() is the correct solution which works properly with eclipse osgi and all that jazz. Should this be standardized? Is it confusing to be using two interchangable APIs?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (JBIDE-9356) NLS.bind vs MessageFormat.format
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9356?page=com.atlassian.jira.plugin... ]
Rob Stryker closed JBIDE-9356.
------------------------------
Resolution: Done
This was more of an informative jira. No work was done. Closing.
> NLS.bind vs MessageFormat.format
> --------------------------------
>
> Key: JBIDE-9356
> URL: https://issues.jboss.org/browse/JBIDE-9356
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cleanup
> Affects Versions: 3.3.0.M3
> Reporter: Rob Stryker
> Assignee: Jeff MAURY
> Fix For: 4.5.0.AM1, 4.0.x
>
>
> A substantial number of classes use NLS.bind(Messages.SomeString, name) to bind message strings. Another subset of the classes use MessageFormat.format(etc).
> I believe NLS.bind() is the correct solution which works properly with eclipse osgi and all that jazz. Should this be standardized? Is it confusing to be using two interchangable APIs?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months