[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21012:
------------------------------------
So... I have no answer here for how to use Nexus for snapshots that don't conflict across the same x.y.z version.
And I have no answer for how to publish to the snapshots repo, with automatic unpacking via the unzip plugin, for a deployment which doesn't have -SNAPSHOT in its name. Sure, we could build the update site and call it 4.3.0.Beta5 instead of 4.3.0-SNAPSHOT, but then it gets pushed to the non-public staging Nexus repo for RELEASE (which Jenkins can't directly push to, afaict), not the public snapshots repo.
I can currently only think of two possible ways around this:
* upversion every time we do a milestone (instead of 4.3.0.Beta1 then 4.3.0.Beta2, we would do 4.3.0 then 4.3.1)
* freeze master branch builds until the milestone is built, respun if needed, and released.
IMHO neither of these are viable solutions (too much churn, too likely to screw up if a job is accidentally turned back on), so we have no choice but to remove deployment to nexus for JBT component sites.
One last option I can see is to figure out a way to convince Jenkins that when it wants to push to /staging/ it REALLY means /snapshots/... perhaps with a Maven config override or settings.xml file?
[~mickael_istria] do you know a way to force Maven to push a non-SNAPSHOT versioned artifact to /snapshots/ instead of /staging/ ?
> Why do we deploy JBT components to Nexus snapshots repo?
> --------------------------------------------------------
>
> Key: JBIDE-21012
> URL: https://issues.jboss.org/browse/JBIDE-21012
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo.
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBTIS-529) fuse fails to install from jboss central
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBTIS-529?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBTIS-529:
-----------------------------
Fix Version/s: 4.3.0.Alpha2
> fuse fails to install from jboss central
> ----------------------------------------
>
> Key: JBTIS-529
> URL: https://issues.jboss.org/browse/JBTIS-529
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Reporter: Max Rydahl Andersen
> Assignee: Fred Bricon
> Priority: Blocker
> Labels: respin-b
> Fix For: 4.3.0.Alpha2
>
>
> not sure where the fault is here but when you open JBDS 9 and type in 'Fuse' you get the "Fuse Integraiotn Project" despite Fuse is only earlyaccess.
> But even with or without earlyaccess installing via the wizard result in:
> Problems occurred while performing installation: There are no connectors to install
> There are no connectors to install
> /cc [~fbricon] any idea ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBTIS-529) fuse fails to install from jboss central
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBTIS-529?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBTIS-529:
-----------------------------
Labels: respin-b (was: )
> fuse fails to install from jboss central
> ----------------------------------------
>
> Key: JBTIS-529
> URL: https://issues.jboss.org/browse/JBTIS-529
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Reporter: Max Rydahl Andersen
> Assignee: Fred Bricon
> Priority: Blocker
> Labels: respin-b
> Fix For: 4.3.0.Alpha2
>
>
> not sure where the fault is here but when you open JBDS 9 and type in 'Fuse' you get the "Fuse Integraiotn Project" despite Fuse is only earlyaccess.
> But even with or without earlyaccess installing via the wizard result in:
> Problems occurred while performing installation: There are no connectors to install
> There are no connectors to install
> /cc [~fbricon] any idea ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBTIS-529) fuse fails to install from jboss central
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBTIS-529?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on JBTIS-529:
-----------------------------------
OK, so the Fuse wizard is now hidden when EA is disabled (close/reopen central to see it happen).
Now looking into problem #2...
> fuse fails to install from jboss central
> ----------------------------------------
>
> Key: JBTIS-529
> URL: https://issues.jboss.org/browse/JBTIS-529
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Reporter: Max Rydahl Andersen
> Assignee: Fred Bricon
> Priority: Blocker
>
> not sure where the fault is here but when you open JBDS 9 and type in 'Fuse' you get the "Fuse Integraiotn Project" despite Fuse is only earlyaccess.
> But even with or without earlyaccess installing via the wizard result in:
> Problems occurred while performing installation: There are no connectors to install
> There are no connectors to install
> /cc [~fbricon] any idea ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3551) JavaEE Developer - be able to start/stop applications on docker with debug on/off
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3551?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov updated JBDS-3551:
---------------------------------
Component/s: docker
(was: jsp/jsf/xml/html-source-editing)
> JavaEE Developer - be able to start/stop applications on docker with debug on/off
> ---------------------------------------------------------------------------------
>
> Key: JBDS-3551
> URL: https://issues.jboss.org/browse/JBDS-3551
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Story
> Components: docker
> Reporter: Max Rydahl Andersen
> Assignee: Alexey Kazakov
>
> User Story:
> As a JavaEE Developer I should be able to start/stop applications with debug turned on or off
> Acceptance Criteria:
> * Developer can start/stop an application from a central place, no CLI operations needed.
> * Developer can start with or without debug enabled
> * if necessary to restart when going from started to debugging or debugging to started the user should be asked if really want to restart
> * When debug is on the Java debugger should be connected and any enabled breakpoints when hit should show up in the debugger
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3551) JavaEE Developer - be able to start/stop applications on docker with debug on/off
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3551?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov reassigned JBDS-3551:
------------------------------------
Assignee: Xavier Coulon (was: Alexey Kazakov)
> JavaEE Developer - be able to start/stop applications on docker with debug on/off
> ---------------------------------------------------------------------------------
>
> Key: JBDS-3551
> URL: https://issues.jboss.org/browse/JBDS-3551
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Story
> Components: docker
> Reporter: Max Rydahl Andersen
> Assignee: Xavier Coulon
>
> User Story:
> As a JavaEE Developer I should be able to start/stop applications with debug turned on or off
> Acceptance Criteria:
> * Developer can start/stop an application from a central place, no CLI operations needed.
> * Developer can start with or without debug enabled
> * if necessary to restart when going from started to debugging or debugging to started the user should be asked if really want to restart
> * When debug is on the Java debugger should be connected and any enabled breakpoints when hit should show up in the debugger
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years