October 2014 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-2076) Add command to generate DAOs from JPA Entities

by Salem Elrahal (JIRA)

[ https://issues.jboss.org/browse/FORGE-2076?page=com.atlassian.jira.plugin... ] Salem Elrahal reassigned FORGE-2076: ------------------------------------ Assignee: Salem Elrahal > Add command to generate DAOs from JPA Entities > ---------------------------------------------- > > Key: FORGE-2076 > URL: https://issues.jboss.org/browse/FORGE-2076 > Project: Forge > Issue Type: Feature Request > Reporter: Salem Elrahal > Assignee: Salem Elrahal > > Add a command to forge that will generate DAOs from JPA Entities -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2076) Add command to generate DAOs from JPA Entities

by Salem Elrahal (JIRA)

Salem Elrahal created FORGE-2076: ------------------------------------ Summary: Add command to generate DAOs from JPA Entities Key: FORGE-2076 URL: https://issues.jboss.org/browse/FORGE-2076 Project: Forge Issue Type: Feature Request Reporter: Salem Elrahal Add a command to forge that will generate DAOs from JPA Entities -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2075) Facet like support for .jar introspection

by paolo antinori (JIRA)

paolo antinori created FORGE-2075: ------------------------------------- Summary: Facet like support for .jar introspection Key: FORGE-2075 URL: https://issues.jboss.org/browse/FORGE-2075 Project: Forge Issue Type: Feature Request Reporter: paolo antinori Priority: Minor As part of Camel addon we are trying to add this functionality: - offer the user the ability to add to the project a new Camel component(i.e. a .jar downloaded from Maven) taken from a predefined list - add it as a dependency to the project - generate various resources based on dynamic templates combined with the user choice To address the last of that list, I have to "consume" the artifact that has been added. And since there is no static metadata, I have to discover which of the classes that are in that .jar implements a specific interface, extends a class or is annotated in a specific way. It would be handy if there could be any helper class that behaves similarly to the {{JavaSourceFacet}} , offering facilities to inspect the classes contained in a .jar. Anything similar to the following snippet but applied on a {{.jar}} {code} project.getFacet(JavaSourceFacet.class).visitJavaSources( new JavaResourceVisitor() { @Override public void visit(VisitContext context, JavaResource javaResource) { try { JavaSource<?> javaType = javaResource.getJavaType(); if (javaType.isClass()) { JavaClassSource source = (JavaClassSource) javaType; if (source.hasAnnotation(org.apache.camel.cdi.ContextName.class) || source.hasAnnotation(org.apache.camel.cdi.Uri.class) ) { matched[0] = true; } } } catch (FileNotFoundException e) { e.printStackTrace(); } } }); {code} [~lincolnthree] pointed me to this example: https://github.com/forge/core/blob/master/database-tools/impl/src/main/ja... Which is exactly what I need, but it would turn out handy having helper methods and classes to keep the code simpler and symmetric to other interaction with Forge APIs -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2070) Forge Arquillian doesn't respect -Dmaven.repo.local=... in tests

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/FORGE-2070?page=com.atlassian.jira.plugin... ] Ondrej Zizka closed FORGE-2070. ------------------------------- Resolution: Duplicate Issue > Forge Arquillian doesn't respect -Dmaven.repo.local=... in tests > ---------------------------------------------------------------- > > Key: FORGE-2070 > URL: https://issues.jboss.org/browse/FORGE-2070 > Project: Forge > Issue Type: Bug > Affects Versions: 2.12.0.Final > Reporter: Ondrej Zizka > > When using -Dmaven.repo.local, Forge Arquillian doesn't respect that and the build fails with something like WINDUP-329: > [FATAL] Non-resolvable parent POM for org.jboss.windup:windup-parent:2.0.0-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:14 due to Could not find artifact org.jboss:jboss-parent:pom:14 and 'parent.relativePath' points at wrong local POM -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2070) Forge Arquillian doesn't respect -Dmaven.repo.local=... in tests

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/FORGE-2070?page=com.atlassian.jira.plugin... ] Ondrej Zizka commented on FORGE-2070: ------------------------------------- Duplicates FORGE-2062. > Forge Arquillian doesn't respect -Dmaven.repo.local=... in tests > ---------------------------------------------------------------- > > Key: FORGE-2070 > URL: https://issues.jboss.org/browse/FORGE-2070 > Project: Forge > Issue Type: Bug > Affects Versions: 2.12.0.Final > Reporter: Ondrej Zizka > > When using -Dmaven.repo.local, Forge Arquillian doesn't respect that and the build fails with something like WINDUP-329: > [FATAL] Non-resolvable parent POM for org.jboss.windup:windup-parent:2.0.0-SNAPSHOT: Failed to resolve POM for org.jboss:jboss-parent:14 due to Could not find artifact org.jboss:jboss-parent:pom:14 and 'parent.relativePath' points at wrong local POM -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed

by James Strachan (JIRA)

[ https://issues.jboss.org/browse/FORGE-2074?page=com.atlassian.jira.plugin... ] James Strachan updated FORGE-2074: ---------------------------------- Description: So Apache Karaf has a nice command "dev:watch *" http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them. It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell. Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool. e.g. a new command, something like... {code} addon-watch * {code} which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar was: So Apache Karaf has a nice command "dev:watch *" http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them. It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell. Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool > easy way to auto-reload addons being developed > ---------------------------------------------- > > Key: FORGE-2074 > URL: https://issues.jboss.org/browse/FORGE-2074 > Project: Forge > Issue Type: Feature Request > Reporter: James Strachan > > So Apache Karaf has a nice command "dev:watch *" > http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html > which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them. > It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell. > Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool. > e.g. a new command, something like... > {code} > addon-watch * > {code} > which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed

by James Strachan (JIRA)

James Strachan created FORGE-2074: ------------------------------------- Summary: easy way to auto-reload addons being developed Key: FORGE-2074 URL: https://issues.jboss.org/browse/FORGE-2074 Project: Forge Issue Type: Feature Request Reporter: James Strachan So Apache Karaf has a nice command "dev:watch *" http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them. It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell. Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2073) File input should be relative to current directory, not ${user.dir}

by Ondrej Zizka (JIRA)

Ondrej Zizka created FORGE-2073: ----------------------------------- Summary: File input should be relative to current directory, not ${user.dir} Key: FORGE-2073 URL: https://issues.jboss.org/browse/FORGE-2073 Project: Forge Issue Type: Enhancement Reporter: Ondrej Zizka Steps to reproduce: {code} cd myDir touch foo.ear forge cd .. windup-migrate-app myDir/foo.ear ***ERROR*** Input path does not exist windup-migrate-app foo.ear (this works...) {code} This is IMO illogical. The relative path should be relative to the directory of the shell. Currently it is relative to the directory where Forge was started. This i -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2072) Setting servletVersion to 3.1 generate as many <error-page> as entity scaffolds

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-2072: ---------------------------------------- Summary: Setting servletVersion to 3.1 generate as many <error-page> as entity scaffolds Key: FORGE-2072 URL: https://issues.jboss.org/browse/FORGE-2072 Project: Forge Issue Type: Bug Components: Java EE Affects Versions: 2.12.0.Final Reporter: Antonio Goncalves Fix For: 2.x Future Take the following scripts. It creates a project, sets up servlet version to 3.1, generates two entities and scaffolds them. {code} project-new --named testwebxml servlet-setup --servletVersion 3.1 jpa-new-entity --named Category ; jpa-new-field --named name --length 100 ; scaffold-generate --webRoot /admin --targets org.testwebxml.model.Category jpa-new-entity --named Publisher ; jpa-new-field --named name --length 30 ; scaffold-generate --webRoot /admin --targets org.testwebxml.model.Publisher {code} We end up with a {{web.xml}} file that has the {{<error-page>}} duplicated. In fact, Forge will duplicate this block each time we scaffold an entity. {code} <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.1" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"> <display-name>module07</display-name> <session-config> <session-timeout>30</session-timeout> </session-config> <mime-mapping> <extension>ico</extension> <mime-type>image/x-icon</mime-type> </mime-mapping> <error-page> <error-code>404</error-code> <location>/faces/error.xhtml</location> </error-page> <error-page> <error-code>500</error-code> <location>/faces/error.xhtml</location> </error-page> <context-param> <param-name>javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE</param-name> <param-value>true</param-value> </context-param> <error-page> <error-code>404</error-code> <location>/faces/error.xhtml</location> </error-page> <error-page> <error-code>500</error-code> <location>/faces/error.xhtml</location> </error-page> </web-app> {code} If you don't setup the servlet to 3.1 but leave the default (3.0) then it works fine, the {{<error-page>}} block is not duplicated -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (FORGE-2067) The java-new-field generates getters/setters even if --generateGetter and --generateSetter are set to false

by Ståle Pedersen (JIRA)

[ https://issues.jboss.org/browse/FORGE-2067?page=com.atlassian.jira.plugin... ] Ståle Pedersen commented on FORGE-2067: --------------------------------------- after a quick look its seems that forge is specifying if a field should have a value or not in æsh here; https://github.com/forge/core/blob/master/shell/impl/src/main/java/org/jb... (i might be wrong, but it looks like it) so either we can add another field called hasValue (or something) to WithAttributes where you can override the default behaviour thats currently in CommandLineUtil, or you can change the default behaviour. [~lincolnthree] [~gastaldi] wdyt? > The java-new-field generates getters/setters even if --generateGetter and --generateSetter are set to false > ----------------------------------------------------------------------------------------------------------- > > Key: FORGE-2067 > URL: https://issues.jboss.org/browse/FORGE-2067 > Project: Forge > Issue Type: Bug > Components: UI - Shell > Affects Versions: 2.12.0.Final > Reporter: Antonio Goncalves > Assignee: Ståle Pedersen > Fix For: 2.x Future > > > No matter if you set {{generateGetter}} or {{generateSetter}} to true or false, get/set are always generated. The following commands generate get/set (which is normal) : > {code} > java-new-class --named DatabaseProducer ; > java-new-field --named em --type javax.persistence.EntityManager ; > {code} > But the following command should not generate get/set : > {code} > java-new-class --named DatabaseProducer ; > java-new-field --named em --type javax.persistence.EntityManager --generateGetter false --generateSetter false ; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues October 2014