-
1. Re: [forge-dev] Several architectural styles in Forge (was Wondering about coding convention)
-
Original Message -
From: "Antonio Goncalves" <antonio.mailing@gmail.com>
To: "forge-dev List" <forge-dev@lists.jboss.org>
Sent: Monday, October 21, 2013 2:09:41 PM
Subject: Several architectural styles in Forge (was Wondering about coding convention)
2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >
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.
Vineet, this is the topic I'm writing about at the moment. To be honest, I
quite like to have persistent concerns in JSF beans and REST for certain
projects... but not all, and that's where I thing Forge should give some
choices. What I'm writing is about having 3 different architectural styles
that could be resume like this (using CLI) :
Current (generates JSF/REST from entities) :
jsf-scaffold-from-entity
rest-scaffold-from-entity
EJB Centric (add a service layer to deal with persistence) :
ejb-scaffold-from-entity
jsf-scaffold-from-ejb
rest-scaffold-from-ejb
REST centric (the JSF backing beans use the REST endpoint, using JAX-RS 2.0
Client API) :
rest-scaffold-from-entity
jsf-scaffold-from-rest
Very interesting. I was about to suggest linking any work in this space with FORGE-944.
Overall, I get the impression that we should structure commands based on
developer workflows given common architectural styles.
I'll await your post.
I will let you know when the post is written, it will be clearer
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
_______________________________________________
forge-dev mailing list
https://lists.jboss.org/mailman/listinfo/forge-dev
-
2. Re: [forge-dev] Several architectural styles in Forge (was Wondering about coding convention)
Hi Vineet,
I've published the blog : http://antoniogoncalves
.org/2013/10/29/several-architectural-styles-with-java-ee-7/
I've implemented the three different architectural styles and you can have
a look at : https://github.com/agoncal/agoncal-sample-javaee/tree/master/03-
TierArchitecture
Unfortunately I still have an issue with the RESTendpoint doing a paginate
(I've asked some help in the jersey mailing list, but still no news, you
can have a look at :
https://java.net/projects/jersey/lists/users/archive/2013-10/message/64
If you look at the code for the three styles, there are not many changes. I
would hope that Forge could help developers to generate different
architectural styles. As I said, we could do something like this (depending
on the future syntax : https://issues.jboss.org/browse/FORGE-944)
Horizontal :*
- jpa-scaffold-from-database
- jsf-scaffold-from-entity
- rest-scaffold-from-entity
EJB Centric :
- jpa-scaffold-from-database
- ejb-scaffold-from-entity
- jsf-scaffold-from-ejb
- rest-scaffold-from-ejb
REST centric :
- jpa-scaffold-from-database
- rest-scaffold-from-entity
- jsf-scaffold-from-rest
If that interests you, I would be more than happy to contribute to
something like that.
Antonio
2013/10/21 Vineet Reynolds Pereira <vpereira@redhat.com>
>
----- Original Message -----
From: "Antonio Goncalves" <antonio.mailing@gmail.com>
To: "forge-dev List" <forge-dev@lists.jboss.org>
Sent: Monday, October 21, 2013 2:09:41 PM
Wondering about coding convention)
2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >
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.
Vineet, this is the topic I'm writing about at the moment. To be honest,
I
quite like to have persistent concerns in JSF beans and REST for certain
projects... but not all, and that's where I thing Forge should give some
choices. What I'm writing is about having 3 different architectural
styles
that could be resume like this (using CLI) :
Current (generates JSF/REST from entities) :
jsf-scaffold-from-entity
rest-scaffold-from-entity
EJB Centric (add a service layer to deal with persistence) :
ejb-scaffold-from-entity
jsf-scaffold-from-ejb
rest-scaffold-from-ejb
REST centric (the JSF backing beans use the REST endpoint, using JAX-RS
2.0
Client API) :
rest-scaffold-from-entity
jsf-scaffold-from-rest
>
Very interesting. I was about to suggest linking any work in this space
with FORGE-944.
Overall, I get the impression that we should structure commands based on
developer workflows given common architectural styles.
I'll await your post.
I will let you know when the post is written, it will be clearer
--
Antonio Goncalves
Software architect and Java Champion
Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
_______________________________________________
forge-dev mailing list
_______________________________________________
forge-dev mailing list
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
| Devoxx France <http://www.devoxx.fr/>
-
3. Re: [forge-dev] Several architectural styles in Forge (was Wondering about coding convention)
lincolnthree Oct 29, 2013 10:19 AM (in response to Antonio Goncalves )Hey Antonio!
I'm definitely very interested in seeing more styles of programming
supported! I think this would be a great project. I am all for it.
The interesting part will be trying to determine appropriate patterns for
each style. REST APIs vary greatly, but if we can find some kind of best
practice, which based on your blog, it looks like you already have an idea
of, then I think that makes our job much simpler (and it is a complex job
So far, our command style is following this basic premise:
jpa-new-entity (instead of entity --named)
jpa-new-embedable
jpa-new-mapped-superclass --named Person
jpa-new-entity --named Vet --extends Person
{spec alias or acronym}-new- {spec alias or acronym}--from-{something else}
We have a dilemma with faces and CDI, though. Should we call them 'faces'
and 'rest' or "jsf" and "jaxrs", since we already have "jpa" "ejb" etc. I
think JAX-RS is the real issue, because most people know it as REST.
But back on topic, yes, I'm all for this!
~Lincoln
On Tue, Oct 29, 2013 at 9:49 AM, Antonio Goncalves <
antonio.mailing@gmail.com> wrote:
Hi Vineet,
I've published the blog : http://antoniogoncalves
.org/2013/10/29/several-architectural-styles-with-java-ee-7/
I've implemented the three different architectural styles and you can have
a look at : https://github.com/agoncal/agoncal-sample-javaee
/tree/master/03-TierArchitecture
Unfortunately I still have an issue with the RESTendpoint doing a
paginate (I've asked some help in the jersey mailing list, but still no
news, you can have a look at :
https://java.net/projects/jersey/lists/users/archive/2013-10/message/64
If you look at the code for the three styles, there are not many changes.
I would hope that Forge could help developers to generate different
architectural styles. As I said, we could do something like this (depending
on the future syntax : https://issues.jboss.org/browse/FORGE-944)
Horizontal :*
- jpa-scaffold-from-database
- jsf-scaffold-from-entity
- rest-scaffold-from-entity
>
EJB Centric :
- jpa-scaffold-from-database
- ejb-scaffold-from-entity
- jsf-scaffold-from-ejb
- rest-scaffold-from-ejb
>
REST centric :
- jpa-scaffold-from-database
- rest-scaffold-from-entity
- jsf-scaffold-from-rest
If that interests you, I would be more than happy to contribute to
something like that.
Antonio
>
>
2013/10/21 Vineet Reynolds Pereira <vpereira@redhat.com>
>>
>>
>> -
Original Message -
>> > From: "Antonio Goncalves" <antonio.mailing@gmail.com>
>> > To: "forge-dev List" <forge-dev@lists.jboss.org>
>> > Sent: Monday, October 21, 2013 2:09:41 PM
>> > Subject: Several architectural styles in Forge (was
>> Wondering about coding convention)
>> >
>> > 2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >
>> >
>> >
>> >
>> >
>> >
>> > 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.
>> >
>> >
>> > Vineet, this is the topic I'm writing about at the moment. To be
>> honest, I
>> > quite like to have persistent concerns in JSF beans and REST for certain
>> > projects... but not all, and that's where I thing Forge should give some
>> > choices. What I'm writing is about having 3 different architectural
>> styles
>> > that could be resume like this (using CLI) :
>> >
>> > Current (generates JSF/REST from entities) :
>> > jsf-scaffold-from-entity
>> > rest-scaffold-from-entity
>> >
>> > EJB Centric (add a service layer to deal with persistence) :
>> > ejb-scaffold-from-entity
>> > jsf-scaffold-from-ejb
>> > rest-scaffold-from-ejb
>> >
>> > REST centric (the JSF backing beans use the REST endpoint, using JAX-RS
>> 2.0
>> > Client API) :
>> > rest-scaffold-from-entity
>> > jsf-scaffold-from-rest
>> >
>>
>> Very interesting. I was about to suggest linking any work in this space
>> with FORGE-944.
>> Overall, I get the impression that we should structure commands based on
>> developer workflows given common architectural styles.
>>
>> I'll await your post.
>>
>> >
>> > I will let you know when the post is written, it will be clearer
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect and Java Champion
>> >
>> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>> >
>> > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> _______________________________________________
>> forge-dev mailing list
>> 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/>
_______________________________________________
forge-dev mailing list
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
"Simpler is better."
-
att1.html.zip 3.1 KB
-
4. Re: [forge-dev] Several architectural styles in Forge (was Wondering about coding convention)
Cool, I would be more than happy to contribute to that.
PS : @lincoln BTW, I've updated the JIRA related to the CLI syntax with
what you've just said :
2013/10/29 Lincoln Baxter, III <lincolnbaxter@gmail.com>
Hey Antonio!
I'm definitely very interested in seeing more styles of programming
supported! I think this would be a great project. I am all for it.
The interesting part will be trying to determine appropriate patterns for
each style. REST APIs vary greatly, but if we can find some kind of best
practice, which based on your blog, it looks like you already have an idea
of, then I think that makes our job much simpler (and it is a complex job
So far, our command style is following this basic premise:
jpa-new-entity (instead of entity --named)
jpa-new-embedable
jpa-new-mapped-superclass --named Person
jpa-new-entity --named Vet --extends Person
>
{spec alias or acronym}-new- > {spec alias or acronym}--from-{something else}
We have a dilemma with faces and CDI, though. Should we call them 'faces'
and 'rest' or "jsf" and "jaxrs", since we already have "jpa" "ejb" etc. I
think JAX-RS is the real issue, because most people know it as REST.
But back on topic, yes, I'm all for this!
~Lincoln
>
On Tue, Oct 29, 2013 at 9:49 AM, Antonio Goncalves <
antonio.mailing@gmail.com> wrote:
>> Hi Vineet,
>>
>> I've published the blog : http://antoniogoncalves
>> .org/2013/10/29/several-architectural-styles-with-java-ee-7/
>>
>> I've implemented the three different architectural styles and you can
>> have a look at : https://github.com/agoncal/agoncal-sample-javaee
>> /tree/master/03-TierArchitecture
>>
>> Unfortunately I still have an issue with the RESTendpoint doing a
>> paginate (I've asked some help in the jersey mailing list, but still no
>> news, you can have a look at :
>> https://java.net/projects/jersey/lists/users/archive/2013-10/message/64
>>
>> If you look at the code for the three styles, there are not many changes.
>> I would hope that Forge could help developers to generate different
>> architectural styles. As I said, we could do something like this (depending
>> on the future syntax : https://issues.jboss.org/browse/FORGE-944)
>>
>> * Horizontal :*
>>
>> - jpa-scaffold-from-database
>> - jsf-scaffold-from-entity
>> - rest-scaffold-from-entity
>>
>>
>> EJB Centric :
>>
>> - jpa-scaffold-from-database
>> - ejb-scaffold-from-entity
>> - jsf-scaffold-from-ejb
>> - rest-scaffold-from-ejb
>>
>>
>> REST centric :
>>
>> - jpa-scaffold-from-database
>> - rest-scaffold-from-entity
>> - jsf-scaffold-from-rest
>>
>> If that interests you, I would be more than happy to contribute to
>> something like that.
>>
>> Antonio
>>
>>
>>
>>
>> 2013/10/21 Vineet Reynolds Pereira <vpereira@redhat.com>
>>
>>>
>>>
>>> -
Original Message -
>>> > From: "Antonio Goncalves" <antonio.mailing@gmail.com>
>>> > To: "forge-dev List" <forge-dev@lists.jboss.org>
>>> > Sent: Monday, October 21, 2013 2:09:41 PM
>>> > Subject: Several architectural styles in Forge (was
>>> Wondering about coding convention)
>>> >
>>> > 2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 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.
>>> >
>>> >
>>> > Vineet, this is the topic I'm writing about at the moment. To be
>>> honest, I
>>> > quite like to have persistent concerns in JSF beans and REST for
>>> certain
>>> > projects... but not all, and that's where I thing Forge should give
>>> some
>>> > choices. What I'm writing is about having 3 different architectural
>>> styles
>>> > that could be resume like this (using CLI) :
>>> >
>>> > Current (generates JSF/REST from entities) :
>>> > jsf-scaffold-from-entity
>>> > rest-scaffold-from-entity
>>> >
>>> > EJB Centric (add a service layer to deal with persistence) :
>>> > ejb-scaffold-from-entity
>>> > jsf-scaffold-from-ejb
>>> > rest-scaffold-from-ejb
>>> >
>>> > REST centric (the JSF backing beans use the REST endpoint, using
>>> JAX-RS 2.0
>>> > Client API) :
>>> > rest-scaffold-from-entity
>>> > jsf-scaffold-from-rest
>>> >
>>>
>>> Very interesting. I was about to suggest linking any work in this space
>>> with FORGE-944.
>>> Overall, I get the impression that we should structure commands based on
>>> developer workflows given common architectural styles.
>>>
>>> I'll await your post.
>>>
>>> >
>>> > I will let you know when the post is written, it will be clearer
>>> >
>>> > --
>>> > Antonio Goncalves
>>> > Software architect and Java Champion
>>> >
>>> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>>> >
>>> > _______________________________________________
>>> > forge-dev mailing list
>>> > forge-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> _______________________________________________
>>> forge-dev mailing list
>>> 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/>
>>
>> _______________________________________________
>> forge-dev mailing list
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
--
Lincoln Baxter, III
"Simpler is better."
_______________________________________________
forge-dev mailing list
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
| Devoxx France <http://www.devoxx.fr/>
-
5. Re: [forge-dev] Several architectural styles in Forge (was Wondering about coding convention)
lincolnthree Oct 29, 2013 1:10 PM (in response to Antonio Goncalves )Perfect. This is exactly what we need Thank you!
On Tue, Oct 29, 2013 at 12:54 PM, Antonio Goncalves <
antonio.mailing@gmail.com> wrote:
Cool, I would be more than happy to contribute to that.
PS : @lincoln BTW, I've updated the JIRA related to the CLI syntax with
what you've just said :
>
2013/10/29 Lincoln Baxter, III <lincolnbaxter@gmail.com>
Hey Antonio!
>>
>> I'm definitely very interested in seeing more styles of programming
>> supported! I think this would be a great project. I am all for it.
>>
>> The interesting part will be trying to determine appropriate patterns for
>> each style. REST APIs vary greatly, but if we can find some kind of best
>> practice, which based on your blog, it looks like you already have an idea
>> of, then I think that makes our job much simpler (and it is a complex job
>>
>> So far, our command style is following this basic premise:
>>
>> jpa-new-entity (instead of entity --named)
>> jpa-new-embedable
>> jpa-new-mapped-superclass --named Person
>> jpa-new-entity --named Vet --extends Person
>>
>>
>> {spec alias or acronym}-new- >> {spec alias or acronym}--from-{something else}
>>
>> We have a dilemma with faces and CDI, though. Should we call them 'faces'
>> and 'rest' or "jsf" and "jaxrs", since we already have "jpa" "ejb" etc. I
>> think JAX-RS is the real issue, because most people know it as REST.
>>
>> But back on topic, yes, I'm all for this!
>> ~Lincoln
>>
>>
>> On Tue, Oct 29, 2013 at 9:49 AM, Antonio Goncalves <
>> antonio.mailing@gmail.com> wrote:
>>
>>> Hi Vineet,
>>>
>>> I've published the blog : http://antoniogoncalves
>>> .org/2013/10/29/several-architectural-styles-with-java-ee-7/
>>>
>>> I've implemented the three different architectural styles and you can
>>> have a look at : https://github.com/agoncal/agoncal-sample-javaee
>>> /tree/master/03-TierArchitecture
>>>
>>> Unfortunately I still have an issue with the RESTendpoint doing a
>>> paginate (I've asked some help in the jersey mailing list, but still no
>>> news, you can have a look at :
>>> https://java.net/projects/jersey/lists/users/archive/2013-10/message/64
>>>
>>> If you look at the code for the three styles, there are not many
>>> changes. I would hope that Forge could help developers to generate
>>> different architectural styles. As I said, we could do something like this
>>> (depending on the future syntax : https://issues.jboss
>>> .org/browse/FORGE-944)
>>>
>>> * Horizontal :*
>>>
>>> - jpa-scaffold-from-database
>>> - jsf-scaffold-from-entity
>>> - rest-scaffold-from-entity
>>>
>>>
>>> EJB Centric :
>>>
>>> - jpa-scaffold-from-database
>>> - ejb-scaffold-from-entity
>>> - jsf-scaffold-from-ejb
>>> - rest-scaffold-from-ejb
>>>
>>>
>>> REST centric :
>>>
>>> - jpa-scaffold-from-database
>>> - rest-scaffold-from-entity
>>> - jsf-scaffold-from-rest
>>>
>>> If that interests you, I would be more than happy to contribute to
>>> something like that.
>>>
>>> Antonio
>>>
>>>
>>>
>>>
>>> 2013/10/21 Vineet Reynolds Pereira <vpereira@redhat.com>
>>>
>>>>
>>>>
>>>> -
Original Message -
>>>> > From: "Antonio Goncalves" <antonio.mailing@gmail.com>
>>>> > To: "forge-dev List" <forge-dev@lists.jboss.org>
>>>> > Sent: Monday, October 21, 2013 2:09:41 PM
>>>> > Subject: Several architectural styles in Forge (was
>>>> Wondering about coding convention)
>>>> >
>>>> > 2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 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.
>>>> >
>>>> >
>>>> > Vineet, this is the topic I'm writing about at the moment. To be
>>>> honest, I
>>>> > quite like to have persistent concerns in JSF beans and REST for
>>>> certain
>>>> > projects... but not all, and that's where I thing Forge should give
>>>> some
>>>> > choices. What I'm writing is about having 3 different architectural
>>>> styles
>>>> > that could be resume like this (using CLI) :
>>>> >
>>>> > Current (generates JSF/REST from entities) :
>>>> > jsf-scaffold-from-entity
>>>> > rest-scaffold-from-entity
>>>> >
>>>> > EJB Centric (add a service layer to deal with persistence) :
>>>> > ejb-scaffold-from-entity
>>>> > jsf-scaffold-from-ejb
>>>> > rest-scaffold-from-ejb
>>>> >
>>>> > REST centric (the JSF backing beans use the REST endpoint, using
>>>> JAX-RS 2.0
>>>> > Client API) :
>>>> > rest-scaffold-from-entity
>>>> > jsf-scaffold-from-rest
>>>> >
>>>>
>>>> Very interesting. I was about to suggest linking any work in this space
>>>> with FORGE-944.
>>>> Overall, I get the impression that we should structure commands based on
>>>> developer workflows given common architectural styles.
>>>>
>>>> I'll await your post.
>>>>
>>>> >
>>>> > I will let you know when the post is written, it will be clearer
>>>> >
>>>> > --
>>>> > Antonio Goncalves
>>>> > Software architect and Java Champion
>>>> >
>>>> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>>>> >
>>>> > _______________________________________________
>>>> > forge-dev mailing list
>>>> > forge-dev@lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>>> _______________________________________________
>>>> forge-dev mailing list
>>>> forge-dev@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/>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> "Simpler is better."
>>
>> _______________________________________________
>> forge-dev mailing list
>> 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/>
_______________________________________________
forge-dev mailing list
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
"Simpler is better."
-
att1.html.zip 3.4 KB
-