[JBoss JIRA] (JBIDE-13882) Allow users to easily "binary deploy"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13882?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-13882 at 6/12/13 4:34 PM:
-------------------------------------------------------------------
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Configure Markers... (and will popup some dialog that allows you to check/uncheck the skip maven build marker)
* Servers view: context menu: OpenShift->Configure Markers...
I filed the "edit markers" for existing projects in JBIDE-14845
was (Author: adietish):
we discussed where to put the UI to allow to create the "skip_maven_project" marker for existing projects. We decided that the OpenShift Explorer is not the right place since its focused on the OpenShift server, the remote part. We add the marker in the local clone/project the Explorer would therefore have to look for a matching project for a given/selected OpenShift application. We opted for a context menu in 2 places:
* Project Explorer: context menu for projects with a .openshift folder: OpenShift->Configure Markers... (and will popup some dialog that allows you to check/uncheck the skip maven build marker)
* Servers view: context menu: OpenShift->Configure Markers...
> Allow users to easily "binary deploy"
> -------------------------------------
>
> Key: JBIDE-13882
> URL: https://issues.jboss.org/browse/JBIDE-13882
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.1.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Max Rydahl Andersen
> Labels: new_and_noteworthy
> Fix For: 4.1.0.Beta2
>
> Attachments: 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.bmml, 2013-05-29 13.33.png
>
>
> We should have an option in the wizard that allows easy "binary only" deployment
> {quote}
> 'binary deployment only' option which will go disable the the build marker...but what do we do about the existing project content - just leave it in place I would say.{quote}
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14846) have option in browsersim to be always on top
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-14846:
-------------------------------------------
Summary: have option in browsersim to be always on top
Key: JBIDE-14846
URL: https://issues.jboss.org/browse/JBIDE-14846
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: browsersim
Reporter: Max Rydahl Andersen
Fix For: 4.1.0.Beta2
watching demos and using browsersim on 13" laptops having to toggle between the IDE and browsersim gets annoying.
Would be great if one could tell Browsersim to stay on top of all other windows (SWT.ON_TOP)
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14845) Allow user to edit markers
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-14845:
----------------------------------------
Summary: Allow user to edit markers
Key: JBIDE-14845
URL: https://issues.jboss.org/browse/JBIDE-14845
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.1.0.Beta2
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 4.1.0.Beta2
OpenShift allows users to set markers in order to enable/disable certain features. There are markers to use Java7, skip the maven build etc. We should allow the users to add or remove those markers.
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14844) Proper feature location for org.jboss.tools.foundation.security.linux fragment
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14844?page=com.atlassian.jira.plugi... ]
Paul Richardson commented on JBIDE-14844:
-----------------------------------------
I agree with the analysis and due to the flexibility required for the fragment, it should be independent of other plugins/fragments.
Locating it in its own feature offers the ability to filter the installability of the fragment by OS since it is only required on Linux.
Feature should be available at a lowish-level so that components, such as Teiid Designer, can simply place a dependency on the fragment's feature in its own features rather than including it, ie. the fragment feature will be part of Teiid Designer's target platform.
> Proper feature location for org.jboss.tools.foundation.security.linux fragment
> ------------------------------------------------------------------------------
>
> Key: JBIDE-14844
> URL: https://issues.jboss.org/browse/JBIDE-14844
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.0.Beta2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.CR1
>
>
> Related to TEIIDDES-1591
> There is a new plugin fragment which provides a more informative dialog for secure storage. This fragment is named org.jboss.tools.foundation.security.linux.
> No other plugin or feature should ever have a binary dependency on this plugin fragment. It may, however, be something projects like AS-Tools or Openshift decide should be installed alongside with it. Plugin dependencies on this fragment should never happen, especially because this fragment should only be installed in linux, not on windows or mac.
> Currently the fragment is included in the feature named org.jboss.tools.foundation.feature. This is not optimal for a few reasons.
> 1) The future of this feature is uncertain. What it will contain, or whether it will continue to exist in its current form, is up for big changes in the next major release.
> 2) Subsets of JBT which may wish this fragment to be present but do not have a binary dependency on this fragment will probably use a feature requirement of some type.
> 3) If this fragment continues to live in org.jboss.tools.foundation.feature, then any plugin which is also in that feature will by default be required by any higher-level feature which 'requires' this. So, for example, if AS-Tools wishes this fragment to be present and then 'requires' the foundation.feature, an addition of egit-related plugins to foundation.feature would then make AS-Tools require egit, which does not make sense.
> 4) Even if no plugins were added to o.j.t.foundation.feature, it then also means this fragment cannot be moved OUT of foundation.feature, as higher-level projects will 'require' foundation.feature and expect the fragment to be present. Moving this fragment out of its current feature would then be a breaking change, and any higher-level features expecting current behavior would then need to be changed / updated to point to this fragments new wrapper-feature. This is a breaking change. As an example of this, if AS-Tools decides to require o.j.t.foundation.feature and expects the fragment to be pulled in, moving the fragment away will result in AS-Tools not having the fragment installed. AS-Tools would then need to update their features to point to the security fragment's new home.
> 5) Having the fragment in NO feature at all would prevent the fragment from being available on update sites.
> 6) Having a higher-level plugin directly "depend on" this plugin in its manifest.mf does not make sense, especially for installations on windows or mac.
> I believe the optimal solution is to give this security fragment its own wrapper feature, so that it may be included on update sites, 'required' by projects/products like TD or AS-Tools without any danger of refactors later, and many other benefits.
> I would appreciate feedback on my thoughts here.
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14844) Proper feature location for org.jboss.tools.foundation.security.linux fragment
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14844?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-14844 at 6/12/13 2:54 PM:
-------------------------------------------------------------
we can now put plugins on update sites directly, just not in Central / Marketplace.
If you expect that dependencies on this plugin (fragment) will come from downstream JBT features or plugins, then there's nothing else we'd need to do here.
The only reason for a feature wrapper specifically for this fragment would be to empower users to install this from:
a) a category in the JBT update site(s)
b) Marketplace
c) JBoss Central
If you want it as an uncategorized item that's only visible on the update site when you uncheck 'categorized features', we can do that today w/o a feature wrapper. That way it's available for other features/plugins to depend on it under the covers, without the need for extra fluff.
Ref: https://bugs.eclipse.org/bugs/show_bug.cgi?id=378338#c21
was (Author: nickboldt):
we can now put plugins on update sites directly, just not in Central / Marketplace.
If you expect that dependencies on this plugin (fragment) will come from downstream JBT features or plugins, then there's nothing else we'd need to do here.
The only reason for a feature wrapper specifically for this fragment would be to empower users to install this from:
a) a category in the JBT update site(s)
b) Marketplace
c) JBoss Central
If you want it as an uncategorized item that's only visible on the update site when you uncheck 'categorized features', we can do that today w/o a feature wrapper. That way it's available for other features/plugins to depend on it under the covers, without the need for extra fluff.
> Proper feature location for org.jboss.tools.foundation.security.linux fragment
> ------------------------------------------------------------------------------
>
> Key: JBIDE-14844
> URL: https://issues.jboss.org/browse/JBIDE-14844
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.0.Beta2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.CR1
>
>
> Related to TEIIDDES-1591
> There is a new plugin fragment which provides a more informative dialog for secure storage. This fragment is named org.jboss.tools.foundation.security.linux.
> No other plugin or feature should ever have a binary dependency on this plugin fragment. It may, however, be something projects like AS-Tools or Openshift decide should be installed alongside with it. Plugin dependencies on this fragment should never happen, especially because this fragment should only be installed in linux, not on windows or mac.
> Currently the fragment is included in the feature named org.jboss.tools.foundation.feature. This is not optimal for a few reasons.
> 1) The future of this feature is uncertain. What it will contain, or whether it will continue to exist in its current form, is up for big changes in the next major release.
> 2) Subsets of JBT which may wish this fragment to be present but do not have a binary dependency on this fragment will probably use a feature requirement of some type.
> 3) If this fragment continues to live in org.jboss.tools.foundation.feature, then any plugin which is also in that feature will by default be required by any higher-level feature which 'requires' this. So, for example, if AS-Tools wishes this fragment to be present and then 'requires' the foundation.feature, an addition of egit-related plugins to foundation.feature would then make AS-Tools require egit, which does not make sense.
> 4) Even if no plugins were added to o.j.t.foundation.feature, it then also means this fragment cannot be moved OUT of foundation.feature, as higher-level projects will 'require' foundation.feature and expect the fragment to be present. Moving this fragment out of its current feature would then be a breaking change, and any higher-level features expecting current behavior would then need to be changed / updated to point to this fragments new wrapper-feature. This is a breaking change. As an example of this, if AS-Tools decides to require o.j.t.foundation.feature and expects the fragment to be pulled in, moving the fragment away will result in AS-Tools not having the fragment installed. AS-Tools would then need to update their features to point to the security fragment's new home.
> 5) Having the fragment in NO feature at all would prevent the fragment from being available on update sites.
> 6) Having a higher-level plugin directly "depend on" this plugin in its manifest.mf does not make sense, especially for installations on windows or mac.
> I believe the optimal solution is to give this security fragment its own wrapper feature, so that it may be included on update sites, 'required' by projects/products like TD or AS-Tools without any danger of refactors later, and many other benefits.
> I would appreciate feedback on my thoughts here.
--
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
12 years, 10 months
[JBoss JIRA] (JBIDE-14844) Proper feature location for org.jboss.tools.foundation.security.linux fragment
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14844?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-14844:
------------------------------------
we can now put plugins on update sites directly, just not in Central / Marketplace.
If you expect that dependencies on this plugin (fragment) will come from downstream JBT features or plugins, then there's nothing else we'd need to do here.
The only reason for a feature wrapper specifically for this fragment would be to empower users to install this from:
a) a category in the JBT update site(s)
b) Marketplace
c) JBoss Central
If you want it as an uncategorized item that's only visible on the update site when you uncheck 'categorized features', we can do that today w/o a feature wrapper. That way it's available for other features/plugins to depend on it under the covers, without the need for extra fluff.
> Proper feature location for org.jboss.tools.foundation.security.linux fragment
> ------------------------------------------------------------------------------
>
> Key: JBIDE-14844
> URL: https://issues.jboss.org/browse/JBIDE-14844
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: common/jst/core
> Affects Versions: 4.1.0.Beta2
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.1.0.CR1
>
>
> Related to TEIIDDES-1591
> There is a new plugin fragment which provides a more informative dialog for secure storage. This fragment is named org.jboss.tools.foundation.security.linux.
> No other plugin or feature should ever have a binary dependency on this plugin fragment. It may, however, be something projects like AS-Tools or Openshift decide should be installed alongside with it. Plugin dependencies on this fragment should never happen, especially because this fragment should only be installed in linux, not on windows or mac.
> Currently the fragment is included in the feature named org.jboss.tools.foundation.feature. This is not optimal for a few reasons.
> 1) The future of this feature is uncertain. What it will contain, or whether it will continue to exist in its current form, is up for big changes in the next major release.
> 2) Subsets of JBT which may wish this fragment to be present but do not have a binary dependency on this fragment will probably use a feature requirement of some type.
> 3) If this fragment continues to live in org.jboss.tools.foundation.feature, then any plugin which is also in that feature will by default be required by any higher-level feature which 'requires' this. So, for example, if AS-Tools wishes this fragment to be present and then 'requires' the foundation.feature, an addition of egit-related plugins to foundation.feature would then make AS-Tools require egit, which does not make sense.
> 4) Even if no plugins were added to o.j.t.foundation.feature, it then also means this fragment cannot be moved OUT of foundation.feature, as higher-level projects will 'require' foundation.feature and expect the fragment to be present. Moving this fragment out of its current feature would then be a breaking change, and any higher-level features expecting current behavior would then need to be changed / updated to point to this fragments new wrapper-feature. This is a breaking change. As an example of this, if AS-Tools decides to require o.j.t.foundation.feature and expects the fragment to be pulled in, moving the fragment away will result in AS-Tools not having the fragment installed. AS-Tools would then need to update their features to point to the security fragment's new home.
> 5) Having the fragment in NO feature at all would prevent the fragment from being available on update sites.
> 6) Having a higher-level plugin directly "depend on" this plugin in its manifest.mf does not make sense, especially for installations on windows or mac.
> I believe the optimal solution is to give this security fragment its own wrapper feature, so that it may be included on update sites, 'required' by projects/products like TD or AS-Tools without any danger of refactors later, and many other benefits.
> I would appreciate feedback on my thoughts here.
--
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
12 years, 10 months