[JBoss JIRA] (JBIDE-12860) JAX-RS validation problems are not linked
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12860?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-12860:
---------------------------------------
Hi [~rrabara] !
Actually, you'll keep having warnings if your sample application has a java-based Application and if its is defined in the web.xml.
The bug to fix in this issue was that if you define 2 applications, you'll have warnings on both of them, but if you remove one of them, the warning on the remaining one should disappear as well. This was not the case when the issue was opened: the remaining application still had an error.
I hope this clarifies the work done on this issue.
Best regards,
Xavier
> JAX-RS validation problems are not linked
> -----------------------------------------
>
> Key: JBIDE-12860
> URL: https://issues.jboss.org/browse/JBIDE-12860
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.0.0.Beta1
> Reporter: Jaroslav Jankovič
> Assignee: Max Rydahl Andersen
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
>
> This case now fails:
> STEP: Create jaxrs problem with Application problem (Multiple application definition - one class extending Application and one application servlet definition in web.xml)
> STEP: comment servlet definition in web.xml
> ASSERT: problem marker in web.xml disappears
> ASSERT: problem marker in application class disappears
> FAIL: problem marker in application class doesn't disappear, because problem markers are not linked now -> project has to be built to correctly remove both problem markers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBIDE-13208) Allow custom 'standalone' mode directory in AS7 server plugin
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13208?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-13208:
-------------------------------------
> why not make all the various system properties base, configuration etc. part of the API instead of just adding it for base dir
Currently none of my code use that, and so I do not make it part of the API. I refuse to make things part of the API (which I then have to maintain) unless I have a use-case of how people will use it. I'm not sure what you mean about "cleaning up the code", because as far as I can tell, all single references to 'standalone' have been removed now except in methods where it makes sense (such as defaults etc).
> Allow custom 'standalone' mode directory in AS7 server plugin
> -------------------------------------------------------------
>
> Key: JBIDE-13208
> URL: https://issues.jboss.org/browse/JBIDE-13208
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Mac OS-X 10.8.2, Java 6, Java 7, JBoss AS 7.x, JBoss EAP 6, JBDS 5.0.1
> Reporter: Duncan Doyle
> Assignee: Rob Stryker
> Labels: f2f2012, new_and_noteworthy
> Fix For: 4.2.0.Alpha1
>
>
> As with JBoss EAP5.x, I have the habit of working in a copy of a 'profile' directory. With JBoss AS7/EAP6 I therefore work in copies of 'standalone' and 'domain' (depending on the operational mode). When I start AS/EAP, I reference the correct server directory with the 'jboss.server.base.dir' or 'jboss.domain.base.dir' system property. This allows me, among other things, to run multiple AS/EAP instances from a single JBoss AS/EAP installation.
> It seems that the JBDS AS7 plugin only allows me to reference the default 'standalone' directory. I'm not able to select a different directory in the 'JBoss Runtime' configuration screen. I would propose to add the possibility to start a JBoss AS7/EAP6 instance from a different directory than 'standalone'.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBDS-2797) .ini upgrade issue for 7.0.1 users
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2797?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-2797:
----------------------------------
We could release an installer for JBDS 7.0.1... would that solve this problem?
Or better yet, stop having 2 .app launchers?
> .ini upgrade issue for 7.0.1 users
> ----------------------------------
>
> Key: JBDS-2797
> URL: https://issues.jboss.org/browse/JBDS-2797
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build, installer
> Affects Versions: 7.0.1.GA
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Priority: Critical
>
> User noticed issues with 7.0.0 to 7.0.1 updates at https://community.jboss.org/message/841477#841477 that needs investigation.
> The post is about osx but I don't think this is limited to this OS, just that OSX has a different java behavior.
> Worrisome issues are:
> development url used in GA update:
> -Djboss.discovery.directory.url=https://devstudio.jboss.com/updates/7.0-development/devstudio-directory.xml
> startup/launcher directories are hardcoded in the .ini file:
> -startup
> ../../../plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
> --launcher.library
> ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.200.v20130807-1835
> Have these been forgotten/set wrong in the update or is this some specific update path that is failing ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15482 at 10/14/13 10:20 PM:
---------------------------------------------------------------
{quote}use of a composite site is bad and causing issues{quote}
The reason it's "bad" is that contents of {code}staging/<job_name>{code} and {code}staging.previous/<job_name>{code} are *subject to change* w/ each new published build. So the statically coded composite site [1] contents may point to different content unexpectedly DURING a build, resulting in unresolved IUs, because one or more of the child sites suddenly contain a DIFFERENT version of the component's build.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
The solution, as outlined in this JIRA (before all the comments above began), is to avoid that issue by instead generating the composite*.xml files to point to the ACTUAL build folders, eg., in this example [2]. So instead of having URLs with "staging.previous" you'd have
{code}
staging/CI/jbosstools-server_master_JBDS2741/2013-09-24_14-46-04-B13/all/repo
staging/CI/jbosstools-server_master_JBDS2741/2013-09-25_14-46-04-B14/all/repo
staging/CI/jbosstools-server_master_JBDS2741/2013-09-25_18-46-04-B15/all/repo
...
{code}
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
If this is not the solution you want, please suggest an alternative approach. I'm coding based on the spec that [~dgolovin] put forth, documented above in the *Description* field.
{quote}that is why I suggested doing that as part of those other issues.{quote}
Which other issues?
was (Author: nickboldt):
{quote}use of a composite site is bad and causing issues{quote}
The reason it's "bad" is that contents of {code}staging/<job_name>{code} {code}staging.previous/<job_name>{code} are subject to change w/ each new published build. So the statically coded composite site [1] contents may point to different content unexpectedly DURING a build, resulting in unresolved IUs.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
The solution, as outlined in this JIRA (before all the comments began), is to avoid that issue by instead generating the composite*.xml files to point to the ACTUAL build folders, eg., in this example [2].
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
If this is not the solution you want, please suggest an alternative approach. I'm coding based on the spec that [~dgolovin] put forth, documented above in the *Description* field.
{quote}that is why I suggested doing that as part of those other issues.{quote}
Which other issues?
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15482:
------------------------------------
{quote}use of a composite site is bad and causing issues{quote}
The reason it's "bad" is that contents of {code}staging/<job_name>{code} {code}staging.previous/<job_name>{code} are subject to change w/ each new published build. So the statically coded composite site [1] contents may point to different content unexpectedly DURING a build, resulting in unresolved IUs.
[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun...
The solution, as outlined in this JIRA (before all the comments began), is to avoid that issue by instead generating the composite*.xml files to point to the ACTUAL build folders, eg., in this example [2].
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1....
If this is not the solution you want, please suggest an alternative approach. I'm coding based on the spec that [~dgolovin] put forth, documented above in the *Description* field.
{quote}that is why I suggested doing that as part of those other issues.{quote}
Which other issues?
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBDS-2797) .ini upgrade issue for 7.0.1 users
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-2797?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-2797:
-------------------------------------
JBoss Developer Studio.app is created in CreateLinkPanel class.
> .ini upgrade issue for 7.0.1 users
> ----------------------------------
>
> Key: JBDS-2797
> URL: https://issues.jboss.org/browse/JBDS-2797
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build, installer
> Affects Versions: 7.0.1.GA
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Priority: Critical
>
> User noticed issues with 7.0.0 to 7.0.1 updates at https://community.jboss.org/message/841477#841477 that needs investigation.
> The post is about osx but I don't think this is limited to this OS, just that OSX has a different java behavior.
> Worrisome issues are:
> development url used in GA update:
> -Djboss.discovery.directory.url=https://devstudio.jboss.com/updates/7.0-development/devstudio-directory.xml
> startup/launcher directories are hardcoded in the .ini file:
> -startup
> ../../../plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
> --launcher.library
> ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.200.v20130807-1835
> Have these been forgotten/set wrong in the update or is this some specific update path that is failing ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JBDS-2797) .ini upgrade issue for 7.0.1 users
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-2797?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-2797:
-------------------------------------
jbdevstudio.ini is not updated because we have two .app launchers:
# JBoss Developer Studio.app
# jbdevstudio.app
First is copy of second one. When update installed only second launcher is updated.
> .ini upgrade issue for 7.0.1 users
> ----------------------------------
>
> Key: JBDS-2797
> URL: https://issues.jboss.org/browse/JBDS-2797
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: build, installer
> Affects Versions: 7.0.1.GA
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Priority: Critical
>
> User noticed issues with 7.0.0 to 7.0.1 updates at https://community.jboss.org/message/841477#841477 that needs investigation.
> The post is about osx but I don't think this is limited to this OS, just that OSX has a different java behavior.
> Worrisome issues are:
> development url used in GA update:
> -Djboss.discovery.directory.url=https://devstudio.jboss.com/updates/7.0-development/devstudio-directory.xml
> startup/launcher directories are hardcoded in the .ini file:
> -startup
> ../../../plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
> --launcher.library
> ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.200.v20130807-1835
> Have these been forgotten/set wrong in the update or is this some specific update path that is failing ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months