|
List Info
Thread: JTrac initial impressions
|
|
| JTrac initial impressions |
 
United States |
2007-03-12 01:34:07 |
Hi gang,
Just wanted to report some initial impressions & success
with using
JTrac.
First off, thanks for putting the effort into sharing the
project!
It's one thing to have some working code and another to get
it robust
enough to share.
Secondly, it was an unexpected treat to see the project
using
Wicket. w00t!
A couple of deployment observations: First off, I'm using
PostgreSQL
and there's some issues getting things started up properly.
The
mapping of the 'locked' column is causing problems. The fix
seems to
be giving the column an attribute of
'type="boolean"', and presumably
for the other boolean in there. Does this not work on all
databases?
As I went in to start debugging this, the current source
tree (r823)
is not compiling. info.jtrac.Version apparently didn't get
checked
in, and also there's some issues with a String converter in
info.jtrac.wicket.JtracCheckBoxMultipleChoice and
info.jtrac.wicket.DatePicker. Nothing that a CI instance
wouldn't
have found.
Finally, I was trying to get LDAP running and did all the
bean
wiring, but looking at JtracImpl.loadUserByUsername(), it
appears
that Acegi and the bean hierarchy is being completely
ignored. Am I
missing something?
Apologies if some of this has been posted on the list, the
mailing
list archives seem to be unreachable from all the website
links I can
find.
best regards,
Brian
------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
j-trac-users mailing list
j-trac-users lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/j-trac-use
rs
|
|
| Re: JTrac initial impressions |
|
2007-03-12 04:46:27 |
|
First off, thanks for putting the effort into sharing the project!
It's one thing to have some working code and another to get it robust
enough to share.
You're welcome : )
Secondly, it was an unexpected treat to see the project using
Wicket. w00t!
A couple of deployment observations: First off, I'm using PostgreSQL
and there's some issues getting things started up properly. The
mapping of the 'locked' column is causing problems. The fix seems to
be giving the column an attribute of 'type="boolean"9;, and presumably
for the other boolean in there. Does this not work on all databases?
As I went in to start debugging this, the current source tree (r823)
is not compiling. ;
info.jtrac.Version apparently didn't get checked
in, and also there's some issues with a String converter in
info.jtrac.wicket.JtracCheckBoxMultipleChoice and
info.jtrac.wicket.DatePicker. Nothing that a CI instance wouldn';t
have found. T here is a change in the latest build approach so that the developer is prompted by the Ant script to enter
"Release Version:" This is just some
automation to make the process of releasing a new version of JTrac
simpler. When you are in development mode - this question is asked only the first time you do anything that depends on the "compile" Ant target and then Version.java gets generated.
Also please refer the developer-guide
http://jtrac.info/doc/html/dev-guide.html - but it has not been updated to mention the Version.java thing (updated in SVN).
No t sure if you used Maven when you tried. Unfortunately for the moment the build is pointing to the Wicket snapshot which does change a little. So that explains the two compile errors you mention. If you follow the instructions in the Developer Guide you should be fine, let me know. ; And if you still have problems, just try deleting the org/apache/wicket folder in you local Maven repository [ look around in the ".m2" folder in
user.home ]
Do let me know, it could be that I'm on an outdated version of the Wicket jar. Once Wicket 1.3 is released this kind of problem will go away.
Finally, I was trying to get LDAP running and did all the bean
wiring, but looking at JtracImpl.loadUserByUsername(), it appears
that Acegi and the bean hierarchy is being completely ignored. Am I
missing something?
Yep. If you read my blog post, that explains it a little. Let me look at re-refactoring so that the user is loaded from Acegi.
Thanks,
Peter.
|
| Re: JTrac initial impressions |
United States |
2007-03-12 12:30:02 |
|
On Mar 12, 2007, at 2:46 AM, JTrac users mailing-list wrote:
IIRC, your link floated across Wicket IRC. Some of the content seems hazily familiar. A couple of deployment observations: First off, I'm using PostgreSQL
and there's some issues getting things started up properly. The
mapping of the 'locked' column is causing problems. The fix seems to
be giving the column an attribute of 'type="boolean"', and presumably
for the other boolean in there. Does this not work on all databases?
You might want to consider Hibernate Annotation s for configuration instead of hbm.xml. I'm sure there may be reasons to not do this, but I haven't found any yet. 
Not sure if you used Maven when you tried. Unfortunately for the moment the build is pointing to the Wicket snapshot which does change a little. So that explains the two compile errors you mention. If you follow the instructions in the Developer Guide you should be fine, let me know. And if you still have problems, just try deleting the org/apache/wicket folder in you local Maven repository [ look around in the ".m2" folder in user.home ]
Do let me know, it could be that I'm on an outdated version of the Wicket jar. Once Wicket 1.3 is released this kind of problem will go away.
Yes, I use Maven. I'm not even sure if I have Ant installed on this machine.
A different way to do this would be to have the build system generate a properties file on the classpath, and have the Version class read from that, or provide reasonable defaults if nothing was found. Then, under Maven, you would use a "filtered" resource, which would change ${project.version} (IIRC) to the current version number.
Finally, I was trying to get LDAP running and did all the bean
wiring, but looking at JtracImpl.loadUserByUsername(), it appears
that Acegi and the bean hierarchy is being completely ignored. Am I
missing something?
Yep. If you read my blog post, that explains it a little. Let me look at re-refactoring so that the user is loaded from Acegi.
This would be really helpful. I could probably have my arm twisted to contribute this as well.
best,
-b
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash j-trac-users mailing list j-trac-use rslists.sourceforge.net">j-trac-userslists.sourceforge.net
|
| Re: JTrac initial impressions |
|
2007-03-13 04:28:13 |
|
You might want to consider Hibernate Annotation s for configuration instead of
hbm.xml. I'm sure there may be reasons to not do this, but I haven't found any yet.
Ok, for the moment a single file holding all the mappings is convenient. Also as may have been evident from the blog post, I'm not really pro-annotations : )
Yes, I use Maven. I'm not even sure if I have Ant installed on this machine.
Ok, for the moment, the build needs Ant although it could move to Maven with minimal changes as that was the plan, all Maven naming conventions used etc. However for most people Ant that comes along with the IDE (
e.g. Eclipse / NetBeans) will do fine.
A different way to do this would be to have the build system generate a properties file on the classpath, and have the Version class read from that, or provide reasonable defaults if nothing was found.
Now why didn't I think of that? ; Will do this as soon as I get the chance, thanks!
Then, under Maven, you would use a "filtered" resource, which would change ${project.version} (IIRC) to the current version number.
Finally, I was trying to get LDAP running and did all the bean
wiring, but looking at JtracImpl.loadUserByUsername(), it appears
that Acegi and the bean hierarchy is being completely ignored. Am I
missing something?
Yep. If you read my blog post, that explains it a little. Let me look at re-refactoring so that the user is loaded from Acegi.
This would be really helpful. I could probably have my arm twisted to contribute this as well.
Thanks
|
[1-4]
|
|