Parancoe evolution
Lucio Benfante
I would like to expose and discuss with all of you my ideas about the
future development of the Parancoe project.
At present I'm very satisfied and proud of our meta-framework. I'm using
it in 4 my projects clients, and I have a client which is adopting it as
its main base for some development activites. Another parancoe-based
project will start in the next weeks (more news about this soo, I
hope). I'm even using the parancoe-core part in a portlet project.
What next, so?
Infrastructure: I think it's time to migrate to a distributed SCM
system. I know some of you are using Git. At present I'm using Mercurial
for some projects (for example JUG Events), and I like it. I think there
aren't much real differences between Git and Mercurial. I found
Mercurial a little easy to use, but probably it's just a question of
experience and habit. Moreover, at present Google Code has support only
for Mercurial, so the choice is pretty obvious, if we don't want to
change all the project infrastructure (and I wouldn't want).
Parancoe 3 (as soon as possible)
The main focus is on the migration to Spring 3 and to Junit 4. Moreover
I would like to start a process of modularization, ending to a Parancoe
4 release (more on this later).
In details:
* Updating to Spring 3.0 (3.1 will be available in the 2nd quarter of
2010...so in this phase probably we could nicely match the Spring versions)
* Updating to JUnit 4
* Rewriting of the Web archetype, and of the documentation, for
supporting and suggesting a RESTful style of development of a Web
application
* Extraction of the persistence part of Parancoe in its own independent
project (suggestions about a cool name are welcomed). The reason of this
extraction is for having an easy development of this part, and for an
easy adoption even in non-Parancoe projects (for example for Swing or
JavaFX applications), already possible, but not as easy as it could be.
Moreover I would like to try to support more persistence frameworks, not
only Hibernate.
* Trying to separate in parancoe-* modules and in parancoe plugins as
much code as possible, with a fine-grained attitude (for example I
already can imagine a parancoe-test-support module)
* Adoption of the new validation introduced with Spring 3.0, deprecating
(but still supporting, for the moment) our own method
Parancoe 4 (1-2 years...but starting in parallel with Parancoe 3):
support and guidelines for developing Web applications in an OSGi
architecture. I would like totally dynamic applications and
parancoe-plugins. During the last Devoxx I already seen some methods for
developing a such kind of applications, but it's not as easy and
productive as I expect from a Parancoe tool. We need a lot of thinking
about this...
Looking forward for your comments...
Kind regards,
Lucio
--
Lucio Benfante
JUG Padova http://www.parancoe.org ...have a look at it!
www.jugpadova.it http://www.jugevents.org
Enrico Giurin
Lucio Benfante wrote:
> Hi,
> I would like to expose and discuss with all of you my ideas about the
> future development of the Parancoe project.
>
> At present I'm very satisfied and proud of our meta-framework. I'm using
> it in 4 my projects clients, and I have a client which is adopting it as
> its main base for some development activites. Another parancoe-based
> project will start in the next weeks (more news about this soo, I
> hope). I'm even using the parancoe-core part in a portlet project.
details soon.
> What next, so?
>
> Infrastructure: I think it's time to migrate to a distributed SCM
> system. I know some of you are using Git. At present I'm using Mercurial
> for some projects (for example JUG Events), and I like it. I think there
> aren't much real differences between Git and Mercurial. I found
> Mercurial a little easy to use, but probably it's just a question of
> experience and habit. Moreover, at present Google Code has support only
> for Mercurial, so the choice is pretty obvious, if we don't want to
> change all the project infrastructure (and I wouldn't want).
because I have not big confidence using them.
> Parancoe 3 (as soon as possible)
>
> The main focus is on the migration to Spring 3 and to Junit 4. Moreover
> I would like to start a process of modularization, ending to a Parancoe
> 4 release (more on this later).
> In details:
>
> * Updating to Spring 3.0 (3.1 will be available in the 2nd quarter of
> 2010...so in this phase probably we could nicely match the Spring versions)
could gain by using spring 3.0 instead of the current 2.5 version?
> * Updating to JUnit 4
>
> * Rewriting of the Web archetype, and of the documentation, for
> supporting and suggesting a RESTful style of development of a Web
> application
application using the only parancoe-core module, that is the parancoe
persistence layer.
> * Extraction of the persistence part of Parancoe in its own independent
> project (suggestions about a cool name are welcomed). The reason of this
> extraction is for having an easy development of this part, and for an
> easy adoption even in non-Parancoe projects (for example for Swing or
> JavaFX applications), already possible, but not as easy as it could be.
> Moreover I would like to try to support more persistence frameworks, not
> only Hibernate.
on is the parancoe-core, I started the project using the structure of
the basic persistence.example, but not the best way actually.
> * Trying to separate in parancoe-* modules and in parancoe plugins as
> much code as possible, with a fine-grained attitude (for example I
> already can imagine a parancoe-test-support module)
>
> * Adoption of the new validation introduced with Spring 3.0, deprecating
> (but still supporting, for the moment) our own method
>
> Parancoe 4 (1-2 years...but starting in parallel with Parancoe 3):
> support and guidelines for developing Web applications in an OSGi
> architecture. I would like totally dynamic applications and
> parancoe-plugins. During the last Devoxx I already seen some methods for
> developing a such kind of applications, but it's not as easy and
> productive as I expect from a Parancoe tool. We need a lot of thinking
> about this...
>
> Looking forward for your comments...
support, introducing the concept of group of users, improving
stability of security annotation methods.
Again I would like to improve the parancoe-fixture project with the
possibility to populate tables even for the entities which have no dao
associated, that is using the super dao.
Another idea is about the creation of a simple eclipse plugin which
allow to the developer to create the pair DAO/POJO automatically
wihtout having to remember to extend interface or adding annotations.
Last but not least, adding CI support to parancoe using hudson for
instances.
Lucio Benfante
I do agree with you, just was wondering if there is any benefit we could gain by using spring 3.0 instead of the current 2.5 version?