Fwd: [JBoss JIRA] Updated: (SEAMFORGE-211) Support structured options in @Commands
by Max Rydahl Andersen
Any recommendations on how we avoid just showing a dull long list in the IDE when no grouping possible ?
/max
Begin forwarded message:
> From: "Lincoln Baxter III (JIRA)" <jira-events(a)lists.jboss.org>
> Subject: [JBoss JIRA] Updated: (SEAMFORGE-211) Support structured options in @Commands
> Date: September 28, 2011 21:04:26 GMT+02:00
> To: max.andersen(a)redhat.com
>
>
> [ https://issues.jboss.org/browse/SEAMFORGE-211?page=com.atlassian.jira.plu... ]
>
> Lincoln Baxter III updated SEAMFORGE-211:
> -----------------------------------------
>
> Fix Version/s: Future
>
>
>> Support structured options in @Commands
>> ---------------------------------------
>>
>> Key: SEAMFORGE-211
>> URL: https://issues.jboss.org/browse/SEAMFORGE-211
>> Project: Seam Forge
>> Issue Type: Feature Request
>> Reporter: Max Rydahl Andersen
>> Fix For: Future
>>
>>
>> ver considered allowing something like
>> generateEntities(@Option String table, @Option String catalog, @Option @Option String schema, @NestedOption final JPADataSource datasource)
>> class DataSource {
>> public DataSource(@Option(...) String name, @Option(..) password, @Option(..) ..)
>> ...
>> )
>> Which would actually provide some more nested structure and be useful in ui construction in IDE plus better naming of things even in shell ?
>> Would also be good to be able to reference "default" @JPADatasource should be "production", "dev" or "test" if SEAMFORGE-210 comes to life?
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
/max
http://about.me/maxandersen
13 years, 1 month
Re: [forge-dev] [forge-users] Forge find-plugin hangs if used behind a proxy
by Lincoln Baxter, III
Sorry for the late reply. This is a tough question, copying Forge-dev.
I'm not too familiar with using proxies, but I assume we'd need to make some
changes to support that. Not exactly sure what would need to happen.
Do you have ideas for this?
~Lincoln
On Tue, Sep 20, 2011 at 4:27 AM, Giancarlo Pioli <gcpioli(a)gmail.com> wrote:
> Hi everybody,
>
> I am using forge 1.0.0 SNAPSHOT on Ubuntu 10.04 with java build
> 1.6.0_26-b03.
> I am behind a proxy so I have tried to configure forge to use them. I have
> tried setting FORGE_OPTS to "-Dhttp.proxyHost=localhost
> -Dhttp.proxyPort=3128" but I have got this error:
>
> [no project] giancarlo $ forge find-plugin jsf
> Connecting to remote repository [
> http://seamframework.org/service/File/148617]... ***ERROR*** [forge find-plugin]
> No route to host
>
> So I have tried to configure the jvm to use the system proxies
> (java.net.useSystemProxies=true on config file
> /etc/java-6-sun/net.properties) but if I try to find the plugins the console
> seems to hang and even using ctrl+c doesn't quit forge. The only thing I
> can do is close the terminal window:
>
> giancarlo@gp-fs:~$ forge
> ____ _____
> / ___| ___ __ _ _ __ ___ | ___|__ _ __ __ _ ___
> \___ \ / _ \/ _` | '_ ` _ \ | |_ / _ \| '__/ _` |/ _ \ \\
> ___) | __/ (_| | | | | | | | _| (_) | | | (_| | __/ //
> |____/ \___|\__,_|_| |_| |_| |_| \___/|_| \__, |\___|
> |___/
> [no project] giancarlo $ forge find-plugin jsf
> Connecting to remote repository [
> http://seamframework.org/service/File/148617]... ^C
> [no project] giancarlo $ ^C
> [no project] giancarlo $ ^C
> [no project] giancarlo $
>
>
> The same thing happens if I set explicitly the http/https proxy server and
> proxy port properties.
>
> Is
> Thank you.
>
> Giancarlo Pioli
>
> _______________________________________________
> forge-users mailing list
> forge-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-users
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 1 month
Re: [forge-dev] [seam-dev] SAF (aka Entity Framework) idea in Seam 3
by Dan Allen
Cross-posting to forge dev.
On Tue, Sep 20, 2011 at 13:54, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> xsalefter,
>
> Thanks, this is valuable feedback and certainly usage patterns to keep in
> mind when designing the new iteration of these components.
>
> In numerous conversations that I've had with developers familiar with Seam
> 2, the common theme is that *Home and *Query components are not the ideal
> design. They lead developers into tight corners exactly in the way you are
> describing. Thus, we likely won't be following the status quo (though, it's
> not too big of an effort to port the existing functionality to CDI, so if
> someone would like to work on that, we won't discourage it).
>
> Instead, I think these components should provide boilerplate functionality,
> yet be flexible and easily tuned to the needs of the developer. I think
> you're right in that going back to a generic DAO design might be a more
> reasonable strategy. I don't think developer expect to code entirely in XML,
> they simply don't want to type the same boilerplate over and over again.
>
> I like Jason's idea of using named queries. Keep in mind we could read the
> queries as a suggestion and produce more sophisticated queries in an
> extension...so we aren't limited to what named queries support today. We've
> also been considering supporting finder "missing" methods that build a query
> from the name of the method (or a set of annotations on the method).
>
> Whatever we decide, this should be the framework code that forge uses when
> generating CRUD applications. Let's make it something that we aren't ashamed
> of having in our projects ;)
>
> -Dan
>
> p.s. I also recommend renaming SAF, because it's a really confusing term.
> Something like "entity framework" is far more sensible.
>
> On Tue, Sep 20, 2011 at 03:47, xsalefter <xsalefter(a)yahoo.com> wrote:
>
>> Hi all.. I know that I never involved on this mailing-list so much, nor
>> contribute things to the community. But because I have an experience with
>> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and
>> EntityHome a lot) in some project, I have a thought about this.
>>
>> EntityQuery anda EntityHome is perfect in case you want to creating an
>> simple CRUD application. Well, not as simple as is. I ever involved in a
>> project with 40 more database tables with quite extensive financial
>> transaction, and use an EntityQuery and EntityHome a lot. The main problem
>> with these classes is that, It's hard (well, at least, for me) to make your
>> code consistent. What I mean by consistent is that, it is confusing to
>> determine whether the classes is a part of your UI layer, or
>> service/domain-model layer. Or where you add new functionality to satisfied
>> a specifics requirement. The study case is maybe like this:
>>
>> Let say that we have a module named accounting transaction. And we want to
>> create a input transaction page, thus we have a TransactionHome.xhtml backed
>> with TransactionHome.java. Now the problems occurs. Because we want a chart
>> of account list in the TransactionHome.xhtml, where is better place to put
>> the logic to call the chart of account list? In the TransactionHome.java, or
>> ChartOfAccountList.java?
>>
>> In the beginning I put it in the ChartOfAccountList.java, and start to
>> realize that seam's EntityList is specialized class to create a page with
>> contains a rich datatable search option, paging, and sorting. It will be
>> strange to the code if try to add non searching/sorting/paging on it. Then I
>> think to back to good-old DAO object, and thinking again about the backing
>> bean: I need to call/inject the DAO in some backing-bean, but where?
>> TransactionHome.java? Well, TransactionHome already have getEntityManager(),
>> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd.
>> Then when I thinking again about the EntityHome, I'm not sure whether I need
>> to treat this class as UI or Service class. You see, this is simple case
>> study (don't get me start with "The list of Chart Of Account need to
>> aligning with the logged in user's departments and user's role. And make
>> sure that an user with level A have a $xxx limit transaction, where level B
>> have $xxx limit").
>>
>> My purpose is not to blame something or rant to something, but instead,
>> give an idea whether is it good enough to leave ***Home and ***Query
>> concept, and back to at least
>> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at
>> least we have a "service" layer, which is "centralized" place to write a
>> business logic in our application. We could treat the "service" as
>> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence
>> classes with minimal coupled with the front-end layer), and put the richness
>> of Weld and Seam 3 maybe in the UI and view layer.
>>
>> Well, I know this is personal view, from me, and my experience. Thus, just
>> ignore if in case this is annoying and not fit with your purpose/target.
>>
>> Thanks,
>> xsalefter
>>
>> *
>> *
>> The Home idea
>>
>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/...
>>
>> The Query idea
>>
>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/...
>>
>> The main thing that I would change with the Query class above is to use
>> named queries, thus espousing the generally accepted best practice in
>> default applications. I understand this doesn't fill all the gaps of the
>> older SAF from Seam 2, but I think it works for the majority of cases, and
>> it also helps people understand the best way to do things instead of relying
>> on the magic of SAF from Seam 2 (which I have found to be a major problem in
>> projects and teams I have worked with over the last three years).
>>
>> I've spoken with Lincoln about this and there are two JIRAs (
>> https://issues.jboss.org/browse/SEAMFORGE-280 and
>> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate
>> this via the JPA plugin or perhaps Seam Persistence plugin.
>>
>> Discuss.
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
>
> --
> 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
>
>
--
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, 1 month
Re: [forge-dev] arquillian powered forge deployer
by Lincoln Baxter, III
Yes, we need this. I believe Paul is working on this. Copied forge-dev.
https://issues.jboss.org/browse/SEAMFORGE-284
Where do we get started?
~Lincoln
On Mon, Sep 19, 2011 at 2:16 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> I think its very important to switch forge over to the arquillian container
> module to handle container life cycle and deploy commands in a generic way,
> rather than the current as7 command. Could you guys catch up so lincoln can
> get the info he needs about the container apis to get this kickef off? This
> is a great example of using what we have across projects (to follow up on a
> theme from the f2f).
>
> - Dan Allen
>
> Sent from my Android-powered phone:
> An open platform for carriers, consumers and developers
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 2 months
Re: [forge-dev] Contributor List
by Lincoln Baxter, III
This sounds like a great plan. I've copied Forge Dev so others can comment.
Looking forward to seeing you!
~Lincoln
On Fri, Sep 16, 2011 at 2:09 PM, Kevin Pollet <pollet.kevin(a)gmail.com>wrote:
> Hi,
>
> Many thanks!
>
> I've seen that I have the editor rights. I will add informations like
> Organization and Hometown :-)
> I hope I will have time soon to continue my contribution on Seam Forge.
>
> Some times ago I've made a roadmap of what I want to do on the validation
> plugin:
>
> * The add-constraint and remove-constraint plugins have to be merged in one
> constraint plugin (to be consistent with other plugins)
> * The constraint plugin commands has to be contextual (e.g. when you are on
> a class, field, method, the constraint has to be added on the current
> resource)
> * Provide a way to scaffold custom constraints (with one command a
> constraint annotation will be created with it's validator...)
> * Support custom contraints (currently only built-in BV constraints can be
> added)
> * Support Hibernate Validator Annotation Processor (it's always nice to see
> that a constraint is not allowed on a given type at compile time :-)
> * Support method constraints
>
> WDYT?
>
> See you at Devoxx ;-)
>
> --Kevin
>
> Le vendredi 16 septembre 2011 à 20:01, Lincoln Baxter, III a écrit :
>
> Hey Kevin :) I updated the page. Do you still want to make edits?
>
> On Mon, Sep 12, 2011 at 11:29 AM, Kevin Pollet <pollet.kevin(a)gmail.com>wrote:
>
> Hey Lincoln,
>
> I've just seen you've added me in the contirbutor list
> <https://docs.jboss.org/author/display/SEAMFORGE/Home>of Seam Forge,
> thanks :-)
> There is a typo in my name and I'm wondering if I can correct that, as I
> have the editor rights?
>
> --Kevin
>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 2 months
