[JBoss JIRA] (JBDS-4493) powershell version <= 2 never returns control to installer after running the scripts
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-4493?page=com.atlassian.jira.plugin.... ]
Jan Richter closed JBDS-4493.
-----------------------------
Verified in build #332
> powershell version <= 2 never returns control to installer after running the scripts
> ------------------------------------------------------------------------------------
>
> Key: JBDS-4493
> URL: https://issues.jboss.org/browse/JBDS-4493
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 11.0.0.AM2
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Fix For: 11.1.0.AM1
>
>
> Follow up on the mail thread about detection not finishing on win 7.
> Namely methods from the Platform class that call powershell commands:
> - isVirtualizationEnabled
> - getHypervisorVersion
> - isHypervisorEnabled
> For some reason when called instead of erroring (since these commands dont work on older powershell) they don't terminate and block the detection.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBDS-4410) DevSuite 1.4 Installer indicate download size during choice selection
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-4410?page=com.atlassian.jira.plugin.... ]
Jan Richter edited comment on JBDS-4410 at 9/1/17 3:22 AM:
-----------------------------------------------------------
Since this is download size, should it even appear for bundled components as it does now? The user has already downloaded those.
[~msuman] [~crobson], thoughts?
was (Author: jrichter1):
Since this is download size, should it even appear for bundled components as it does now?
[~msuman] [~crobson], thoughts?
> DevSuite 1.4 Installer indicate download size during choice selection
> ---------------------------------------------------------------------
>
> Key: JBDS-4410
> URL: https://issues.jboss.org/browse/JBDS-4410
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Environment: DevSuite 1.4 installer, Windows 10 Pro/64
> Reporter: Robert Terzi
> Assignee: Mohit Suman
> Priority: Minor
> Fix For: 11.1.0.AM1
>
> Attachments: size-pkg.png
>
>
> During the software selection phase the DevSuite 1.4 installer should indicate the approximate size of the download. The download size is shown during actual installation progress, but by that time it's too late.
> The two use cases I see for this:
> # A minishift/CDK user that is looking to try OpenShift might not want to download and install all of JBoss. Seeing the size of it ahead of time, would avoid some shock later.
> # When trying to decide between enabling Hyper-V or installing VirtualBox, knowing the size might influence the user to just enable Hyper-V.
> Note: I think I filed a bug against a previous version that the installer provides No estimate of the required disk space in order to proceed. Doesn't look like it is still open.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBDS-4410) DevSuite 1.4 Installer indicate download size during choice selection
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-4410?page=com.atlassian.jira.plugin.... ]
Jan Richter commented on JBDS-4410:
-----------------------------------
Since this is download size, should it even appear for bundled components as it does now?
[~msuman] [~crobson], thoughts?
> DevSuite 1.4 Installer indicate download size during choice selection
> ---------------------------------------------------------------------
>
> Key: JBDS-4410
> URL: https://issues.jboss.org/browse/JBDS-4410
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Environment: DevSuite 1.4 installer, Windows 10 Pro/64
> Reporter: Robert Terzi
> Assignee: Mohit Suman
> Priority: Minor
> Fix For: 11.1.0.AM1
>
> Attachments: size-pkg.png
>
>
> During the software selection phase the DevSuite 1.4 installer should indicate the approximate size of the download. The download size is shown during actual installation progress, but by that time it's too late.
> The two use cases I see for this:
> # A minishift/CDK user that is looking to try OpenShift might not want to download and install all of JBoss. Seeing the size of it ahead of time, would avoid some shock later.
> # When trying to decide between enabling Hyper-V or installing VirtualBox, knowing the size might influence the user to just enable Hyper-V.
> Note: I think I filed a bug against a previous version that the installer provides No estimate of the required disk space in order to proceed. Doesn't look like it is still open.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBIDE-24893) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24893?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on JBIDE-24893 at 9/1/17 2:43 AM:
-----------------------------------------------------------------------
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that onemay need to configure. In practice, we only have a real-world need to configure a subset of the universe of subsystems supported)
2. We then have a so called create domain tool that swallows all of that configuration and ends up producing a single wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
- perhaps in the future - there will be such a need to create both a "wildfly domain (domain)" with N wildfly standalone coordinated domains ... that is not a use case for now.
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that onemay need to configure. In practice, we only have a real-world need to configure a subset of the universe of subsystems supported)
2. We then have a so called create domain tool that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
> Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24893
> URL: https://issues.jboss.org/browse/JBIDE-24893
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: integration-platform, server
> Affects Versions: 4.5.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Tomaz Cerar
> Priority: Optional
>
> Hi,
> I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations".
> When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder.
> I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain.
> Where in particular, the start script is created with properties like java options that matter to our deployments.
> Weblogic start plugin uses the startWeblogic.cmd in the bin folder.
> Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent.
> But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings.
> If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh.
> As it stands, every time I create a new runtime I need to open the configuration page.
> Go to the launch configurations, remove the heap settings.
> And then go to my startup domain scripts, search for the java opts that I care about, and copy them over.
> This is quite time wasteful.
> It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located.
> Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBIDE-24893) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24893?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on JBIDE-24893 at 9/1/17 2:41 AM:
-----------------------------------------------------------------------
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that onemay need to configure. In practice, we only have a real-world need to configure a subset of the universe of subsystems supported)
2. We then have a so called create domain tool that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that may need to configure)
2. We then have a so called create domain tool that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
> Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24893
> URL: https://issues.jboss.org/browse/JBIDE-24893
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: integration-platform, server
> Affects Versions: 4.5.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Tomaz Cerar
> Priority: Optional
>
> Hi,
> I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations".
> When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder.
> I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain.
> Where in particular, the start script is created with properties like java options that matter to our deployments.
> Weblogic start plugin uses the startWeblogic.cmd in the bin folder.
> Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent.
> But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings.
> If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh.
> As it stands, every time I create a new runtime I need to open the configuration page.
> Go to the launch configurations, remove the heap settings.
> And then go to my startup domain scripts, search for the java opts that I care about, and copy them over.
> This is quite time wasteful.
> It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located.
> Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBIDE-24893) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24893?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on JBIDE-24893 at 9/1/17 2:35 AM:
-----------------------------------------------------------------------
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that may need to configure)
2. We then have a so called create domain tool that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that may need to configure)
2. We then have a so called create domain python script that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
> Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24893
> URL: https://issues.jboss.org/browse/JBIDE-24893
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: integration-platform, server
> Affects Versions: 4.5.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Tomaz Cerar
> Priority: Optional
>
> Hi,
> I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations".
> When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder.
> I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain.
> Where in particular, the start script is created with properties like java options that matter to our deployments.
> Weblogic start plugin uses the startWeblogic.cmd in the bin folder.
> Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent.
> But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings.
> If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh.
> As it stands, every time I create a new runtime I need to open the configuration page.
> Go to the launch configurations, remove the heap settings.
> And then go to my startup domain scripts, search for the java opts that I care about, and copy them over.
> This is quite time wasteful.
> It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located.
> Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (JBIDE-24893) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24893?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on JBIDE-24893 at 9/1/17 2:35 AM:
-----------------------------------------------------------------------
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- mailsettings
- and so on and so on...
(conceptually - any property that is relevant to tune and JEE 7 wildfly subsystem - that may need to configure)
2. We then have a so called create domain python script that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
was (Author: nuno.godinhomatos):
Hi Rob,
Sure.
1. Step one - for each specific user project, a software developer will have config folder with
- Datasource configuration.properties
- Jms configuration.properties
- jvm settings
- main settings
- and so on and so on...
2. We then have a so called create domain python script that swallows all of that configuration and ends up producing a wildfly *standalone* domain.
- so this not a domain in the sense of a wildfly instance to coordinate the deployment to multiple managed instances. But a domain in the sense of a singular wilfly instance that will run a specific project applications(s) with its own configuration
3. This create domain script will produce this stand alone domain by combining a mix of a very simple stand alone template + all the configuration the user wants which gets injected in there during domain creation via CLI script.
4. At the end of this domain/instance creation process you end up with a
WILDFLY_HOM/user_projects/domains/myIndividualDevelopperDomainWithAllConfigurationILike
And in this instance folder you have all the normal things:
(a) log folder
(b) temp
(c) deployments
...
(zz) bin/
The bin folder is created by the create domain tool. and poduces easy to use scripts for starting, stopping etc... the instance.
5. When you are developping you do not care about this bin/ folder.
You care about the eclipse plugin working properly.
And the first problem you ecounter is that when you tell eclipse to work with a specific standalone instance, the plugin is addicted to some very constant startup settings.
6. This is where I wulld like an enhancement.
I would like to be able to stop having to visit the open launch configuraiton window every time i tell wildfly where my instance folder is located and the standalone.xml it should use.
I would much rather like that the plugin looks at the configuration folder, e.g. where you have that dynamic logging.properties, the user realm passwords and all of that, and that it looks in there and sees something like:
.eclipse_launch_configuration.properties
Or some other file format you think appropriate.
And that instead of deciding on his own what launch configurations to use by default, to use this "overriding" set of configurations.
In this way, when I developper creates a new domain/instance he would automatically see this eclipse plugin properties file tunning, and not have to waste time going to the bin/startWildfly.bat to copy the java_opts he wants to use.
I hope the explanation is not too big and confusing.
Kindest regards.
> Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24893
> URL: https://issues.jboss.org/browse/JBIDE-24893
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: integration-platform, server
> Affects Versions: 4.5.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Tomaz Cerar
> Priority: Optional
>
> Hi,
> I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations".
> When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder.
> I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain.
> Where in particular, the start script is created with properties like java options that matter to our deployments.
> Weblogic start plugin uses the startWeblogic.cmd in the bin folder.
> Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent.
> But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings.
> If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh.
> As it stands, every time I create a new runtime I need to open the configuration page.
> Go to the launch configurations, remove the heap settings.
> And then go to my startup domain scripts, search for the java opts that I care about, and copy them over.
> This is quite time wasteful.
> It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located.
> Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months