> -----Original Message----- > From: Michal Maczka [mailto:[EMAIL PROTECTED] > Sent: 18 June 2003 12:44 > To: 'Maven Developers List' > Subject: RE: Recent changes in war plugin > > > > > > > > > > > > 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
If you keep using the Ant jar task and do not write a single line of java, then I'm 0. BTW, why would you need to write some java code? > > > > [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. That's easy to fix by excluding it (same as what is done for the ear plugin). > > > > > > > > > > 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. Oh ok, so you're also saying that the Ant Jar/Zip tasks do nothing... I'm definitely -10 to reimplement the Jar task from Ant. > > This will solve a lot of problems (e.g. classloaders) I have heard of these "issues" but I've never encountered any when using the Ant War/Jar/Zip java tasks. > > 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. I don't call War.setProject(new Project().init()) a "lot of unnecessary stuff". Ok, it would have been better without, but it's not that bad compared to the benefits you get. > 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. No. I would continue to be -1 for a reimplementation of the Zip/Jar/War tasks in java. You seem to be missing that for every line of code you write instead of reusing: - you have to test it - you have to document it - you are upping the bar for any newcomer to participate to development (the more code the less easy it is usually) - you must maintain it - fix bugs - add new features that you had forgotten to add initially I'd much rather have all these done by another project... Thus, I also like to write code but it really has to be worth it, IMO.... especially as we have so many other important areas of improvements in maven land... :-) > > [...] > > > > 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. I was talking about the fact that you said it wasn't interesting to have a wewbxml attribute in the war task. I was not agreeing to that. > 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. Err... we're changing subject here, no? :-) > > > > 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. This already exists in Ant: it's called <manifest> (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? If you were implementing a framework in commons, I would agree with your approach, i.e. make available some java classes for creating Manifest, Wars, etc. However, I don't think it is the role of the Maven project to create these classes. Anyway, that's my personal opinion and if all the other committers agree with your approach I'll bend to the majority. Thanks -Vincent > > > Michal > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
