[JBoss JIRA] (JBDS-3285) Git: Easy Import
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3285?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-3285:
--------------------------------------
Component/s: upstream
> Git: Easy Import
> ----------------
>
> Key: JBDS-3285
> URL: https://issues.jboss.org/browse/JBDS-3285
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: upstream
> Affects Versions: 8.0.0.GA
> Reporter: Burr Sutter
> Labels: requirements, usability
>
> As a Java EE developer, in some cases using Git for the first time (or only familiar with command line git), I find it very difficult to clone and import a project correctly into JBDS, having the appropriate facets configured, if it has a maven pom.xml, correctly setting the build path, where it is easily deployable to a localhost EAP instance.
> The mission here is to make the Git experience much more user friendly.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBDS-3277) OpenShift v2
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBDS-3277?page=com.atlassian.jira.plugin.... ]
Marián Labuda edited comment on JBDS-3277 at 12/11/14 6:16 AM:
---------------------------------------------------------------
QE knows about it. QE is already testing OpenShift tools with OSEv2 and OpenShift Online. I think it would be enough to have JBDS-3250. If something is in JIRA it's considered to be done as one time task/bug fix/enhancement and once it is done it should be resolved and closed. I don't find it reasonable to have tracking JIRAs like this one for QE. To have such reminders it is sufficient to include it in test plan.
was (Author: mlabuda):
QE knows about it. QE is already testing OpenShift tools with OSEv2 and OpenShift Online. I think it would be enough to have JBDS-3250. If something is in JIRA, it is considers, at least that's my understanding, to complete some task/fix issue/do enhancement, and once it is done, then it is resolved and closed. To have tracking JIRAs like this one - what to do - it is appropriate to include it in test plans, not in JIRA. What do you think ;)
> OpenShift v2
> ------------
>
> Key: JBDS-3277
> URL: https://issues.jboss.org/browse/JBDS-3277
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
>
> As a OpenShift v2 end-user, I need to deploy, undeploy, add, remove, view logs, etc apps running on OpenShift v2, so I can maintain my existing applications that were previously bound to OpenShift v2.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18919) Weak performance on Software/Update tab features loading
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18919?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18919:
----------------------------------------
Do you mean that this has become slow independently of JBDS 8.0.1 build? Ie this would be a change in our p2 repositories or in ide-config.properties that would cause that, and this also affects the 8.0.0.GA release.
> Weak performance on Software/Update tab features loading
> --------------------------------------------------------
>
> Key: JBIDE-18919
> URL: https://issues.jboss.org/browse/JBIDE-18919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.2.1.CR1
> Reporter: Pavol Srna
> Assignee: Mickael Istria
> Fix For: 4.2.1.Final
>
>
> It takes about ~1 minute to load content into Software/Update tab in central.
> Some of my colleagues noticed this too.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18919) Weak performance on Software/Update tab features loading
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18919?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-18919:
---------------------------------------
I have checked 7.1.1.GA. It was pretty fast, just few seconds. Now I tried in with JBDS 8.0.0.Beta3, JBDS 8.0.0.GA and JBDS 8.0.1.CR1 and it was pretty same, takes over half a minute. Before few days / weeks it was much faster and not happening.
> Weak performance on Software/Update tab features loading
> --------------------------------------------------------
>
> Key: JBIDE-18919
> URL: https://issues.jboss.org/browse/JBIDE-18919
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central
> Affects Versions: 4.2.1.CR1
> Reporter: Pavol Srna
> Assignee: Mickael Istria
> Fix For: 4.2.1.Final
>
>
> It takes about ~1 minute to load content into Software/Update tab in central.
> Some of my colleagues noticed this too.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBDS-3277) OpenShift v2
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBDS-3277?page=com.atlassian.jira.plugin.... ]
Marián Labuda commented on JBDS-3277:
-------------------------------------
QE knows about it. QE is already testing OpenShift tools with OSEv2 and OpenShift Online. I think it would be enough to have JBDS-3250. If something is in JIRA, it is considers, at least that's my understanding, to complete some task/fix issue/do enhancement, and once it is done, then it is resolved and closed. To have tracking JIRAs like this one - what to do - it is appropriate to include it in test plans, not in JIRA. What do you think ;)
> OpenShift v2
> ------------
>
> Key: JBDS-3277
> URL: https://issues.jboss.org/browse/JBDS-3277
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
>
> As a OpenShift v2 end-user, I need to deploy, undeploy, add, remove, view logs, etc apps running on OpenShift v2, so I can maintain my existing applications that were previously bound to OpenShift v2.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 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 12/10/14 7:02 PM:
----------------------------------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{noformat}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{noformat}}
was (Author: dlmiles):
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{pre}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{pre}}
> 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: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.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.8#6338)
11 years, 5 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 12/10/14 7:03 PM:
----------------------------------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{noformat}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{noformat}
was (Author: dlmiles):
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{noformat}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{noformat}}
> 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: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.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.8#6338)
11 years, 5 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 12/10/14 6:59 PM:
----------------------------------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{pre}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{pre}}
was (Author: dlmiles):
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
}}
> 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: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.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.8#6338)
11 years, 5 months