J2EE - what, if anything, does it mean to Bugzilla??

[Jason Pyeron]

So this is what happens when I am not at my computer...
[to find my responses search for $$$$]

On Wed, 3 Dec 2003, Joel Peshkin wrote:

> 
> Anybody have an idea of what a J2EE shop expects from its applications?  
> Must they all be WRITTEN in J2EE or is it an API?
> 
> Is there anything in particular that could make Bugzilla more friendly 
> to a J2EE shop??
> 

$$$$ Short answer, they want J2EE compliance http://java.sun.com/j2ee/
Longer answer:

J2EE is a methodology of programming, it covers RPC, Persistence, 
Data-Modeling, N-tier application development. J2EE is more a design 
pattern than anything else.

There are many tools/API implementations which are use in a J2EE 
environment. A "J2EE" shop will most likely have IDEs (JBuilder, etc.), 
App-servers (Websphere, Weblogic, etc.), developers familiar with Beans, 
Corba, UML, Java, (other languages via JINI)

any we organized "shop" will eat what they make, that means they will be 
using tools which support live code inspection, and tools which can reside 
on their (expensive) app-servers.

This means a marketable tool for a "J2EE shop" should conform to the 
Enterprise Bean Design patterns. (implies java?, don't know a ways around 
this other than lots of CORBA stuff)




On Wed, 3 Dec 2003, J. Paul Reed wrote:

> On 03 Dec 2003 at 21:55:15, Bruce Armstrong arranged the bits on my disk 
to s$
>
> > They'd want it written in Java, preferrable using
> > servlets or something similar (i.e., Scarab).
>
> J2EE doesn't read XML?
>
> Later,
> Paul

$$$$
Yes, a JavaBean, with a front end in a Servlet would be most 
liked/accepted.

J2EE is a design pattern, there are API's which read XML (xerces, etc..)

On Wed, 3 Dec 2003, J. Paul Reed wrote:

> On 03 Dec 2003 at 22:21:21, Bruce Armstrong [TeamSybase] arranged the bits on$
>
> > It's not a matter of whether it reads XML or not.  If
> > they're going to maintain it, customize it, etc.,
> > they're going to want it in the language they're
> > already fluent in (i.e., Java).  It also means they
> > would be able to deploy it into their existing
> > infrastructure (their J2EE/JSP servers).
>
$$$$ I don't think that most organizations will "maintain it" other than via 
a web interface. That said being able to give a "WAR" (web archive, more 
following) to the it people to put up on the App-server (they don't have 
'web' servers) is the only way for them. Most of our clients don't have the 
capability to put up a new machine or add software to their existing 
machines.


A war is a JAR following special design patterns. there is a special 
directory called WEB-INF inside it there are "private" details like 
configurations of users, a web.xml (like httpd.conf), code, libraries, 
etc. A war is designed such that it can be compiled (like tar czf) once 
and then be deployed/installed on any server.

A jar is a ZIP based archive, POSIX compliant version I think. 

> Then they don't want Bugzilla, plain and simple. Assuming you just wanted
> something to interface in certain clearly defined ways with Bugzilla, then
> getting information via XML for display in a J2EE application should work
> just fine.
>
> But if you're doing anything else, then don't use Bugzilla. I don't
> understand this preoccupation some people have with wanting to use
> Bugzilla, but in some other language.
>

$$$$ I tend to think of Bugzilla as a design, not the Perl code. So when 
someone asks for Bugzilla on there app server which only runs 'Java' 
applications, they DO STILL want Bugzilla.

If you allow for the possibility of constrained resources then asking to use 
XML/RPC to a machine running Apache w/Perl is a inappropriate. This is the 
basis for the "preoccupation". Almost all of our clients refuse to do 
something a different way, for some reason they think is a good one.

> There's already a Java-based bug tracker if you want that (Apache uses it,
> I guess). You (meaning Joel, I guess) should also talk to Jason (see bug
> 188570).
>
> Later,
> Paul


$$$$ as far as bug 188570, we are working full steam on it, but it changed 
course a little bit. I have decided that there seems to be to much anti 
java sentiment to produce something useful to the bugzilla community. That 
said we have taken the bugzilla schema, and some long term goals of bugzilla 
(security, security, security, customization, ISO 9001, etc..) and 
targeted it at that (BZ 3.0?). Once done we are going to port/track it to 
Perl as a (set of?) module. [we are not so much concerned with reports, charts, 
etc...) I am going to make a separate email for this...

Yes, I am asking to be flamed there, please be gentle.


On Wed, 3 Dec 2003, Bruce Armstrong [TeamSybase] wrote:

> FWIW, I understand it quite a bit.  People want to
> work with a language that they're fluent in.  And a
> number of people out there (myself included) are much
> more fluent in other langauges than they are in Perl.
>
> --- "J. Paul Reed" <preed at sigkill.com> wrote:
> > I don't understand this preoccupation some people
> > have with wanting to use Bugzilla, but in some
> > other language.
>
>
> =====
> Bruce Armstrong [TeamSybase]


$$$$ I think that is a moot point, the current developer community has 
precedent here. It is a Perl project, with Perl resources invested (us, 
the developers), the client (us the users) demands a high quality product.

there is no guarantee that here will be same caliber/quantity of resources 
for an other language. this means that expected quality may falter, hence 
we the customers would be very dissatisfied.

that said it is further inappropriate to ignore more resources and large 
client base (maybe larger?, at least more money)



-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Partner & Sr. Manager         Pyerotechnics Development, Inc. -
- +1 (443) 451-2697             500 West University Parkway #1S -
- +1 (410) 808-6646 (c)         Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you 
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.