[JBoss JIRA] (JBIDE-13904) Minor UI issues in "Configure Repositories" wizard
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13904?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-13904:
---------------------------------------
{quote}
* The repo viewer should have a horizontal scroller, since adding the (inactive) suffix can make a pretty long label and you have to resize the whole dialog to be able to read the labels
{quote}
I have added a horizontal and vertical scrollbar.
{quote}
* Edit a repo, switching the profile activation status : it reorders the repositories/profiles in settings.xml.
{quote}
Earlier, the wizard was editing a repository by removing/creating a new one.
Now, it edits elements in an existing repository.
> Minor UI issues in "Configure Repositories" wizard
> --------------------------------------------------
>
> Key: JBIDE-13904
> URL: https://issues.jboss.org/browse/JBIDE-13904
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Affects Versions: 4.1.0.Alpha2
> Reporter: Fred Bricon
> Assignee: Snjezana Peco
> Priority: Minor
> Labels: uxp
> Fix For: 4.2.1.Final, 4.3.0.Alpha1
>
>
> In the Window > Preferences > JBoss Tools > JBoss Maven Integration > Configure Maven Repositories...
> * The repo viewer should have a horizontal scroller, since adding the (inactive) suffix can make a pretty long label and you have to resize the whole dialog to be able to read the labels
> * Edit a repo, switching the profile activation status : it reorders the repositories/profiles in settings.xml.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18862:
---------------------------------------------
I can confirm I end up with a .dodeploy file after having removed the module while the server was stopped.
We should definitely remove the .dodeploy either when we remove or before we start publishing, maybe in both cases just to be safe.
> 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
>
> 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, 4 months
[JBoss JIRA] (JBIDE-18860) Publish to Wildfly AS does not update files
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18860?page=com.atlassian.jira.plugi... ]
Darryl Miles updated JBIDE-18860:
---------------------------------
Attachment: org.example.jbide18860_v2.tar.gz
Version 2
corrected Java1.7 usage in WAR/EJB projects.
corrected XSD location in web.xml
> Publish to Wildfly AS does not update files
> -------------------------------------------
>
> Key: JBIDE-18860
> URL: https://issues.jboss.org/browse/JBIDE-18860
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Environment: Windows7 64bit, JDK8u25
> Reporter: Darryl Miles
> Priority: Critical
> Fix For: 4.2.1.Final, 4.2.2.Final, 4.3.0.Alpha1
>
> Attachments: org.example.jbide18860.tar.gz, org.example.jbide18860_v2.tar.gz
>
>
> I think I am on JBIDE product 4.2.0.Final (but features show as 3.6.0.Final and Plugins as 3.0.0.Final-v20141016)
> I have an EAR Maven project published to Wildfly 8.x.
> there is a file in the project TOPLEVEL/src/main/application/META-INF/jboss-deployment-structure.xml
> If this file is edited and saved, and I perform publish operation on server. The change is never made to the deployments directory.
> If I manually delete the file from the deployments direcory, then perform clean operation and publish operation and full publish operation, the file is never re-crearted.
> The only way is to REMOVE EAR module from server, clean server, stop server, ADD EAR module to server, publish server, start server.
> Now the file is updated.
> I also note that I have a number of workspace JPA/JAR projects that should be included in the EAR in the lib/* folder but they are never copied there.
> I have found a copy in a folder like workspace\.metadata\.plugins\org.jboss.ide.eclipse.as.core\WildFly_8.1.0.Final\tempRemoteDeploy\ in here are the JARs I expected to find in the server runtime folder wildfly-8.1.0.Final\standalone\deployments\com.company.ear\lib\**
> The timestamps on the files in this directory appear to be up-to-date at each publish event.
> As a workaround I use "Make As Deployable" on the file workspace\com.company.ear\target\com.company.ear-1.2.3-SNAPSHOW.ear and I use a manual Maven build profile to create this file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18700) EAP 6.x Configuration shows Servlet 3.1 as a valid choice
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18700?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-18700.
---------------------------------
You didn't answer my question about the java facet, but as I said, I'm fine with how this works in JBDS 8.0.1.CR1 so I'm closing this JIRA ;)
> EAP 6.x Configuration shows Servlet 3.1 as a valid choice
> ---------------------------------------------------------
>
> Key: JBIDE-18700
> URL: https://issues.jboss.org/browse/JBIDE-18700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Fix For: 4.2.1.CR1, 4.3.0.Alpha1
>
>
> - Create a new EAP 6.3 server
> - Create a new Dynamic Web Project
> - Select the EAP runtime
> => An error is shown : "Dynamic Web Module 3.1 requires Java 1.7 or newer."
> !http://content.screencast.com/users/fbricon/folders/Jing/media/ee20c272-5761-40ab-8fe8-1004533501c7/00000025.png!
> The EAP 6 Default Configuration should -have the Java 1.7 Facet set by default- not have the Web 3.1 option, which is part of JavaEE 7.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3208:
-------------------------------------------
"I don't understand why we need that." -> to avoid install/updates to fail when nightly/snapshots are being updated.
"cleaning up stuff isn't high priority" -> I wish that was true. But we need to be aware how much we use. And whatever schema we setup the clean up needs to be easy to automate. Try to avoid being magical/complex since we don't have full access to the filesystem/shell to do too much logic.
I have same concerns as you about the updates/mars pointing to updates/mars/stable. Why do we need updates/mars or updates/9.0 to point at any p2 content ?
And yes, would be best /snapshots actually points to the current related central, tp, etc. so it mimicks what staging, development and stable will contain.
> reorg/refactor directories for consistency across JBT/JBDS
> ----------------------------------------------------------
>
> Key: JBDS-3208
> URL: https://issues.jboss.org/browse/JBDS-3208
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.0.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 9.0.0.Alpha1
>
>
> Be it resolved - we should reorg directories for consistency across JBT/JBDS:
> {code}
> download.jboss.org
> <earlyaccess,updates,discovery>/mars
> /snapshots [replace nightly]
> /staging [rename content for QE, moves to development when approved]
> /development
> /stable (updates/mars/stable is a pointer back into updates/mars)
> drop /integration (not used)
> builds/<jobname>/<buildid>
> builds/<jobname>/composite*.xml for last 2 builds
> targetplatforms/<type>/<version>
> {code}
> and
> {code}
> devstudio.redhat.com
> <earlyaccess,updates,discovery>/9.0
> /snapshots
> /staging
> /development
> /stable (updates/9.0/stable is a pointer back into updates/9.0)
> builds/<jobname>/<buildid>
> builds/<jobname>/composite*.xml for last 2 builds
> targetplatforms/<type>/<version>
> {code}
> Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112
> This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970.
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2....
> [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18700) EAP 6.x Configuration shows Servlet 3.1 as a valid choice
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18700?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-18700.
---------------------------------
Resolution: Done
I think it is necessary to keep as an option for now; just cannot be the default option.
> EAP 6.x Configuration shows Servlet 3.1 as a valid choice
> ---------------------------------------------------------
>
> Key: JBIDE-18700
> URL: https://issues.jboss.org/browse/JBIDE-18700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Fix For: 4.2.1.CR1, 4.3.0.Alpha1
>
>
> - Create a new EAP 6.3 server
> - Create a new Dynamic Web Project
> - Select the EAP runtime
> => An error is shown : "Dynamic Web Module 3.1 requires Java 1.7 or newer."
> !http://content.screencast.com/users/fbricon/folders/Jing/media/ee20c272-5761-40ab-8fe8-1004533501c7/00000025.png!
> The EAP 6 Default Configuration should -have the Java 1.7 Facet set by default- not have the Web 3.1 option, which is part of JavaEE 7.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 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/2/14 7:15 AM:
---------------------------------------------------------------
The AS does emit a info/warning in server.log when an unexpected marker file exists.
So if *.dodeploy is the only marker file that JBIDE creates.
Then please take this bug to ensure that:
* When REMOVING a module from runtime the *.dodeploy file is also deleted by Eclipse. [This is a bug right now]
* Before ADDING a module to runtime, but before writing the EAR (or other module implementation data), ensure the *.dodeploy file is deleted by Eclipse. You delete it to prevent cross-over from a failed REMOVE and to ensure Eclipse doesn't process it. [Difficult to see/test as publishing can be too quick]
* Before ADDING a module to runtime, but before writing the EAR (or other module imlementation data), ensure the target toplevel name/file is deleted. This would be "rm -rf ear-0.0.1-SNAPSHOT.ear.ear\" (as an exploded directory) or maybe "rm -f foobar-0.0.1-SNAPSHOT.ear" (as a file). This is to ensure a CLEAN is done before anything is written. Maybe server tooling already does this? [This appears to be the case in a quick test with exploded directory deployment, but would be nice to have it confirmed by someone understanding the Eclipse/JBIDE code]
* (only) After ADDING a module to runtime, then you can re-create the *.dodeploy at the point when everything is publish ok. [Sure I can see a file there each time I expect it]
was (Author: dlmiles):
The AS does emit a info/warning in server.log when an unexpected marker file exists.
So if *.dodeploy is the only marker file that JBIDE creates.
Then please take this bug to ensure that:
* When REMOVING a module from runtime the *.dodeploy file is also deleted by Eclipse.
* Before ADDING a module to runtime, but before writing the EAR (or other module implementation data), ensure the *.dodeploy file is deleted by Eclipse. You delete it to prevent cross-over from a failed REMOVE and to ensure Eclipse doesn't process it.
* Before ADDING a module to runtime, but before writing the EAR (or other module imlementation data), ensure the target toplevel name/file is deleted. This would be "rm -rf ear-0.0.1-SNAPSHOT.ear.ear\" (as an exploded directory) or maybe "rm -f foobar-0.0.1-SNAPSHOT.ear" (as a file). This is to ensure a CLEAN is done before anything is written. Maybe server tooling already does this?
* (only) After ADDING a module to runtime, then you can re-create the *.dodeploy at the point when everything is publish ok.
> 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
>
> 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, 4 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 commented on JBIDE-18862:
--------------------------------------
The AS does emit a info/warning in server.log when an unexpected marker file exists.
So if *.dodeploy is the only marker file that JBIDE creates.
Then please take this bug to ensure that:
* When REMOVING a module from runtime the *.dodeploy file is also deleted by Eclipse.
* Before ADDING a module to runtime, but before writing the EAR (or other module implementation data), ensure the *.dodeploy file is deleted by Eclipse. You delete it to prevent cross-over from a failed REMOVE and to ensure Eclipse doesn't process it.
* Before ADDING a module to runtime, but before writing the EAR (or other module imlementation data), ensure the target toplevel name/file is deleted. This would be "rm -rf ear-0.0.1-SNAPSHOT.ear.ear\" (as an exploded directory) or maybe "rm -f foobar-0.0.1-SNAPSHOT.ear" (as a file). This is to ensure a CLEAN is done before anything is written. Maybe server tooling already does this?
* (only) After ADDING a module to runtime, then you can re-create the *.dodeploy at the point when everything is publish ok.
> 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
>
> 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, 4 months
[JBoss JIRA] (JBIDE-18860) Publish to Wildfly AS does not update files
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18860?page=com.atlassian.jira.plugi... ]
Darryl Miles commented on JBIDE-18860:
--------------------------------------
>> If there is anyway you can give us a copy of the project or even just its dot-metadata (files/folders starting with ., i.e. .project, .classpath, .settings/* etc.) so we could try and reproduce.
I am using this test case org.example.jbide18860.* Maven project suite to re-create the issues I face in a more complex scenario and report one issue at a time as I find it.
I shall make the TAR.GZ file more complex as time goes by (multiple JARs/EJBs/WARs etc... as necessary to cause the problem(s) I see).
But I must knock down each issue as I re-create it. The journey towards the more complex environment should help find the areas of problems to maybe allow auto-detection/fix by JBIDE tooling by using error markers on the project explaining what is badly configured or wrong with the setup.
> Publish to Wildfly AS does not update files
> -------------------------------------------
>
> Key: JBIDE-18860
> URL: https://issues.jboss.org/browse/JBIDE-18860
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Environment: Windows7 64bit, JDK8u25
> Reporter: Darryl Miles
> Priority: Critical
> Fix For: 4.2.1.Final, 4.2.2.Final, 4.3.0.Alpha1
>
> Attachments: org.example.jbide18860.tar.gz
>
>
> I think I am on JBIDE product 4.2.0.Final (but features show as 3.6.0.Final and Plugins as 3.0.0.Final-v20141016)
> I have an EAR Maven project published to Wildfly 8.x.
> there is a file in the project TOPLEVEL/src/main/application/META-INF/jboss-deployment-structure.xml
> If this file is edited and saved, and I perform publish operation on server. The change is never made to the deployments directory.
> If I manually delete the file from the deployments direcory, then perform clean operation and publish operation and full publish operation, the file is never re-crearted.
> The only way is to REMOVE EAR module from server, clean server, stop server, ADD EAR module to server, publish server, start server.
> Now the file is updated.
> I also note that I have a number of workspace JPA/JAR projects that should be included in the EAR in the lib/* folder but they are never copied there.
> I have found a copy in a folder like workspace\.metadata\.plugins\org.jboss.ide.eclipse.as.core\WildFly_8.1.0.Final\tempRemoteDeploy\ in here are the JARs I expected to find in the server runtime folder wildfly-8.1.0.Final\standalone\deployments\com.company.ear\lib\**
> The timestamps on the files in this directory appear to be up-to-date at each publish event.
> As a workaround I use "Make As Deployable" on the file workspace\com.company.ear\target\com.company.ear-1.2.3-SNAPSHOW.ear and I use a manual Maven build profile to create this file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18860) Publish to Wildfly AS does not update files
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18860?page=com.atlassian.jira.plugi... ]
Darryl Miles commented on JBIDE-18860:
--------------------------------------
>> How is the server setup ? is it a remote server or local running one ?
Local, nothing special (unzip, install modules, edit standalone*xml with some things should should not affect any of this test)
>> Anything in the error log ?
There is in Eclipse concerning Maven -> Update Project, spitting an error (due to bug in SPRING-IDE), I reported a while ago https://jira.spring.io/browse/IDE-1357
>> Anything in the server log ?
If you work through the previous comment you should see a deployment failure for the EAR, due to the EJB and WAR file missing from publish operation.
>> Do you have m2e-wtp installed ? if no, then maven projects won't work properly for sure - they will only be configured for the java part, not the "web" (wtp) part and that is known to cause the issue above ;/
Yes with m2e-wtp installed.
> Publish to Wildfly AS does not update files
> -------------------------------------------
>
> Key: JBIDE-18860
> URL: https://issues.jboss.org/browse/JBIDE-18860
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Environment: Windows7 64bit, JDK8u25
> Reporter: Darryl Miles
> Priority: Critical
> Fix For: 4.2.1.Final, 4.2.2.Final, 4.3.0.Alpha1
>
> Attachments: org.example.jbide18860.tar.gz
>
>
> I think I am on JBIDE product 4.2.0.Final (but features show as 3.6.0.Final and Plugins as 3.0.0.Final-v20141016)
> I have an EAR Maven project published to Wildfly 8.x.
> there is a file in the project TOPLEVEL/src/main/application/META-INF/jboss-deployment-structure.xml
> If this file is edited and saved, and I perform publish operation on server. The change is never made to the deployments directory.
> If I manually delete the file from the deployments direcory, then perform clean operation and publish operation and full publish operation, the file is never re-crearted.
> The only way is to REMOVE EAR module from server, clean server, stop server, ADD EAR module to server, publish server, start server.
> Now the file is updated.
> I also note that I have a number of workspace JPA/JAR projects that should be included in the EAR in the lib/* folder but they are never copied there.
> I have found a copy in a folder like workspace\.metadata\.plugins\org.jboss.ide.eclipse.as.core\WildFly_8.1.0.Final\tempRemoteDeploy\ in here are the JARs I expected to find in the server runtime folder wildfly-8.1.0.Final\standalone\deployments\com.company.ear\lib\**
> The timestamps on the files in this directory appear to be up-to-date at each publish event.
> As a workaround I use "Make As Deployable" on the file workspace\com.company.ear\target\com.company.ear-1.2.3-SNAPSHOW.ear and I use a manual Maven build profile to create this file.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months