[JBoss JIRA] (JBTIS-471) Unify component versions
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-471?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBTIS-471:
-----------------------------------------
One small change
* JBoss Drools Core 6.4.0.201601201107 should be 6.4.0.CR1-v201601201107-0800-B212 (added the "CR1" rather than "Final" because we are still not in GA)
Moreover, I also noticed that the SAP tooling doesn't follow the format
* JBoss Fuse SAP Tool Suite 8.0.0.v20160215-1551-H23-Beta1 should be 8.0.0.Beta1-v20160215-1551-B23
> Unify component versions
> ------------------------
>
> Key: JBTIS-471
> URL: https://issues.jboss.org/browse/JBTIS-471
> Project: JBoss Tools Integration Stack
> Issue Type: Enhancement
> Components: distribution
> Affects Versions: 8.0.3.GA
> Reporter: Andrej Podhradsky
> Assignee: Robert (Bob) Brodt
> Fix For: 4.3.0.Beta1
>
> Attachments: junit4.8vs4.12.png
>
>
> Currently, JBDS-IS 8.0.3.CR2 contains components with different version format such as
> BPMN2 1.1.3.Final
> Fuse 7.3.1.v20150728-1330-H54-Final
> Teiid Designer 9.0.3.Final-v20150728-2029-B1148
> I suggest to use the format used by Teiid Designer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3557) JBDS Installer should be EPL licensed
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBDS-3557?page=com.atlassian.jira.plugin.... ]
Martin Malina closed JBDS-3557.
-------------------------------
In this case I am closing this issue.
> JBDS Installer should be EPL licensed
> -------------------------------------
>
> Key: JBDS-3557
> URL: https://issues.jboss.org/browse/JBDS-3557
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Components: installer, legal
> Reporter: Ken Finnigan
> Assignee: Nick Boldt
> Fix For: 9.1.0.CR1, 10.0.0.Alpha1
>
>
> For the Developer Platform to be able to bundle JBDS, it needs to be licensed as ASLv2 or EPL and not GPL
> Sources code in repository ether has Apache Licence or no license.
> IzPack distribution jar's and licenses:
> 1. kunstoff Look and Feel is under LGPL http://kunstoff.incors.com/archive/licence.php3
> 2. Birosoft Liquid Look and Feel
> The source code (except the files or methods mentioned below) of the look and feel is released under the LGPL (GNU Lesser General Public License),
> which you can view on http://www.gnu.org/copyleft/lesser.html.
> Some methods are marked as SUN proprietary, the LGPL does not apply for those methods.
> 3. JGoodies Karsten Lentzsch - BSD open source license http://www.jgoodies.com/downloads/libraries/
> 4. Metouia Look And Feel: a free pluggable look and feel for java - LGPLv2.1 http://grepcode.com/file/repo1.maven.org/maven2/net.sf.squirrel-sql.third...
> 5. Nimbus Look And Feel
> This library is free software; you can redistribute it and/or
> * modify it under the terms of the GNU Lesser General Public
> * License as published by the Free Software Foundation; either
> * version 2.1 of the License, or (at your option) any later version.
> 6. Substance Java Look and Feel (bundles several components with licenses listed below)
> 6.1 Copyright (c) 2005-2007, Kirill Grouchnikov and contributors
> All rights reserved.
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are met:
> * Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
> * Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in the
> documentation and/or other materials provided with the distribution.
> * Neither the name of the Kirill Grouchnikov and contributors nor
> the names of its contributors may be used to endorse or promote products
> derived from this software without specific prior written permission.
> 6.2 Source code, documentation and binaries of the Quaqua Look and
> Feel (also called "this software") are subject to the GNU Lesser
> General Public License (LGPL).
> 6.3. MOZILLA PUBLIC LICENSE Version 1.1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21719) Move Properties view to its previous position
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21719?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-21719:
----------------------------------------
Project: Tools (JBoss Tools) (was: Developer Studio (JBoss Developer Studio))
Key: JBIDE-21719 (was: JBDS-3599)
Workflow: GIT Pull Request workflow (was: CDW v1)
Status: Open (was: New)
Docs QE Status: (was: NEW)
Affects Version/s: (was: 9.1.0.Beta2)
> Move Properties view to its previous position
> ---------------------------------------------
>
> Key: JBIDE-21719
> URL: https://issues.jboss.org/browse/JBIDE-21719
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Environment: JBDS 9.1.0.Beta2
> JBDS 9.1.0.CR1-v20160218-0332-B322 (nightly build)
> Reporter: Andrej Podhradsky
> Priority: Minor
> Attachments: jbds-8.1.0.GA.png, jbds-9.1.0.CR1.png
>
>
> I noticed that the Properties view is located at the right bottom (see the screenshot jbds-9.1.0.CR1.png). The width of the view is not enough if we want to use it in SwitchYard / Camel / BPMN2 editor. Please move it to the position as it was in JBDS 8.1.0.GA (jbds-8.1.0.GA.png).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3599) Move Properties view to its previous position
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-3599?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on JBDS-3599:
-------------------------------------------
If we move it back users can't see the properties view when they use server, docker and openshift explorer views.
For now I would weight being able to see the properties view for the most used views over a single editor that has a very wide properties setup.
But can you provide some examples of where we have properties UI that is so wide you can't have it in the default position ?
> Move Properties view to its previous position
> ---------------------------------------------
>
> Key: JBDS-3599
> URL: https://issues.jboss.org/browse/JBDS-3599
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Enhancement
> Affects Versions: 9.1.0.Beta2
> Environment: JBDS 9.1.0.Beta2
> JBDS 9.1.0.CR1-v20160218-0332-B322 (nightly build)
> Reporter: Andrej Podhradsky
> Priority: Minor
> Attachments: jbds-8.1.0.GA.png, jbds-9.1.0.CR1.png
>
>
> I noticed that the Properties view is located at the right bottom (see the screenshot jbds-9.1.0.CR1.png). The width of the view is not enough if we want to use it in SwitchYard / Camel / BPMN2 editor. Please move it to the position as it was in JBDS 8.1.0.GA (jbds-8.1.0.GA.png).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21657) set up jobs to handle building from PRs
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21657?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-21657:
---------------------------------------------
+1000 on this. I did templates for doing this but we never got the templatized jobs and at the time the builds were too intermingle to publish reliably to a separate site. If we can do it manually for the 40 odd or so jobs that is better than nothing.
About posting the build result - then I would say that is a big plus if we can, but there is more often than not more than 1 pr on our repos so I don't think having autoclean happen that way is practical. Can we do keep a week instead ?
Also note that when some git pushes (with or without force) to the PR it should just overwrite the old pr content.
About the filtering - why not just run mvn install and just override the publish location ? the issue you have is because you are setting the various parameters on the job is it not ?
In the case of PR's you cannot feasibly know which branches etc. they are rebased against, and I would argue its better if we dont have to care. The PR builds should be built as you would do it locally, with only difference being where the publish destination goes.
> set up jobs to handle building from PRs
> ---------------------------------------
>
> Key: JBIDE-21657
> URL: https://issues.jboss.org/browse/JBIDE-21657
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.1.Beta2, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.CR1, 4.4.0.Alpha1
>
>
> First experimental build:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sit...
> Output:
> http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-bui...
> {code}
> "revision" : {
> "HEAD" : "bfe76fb3f3c34d68b873d0acf715e2145e4cb805",
> "currentBranch" : "HEAD",
> "knownReferences" : [{
> "name" : "origin",
> "url" : "git://github.com/jbosstools/jbosstools-build-sites.git",
> "ref" : "pr/221/merge"
> }]
> },
> {code}
> http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-bui...
> {code}
> #Fri Feb 05 16:42:42 EST 2016
> null\:merge=bfe76fb3f3c34d68b873d0acf715e2145e4cb805
> HEAD=bfe76fb3f3c34d68b873d0acf715e2145e4cb805
> {code}
> build log:
> {code}
> Started by upstream project "jbosstools-build-sites.aggregate.child-sites__pull-request_master" build number 1
> originally caused by:
> GitHub pull request #221 of commit 50c10ad83d250d2b86f5697c4581ba8f9cb4937d, no merge conflicts.
> ...
> Fetching upstream changes from git://github.com/jbosstools/jbosstools-build-sites.git
> > git -c core.askpass=true fetch --tags --progress git://github.com/jbosstools/jbosstools-build-sites.git +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/*
> Checking out Revision bfe76fb3f3c34d68b873d0acf715e2145e4cb805 (refs/remotes/origin/pr/221/merge)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f bfe76fb3f3c34d68b873d0acf715e2145e4cb805
> {code}
> vars:
> {code}
> -DghprbActualCommit=50c10ad83d250d2b86f5697c4581ba8f9cb4937d
> -DghprbPullId=221
> -Dsha1=origin/pr/221/merge
> "-DghprbPullDescription=GitHub pull request #221 of commit 50c10ad83d250d2b86f5697c4581ba8f9cb4937d, no merge conflicts."
> -DghprbActualCommit=50c10ad83d250d2b86f5697c4581ba8f9cb4937d
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3598) Error while building Jboss developer studio 9.1.0 Beta 2 from source
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3598?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3598:
----------------------------------
Re: your question about other projects that use reproducible version qualifiers, the issue here is simply that we have a src zip with no .git folder, so the jgit timestamp provider won't work. I tried a workaround using -DforceContextQualifier but that doesn't appear to work.
So, one possible solution is to create the sources zip using `git clone` instead of `git archive`:
https://github.com/jbosstools/jbosstools-maven-plugins/pull/53
For the case of the JBDS src zip, this only adds about 2.5M to the already 225M zip, so it's only a minor increase in relative size.
---
Re: replacing the need for a src zip w/ simply telling users to fetch sources directly from a tag in Github... it's not exactly a drop-in replacement for creating a zip, but it'd also be a simpler way to provide sources. But if we need to provide a source zip rather than a link to live sources in Github (eg., for legal or offline reasons) then the above PR should work.
[~mickael_istria] please review when you're back from PTO.
> Error while building Jboss developer studio 9.1.0 Beta 2 from source
> --------------------------------------------------------------------
>
> Key: JBDS-3598
> URL: https://issues.jboss.org/browse/JBDS-3598
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: build
> Affects Versions: 9.1.0.Beta2
> Environment: RHEL 7.1 PPC64le and Ubuntu x86_64
> Maven - 3.3.9
> JDK - 1.8
> Reporter: Deepali Chourasia
> Assignee: Nick Boldt
> Fix For: 9.1.0.CR1, 10.0.0.Alpha1
>
> Attachments: Jboss_devstudio_9.1.0_Beta2_buildlog.txt
>
>
> I have downloaded jboss-devstudio-9.1.0.Beta2-src.zip and am building it from source.
> The build fails with the following error:
> [ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.24.0:package-plugin (default-package-plugin) on project com.jboss.devstudio.core: Execution default-package-plugin of goal org.eclipse.tycho:tycho-packaging-plugin:0.24.0:package-plugin failed: One of setGitDir or setWorkTree must be called. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.24.0:package-plugin (default-package-plugin) on project com.jboss.devstudio.core: Execution default-package-plugin of goal org.eclipse.tycho:tycho-packaging-plugin:0.24.0:package-plugin failed: One of setGitDir or setWorkTree must be called.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-package-plugin of goal org.eclipse.tycho:tycho-packaging-plugin:0.24.0:package-plugin failed: One of setGitDir or setWorkTree must be called.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBDS-3589) no composite*.xml files in root of JBDS installer
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-3589?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-3589:
----------------------------------
[~dgolovin] can you review ?
> no composite*.xml files in root of JBDS installer
> -------------------------------------------------
>
> Key: JBDS-3589
> URL: https://issues.jboss.org/browse/JBDS-3589
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> JBDS installer no longer includes composite*.xml in its root folder, so the jar won't work as an offline update site (eg., for an offline install of JBDS IS into Eclipse)
> {code}
> org.eclipse.equinox.p2.core.ProvisionException: No repository found at jar:file:/home/nboldt/tmp/JBDS_Installers/jboss-devstudio-9.1.0.Beta2-v20160127-2213-B262-installer-standalone.jar!/.
> {code}
> Workaround:
> use jar:file:/home/nboldt/tmp/JBDS_Installers/jboss-devstudio-9.1.0.Beta2-v20160127-2213-B262-installer-standalone.jar!/jbds/ as the update site path
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month