|
List Info
Thread: Re: Jtrac Install Log
|
|
| Re: Jtrac Install Log |
 
United Kingdom |
2007-09-12 04:35:46 |
Hi Peter,
Peter Thomas wrote on 12 September 2007 08:02:
> Hi Tim,
>
> Sorry for the delay, I just scanned through the first
part of your
> mail and stopped because I really think you missed one
thing: to RTFM
> !
Well you would say that wouldn't you 
But I would say that software developers should
favour 'Convention over Configuration' and
that a Maven project that doesn't 'just work' is broken.
The log is a realtime log, slightly tidied up, of what I
actually did over
three days.
It should have read:
>> Downloaded from svn
>> Typed mvn install jetty:run
>> and was presented with the configuration screen on
>> http://localhost:8080/
>>
>> Thanks!!
That there is a need to RTFM for a simple issue tracker is a
problem.
> If you had gone through these links, I think it would
have saved you
> a lot of trouble:
>
> http://jtra
c.info/doc/html/dev-guide.html
>
> http://j
trac.info/doc/html/installation.html
By the end of the installation I have read all the docs, but
I shouldn't
have to!!
The assumptions about how I want to use the software are
wrong,
it is this that I am trying to communicate: I am not a
grateful user who is
thankful that you have kindly given me your software:
I am a slightly peaved developer who is trying to help you
improve from
what is currently quite a broken position.
> But appreciate your feedback, can you let me know how
your experience
> is once you follow the instructions and all and I would
like to
> respond to your other points, and make changes to JTrac
/ build steps
> if required.
My experience is that the application is rather broken.
I have integrated it with Melati, so one can now see what is
going on at the db level.
I like the integration with Excel, this seems to be better
than using a
plain CSV,
though I believe it is possible to separate the concerns so
that you can
have
the styling in a static file which reads its data from a
plain CSV.
The data design is too abstract: these are not spaces and
items
they are projects and issues.
The hardcoded key conventions are not flexible so this
system cannot
readily
integrate with existing setups.
The hardcoded spare fields is not nice, in Melati one would
just add new
fields as required.
The table naming conventions do not follow the class naming
conventions.
The user interface is not easy to use or understand.
I am not convinced by the metadata handling, but I will
investigate it
further.
I have yet to understand wicket, but that is a problem.
I have a problem understanding why one would use
Spring/Hibernate for
what is never going to be a multi-jvm application.
I think that the dual use of Maven and ant is a mistake: the
Maven build is
broken,
which seems to imply that you must be relying upon ant.
If you are goping to have a dual build then you need
continuous integration
running both builds to ensure that both work all the time
and that the
results of both
are identical: a lot of work for no benefit.
Stop sitting on the fence and throw ant away!!
I have only looked at my own software in my IDE of choice
(Eclipse),
but Eclipse does complain about quite a lot of trivial
issues with the
code.
I have made a lot of changes locally, would you like me to
send them to you
as a patch?
I tend to want write access to projects that I am involved
with, is this
ever likely
on jtrac?
My current feeling is that the way forward is to use jtrac
as a starting
point
for a rewrite using Melati and then do some time trials.
yours
TimP
http://www.
context-computing.co.uk/~timp/
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
j-trac-users mailing list
j-trac-users lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/j-trac-use
rs
|
|
| Re: Jtrac Install Log |
|
2007-09-14 04:02:04 |
|
Hi Tim,
Since you have repeatedly implied that JTrac is "broken" I feel it is important to respond.
Positive feedback from users about the existing JTrac developer-guide can be found if you scan the forums and mailing list. ; Here is a blog entry (from a .NET developer mind you) who was able to set up things with ease:
http://industrialsomething.org/weblog/?p=107
I have seen developers who had absolutely no exposure to Maven at all get up and running building JTrac in no time. ;
But I will be the last person to claim that the JTrac build is perfect. It
can certainly be improved and I will keep working on it. For example, what
was the biggest problem for you will be easily solved if the custom
plugin is hosted on a publicly accessible Maven2 repository say on the
JTrac web-site.
But I completely disagree with your comment that the condition of the build is "quite a broken position". Actually you find everything wrong with JTrac, the architecture, the naming conventions, the database design, the UI design, everything. And then, you have the audacity to ask me for developer commit rights! Wow.
I am not going to waste my time responding point-by-point to all your complaints. There is one particular comment you made however to which I will respond which is:
I have yet to understand wicket, but that is a problem.
I think that says everything that needs to be said. ; You don't know anything about Wicket at all, and surprise! You have a problem with JTrac!
Cheers!
Peter.
On 9/12/07, TimP < timp_workpaneris.org">timp_workpaneris.org> wrote:
Hi Peter,
Peter Thomas wrote on 12 September 2007 08:02:
>; Hi Tim,
>
> Sorry for the delay, I just scanned through the first part of your
> mail and stopped because I really think you missed one thing: to RTFM
>; !
Well you would say that wouldn';t you
But I would say that software developers should
favour 'Convention over Configuration' and
that a Maven project that doesn't 'just work' is broken.
See my initial comment. The project did not work for you, but that does not make it broken for other people.
The log is a realtime log, slightly tidied up, of what I actually did over
three days.
It should have read:
>;> Downloaded from svn
>> Typed mvn install jetty:run
>> and was presented with the configuration screen on
>> http://localhost:8080/
>>
>> Thanks!!
That there is a need to RTFM for a simple issue tracker is a problem.
Maybe JTrac is not as simple as you think it is. And the RTFM applies to developers, *not* users of JTrac. I hope you don't think that because the JTrac build is "broken" (and that's just your opinion) - the application itself is broken?
> If you had gone through these links, I think it would have saved you
> a lot of trouble:
>
> http://jtrac.info/doc/html/dev-guide.html
>
> http://jtrac.info/doc/html/installation.html
By the end of the installation I have read all the docs, but I shouldn9;t
have to!!
The assumptions about how I want to use the software are wrong,
it is this that I am trying to communicate: I am not a grateful user who is
thankful that you have kindly given me your software:
I am a slightly peaved developer who is trying to help you improve from
what is currently quite a broken position.
> But appreciate your feedback, can you let me know how your experience
> is once you follow the instructions and all and I would like to
> respond to your other points, and make changes to JTrac / build steps
> if required.
My experience is that the application is rather broken.
Aha! ; So now you say that the application is broken. So it is not just the build, is it?
I have integrated it with Melati, so one can now see what is
going on at the db level.
I like the integration with Excel, this seems to be better than using a
plain CSV,
though I believe it is possible to separate the concerns so that you can
have
the styling in a static file which reads its data from a plain CSV.
The data design is too abstract: these are not spaces and items
they are projects and issues.
Nope. JTrac is not restricted to "issues" it can be tasks, bugs, etc. I have a similar reasoning for Spaces.
The hardcoded key conventions are not flexible so this system cannot
readily
integrate with existing setups.
The hardcoded spare fields is not nice, in Melati one would just add new
fields as required.
The table naming conventions do not follow the class naming conventions.
The user interface is not easy to use or understand.
I am not convinced by the metadata handling, but I will investigate it
further.
I have yet to understand wicket, but that is a problem.
I'm not responding point by point to all what *you* consider are problems but this I cannot resist. Because you don't know Wicket - you say that is a problem? I think
I have a problem understanding why one would use Spring/Hibernate for
what is never going to be a multi-jvm application.
I think that the dual use of Maven and ant is a mistake: the Maven build is
broken,
which seems to imply that you must be relying upon ant.
If you are goping to have a dual build then you need continuous integration
running both builds to ensure that both work all the time and that the
results of both
are identical: a lot of work for no benefit.
Stop sitting on the fence and throw ant away!!
I have only looked at my own software in my IDE of choice (Eclipse),
but Eclipse does complain about quite a lot of trivial issues with the
code.
I have made a lot of changes locally, would you like me to send them to you
as a patch?
I tend to want write access to projects that I am involved with, is this
ever likely
on jtrac?
My current feeling is that the way forward is to use jtrac as a starting
point
for a rewrite using Melati and then do some time trials.
yours
TimP
http://www.context-computing.co.uk/~timp/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
j-trac-users mailing list
j-trac-userslists.sourceforge.net">
j-trac-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/j-trac-users
|
[1-2]
|
|