I see no problem on having lots of tasks that do specialized work in one are of the other. Why should everyone rediscover the wheel if we can just give them one. These are the kinds of tasks that should be provided in separate libraries. A J2EEtasklib for example, containing all these WAR EAR deployment tools and so forth.
We get on these arguments because we are trying to control (maybe administer) every single task ever written and offerd to the larger comunity. That is unmanagable in the long run. Jose Alberto > -----Original Message----- > From: Les Hughes [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 21, 2001 1:45 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [SUBMIT] Ear.java task > > > > Hi, > > You could say the same thing about the WAR task and deprecate > that but like > I said, Ear just makes my life easier. I guess I look on JAR > as low level > and WAR and EAR as wrappers saving me the hassle of messing about with > zipfilesets. But you're right, we could end up with a load of > [A-Za-z]ar > tasks. > > Bye, > > Les > > > > > > -----Original Message----- > > From: Rosen, Alex [mailto:[EMAIL PROTECTED] > > Sent: 20 March 2001 17:59 > > To: [EMAIL PROTECTED] > > Subject: RE: [SUBMIT] Ear.java task > > > > > > > > Not really anything wonderful, I've hacked together an Ear > > > > task out of the > > > > War task, basically because I'm too lazy to keep using > > > > zipfilesets in Jar > > > > ;-) > > > > Now that we have zipfilesets, do we really need tasks for > EARs, client > > application JARs (CARs), resource adapter JARs (RARs), and > > anything else Sun > > comes up with? Doesn't seem worth it to me... > > > > Alex > > >
