[JBoss JIRA] Closed: (SEAMFORGE-120) StackOverFlow error in CDIFacet for proejcts with BASIC packaging type
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/SEAMFORGE-120?page=com.atlassian.jira.plu... ]
Lincoln Baxter III closed SEAMFORGE-120.
----------------------------------------
Resolution: Done
done, facets now attempt to self-register when requested via project.getFacet(FacetType.class)
> StackOverFlow error in CDIFacet for proejcts with BASIC packaging type
> ----------------------------------------------------------------------
>
> Key: SEAMFORGE-120
> URL: https://issues.jboss.org/browse/SEAMFORGE-120
> Project: Seam Forge
> Issue Type: Bug
> Components: Brainstorming
> Affects Versions: 1.0.0.Alpha3
> Reporter: Lincoln Baxter III
> Assignee: Lincoln Baxter III
> Fix For: 1.0.0.Alpha4
>
>
> at org.jboss.seam.forge.project.facets.builtin.MavenPackagingFacet.getPackagingType(MavenPackagingFacet.java:84)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:84)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.printPackTypeWarning(CDIFacet.java:108)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:98)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:84)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.printPackTypeWarning(CDIFacet.java:108)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:98)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:84)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.printPackTypeWarning(CDIFacet.java:108)
> at org.jboss.seam.forge.spec.cdi.CDIFacet.getConfigFile(CDIFacet.java:98)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Commented: (SEAMFORGE-122) Forge j2ee plugins should be renamed to JavaEE 6 Plugins
by Rodney Russ (JIRA)
[ https://issues.jboss.org/browse/SEAMFORGE-122?page=com.atlassian.jira.plu... ]
Rodney Russ commented on SEAMFORGE-122:
---------------------------------------
I didn't see any j2ee references, is this for the javaee packaging? For example:
./src/main/java/org/jboss/forge/spec/javaee
./src/main/java/org/jboss/forge/spec/javaee/util
./src/main/java/org/jboss/forge/spec/javaee
./src/main/java/org/jboss/forge/spec/javaee/cdi
./src/main/java/org/jboss/forge/spec/javaee/jpa
./src/main/java/org/jboss/forge/spec/javaee/jpa/api
./src/main/java/org/jboss/forge/spec/javaee/jpa/container
./src/main/java/org/jboss/forge/spec/javaee/jpa/provider
./src/main/java/org/jboss/forge/spec/javaee/jsf
./src/main/java/org/jboss/forge/spec/javaee/servlet
Would they all be moved to javaee6 directory/packaging? What about JavaEEDefaultContainer.java, the only java file I found with javaee in it's name? Should it change as well?
> Forge j2ee plugins should be renamed to JavaEE 6 Plugins
> --------------------------------------------------------
>
> Key: SEAMFORGE-122
> URL: https://issues.jboss.org/browse/SEAMFORGE-122
> Project: Seam Forge
> Issue Type: Task
> Components: Builtin Plugins
> Affects Versions: 1.0.0.Alpha3
> Reporter: Lincoln Baxter III
> Assignee: Lincoln Baxter III
> Fix For: 1.0.0.Alpha4
>
>
> as name states... refactor packages to allow different versions of javaEE facets.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (SEAMFORGE-166) Getting ***ERROR*** [set] null on a couple of commands
by Rodney Russ (JIRA)
Getting ***ERROR*** [set] null on a couple of commands
------------------------------------------------------
Key: SEAMFORGE-166
URL: https://issues.jboss.org/browse/SEAMFORGE-166
Project: Seam Forge
Issue Type: Bug
Components: Builtin Plugins
Affects Versions: 1.0.0.Alpha4
Reporter: Rodney Russ
In running through "First Steps with Scaffolding" in the docs, I got an "***ERROR*** [set] null" as a result of step 5 (incidentally, the new-entity has changed to just entity). I wanted to figure out what was going on and tried to execute "set VERBOSE" and actually got the same error.
I built the lastest code from master in trying to do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
put git repository in hackable location
by Dan Allen
As I've been demoing forge, I've been pitching that one of the most elegant
aspects of the git-plugin command is that it automatically sets you up with
source code to hack on. After experimenting with a plugin tonight, I
realized that while the final artifact gets put in ~/.forge/plugins, the
repository is hidden away in a cryptic directory in my temporary folder. I
think behavior should be changed to make it more welcoming for developers to
contribute back.
I propose one of the following two locations, though feel free to choose a
more flexible option:
~/.forge/plugin-repos
~/forge/plugins
...or read an option from .forge/config. Perhaps prompt the user where to
stick the source even.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
13 years, 6 months
Forge JRebel Plugin
by Lincoln Baxter, III
Hey!
Thanks for connecting with me on this. So, I am very interested in seeing a
Forge JRebel Setup plugin, and would like to help make this a reality.
In my estimation, it should take no more than 30 minutes to accomplish the
basic functionality using our new Maven APIs. I cannot speak for IDE
integration, because that is a little trickier, but if your maven plugin
takes care of most of the work, then it should at least help people out on
that regard, possibly also provide a path for obtaining licenses as well.
I'm not too too familiar with the latest JRebel setup (it's been a while
since I used it,) but perhaps we should start with building a list of things
you think (or would like) the plugin to do, and I can get you guys started.
How does that sound?
- jrebel
- setup (configures the project and does maven stuff)
- status (display license and installation status)
- update-config
- get-license (would open a browser and step through that process)
- install-license (takes license file and copies it to required
location... etc)
Just a few ideas to get us started
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 6 months
[JBoss JIRA] Created: (SEAMFORGE-164) Forge Plugins should be decoupled from the Shell Interface, run standalone in JBoss Tools
by Lincoln Baxter III (JIRA)
Forge Plugins should be decoupled from the Shell Interface, run standalone in JBoss Tools
-----------------------------------------------------------------------------------------
Key: SEAMFORGE-164
URL: https://issues.jboss.org/browse/SEAMFORGE-164
Project: Seam Forge
Issue Type: Feature Request
Components: Brainstorming, JBoss Tools Integration
Reporter: Lincoln Baxter III
(01:41:28 PM) Lincoln: I'd like to start Forge in JBoss Tools, but instead of using the Shell, use the PluginMetadata to build a GUI to run Plugins from the IDE itself.
(01:41:34 PM) Lincoln: Using windows and input fields, etc.
(01:41:45 PM) Koen Aers: hm
(01:42:07 PM) Lincoln: So workflow like this:
(01:42:46 PM) Lincoln: <CTRL-4> JBT pops up a window like <CTRL-3> where you can type and it will search through the list of commands that are available
(01:42:48 PM) Lincoln: you can pick one
(01:42:51 PM) Lincoln: when you do
(01:43:06 PM) Lincoln: JBT generates a UI for that command, with a list of required and optional fields, based on teh plugin metadata
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
Fwd: [gradle-user] tooling api
by Lincoln Baxter, III
Who wants to take a stab at Gradle integration in Forge?
---------- Forwarded message ----------
From: Jason Porter <lightguard.jp(a)gmail.com>
Date: Wed, May 4, 2011 at 12:03 PM
Subject: Fwd: [gradle-user] tooling api
To: lincolnbaxter(a)gmail.com
Adam has done a good job of describing what the Tooling API is.
Certainly something to look into for forge.
---------- Forwarded message ----------
From: Adam Murdoch
Date: Sunday, May 1, 2011
Subject: [gradle-user] tooling api
To: user(a)gradle.codehaus.org
Hi,
The 1.0-milestone-3 release includes a new API, called the tooling
API, which you can use for embedding Gradle. This API allows you to
execute and monitor builds, and to query Gradle about the details of a
build. It does so in a version independent way, so that you can use
the same API to work with different versions of Gradle. The main
audience for this API is IDE, CI server, and other UI authors.
However, it is open for anyone who needs to embed Gradle in their
application.
So, what does this API give you? Here are some features:
* You can query Gradle for the details of a build, including the
project hierarchy and the project dependencies, external dependencies
(including source and javadoc jars), source directories and tasks of
each project.
* You can execute a build, and listen to stdout and stderr logging and
progress (ie the stuff shown in the 'status bar' when you run on the
command line).
* Gradle wrapper aware and, by default, uses the same Gradle version
as that used when you run on the command-line.
* Downloads and installs the appropriate Gradle version, similar to the
wrapper.
* Lightweight implementation, with only a small number of
dependencies. It is also a well-behaved library, and makes no
assumptions about your classloader structure or logging configuration.
This makes the API easy to bundle in your application.
* Integrated with the daemon, and will use it where appropriate, for
fast builds which don't pollute the JVM which your application is
running in.
We plan to add a bunch more UI and IDE friendly features. Some examples:
* Performance. The API gives us the opportunity to do lots of caching,
static analysis and preemptive work, to make things faster for the
user. Given that this is the first cut of the API, the implementation
does not take advantage of this yet.
* Better progress monitoring and build cancellation. For example,
allowing test execution to be monitored.
* Notifications when things in the build change, so that UIs and
models can be updated.
* Validating and prompting for user supplied configuration.
* Prompting for and managing user credentials.
This API is now the official and recommended way to embed Gradle. This
means that the existing APIs, namely GradleLauncher and the open API
(UIFactory and friends), are now deprecated and will be removed in
future versions of Gradle. This will almost certainly happen before
Gradle 1.0 is released. And for the GradleLauncher API, this might
happen before the next milestone.
If you happen to use one of the above APIs, please consider changing
your application to use the tooling API instead.
You can find some samples in $gradleHome/samples/toolingApi. The build
files for these samples show the appropriate repository configuration
and dependency declarations you'll need in order to use it. See also
the Javadoc for GradleConnector, which is the main entry point of the
API:
http://gradle.org/current/docs/javadoc/org/gradle/tooling/GradleConnector...
The tooling API currently supports only Gradle 1.0-milestone-3. It
will also support any future releases of Gradle. At this stage, we are
not planning to add any support for older Gradle releases. That is,
you won't be able to use the tooling API to execute a build that needs
Gradle 0.9, for example. However, if there's a convincing reason, we
can look at adding support for some earlier Gradle releases.
--Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 6 months
Re: [forge-dev] If we can rename "Alias" to "Plugin" and remove plugin interface?
by Lincoln Baxter, III
Sorry, this is a technical requirement of using CDI to provide plugins with
injection, and it also prevents a whole lot of redundant class scanning that
would really be a performance problem, but we did consider this approach
initially.
Lincoln Baxter's Droid
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On May 9, 2011 6:45 PM, "fluids liu" <flowas(a)gmail.com> wrote:
> For example,change
>
> @Alias("gen")
> @Singleton
> public class GenPlugin implements Plugin
>
> to
>
> @Plugin("gen")
> @Singleton
> public class GenPlugin
13 years, 6 months
