[JBoss JIRA] (JBDS-3324) Create a new installer for JBDS 8.1.0
by Len DiMaggio (JIRA)
Len DiMaggio created JBDS-3324:
----------------------------------
Summary: Create a new installer for JBDS 8.1.0
Key: JBDS-3324
URL: https://issues.jboss.org/browse/JBDS-3324
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Task
Components: installer
Affects Versions: 8.1.0.GA
Reporter: Len DiMaggio
Assignee: Len DiMaggio
Priority: Blocker
Fix For: 8.1.0.GA
The 8.1.0 release will include an updated installer for JBDS - for EAP and standalone. The installers must be tested and released along with the update sites.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBDS-3324) Test the new installer for JBDS 8.1.0
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-3324?page=com.atlassian.jira.plugin.... ]
Len DiMaggio updated JBDS-3324:
-------------------------------
Summary: Test the new installer for JBDS 8.1.0 (was: Create a new installer for JBDS 8.1.0)
> Test the new installer for JBDS 8.1.0
> -------------------------------------
>
> Key: JBDS-3324
> URL: https://issues.jboss.org/browse/JBDS-3324
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Task
> Components: installer
> Affects Versions: 8.1.0.GA
> Reporter: Len DiMaggio
> Assignee: Len DiMaggio
> Priority: Blocker
> Fix For: 8.1.0.GA
>
>
> The 8.1.0 release will include an updated installer for JBDS - for EAP and standalone. The installers must be tested and released along with the update sites.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:41 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until the *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
Please stop thinking about "Full Publish" and "Incremental Publish" this is implementation detail and a problem for Eclipse to manage. A previous Full Publish action that was not terminally completed, is not yet over! So until the AS does the deploy the Full Publish is still in progress. If Eclipse happens to be able to get in an extra Incremental Publish (as eclipse wants to call it) then great. But that original Full Publish is not yet compelted at the time, so it is still an outstanding action on the AS.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
Please stop thinking about "Full Publish" and "Incremental Publish" this is implementation detail and a problem for Eclipse to manage. A previous Full Publish action that was not terminally completed, is not yet over! So until the AS does the deploy the Full Publish is still in progress. If Eclipse happens to be able to get in an extra Incremental Publish (as eclipse wants to call it) then great. But that original Full Publish is not yet compelted at the time, so it is still an outstanding action on the AS.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:40 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
Please stop thinking about "Full Publish" and "Incremental Publish" this is implementation detail and a problem for Eclipse to manage. A previous Full Publish action that was not terminally completed, is not yet over! So until the AS does the deploy the Full Publish is still in progress. If Eclipse happens to be able to get in an extra Incremental Publish (as eclipse wants to call it) then great. But that original Full Publish is not yet compelted at the time, so it is still an outstanding action on the AS.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:37 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform AS state changes.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:36 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
There is no notion of Full Publish or Incremental Publish by the AS. This is an Eclipse'ism.
There is only the notion that Eclipse has a target runtime state and the AS has a current runtime state and actions to perform.
So yes... an incremental publish that removed the marker before making any file change operations should at the end of the operation review the situation. It will find that Eclipse has a target runtime state to achieve of "AS Started" and "Module Started". It will note that Eclipse is already started and take no action. It will note that the Eclipse module is not started (or is configured to be restarted on change) and signal the appropriate action to the AS to bring the runtime AS state into alignment with the Eclipse target runtime state. Once Eclipse target state matches the AS runtime actual state, we have achieved a nominal state.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:31 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying market has been removed by the AS.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months