[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15135:
----------------------------------------
{quote}QUESTION Should there be something in upstream?{quote}
Upstream contains the buildInfo from upstream sites, when available (except there own upstream elements or we'd get huge files)
{quote}QUESTION What about details about the OS & JDK version?{quote}
I didn't include them because I never used them (I also use this mojo as an opportunity to think about what's not useful any more). It would be easy to re-introduce if you use them occasionally.
{quote}QUESTION Why are TARGET_PLATFORM_VERSION, TARGET_PLATFORM_VERSION_MAXIMUM, BUILD_ALIAS and BUILD_ID not resolved? The first 3 of those are from maven variables in the parent pom (if not set commandline), and BUILD_ID is a timestamp that could be the same as the one placed in GIT_REVISION.txt{quote}
This should report the build properties that are specified manually. So unless you set those properties, buildInfo reports null. On Jenkins, since we set thos properties, they would be set.
{quote}QUESTION Why is WORKSPACE not listed, and resolved to `pwd` ? This is often useful when builds fail to figure out where files have been created on a slave's filesystem, because they don't all use the same workspace path convention. And while you CAN browse the workspace within Jenkins, sometimes it's more efficient to do so over ssh.{quote}
Same reason, it's reporting the value of the property from Jenkins (or CLI).
{quote}QUESTION Can you also generate an ALL_VERSIONS.txt for aggregate builds? Or does that only happen when the mojo detects there are upstream projects? If so, how do I tell the mojo that there are upstream projects when building locally?{quote}
This is meant to go in the upstream block when upstream data is available
{quote}QUESTION Why did you change the format of GIT_REVSION.txt? I like that you've added details about the repo from which the code comes, but would a format such as the one below be more compact & easier to parse out the useful values of branch/tag, SHA, and source repo?{quote}
I created this new format because it would also list aliases when there are some. I don't mind much changing it since I believe the "revision" block of buildinfo.json is a better alternative.
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18862:
-------------------------------------
[~mmalina] let me know if this works in master
> 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.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.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3275) Add wildfly archetypes to JBoss Central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3275?page=com.atlassian.jira.plugin.... ]
Fred Bricon edited comment on JBDS-3275 at 1/5/15 11:05 AM:
------------------------------------------------------------
Fastest solution is probably to use http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
was (Author: fbricon):
Fastest solution is probably to use
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
> Add wildfly archetypes to JBoss Central
> ---------------------------------------
>
> Key: JBDS-3275
> URL: https://issues.jboss.org/browse/JBDS-3275
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> Supporting Wildfly archetypes with JBoss Central. As an Java EE developer, I need to be able to switch between EAP and Wildfly, when I select Wildfly, the archetype needs to correctly include the right BOMs, where all artifacts are available only on Maven Central.
> This should include both the Java EE Web Project, Java EE EAR Project, and HTML5 Project
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3275) Add wildfly archetypes to JBoss Central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3275?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on JBDS-3275:
-----------------------------------
Fastest solution is probably to use
!http://static.jboss.org/wildfly/images/wildfly-banner-1180px.png!
... and set proper dimensions via css, if needed. File name says 1180px but it really is 1280.
In the mean time, you can also open a bug on https://issues.jboss.org/browse/DESIGN/ and request for a scaled down version of wildfly-banner.
> Add wildfly archetypes to JBoss Central
> ---------------------------------------
>
> Key: JBDS-3275
> URL: https://issues.jboss.org/browse/JBDS-3275
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Fix For: 8.1.0.GA
>
>
> Supporting Wildfly archetypes with JBoss Central. As an Java EE developer, I need to be able to switch between EAP and Wildfly, when I select Wildfly, the archetype needs to correctly include the right BOMs, where all artifacts are available only on Maven Central.
> This should include both the Java EE Web Project, Java EE EAR Project, and HTML5 Project
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18953) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18953?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-18953:
----------------------------------
Fix Version/s: (was: 4.3.0.Alpha1)
> Unexpected JAX-RS validation error for client filters
> -----------------------------------------------------
>
> Key: JBIDE-18953
> URL: https://issues.jboss.org/browse/JBIDE-18953
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.2.0.Final
> Reporter: Valentin Baciu
> Assignee: Xavier Coulon
> Fix For: 4.2.2.Final
>
>
> We are using JAX-RS client filters in our project. One of the classes looks like this:
> ...
> import java.io.IOException;
> import javax.ws.rs.client.ClientRequestContext;
> import javax.ws.rs.client.ClientRequestFilter;
> import javax.ws.rs.client.ClientResponseContext;
> import javax.ws.rs.client.ClientResponseFilter;
> import javax.ws.rs.ext.Provider;
> ...
> @Provider
> public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
> {
> ...
> }
> The class is part of a Dynamic Web Project with JAX-RS support turned on.
> The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
> The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
> I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18994) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18994?page=com.atlassian.jira.plugi... ]
Xavier Coulon updated JBIDE-18994:
----------------------------------
Fix Version/s: (was: 4.2.2.Final)
> Unexpected JAX-RS validation error for client filters
> -----------------------------------------------------
>
> Key: JBIDE-18994
> URL: https://issues.jboss.org/browse/JBIDE-18994
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.2.0.Final
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.3.0.Alpha1
>
>
> We are using JAX-RS client filters in our project. One of the classes looks like this:
> ...
> import java.io.IOException;
> import javax.ws.rs.client.ClientRequestContext;
> import javax.ws.rs.client.ClientRequestFilter;
> import javax.ws.rs.client.ClientResponseContext;
> import javax.ws.rs.client.ClientResponseFilter;
> import javax.ws.rs.ext.Provider;
> ...
> @Provider
> public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
> {
> ...
> }
> The class is part of a Dynamic Web Project with JAX-RS support turned on.
> The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
> The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
> I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18994) Unexpected JAX-RS validation error for client filters
by Xavier Coulon (JIRA)
Xavier Coulon created JBIDE-18994:
-------------------------------------
Summary: Unexpected JAX-RS validation error for client filters
Key: JBIDE-18994
URL: https://issues.jboss.org/browse/JBIDE-18994
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: webservices
Affects Versions: 4.2.0.Final
Reporter: Xavier Coulon
Assignee: Xavier Coulon
Fix For: 4.2.2.Final, 4.3.0.Alpha1
We are using JAX-RS client filters in our project. One of the classes looks like this:
...
import java.io.IOException;
import javax.ws.rs.client.ClientRequestContext;
import javax.ws.rs.client.ClientRequestFilter;
import javax.ws.rs.client.ClientResponseContext;
import javax.ws.rs.client.ClientResponseFilter;
import javax.ws.rs.ext.Provider;
...
@Provider
public class ClientFilter implements ClientRequestFilter, ClientRequestFilter
{
...
}
The class is part of a Dynamic Web Project with JAX-RS support turned on.
The combination of @Provider and either of the ClientRequestFilter or ClientRequestFilter appears to confuse the JAX-RS validator which produces the following error:
The Provider must implement at least one of the following interfaces: javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter, javax.ws.rs.ext.ExceptionMapper, javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.WriterInterceptor, javax.ws.rs.container.ContainerRequestFilter, javax.ws.rs.container.ContainerResponseFilter or javax.ws.rs.ext.ContextResolver.
I suspect the validator needs to be enhanced to also accept the two client filter interfaces when checking the @Provider annotation?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Burr Sutter commented on JBDS-3298:
-----------------------------------
[~maxandersen] I would say that is the oversimplified way to look at it. git push is step h, there are also things like i and j to consider. Not to mention a through g which are required before "git push" would work.
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3298:
-------------------------------------------
is this anything but just doing git push on the openshift project ?
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18827) Explorer: add Application start/stop/restart
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18827?page=com.atlassian.jira.plugi... ]
Marián Labuda reassigned JBIDE-18827:
-------------------------------------
Assignee: Andre Dietisheim (was: Marián Labuda)
> Explorer: add Application start/stop/restart
> ---------------------------------------------
>
> Key: JBIDE-18827
> URL: https://issues.jboss.org/browse/JBIDE-18827
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.2.0.Final
> Environment: Eclipse plugin
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Blocker
> Labels: explorer, new_and_noteworthy
> Fix For: 4.3.0.Alpha1
>
>
> The OpenShift Console view should contain controls for application start|stop|restart to match the functionality of the CLI. Currently, if you select Window->Show View->Others->OpenShift Express Console, then login in and select an application. The right-click menu doesn't have start|stop|restart so users have to either install the rhc client tools or ssh onto the OpenShift host gear.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
