[JBoss JIRA] (JBDS-3645) Installation of JBoss Developer Studio to a network drive fails
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3645?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3645:
--------------------------------
Fix Version/s: 11.x
(was: 11.0.0.GA)
> Installation of JBoss Developer Studio to a network drive fails
> ----------------------------------------------------------------
>
> Key: JBDS-3645
> URL: https://issues.jboss.org/browse/JBDS-3645
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 8.1.0.GA
> Environment: * Windows Server 2012
> Reporter: Takayuki Konishi
> Assignee: Denis Golovin
> Fix For: 11.x
>
>
> A customer is trying to install 64 bit jboss developer studio 8.1 using java 1.8 64 bit on a network drive (32 bit) from their local 64 bit machine.
> Installation failed with the error, see the attached error message:
> {code}
> !SESSION 2016-02-16 16:05:32.385 -----------------------------------------------
> eclipse.buildId=unknown
> java.version=1.8.0_65
> java.vendor=Oracle Corporation
> BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
> Framework arguments: -roaming -r jar:file:///E:/downloads/jboss-devstudio-8.1.0.GA-installer-standalone.jar!/ -d E:\tools\eclipse\studio -p jbds -i com.jboss.devstudio.core.package,org.testng.eclipse.feature.group,org.eclipse.wst.jsdt.feature.patch.feature.group -profileProperties org.eclipse.update.install.features=true
> Command-line arguments: -roaming -r jar:file:///E:/downloads/jboss-devstudio-8.1.0.GA-installer-standalone.jar!/ -d E:\tools\eclipse\studio -p jbds -i com.jboss.devstudio.core.package,org.testng.eclipse.feature.group,org.eclipse.wst.jsdt.feature.patch.feature.group -profileProperties org.eclipse.update.install.features=true
> !ENTRY org.eclipse.equinox.p2.engine 4 4 2016-02-16 16:27:12.468
> !MESSAGE An error occurred while installing the items
> !SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2016-02-16 16:27:12.468
> !MESSAGE session context was:(profile=jbds, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.rse.subsystems.shells.telnet 1.2.300.201403100950, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
> !SUBENTRY 1 org.eclipse.equinox.p2.touchpoint.eclipse 4 0 2016-02-16 16:27:12.468
> !MESSAGE The artifact file for osgi.bundle,org.eclipse.rse.subsystems.shells.telnet,1.2.300.201403100950 was not found.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-22443) Add to TP build a check that produced TP can be installed in target Eclipse version
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22443?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22443:
-------------------------------
Attachment: composite.install.test.log.txt
> Add to TP build a check that produced TP can be installed in target Eclipse version
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-22443
> URL: https://issues.jboss.org/browse/JBIDE-22443
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, target-platform
> Reporter: Mickael Istria
> Fix For: 4.5.x
>
> Attachments: composite.install.test.log.txt
>
>
> Recently, a change in TP (jetty 9.3.6) was introduced and everything built fine with it; until the very end of the build process: during install-tests.
> This issue would *probably* have occured if trying to install all content of the TP into the target Eclipse IDE (using install-grinder or p2director or whatever installation). So it would be good to have inside the TP build (as a "verify" plugin in pom.xml) something that would try to find whether target Eclipse version and our TP are already compatible.
> Technical notes:
> * Trying to install all IUs from the release train site + our TP seems easier to implement
> * We do not need to actually install the artifacts, just making the p2 request and getting whether the request managed to find a working plan without remediation seems enough.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-22443) Add to TP build a check that produced TP can be installed in target Eclipse version
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22443?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-22443:
------------------------------------
Max's suggestion and JBDS-3917 are now the same thing.
And installing the contents of the TP into an Eclipse platform is something we already do as part of the composite install job, which runs on any TP change or any JBT component republish.
For example... https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud... shows we install the whole TP plus all of JBT. Here's a snippet from that log: [^composite.install.test.log.txt]
So... I'm inclined to close this since we do the same sort of verification, albeit a bit AFTER the TP is built.
> Add to TP build a check that produced TP can be installed in target Eclipse version
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-22443
> URL: https://issues.jboss.org/browse/JBIDE-22443
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, target-platform
> Reporter: Mickael Istria
> Fix For: 4.5.x
>
> Attachments: composite.install.test.log.txt
>
>
> Recently, a change in TP (jetty 9.3.6) was introduced and everything built fine with it; until the very end of the build process: during install-tests.
> This issue would *probably* have occured if trying to install all content of the TP into the target Eclipse IDE (using install-grinder or p2director or whatever installation). So it would be good to have inside the TP build (as a "verify" plugin in pom.xml) something that would try to find whether target Eclipse version and our TP are already compatible.
> Technical notes:
> * Trying to install all IUs from the release train site + our TP seems easier to implement
> * We do not need to actually install the artifacts, just making the p2 request and getting whether the request managed to find a working plan without remediation seems enough.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBDS-3827) DevStudio installation fails when (windows) user has non-ascii chars in the name
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3827?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3827:
--------------------------------
Fix Version/s: 11.x
(was: 11.0.0.GA)
> DevStudio installation fails when (windows) user has non-ascii chars in the name
> --------------------------------------------------------------------------------
>
> Key: JBDS-3827
> URL: https://issues.jboss.org/browse/JBDS-3827
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 9.1.0.CR1, 10.4.0.GA
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc
> Fix For: 11.x
>
>
> I have created a user named Pakoň and tried to install everything into the default folder. JBDS failed with:
> {noformat}Fri, 15 Apr 2016 12:38:40 GMT-ERROR: jbds - Error: Command failed: c:\DeveloperPlatform\jdk8\bin\java.exe -DTRACE=true -jar C:\WINDOWS\7zS9F06.tmp\jbds.jar C:\Users\Pakoň\AppData\Local\Temp\jbds-autoinstall.xml
> - ERROR -
> java.io.FileNotFoundException: C:\Users\Pakon\AppData\Local\Temp\jbds-autoinstall.xml (The system cannot find the path specified)
> java.io.FileNotFoundException: C:\Users\Pakon\AppData\Local\Temp\jbds-autoinstall.xml (The system cannot find the path specified)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> at com.izforge.izpack.installer.AutomatedInstaller.getXMLData(AutomatedInstaller.java:564)
> at com.izforge.izpack.installer.AutomatedInstaller.<init>(AutomatedInstaller.java:86)
> at com.izforge.izpack.installer.Installer.main(Unknown Source){noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-22443) Add to TP build a check that produced TP can be installed in target Eclipse version
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22443?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22443:
-------------------------------
Fix Version/s: 4.5.x
(was: 4.4.x)
> Add to TP build a check that produced TP can be installed in target Eclipse version
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-22443
> URL: https://issues.jboss.org/browse/JBIDE-22443
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build, target-platform
> Reporter: Mickael Istria
> Fix For: 4.5.x
>
>
> Recently, a change in TP (jetty 9.3.6) was introduced and everything built fine with it; until the very end of the build process: during install-tests.
> This issue would *probably* have occured if trying to install all content of the TP into the target Eclipse IDE (using install-grinder or p2director or whatever installation). So it would be good to have inside the TP build (as a "verify" plugin in pom.xml) something that would try to find whether target Eclipse version and our TP are already compatible.
> Technical notes:
> * Trying to install all IUs from the release train site + our TP seems easier to implement
> * We do not need to actually install the artifacts, just making the p2 request and getting whether the request managed to find a working plan without remediation seems enough.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24789) Find a way to avoid freeze of master for several days
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24789?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-24789:
------------------------------------
1. Creating branches can be done by script.
2. Updating parent pom can be done by script.
3. Updating jbosstools-* project root poms to use the new parent pom can be done by script, *except for projects with Protected Branches like fuse and fuse-extras*.
We've never created milestone branches for AM1, AM2, AM3. But we used to create a branch when code freezing for the 4th sprint to GA, so that as soon as GA bits were done and ready to build, devs could continue in master while the jobs were updated to use the 4.5.0.x branch.
For this train, we decided to NOT create the 4.5.0.x branch to simplify the amount of changes/steps involved in releases.
> Find a way to avoid freeze of master for several days
> -----------------------------------------------------
>
> Key: JBIDE-24789
> URL: https://issues.jboss.org/browse/JBIDE-24789
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Fix For: 4.5.x
>
>
> Currently, for each milestone, final release, the master branch is frozen for several days which is decreasing productivity and increase risk at the end of code freeze (as everybody wants to merge a lot of PRs at the same time)
> it would be nice to find a way to avoid the freeze on the master branch.
> Proposal:
> - create a branch for each milestone/release:
> -- it allows to continue working on master
> -- it allows to provide blocker/critical fix if needed on the branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24789) Find a way to avoid freeze of master for several days
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24789?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-24789:
----------------------------------
Assignee: Jeff MAURY
> Find a way to avoid freeze of master for several days
> -----------------------------------------------------
>
> Key: JBIDE-24789
> URL: https://issues.jboss.org/browse/JBIDE-24789
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.5.x
>
>
> Currently, for each milestone, final release, the master branch is frozen for several days which is decreasing productivity and increase risk at the end of code freeze (as everybody wants to merge a lot of PRs at the same time)
> it would be nice to find a way to avoid the freeze on the master branch.
> Proposal:
> - create a branch for each milestone/release:
> -- it allows to continue working on master
> -- it allows to provide blocker/critical fix if needed on the branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24789) Find a way to avoid freeze of master for several days
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24789?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-24789:
-------------------------------
Fix Version/s: 4.5.x
> Find a way to avoid freeze of master for several days
> -----------------------------------------------------
>
> Key: JBIDE-24789
> URL: https://issues.jboss.org/browse/JBIDE-24789
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.5.0.Final
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.5.x
>
>
> Currently, for each milestone, final release, the master branch is frozen for several days which is decreasing productivity and increase risk at the end of code freeze (as everybody wants to merge a lot of PRs at the same time)
> it would be nice to find a way to avoid the freeze on the master branch.
> Proposal:
> - create a branch for each milestone/release:
> -- it allows to continue working on master
> -- it allows to provide blocker/critical fix if needed on the branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months