[JBoss JIRA] Created: (SEAMFORGE-140) FSHParser is too agressive (destroys command input)
by Lincoln Baxter III (JIRA)
FSHParser is too agressive (destroys command input)
---------------------------------------------------
Key: SEAMFORGE-140
URL: https://issues.jboss.org/browse/SEAMFORGE-140
Project: Seam Forge
Issue Type: Bug
Components: Shell
Affects Versions: 1.0.0.Alpha3
Reporter: Lincoln Baxter III
Assignee: Christopher Brock
FSHParser is breaking up statements that clearly are not scripts:
[example] Customer.java $ prettyfaces mapping --resource /scaffold/customer/view.xhtml --pattern /customer/#{id} --id viewCustomer
***INFO*** The command [mapping] takes [0] unnamed argument(s), but found [1].
***INFO*** Swallowed unknown token [{] for command [mapping].
***INFO*** Swallowed unknown token [id] for command [mapping].
***INFO*** Swallowed unknown token [}] for command [mapping].
***ERROR*** [prettyfaces mapping] Pattern is already mapped by the UrlMapping [ id=viewCustomer, pattern=/customer/#, parentId=, viewId=/scaffold/customer/view.xhtml, actions=[], outbound=true, parser=null, pathValidators=[], queryParams=[]]
[example] Customer.java $
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
Re: [forge-dev] Fw: Re: Mojavelinux.com Feedback: seam-gen and cdi/weld
by Rodney Russ
----- "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com> wrote:
> From: "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
> To: "brian long" <brian.long(a)vt.edu>
> Cc: "brian" <brianx(a)vt.edu>, "forge-dev List" <forge-dev(a)lists.jboss.org>, "John du Clos" <duclosjj(a)yahoo.com>
> Sent: Friday, April 15, 2011 1:14:38 PM GMT -07:00 US/Canada Mountain
> Subject: Re: [forge-dev] Fw: Re: Mojavelinux.com Feedback: seam-gen and cdi/weld
>
> My suggestion for reading persistence XML is to use the
> PersistenceFacet:
>
> Facets are how plugins interact with pieces of the underlying project:
>
> project.getFacet(PersistenceFacet.class).getConfig();
>
> (this will blow up if persistence is not installed, so you need to
> first call (project.hasFacet(PersistenceFacet.class))
Why couldn't you use: @RequiresFacet(PersistenceFacet.class)
>
> ~Lincoln
>
>
> On Fri, Apr 15, 2011 at 12:55 PM, brian < brianx(a)vt.edu > wrote:
>
>
>
> hi L3 and john.
>
> I was thinking about the persistence.xml. Would using piping make
> sense
> to read/parse the fields from the persistence.xml and then pass them
> to
> GenerateEntities?
>
> so "read-persistence | generate-entities" ?
>
> ...I'm not sure if a plugin can read a file, but if it could, a little
> file-reader/parser might work?
>
>
>
> On Fri, 2011-04-15 at 12:04 -0400, Lincoln Baxter, III wrote:
> > Hi John!
> >
> > Thank you for your interest! I think it's fair to say that we are
> > "close" to having a fully-functional database reverse-engineering
> > plugin, but we are not there yet. Brian (ccd) has been doing some
> work
> > recently (when he has time) to get Max Andersen's prototype up and
> > running. The prototype is here, but has a few shortcomings:
> >
> > https://github.com/forge/plugin-hibernate-tools
> > 1. Connection settings are hardcoded
> > 2. JDBC drivers are not included with the plugin
> > 3. Does not take persistence.xml into account, if it exists
>
>
>
> > In short, it works, but is not usable yet; however, these are all
> > things that can be worked on if you are interested! And I would be
> > more than happy to help you get together with Brian and get two
> brains
> > working on this! Would you be intersted in that?
> >
> > No matter your level of commitment, I would recommend joining the
> dev
> > and users lists:
> > * https://lists.jboss.org/mailman/listinfo/forge-dev
> > * https://lists.jboss.org/mailman/listinfo/forge-users
> > Just let me know and I'll get you all the info that you'll need :)
> > ~Lincoln
> >
> > On Thu, Mar 17, 2011 at 8:57 PM, John du Clos < duclosjj(a)yahoo.com >
> > wrote:
> > Hi Lincoln-
> >
> > I was chatting with Dan Allen and he mentioned you are working
> > on Forge and specifically the reverse engineering feature from
> > the database. I wanted to reach out to you to see if you have
> > any early versions you need testers to help you verify this
> > feature.
> >
> > I look forward to hearing from you!
> > John
> >
> > --- On Wed, 3/16/11, Dan Allen < dan.j.allen(a)gmail.com > wrote:
> >
> >
> > From: Dan Allen < dan.j.allen(a)gmail.com >
> > Subject: Re: Mojavelinux.com Feedback: seam-gen and
> > cdi/weld
> > To: duclosjj(a)yahoo.com
> > Date: Wednesday, March 16, 2011, 9:33 PM
> >
> > Hey John,
> > Thanks for reading the book. I'm glad it helped you
> > along. I know about those painful days of J2EE you are
> > talking about.
> > The best way to get started atm is using the Maven
> > archetype.
> > http://tinyurl.com/gojavaee
> > That gives you a starter project. We don't yet have
> > the reverse engineering yet for this environment. That
> > what Forge will offer soon. Check out the issue
> > tracker or mailing list for updates.
> > Hope that gets you started. Cheers,
> > - Dan Allen
> > Sent from my Android-powered phone:
> > An open platform for carriers, consumers and
> > developers
> > On Mar 16, 2011 9:04 PM, < duclosjj(a)yahoo.com > wrote:
> > > Submitted by: John duClos < duclosjj(a)yahoo.com > on
> > Wednesday, March 16th, 2011 @ 9:04:25 pm (-0400)
> > >
> > > Online Form Fields
> > > ------------------
> > >
> > > Url:
> > >
> > >
> > > Message:
> > > Dan-
> > >
> > > I purchased your Seam book when it was published and
> > am a supporter of
> > > the Seam framework since I lived the challenging
> > days of early J2EE
> > > development.
> > >
> > > I work with database centric solutions and seam-gen
> > allowed me to
> > > develop solutions in record time by getting my
> > project started very
> > > quickly. I'd like to start implementing JEE 6/CDI
> > with JBoss AS 6, but
> > > I can't seem to find a way to issue the seam-gen
> > command.
> > >
> > > I looked at Forge but that is not where seam-gem
> > was. Do you know of a
> > > valid seam-gen solution for JEE 6/CDI based projects
> > (Seam 3).
> > >
> > > Thanks,
> > > John
> > >
> > > Client Variables
> > > ----------------
> > >
> > > HTTP_USER_AGENT:
> > > Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0;
> > Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR
> > 3.5.21022; .NET CLR 3.5.30729; MDDS; .NET CLR
> > 3.0.30729; MS-RTC LM 8; AskTB5.4)
> > >
> > >
> >
> >
> >
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.com
> > http://scrumshark.com
> > "Keep it Simple"
>
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
13 years, 7 months
Re: [forge-dev] [forge-users] Problems with scaffolding
by Lincoln Baxter, III
Brian,
Sorry for the late reply. Yeah everything is OK, just really busy and a bit
stressed :) How are things on your end?
Re-adding the dev list so that Max and others will see.
To answer your questions, see responses inline.
***ERROR*** [generate-entities] 'hibernate.dialect' must be set when no
> Connection available
>
Not sure what this is about. It seems that some hibernate configuration
properties need to be set somehow, Max?
> ... i did 'project add-dependency
> org.hibernate:hibernate-tools:3.4.0.CR2-SNAPSHOT'
>
> i also modified my persistence.xml by hand.
>
> neither seems to make much difference. have rebuilt in forge and
> generate-entities is complaining about 'no connection available.'
>
The generate-entities command is not aware of persistence.xml (unless you
did something to improve that.) It would certainly be nice, and even nicer
if it would even talk to the appserver through JNDI, but as Max said, he had
hard-coded all the connection properties in his initial effort. This is
something that will need to be A. fixed, or B. worked around.
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 7 months
[JBoss JIRA] Created: (SEAMFORGE-48) Implicit navigation cases on scaffolded views is not functioning
by Lincoln Baxter III (JIRA)
Implicit navigation cases on scaffolded views is not functioning
----------------------------------------------------------------
Key: SEAMFORGE-48
URL: https://issues.jboss.org/browse/SEAMFORGE-48
Project: Seam Forge
Issue Type: Bug
Components: Builtin Plugins
Affects Versions: 1.0.0.Alpha2
Reporter: Lincoln Baxter III
14:41:08,439 WARNING [javax.enterprise.resource.webcontainer.jsf.context] JSF1091: No mime type could be found for file favicon.ico. To resolve this, add a mime-type mapping to the applications web.xml.
14:41:08,440 WARNING [javax.enterprise.resource.webcontainer.jsf.renderkit] JSF1090: Navigation case not resolved for component j_idt9.
14:41:08,452 WARN [org.jboss.weld.integration.ejb.JBossSessionObjectReference] Cannot remove EJB, id unknown (likely because this is a no-interface view!)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (SEAMFORGE-111) Prompt for finalName when creating project, or default to project name
by Dan Allen (JIRA)
Prompt for finalName when creating project, or default to project name
----------------------------------------------------------------------
Key: SEAMFORGE-111
URL: https://issues.jboss.org/browse/SEAMFORGE-111
Project: Seam Forge
Issue Type: Enhancement
Components: Builtin Plugins
Affects Versions: 1.0.0.Alpha3
Reporter: Dan Allen
Priority: Minor
Currently forge does not set the finalName of the project. In a WAR project, it's common to exclude the version from the generated war, which is done by setting the finalName as follows:
{code:xml}
<build>
<finalName>${project.artifactId}</finalName>
</build>
{code}
This should either be the default in forge, or forge should prompt the user for a name when switching to a war project (informing them that this name will be the name of the generated war).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (SEAMFORGE-134) IOException: Could not delete file /tmp/forgetemp...
by Brian Leathem (JIRA)
IOException: Could not delete file /tmp/forgetemp...
----------------------------------------------------
Key: SEAMFORGE-134
URL: https://issues.jboss.org/browse/SEAMFORGE-134
Project: Seam Forge
Issue Type: Bug
Components: Plugin API
Affects Versions: 1.0.0.Alpha3
Environment: Linux (fedora 12), Sun jvm 1.6.0_20
Reporter: Brian Leathem
Trying to install a plugin from a git repositoy, with the command:
forge git-plugin git://github.com/bleathem/richfaces-forge-plugin.git
I get the error:
***ERROR*** [forge git-plugin] Could not delete file /tmp/forgetemp4740532537388554878/repo/.git/objects/incoming_7012870980931945616.idx
Setting VERBOSE = true I get the stack trace:
org.jboss.seam.forge.shell.exceptions.CommandExecutionException: Could not delete file /tmp/forgetemp4740532537388554878/repo/.git/objects/incoming_7012870980931945616.idx
at org.jboss.seam.forge.shell.command.Execution.perform(Execution.java:143)
at org.jboss.seam.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:125)
at org.jboss.seam.forge.shell.command.fshparser.FSHRuntime.run(FSHRuntime.java:63)
at org.jboss.seam.forge.shell.ShellImpl.execute(ShellImpl.java:677)
at org.jboss.seam.forge.shell.ShellImpl.doShell(ShellImpl.java:493)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:48)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.seam.forge.shell.org$jboss$weld$bean-classpath-ManagedBean-class_org$jboss$seam$forge$shell$ShellImpl_$$_WeldClientProxy.doShell(org$jboss$weld$bean-classpath-ManagedBean-class_org$jboss$seam$forge$shell$ShellImpl_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at org.jboss.seam.forge.shell.Bootstrap$2.run(Bootstrap.java:92)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.seam.forge.shell.command.Execution.perform(Execution.java:139)
... 30 more
Caused by: org.eclipse.jgit.errors.TransportException: Could not delete file /tmp/forgetemp4740532537388554878/repo/.git/objects/incoming_7012870980931945616.idx
at org.eclipse.jgit.transport.BasePackFetchConnection.doFetch(BasePackFetchConnection.java:286)
at org.eclipse.jgit.transport.BasePackFetchConnection.fetch(BasePackFetchConnection.java:224)
at org.eclipse.jgit.transport.FetchProcess.fetchObjects(FetchProcess.java:214)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:149)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:111)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:904)
at org.jboss.seam.forge.git.Clone.runFetch(Clone.java:130)
at org.jboss.seam.forge.git.Clone.run(Clone.java:99)
at org.jboss.seam.forge.git.GitUtils.clone(GitUti
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Commented: (SEAMFORGE-3) Create project from Maven archetype
by Dan Allen (JIRA)
[ https://issues.jboss.org/browse/SEAMFORGE-3?page=com.atlassian.jira.plugi... ]
Dan Allen commented on SEAMFORGE-3:
-----------------------------------
Fantastic. Keep in mind that archetypes are very much a means to an end. What I'm most interested in is the end. The end is having a ready-made project for experimenting with CDI, JPA, JSF, JAX-RS, Bean Validation, EJB-lite and Arquillian. In fact, having to maintain the archetypes using a reverse engineering of the project is a real pain. Hopefully the helps give you an idea of where to place focus.
I should also mention that the archetypes have been extremely popular in trainings because minimal effort gives students a lot of early success.
> Create project from Maven archetype
> -----------------------------------
>
> Key: SEAMFORGE-3
> URL: https://issues.jboss.org/browse/SEAMFORGE-3
> Project: Seam Forge
> Issue Type: Feature Request
> Reporter: Dan Allen
> Assignee: Rodney Russ
> Priority: Minor
>
> Since the catalog of Maven archetypes is substantial, and the archetype plugin interface is so abysmal, Forge could benefit from being a stand-in replacement to archetype:generate. A command in Forge to create a new project from a Maven archetype would certainly offer a nice complement to the more basic "new-project" command. It could just be an additional flag to the new-project command, such as:
> new-project --named MyProject --fromArchetype org.jboss.weld.archetypes:jboss-javaee6-webapp
> Using the interactive prompts, you may be able to provide a list of archetypes, perhaps w/ a filtering mechanism. You could also just do a best guess based on what's found in the catalog.
> new-project --named MyProject --fromArchetype jboss-javaee6-webapp
> You could just delegate to Maven by building up the "mvn archetype:generate" command from Forge. Long term we could consider emulating the archetype:generate plugin so as just to consume the projects that are out there already w/o any linkage to Maven.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months