[JBoss JIRA] (JBIDE-18363) BrowserSim/CordovaSim skins for iPhone 6 and 6+
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18363?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-18363:
-------------------------------------
< legal got back to me and said http://psdreams.com/free-psd/iphone-6-psd-mockups-pack is okey to use.
[~maxandersen] Great! Happy we got the green light ;-)
< legal underlined that the license says: "if you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original" thus any images etc. we derive from this material need to be marked as listed under this specific license.
^ Just want to clarify - is it about *Creative Commons Attribution 3.0 Unported License* or about *Creative Commons Attribution-ShareAlike 3.0*
AFAIK, *Creative Commons Attribution 3.0 Unported License* does *not* require distribution of our contributions under the same license as the original - http://creativecommons.org/licenses/by/3.0/.
> BrowserSim/CordovaSim skins for iPhone 6 and 6+
> -----------------------------------------------
>
> Key: JBIDE-18363
> URL: https://issues.jboss.org/browse/JBIDE-18363
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim, cordovasim
> Affects Versions: 4.2.0.Final
> Reporter: Alexey Kazakov
> Assignee: Ilya Buziuk
> Labels: new_and_noteworthy
> Fix For: 4.2.1.Final, 4.3.0.Alpha1
>
>
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18820) define how to handle ide.properties and avoid parent pom to always change
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18820:
---------------------------------------------
[~mickael_istria] thinking about your suggestion about mock, jbt and jbds is not a bad idea after all assuming we don't mix jboss.org and devstudio updatesites....
I know that I are very religious about this but others aren't...but I think this can be solved by JBT have lower priority over JBDS.
Which plugins/features would declare these require capabilities to ensure things get installed ?
> define how to handle ide.properties and avoid parent pom to always change
> -------------------------------------------------------------------------
>
> Key: JBIDE-18820
> URL: https://issues.jboss.org/browse/JBIDE-18820
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Reporter: Max Rydahl Andersen
>
> As illustrated in JBIDE-18806 our current setup of how ide.properties and project versioning are not working or at least we seem to not get it updated right.
> Current workaround applied is that parent pom now again defines the global version even though this is not reliable at all since not all plugins will be rebuilt. (see JBIDE-13452 for earlier attempts on this)
> Opening this jira to make sure we walkthrough and write down which values should be in ide.properties and what level (4.2.0.CR1, 4.2.0 or 4.2. etc), when they get updated (hopefully rarely) and how to avoid parent pom from always having to respin because of a maintanence release.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18820) define how to handle ide.properties and avoid parent pom to always change
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18820?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18820:
---------------------------------------------
I'm sorry - but these fixes does not fix the issue. It just makes versioning of the parent pom even *more* hardcoded to jbosstools version. This is *not* a better solution.
> define how to handle ide.properties and avoid parent pom to always change
> -------------------------------------------------------------------------
>
> Key: JBIDE-18820
> URL: https://issues.jboss.org/browse/JBIDE-18820
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Reporter: Max Rydahl Andersen
>
> As illustrated in JBIDE-18806 our current setup of how ide.properties and project versioning are not working or at least we seem to not get it updated right.
> Current workaround applied is that parent pom now again defines the global version even though this is not reliable at all since not all plugins will be rebuilt. (see JBIDE-13452 for earlier attempts on this)
> Opening this jira to make sure we walkthrough and write down which values should be in ide.properties and what level (4.2.0.CR1, 4.2.0 or 4.2. etc), when they get updated (hopefully rarely) and how to avoid parent pom from always having to respin because of a maintanence release.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18837) because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18837?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18837:
---------------------------------------------
This looks like a special case of JBIDE-18820 to me.
And I do not see why this is required. 4.2.0 and 4.2.1 settings should be the exact same, they should be stored under 4.2 in the settings. There should be zero difference.
Only time 4.2.1 are relevant is during its development phase *if* we have some changes/differences.
None of this should be this lockstepped - if it is there is something very wrong since it is a *backwards* compatible release.
Please give example of where such hard coupling would ever and have ever been an issue ?
For now a very big -1 on applying such changes.
> because Foundation defines the version of JBoss Tools used to do ide-config.properties lookup, must enforce it's always updated
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18837
> URL: https://issues.jboss.org/browse/JBIDE-18837
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, central, common/jst/core, project-examples
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Labels: respin-a
> Fix For: 4.2.1.CR1
>
>
> When updating from 4.2.0 to 4.2.1, a user might decide to only update Central or Project Examples, and NOT update Foundation.core, which means his Eclipse will still think it's 4.2.0, not 4.2.1, and he might get the wrong version of central/examples.
> Therefore we need manifest-level [4.2.1,) requirements on upstream foundation.core in examples and central, to force this lock-step updating.
> And we need to use the maven enforcer plugin to fail the build if these versions get out of sync.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months