[JBoss JIRA] (JBIDE-15610) For 4.1.1.Beta1: since one forge plugin has bumped, so should they all
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15610?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15610:
------------------------------------
You're suggesting that instead of bumping anything from 1.2.0 to 1.2.1, we should have just bumped the feature to 1.2.0a ?
Dude, that's crazytalk.The contained runtime plugin changed from version 1.3.3 to 1.4.1, so it's a full minor update (including a service update too). The version of the wrapper feature should be at least 1.2.1, if not 1.3.0.
> For 4.1.1.Beta1: since one forge plugin has bumped, so should they all
> ----------------------------------------------------------------------
>
> Key: JBIDE-15610
> URL: https://issues.jboss.org/browse/JBIDE-15610
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Affects Versions: 4.1.1.Alpha2
> Reporter: Nick Boldt
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.1.1.Beta1
>
>
> [~maxandersen] would prefer that since a single forge plugin (forge.runtime) has bumped from 1.3.3 to 1.4.1, that all the forge plugins (and their containing features) also bump at least their service (micro) increment.
> Thus:
> 1.2.0 -> 1.2.1
> 1.0.0 -> 1.0.1
> 2.0.0 -> 2.0.1
> And in master branch [1], I'm guessing this is wrong:
> {code}org.jboss.tools.forge2.runtime_2.0.1.Alpha1-v20130927-1755-B403.jar{code}
> Shouldn't that be at version 2.1.0 or 2.0.100, not 2.0.1?
> [1] http://download.jboss.org/jbosstools/builds/staging/jbosstools-forge_mast...
--
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-2783) Increase default EGit/OpenShift timeout
by Mickael Istria (JIRA)
Mickael Istria created JBDS-2783:
------------------------------------
Summary: Increase default EGit/OpenShift timeout
Key: JBDS-2783
URL: https://issues.jboss.org/browse/JBDS-2783
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: openshift, p2-product
Affects Versions: 7.0.0.GA, 7.1.0.Alpha2
Reporter: Mickael Istria
Assignee: Max Rydahl Andersen
Default value for EGit and OpenShift is 30 seconds. In most cases, this value is too short and isn't enoguh for a successful deploy of a dummy JEE app inside JBDS, which leads to a poor first impression.
As we can control the preferences in JBDS (with installer), I suggest we should make default to 60 which seems to behave better.
--
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-2783) Increase default EGit/OpenShift timeout
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-2783?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-2783:
-----------------------------
CDW devel_ack: ?
CDW pm_ack: ?
CDW qa_ack: ?
CDW release: ?
> Increase default EGit/OpenShift timeout
> ---------------------------------------
>
> Key: JBDS-2783
> URL: https://issues.jboss.org/browse/JBDS-2783
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: openshift, p2-product
> Affects Versions: 7.0.0.GA, 7.1.0.Alpha2
> Reporter: Mickael Istria
> Assignee: Max Rydahl Andersen
>
> Default value for EGit and OpenShift is 30 seconds. In most cases, this value is too short and isn't enoguh for a successful deploy of a dummy JEE app inside JBDS, which leads to a poor first impression.
> As we can control the preferences in JBDS (with installer), I suggest we should make default to 60 which seems to behave better.
--
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-15606) build tool to regenerate component update sites from published JBT aggregate
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15606?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15606:
------------------------------------
In the past this step's not been needed, because the whole stack just rebuilt itself even if nothing had changed.
But going forward, we're trying to be better about "nothing changed == no respins", so I need to have 1 repo per component that won't be changing in the next release.
The reason I don't want to put in specific versions is that it means maintaining that information in multiple places:
1. http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.... composite*.xml
2. https://github.com/jbosstools/jbosstools-build-sites/blob/jbosstools-4.1....
3. https://github.com/jbosstools/jbosstools-build-sites/blob/jbosstools-4.1....
etc.
What I'd like to do is find the midground between "release every component by itself AS WELL as JBT aggregate" (too much work - especially if some projects start out unchanged for Alpha1 and then later end up changing for Alpha2, like Forge; or like Freemarker which didn't change at all during the JBT 4.1.0 cycle until after Beta, IIRC) and "oops, we need to go back and re-aggregate a few projects".
> build tool to regenerate component update sites from published JBT aggregate
> ----------------------------------------------------------------------------
>
> Key: JBIDE-15606
> URL: https://issues.jboss.org/browse/JBIDE-15606
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.1.1.Alpha2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1
>
>
> When we released JBT 4.1.0.Final, we didn't publish the individual projects as sites themselves, so now when we're trying to aggregate JBT 4.1.1.Alpha2 using a combination of unchanged older projects + changed newer projects, we're unable to do so.
> We could rebuild the projects from source, but it would be better to simply re-aggregate the binaries in order to produce subset sites which match the content of the released JBT site, but only for those individual projects.
> This would allow us to swap in/out projects like GWT, Freemarker, Birt, Hibernate and Portal, which haven't changed yet since JBT 4.1.0.Final was released.
--
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-15615) Easily filter dependencies during Maven conversion
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15615?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-15615:
--------------------------------
Description: When converting a Maven project with a large number of dependencies, it can be hard to navigate/select the ones needing to be converted. Adding a filter textbox on top of the dependencies table would help (was: When converting a Maven project with a large number of depencies, it can be hard to navigate/select the ones needing to be converted. Adding a filter textbox on top of the dependencies table would help)
> Easily filter dependencies during Maven conversion
> --------------------------------------------------
>
> Key: JBIDE-15615
> URL: https://issues.jboss.org/browse/JBIDE-15615
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Affects Versions: 4.1.0.Final
> Reporter: Fred Bricon
> Assignee: Fred Bricon
> Labels: new_and_noteworthy
> Fix For: 4.2.0.Alpha1
>
>
> When converting a Maven project with a large number of dependencies, it can be hard to navigate/select the ones needing to be converted. Adding a filter textbox on top of the dependencies table would help
--
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