November 2011 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-93) AbstractResource.getFullyQualifiedName() returns wrong file path on Windows

by Richard Kennard (Reopened) (JIRA)

[ https://issues.jboss.org/browse/FORGE-93?page=com.atlassian.jira.plugin.s... ] Richard Kennard reopened FORGE-93: ---------------------------------- This issue has not been resolved on Windows. At the moment AbstractResource.getFullyQualifiedName does... return getParent() != null ? getParent().getFullyQualifiedName() + "/" + getName() : getName(); ...note the Unix-specific forward slash in there. This results in folders like... z:\/tmp/abstractshelltest3593945778774802366.tmp/test ...which Java manages to process but are generally invalid. I tried fixing it to use... return getParent() != null ? getParent().getFullyQualifiedName() + File.separator + getName() : getName(); ...but then I get... z:\\tmp\abstractshelltest1970534850818564205.tmp\test ...which is again invalid (should be z:\ not z:\\) and seems to break other parts of Forge > AbstractResource.getFullyQualifiedName() returns wrong file path on Windows > --------------------------------------------------------------------------- > > Key: FORGE-93 > URL: https://issues.jboss.org/browse/FORGE-93 > Project: Forge > Issue Type: Bug > Reporter: Liu Jianhong > Assignee: Lincoln Baxter III > Priority: Minor > Fix For: 1.0.0.Alpha4 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > 1,cd to C:\Users > 2,Get path use AbstractResource.getFullyQualifiedName() and it returns /Users > 3,Execute "cd /Users" produces error of "[cd] no such resources:Users" > So,the following test failed: > org.junit.ComparisonFailure: expected:</Users[/Administrator]> but was:</Users[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at org.junit.Assert.assertEquals(Assert.java:145) > at org.jboss.forge.shell.test.plugins.builtin.ChangeDirectoryPluginTest.testAbsolutePath(ChangeDirectoryPluginTest.java:137) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:251) > at org.jboss.arquillian.protocol.local.LocalMethodExecutor.invoke(LocalMethodExecutor.java:40) > at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:50) > at org.jboss.arquillian.impl.handler.ContainerTestExecuter.callback(ContainerTestExecuter.java:40) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:157) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:244) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:207) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:225) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:221) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:163) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (FORGE-374) CompiledTemplateResource should allow access to CompiledTemplate

by Richard Kennard (Created) (JIRA)

CompiledTemplateResource should allow access to CompiledTemplate ---------------------------------------------------------------- Key: FORGE-374 URL: https://issues.jboss.org/browse/FORGE-374 Project: Forge Issue Type: Feature Request Reporter: Richard Kennard Assignee: Lincoln Baxter III Hi guys, It would be really handy if CompiledTemplateResource had some kind of 'getCompiledTemplate' method. At the moment it just keeps this internally. My use case is: I need to be able to compile a template *and* parse it for certain contents. At the moment this means I have to do it twice: this.viewTemplate = this.compiler.compile(VIEW_TEMPLATE); NamespacesAndIndent namespacesAndIndent = parseNamespacesAndIndent(this.compiler .getTemplateResolverFactory() .resolve(VIEW_TEMPLATE).getInputStream()); If I could get to the actual CompiledTemplate, then CompiledTemplate.getRoot() and CompiledTemplate.getTemplate() have already been parsed for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
3
0 / 0

[JBoss JIRA] (FORGE-383) Ability to set up a technology stack

by Pete Muir (Created) (JIRA)

Ability to set up a technology stack ------------------------------------ Key: FORGE-383 URL: https://issues.jboss.org/browse/FORGE-383 Project: Forge Issue Type: Feature Request Affects Versions: 1.0.0.Beta3 Reporter: Pete Muir Assignee: Lincoln Baxter III For example setup JavaEE_Web_Profile -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[JBoss JIRA] (FORGE-363) Pressing Ctrl+C should abort current task

by Hendy Irawan (Created) (JIRA)

Pressing Ctrl+C should abort current task ----------------------------------------- Key: FORGE-363 URL: https://issues.jboss.org/browse/FORGE-363 Project: Forge Issue Type: Bug Components: Shell Affects Versions: 1.0.0.Beta3 Environment: Linux Reporter: Hendy Irawan Assignee: Lincoln Baxter III While pressing Ctrl+D works, it should (also) respond to Ctrl+C. {code} [ecommerce] ecommerce $ new-project --help ***INFO*** The command [new-project] takes [0] unnamed argument(s), but found [1]. ***INFO*** Swallowed unknown token [--help] for command [new-project]. ? [named=The name of the new project (of type java.lang.String)]: ^C ? [named=The name of the new project (of type java.lang.String)]: ***INFO*** Aborted. {code} I would say that the absence of "--help" as a synonym for "help <cmd>" is also a bug, let me know if you agree with me and I'll file another issue for that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[JBoss JIRA] (FORGE-137) Add explode and deploy goals to pom.xml during scaffold generation

by Lincoln Baxter III (Commented) (JIRA)

[ https://issues.jboss.org/browse/FORGE-137?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III commented on FORGE-137: ------------------------------------------ Hmmm, actually. If we do FORGE-194, do you think this is necessary? Would that be a solution that meets your use case? Also, the "as7 deploy" command now supports "as7 deployExploded". There's also FORGE-256 which is related to this I think. So many people asking for different things! Do all? One? Some? > Add explode and deploy goals to pom.xml during scaffold generation > ------------------------------------------------------------------ > > Key: FORGE-137 > URL: https://issues.jboss.org/browse/FORGE-137 > Project: Forge > Issue Type: Enhancement > Components: Forge Build, Maven Integration > Environment: JBoss 7, JBoss 6, Glassfish 3.1 > Reporter: Kevin Sapper > > Hi Guys, > One of the most compelling features about seam-gen is that after you've build the projects scaffold deploying and exploding to an application server just goes by calling an ant target. It really would be nice to have such a goal in the projects pom.xml after creating the scaffold and boilerplate code. Adding that functionality yourself really takes an awful lot of time. Especially with glassfish 3.1 I failed to accomplish that task. > Best regards//Kevin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (FORGE-161) AS7 deploy plugin should have dist as dependency to prevent requirement for JBOSS_HOME

by Lincoln Baxter III (Closed) (JIRA)

[ https://issues.jboss.org/browse/FORGE-161?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-161. ------------------------------------ Resolution: Duplicate Issue > AS7 deploy plugin should have dist as dependency to prevent requirement for JBOSS_HOME > -------------------------------------------------------------------------------------- > > Key: FORGE-161 > URL: https://issues.jboss.org/browse/FORGE-161 > Project: Forge > Issue Type: Enhancement > Components: Blessed Plugins > Affects Versions: 1.0.0.Alpha4 > Reporter: Ken Finnigan > > To remove the need for users to specify JBOSS_HOME when running the AS7 deploy plugin on forge you could add the following Maven plugin: > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-dependency-plugin</artifactId> > <executions> > <execution> > <id>unpack-as7</id> > <phase>process-test-classes</phase>  > <goals> > <goal>unpack</goal> > </goals> > <configuration> > <artifactItems> > <artifactItem> > <groupId>org.jboss.as</groupId> > <artifactId>jboss-as-dist</artifactId> > <version>7.0.0.Final</version> > <type>zip</type> > <overWrite>false</overWrite> > <outputDirectory>${project.build.directory}</outputDirectory> > </artifactItem> > </artifactItems> > </configuration> > </execution> > </executions> > </plugin> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (FORGE-143) Create some base classes for plugin development

by Lincoln Baxter III (Closed) (JIRA)

[ https://issues.jboss.org/browse/FORGE-143?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III closed FORGE-143. ------------------------------------ Resolution: Incomplete Description Sounds like a docs problem. We have a separate issue for updating the docs. > Create some base classes for plugin development > ----------------------------------------------- > > Key: FORGE-143 > URL: https://issues.jboss.org/browse/FORGE-143 > Project: Forge > Issue Type: Enhancement > Components: Plugin API > Affects Versions: 1.0.0.Alpha4 > Reporter: Jason Porter > Priority: Minor > > There are some core actions a plugin that creates Java classes must do, such as get the current package. Actions like this should be on an abstract base class such as JavaSourceCreationPluginBase (maybe something shorter?) which would also implement Plugin (so we don't break existing plugins) that will have these methods baked in so each plugin doesn't end up copying the code from somewhere else. If Java had mixins this would be a perfect fit, alas, it does not and we're stuck with something else. > The class would probably have to have some abstract getter methods that the subclass would have to implement to get common things like the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (FORGE-143) Create some base classes for plugin development

by Lincoln Baxter III (Commented) (JIRA)

[ https://issues.jboss.org/browse/FORGE-143?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III commented on FORGE-143: ------------------------------------------ If there are specific APIs you think that should be added. Go ahead and open up issues for them individually (or grouped by facet). Thanks! > Create some base classes for plugin development > ----------------------------------------------- > > Key: FORGE-143 > URL: https://issues.jboss.org/browse/FORGE-143 > Project: Forge > Issue Type: Enhancement > Components: Plugin API > Affects Versions: 1.0.0.Alpha4 > Reporter: Jason Porter > Priority: Minor > > There are some core actions a plugin that creates Java classes must do, such as get the current package. Actions like this should be on an abstract base class such as JavaSourceCreationPluginBase (maybe something shorter?) which would also implement Plugin (so we don't break existing plugins) that will have these methods baked in so each plugin doesn't end up copying the code from somewhere else. If Java had mixins this would be a perfect fit, alas, it does not and we're stuck with something else. > The class would probably have to have some abstract getter methods that the subclass would have to implement to get common things like the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (FORGE-365) forge:list-plugins "no such command"

by Burr Sutter (Created) (JIRA)

forge:list-plugins "no such command" ------------------------------------ Key: FORGE-365 URL: https://issues.jboss.org/browse/FORGE-365 Project: Forge Issue Type: Bug Reporter: Burr Sutter Assignee: Lincoln Baxter III list-commands says that "forge:list-plugins" is a valid command (see screenshot). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
2
0 / 0

[JBoss JIRA] (FORGE-375) There is invalid check in RestPlugin install method

by Doychin Bondzhev (Created) (JIRA)

There is invalid check in RestPlugin install method --------------------------------------------------- Key: FORGE-375 URL: https://issues.jboss.org/browse/FORGE-375 Project: Forge Issue Type: Bug Components: Builtin Plugins Affects Versions: 1.0.0.Beta3 Reporter: Doychin Bondzhev Assignee: Lincoln Baxter III /* * Make sure we have all the features we need for this to work. */ if (!project.hasAllFacets(Arrays.asList(CDIFacet.class, PersistenceFacet.class))) { request.fire(new InstallFacets(true, EJBFacet.class, PersistenceFacet.class)); } In the code above you see that there is difference between checked facets and installed facets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues November 2011