7:11 a.m.
Richard and Jason,
Both of you are working on (polished) code to provide CRUD functionality in
Java EE 6 / CDI, code that was laid down for Seam 2 applications by
seam-gen. Namely, you are replacing the Home and Query components, Richard
for the Forge scaffolding and Jason for migrating a seam-gen app to Java EE
6.
Ideally, you'll both reach the same endpoint. By that, I mean that the CRUD
architecture in a new Forge application should match the code that we
recommend for developers migrating from Seam 2 (specifically seam-gen
apps). Otherwise, developers are going to be stuck trying to decide which
direction to go...and that's no good obviously.
Richard, I noticed that you are taking the no framework route by using the
EntityManager directly and weaving both CRUD, conversation and pagination
in a single component. Are you fixed on doing it that way, or would you
consider using something like the CDI Query extension developed by Thomas
and Bartosz from CTP [1]?
I'm not trying to push you guys in either direction, other than I hope that
we can settle on a single approach to become the recommended way of doing
CRUD. The Seam community has been asking for a CRUD and Query module for a
looooooong time, and we are now at the point where we actually need it
ourselves.
I'm interested to hear your feedback, and anyone else that has opinions or
ideas for that matter.
-Dan
[1] http://ctpconsulting.github.com/query/1.0.0.Alpha2/index.html
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
7:20 a.m.
Hi Dan,
No, I'm not fixed. I am completely open to a CDI Query-based scaffold. And I agree
this is something that Seam (actually, Java EE) has been lacking for a
long time!
However the brief I was given was to generate a pure EE app with minimal (ideally zero)
non-EE library dependencies. Lincoln/Pete felt this was important,
at least for the default scaffolding provider. But this may have changed?
Regards,
Richard.
On 24/01/2012 5:11 PM, Dan Allen wrote:
Richard and Jason,
Both of you are working on (polished) code to provide CRUD functionality in Java EE 6 /
CDI, code that was laid down for Seam 2 applications by seam-gen.
Namely, you are replacing the Home and Query components, Richard for the Forge
scaffolding and Jason for migrating a seam-gen app to Java EE 6.
Ideally, you'll both reach the same endpoint. By that, I mean that the CRUD
architecture in a new Forge application should match the code that we
recommend for developers migrating from Seam 2 (specifically seam-gen apps). Otherwise,
developers are going to be stuck trying to decide which direction
to go...and that's no good obviously.
Richard, I noticed that you are taking the no framework route by using the EntityManager
directly and weaving both CRUD, conversation and pagination in a
single component. Are you fixed on doing it that way, or would you consider using
something like the CDI Query extension developed by Thomas and Bartosz
from CTP [1]?
I'm not trying to push you guys in either direction, other than I hope that we can
settle on a single approach to become the recommended way of doing
CRUD. The Seam community has been asking for a CRUD and Query module for a looooooong
time, and we are now at the point where we actually need it ourselves.
I'm interested to hear your feedback, and anyone else that has opinions or ideas for
that matter.
-Dan
[1] http://ctpconsulting.github.com/query/1.0.0.Alpha2/index.html
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
7:27 a.m.
Hey Dan, you're about an hour late to the party :) we've been discussing and
Eichard has given me some info and code to look at and read through.
As for the non dep idea, I can certainly understand where Lincoln and Pete are coming
from. I do wonder though if that would preclude us from creating a CDI extension for
rolling our own simple CRUD framework perhaps with an spi for future expansion. That be a
bit much though. At any rate I need to go through the stuff Richard has sent me and give
some feedback.
Sent from my iPhone
On Jan 23, 2012, at 23:20, Richard Kennard <richard(a)kennardconsulting.com> wrote:
Hi Dan,
No, I'm not fixed. I am completely open to a CDI Query-based scaffold. And I agree
this is something that Seam (actually, Java EE) has been lacking for a
long time!
However the brief I was given was to generate a pure EE app with minimal (ideally zero)
non-EE library dependencies. Lincoln/Pete felt this was important,
at least for the default scaffolding provider. But this may have changed?
Regards,
Richard.
On 24/01/2012 5:11 PM, Dan Allen wrote:
> Richard and Jason,
>
> Both of you are working on (polished) code to provide CRUD functionality in Java EE 6
/ CDI, code that was laid down for Seam 2 applications by seam-gen.
> Namely, you are replacing the Home and Query components, Richard for the Forge
scaffolding and Jason for migrating a seam-gen app to Java EE 6.
>
> Ideally, you'll both reach the same endpoint. By that, I mean that the CRUD
architecture in a new Forge application should match the code that we
> recommend for developers migrating from Seam 2 (specifically seam-gen apps).
Otherwise, developers are going to be stuck trying to decide which direction
> to go...and that's no good obviously.
>
> Richard, I noticed that you are taking the no framework route by using the
EntityManager directly and weaving both CRUD, conversation and pagination in a
> single component. Are you fixed on doing it that way, or would you consider using
something like the CDI Query extension developed by Thomas and Bartosz
> from CTP [1]?
>
> I'm not trying to push you guys in either direction, other than I hope that we
can settle on a single approach to become the recommended way of doing
> CRUD. The Seam community has been asking for a CRUD and Query module for a looooooong
time, and we are now at the point where we actually need it ourselves.
>
> I'm interested to hear your feedback, and anyone else that has opinions or ideas
for that matter.
>
> -Dan
>
> [1] http://ctpconsulting.github.com/query/1.0.0.Alpha2/index.html
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
7:50 a.m.
On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp(a)gmail.com> wrote:
Hey Dan, you're about an hour late to the party :) we've been
discussing
and Eichard has given me some info and code to look at and read through.
Cool. I just wanted to make sure I made the discussion public.
As for the non dep idea, I can certainly understand where Lincoln and Pete
are coming from. I do wonder though if that would preclude us from creating
a CDI extension for rolling our own simple CRUD framework perhaps with an
spi for future expansion. That be a bit much though. At any rate I need to
go through the stuff Richard has sent me and give some feedback.
First, I want to acknowledge that Richard is working with requirements that
specify no deps. Being reminded of that, the design in the scaffolding
makes sense. So I don't mean to question your choice in working within
that requirement.
My personal viewpoint, which I recognize may have no relevance, is that
this is an extreme requirement. So I'm challenging the requirement, not the
implementation :)
I think the goal to make a pure Java EE application is absurd. If anything,
it reveals the shortcomings and verbosity in Java EE 6 more than it shows
how great it is. I get that we don't want to inflate the project with
libraries, but to say that you can't have a single JAR file extra from Java
EE, well, I just don't buy it.
I *suppose* we can have multiple providers. Either way, as Richard said,
Java EE 6 needs a decent CRUD and Query framework and whether it goes into
the default Forge scaffolding or not, 99% of developers are going to want
to use it if it's available.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
7:54 a.m.
"My personal viewpoint, which I recognize may have no relevance..."
And this humility, right here, is why I love Dan Allen :)
On 24/01/2012 5:50 PM, Dan Allen wrote:
On Tue, Jan 24, 2012 at 01:27, Jason Porter
<lightguard.jp(a)gmail.com <mailto:lightguard.jp@gmail.com>> wrote:
Hey Dan, you're about an hour late to the party :) we've been discussing and
Eichard has given me some info and code to look at and read through.
Cool. I just wanted to make sure I made the discussion public.
As for the non dep idea, I can certainly understand where Lincoln and Pete are coming
from. I do wonder though if that would preclude us from
creating a CDI extension for rolling our own simple CRUD framework perhaps with an
spi for future expansion. That be a bit much though. At any rate I
need to go through the stuff Richard has sent me and give some feedback.
First, I want to acknowledge that Richard is working with requirements that specify no
deps. Being reminded of that, the design in the scaffolding makes
sense. So I don't mean to question your choice in working within that requirement.
My personal viewpoint, which I recognize may have no relevance, is that this is an
extreme requirement. So I'm challenging the requirement, not the
implementation :)
I think the goal to make a pure Java EE application is absurd. If anything, it reveals
the shortcomings and verbosity in Java EE 6 more than it shows how
great it is. I get that we don't want to inflate the project with libraries, but to
say that you can't have a single JAR file extra from Java EE, well, I
just don't buy it.
I *suppose* we can have multiple providers. Either way, as Richard said, Java EE 6 needs
a decent CRUD and Query framework and whether it goes into the
default Forge scaffolding or not, 99% of developers are going to want to use it if
it's available.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
7:59 a.m.
On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp(a)gmail.com> wrote:
As for the non dep idea, I can certainly understand where Lincoln and Pete
are coming from.
I don't.
I do wonder though if that would preclude us from creating a CDI extension
for rolling our own simple CRUD framework
The one reasonable path I see here is working out the framework and then
having Forge just spit it out into the project. (I know that will turn
Richard's stomach). But then, it's easy to nuke that package and add the
dep...likely update the imports to use the right package too. In fact,
*that* could be a Forge plugin. It would be called
forge> leave-javaee-purist-mode
:)
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
8:15 a.m.
On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Tue, Jan 24, 2012 at 01:27, Jason Porter
<lightguard.jp(a)gmail.com>wrote:
>
> As for the non dep idea, I can certainly understand where Lincoln and
> Pete are coming from.
I don't.
This is a support-driven requirement. There was a good deal of concern as
to what kind of libraries we wanted to "commit" to for a 5-7 year support
plan. This is why Seam and the other libraries were removed.
I do wonder though if that would preclude us from creating a CDI
extension
> for rolling our own simple CRUD framework
The one reasonable path I see here is working out the framework and then
having Forge just spit it out into the project. (I know that will turn
Richard's stomach). But then, it's easy to nuke that package and add the
dep...likely update the imports to use the right package too. In fact,
*that* could be a Forge plugin. It would be called
There are always multiple paths, just like we can always have multiple
scaffold providers. Open to extension - We can't, and I would argue that we
shouldn't, drop the pure EE scaffold, but we can certainly add more, and
enhance the way in which plugins can inter-operate with the generated
scaffold. That's the area where I think we should be focusing, instead of
thinking "straight up replacement." What we have is a good foundation.
Let's build onto it, not bulldoze and rebuild it :)
forge> leave-javaee-purist-mode
Also remember that what Richard has done with purist java EE is very
impressive! The main thing that's missing is security, and that's something
that's just not there in EE. (And wasn't a requirement for the scaffold.)
:)
-Dan
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
3:34 p.m.
On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com>wrote:
On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen
<dan.j.allen(a)gmail.com> wrote:
> On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp(a)gmail.com>wrote:
>
>>
>> As for the non dep idea, I can certainly understand where Lincoln and
>> Pete are coming from.
>
>
> I don't.
>
This is a support-driven requirement. There was a good deal of concern as
to what kind of libraries we wanted to "commit" to for a 5-7 year support
plan. This is why Seam and the other libraries were removed.
Again, I can stand see the point being made standing in those shoes.
You do have to admit that it looks a bit bipolar that we are working hard
to grow a CDI ecosystem with one face, then telling developers they don't
need it (and we don't want to support it) with another face.
When did we become so fearful of supporting open source software, whether
it's invented "here" or not. I'm not saying your wrong, I'm just
encouraging you to take another look.
> I do wonder though if that would preclude us from creating a CDI
>> extension for rolling our own simple CRUD framework
>
>
> The one reasonable path I see here is working out the framework and then
> having Forge just spit it out into the project. (I know that will turn
> Richard's stomach). But then, it's easy to nuke that package and add the
> dep...likely update the imports to use the right package too. In fact,
> *that* could be a Forge plugin. It would be called
>
There are always multiple paths, just like we can always have multiple
scaffold providers.
Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is
fair.
Open to extension - We can't, and I would argue that we
shouldn't, drop
the pure EE scaffold, but we can certainly add more, and enhance the way in
which plugins can inter-operate with the generated scaffold.
Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean? Does that fit within the requirements. After all, we want to
make sure the code is as maintainable as possible given these constraints.
That's the area where I think we should be focusing, instead of
thinking
"straight up replacement." What we have is a good foundation. Let's build
onto it, not bulldoze and rebuild it :)
I'm not suggesting bulldoze. Simply refactor a small portion.
>
> forge> leave-javaee-purist-mode
>
Also remember that what Richard has done with purist java EE is very
impressive!
+100
Perhaps I should have started with "I was noticeably impressed during my
demo last week at the JBUG when I first saw the sophistication of the UI
forms and use of conversations." It's looking great.
The main thing that's missing is security, and that's
something that's
just not there in EE. (And wasn't a requirement for the scaffold.)
<sarcasm> Yeah, because security one of those nice to have extras.
</sarcasm>
Sarcasm aside, I understand that this is just a general problem. Being
reminded of that, Jason and I recognized we should raise this as an early
task in DeltaSpike, perhaps integrating with another Apache library to
start, Shiro. Anyway, OT.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
11:19 p.m.
Dan,
Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each view bean
I'd actually be against this.
I don't think we can have an embedded framework without it being non-trivial. It's
probably going to use unusual methods like 'getGenericSuperClass', or
declare proprietary interfaces like 'EntityWithId', or use non-obvious tricks like
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
So it'll need to be properly documented. Plus frameworks have a habit of growing.
They'll need bug fixes, feature requests, examples etc.
I don't think we should try and 'slip something like this past' as part of
Forge. I'd be 100% behind creating something that is run as a top-level project:
a Seam CRUD framework (like CDI Query) or something. And Forge could use that. But I think
it's too big to be part of Forge itself.
I agree that many developers, when they first see the Forge output, are going to
immediately think "oh I could improve this, I could refactor that, oh look
I could push that into a base class". There's something implicit in that, which
is that they've immediately grok'ed the output and are moving on to better
things. That's not such a bad achievement. In my opinion it's better than a lot of
code generators (like, say, Roo) where your first thought is "so where
is the code that actually saves my entity? How does that get called? What plumbing is
this?"
Regards,
Richard.
On 25/01/2012 1:34 AM, Dan Allen wrote:
On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote:
On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <dan.j.allen(a)gmail.com
<mailto:dan.j.allen@gmail.com>> wrote:
On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp(a)gmail.com
<mailto:lightguard.jp@gmail.com>> wrote:
As for the non dep idea, I can certainly understand where Lincoln and Pete
are coming from.
I don't.
This is a support-driven requirement. There was a good deal of concern as to what
kind of libraries we wanted to "commit" to for a 5-7 year support
plan. This is why Seam and the other libraries were removed.
Again, I can stand see the point being made standing in those shoes.
You do have to admit that it looks a bit bipolar that we are working hard to grow a CDI
ecosystem with one face, then telling developers they don't need
it (and we don't want to support it) with another face.
When did we become so fearful of supporting open source software, whether it's
invented "here" or not. I'm not saying your wrong, I'm just encouraging
you to take another look.
I do wonder though if that would preclude us from creating a CDI extension
for rolling our own simple CRUD framework
The one reasonable path I see here is working out the framework and then having
Forge just spit it out into the project. (I know that will turn
Richard's stomach). But then, it's easy to nuke that package and add the
dep...likely update the imports to use the right package too. In fact,
*that* could be a Forge plugin. It would be called
There are always multiple paths, just like we can always have multiple scaffold
providers.
Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is fair.
Open to extension - We can't, and I would argue that we shouldn't, drop the
pure EE scaffold, but we can certainly add more, and enhance the way in
which plugins can inter-operate with the generated scaffold.
Can we agree to at least try to move some of the boilerplate into an embedded framework
rather than have the common logic duplicated in each view bean?
Does that fit within the requirements. After all, we want to make sure the code is as
maintainable as possible given these constraints.
That's the area where I think we should be focusing, instead of thinking
"straight up replacement." What we have is a good foundation. Let's build
onto it, not bulldoze and rebuild it :)
I'm not suggesting bulldoze. Simply refactor a small portion.
forge> leave-javaee-purist-mode
Also remember that what Richard has done with purist java EE is very impressive!
+100
Perhaps I should have started with "I was noticeably impressed during my demo last
week at the JBUG when I first saw the sophistication of the UI forms
and use of conversations." It's looking great.
The main thing that's missing is security, and that's something that's
just not there in EE. (And wasn't a requirement for the scaffold.)
<sarcasm> Yeah, because security one of those nice to have extras.
</sarcasm>
Sarcasm aside, I understand that this is just a general problem. Being reminded of that,
Jason and I recognized we should raise this as an early task in
DeltaSpike, perhaps integrating with another Apache library to start, Shiro. Anyway, OT.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
11:56 p.m.
*Some* will do that. Those people that are decent programmers will. Many
people, or just programmers at outsourced companies will just follow along
and do whatever they're presented with (I have horror stories, as I'm sure
many of us do). I think what Richard has done is great and it works
decently. I'm simply not 100% convinced that having this EE purist view is
the best for us in the long run. After all, if we're going all purist, then
we shouldn't need anything like Seam, or all the Hibernate extensions, or
PrettyFaces, RichFaces, etc. I'm just wondering if this CRUD stuff, which
we all know vanilla EE doesn't do very well, would be best to off load to
something else. Same thing with Security, if the scaffolding will do
anything with security.
On Tue, Jan 24, 2012 at 15:19, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
Dan,
> Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean
I'd actually be against this.
I don't think we can have an embedded framework without it being
non-trivial. It's probably going to use unusual methods like
'getGenericSuperClass', or
declare proprietary interfaces like 'EntityWithId', or use non-obvious
tricks like
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
So it'll need to be properly documented. Plus frameworks have a habit of
growing. They'll need bug fixes, feature requests, examples etc.
I don't think we should try and 'slip something like this past' as part of
Forge. I'd be 100% behind creating something that is run as a top-level
project:
a Seam CRUD framework (like CDI Query) or something. And Forge could use
that. But I think it's too big to be part of Forge itself.
I agree that many developers, when they first see the Forge output, are
going to immediately think "oh I could improve this, I could refactor that,
oh look
I could push that into a base class". There's something implicit in that,
which is that they've immediately grok'ed the output and are moving on to
better
things. That's not such a bad achievement. In my opinion it's better than
a lot of code generators (like, say, Roo) where your first thought is "so
where
is the code that actually saves my entity? How does that get called? What
plumbing is this?"
Regards,
Richard.
On 25/01/2012 1:34 AM, Dan Allen wrote:
> On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote:
>
> On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <dan.j.allen(a)gmail.com<mailto:
dan.j.allen(a)gmail.com>> wrote:
>
> On Tue, Jan 24, 2012 at 01:27, Jason Porter <
lightguard.jp(a)gmail.com <mailto:lightguard.jp@gmail.com>> wrote:
>
>
> As for the non dep idea, I can certainly understand where
Lincoln and Pete are coming from.
>
>
> I don't.
>
>
> This is a support-driven requirement. There was a good deal of
concern as to what kind of libraries we wanted to "commit" to for a 5-7
year support
> plan. This is why Seam and the other libraries were removed.
>
>
> Again, I can stand see the point being made standing in those shoes.
>
> You do have to admit that it looks a bit bipolar that we are working
hard to grow a CDI ecosystem with one face, then telling developers they
don't need
> it (and we don't want to support it) with another face.
>
> When did we become so fearful of supporting open source software,
whether it's invented "here" or not. I'm not saying your wrong, I'm
just
encouraging
> you to take another look.
>
>
> I do wonder though if that would preclude us from creating a
CDI extension for rolling our own simple CRUD framework
>
>
> The one reasonable path I see here is working out the framework
and then having Forge just spit it out into the project. (I know that will
turn
> Richard's stomach). But then, it's easy to nuke that package and
add the dep...likely update the imports to use the right package too. In
fact,
> *that* could be a Forge plugin. It would be called
>
>
> There are always multiple paths, just like we can always have
multiple scaffold providers.
>
>
> Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options
is fair.
>
> Open to extension - We can't, and I would argue that we shouldn't,
drop the pure EE scaffold, but we can certainly add more, and enhance the
way in
> which plugins can inter-operate with the generated scaffold.
>
>
> Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean?
> Does that fit within the requirements. After all, we want to make sure
the code is as maintainable as possible given these constraints.
>
> That's the area where I think we should be focusing, instead of
thinking "straight up replacement." What we have is a good foundation.
Let's build
> onto it, not bulldoze and rebuild it :)
>
>
> I'm not suggesting bulldoze. Simply refactor a small portion.
>
>
> forge> leave-javaee-purist-mode
>
>
> Also remember that what Richard has done with purist java EE is very
impressive!
>
>
> +100
>
> Perhaps I should have started with "I was noticeably impressed during my
demo last week at the JBUG when I first saw the sophistication of the UI
forms
> and use of conversations." It's looking great.
>
> The main thing that's missing is security, and that's something
that's just not there in EE. (And wasn't a requirement for the scaffold.)
>
>
> <sarcasm> Yeah, because security one of those nice to have extras.
</sarcasm>
>
> Sarcasm aside, I understand that this is just a general problem. Being
reminded of that, Jason and I recognized we should raise this as an early
task in
> DeltaSpike, perhaps integrating with another Apache library to start,
Shiro. Anyway, OT.
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
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
12:15 a.m.
Hi everyone,
its not just a matter of using different ScaffoldProviders in
generateFromEntity plugin?
if you want vanilla javaEE code generation use FacesScaffold, if you want
CDI Quey use CDIQueryBasedScafold and so on...
or its not that simple?
2012/1/24 Jason Porter <lightguard.jp(a)gmail.com>
*Some* will do that. Those people that are decent programmers will.
Many
people, or just programmers at outsourced companies will just follow along
and do whatever they're presented with (I have horror stories, as I'm sure
many of us do). I think what Richard has done is great and it works
decently. I'm simply not 100% convinced that having this EE purist view is
the best for us in the long run. After all, if we're going all purist, then
we shouldn't need anything like Seam, or all the Hibernate extensions, or
PrettyFaces, RichFaces, etc. I'm just wondering if this CRUD stuff, which
we all know vanilla EE doesn't do very well, would be best to off load to
something else. Same thing with Security, if the scaffolding will do
anything with security.
On Tue, Jan 24, 2012 at 15:19, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
> Dan,
>
> > Can we agree to at least try to move some of the boilerplate into an
> embedded framework rather than have the common logic duplicated in each
> view bean
>
> I'd actually be against this.
>
> I don't think we can have an embedded framework without it being
> non-trivial. It's probably going to use unusual methods like
> 'getGenericSuperClass', or
> declare proprietary interfaces like 'EntityWithId', or use non-obvious
> tricks like
>
>
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
>
> So it'll need to be properly documented. Plus frameworks have a habit of
> growing. They'll need bug fixes, feature requests, examples etc.
>
> I don't think we should try and 'slip something like this past' as part
> of Forge. I'd be 100% behind creating something that is run as a top-level
> project:
> a Seam CRUD framework (like CDI Query) or something. And Forge could use
> that. But I think it's too big to be part of Forge itself.
>
> I agree that many developers, when they first see the Forge output, are
> going to immediately think "oh I could improve this, I could refactor that,
> oh look
> I could push that into a base class". There's something implicit in that,
> which is that they've immediately grok'ed the output and are moving on to
> better
> things. That's not such a bad achievement. In my opinion it's better than
> a lot of code generators (like, say, Roo) where your first thought is "so
> where
> is the code that actually saves my entity? How does that get called? What
> plumbing is this?"
>
> Regards,
>
> Richard.
>
> On 25/01/2012 1:34 AM, Dan Allen wrote:
> > On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III <
> lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote:
> >
> > On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen
<dan.j.allen(a)gmail.com<mailto:
> dan.j.allen(a)gmail.com>> wrote:
> >
> > On Tue, Jan 24, 2012 at 01:27, Jason Porter <
> lightguard.jp(a)gmail.com <mailto:lightguard.jp@gmail.com>> wrote:
> >
> >
> > As for the non dep idea, I can certainly understand where
> Lincoln and Pete are coming from.
> >
> >
> > I don't.
> >
> >
> > This is a support-driven requirement. There was a good deal of
> concern as to what kind of libraries we wanted to "commit" to for a 5-7
> year support
> > plan. This is why Seam and the other libraries were removed.
> >
> >
> > Again, I can stand see the point being made standing in those shoes.
> >
> > You do have to admit that it looks a bit bipolar that we are working
> hard to grow a CDI ecosystem with one face, then telling developers they
> don't need
> > it (and we don't want to support it) with another face.
> >
> > When did we become so fearful of supporting open source software,
> whether it's invented "here" or not. I'm not saying your wrong,
I'm just
> encouraging
> > you to take another look.
> >
> >
> > I do wonder though if that would preclude us from creating
> a CDI extension for rolling our own simple CRUD framework
> >
> >
> > The one reasonable path I see here is working out the framework
> and then having Forge just spit it out into the project. (I know that will
> turn
> > Richard's stomach). But then, it's easy to nuke that package
> and add the dep...likely update the imports to use the right package too.
> In fact,
> > *that* could be a Forge plugin. It would be called
> >
> >
> > There are always multiple paths, just like we can always have
> multiple scaffold providers.
> >
> >
> > Agreed. We want to avoid the paradox of choice, but 2 - 3 strong
> options is fair.
> >
> > Open to extension - We can't, and I would argue that we shouldn't,
> drop the pure EE scaffold, but we can certainly add more, and enhance the
> way in
> > which plugins can inter-operate with the generated scaffold.
> >
> >
> > Can we agree to at least try to move some of the boilerplate into an
> embedded framework rather than have the common logic duplicated in each
> view bean?
> > Does that fit within the requirements. After all, we want to make sure
> the code is as maintainable as possible given these constraints.
> >
> > That's the area where I think we should be focusing, instead of
> thinking "straight up replacement." What we have is a good foundation.
> Let's build
> > onto it, not bulldoze and rebuild it :)
> >
> >
> > I'm not suggesting bulldoze. Simply refactor a small portion.
> >
> >
> > forge> leave-javaee-purist-mode
> >
> >
> > Also remember that what Richard has done with purist java EE is
> very impressive!
> >
> >
> > +100
> >
> > Perhaps I should have started with "I was noticeably impressed during
> my demo last week at the JBUG when I first saw the sophistication of the UI
> forms
> > and use of conversations." It's looking great.
> >
> > The main thing that's missing is security, and that's something
> that's just not there in EE. (And wasn't a requirement for the scaffold.)
> >
> >
> > <sarcasm> Yeah, because security one of those nice to have extras.
> </sarcasm>
> >
> > Sarcasm aside, I understand that this is just a general problem. Being
> reminded of that, Jason and I recognized we should raise this as an early
> task in
> > DeltaSpike, perhaps integrating with another Apache library to start,
> Shiro. Anyway, OT.
> >
> > -Dan
> >
> > --
> > Dan Allen
> > Principal Software Engineer, Red Hat | Author of Seam in Action
> > Registered Linux User #231597
> >
> > http://google.com/profiles/dan.j.allen
> > http://mojavelinux.com
> > http://mojavelinux.com/seaminaction
> >
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
--
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
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
<http://www.advancedit.com.br/>Att,
Rafael M. Pestano
Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
Graduando em Ciência da Computação UFRGS
@realpestano
http://code.google.com/p/jsf-conventions-framework/
1:22 a.m.
On Tue, Jan 24, 2012 at 18:15, Rafael Pestano <rmpestano(a)gmail.com> wrote:
Hi everyone,
its not just a matter of using different ScaffoldProviders in
generateFromEntity plugin?
if you want vanilla javaEE code generation use FacesScaffold, if you want
CDI Quey use CDIQueryBasedScafold and so on...
or its not that simple?
It's true. And from the conversation above, it looks like that's where we
are headed.
I say that because:
(a) it appears the Java EE purist output is an immovable requirement
(b) we definitely want to offer output that *does* use a framework for
those that want it (CDI Query likely)
Now, if at some point we decide that (b) isn't needed anymore, then (b)
because the preferred recommendation. Yeah.
Granted, (a) and (b) won't be all that different, so we certainly aren't
dumping work. (b) is simply introducing a dependency that effectively trims
down what (a) produces.
I think Jason should proceed with what the (b) output will look like for
the Open18 migration, then we can work it back into a (b) plugin.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
1:34 a.m.
On Tue, Jan 24, 2012 at 17:19, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
Dan,
> Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean
I'd actually be against this.
I don't think we can have an embedded framework without it being
non-trivial. It's probably going to use unusual methods like
'getGenericSuperClass', or
declare proprietary interfaces like 'EntityWithId', or use non-obvious
tricks like
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
So it'll need to be properly documented. Plus frameworks have a habit of
growing. They'll need bug fixes, feature requests, examples etc.
After I laid down last night, this thought (i.e, fear) came rushing into my
head. Shading in framework code is no good (like a bad hangover tells you
about that last shot you did the night before).
^ The beginning of Hangover 2 just came to mind :)
I don't think we should try and 'slip something like this past' as part of
Forge. I'd be 100% behind creating something that is run as a top-level
project:
a Seam CRUD framework (like CDI Query) or something. And Forge could use
that. But I think it's too big to be part of Forge itself.
Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git repository.
I agree that many developers, when they first see the Forge output, are
going to immediately think "oh I could improve this, I could refactor that,
oh look
I could push that into a base class". There's something implicit in that,
which is that they've immediately grok'ed the output and are moving on to
better
things. That's not such a bad achievement. In my opinion it's better than
a lot of code generators (like, say, Roo) where your first thought is "so
where
is the code that actually saves my entity? How does that get called? What
plumbing is this?"
Very true.
As I said in my other e-mail, we can sort of agree to disagree in part. The
pure Java EE approach will likely invoke the reaction of "I could improve
that", and they would be correct. But the output is not doing anything
cryptic, so it fills a void of showing them what Java EE has, for better or
for worse.
I'm guessing you would agree that using a few frameworks would dramatically
improve the elegance of the output, for example Query and MetaWidget.
Therefore it's worth the community (at least) exploring a second scaffold
that does make use of a palatable set of extension libraries.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
1:44 a.m.
+1 for a second scaffold.
Clearly the current scaffold is not doing much to further my clandestine goal of runtime
UI generation. I'd definitely want to explore a second scaffold
that depends on a runtime Metawidget (much as Forge Beta 3 did). And probably something
like CDI Query, RichFaces, PrettyFaces etc. as well.
On 25/01/2012 11:34 AM, Dan Allen wrote:
On Tue, Jan 24, 2012 at 17:19, Richard Kennard
<richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote:
Dan,
> Can we agree to at least try to move some of the boilerplate into an embedded
framework rather than have the common logic duplicated in each view bean
I'd actually be against this.
I don't think we can have an embedded framework without it being non-trivial.
It's probably going to use unusual methods like 'getGenericSuperClass', or
declare proprietary interfaces like 'EntityWithId', or use non-obvious tricks
like
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
So it'll need to be properly documented. Plus frameworks have a habit of growing.
They'll need bug fixes, feature requests, examples etc.
After I laid down last night, this thought (i.e, fear) came rushing into my head. Shading
in framework code is no good (like a bad hangover tells you
about that last shot you did the night before).
^ The beginning of Hangover 2 just came to mind :)
I don't think we should try and 'slip something like this past' as part
of Forge. I'd be 100% behind creating something that is run as a top-level
project:
a Seam CRUD framework (like CDI Query) or something. And Forge could use that. But I
think it's too big to be part of Forge itself.
Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git repository.
I agree that many developers, when they first see the Forge output, are going to
immediately think "oh I could improve this, I could refactor that,
oh look
I could push that into a base class". There's something implicit in that,
which is that they've immediately grok'ed the output and are moving on to
better
things. That's not such a bad achievement. In my opinion it's better than a
lot of code generators (like, say, Roo) where your first thought is "so where
is the code that actually saves my entity? How does that get called? What plumbing is
this?"
Very true.
As I said in my other e-mail, we can sort of agree to disagree in part. The pure Java EE
approach will likely invoke the reaction of "I could improve
that", and they would be correct. But the output is not doing anything cryptic, so
it fills a void of showing them what Java EE has, for better or for worse.
I'm guessing you would agree that using a few frameworks would dramatically improve
the elegance of the output, for example Query and MetaWidget.
Therefore it's worth the community (at least) exploring a second scaffold that does
make use of a palatable set of extension libraries.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
3:13 a.m.
And don't forget Ryan Bradley is working hard on a Spring scaffold too.
On 25/01/2012 11:44 AM, Richard Kennard wrote:
+1 for a second scaffold.
Clearly the current scaffold is not doing much to further my clandestine goal of runtime
UI generation. I'd definitely want to explore a second scaffold
that depends on a runtime Metawidget (much as Forge Beta 3 did). And probably something
like CDI Query, RichFaces, PrettyFaces etc. as well.
On 25/01/2012 11:34 AM, Dan Allen wrote:
> On Tue, Jan 24, 2012 at 17:19, Richard Kennard <richard(a)kennardconsulting.com
<mailto:richard@kennardconsulting.com>> wrote:
>
> Dan,
>
> > Can we agree to at least try to move some of the boilerplate into an embedded
framework rather than have the common logic duplicated in each view bean
>
> I'd actually be against this.
>
> I don't think we can have an embedded framework without it being non-trivial.
It's probably going to use unusual methods like
> 'getGenericSuperClass', or
> declare proprietary interfaces like 'EntityWithId', or use non-obvious
tricks like
>
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
>
> So it'll need to be properly documented. Plus frameworks have a habit of
growing. They'll need bug fixes, feature requests, examples etc.
>
>
> After I laid down last night, this thought (i.e, fear) came rushing into my head.
Shading in framework code is no good (like a bad hangover tells you
> about that last shot you did the night before).
>
> ^ The beginning of Hangover 2 just came to mind :)
>
>
> I don't think we should try and 'slip something like this past' as
part of Forge. I'd be 100% behind creating something that is run as a top-level
> project:
> a Seam CRUD framework (like CDI Query) or something. And Forge could use that.
But I think it's too big to be part of Forge itself.
>
>
> Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git repository.
>
>
> I agree that many developers, when they first see the Forge output, are going to
immediately think "oh I could improve this, I could refactor that,
> oh look
> I could push that into a base class". There's something implicit in
that, which is that they've immediately grok'ed the output and are moving on to
> better
> things. That's not such a bad achievement. In my opinion it's better than
a lot of code generators (like, say, Roo) where your first thought is "so
> where
> is the code that actually saves my entity? How does that get called? What
plumbing is this?"
>
>
> Very true.
>
> As I said in my other e-mail, we can sort of agree to disagree in part. The pure Java
EE approach will likely invoke the reaction of "I could improve
> that", and they would be correct. But the output is not doing anything cryptic,
so it fills a void of showing them what Java EE has, for better or for
> worse.
>
> I'm guessing you would agree that using a few frameworks would dramatically
improve the elegance of the output, for example Query and MetaWidget.
> Therefore it's worth the community (at least) exploring a second scaffold that
does make use of a palatable set of extension libraries.
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
5:35 p.m.
Yes. +1 to additional scaffolds that take advantage of all of these
features and show off everything we can do!
Also, let's not forget that we can always find clever ways to add plugins
to change the behavior of a scaffold, to tie in new frameworks like was
done with the PrettyFaces plugin - which detects when resources have been
generated, and automatically provides URL-mappings for them. Or the OCPsoft
Rewrite plugin that literally maps all scaffolded resources using one line
of config.
Let's not forget about plugin love! Creating plugins that can operate on
any scaffold is the Future!!!
~Lincoln
On Tue, Jan 24, 2012 at 9:13 PM, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
And don't forget Ryan Bradley is working hard on a Spring
scaffold too.
On 25/01/2012 11:44 AM, Richard Kennard wrote:
> +1 for a second scaffold.
>
> Clearly the current scaffold is not doing much to further my clandestine
goal of runtime UI generation. I'd definitely want to explore a second
scaffold
> that depends on a runtime Metawidget (much as Forge Beta 3 did). And
probably something like CDI Query, RichFaces, PrettyFaces etc. as well.
>
> On 25/01/2012 11:34 AM, Dan Allen wrote:
>> On Tue, Jan 24, 2012 at 17:19, Richard Kennard <
richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>
wrote:
>>
>> Dan,
>>
>> > Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean
>>
>> I'd actually be against this.
>>
>> I don't think we can have an embedded framework without it being
non-trivial. It's probably going to use unusual methods like
>> 'getGenericSuperClass', or
>> declare proprietary interfaces like 'EntityWithId', or use
non-obvious tricks like
>>
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/s...
>>
>> So it'll need to be properly documented. Plus frameworks have a
habit of growing. They'll need bug fixes, feature requests, examples etc.
>>
>>
>> After I laid down last night, this thought (i.e, fear) came rushing
into my head. Shading in framework code is no good (like a bad hangover
tells you
>> about that last shot you did the night before).
>>
>> ^ The beginning of Hangover 2 just came to mind :)
>>
>>
>> I don't think we should try and 'slip something like this past'
as
part of Forge. I'd be 100% behind creating something that is run as a
top-level
>> project:
>> a Seam CRUD framework (like CDI Query) or something. And Forge
could use that. But I think it's too big to be part of Forge itself.
>>
>>
>> Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git
repository.
>>
>>
>> I agree that many developers, when they first see the Forge output,
are going to immediately think "oh I could improve this, I could refactor
that,
>> oh look
>> I could push that into a base class". There's something implicit
in
that, which is that they've immediately grok'ed the output and are moving
on to
>> better
>> things. That's not such a bad achievement. In my opinion it's
better than a lot of code generators (like, say, Roo) where your first
thought is "so
>> where
>> is the code that actually saves my entity? How does that get
called? What plumbing is this?"
>>
>>
>> Very true.
>>
>> As I said in my other e-mail, we can sort of agree to disagree in part.
The pure Java EE approach will likely invoke the reaction of "I could
improve
>> that", and they would be correct. But the output is not doing anything
cryptic, so it fills a void of showing them what Java EE has, for better or
for
>> worse.
>>
>> I'm guessing you would agree that using a few frameworks would
dramatically improve the elegance of the output, for example Query and
MetaWidget.
>> Therefore it's worth the community (at least) exploring a second
scaffold that does make use of a palatable set of extension libraries.
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://google.com/profiles/dan.j.allen
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
7:23 a.m.
Hey Dan,
We can definitely look in to a scaffold-provider that uses an extension for
query logic! We need to work on the extension points for the scaffold
anyway, so that would be a good thing to do while we work on that. It's
important to make sure we keep up a pure EE implementation at the same time
as well, but Metawidget has proven excellent for many kinds of Generation,
so I think that we should definitely consider that as a very good option
for working on another provider :)
~Lincoln
On Tue, Jan 24, 2012 at 1:11 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Richard and Jason,
Both of you are working on (polished) code to provide CRUD functionality
in Java EE 6 / CDI, code that was laid down for Seam 2 applications by
seam-gen. Namely, you are replacing the Home and Query components, Richard
for the Forge scaffolding and Jason for migrating a seam-gen app to Java EE
6.
Ideally, you'll both reach the same endpoint. By that, I mean that the
CRUD architecture in a new Forge application should match the code that we
recommend for developers migrating from Seam 2 (specifically seam-gen
apps). Otherwise, developers are going to be stuck trying to decide which
direction to go...and that's no good obviously.
Richard, I noticed that you are taking the no framework route by using the
EntityManager directly and weaving both CRUD, conversation and pagination
in a single component. Are you fixed on doing it that way, or would you
consider using something like the CDI Query extension developed by Thomas
and Bartosz from CTP [1]?
I'm not trying to push you guys in either direction, other than I hope
that we can settle on a single approach to become the recommended way of
doing CRUD. The Seam community has been asking for a CRUD and Query module
for a looooooong time, and we are now at the point where we actually need
it ourselves.
I'm interested to hear your feedback, and anyone else that has opinions or
ideas for that matter.
-Dan
[1] http://ctpconsulting.github.com/query/1.0.0.Alpha2/index.html
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
4475
days inactive
4476
days old
16 comments
5 participants
participants (5)
-
Dan Allen -
Jason Porter -
Lincoln Baxter, III -
Rafael Pestano -
Richard Kennard