[JBoss JIRA] (FORGE-2184) GenerateDot fails with Maven 3.2.5: NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/FORGE-2184?page=com.atlassian.jira.plugin... ]
Ondrej Zizka reopened FORGE-2184:
---------------------------------
George, I am seeing this again.
$ mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /home/ondra/sw/prog/maven/3.2.5
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: "unix"
> GenerateDot fails with Maven 3.2.5: NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
> ---------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2184
> URL: https://issues.jboss.org/browse/FORGE-2184
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 2.12.1.Final
> Reporter: Ondrej Zizka
> Assignee: George Gastaldi
> Fix For: 2.14.0.Final
>
>
> STR:
> Use Maven 3.2.5 and run the generate-dot goal on anything.
> Should give you:
> {code}
> --- furnace-maven-plugin:2.12.1.Final:generate-dot (generate-dot) @ windup-victims ---
> Generating /home/ondra/work/Migration/WindupQuickstarts/victi.ms/target/classes/META-INF/resources/windup-victims-2.0.0-SNAPSHOT.dot
> Exception in thread "pool-5-thread-1" Exception in thread "pool-6-thread-1" Exception in thread "DefaultMetadataResolver-3-1" Exception in thread "DefaultMetadataResolver-3-0" java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
> at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
> at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.spi.connector.Transfer$State
> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 5 more
> java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
> at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.spi.connector.Transfer$State
> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 5 more
> java.lang.NoClassDefFoundError: org/eclipse/aether/spi/connector/Transfer$State
> at org.eclipse.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGEPLUGINS-194) Being able to create an Arquillian test as a client
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGEPLUGINS-194:
----------------------------------------------
Summary: Being able to create an Arquillian test as a client
Key: FORGEPLUGINS-194
URL: https://issues.jboss.org/browse/FORGEPLUGINS-194
Project: Forge Plugins/Addons
Issue Type: Feature Request
Components: Arquillian Plugin
Reporter: Antonio Goncalves
Assignee: Aslak Knutsen
It would be good to be able to create client tests with Arquillian. At the moment, to test a REST endpoint we get the following :
{code}
arquillian-create-test --targets CategoryEndpoint
@RunWith(Arquillian.class)
public class CategoryEndpointTest
{
@Inject
private CategoryEndpoint categoryendpoint;
@Deployment
public static JavaArchive createDeployment()
{
return ShrinkWrap.create(JavaArchive.class)
.addClass(CategoryEndpoint.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Test
public void should_be_deployed()
{
Assert.assertNotNull(categoryendpoint);
}
}
{code}
But what would be nice is to have a {{runAsWebClient}} parameter that would create a test case with an {{ArquillianResource}} and a {{RunAsClient}} such as :
{code}
@RunWith(Arquillian.class)
@RunAsClient
public class CategoryEndpointTest
{
@ArquillianResource
private URI baseURL;
@Deployment(testable = false)
public static WebArchive createDeployment()
{
return ShrinkWrap.create(WebArchive.class)
.addClass(CategoryEndpoint.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Test
public void should_be_deployed()
{
Assert.assertNotNull(baseURL);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2374) Being able to generate an abstract or final Java class
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2374:
----------------------------------------
Summary: Being able to generate an abstract or final Java class
Key: FORGE-2374
URL: https://issues.jboss.org/browse/FORGE-2374
Project: Forge
Issue Type: Sub-task
Components: UI - API
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
At the moment the {{java-new-class}} only has a {{targetPackage}} and {{named}} parameter. It would be good to be able to generate abstract or final classes
{code}
$ java-new-class --named MyClass --isAbstract
public abstract class MyClass {
}
{code}
Or final :
{code}
$ java-new-class --named MyClass --isFinal
public final class MyClass {
}
{code}
What we have to be careful is that a class cannot be abstract and final. So the following is illegal :
{code}
$ java-new-class --named MyClass --isFinal --isAbstract
public final abstract class MyClass {
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2373) jpa-new-entity should be able to use caching
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2373:
----------------------------------------
Summary: jpa-new-entity should be able to use caching
Key: FORGE-2373
URL: https://issues.jboss.org/browse/FORGE-2373
Project: Forge
Issue Type: Sub-task
Components: Java EE
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
It would be good to enable second level cache in an Entity. Something like adding an extra parameter to the {{jpa-new-entity}} command :
{code}
jpa-new-entity --named MyEntity --isCacheable
{code}
This would generate the following with the {{javax.persistence.Cacheable}} annotation :
{code}
@Cacheable
@Entity
public class Book implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "id", updatable = false, nullable = false)
private Long id;
@Version
@Column(name = "version")
private int version;
// ...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2372) The scaffold provider should be mandatory when there are more than one
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2372:
----------------------------------------
Summary: The scaffold provider should be mandatory when there are more than one
Key: FORGE-2372
URL: https://issues.jboss.org/browse/FORGE-2372
Project: Forge
Issue Type: Sub-task
Components: Scaffold
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
After installing a few addons, including Angular, I use the {{scaffold-generate}} command thinking that it would use Faces, but it generates an Angular app. In this cas, the {{provider}} attribute should become mandatory .
{code}
$ scaffold-generate
--provider --webRoot --targets --generateRestResources
{code}
Script that reproduces it :
{code}
$ addon-list
org.jboss.forge.addon:angularjs,2.1.5-SNAPSHOT
org.jboss.forge.addon:scaffold,2.16.1.Final
org.jboss.forge.addon:scaffold-faces,2.16.1.Final
org.jboss.forge.addon:scaffold-spi,2.16.1.Final
$ project-new --named demo
$ jpa-new-entity --named MyEntity
$ scaffold-generate --targets org.demo.model.MyEntity
***SUCCESS*** CDI has been installed.
***SUCCESS*** EJB has been installed.
***SUCCESS*** Servlet API has been installed.
***SUCCESS*** JAX-RS has been installed.
***SUCCESS*** Scaffold was generated successfully.
{code}
A {{RestApplication}} class is generated,
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2371) Use <h:graphicImage> instead of <img> in JSF scaffolding
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2371:
----------------------------------------
Summary: Use <h:graphicImage> instead of <img> in JSF scaffolding
Key: FORGE-2371
URL: https://issues.jboss.org/browse/FORGE-2371
Project: Forge
Issue Type: Sub-task
Components: Scaffold
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
In the JSF scaffolding, it would be better to use the JSF <h:graphicImage> instead of <img> (to have a more JSF consistent code). There are two pages that would need to get changed :
In the {{pageTemplate.xhtml}}, we should replace
{code}
<img src='#{resource["forge-logo.png"]}' alt="Forge... get hammered" border="0" />
{code}
With :
{code}
<h:graphicImage value="#{resource['forge-logo.png']}" alt="Forge... get hammered" border="0" />
{code}
In the {{error.xhtml}}, we should replace
{code}
<img src='#{resource["jboss-community.png"]}' alt="JBoss and JBoss Community" width="254" height="31" border="0" />
{code}
With :
{code}
<h:graphicImage value="#{resource['jboss-community.png']}" alt="JBoss and JBoss Community" width="254" height="31" border="0" />
{code}
Add add {{xmlns:h="http://java.sun.com/jsf/html"}} to the namespaces.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2370) Being able to create a new HTML Page
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2370:
----------------------------------------
Summary: Being able to create a new HTML Page
Key: FORGE-2370
URL: https://issues.jboss.org/browse/FORGE-2370
Project: Forge
Issue Type: Sub-task
Components: Java EE
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
At the moment the only way to generate HTML pages is with scaffolding. It would be good to have a separate command to create HTML pages. Commands such as :
{code}
html-new-page --named mypage
{code}
This will create a mypage.html on the root of the webapp directory. You could also give a different directory with :
{code}
html-new-page --named mypage --targetDirectory admin
{code}
This will create the page under webapp/admin/mypage.html.
{code}
<!DOCTYPE HTML>
<html>
<head>
<title>mypage</title>
</head>
<body>
<h1>mypage</h1>
</body>
</html>
{code}
The name of the page {{mypage}} is used for the title but we could customize it :
{code}
html-new-page --named mypage --title Administration Page
{code}
It would just generate the following HTML page :
{code}
<!DOCTYPE HTML>
<html>
<head>
<title>Administration Page</title>
</head>
<body>
<h1>Administration Page</h1>
</body>
</html>
{code}
If the page needs to be included in the {{welcome-file-list}} in the {{web.xml}} we could :
{code}
html-new-page --named mypage --isWelcomePage
html-new-page --named mypage2 --isWelcomePage
{code}
{code}
<web-app>
<welcome-file-list>
<welcome-file>mypage.html</welcome-file>
<welcome-file>mypage2.html</welcome-file>
</welcome-file-list>
</web-app>
{code}
If we want a page that redirects to somewhere else, we just type :
{code}
html-new-page --named mypage --redirectsTo ./faces/index.xhtml
{code}
{code}
<!DOCTYPE HTML>
<meta http-equiv="refresh" content="0;url=./faces/index.xhtml" />
<html>
<head>
<title>mypage</title>
</head>
<body>
<h1>mypage</h1>
</body>
</html>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2369) In commands there are several targetXXX attributes, some are confusing
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2369?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2369:
-------------------------------------
Description:
At the moment commands deal with different {{targetXXX}} attributes. Some are easy to understand but some are confusing. We have :
* {{targetClass}} : this mostly targets a Java class
* {{targetDirectory}} : used in {{GitCloneCommand}}, for example, but also in {{NewEJBCommand}} or {{FacesNewBean}} (which relate to Java code and should then be {{targetPackage}})
* {{targetEJB}} : used in {{EJBSetClassTransactionAttributeCommand}}, it should just be {{targetClass}} that filter EJBs
* {{targetEntity}} : used in {{JPANewFieldWizard}} or {{JPANewNamedQueryCommand}}, it should just be {{targetClass}} that filter Entities
* {{targetFolder}} : used in {{CopyCommand}} and {{MoveCommand}} but is fine like that because this parameter is not visible to the user
* {{targetLocation}} : is mostly used when a project doesn't exist, but it is also used in {{JPANewEntityCommand}}
* {{targetPackage}} : for a Java class
* {{targetResource}} : used in {{CopyCommand}} and {{MoveCommand}} but it's not visible for the user
* {{targetSuperClass}} : used in {{JavaNewMethodCommand}} to target the super class, as there is already a {{targetClass}} attribute, but it should maybe be {{type}}
* {{targetTypes}} : used in {{CDINewStereotype}} command, it should be {{types}} like most commands
was:
At the moment commands deal with different {{targetXXX}} attributes. Some are easy to understand but some are confusing. We have :
* {{targetClass}} : this mostly targets a Java class
* {{targetDirectory}} : used in {{GitCloneCommand}}, for example, but also in {{NewEJBCommand}} or {{FacesNewBean}} (which relate to Java code and should then be {{targetPackage}})
* {{targetEJB}} : used in {{EJBSetClassTransactionAttributeCommand}}, it should just be {{targetClass}} that filter EJBs
* {{targetEntity}} : used in {{JPANewFieldWizard}} or {{JPANewNamedQueryCommand}}, it should just be {{targetClass}} that filter Entities
* {{targetFolder}} : used in {{CopyCommand}} and {{MoveCommand}} but is fine like that because this parameter is not visible to the user
* {{targetLocation}} : is mostly used when a project doesn't exist, but it is also used in {{JPANewEntityCommand}}
* {{targetPackage}} : for a Java class
* {{targetResource}} : used in {{CopyCommand}} and {{MoveCommand}} but it's not visible for the user
* {{targetSuperClass}} : used in {{JavaNewMethodCommand}} to target the super class, as there is already a {{targetClass}} attribute
* {{targetTypes}} : used in {{CDINewStereotype}} command, it should be {{types}} like most commands
> In commands there are several targetXXX attributes, some are confusing
> ----------------------------------------------------------------------
>
> Key: FORGE-2369
> URL: https://issues.jboss.org/browse/FORGE-2369
> Project: Forge
> Issue Type: Sub-task
> Components: UI - API
> Affects Versions: 2.16.2.Final
> Reporter: Antonio Goncalves
>
> At the moment commands deal with different {{targetXXX}} attributes. Some are easy to understand but some are confusing. We have :
> * {{targetClass}} : this mostly targets a Java class
> * {{targetDirectory}} : used in {{GitCloneCommand}}, for example, but also in {{NewEJBCommand}} or {{FacesNewBean}} (which relate to Java code and should then be {{targetPackage}})
> * {{targetEJB}} : used in {{EJBSetClassTransactionAttributeCommand}}, it should just be {{targetClass}} that filter EJBs
> * {{targetEntity}} : used in {{JPANewFieldWizard}} or {{JPANewNamedQueryCommand}}, it should just be {{targetClass}} that filter Entities
> * {{targetFolder}} : used in {{CopyCommand}} and {{MoveCommand}} but is fine like that because this parameter is not visible to the user
> * {{targetLocation}} : is mostly used when a project doesn't exist, but it is also used in {{JPANewEntityCommand}}
> * {{targetPackage}} : for a Java class
> * {{targetResource}} : used in {{CopyCommand}} and {{MoveCommand}} but it's not visible for the user
> * {{targetSuperClass}} : used in {{JavaNewMethodCommand}} to target the super class, as there is already a {{targetClass}} attribute, but it should maybe be {{type}}
> * {{targetTypes}} : used in {{CDINewStereotype}} command, it should be {{types}} like most commands
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2369) In commands there are several targetXXX attributes, some are confusing
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2369?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2369:
-------------------------------------
Parent: FORGE-1926
Issue Type: Sub-task (was: Enhancement)
> In commands there are several targetXXX attributes, some are confusing
> ----------------------------------------------------------------------
>
> Key: FORGE-2369
> URL: https://issues.jboss.org/browse/FORGE-2369
> Project: Forge
> Issue Type: Sub-task
> Components: UI - API
> Affects Versions: 2.16.2.Final
> Reporter: Antonio Goncalves
>
> At the moment commands deal with different {{targetXXX}} attributes. Some are easy to understand but some are confusing. We have :
> * {{targetClass}} : this mostly targets a Java class
> * {{targetDirectory}} : used in {{GitCloneCommand}}, for example, but also in {{NewEJBCommand}} or {{FacesNewBean}} (which relate to Java code and should then be {{targetPackage}})
> * {{targetEJB}} : used in {{EJBSetClassTransactionAttributeCommand}}, it should just be {{targetClass}} that filter EJBs
> * {{targetEntity}} : used in {{JPANewFieldWizard}} or {{JPANewNamedQueryCommand}}, it should just be {{targetClass}} that filter Entities
> * {{targetFolder}} : used in {{CopyCommand}} and {{MoveCommand}} but is fine like that because this parameter is not visible to the user
> * {{targetLocation}} : is mostly used when a project doesn't exist, but it is also used in {{JPANewEntityCommand}}
> * {{targetPackage}} : for a Java class
> * {{targetResource}} : used in {{CopyCommand}} and {{MoveCommand}} but it's not visible for the user
> * {{targetSuperClass}} : used in {{JavaNewMethodCommand}} to target the super class, as there is already a {{targetClass}} attribute
> * {{targetTypes}} : used in {{CDINewStereotype}} command, it should be {{types}} like most commands
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (FORGE-2369) In commands there are several targetXXX attributes, some are confusing
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2369:
----------------------------------------
Summary: In commands there are several targetXXX attributes, some are confusing
Key: FORGE-2369
URL: https://issues.jboss.org/browse/FORGE-2369
Project: Forge
Issue Type: Enhancement
Components: UI - API
Affects Versions: 2.16.2.Final
Reporter: Antonio Goncalves
At the moment commands deal with different {{targetXXX}} attributes. Some are easy to understand but some are confusing. We have :
* {{targetClass}} : this mostly targets a Java class
* {{targetDirectory}} : used in {{GitCloneCommand}}, for example, but also in {{NewEJBCommand}} or {{FacesNewBean}} (which relate to Java code and should then be {{targetPackage}})
* {{targetEJB}} : used in {{EJBSetClassTransactionAttributeCommand}}, it should just be {{targetClass}} that filter EJBs
* {{targetEntity}} : used in {{JPANewFieldWizard}} or {{JPANewNamedQueryCommand}}, it should just be {{targetClass}} that filter Entities
* {{targetFolder}} : used in {{CopyCommand}} and {{MoveCommand}} but is fine like that because this parameter is not visible to the user
* {{targetLocation}} : is mostly used when a project doesn't exist, but it is also used in {{JPANewEntityCommand}}
* {{targetPackage}} : for a Java class
* {{targetResource}} : used in {{CopyCommand}} and {{MoveCommand}} but it's not visible for the user
* {{targetSuperClass}} : used in {{JavaNewMethodCommand}} to target the super class, as there is already a {{targetClass}} attribute
* {{targetTypes}} : used in {{CDINewStereotype}} command, it should be {{types}} like most commands
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months