11:50 a.m.
Hi all,
I love Forge because it generates code. And that's why my customers start
to love it too. Basically, they look at Forge as the "way to write
Java EEcode" or if you like "if those guys write code like this, then
we should".
I am digging into some details of the generated code (I am writing a blog
about several architectural styles starting with Forge) and I feel coding
convention should be homogenized. I know extensions are written by
different individuals, but some basic coding conventions should be applied.
For example, when you generate a web app with REST and Faces scaffolding,
you get some difference :
- Faces Backing Bean use *query builder* (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
and
- REST Endpoint use *dynamic queries* (the list all method is "SELECT
DISTINCT b FROM Book b ORDER BY b.id"))
Method names are different and do the same :
- JSF : getAll
- REST : listAll
Attributes
- private EntityManager em;
- private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead
of directly em in REST)
And there are several examples like this. If Forge is seen as "the way of
writing code" maybe something should be created to get homogenized code.
PMD, Checkstyle, human review and so one.....
Just wondering....
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
9:29 p.m.
Hi Antonio!
Thanks for your feedback! We'll consider your suggestions for the Forge 2 REST code
generation and the scaffold. In the meanwhile could you file a JIRA feature request so we
don't lose track of this?
Thank you very much!
George Gastaldi
Em 20/10/2013, às 14:51, Antonio Goncalves
<antonio.mailing(a)gmail.com> escreveu:
Hi all,
I love Forge because it generates code. And that's why my customers start to love it
too. Basically, they look at Forge as the "way to write Java EE code" or if you
like "if those guys write code like this, then we should".
I am digging into some details of the generated code (I am writing a blog about several
architectural styles starting with Forge) and I feel coding convention should be
homogenized. I know extensions are written by different individuals, but some basic coding
conventions should be applied. For example, when you generate a web app with REST and
Faces scaffolding, you get some difference :
Faces Backing Bean use query builder (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList(); and
REST Endpoint use dynamic queries (the list all method is "SELECT DISTINCT b FROM
Book b ORDER BY b.id"))
Method names are different and do the same :
JSF : getAll
REST : listAll
Attributes
private EntityManager em;
private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead of directly em in
REST)
And there are several examples like this. If Forge is seen as "the way of writing
code" maybe something should be created to get homogenized code. PMD, Checkstyle,
human review and so one.....
Just wondering....
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
10:58 p.m.
Hey Antonio!
You are absolutely correct. We really need to standardize (and improve in
general) most of the code that Forge generates. Really it works, but I
think that we can do much better to set a good example.
These are good issues to track :)
~Lincoln
On Sun, Oct 20, 2013 at 10:29 PM, George Gastaldi <ggastald(a)redhat.com>wrote:
Hi Antonio!
Thanks for your feedback! We'll consider your suggestions for the Forge 2
REST code generation and the scaffold. In the meanwhile could you file a
JIRA feature request so we don't lose track of this?
Thank you very much!
George Gastaldi
Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing(a)gmail.com>
escreveu:
Hi all,
I love Forge because it generates code. And that's why my customers start
to love it too. Basically, they look at Forge as the "way to write Java EEcode"
or if you like "if those guys write code like this, then we should".
I am digging into some details of the generated code (I am writing a blog
about several architectural styles starting with Forge) and I feel coding
convention should be homogenized. I know extensions are written by
different individuals, but some basic coding conventions should be applied.
For example, when you generate a web app with REST and Faces scaffolding,
you get some difference :
- Faces Backing Bean use *query builder* (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
and
- REST Endpoint use *dynamic queries* (the list all method is "SELECT
DISTINCT b FROM Book b ORDER BY b.id"))
Method names are different and do the same :
- JSF : getAll
- REST : listAll
Attributes
- private EntityManager em;
- private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead
of directly em in REST)
And there are several examples like this. If Forge is seen as "the way of
writing code" maybe something should be created to get homogenized code.
PMD, Checkstyle, human review and so one.....
Just wondering....
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
_______________________________________________
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.org
"Simpler is better."
12:01 a.m.
While there are several ways to do this, I would prefer (and suggest)
something a little more tangible than standardizing by convention (i.e.
what is generated by Forge). It would be good to highlight the coding
convention in a separate (maven) project, presumably residing inside the
reactor.
I would suggest something like:
<dependency>
<groupId>se.jguru.nazgul.tools.codestyle</groupId>
<artifactId>nazgul-codestyle</artifactId>
<version>2.0.9</version>
</dependency>
This will - in turn - be used by all plugins defined in the reactor parent
pom, and by IDEs integrating in Forge. Also, the codestyle would be useable
for other developers in other projects. In my opinion, this is a matter of
usability for developers wanting to use Forge properly, as well as
developers working on the Forge codebase itself. Currently, one is more or
less required to use Eclipse to have some notion of getting a codestyle
which is similar or identical to the style used by the other Forge
developers.
So ... long story made short. I would suggest formalizing the codestyle -
for use in generated code, for use within the Forge reactor and for simple
inclusion in other reactors as well.
2013/10/21 Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
Hey Antonio!
You are absolutely correct. We really need to standardize (and improve in
general) most of the code that Forge generates. Really it works, but I
think that we can do much better to set a good example.
These are good issues to track :)
~Lincoln
On Sun, Oct 20, 2013 at 10:29 PM, George Gastaldi <ggastald(a)redhat.com>wrote:
> Hi Antonio!
>
> Thanks for your feedback! We'll consider your suggestions for the Forge 2
> REST code generation and the scaffold. In the meanwhile could you file a
> JIRA feature request so we don't lose track of this?
>
> Thank you very much!
>
> George Gastaldi
>
> Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing(a)gmail.com>
> escreveu:
>
> Hi all,
>
> I love Forge because it generates code. And that's why my customers start
> to love it too. Basically, they look at Forge as the "way to write Java
> EE code" or if you like "if those guys write code like this, then we
> should".
>
> I am digging into some details of the generated code (I am writing a blog
> about several architectural styles starting with Forge) and I feel coding
> convention should be homogenized. I know extensions are written by
> different individuals, but some basic coding conventions should be applied.
> For example, when you generate a web app with REST and Faces scaffolding,
> you get some difference :
>
> - Faces Backing Bean use *query builder* (e.g getAll method is
>
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
> and
> - REST Endpoint use *dynamic queries* (the list all method is "SELECT
> DISTINCT b FROM Book b ORDER BY b.id"))
>
> Method names are different and do the same :
>
> - JSF : getAll
> - REST : listAll
>
>
> Attributes
>
> - private EntityManager em;
> - private EntityManager entityManager; // em would be better
>
> Or the use of this keyword (JSF beans use this.entityManager instead
> of directly em in REST)
>
> And there are several examples like this. If Forge is seen as "the way of
> writing code" maybe something should be created to get homogenized code.
> PMD, Checkstyle, human review and so one.....
>
> Just wondering....
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
> | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
> | Devoxx France <http://www.devoxx.fr/>
>
> _______________________________________________
> 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.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj(a)jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
4:37 a.m.
So we don't forget : https://issues.jboss.org/browse/FORGE-1271
2013/10/21 George Gastaldi <ggastald(a)redhat.com>
Hi Antonio!
Thanks for your feedback! We'll consider your suggestions for the Forge 2
REST code generation and the scaffold. In the meanwhile could you file a
JIRA feature request so we don't lose track of this?
Thank you very much!
George Gastaldi
Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing(a)gmail.com>
escreveu:
Hi all,
I love Forge because it generates code. And that's why my customers start
to love it too. Basically, they look at Forge as the "way to write Java EEcode"
or if you like "if those guys write code like this, then we should".
I am digging into some details of the generated code (I am writing a blog
about several architectural styles starting with Forge) and I feel coding
convention should be homogenized. I know extensions are written by
different individuals, but some basic coding conventions should be applied.
For example, when you generate a web app with REST and Faces scaffolding,
you get some difference :
- Faces Backing Bean use *query builder* (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
and
- REST Endpoint use *dynamic queries* (the list all method is "SELECT
DISTINCT b FROM Book b ORDER BY b.id"))
Method names are different and do the same :
- JSF : getAll
- REST : listAll
Attributes
- private EntityManager em;
- private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead
of directly em in REST)
And there are several examples like this. If Forge is seen as "the way of
writing code" maybe something should be created to get homogenized code.
PMD, Checkstyle, human review and so one.....
Just wondering....
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
_______________________________________________
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
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
1:57 a.m.
----- Original Message -----
From: "Antonio Goncalves"
<antonio.mailing(a)gmail.com>
To: "forge-dev List" <forge-dev(a)lists.jboss.org>
Sent: Sunday, October 20, 2013 10:20:49 PM
Subject: [forge-dev] Wondering about coding convention #philosophy
Hi all,
I love Forge because it generates code. And that's why my customers start to
love it too. Basically, they look at Forge as the "way to write Java EE
code" or if you like "if those guys write code like this, then we
should".
I am digging into some details of the generated code (I am writing a blog
about several architectural styles starting with Forge) and I feel coding
convention should be homogenized . I know extensions are written by
different individuals, but some basic coding conventions should be applied.
+1.
I would consider these architectural styles more than coding conventions,
and I believe it would be wise to 'standardize' some of these for Java EE 6+.
For example, when you generate a web app with REST and Faces
scaffolding,
you get some difference :
* Faces Backing Bean use query builder (e.g getAll method is
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
and
* REST Endpoint use dynamic queries (the list all method is "SELECT
DISTINCT b FROM Book b ORDER BY b.id "))
Method names are different and do the same :
* JSF : getAll
* REST : listAll
They do look similar, but they're not the same in all respects.
The one in REST will contain JOIN FETCH expressions when relationships (@OneToMany,
@ManyToMany etc.) are found in the class.
This was done to ensure that serialization would not emit incomplete object graphs.
There are various factors that would be at work here in determining what JPQL queries
should be generated.
Obviously in this context, exposing JPA entities directly is bad idea and
projections/views of the entities should be used instead.
IMHO we should not be putting persistence concerns in either the JSF beans or the REST
resources.
They should go into a service or a repository or whatever data access pattern is suitable
for the context.
This is where we lack any standardization at the moment, and it would be better to not
limit this exercise to improving the conventions alone, but also the architecture.
I don't believe in packing in persistence concerns however small, into these beans for
* we run the risk of generating God classes, and
* we'd leave users with the task of creating/extracting the persistence layer (which
should have been done by Forge in the first place).
Attributes
* private EntityManager em;
* private EntityManager entityManager; // em would be better
Or the use of this keyword (JSF beans use this.entityManager instead of
directly em in REST)
And there are several examples like this. If Forge is seen as "the way of
writing code" maybe something should be created to get homogenized code.
PMD, Checkstyle, human review and so one.....
Just wondering....
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4:36 a.m.
> * JSF : getAll
> * REST : listAll
They do look similar, but they're not the same in all respects.
The one in REST will contain JOIN FETCH expressions when relationships
(@OneToMany,
@ManyToMany etc.) are found in the class.
This was done to ensure that serialization would not emit incomplete
object graphs.
When you have too many @OneToMany or @ManyToMany relationships, you end up
with several queries that JOIN FETCH several/different relationships. So
what I usually do when things are complex is :
findAll
findAllWithRelations (meaning all relations are FETCH)
or more specific (when things are really really complex)
findAllWithBooks
findAllWithAuthors
findAllWithBooksAndAuthors
Antonio
2013/10/21 Vineet Reynolds Pereira <vpereira(a)redhat.com>
>
>
> ----- Original Message -----
> > From: "Antonio Goncalves" <antonio.mailing(a)gmail.com>
> > To: "forge-dev List" <forge-dev(a)lists.jboss.org>
> > Sent: Sunday, October 20, 2013 10:20:49 PM
> > Subject: [forge-dev] Wondering about coding convention #philosophy
> >
> > Hi all,
> >
> > I love Forge because it generates code. And that's why my customers
> start to
> > love it too. Basically, they look at Forge as the "way to write Java EE
> > code" or if you like "if those guys write code like this, then we
> should".
> >
> > I am digging into some details of the generated code (I am writing a blog
> > about several architectural styles starting with Forge) and I feel coding
> > convention should be homogenized . I know extensions are written by
> > different individuals, but some basic coding conventions should be
> applied.
>
> +1.
>
> I would consider these architectural styles more than coding conventions,
> and I believe it would be wise to 'standardize' some of these for Java EE
> 6+.
>
> > For example, when you generate a web app with REST and Faces scaffolding,
> > you get some difference :
> >
> >
> > * Faces Backing Bean use query builder (e.g getAll method is
> >
>
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
> > and
> > * REST Endpoint use dynamic queries (the list all method is "SELECT
> > DISTINCT b FROM Book b ORDER BY b.id "))
> > Method names are different and do the same :
> >
> >
> > * JSF : getAll
> > * REST : listAll
>
They do look similar, but they're not the same in all respects.
The one in REST will contain JOIN FETCH expressions when relationships
>
(@OneToMany, @ManyToMany etc.) are found in the class.
This was done to ensure that serialization would not emit incomplete
> object graphs.
> There are various factors that would be at work here in determining what
> JPQL queries should be generated.
> Obviously in this context, exposing JPA entities directly is bad idea and
> projections/views of the entities should be used instead.
>
> IMHO we should not be putting persistence concerns in either the JSF beans
> or the REST resources.
> They should go into a service or a repository or whatever data access
> pattern is suitable for the context.
> This is where we lack any standardization at the moment, and it would be
> better to not limit this exercise to improving the conventions alone, but
> also the architecture.
>
> I don't believe in packing in persistence concerns however small, into
> these beans for
> * we run the risk of generating God classes, and
> * we'd leave users with the task of creating/extracting the persistence
> layer (which should have been done by Forge in the first place).
>
> >
> > Attributes
> >
> >
> > * private EntityManager em;
> > * private EntityManager entityManager; // em would be better
> > Or the use of this keyword (JSF beans use this.entityManager instead of
> > directly em in REST)
> >
> > And there are several examples like this. If Forge is seen as "the way of
> > writing code" maybe something should be created to get homogenized code.
> > PMD, Checkstyle, human review and so one.....
> >
> > Just wondering....
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > 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
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
| LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
| Devoxx France <http://www.devoxx.fr/>
10:54 a.m.
----- Original Message -----
From: "Antonio Goncalves"
<antonio.mailing(a)gmail.com>
To: "forge-dev List" <forge-dev(a)lists.jboss.org>
Sent: Tuesday, October 22, 2013 3:06:12 PM
Subject: Re: [forge-dev] Wondering about coding convention #philosophy
>> * JSF : getAll
>> * REST : listAll
> They do look similar, but they're not the same in all respects.
> The one in REST will contain JOIN FETCH expressions when relationships
> (@OneToMany, @ManyToMany etc.) are found in the class.
> This was done to ensure that serialization would not emit incomplete object
> graphs.
When you have too many @OneToMany or @ManyToMany relationships, you end up
with several queries that JOIN FETCH several/different relationships. So
what I usually do when things are complex is :
findAll
findAllWithRelations (meaning all relations are FETCH)
or more specific (when things are really really complex)
findAllWithBooks
findAllWithAuthors
findAllWithBooksAndAuthors
Tracking as FORGE-1277 <https://issues.jboss.org/browse/FORGE-1277>;.
I'll just reproduce my comments posted there to carry on the thread:
In my opinion, this is a good addition to have. We should however handle the scenario (or
the equivalent ):
If a client issues a GET with a filter parameter (like filterAllWithBooks), then the
resource representation should not be used in a subsequent PUT request to update the
entity. The resource representation used in such a PUT request would lack certain
relationships, and thus such requests would result in incorrect updates.
I believe this could be done via documentation - clients should not be using filtered
representations to represent updates in entities. Also we do not support HTTP PATCH (yet),
so we should accept resource representations in whole and not in bits. It may also be
necessary to ensure that the relationships are eagerly fetched by default (debatable on
whether we should require clients to take the additional step of using the filter
parameter to request the complete entity representation).
Antonio
2013/10/21 Vineet Reynolds Pereira < vpereira(a)redhat.com >
----- Original Message -----
> From: "Antonio Goncalves" < antonio.mailing(a)gmail.com >
> To: "forge-dev List" < forge-dev(a)lists.jboss.org >
> Sent: Sunday, October 20, 2013 10:20:49 PM
> Subject: [forge-dev] Wondering about coding convention #philosophy
>
> Hi all,
>
> I love Forge because it generates code. And that's why my customers start
> to
> love it too. Basically, they look at Forge as the "way to write Java EE
> code" or if you like "if those guys write code like this, then we
should".
>
> I am digging into some details of the generated code (I am writing a blog
> about several architectural styles starting with Forge) and I feel coding
> convention should be homogenized . I know extensions are written by
> different individuals, but some basic coding conventions should be applied.
+1.
I would consider these architectural styles more than coding conventions,
and I believe it would be wise to 'standardize' some of these for Java EE 6+.
> For example, when you generate a web app with REST and Faces scaffolding,
> you get some difference :
>
>
> * Faces Backing Bean use query builder (e.g getAll method is
>
entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
> and
> * REST Endpoint use dynamic queries (the list all method is "SELECT
> DISTINCT b FROM Book b ORDER BY b.id "))
> Method names are different and do the same :
>
>
> * JSF : getAll
> * REST : listAll
They do look similar, but they're not the same in all respects.
The one in REST will contain JOIN FETCH expressions when relationships
(@OneToMany, @ManyToMany etc.) are found in the class.
This was done to ensure that serialization would not emit incomplete object
graphs.
There are various factors that would be at work here in determining what JPQL
queries should be generated.
Obviously in this context, exposing JPA entities directly is bad idea and
projections/views of the entities should be used instead.
IMHO we should not be putting persistence concerns in either the JSF beans or
the REST resources.
They should go into a service or a repository or whatever data access pattern
is suitable for the context.
This is where we lack any standardization at the moment, and it would be
better to not limit this exercise to improving the conventions alone, but
also the architecture.
I don't believe in packing in persistence concerns however small, into these
beans for
* we run the risk of generating God classes, and
* we'd leave users with the task of creating/extracting the persistence layer
(which should have been done by Forge in the first place).
>
> Attributes
>
>
> * private EntityManager em;
> * private EntityManager entityManager; // em would be better
> Or the use of this keyword (JSF beans use this.entityManager instead of
> directly em in REST)
>
> And there are several examples like this. If Forge is seen as "the way of
> writing code" maybe something should be created to get homogenized code.
> PMD, Checkstyle, human review and so one.....
>
> Just wondering....
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>
> _______________________________________________
> 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
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4083
days inactive
4085
days old
7 comments
5 participants
participants (5)
-
Antonio Goncalves -
George Gastaldi -
Lennart Jörelid -
Lincoln Baxter, III -
Vineet Reynolds Pereira