May 2014 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-1825) Remove the overwrite flag in the Scaffold commands

by Vineet Reynolds (JIRA)

Vineet Reynolds created FORGE-1825: -------------------------------------- Summary: Remove the overwrite flag in the Scaffold commands Key: FORGE-1825 URL: https://issues.jboss.org/browse/FORGE-1825 Project: Forge Issue Type: Enhancement Components: Scaffold Affects Versions: 2.5.0.Final Reporter: Vineet Reynolds Assignee: Vineet Reynolds The overwrite flag in the scaffold commands makes sense if individual overwrites to existing files could be ignored. But this is not the case, since the flag. We should therefore remove the flag. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1824) IMPL modules of all addons should be marked as optional to prevent transitive compilation

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created FORGE-1824: ----------------------------------------- Summary: IMPL modules of all addons should be marked as optional to prevent transitive compilation Key: FORGE-1824 URL: https://issues.jboss.org/browse/FORGE-1824 Project: Forge Issue Type: Enhancement Components: Addon Development, Forge Build Affects Versions: 2.5.0.Final Reporter: Lincoln Baxter III Fix For: 2.5.1.Final Impl modules should all be marked as optional to prevent transitive compilation. Addons commands should be updated to make this the default for complex addon projects. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1823) Furnace addon-manager should include optional non-addon dependencies as if they were not optional

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1823?page=com.atlassian.jira.plugin... ] Lincoln Baxter III closed FORGE-1823. ------------------------------------- Assignee: Lincoln Baxter III Resolution: Done Done. > Furnace addon-manager should include optional non-addon dependencies as if they were not optional > ------------------------------------------------------------------------------------------------- > > Key: FORGE-1823 > URL: https://issues.jboss.org/browse/FORGE-1823 > Project: Forge > Issue Type: Enhancement > Components: Furnace (Container) > Affects Versions: 2.5.0.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Priority: Blocker > Fix For: 2.5.1.Final > > > {code} > jsightler > 5:10 lincolnthree: Could "optional" dependencies help here as well? > jsightler > 5:10 http://maven.apache.org/guides/introduction/introduction-to-optional-and-... > 5:10 sbryzak left the room (quit: Ping timeout: 264 seconds). > lincolnthree > 5:11 jsightler: possible actually..... > 5:11 jsightler: actualllyyyyyyyy > 5:11 jsightler: if the runtime scoped non-addon dependency were marked as optional, we could just decide to include that > 5:11 jsightler: as a one-off case > jsightler > 5:12 lincolnthree: fwiw, this definition of "optional" is not what I would have thought it to be. but it sounds like it could be useful for this scenario. :) > lincolnthree > 5:12 yeah, we already slightly hijacked optional > 5:13 jsightler: given that it would be impossible for addons to consume optional dependencies provided by addons that included them, this would technically work - if not be slightly confusing > gastaldi > 5:13 I think using the BOM is the best way to go > lincolnthree > 5:13 gastaldi: im not sure about that > gastaldi > 5:13 why not? > lincolnthree > 5:14 gastaldi: that requires that people actually use the bom, which is a good idea, but it doesn't solve the problem for 3rd party addons > gastaldi > 5:14 it worked here > lincolnthree > 5:14 gastaldi: it works for us, not for everyone else > gastaldi > 5:14 3rd party addons could have a BOM too... > lincolnthree > 5:14 gastaldi: we can't expect everyone to require that people use boms or dependencyManagement to control this. > 5:15 gastaldi: i think a runtime/optional non-addon dependency would be fine to include in the addon deployment > 5:15 gastaldi: we already changed the way poms are handled for forge-addon classified elements > 5:15 gastaldi: now we're changing how those addons include deps as well, but only in forge-addon classified deps > 5:15 gastaldi: i think this works > 5:16 jsightler: yes, this does what we want > 5:17 gastaldi: it would look like this: http://paste2.org/0UVzK6jL > 5:17 gastaldi: im not a fan of the syntax.....but.... given the options > 5:17 gastaldi: using this as a hack/toggle seems tolerable to me > jsightler > 5:17 lincolnthree: Nice. :) > 5:18 lincolnthree: Mostly I just think maven chose an awful word for this. > lincolnthree > 5:18 jsightler: yeah they did... > jsightler > 5:18 lincolnthree: Optional=="ignore me transitively in every case" > lincolnthree > 5:18 jsightler: right > 5:19 gastaldi: at which point, it wouldn't matter what scope the optional dependency is... > 5:19 gastaldi: think about it > 5:19 gastaldi: when would you ever want an "optional" library in an addon > 5:19 gastaldi: never > 5:19 gastaldi: there's no situation where it makes sense > gastaldi > 5:19 right... > lincolnthree > 5:19 gastaldi: because the classpath is isolated from things that depend on it > 5:20 gastaldi: so nothing could *ever* provide the optional dependency except itself > 5:20 gastaldi: it would be like writing classes that can never be classloaded ever > 5:20 gastaldi: lol > 5:20 gastaldi: like a dog chasing its tail > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1823) Furnace addon-manager should include optional non-addon dependencies as if they were not optional

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created FORGE-1823: ----------------------------------------- Summary: Furnace addon-manager should include optional non-addon dependencies as if they were not optional Key: FORGE-1823 URL: https://issues.jboss.org/browse/FORGE-1823 Project: Forge Issue Type: Enhancement Components: Furnace (Container) Affects Versions: 2.5.0.Final Reporter: Lincoln Baxter III Priority: Blocker Fix For: 2.5.1.Final {code} jsightler 5:10 lincolnthree: Could "optional" dependencies help here as well? jsightler 5:10 http://maven.apache.org/guides/introduction/introduction-to-optional-and-... 5:10 sbryzak left the room (quit: Ping timeout: 264 seconds). lincolnthree 5:11 jsightler: possible actually..... 5:11 jsightler: actualllyyyyyyyy 5:11 jsightler: if the runtime scoped non-addon dependency were marked as optional, we could just decide to include that 5:11 jsightler: as a one-off case jsightler 5:12 lincolnthree: fwiw, this definition of "optional" is not what I would have thought it to be. but it sounds like it could be useful for this scenario. :) lincolnthree 5:12 yeah, we already slightly hijacked optional 5:13 jsightler: given that it would be impossible for addons to consume optional dependencies provided by addons that included them, this would technically work - if not be slightly confusing gastaldi 5:13 I think using the BOM is the best way to go lincolnthree 5:13 gastaldi: im not sure about that gastaldi 5:13 why not? lincolnthree 5:14 gastaldi: that requires that people actually use the bom, which is a good idea, but it doesn't solve the problem for 3rd party addons gastaldi 5:14 it worked here lincolnthree 5:14 gastaldi: it works for us, not for everyone else gastaldi 5:14 3rd party addons could have a BOM too... lincolnthree 5:14 gastaldi: we can't expect everyone to require that people use boms or dependencyManagement to control this. 5:15 gastaldi: i think a runtime/optional non-addon dependency would be fine to include in the addon deployment 5:15 gastaldi: we already changed the way poms are handled for forge-addon classified elements 5:15 gastaldi: now we're changing how those addons include deps as well, but only in forge-addon classified deps 5:15 gastaldi: i think this works 5:16 jsightler: yes, this does what we want 5:17 gastaldi: it would look like this: http://paste2.org/0UVzK6jL 5:17 gastaldi: im not a fan of the syntax.....but.... given the options 5:17 gastaldi: using this as a hack/toggle seems tolerable to me jsightler 5:17 lincolnthree: Nice. :) 5:18 lincolnthree: Mostly I just think maven chose an awful word for this. lincolnthree 5:18 jsightler: yeah they did... jsightler 5:18 lincolnthree: Optional=="ignore me transitively in every case" lincolnthree 5:18 jsightler: right 5:19 gastaldi: at which point, it wouldn't matter what scope the optional dependency is... 5:19 gastaldi: think about it 5:19 gastaldi: when would you ever want an "optional" library in an addon 5:19 gastaldi: never 5:19 gastaldi: there's no situation where it makes sense gastaldi 5:19 right... lincolnthree 5:19 gastaldi: because the classpath is isolated from things that depend on it 5:20 gastaldi: so nothing could *ever* provide the optional dependency except itself 5:20 gastaldi: it would be like writing classes that can never be classloaded ever 5:20 gastaldi: lol 5:20 gastaldi: like a dog chasing its tail {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1822) Improve the ScaffoldSetupContext and ScaffoldGenerationContext APIs to include the Project instance

by Vineet Reynolds (JIRA)

Vineet Reynolds created FORGE-1822: -------------------------------------- Summary: Improve the ScaffoldSetupContext and ScaffoldGenerationContext APIs to include the Project instance Key: FORGE-1822 URL: https://issues.jboss.org/browse/FORGE-1822 Project: Forge Issue Type: Enhancement Components: Scaffold Affects Versions: 2.5.0.Final Reporter: Vineet Reynolds Assignee: Vineet Reynolds The Project instance could be supplied with the context instances to the scaffold providers instead of being provided as a separate argument in the SPI methods. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1819) Include red hat logo on footer of all pages of website

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1819?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-1819. ---------------------------------- Assignee: George Gastaldi Resolution: Done > Include red hat logo on footer of all pages of website > ------------------------------------------------------ > > Key: FORGE-1819 > URL: https://issues.jboss.org/browse/FORGE-1819 > Project: Forge > Issue Type: Sub-task > Components: Website > Affects Versions: 2.5.0.Final > Reporter: Lincoln Baxter III > Assignee: George Gastaldi > Fix For: 2.x Future > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-13) PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods

by Matej Briskar (JIRA)

[ https://issues.jboss.org/browse/ROASTER-13?page=com.atlassian.jira.plugin... ] Matej Briskar reopened ROASTER-13: ---------------------------------- > PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods > ------------------------------------------------------------------------------------------- > > Key: ROASTER-13 > URL: https://issues.jboss.org/browse/ROASTER-13 > Project: Roaster > Issue Type: Bug > Reporter: Matej Briskar > Assignee: Matej Briskar > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-13) PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods

by Matej Briskar (JIRA)

[ https://issues.jboss.org/browse/ROASTER-13?page=com.atlassian.jira.plugin... ] Matej Briskar resolved ROASTER-13. ---------------------------------- Resolution: Won't Fix > PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods > ------------------------------------------------------------------------------------------- > > Key: ROASTER-13 > URL: https://issues.jboss.org/browse/ROASTER-13 > Project: Roaster > Issue Type: Bug > Reporter: Matej Briskar > Assignee: Matej Briskar > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-13) PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods

by Matej Briskar (JIRA)

[ https://issues.jboss.org/browse/ROASTER-13?page=com.atlassian.jira.plugin... ] Matej Briskar resolved ROASTER-13. ---------------------------------- Resolution: Done > PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods > ------------------------------------------------------------------------------------------- > > Key: ROASTER-13 > URL: https://issues.jboss.org/browse/ROASTER-13 > Project: Roaster > Issue Type: Bug > Reporter: Matej Briskar > Assignee: Matej Briskar > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-13) PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods

by Matej Briskar (JIRA)

[ https://issues.jboss.org/browse/ROASTER-13?page=com.atlassian.jira.plugin... ] Matej Briskar commented on ROASTER-13: -------------------------------------- After the conversation, it is not considered to be wrong. > PropertyImpl is not checking return type/parameter type in isAccessor() isMutator() methods > ------------------------------------------------------------------------------------------- > > Key: ROASTER-13 > URL: https://issues.jboss.org/browse/ROASTER-13 > Project: Roaster > Issue Type: Bug > Reporter: Matej Briskar > Assignee: Matej Briskar > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues May 2014