[JBoss JIRA] (FORGE-934) Provide method "public void visitResources(ResourceVisitor visitor); " in ResourceFacet
by Alceu Medeiros (JIRA)
Alceu Medeiros created FORGE-934:
------------------------------------
Summary: Provide method "public void visitResources(ResourceVisitor visitor);" in ResourceFacet
Key: FORGE-934
URL: https://issues.jboss.org/browse/FORGE-934
Project: Forge
Issue Type: Feature Request
Components: Parsers / File Manipulation, Plugin API
Reporter: Alceu Medeiros
As mentioned in IRC channel with development team, it would be nice if we have in ResourceFacet the method "public void visitResources(ResourceVisitor visitor);", as we have in JavaSourceFacet the method "public void visitJavaSources(JavaResourceVisitor visitor);".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-933) Expose the ForgePropertyStyle methods as an API
by Alceu Medeiros (JIRA)
Alceu Medeiros created FORGE-933:
------------------------------------
Summary: Expose the ForgePropertyStyle methods as an API
Key: FORGE-933
URL: https://issues.jboss.org/browse/FORGE-933
Project: Forge
Issue Type: Sub-task
Components: Parsers / File Manipulation
Reporter: Alceu Medeiros
As mentioned in IRC channel with development team, it would be nice if we have the ForgePropertyStyle methods as an API, to retrieve getter/setter methods from Fields, among other project higher-level properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-749) Support rendering of choices when prompting user for input
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-749?page=com.atlassian.jira.plugin.... ]
George Gastaldi commented on FORGE-749:
---------------------------------------
Forge 2 provides the UI API which allows to specify an Item label converter.
> Support rendering of choices when prompting user for input
> ----------------------------------------------------------
>
> Key: FORGE-749
> URL: https://issues.jboss.org/browse/FORGE-749
> Project: Forge
> Issue Type: Feature Request
> Components: UI - Shell
> Affects Versions: 1.2.0.Final
> Reporter: Aslak Knutsen
>
> In order to display Typed choice objects to the user
> As a Plugin Developer
> I want to be able to control the rendering
> Given a list of choices of type List<T>
> And a call to built in Shell.promptChoice( String, List<T> )
> Then it should be possible to pass in a Renderer to the shell to control out displayed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-604) Add support for Java EE 6 Full Profile
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-604?page=com.atlassian.jira.plugin.... ]
George Gastaldi closed FORGE-604.
---------------------------------
Assignee: George Gastaldi
Fix Version/s: 1.3.0.Final
Resolution: Done
Closing this issue since the EAR packaging type is now supported.
> Add support for Java EE 6 Full Profile
> --------------------------------------
>
> Key: FORGE-604
> URL: https://issues.jboss.org/browse/FORGE-604
> Project: Forge
> Issue Type: Task
> Components: Java EE APIs
> Affects Versions: 1.0.5.Final
> Environment: All
> Reporter: Christopher Volk
> Assignee: George Gastaldi
> Fix For: 1.3.0.Final
>
>
> Add support for Java EE 6 Full profile, including multi-module support (cli/maven/ear) and EAR packaging.
> The EAR packaging should be fairly "easy" to implement. The maven side of multi-module should be similarly "easy". CLI multi-module support is something I would expect to take up most of this effort.
> I believe this to be a critical feature - serious enterprise software requires Full Profile, and Forge would be even more useful for bootstrapping and developing against the Full Profile than even the Web Profile. I know that almost all the apps I work on professionally require Full Profile.
> This would be a real home run, IMHO, especially in the wake of JBoss AS7.1's Full Profile Compliance :-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-883) The persistence plugin should allow creation and configuration of multiple persistence units
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-883?page=com.atlassian.jira.plugin.... ]
George Gastaldi closed FORGE-883.
---------------------------------
Assignee: George Gastaldi
Fix Version/s: 2.0.0.Alpha5
Resolution: Done
Implemented in 2.0.0.Alpha5
> The persistence plugin should allow creation and configuration of multiple persistence units
> --------------------------------------------------------------------------------------------
>
> Key: FORGE-883
> URL: https://issues.jboss.org/browse/FORGE-883
> Project: Forge
> Issue Type: Feature Request
> Components: Java EE APIs
> Reporter: Vineet Reynolds
> Assignee: George Gastaldi
> Fix For: 2.0.0.Alpha5
>
>
> The persistence plugin sets up only one persistence unit - "forge-default". Successive executions of the {{persistence setup}} command will recreate this persistence unit. Multiple persistence units would have to be manually created by hand.
> Considering this, it would be good to have the persistence plugin support the creation of multiple persistence units.
> Additionally, the plugin should also allow for (re)configuration of the persistence unit, so that a PU once created should not require manual editing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-770) Ability to restrict ServiceRegistry and AddonRegistry services by addon dependency version
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-770?page=com.atlassian.jira.plugin.... ]
George Gastaldi edited comment on FORGE-770 at 6/2/13 6:34 PM:
---------------------------------------------------------------
Here are the comments from David Bosschaert about OSGi versioning:
{quote}
Let's say you have a component that wants to use the org.acme.Foo service. Let's say you have 2 versions of the Foo service in your system:
// version 1.0
interface Foo {
public void bar();
}
// version 2.0
interface Foo {
public void bar();
public void bar(int blah);
}
Each of the above would be in a separate module.
If I want to use the bar(int) API I clearly need version 2.0 of the API. So such a client would import org.acme at version range [2.0, 3.0), so it has visibility of the correct API.
When looking up services they are normally looked up by API name, so org.acme.Foo. If there is both an 1.0 and 2.0 service in the system, how do you pick the right one? How does the service registry decide which one to return? Since it knows the client that is requesting the service it will check whether the interface requested as visible by the client is the same one as the interface implemented by the service. If it is not the same then it is a different version of the interface and the service should not be returned to the client. If it is assignable then we're good and the client gets the service instance.
This is how OSGi frameworks do it, and it's actually quite a simple process, as the Class.isAssignableFrom() API gives you the tool you need to do it :)
If you want automated support for installing additional addons when required you really need some sort of a repository that has all the addons and exposes metadata about what they provide. Then you need a resolver that knows how to use this information and installs the addons on request.
This is potentially a (very) large piece of work. Especially resolvers are complex and can take a lot of time to write.
The OSGi Enterprise R5 spec [1] and [2] defines a Repository spec that can be used to catalogue your addons in a machine-readable way. Then, the OSGi Resolver spec (also in [1] and [2]) implements a general purpose resolver that can work with the Repository to install just the additional modules that you want. If you want to play with this stuff the Reference Implementations are available as opensource, see here for more details: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
I would think twice before implementing all this stuff, as it might seem simple when you start out but it could end up being more work than you think. OSGi implements all these things already. If you're inside AS8 then JBoss OSGi provides all this. If you are in a different environment you could simply use Apache Felix, which is about 500 kb and very embeddable.
Cheers,
David
[1] http://www.osgi.org/Download/Release5
[2] http://www.osgi.org/javadoc/r5/enterprise/
{quote}
was (Author: gastaldi):
Here are the comments feom David Bosschaert about OSGi versioning:
{quote}
Let's say you have a component that wants to use the org.acme.Foo service. Let's say you have 2 versions of the Foo service in your system:
// version 1.0
interface Foo {
public void bar();
}
// version 2.0
interface Foo {
public void bar();
public void bar(int blah);
}
Each of the above would be in a separate module.
If I want to use the bar(int) API I clearly need version 2.0 of the API. So such a client would import org.acme at version range [2.0, 3.0), so it has visibility of the correct API.
When looking up services they are normally looked up by API name, so org.acme.Foo. If there is both an 1.0 and 2.0 service in the system, how do you pick the right one? How does the service registry decide which one to return? Since it knows the client that is requesting the service it will check whether the interface requested as visible by the client is the same one as the interface implemented by the service. If it is not the same then it is a different version of the interface and the service should not be returned to the client. If it is assignable then we're good and the client gets the service instance.
This is how OSGi frameworks do it, and it's actually quite a simple process, as the Class.isAssignableFrom() API gives you the tool you need to do it :)
If you want automated support for installing additional addons when required you really need some sort of a repository that has all the addons and exposes metadata about what they provide. Then you need a resolver that knows how to use this information and installs the addons on request.
This is potentially a (very) large piece of work. Especially resolvers are complex and can take a lot of time to write.
The OSGi Enterprise R5 spec [1] and [2] defines a Repository spec that can be used to catalogue your addons in a machine-readable way. Then, the OSGi Resolver spec (also in [1] and [2]) implements a general purpose resolver that can work with the Repository to install just the additional modules that you want. If you want to play with this stuff the Reference Implementations are available as opensource, see here for more details: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
I would think twice before implementing all this stuff, as it might seem simple when you start out but it could end up being more work than you think. OSGi implements all these things already. If you're inside AS8 then JBoss OSGi provides all this. If you are in a different environment you could simply use Apache Felix, which is about 500 kb and very embeddable.
Cheers,
David
[1] http://www.osgi.org/Download/Release5
[2] http://www.osgi.org/javadoc/r5/enterprise/
{quote}
> Ability to restrict ServiceRegistry and AddonRegistry services by addon dependency version
> -------------------------------------------------------------------------------------------
>
> Key: FORGE-770
> URL: https://issues.jboss.org/browse/FORGE-770
> Project: Forge
> Issue Type: Feature Request
> Components: Container
> Affects Versions: 2.0.0.Alpha1
> Reporter: Lincoln Baxter III
> Assignee: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> Like in OSGi (shudder,) when looking up services from the ServiceRegistry, it should be possible to require that services retrieved from the ServiceRegistry be locked to a specific addon API version (via addon-dependency/classloader mapping.)
> {code}
> (A) -> (B, v1)
> -> Service 1
> (B, v2)
> -> Service 1v2
> -> Service 2v1
> {code}
> A should receive only the instance of Service 1 from (B, v1)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-770) Ability to restrict ServiceRegistry and AddonRegistry services by addon dependency version
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-770?page=com.atlassian.jira.plugin.... ]
George Gastaldi commented on FORGE-770:
---------------------------------------
Here are the comments feom David Bosschaert about OSGi versioning:
{quote}
Let's say you have a component that wants to use the org.acme.Foo service. Let's say you have 2 versions of the Foo service in your system:
// version 1.0
interface Foo {
public void bar();
}
// version 2.0
interface Foo {
public void bar();
public void bar(int blah);
}
Each of the above would be in a separate module.
If I want to use the bar(int) API I clearly need version 2.0 of the API. So such a client would import org.acme at version range [2.0, 3.0), so it has visibility of the correct API.
When looking up services they are normally looked up by API name, so org.acme.Foo. If there is both an 1.0 and 2.0 service in the system, how do you pick the right one? How does the service registry decide which one to return? Since it knows the client that is requesting the service it will check whether the interface requested as visible by the client is the same one as the interface implemented by the service. If it is not the same then it is a different version of the interface and the service should not be returned to the client. If it is assignable then we're good and the client gets the service instance.
This is how OSGi frameworks do it, and it's actually quite a simple process, as the Class.isAssignableFrom() API gives you the tool you need to do it :)
If you want automated support for installing additional addons when required you really need some sort of a repository that has all the addons and exposes metadata about what they provide. Then you need a resolver that knows how to use this information and installs the addons on request.
This is potentially a (very) large piece of work. Especially resolvers are complex and can take a lot of time to write.
The OSGi Enterprise R5 spec [1] and [2] defines a Repository spec that can be used to catalogue your addons in a machine-readable way. Then, the OSGi Resolver spec (also in [1] and [2]) implements a general purpose resolver that can work with the Repository to install just the additional modules that you want. If you want to play with this stuff the Reference Implementations are available as opensource, see here for more details: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations
I would think twice before implementing all this stuff, as it might seem simple when you start out but it could end up being more work than you think. OSGi implements all these things already. If you're inside AS8 then JBoss OSGi provides all this. If you are in a different environment you could simply use Apache Felix, which is about 500 kb and very embeddable.
Cheers,
David
[1] http://www.osgi.org/Download/Release5
[2] http://www.osgi.org/javadoc/r5/enterprise/
{quote}
> Ability to restrict ServiceRegistry and AddonRegistry services by addon dependency version
> -------------------------------------------------------------------------------------------
>
> Key: FORGE-770
> URL: https://issues.jboss.org/browse/FORGE-770
> Project: Forge
> Issue Type: Feature Request
> Components: Container
> Affects Versions: 2.0.0.Alpha1
> Reporter: Lincoln Baxter III
> Assignee: Lincoln Baxter III
> Fix For: 2.0.0.Alpha5
>
>
> Like in OSGi (shudder,) when looking up services from the ServiceRegistry, it should be possible to require that services retrieved from the ServiceRegistry be locked to a specific addon API version (via addon-dependency/classloader mapping.)
> {code}
> (A) -> (B, v1)
> -> Service 1
> (B, v2)
> -> Service 1v2
> -> Service 2v1
> {code}
> A should receive only the instance of Service 1 from (B, v1)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-766) Allow manipulation of maven plugins in a project
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-766?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III closed FORGE-766.
------------------------------------
Fix Version/s: 1.3.0.Final
Resolution: Done
> Allow manipulation of maven plugins in a project
> ------------------------------------------------
>
> Key: FORGE-766
> URL: https://issues.jboss.org/browse/FORGE-766
> Project: Forge
> Issue Type: Enhancement
> Components: Builtin Plugins
> Affects Versions: 1.2.0.Final
> Reporter: George Gastaldi
> Labels: starter
> Fix For: 1.3.0.Final
>
>
> The ProjectPlugin could introduce the addition and removal maven plugins, so it will be easy to register a new Maven plugin in the pom.xml project without the need to write a plugin for that.
> The implementation could be like this:
> {code}
> MavenPluginBuilder processorPlugin = MavenPluginBuilder.create()
> .setDependency( ... )
> .addExecution( .. )
> .addPluginDependency( ... );
> project.getFacet(MavenPluginFacet.class).addPlugin(processorPlugin);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (FORGE-766) Allow manipulation of maven plugins in a project
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-766?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on FORGE-766:
------------------------------------------
Yes, I believe you are correct :) Thanks for the reminder!
> Allow manipulation of maven plugins in a project
> ------------------------------------------------
>
> Key: FORGE-766
> URL: https://issues.jboss.org/browse/FORGE-766
> Project: Forge
> Issue Type: Enhancement
> Components: Builtin Plugins
> Affects Versions: 1.2.0.Final
> Reporter: George Gastaldi
> Labels: starter
>
> The ProjectPlugin could introduce the addition and removal maven plugins, so it will be easy to register a new Maven plugin in the pom.xml project without the need to write a plugin for that.
> The implementation could be like this:
> {code}
> MavenPluginBuilder processorPlugin = MavenPluginBuilder.create()
> .setDependency( ... )
> .addExecution( .. )
> .addPluginDependency( ... );
> project.getFacet(MavenPluginFacet.class).addPlugin(processorPlugin);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months