Hi,
I have committed my branch, it is somewhere in repository. This branch has two new functionalities and 3 struts2 modules and changes to poms, new dependencies, one of which is not in maven2 repo.I couldn't find it anywhere in launchpad.
I am also not able to change any settings for blueprints assigned to me, it says i don't have enough privileges to perform this action.
regards,
murod
Hi Murod,
it would be very nice if you could separate the struts upgrade code from the rest as we definitely don’t want to have 3 of the web modules as struts and the rest with webwork. I know it’s too late in this case, but it’s good to develop different features in different branches. In this case I guess it must be done manually. Would be nice if you could do it, otherwise someone else will have to do it…
I will have a look at how to push branches soon.
cheers
Lars
On Sat, Apr 18, 2009 at 2:21 PM, Murodullo Latifov murodlatifov@yahoo.com wrote:
Hi,
I have committed my branch, it is somewhere in repository. This branch has two new functionalities and 3 struts2 modules and changes to poms, new dependencies, one of which is not in maven2 repo.I couldn’t find it anywhere in launchpad.
I am also not able to change any settings for blueprints assigned to me, it says i don’t have enough privileges to perform this action.
regards,
murod
Ok,
I will copy/paste ‘easy help’ and ‘dataelement history’ into trunk. struts2 modules are independent of other modules, original modules are still there, its just a matter of removing them as name from poms to exclude from compilation, code could be there for reference. But still fine we can do that later.
‘easy help access’ needs further work by manual writers. First we need to test it and then manual writers should add tags and translation strings accordingly. ‘dataelement history’ also needs causion, it has dependency which is not in maven2 repository at this time. I will commit, you can revert in case, is this ok?
regards,
murod
From: Lars Helge Øverland larshelge@gmail.com
To: Murodullo Latifov murodlatifov@yahoo.com
Cc: DHIS 2 developers dhis2-devs@lists.launchpad.net
Sent: Saturday, April 18, 2009 2:38:54 PM
Subject: Re: [Dhis2-devs] My branch
On Sat, Apr 18, 2009 at 2:21 PM, Murodullo Latifov murodlatifov@yahoo.com wrote:
Hi,
I have committed my branch, it is somewhere in repository. This branch has two new functionalities and 3 struts2 modules and changes to poms, new dependencies, one of which is not in maven2 repo.I couldn’t find it anywhere in launchpad.
I am also not able to change any settings for blueprints assigned to me, it says i don’t have enough privileges to perform this action.
regards,
murod
Hi Murod,
it would be very nice if you could separate the struts upgrade code from the rest as we definitely don’t want to have 3 of the web modules as struts and the rest with webwork. I know it’s too late in this case, but it’s good to develop different features in different branches. In this case I guess it must be done manually. Would be nice if you could do it, otherwise someone else will have to do it…
I will have a look at how to push branches soon.
cheers
Lars
Ok,
I will copy/paste ‘easy help’ and ‘dataelement history’ into trunk. struts2 modules are independent of other modules, original modules are still there, its just a matter of removing them as name from poms to exclude from compilation, code could be there for reference. But still fine we can do that later.
Great. I will have a look soon, seems nice…
‘easy help access’ needs further work by manual writers. First we need to test it and then manual writers should add tags and translation strings accordingly. ‘dataelement history’ also needs causion, it has dependency which is not in maven2 repository at this time. I will commit, you can revert in case, is this ok?
Frankly I don’t think we should add dependencies that are not in the central maven repo. It makes it harder for other developers. We could set up our own / use the one on hisp.info, but this server has not been stable at all lately and it feels better to only be dependent on the central one.
Also, I have had some second thoughts about this solution… Isn’t it a little overkill to change the persistence framework to accomplish this task? I agree that we should not reinvent the wheel and so on but in this case it seems just a matter of creating a DataValueModification object (or similar) and make add- and getall- functions.
Also, this makes us dependent on Hibernate. We have seen talk of switching the persistence layer. In that case this function must be re-implemented. If we put it in the service layer it will remain.
Not saying I have the answer, just a little sceptical, what do you think?
2009/4/18 Murodullo Latifov murodlatifov@yahoo.com
‘easy help access’ needs further work by manual writers. First we need to test it and then manual writers should add tags and translation strings accordingly. ‘dataelement history’ also needs causion, it has dependency which is not in maven2 repository at this time. I will commit, you can revert in case, is this ok?
Frankly I don’t think we should add dependencies that are not in the central maven repo. It makes it harder for other developers. We could set up our own / use the one on hisp.info, but this server has not been stable at all lately and it feels better to only be dependent on the central one.
Also, I have had some second thoughts about this solution… Isn’t it a little overkill to change the persistence framework to accomplish this task? I agree that we should not reinvent the wheel and so on but in this case it seems just a matter of creating a DataValueModification object (or similar) and make add- and getall- functions.
Also, this makes us dependent on Hibernate. We have seen talk of switching the persistence layer. In that case this function must be re-implemented. If we put it in the service layer it will remain.
Not saying I have the answer, just a little sceptical, what do you think?
Hi Lars,
We have many threads talking on easy installation, maintenance, porting to different environments, etc. What is the rational to move out of hibernate? Hibernate provides complete control and maintenance of underlying database. Can you imagine if someone in the field installs DHIS2 or upgrades and there are database schema changes? I don’t think he will succeed if we are not using hibernate. iBATIS does not this, JPA does not, moreover they are database dependent, especially iBATIs. If we decide to go iBATIS, it is not good idea, than it becomes type of javascript, kill bug for mySql, kill bug for Postgress, H2, H3, H365. Here is some research done: http://seasar.javaeye.com/blog/233951.
Sorry that I am talking to much but to honest we should make decisions that give long term solutions. Spring (AOP, DI, Security), Hibernate, MySQL, Struts2 or Spring MVC are well integrated, tons of documwentations. I am SQL and SP guy, but still feel hibernate is perfect solution for DHIS2 context. We have very few experts in the field and maintenance becomes a bottleneck if we don’t use hibernate. We should learn and improve hibernate, make its performance faster.
Other thing I want to point here is use of @nnotations. If we manage to implement all this, we have to write POJOs, say @Entity, @Secured, @Audited and thats all. We have many blueprint marks, which fall into this category, type of general consideration, which IMHO should be discussed and decided in combination (Spring Hibernate, Spring Security…).
I would call core developers to have skype discussion or actively participate into discussions before we come to make certain “general rules”, which should be followed after and we don’t face deadlocks (time spent for development, resources used). Like we have saying, make code Java1.5 compliant, this is known and all follow it. And if we decided to move out of hibernate for some reason, we should state that, by the same means as java1.5, remove such dependencies from pom and thats it.
Its bad that I am sometimes on and off depending on my research needs, I might have missed some points made by others earlier, please correct me if I am wrong.
regards,
murod
We have many threads talking on easy installation, maintenance, porting to different environments, etc. What is the rational to move out of hibernate? Hibernate provides complete control and maintenance of underlying database. Can you imagine if someone in the field installs DHIS2 or upgrades and there are database schema changes? I don’t think he will succeed if we are not using hibernate. iBATIS does not this, JPA does not, moreover they are database dependent, especially iBATIs. If we decide to go iBATIS, it is not good idea, than it becomes type of javascript, kill bug for mySql, kill bug for Postgress, H2, H3, H365. Here is some research done: http://seasar.javaeye.com/blog/233951.
Sorry that I am talking to much but to honest we should make decisions that give long term solutions. Spring (AOP, DI, Security), Hibernate, MySQL, Struts2 or Spring MVC are well integrated, tons of documwentations. I am SQL and SP guy, but still feel hibernate is perfect solution for DHIS2 context. We have very few experts in the field and maintenance becomes a bottleneck if we don’t use hibernate. We should learn and improve hibernate, make its performance faster.
I completely agree with you. I think Hibernate is doing a very good job for us and I have no intention of moving away from it.
Why I made the comment on moving persistence code into a separate project is to improve the design and benefit from our layered design; it is good design to be able to switch it even if we don’t want to do it:)
Other thing I want to point here is use of @nnotations. If we manage to implement all this, we have to write POJOs, say @Entity, @Secured, @Audited and thats all. We have many blueprint marks, which fall into this category, type of general consideration, which IMHO should be discussed and decided in combination (Spring Hibernate, Spring Security…).
These are exiting features. These annotations are general for Java 5 right? In that case the code will stay unaware of which persistence framework is being used. My argument of being dependent of Hibernate is then invalid.
Other thing I want to point here is use of @nnotations. If we manage to implement all this, we have to write POJOs, say @Entity, @Secured, @Audited and thats all. We have many blueprint marks, which fall into this category, type of general consideration, which IMHO should be discussed and decided in combination (Spring Hibernate, Spring Security…).
These are exiting features. These annotations are general for Java 5 right? In that case the code will stay unaware of which persistence framework is being used. My argument of being dependent of Hibernate is then invalid.
No, these annotations are hibernate, spring, JPA dependent, they are java 5 compliant. If we don’t deploy envers.jar we cannot use @Audited, as it is implemented there.
Yes OK, but the annotations themselves are JDK, not Hibernate…? So that one could change the underlying persistence framework and rely on them to “implement” the annotations?
2009/4/18 Murodullo Latifov murodlatifov@yahoo.com
No, these annotations are hibernate, spring, JPA dependent, they are java 5 compliant. If we don’t deploy envers.jar we cannot use @Audited, as it is implemented there.