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.