[JBoss JIRA] (JBIDE-14844) Proper feature location for org.jboss.tools.foundation.security.linux fragment
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14844?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-14844:
--------------------------------
Description:
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.
was:
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 require this plugin 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.
> 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 Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14844?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-14844:
--------------------------------
Description:
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 require this plugin 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.
was:
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.
Currently the fragment is included in the org.jboss.tools.foundation.feature 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 require this plugin 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.
> 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 require this plugin 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 Rob Stryker (JIRA)
Rob Stryker created JBIDE-14844:
-----------------------------------
Summary: 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.
Currently the fragment is included in the org.jboss.tools.foundation.feature 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 require this plugin 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-13788) mvn package
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13788?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-13788:
--------------------------------
Fix Version/s: 4.1.x
(was: 4.1.0.Beta2)
> mvn package
> -----------
>
> Key: JBIDE-13788
> URL: https://issues.jboss.org/browse/JBIDE-13788
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 4.1.x
>
> Attachments: 2013-03-13_1738.png, Screen Shot 2013-03-13 at 5.39.10 PM.png
>
>
> In Java EE land you tend to use "mvn package", but that is not listed in the menu, nor is it visible in the dialog. Not too mention, having the Maven commands under the Run menu option, instead of the Maven menu is counter-intuitive.
--
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-13698) Build As submenu
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13698?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-13698:
--------------------------------
Fix Version/s: 4.1.x
(was: 4.1.0.Beta2)
> Build As submenu
> ----------------
>
> Key: JBIDE-13698
> URL: https://issues.jboss.org/browse/JBIDE-13698
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 4.1.x
>
> Attachments: Screen Shot 2013-03-01 at 8.03.01 AM.png
>
>
> This is a usability issue - new users to Eclipse struggle with finding the "mvn package" or "mvn install" options hidden in the JBDS menu. Having those under Run As is simply not intuitive. Not too mention that there is a Maven menu, that does not have the build options - which would have been slightly more intuitive.
> One proposal is a Build As menu - where I can issue my various mvn commands.
> Screenshot of current JBDS 7 context menu (right-click) on a project attached.
--
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] (JBDS-2552) JBDS70_0412: [Commit] (Dev) (P2) Offline - Examples/Archetypes - UI candy
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-2552?page=com.atlassian.jira.plugin.... ]
Fred Bricon updated JBDS-2552:
------------------------------
Attachment: examples-offline-support.png
New Offline support preference page to enable offline mode and generate script command to go offline :
!examples-offline-support.png!
> JBDS70_0412: [Commit] (Dev) (P2) Offline - Examples/Archetypes - UI candy
> -------------------------------------------------------------------------
>
> Key: JBDS-2552
> URL: https://issues.jboss.org/browse/JBDS-2552
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Requirements
> Reporter: Jiri Pallich
> Assignee: Fred Bricon
> Fix For: 7.0.0.Beta2
>
> Attachments: examples-offline-support.png
>
>
> Once the script described in JBDS-2543 exists, provide a "make available offline" button in Central to make offline provisioning easier.
--
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