axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Jordahl <t...@macromedia.com>
Subject RE: Compilation trouble
Date Mon, 14 Apr 2003 13:44:26 GMT

Well, that is in the docs directory of any release/nightly build.  I would think it would
be a great place to start if I were a newbie. :-)

In any case, I am +1 to moving the components that aren't 'mainstream' like JMS and Castor
to a single directory that I can exclude in IDEA with one step.

I have used IDEA to work on Axis since day 1, and especially with Idea 3.0, excluding a file
is simply a matter of right-clicking it in the compile window and selecting 'Exclude from
Compile'. I realize that someone not familiar with the code base would have trouble knowing
what is OK and what is a problem to exclude.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Kellogg, Richard [mailto:RKellogg@MICROS.COM] 
Sent: Monday, April 14, 2003 8:05 AM
To: axis-dev@ws.apache.org
Subject: RE: Compilation trouble

Has anyone seen:

Guide to building Axis
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/building-axis.html

It is listed in the Wiki.

Enjoy!
Rick Kellogg


-----Original Message-----
From: Steve Loughran [mailto:steve_l@iseran.com]
Sent: Sunday, April 13, 2003 11:46 PM
To: axis-dev@ws.apache.org
Subject: Re: Compilation trouble



----- Original Message -----
From: <Aaron.Knauf@vodafone.co.nz>
To: <axis-dev@ws.apache.org>
Sent: Sunday, April 13, 2003 14:09
Subject: Re: Compilation trouble


>
> Hi Steve,
>
> Thanks for your reply.  Using ant from in my IDE does get me started.  (I
> do use IDEA and refactoring is great).
>
> I agree that ant is a great tool.  I have been using it since version 1.0.
> (I contributed the original patch for the includesfile/excludesfile
> attributes.)  I have my doubts about using it in the manner that you do
for
> the Axis project, however.  I can see that it works, but it has several
> drawbacks:
>
> *    It encourages a poor division between core and non-core code.  (The
> lack of a plugin architecture is probably due, in part, to the general
> acceptance of this as a workaround.)
> *    The ant script is made more complex by the inclusion/exclusion of
> various bits of code.
> *    Keeping the ant script up to date with all of the required/optional
> libs and their versions becomes painful.  (As you can see, it simply
> doesn't get updated.)
> *    Setup is non-obvious for project newcomers.
> *    Compilation takes several seconds, instead of less than one second.

ooh, are you using jikes yet?

>
> If a plugin framework is considered desirable, perhaps a good way to start
> would be to make all of the current optional bits into addons?  Alongside
> that effort, a standard for packaging plugins, web services and handlers
> would also be a handy feature.  It would be useful to be able to include a
> deployment descriptor with the web service implementation and have axis
> find that automatically.  (Obviously, being able to override the config
> from the packaged descriptor without having to re-package it would be a
> requirement.)


one funny with the current build is that some things are nominally
optional -attachments, servlets, but you dont get a very useful axis.jar
without it. Actually you can usually get by without Axis, but if you are
going to use ant you do need a more thorough setup.


-junit and castor are both my fault; yes, we can clean those up in future.



Mime
View raw message