jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Ferguson" <William.Fergu...@contractorsolutions.com.au>
Subject RE: EarArchive, WarArchive, JarArchive
Date Tue, 02 May 2006 01:22:52 GMT

> -----Original Message-----
> From: felipealists@gmail.com [mailto:felipealists@gmail.com] On Behalf
> Felipe Leme
> Sent: Thursday, 27 April 2006 1:32 PM
> To: Cactus Developers List
> Subject: Re: EarArchive, WarArchive, JarArchive
> How exactly would EarParser use the new classes? I mean, currently the
> parse() method instantiate a DefaultEarArchive; would you be creating
> a new method that takes the EarArchive as parameter and refactor the
> current method to call the new one?

No, #parse would still be point of access and still take a File. If the
File is actually a File the a DefaultEarArchive is created, but if not
(it is presumably a Folder) then an ExplodedEarArchive is created.
Everything else remains the same.

BTW do we really need the checkstyle constraint that limits the line
length to 80 chars? Its making some of the code extremely unreadable and
who uses such a limited viewpoint nowadays? I'd bump it to at least 120.
Personally 160 would suit me fine.

> > 2) Change them to implement the Cargo interfaces now, but this means
> > that EarParser (WarParser should be changed too) would have to rely
> > the Cargo implementations.

OK, this is the approach I have taken. That's why it took so long -
I believe we can now remove all of the existing Cactus Archive
implementations and there associated classes as I'm pretty sure I have
switched everything over to use Cargo now.

The Exploded Archive implementations that I have introduced should also
be submitted to Cargo. I'll look at doing so soon.


To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org

View raw message