Closed Bug 188570 Opened 22 years ago Closed 16 years ago

System port - J2EE, Java, Servlet, JSP, Swing

Categories

(Bugzilla :: Bugzilla-General, enhancement)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jpyeron, Assigned: jpyeron)

References

(
URL
)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.0.3705)
Build Identifier: 

Perl->Java port. 
I see it as two steps:
1: generate an api test bed
2: generate the servlet/jsp/swing components

Our firm is going to starat on this. We would appreciate direction and 
integration.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Summary: System port - J2EE → System port - J2EE, Java, Servlet, JSP, Swing
A Java port of Bugzilla has already been done.  See http://scarab.tigris.org/ 
Feel free to help them out.

We use Perl because more people know Perl than know Java, and it's easier for
people to contribute.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Closing this RFE with out investigation is inappropriate. It should be 
desirable to have a java based UI. Our firm is willing to do the work, we feel 
it is appropriate to have it tightly linked to the core project. That being in 
your CVS repository.

We can go and redo from scratch, we can make use of the db schema, we can do 
this with out the help of your project. But we don’t want to go off on our own 
we want your input.

The reason ‘because more people know Perl than know Java’ is like saying lets 
not do a localization for Chinese because more people use English. 

We envision in the future a user can go Help->About->Support->Bugzilla from in 
the application. I understand if you personally or even a very large group of 
you don’t see the need, but that does not justify its nonexistence.


A Java port of Bugzilla has already been done.  See http://scarab.tigris.org/ 
Feel free to help them out.

this is incorrect, it is not compatible with Bugzilla.
there intension is a replacement, not a language port.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
OK.  I've posted a request for comments on this to developers@bugzilla.org.  If
you're undertaking this magnitude of a project you probably ought to subscribe
and take part if you haven't already (http://www.bugzilla.org/discussion.html).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just for clarification, was this a java-based client that would communicate with
an existing Bugzilla, or is this a replacement for the server-side?
Ok, we're talking about this on IRC, and we're all confused: do you want a new
client to interact with Bugzilla (for which you'd use Swing, etc.) or do you
want to rewrite Bugzilla using servlets and JSP?

Those are two different things; one we may be able to help you with; the other,
we probably won't help with.

There's no incentive to rewrite a product as big as Bugzilla in Java. Our
developers know perl, perl supports more platforms than Java, and we have a lot
of infrastructure (TT, etc.) in Perl.

Another reason why there's no reason to port Bugzilla to Java: it's just plain
stupid. Read http://www.joelonsoftware.com/articles/fog0000000069.html for an
explanation why.
URL: http://www.joelonsoftware.com/article...
>Ok, we're talking about this on IRC, and we're all confused: do you want a new
>client to interact with Bugzilla (for which you'd use Swing, etc.) or do you
>want to rewrite Bugzilla using servlets and JSP?

We do not want to change any aspects of the bookkeeping in Bugzilla, but we 
cannot run Bugzilla in environment which do not have Perl. 

That being said, from the review I have done of the code sofar:

we see a seperation in the following:

UI render
Validation
Storage

We hope to stay as close as possible to the UI layer.

after reading http://www.joelonsoftware.com/articles/fog0000000069.html it too 
justifies my point of view. I have come to realize I am not articulating my 
point. I will work on it and post a game plan.

btw, Perl does not run on our embedded controlers.
Sorry, but I don't understand why you want to run a bugzilla server on an
embedded controller. Can you elaborate a bit? Maybe I'm misunderstanding something.
Jason: it could be that you are under a misapprehension. 

- You do not need Perl to access a Bugzilla server - only an HTML 4 web browser
- The server is a single entity which runs, usually on a dedicated machine, on
  your network. It does not run on the hardware which bugs are being filed about.
- It would be possible to write a Java applet or application which communicated 
  with a Bugzilla server, instead of using the web pages - but what would be the
  point? Everywhere that has Java also has a web browser.

Gerv
The point I was trying to make is embodied in the ideals of your 2.20 
milestones; Improve front-end/back-end separation to improve code readability 
and provide the ability to regression test back-end. 

Currently there is no way to address environments where no Perl is allowed or 
available, where HTML is not useful or able to be rendered.

what it really boils down to is I see many separation layers in Bugzilla, your 
milestones will get you there. For our systems which don’t have Perl, we would 
like to use Java.

Even if my motives are suspect my methodologies should not be.

I don’t want to add any 'Enhancements' 
I don’t want to optimize it.
I don’t want to change the way it works.

I just want to translate the Perl to Java with the natural API boundaries and 
then write some AWT components for use in our applications.

We are currently charting the Bugzilla source from the tip. We are dividing up 
the tasks, as soon as we get a game plan roughed out, I will post it.

You do need Perl to access the back-end, currently. RE:
- You do not need Perl to access a Bugzilla server - only an HTML 4 web browser

Given on secure Network A there is no Perl. You deploy an Intranet Application 
as a host on Network A. The best place to the QA interface is one Network A, 
specifically embedded in your Intranet Application. RE:
- The server is a single entity which runs, usually on a dedicated machine, on
  your network. It does not run on the hardware which bugs are being filed 
about.

Not every place there is Java is there a HTML browser. Likewise not every place 
there is C, C++, Perl, Bash, … is there a web browser. You are right, there 
would be no point in an application which communicated with a Bugzilla server. 
RE:
- It would be possible to write a Java applet or application which communicated 
  with a Bugzilla server, instead of using the web pages - but what would be the
  point? Everywhere that has Java also has a web browser.

Please just remember some organizations work in environments which are unusual 
and/or have client stipulated regulations. Sometimes no Perl can be used.

P.S. Some of our intended applications:
 Damascus product: mobile sales counter hardware/software [Firmware/Software]
 Damascus Access Point: GPRS-VPN, GPS, WLAN, Battery backup [Hardware]
 Standard Intranet product: for use in government networks [Software/Server]
 Various Java applications [Software/Applets]

> For our systems which don’t have Perl, we would like to use Java.

I don't get this. Go down to PC World, pay 400 of your local currency, pick up a
box, bring it home, install Linux. You now have a Bugzilla server. You only
require one of these, and this is the only place Perl is required. 

_Perl is not required on the client._

> Given on secure Network A there is no Perl.

If the network is secure, what's the reason for banning Perl? Anything Perl can
do can be done in other languages, albeit with more effort, so there's no valid
security reason for banning Perl from a network.

I also don't get your "not everywhere has an HTML browser" point. Do your
engineers and QA people not have desktop machines with web browsers on them?

Gerv
Mr. Markham,

It is not necessary for you to understand why this is needed, but let it 
suffice, that it is needed in addition to the Perl code. We don’t make a habit 
of wasting our financial resources, but rather investing them where we see a 
decent return on investment.

What should be relevant in this discussion is how to proceed. We feel confident 
that a Java based API married closely to the Perl source is a feasible and 
reliable approach.

Sincerely,

Jason Pyeron

Mr. Pyeron:

> It is not necessary for you to understand why this is needed, but let it 
> suffice, that it is needed in addition to the Perl code. 

If you want the Bugzilla Team's help and assistance, you better make explaining
these questions for us a priority.

> We don’t make a habit of wasting our financial resources, but rather investing 
> them where we see a decent return on investment.

Same with us. Except we deal in temporal resources and weigh them against a
return on our (feature) investment for users.

In case you've never done open source before, I suggest you modify your
attitude. From what I've read, you're proposing a whole rewrite of a system that
works just fine as it is because you want to run it in an environment where you
haven't been able to sufficiently justify not running Perl. 

In other words, you haven't given sufficient justification for why we should
spend time porting a product that already works just fine where it is, something
which you're obviously not catching in that Joel on Software article. And then
you tell us that we don't need to understand why we should spend our time on
helping you port something, just that we should.

Uhm... no. Doesn't work like that.

We're telling how to achieve what you want by using our product. If you're not
willing to listen, then we can't help you.

-jpr
Yeesh, Paul, get a little more defensive why don't you...  :)

Earlier comments indicated Jason's team was going to do the work and they just
wanted input.  So he's not asking us to spend time on it.

The code is MPL.  He can just about do whatever he wants with it.  However,
we're under no obligation to put it into our CVS (which was also mentioned in an
earlier comment).

I'm still very confused about the intended use of this.  And until I get
unconfused I have no reason to support this, because I still don't see what the
point is.  I am also curious to see Gerv's comments (from comment 11) addressed.
 You want direction from us on how to proceed, but until we understand just what
it is you're trying to do (as mentioned above, I'm still really confused) it's
not real easy for us to give you any direction.
As I have said before, We wil post a game plan, a detailed game plan.
But we cannot drop everything and post it at midnight.
We will put together coherent descriptions, so for now lets put off the 
discussion. 

By weeks end we will have more to post.
OK, thanks!
We have started a line for line port of the code. see footnote 1 for an excerpt
We are tracking our port to the CVS tag Bugzilla_Stable.
We are only doing a port of the API, plus a test command line app for testing 
against the Perl version.
UI components like Template module are out of the scope of what is to be done 
at this stage.

What do we need:
* Opinions as to which CVS tag to track our port against?
* Occasional explanation about some cryptic Perl code (rare?)
* Opinions as to directions to leave open due to future trends anticipated in 
Bugzilla

What do you get:
* Java API for access into a Bugzilla system.
* Added exposure, usage, developers, etc...

How we plan to do it:
* No structure changes (hey feel free to hold us to this)
* No database fiddling.
* up-to-date issue: Monitor CVS commits on tag chosen, read notes for bug 
references, test the Java API for compliance to the issue/fix, create the fix 
as needed in the Java code.
* Listen to opinions
* Line for line port of code, in beginning.
* Build tester app to verify API.
* Let UIs be a separate project (another discussion its own)
* Establish a developer base, to track the Perl code & bug fix
* When bug is discovered in Java & Perl: submit patch for Perl before/with Java
* Propose creation of new Component in Bugzilla's QA system: jAPI (personally I 
think you should have an API Component for the Perl API too, instead of using 
Bugzilla-General)

Detailed Answers to questions raised:
* Jim Walters curious about the advantages we see... We have many times run in 
to clients who say, "We will not install Perl, do it some other way" not to 
mention most of out products are pure Java. Hell I cant count the time one of 
my clients called up and my first answer to them was install Perl, but we deal 
in a multi-vendor environment, mostly on windows, and our clients like most 
have counter productive rules. SHORT ANSWER: For environments where there is 
(only) Java, it would be a productive for Bugzilla to run on Java.
* David Miller raises the issue of keeping it up-to-date... As I have said, we 
are trying to build a developer base, read CVS logs, etc. SHORT ANSWER: We 
don’t know yet, but we have ideas and we need input on this.
* David Miller asks server-side or client-side... Not really sure yet how y’all 
define the breaks in your software yet, but leaning to server-side. 
Specifically the layer between the UI and the DB. We have run program traces on 
most of your code, marked it up allover the wall, no ink on the database schema 
and no ink once output is being sent to the client. SHORT ANSWER: server-side 
Perl modules, no UI.
* Gervase Markham raises questions about how any why Perl is not available... 
As a tangent answer to this, I still cannot get all the Perl modules working on 
my laptop windows box. But I am sure I spend more time I would solve the 
make/install issues. So under the assumption that Perl works there, we still 
have client IT department specifications. An example of this was CIENNA, we 
were helping them debug some ksh scripts, they needed to ssh into some machines 
to do this. Our contact came into work one morning with a note on his computer 
to see his boss. His boss told him that it was against company policy to 
install non-authorized software on the workstation, he appealed that it was to 
do his job, and it was never resolved (he used a web based ssh client). Another 
client (the government) when presented with a 25MB text file of data which they 
acquire each year, needed to be imported into there system. We were asked how 
to do it, and we suggested use Perl gave them a script. They replied that Perl 
was not on there system, and they were not going to install it, because it was 
not on a list approved software. Instead they paid 5000$ to have a vendor come 
in with a laptop, and load the data from the laptop (did he use Perl?). I can 
list oodles more cases, but I don’t think that would be necessary. SHORT 
ANSWER: Client said no to the Perl install.

If I missed any questions or concerns, please repost them clearly and concise 
and I will answer them.

Jason Pyeron

---footnote 1---
//globals.java

  // lines 103-107:
  main.put("dontchange","--do_not_change--");
  main.put("chooseone","--Choose_one:--");
  main.put("defaultqueryname","(Default query)");
  main.put("unconfirmedstate","UNCONFIRMED");
  main.put("dbwritesallowed",new Integer(1));

  // line 111:
  main.put("superusergroupset","9223372036854775807");

  // lines 186-192:
  //# This is used to manipulate global state used by SendSQL(),
  //# MoreSQLData() and FetchSQLData().  It provides a way to do another
  //# SQL query without losing any as-yet-unfetched data from an existing
  //# query.  Just push the current global state, do your new query and fetch
  //# any data you need from it, then pop the current global state.
  //#
  //@::SQLStateStack = ();
  main.getList("SQLStateStack").clear();

  // lines 329-330:
  //@::default_column_list = ("severity", "priority", "platform", "owner",
  //                        "status", "resolution", "summary");
  Object[] _a329=
{"severity", "priority", "platform", "owner", "status", "resolution", "summary"}
;
  main.getList("default_column_list").set(_a329);

  // line 615:
  main.put("VersionTableLoaded", new Integer(0));

Well, I know from personal experience that lots of places have rules about what
software they want to install. For a large comapny, those rules make lots of
sense when your're going to be gone in a few months, leaving their IT department
to manage a language they don't know (but see below)

However:

a) Bugzilla isn't standalone. We use lots of modules (DBI, CGI.pm, Template
Toolkit, etc) which you'd have to port, or at least emulate the interfaces to.
Note that we will start really using the DBI RSN rather than SendSQL, so you
have that to deal with too. Now, I suppose its not impossible to port TT to
java, but...

b) You'd have to track every change we make to the code with a corresponding
java change. If your goal is 'no perl at all', then the two things aren't going
to end up being integrated, so thats going to be _lots_ of work, and wasted effort.

c) "Specifically the layer between the UI and the DB". Well, thats all of
Bugzilla, really, since its a web browser which does the user<->UI interaction.

d) I'm not too sure how well the maintainability argument holds here. If company
X buys a generic oftware product form company Y, all they're going to get most
of the time is some compiled code, and thats not exactly maintainable either.

I guess my point is that 'only doing a port of the API' won't work, because the
external api is a CGI form submission, and so I can't see anythign which you
won't need to port. There are long term plans to make a 'stable' API for stuff
like XML-RPC, but thats a while off still.

Hypothetically, if you had a perfect c->java convertor, and ran that on the perl
source code, and then gave your clients this program called perl.class and some
'runtime support files' called bugzilla, would that make them happy? If so, then....

None of this precludes a java front end, though, talking to a perl backend using
xmlrpc or similar. that a whole different story, whcih of course depends on
actually having XML-RPC apis.
a quick clarification:

I defined UI as the code starting at 
print "Content-Type: text/html\n\n";
$template->process("index.html.tmpl", $vars) || ThrowTemplateError($template-
>error());

please let me know what you call this section of the code if not UI

this does mean the TT issue is moot, right?

now back to reading comment 18
I am beginning to see the fundamental communication problem here.

Bugzilla works this way (please correct me)

[DB Server] <--> [Server] <--> [Client]

on the DB Server there is a schema, and optional udfs, stored procedures etc.
The Server can be broken into two stages:
1: Business Logic 
   for example see lines –56 index.cgi stable tag
2: Rendering 
   for example see lines 58- index.cgi stable tag
the Client does more Rendering

Here is what we want to do:

Not touch the DB
Port the Business Logic to a Java API
Not worry about the Rendering Layer (UI) as that is a separate task.
Since the Rendering Layer is being omitted from the scope of this task, the 
concept of a Client is UNDEFINED. Assumptions about using http, html, web 
browser is not relevant.

Why break it down this way? It makes sense from a division of labor, it becomes 
maintainable, etc.

My opinion would be, ALL UI code should be part of another RFE.

We don’t need a full API port for our needs right now, but doing a **** 
job would be counterproductive not to mention inappropriate. 



I'd like to pick up on what bbaetz said:

> c) "Specifically the layer between the UI and the DB". Well, thats all of
> Bugzilla, really, since its a web browser which does the user<->UI interaction.

The UI is basically the templates (and a few lines of Perl to invoke them.)
Leaving those aside, my source-code line counter says that Bugzilla is 30,000
lines - 20,000 lines of non-comment source lines (NCSL). It's been extensively
field-tested and debugged. And you will need to rewrite basically all of it in
Java. And that's not counting the thousands of lines of code in Perl modules
that we use - DB interfaces etc - which would also need replacing.

I don't know what figures people use for kloc per programmer-year, but this is a
massive job by any standards. I really hope this "no Perl" company is
compensating you extremely well for this work. One would have thought a $200,000
bill for programmer time might make them rethink their policy, though. Or use
Scarab.

Gerv
Just a note to let others know that it has not gone stale, and we are working 
on this issue.
.
Assignee: justdave → jpyeron
Back logged right now with projects, but still working...
Personally, I'd love to see a version of Bugzilla in Java but there are a lot of
valid points listed above that need to be seriously considered before embarking
on such a massive project.

I agree that none of the Java options out there are up to scratch. Scarab is way
too bloated, Bugrat's (http://www.gjt.org/pkg/bugrat/) code is a big ball of mud
and iTracker  (http://sourceforge.net/projects/itracker) doesn't have all the
features of bugzilla yet.  Bugzero (http://www.websina.com/bugzero/) is nice,
but it isn't free.

None of them are compatible with the bugzilla schema which is important if you
want to convert existing bugzilla sites. Schema compatibility would also permit
a parallel run.

The port would have to offer some advantage over the existing version.  e.g.
faster, nicer interface, easy installation, database independence. 

I would *never* involve myself in a port that did it as a line-by-line
translation of the perl code. The resulting code would become unmaintainable
very quickly, not to mention buggy.

Perhaps this discussion belongs elsewhere .. on a wiki or something?  I'd love
to get involved in this further but only if it is going to be done properly with
clearly defined objectives.
I'm not convinced your advantages really stack up...

> The port would have to offer some advantage over the existing version.  e.g.
> faster, 

Bugzilla is fast enough for most installations - and mod_perl support, coming
very soon, will sort the big ones.

> nicer interface, 

How does the underlying technology define the UI? Or do you mean another sort of
interface?

> easy installation, 

Possibly - although it remains to be seen how many extra Java libraries one
would need, and CPAN is pretty smooth.

> database independence. 

Again, coming - but 95% of people don't care, as long as whatever DB you use is
easy to install, and doesn't require continuous care and feeding.

But then, I've always said this is a waste of time :-) If someone is so
Perl-phobic that they want a Java bug tracker, effort would be better spent
improving one of the current ones.

Gerv
Re comment #25:

I think part of the reason most people (or maybe just us developers?) see this
as a bad idea is because all of the noted benefits haven't *really* been shown
to actually exist:

> e.g. faster,

Says who?

Java's not known for its speed, and benchmarks show perl to be just a shade
slower than C in most cases. With mod_perl support, I'd be willing to put money
on the perl being faster, ASSUMING it's slower than Java would be now... and
having seen some Java web apps of similar complexity, I'm not convinced that
*that's* even the case.

> nicer interface,

If you want a nicer interface, than work on bug 16775 or spend some time
refining the templates so it "looks good enough" for you.

The solution *isn't* rewriting BZ in Java.

> easy installation,

Right... 'cause checksetup.pl and getting Bugzilla::Bundle is so hard (and most
Linux distros/Unix installations these days don't come with perl installed).
That, and Tomcat/Jakarta is a cinch to install and oh-so standard.

> database independence.

As Gerv notes, this is coming to BZ, but this, like your "better user interface"
point above, has nothing to do with implementation language. If you want
database independance, than work on bug 173130 and bug 98304. Don't rewrite it
in Java, which doesn't *automagically* provide database independence anyway.

If you guys really want a Java-based bug tracker, it really would be a better
idea to spend time working on one of the other already-existing Java-based bug
trackers you listed. This is not an attempt to be rude or unhelpful at all, but
to point out the obvious solution to save your time and effort in trying to
convert something that will *not* be a straight translation and our time in
trying to help you do so.
It appears that comment #26 and comment #27 both misread my offering.  To
reiterate, I said "The port would have to offer some advantage over the existing
version.", NOT "The port would have some advantages over the existing version."

In short, unless the Java port exhibited some tangible advantage then I don't
think it is worth doing. I don't think a Java port could ever be faster.

As far as the db goes, many companies I have worked for want to use their
existing database product for everything possible because they have admins who
know it inside out and have backup and disaster recovery in place.

In response to Comment #25 by Pards:

-The port would have to offer some advantage over the existing version.  e.g.
-faster, nicer interface, easy installation, database independence. 

VALID Reasons for Java port:
 Platform Independence (for systems where Perl does not/can not exist)
 Nicer Interface (this is very weak argument) for JSP based web servers

INVALID Reasons to port to Java:
 Speed
 Installation difficulty
 Database independence 

-Perhaps this discussion belongs elsewhere .. on a wiki or something?  I'd love
-to get involved in this further but only if it is going to be done properly
-with clearly defined objectives.

To address the clearly defined objectives:

 1: create a solution to run Bugzilla where PERL is prohibited and Java exists.
 1a: Milestone: Learn Bugzilla internals / rewrite in java / track against 
STABLE branch
 1b: Optimize java code into coherent API, and JSP Front-end (this is not going 
to be exactly same as Perl CGI version)

-I would *never* involve myself in a port that did it as a line-by-line
-translation of the Perl code. The resulting code would become unmaintainable
-very quickly, not to mention buggy.

We have chose to do it this way since there has not been a serious interest 
(willingness) to do it at all. That being said, we will keep on doing it our 
way until someone else decides assist, then we will look into a change in 
strategy.



We have started agianst the TIP!

I belive we can go at a sufficent pace to track against any commits that are 
done now.

 :)
We will have a swing application and applet release of the query engine by end 
of the week. Looking for java people to give pointers, etc...


asking for opinions or help in addressing part 2 of the two steps...

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25883
> Platform Independence (for systems where Perl does not/can not exist)
> Nicer Interface (this is very weak argument) for JSP based web servers

I don't get what systems would have java that wouldn't have perl. I have had 
Bugzilla up on both Win32 and Linux. The only real issues with perl are that 
it can be a pain getting the packages from CPAN when your perl installation is 
broken.

HTML works just fine, and is available at libraries and schools, etc where 
they might not have Java installed (and I have checked my bugmail while on 
vacation).

> We don’t make a habit of wasting our financial resources, but 
> rather investing them where we see a decent return on investment.

Then don't waste your money reinventing the wheel. Take that money and time 
and invest it in fixing what you don't like about Bugzilla instead of 
rewriting a program that was years in the making and is used by 100s of 
organizations. It won't be as easy as you think it will be.

> What should be relevant in this discussion is how to proceed. We feel 
> confident that a Java based API married closely to the Perl source is a 
> feasible and reliable approach.

The best course of action would be to help with the existing work to create a 
pure XML output (or other object format) and input for the CGIs, and then 
build the java and html systems on the other side of the layer. Go out and 
grab a throw-away AMD K6-2 system or something and add a little more mem and 
bigger hard drive and throw Linux on it. Will probably cost you $80. Get the 
O'Reilly camel book for perl and keep it by your side and dig through the Perl 
code.
             
Mysql
^
|
|              
 ---> Perl Bugzilla -> template-toolkit ----->Apache HTTP -------> html
               ^                                                   |
               |___CGI.pm <-----Environ Vars <---Apache------------- 

Current system??? (I think)

                                                               
                                                               |-perl ---> XUL
                                                               |
                                                               |-perl ---> HTML
                                                               |
Mysql <-----> Perl Bugzilla ----> template-toolkit ---> raw XML --> JSP (local)
                                                               |
                                                               --> intranet
                                                               |
                                                               --> apache
                                                                  (internet)

CGI would probably still be the best method (and simplest way) to continue the 
communication back to Bugzilla. You can simply use SSH for this if Bugzilla is 
on a different system than the JSP and capture the CGI output in SSH.

What is shown here is the XML layer that would be between Bugzilla and the 
various display systems. XUL would be a possibility. HTML would be another (I 
left out mentioning template-toolkit which would probably be used in the XML <-
> HTML stage along with the Apache server because I ran out of room). A local 
JSP daemon could have the data piped to it. The raw XML could also be sent out 
through HTTP to a remote GUI application on the internet, or a Java 
application on a different computer on the same intranet. Furthermore, mail 
could be handled through the same mechanism. The computer running perl 
wouldn't have to have any ports open except for the one communicating with the 
Java server on the same network that does all the display work (including 
sending the emails).

The best thing is that the XML could be standardized for all the GUI systems 
that use it to prettify Bugzilla.

This kind of thing would require a lot of coordination and most likely a 
seperate tree because it'd be hard to keep in sync with the current one. After 
it was working, changes in the existing system would have to be manually 
copied over to work through the XML layer instead. It also means you'll have 
to be willing to work together with the Bugzilla people that are possibly 
looking into such a thing, and you'll have to learn Perl.

The existing system would be broken down into the display code for HTML and 
the CGI code for handling Mysql.


The question is: Is it really worth it? I don't see how reinventing the wheel 
will improve your bottom line unless you are planning to sell this system. In 
conclusion, I recommend using Bugzilla as-is, and when you have more 
experience with the system, re-investigate providing a layer to other display 
formats.
                                                                 
re comment 33:

yes you have made all valid points but they are severly off topic.

>> Platform Independence (for systems where Perl does not/can not exist)
>> Nicer Interface (this is very weak argument) for JSP based web servers
>
> I don't get what systems would have java that wouldn't have perl. I have had 
> Bugzilla up on both Win32 and Linux. The only real issues with perl are that 
> it can be a pain getting the packages from CPAN when your perl installation 
> is broken.

Please take for a fact that THERE ARE places which perl cannot run, but Java 
can.

Here I will drop 2 names:
CIENNA, and US Congress, House or Reps, California 15th district.

I agree, they are idiots for such a decision, but that is thier decision,

NOT MINE, REPEAT, NOT MINE.

So once you are able to concede this point, please feel free to address it.


This thread has piqued my curiousity for two reasons, one of which is practical:

1. Mr. Pyeron, may be I missed something, but why is it a requirement that the
pure-java bug tracker be compatible with bugzilla, to the extent that you commit
yourself to tracking future updates to bugzilla?  Having worked extensively with
bugzilla codebase for the past couple of months, I'd wager that a clean re-write
against a cleaner schema that doesn't have all the bloat that you will never use
is perhaps a better approach, joel's article notwithstanding, and provided of
course that no other java solution at all answers your needs.  If compatibility
with bugzilla is still a firm requirement, I wonder if some existing java based
bug tracker could be modified to be compatible with bugzilla...

2. These points are moot, of course, since it sounds like you're well on your
way on your project.  In which case, my question is: have you approached the
second phase of it, i.e. have you refactored the business logic into a java API
of its own.  If you have, I'd be curious if I could use it.  If you are still
working on it, I'd be able to help on specific parts that are of interest to me
presently.

As a general point: such a java API would be useful, right here and right now. 
The reason is integration with other, java-based tools (or even compelete java
versions ...)  It doesn't matter that bugzilla currently is not amenable to such
an api internally (at least the 2.16 branch that I know and hack) -- it could be
implemented using a java http client, and later upgraded to xml-rpc or whatever
bugzilla eventually uses to expose its underlying functionality.

As a complete aside, I find it hilarious (although I'm not really sure why) that
someone would forbid perl but allow mysql.
QA Contact: mattyt-bugzilla → default-qa
Jason, it may be possible (and much simplier) to package Bugzilla (or Bugzilla client) into executable with PAR. It supports Wx. Both PAR (module) and Wx are crossplatform.

Jason, i completely aggree to your intentiation for and why porting to java. Many of our clients also have very restrictive policies on infrastructures and in 99% there is ! no ! Perl installed anyhow. So, how to participate in this development, planning, architecture, font-end renderes and so on?
We are not going to help porting Bugzilla core code to Java, nor are we going to have Java code in our CVS repo, for various reasons already described in previous comments (maintainability, sync problems, developer ressources, ...).

Porting Bugzilla code to Java is definitely another project. You are free to fork Bugzilla and start from here for your project.

If you want help to port Bugzilla to Java, use newsgroups for that, but this bug is not the right place to have this discussion -> WONTFIX
Status: NEW → RESOLVED
Closed: 22 years ago → 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.