> > > > > > > What's so magical in ant war task? > > It's written, fully supports the war model and has gone through lots of > testing. >
OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing > [snip] > > > > > Why web.xml should not be kept in src/webapp/WEB-INF? > > What's so wrong in it? Why Ant dislikes this? > > Nothing wrong. That works BTW. This is where I put my web.xml file... > I know it works... but prints this annoying warning message. > > > > > > I don't see any benefits which we gain using this ant target. > > Are you going to say the same with the Ant Jar task? Or do you plan to > extend it in the same way the War task does it? > > Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need "real Ant task" with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. This will solve a lot of problems (e.g. classloaders) But I am too extreme with this subject ... so please ignore me :) > > And personally I think that as much as possible of the code should be > done > > in pure java - not in jelly with help of ant. I think that that's the > > direction Maven should take. > > > > This will increase quality of the code, speed and code reuse. > > So from my point of view less dependencies on ant - better code. > > > > I'm completely +1 with this. Why do you say that War.java is not java? > It is java. But is has a lot of unnecessary stuff which makes plugins which are using ant more heavy. This price is worthed to pay as we can reuse a lot of nice ant's features. But if we are able in simple way to replace it with our own code which does the same but in better way - I think we should go for it. [...] > BTW, I think identifying the web.xml file is a good idea as it allows > you perform any kind of thing like validation, etc. Sure it is. We can even add a goal like war:validate-web-xml .... Note that in Ant you don't have standard properties which e.g. are pointing to location of your web.xml file. So Ant knows nothing about web.xml. In Maven we already have it. So we are already ahead with some conceptions and formalisms. I am sure this advantage will grow and we will be able to use it. You already do this with maven cactus plugin ... a lot of things is happening automatically. But if you have common set of classes which does a thing you can use it in maven-plugin, eclipse-plugin and in ant. You do not necessarily need to write code for ant and then try to reuse it. This was (as for me) one of the biggest problems with XDoclet1. But the lesson was learnt and Xdoclet2 will not have this limitation. BTW: Other thing I am trying to achieve is to centralize the generation of manifest file from POM. I am almost done with that. Will see how it overlaps with subject of this discussion. I don't know if I should always create a manifest file (physical file) or just an object in memory (String). Then manifest (file, object) can be used by jar, war and other plugins. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
