Re: RFE for the war plugin
Send the patch in and lets talk it through. On Wed, 30 Jun 2004 09:38:22 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > First, let me apologize to the list for being short yesterday, it was > entirely born out of have to explain things 4 times and still getting > negative feedback that didn't address the issue. > > Ryan Sonnek wrote: > > >whoo now, i don't want to get involved, but i do want to let it be known that since > >this is an open source project, nothing is stopping you from adding the feature > >you're asking for. > >* download the source from cvs > >* make the change you're requesting > >* submit the change as a patch to JIRA. > >* hope that a commiter will take the patch and apply it to the codebase! =) > > > > > You are absolutely right and I'll endeavor to do that. However in a > messaged dated 06/29/04 09:11 M.M. so much as said it wouldn't be added > despite not bothering to look into it, or even understand what "it" was. > > I will attempt to create a patch for this and submit it though the > "proper" channels, in fact I think there was some code posted to the > list that would do the trick, and I'll start with that. > > Now, because I no longer trust that at least one developer on this list > actually understands how his (and therefor my) system works, is there > another developer with commit access that will review the request? > > > > - Brill Pappin > > - > 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]
Re: RFE for the war plugin
> Now, because I no longer trust that at least one developer on this list > actually understands how his (and therefor my) system works, is there > another developer with commit access that will review the request? Just add it to JIRA and explain better.. And see if someone picks it up or not.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
First, let me apologize to the list for being short yesterday, it was entirely born out of have to explain things 4 times and still getting negative feedback that didn't address the issue. Ryan Sonnek wrote: whoo now, i don't want to get involved, but i do want to let it be known that since this is an open source project, nothing is stopping you from adding the feature you're asking for. * download the source from cvs * make the change you're requesting * submit the change as a patch to JIRA. * hope that a commiter will take the patch and apply it to the codebase! =) You are absolutely right and I'll endeavor to do that. However in a messaged dated 06/29/04 09:11 M.M. so much as said it wouldn't be added despite not bothering to look into it, or even understand what "it" was. I will attempt to create a patch for this and submit it though the "proper" channels, in fact I think there was some code posted to the list that would do the trick, and I'll start with that. Now, because I no longer trust that at least one developer on this list actually understands how his (and therefor my) system works, is there another developer with commit access that will review the request? - Brill Pappin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 10:41 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > > Michal Maczka wrote: > > > > Have you tried to do it with the war? Coulpe of times. With different result sas some servlet contanier refused to work with them. > Did you even read that spec? Obviously not. > The classloader loads the jar and the respective versioning > information > not the webapp container that loads the war! Right classes and files in WEB-INF/classes META-INF are not loaded by any classloader. Gradma loads them. > Remember that in this day and age all list mail gets archived so what > you just said above will be preserved forever. > Here is what spec says: "Web containers are recommended to have a mechanism by which web applications can learn what JAR files containing resources and code are available, and for making them available to the application. Containers should provide a convenient procedure for editing and configuring library files or extensions. It is recommended that Application developers provide a META-INF/ MANIFEST.MF entry in the WAR file listing extensions, if any, needed by the WAR. The format of the manifest entry should follow standard JAR manifest format. In expressing dependencies on extensions installed on the web container, the manifest entry should follow the specification for standard extensions defined at http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. Web Containers should be able to recognize declared dependencies expressed in the manifest entry of any of the library JARs under the WEB-INF/lib entry in a WAR. If a web container is not able to satisfy the dependencies declared in this manner, it should reject the application with an informative error message." So realy the spec makes no difference between any of the manifest files which are provided inside wars and clearly defines where they can be placed. But for strange reason it says: "It is recommended that Application developers provide a META-INF/MANIFEST.MF entry in the WAR file listing extensions". Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
I don't want into this discussion either, but please remember that this is an open system and as such does allow for third-party plugins. If you can't find a committer willing to listen, scratch your own itch on SF.net or something, and be done with it. -j On Tue, 2004-06-29 at 16:57, Ryan Sonnek wrote: > whoo now, i don't want to get involved, but i do want to let it be known that since > this is an open source project, nothing is stopping you from adding the feature > you're asking for. > * download the source from cvs > * make the change you're requesting > * submit the change as a patch to JIRA. > * hope that a commiter will take the patch and apply it to the codebase! =) > > > -Original Message- > > From: Brill Pappin [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 29, 2004 3:41 PM > > To: Maven Users List > > Subject: Re: RFE for the war plugin > > > > > > > > Michal Maczka wrote: > > > > >On Tue, 2004-06-29 at 18:00, Brill Pappin wrote: > > > > > > > > >>I thought I had explained this? > > >> > > >> > > >> > > >You did not. > > > > > >[...] > > > > > > > > > > Actually yes I did, working backwards in time and no > > including the one > > quoted here: > > > > On Tue, 29 Jun 2004 08:53:47 -0400: > > "The reason I specifically want to do it, is so I can use the > > manifest > > to package extended information about the classes. I think I > > said that > > though..." > > > > At Monday, June 28, 2004 2:21 PM > > "Doing this allows me to use the manifest versioning, labeling and > > dependency parts of the manifest." > > > > I think there might even be a few others I missed. > > > > >>If you want to know more about what I'm doing (and why I'm > > asking for > > >>this), you can get a very good idea at this site: > > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > > >> > > >>Specifically take a look at the "Package Versioning > > Specification" which > > >>is link to the URL above, or at this URL: > > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/ve > rsioningTOC.html > >> > >> > >> > > > > > >Are you aware of the fact that servlet specification clearly defines the > >location in the war archive where manifest files should go? > > > > > [...] > > >IMO there is absolutely no difference and servlet spec _recommends_ the > >first option! > > > >So this reason is not really a valid one and there is no any other valid > >reason why this should be done. At least I am not going to do this. > > > > > > > Have you tried to do it with the war? > Did you even read that spec? Obviously not. > The classloader loads the jar and the respective versioning information > not the webapp container that loads the war! > Remember that in this day and age all list mail gets archived so what > you just said above will be preserved forever. > > Michal, you are leading me to believe that you are the originator for > this plugin. If that is the case I am hearing some very negative > feedback from a member of this project which boils down to "I'm to lazy > and can't be bothered". > > Not only to lazy to do the work, which would be at your discretion, but > to lazy to even bother looking into what I'm asking for and giving > reasonable and coherent reasons for not doing it. > > I don't think you *must* add this feature because *I* ask for it, but > you owe all of us the courtesy of looking into the request (which you > very clearly have not done). > > This is exactly the kind of negative attitude that is turning people off > of Maven and I find it very disappointing. > > - Brill Pappin > > - > 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] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
Oh, and provide some support for it other than 'we want it like this'. (btw Brill, I think you have a good argument, but given the trivial workaround) Featuritis is the bane of most software. On Tue, 29 Jun 2004 15:57:47 -0500, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > whoo now, i don't want to get involved, but i do want to let it be known that since > this is an open source project, nothing is stopping you from adding the feature > you're asking for. > * download the source from cvs > * make the change you're requesting > * submit the change as a patch to JIRA. > * hope that a commiter will take the patch and apply it to the codebase! =) > > > > -Original Message- > > From: Brill Pappin [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 29, 2004 3:41 PM > > To: Maven Users List > > Subject: Re: RFE for the war plugin > > > > > > > > Michal Maczka wrote: > > > > >On Tue, 2004-06-29 at 18:00, Brill Pappin wrote: > > > > > > > > >>I thought I had explained this? > > >> > > >> > > >> > > >You did not. > > > > > >[...] > > > > > > > > > > Actually yes I did, working backwards in time and no > > including the one > > quoted here: > > > > On Tue, 29 Jun 2004 08:53:47 -0400: > > "The reason I specifically want to do it, is so I can use the > > manifest > > to package extended information about the classes. I think I > > said that > > though..." > > > > At Monday, June 28, 2004 2:21 PM > > "Doing this allows me to use the manifest versioning, labeling and > > dependency parts of the manifest." > > > > I think there might even be a few others I missed. > > > > >>If you want to know more about what I'm doing (and why I'm > > asking for > > >>this), you can get a very good idea at this site: > > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > > >> > > >>Specifically take a look at the "Package Versioning > > Specification" which > > >>is link to the URL above, or at this URL: > > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/ve > rsioningTOC.html > >> > >> > >> > > > > > >Are you aware of the fact that servlet specification clearly defines the > >location in the war archive where manifest files should go? > > > > > [...] > > >IMO there is absolutely no difference and servlet spec _recommends_ the > >first option! > > > >So this reason is not really a valid one and there is no any other valid > >reason why this should be done. At least I am not going to do this. > > > > > > > Have you tried to do it with the war? > Did you even read that spec? Obviously not. > The classloader loads the jar and the respective versioning information > not the webapp container that loads the war! > Remember that in this day and age all list mail gets archived so what > you just said above will be preserved forever. > > Michal, you are leading me to believe that you are the originator for > this plugin. If that is the case I am hearing some very negative > feedback from a member of this project which boils down to "I'm to lazy > and can't be bothered". > > Not only to lazy to do the work, which would be at your discretion, but > to lazy to even bother looking into what I'm asking for and giving > reasonable and coherent reasons for not doing it. > > I don't think you *must* add this feature because *I* ask for it, but > you owe all of us the courtesy of looking into the request (which you > very clearly have not done). > > This is exactly the kind of negative attitude that is turning people off > of Maven and I find it very disappointing. > > - Brill Pappin > > - > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
whoo now, i don't want to get involved, but i do want to let it be known that since this is an open source project, nothing is stopping you from adding the feature you're asking for. * download the source from cvs * make the change you're requesting * submit the change as a patch to JIRA. * hope that a commiter will take the patch and apply it to the codebase! =) > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 3:41 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > > Michal Maczka wrote: > > >On Tue, 2004-06-29 at 18:00, Brill Pappin wrote: > > > > > >>I thought I had explained this? > >> > >> > >> > >You did not. > > > >[...] > > > > > > Actually yes I did, working backwards in time and no > including the one > quoted here: > > On Tue, 29 Jun 2004 08:53:47 -0400: > "The reason I specifically want to do it, is so I can use the > manifest > to package extended information about the classes. I think I > said that > though..." > > At Monday, June 28, 2004 2:21 PM > "Doing this allows me to use the manifest versioning, labeling and > dependency parts of the manifest." > > I think there might even be a few others I missed. > > >>If you want to know more about what I'm doing (and why I'm > asking for > >>this), you can get a very good idea at this site: > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > >> > >>Specifically take a look at the "Package Versioning > Specification" which > >>is link to the URL above, or at this URL: > >>http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/ve rsioningTOC.html >> >> >> > > >Are you aware of the fact that servlet specification clearly defines the >location in the war archive where manifest files should go? > > [...] >IMO there is absolutely no difference and servlet spec _recommends_ the >first option! > >So this reason is not really a valid one and there is no any other valid >reason why this should be done. At least I am not going to do this. > > > Have you tried to do it with the war? Did you even read that spec? Obviously not. The classloader loads the jar and the respective versioning information not the webapp container that loads the war! Remember that in this day and age all list mail gets archived so what you just said above will be preserved forever. Michal, you are leading me to believe that you are the originator for this plugin. If that is the case I am hearing some very negative feedback from a member of this project which boils down to "I'm to lazy and can't be bothered". Not only to lazy to do the work, which would be at your discretion, but to lazy to even bother looking into what I'm asking for and giving reasonable and coherent reasons for not doing it. I don't think you *must* add this feature because *I* ask for it, but you owe all of us the courtesy of looking into the request (which you very clearly have not done). This is exactly the kind of negative attitude that is turning people off of Maven and I find it very disappointing. - Brill Pappin - 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]
Re: RFE for the war plugin
Michal Maczka wrote: On Tue, 2004-06-29 at 18:00, Brill Pappin wrote: I thought I had explained this? You did not. [...] Actually yes I did, working backwards in time and no including the one quoted here: On Tue, 29 Jun 2004 08:53:47 -0400: "The reason I specifically want to do it, is so I can use the manifest to package extended information about the classes. I think I said that though..." At Monday, June 28, 2004 2:21 PM "Doing this allows me to use the manifest versioning, labeling and dependency parts of the manifest." I think there might even be a few others I missed. If you want to know more about what I'm doing (and why I'm asking for this), you can get a very good idea at this site: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html Specifically take a look at the "Package Versioning Specification" which is link to the URL above, or at this URL: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioningTOC.html Are you aware of the fact that servlet specification clearly defines the location in the war archive where manifest files should go? [...] IMO there is absolutely no difference and servlet spec _recommends_ the first option! So this reason is not really a valid one and there is no any other valid reason why this should be done. At least I am not going to do this. Have you tried to do it with the war? Did you even read that spec? Obviously not. The classloader loads the jar and the respective versioning information not the webapp container that loads the war! Remember that in this day and age all list mail gets archived so what you just said above will be preserved forever. Michal, you are leading me to believe that you are the originator for this plugin. If that is the case I am hearing some very negative feedback from a member of this project which boils down to "I'm to lazy and can't be bothered". Not only to lazy to do the work, which would be at your discretion, but to lazy to even bother looking into what I'm asking for and giving reasonable and coherent reasons for not doing it. I don't think you *must* add this feature because *I* ask for it, but you owe all of us the courtesy of looking into the request (which you very clearly have not done). This is exactly the kind of negative attitude that is turning people off of Maven and I find it very disappointing. - Brill Pappin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
Thanks, thats a good and simple temporary solution and will do until a property can be added. - Brill Charles Daniels wrote: Brett, If you want to generate a jar file for your war file and do not want to create 2 subprojects (as is the general convention), you can create a very simple postGoal that will jar your class files just prior to construction of your war file: I haven't tested it, so you may have to fiddle with it a bit, but I think you get the idea. Cheers, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
Brett, If you want to generate a jar file for your war file and do not want to create 2 subprojects (as is the general convention), you can create a very simple postGoal that will jar your class files just prior to construction of your war file: I haven't tested it, so you may have to fiddle with it a bit, but I think you get the idea. Cheers, Chuck > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 9:03 AM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > Actually I don't really have much of a problem with Eclipse, other than > I have to keep the parts of an app together... remember I'm one of the > group who is trying to get the old fuddy-duddies around here to use > Maven, so not everyone would "get it" if the parts of an app where > spread all over the repository. > > I'm having a hard enough time getting people to build with maven > (despite it being easier)... I've even got a couple of guys that won't > even *execute* it on our development box to build an app, for no reason > other than being stubbourn. > > BTW - A little off topic but following that last thought -- I see Mavens > value, but if you want to gain more support and remove some of the > roadblocks (for me at least) you have to target the agile folks; we are > an agile shop but its they are who are the ones bulking even though > Maven fits right into agile practice. > > - Brill Pappin > > Matt Read wrote: > > >What problems do you have with Eclipse? I do exactly this across > a project > >with many components which are re-used in various combinations > of .ear and > >.war files using the Maven dependency mechanism and have no > problems at all > >using Eclipse as my IDE. > > > >Matt. > > > > > > > >>-Original Message- > >>From: Brill Pappin [mailto:[EMAIL PROTECTED] > >>Sent: 29 June 2004 13:38 > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >>Yes, I thought of doing that very thing :) however I then > >>have problems with Eclipse as it doesn't understand > >>multi-project builds, and you really want all the parts of an > >>application in the same place. > >> > >>Still doable, but less than optimum. > >> > >>- Brill > >> > >> > >> > > > - > 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]
Re: RFE for the war plugin
On Tue, 2004-06-29 at 18:00, Brill Pappin wrote: > I thought I had explained this? > You did not. [...] > If you want to know more about what I'm doing (and why I'm asking for > this), you can get a very good idea at this site: > http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > > Specifically take a look at the "Package Versioning Specification" which > is link to the URL above, or at this URL: > http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioningTOC.html > Are you aware of the fact that servlet specification clearly defines the location in the war archive where manifest files should go? And my question was why you don't put it there and if there is any difference between webapp WEB-INF classes META-INF MANIFEST.MF and webapp WEB-INF lib foo.jar!/META-INF/MANIFEST.MF IMO there is absolutely no difference and servlet spec _recommends_ the first option! So this reason is not really a valid one and there is no any other valid reason why this should be done. At least I am not going to do this. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
Brill, First, let me apologize for calling you Brent in my previous posting. Second, I agree with you. It would be a very simple enhancement to the war plugin. All that should be needed are: 1. Define a new Boolean property, named something to the effect of maven.war.generate.jar 2. Enhance war:webapp goal by adding something similar to the following (which is the same thing that the postGoal does that I gave in my previous reply to you): By default, the war plugin would set the new property to false, so that default behavior remains unchanged (i.e., no jar file is generated). -- Chuck > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 12:01 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > I thought I had explained this? > > Under no circumstances am I asking that classes not ever go into the > classes directory, I'm not even asking that the JAR method be the > default... I just want to be able to do it. > > Our requirements do not "clash" not even a little bit. So far, I've only > herd reasons against it like "we don't want to, because we can't see the > value" while I've given a good reason to add it -- I don't see where the > problem is in terms of *adding the ability*... please note I didn't say > *remove the old method*. > > As for "convincing" people, I don't actually care if you want to use it > or not; I explained why I was asking for it and it's a valid reason with > a solid implementation behind it (the subject is RFE with means "request > for enhancement"). > > If you want to know more about what I'm doing (and why I'm asking for > this), you can get a very good idea at this site: > http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html > > Specifically take a look at the "Package Versioning Specification" which > is link to the URL above, or at this URL: > http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioni > ngTOC.html > > I apologize to everyone if I'm sounding a bit "huffy" in this post but > I've said the same thing for the 3rd time now. > Frankly I think it imperative in a tool that your not supposed to have > to customize too much, that all the options are covered... and that > alone is a reason to add this ability. > Mavin is built on the premise that the build is "uniform" and "easy", so > if I go and write my own plugin that duplicates exactly what another > plugin already does except one small addition, what the heck is the > point of Maven in the first place? I'd be better off using Ant. > > - Brill Pappin > > Maczka Michal wrote: > > >But sometimes two users have clashing requirements ( I am myself > also a user > >of war plugin > >and in some cases for some reasons I really need to have classes in > >WEB-INF/classes folder). > > > >If you are not convincing enough you have 0% of chances that such change > >which your are asking for will be ever made. > > > > > > > > - > 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]
Re: RFE for the war plugin
heh, Ready or not, here it comes (re: mavin). The team I work with now is likely one of the best I've ever worked with... but also a fairly stubbourn bunch; unfortunatly buzz-words won't work here... we pratice Scrum, Pair Programming, agile and TDD daily so its not like there is no exposure or flexability. Anyway you don't need to preach to me, I know the value of Maven and the build practice prmotes (I'm using it after all). - Brill Pappin Matt Read wrote: I suggest talking to them about components, cohesion and various other buzzwords although it sounds like you might be fighting a losing battle if your team are too stubborn to run builds. Separating your application into individual components with clearly defined responsibilities makes a lot of sense for all sorts of reasons which aren't really relevant to this list. Maintaining the source for these components in separate source trees, and treating each component as separate artifacts with it's own Maven project.xml with interdependencies and versioning managed via the very easy to use Maven dependency mechanism has worked very well for me and my team. If my understanding of your team's desire to "keeping parts of the app together" is to construct one monolithic source tree with no independent versioning of components then maybe your team isn't ready for Maven yet and you should focus on introducing some of the more basic principles of OOD. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
I thought I had explained this? Under no circumstances am I asking that classes not ever go into the classes directory, I'm not even asking that the JAR method be the default... I just want to be able to do it. Our requirements do not "clash" not even a little bit. So far, I've only herd reasons against it like "we don't want to, because we can't see the value" while I've given a good reason to add it -- I don't see where the problem is in terms of *adding the ability*... please note I didn't say *remove the old method*. As for "convincing" people, I don't actually care if you want to use it or not; I explained why I was asking for it and it's a valid reason with a solid implementation behind it (the subject is RFE with means "request for enhancement"). If you want to know more about what I'm doing (and why I'm asking for this), you can get a very good idea at this site: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html Specifically take a look at the "Package Versioning Specification" which is link to the URL above, or at this URL: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioningTOC.html I apologize to everyone if I'm sounding a bit "huffy" in this post but I've said the same thing for the 3rd time now. Frankly I think it imperative in a tool that your not supposed to have to customize too much, that all the options are covered... and that alone is a reason to add this ability. Mavin is built on the premise that the build is "uniform" and "easy", so if I go and write my own plugin that duplicates exactly what another plugin already does except one small addition, what the heck is the point of Maven in the first place? I'd be better off using Ant. - Brill Pappin Maczka Michal wrote: But sometimes two users have clashing requirements ( I am myself also a user of war plugin and in some cases for some reasons I really need to have classes in WEB-INF/classes folder). If you are not convincing enough you have 0% of chances that such change which your are asking for will be ever made. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 2:54 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > Where this flack is coming from? > > The reason I specifically want to do it, is so I can use the > manifest to > package extended information about the classes. What's the difference bewtween manifest file kept in META-INF folder of your web application and WEB-INF/your.jar!/META-INF/? > I think I said that though... as for not "convincing", that > assumes that > the way you do things is the right way... I wasn't trying to convince > anyone. > Nope. You asked us to do some work and change war plugin. Before anybody will bother to apply your patch or spend its time trying to implement what you want there are two conditions which must be satisfed: a) there must be an agreement between maintainers of given plugin that this patch is a move into right direction b) somebody must feel that it is important enough to dedicate its time to apply such patch. Most of the plugins are improved thanks to feedback and suggestions of maven users. And we do appreciate suggestions and feedback. But sometimes two users have clashing requirements ( I am myself also a user of war plugin and in some cases for some reasons I really need to have classes in WEB-INF/classes folder). If you are not convincing enough you have 0% of chances that such change which your are asking for will be ever made. > I guess I'm surprised that people don't even want the *ability* to > package as a JAR instead of in the classes dir. Frankly with > my style, > I'd package into a jar instead even if I wasn't interested in the > manifest just to keep things what I would think of as tidy. > so you have been given clean solution how to do that (use one more project for creating your jar and then package it into war) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
The way we do this for our projects is to have a separate project to hold the code in Eclipse and another for the web app. This works well for us in MyEclipse or WSAD. On Tue, 29 Jun 2004 08:53:47 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > > Where this flack is coming from? > > The reason I specifically want to do it, is so I can use the manifest to > package extended information about the classes. > I think I said that though... as for not "convincing", that assumes that > the way you do things is the right way... I wasn't trying to convince > anyone. > > I guess I'm surprised that people don't even want the *ability* to > package as a JAR instead of in the classes dir. Frankly with my style, > I'd package into a jar instead even if I wasn't interested in the > manifest just to keep things what I would think of as tidy. > > - Brill Pappin > > > Maczka Michal wrote: > > >>-Original Message- > >>From: Brill Pappin [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, June 29, 2004 2:38 PM > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >> > >>Yes, I thought of doing that very thing :) > >>however I then have problems with Eclipse as it doesn't understand > >>multi-project builds, and you really want all the parts of an > >>application in the same place. > >> > >>Still doable, but less than optimum. > >> > >> > >> > >Can you provide at least one valid reason why would like to do that (put jar > >file into WEB-INF/lib folder)? > >All the points you mentioned in you original post are either not very > >convincing or false > >(e.g. that size of war thanks to that will be smaller). > > > >Michal > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > "Any sufficiently advanced magic is indistinguishable from technology." > - Arthur C Anticlarke > > > > > - > 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]
RE: RFE for the war plugin
I suggest talking to them about components, cohesion and various other buzzwords although it sounds like you might be fighting a losing battle if your team are too stubborn to run builds. Separating your application into individual components with clearly defined responsibilities makes a lot of sense for all sorts of reasons which aren't really relevant to this list. Maintaining the source for these components in separate source trees, and treating each component as separate artifacts with it's own Maven project.xml with interdependencies and versioning managed via the very easy to use Maven dependency mechanism has worked very well for me and my team. If my understanding of your team's desire to "keeping parts of the app together" is to construct one monolithic source tree with no independent versioning of components then maybe your team isn't ready for Maven yet and you should focus on introducing some of the more basic principles of OOD. Matt. > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: 29 June 2004 14:03 > To: Maven Users List > Subject: Re: RFE for the war plugin > > Actually I don't really have much of a problem with Eclipse, > other than I have to keep the parts of an app together... > remember I'm one of the group who is trying to get the old > fuddy-duddies around here to use Maven, so not everyone would > "get it" if the parts of an app where spread all over the repository. > > I'm having a hard enough time getting people to build with > maven (despite it being easier)... I've even got a couple of > guys that won't even *execute* it on our development box to > build an app, for no reason other than being stubbourn. > > BTW - A little off topic but following that last thought -- I > see Mavens value, but if you want to gain more support and > remove some of the roadblocks (for me at least) you have to > target the agile folks; we are an agile shop but its they are > who are the ones bulking even though Maven fits right into > agile practice. > > - Brill Pappin > > Matt Read wrote: > > >What problems do you have with Eclipse? I do exactly this across a > >project with many components which are re-used in various > combinations > >of .ear and .war files using the Maven dependency mechanism > and have no > >problems at all using Eclipse as my IDE. > > > >Matt. > > > > > > > >>-Original Message- > >>From: Brill Pappin [mailto:[EMAIL PROTECTED] > >>Sent: 29 June 2004 13:38 > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >>Yes, I thought of doing that very thing :) however I then have > >>problems with Eclipse as it doesn't understand > multi-project builds, > >>and you really want all the parts of an application in the > same place. > >> > >>Still doable, but less than optimum. > >> > >>- Brill > >> > >> > >> > > > - > 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]
Re: RFE for the war plugin
Actually I don't really have much of a problem with Eclipse, other than I have to keep the parts of an app together... remember I'm one of the group who is trying to get the old fuddy-duddies around here to use Maven, so not everyone would "get it" if the parts of an app where spread all over the repository. I'm having a hard enough time getting people to build with maven (despite it being easier)... I've even got a couple of guys that won't even *execute* it on our development box to build an app, for no reason other than being stubbourn. BTW - A little off topic but following that last thought -- I see Mavens value, but if you want to gain more support and remove some of the roadblocks (for me at least) you have to target the agile folks; we are an agile shop but its they are who are the ones bulking even though Maven fits right into agile practice. - Brill Pappin Matt Read wrote: What problems do you have with Eclipse? I do exactly this across a project with many components which are re-used in various combinations of .ear and .war files using the Maven dependency mechanism and have no problems at all using Eclipse as my IDE. Matt. -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: 29 June 2004 13:38 To: Maven Users List Subject: Re: RFE for the war plugin Yes, I thought of doing that very thing :) however I then have problems with Eclipse as it doesn't understand multi-project builds, and you really want all the parts of an application in the same place. Still doable, but less than optimum. - Brill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
Where this flack is coming from? The reason I specifically want to do it, is so I can use the manifest to package extended information about the classes. I think I said that though... as for not "convincing", that assumes that the way you do things is the right way... I wasn't trying to convince anyone. I guess I'm surprised that people don't even want the *ability* to package as a JAR instead of in the classes dir. Frankly with my style, I'd package into a jar instead even if I wasn't interested in the manifest just to keep things what I would think of as tidy. - Brill Pappin Maczka Michal wrote: -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 29, 2004 2:38 PM To: Maven Users List Subject: Re: RFE for the war plugin Yes, I thought of doing that very thing :) however I then have problems with Eclipse as it doesn't understand multi-project builds, and you really want all the parts of an application in the same place. Still doable, but less than optimum. Can you provide at least one valid reason why would like to do that (put jar file into WEB-INF/lib folder)? All the points you mentioned in you original post are either not very convincing or false (e.g. that size of war thanks to that will be smaller). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Any sufficiently advanced magic is indistinguishable from technology." - Arthur C Anticlarke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
> -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 29, 2004 2:38 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > Yes, I thought of doing that very thing :) > however I then have problems with Eclipse as it doesn't understand > multi-project builds, and you really want all the parts of an > application in the same place. > > Still doable, but less than optimum. > Can you provide at least one valid reason why would like to do that (put jar file into WEB-INF/lib folder)? All the points you mentioned in you original post are either not very convincing or false (e.g. that size of war thanks to that will be smaller). Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
What problems do you have with Eclipse? I do exactly this across a project with many components which are re-used in various combinations of .ear and .war files using the Maven dependency mechanism and have no problems at all using Eclipse as my IDE. Matt. > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: 29 June 2004 13:38 > To: Maven Users List > Subject: Re: RFE for the war plugin > > Yes, I thought of doing that very thing :) however I then > have problems with Eclipse as it doesn't understand > multi-project builds, and you really want all the parts of an > application in the same place. > > Still doable, but less than optimum. > > - Brill > > Charles Daniels wrote: > > >If you really want to create a jar file instead of deploying your > >classes in WEB-INF/classes, just split your project into 2 > subprojects. > >One subproject will create your jar file. The other subproject will > >build your war file and will include the jar file as a > dependency, with > >the property set to true (just like any other > dependency > >that you bundle into your war file). > > > > > > > >>-Original Message- > >>From: Brill Pappin [mailto:[EMAIL PROTECTED] > >>Sent: Monday, June 28, 2004 2:21 PM > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >> > >>To clarify; I'm not asking that the classes dir go away, I'm just > >>asking for the ability to use a jar instead. Which should > be a fairly > >>simple addition to the war goal. > >> > >>Doing this allows me to use the manifest versioning, labeling and > >>dependency parts of the manifest. For example, my code > currently logs > >>not only the file and line number that an exception > happened in, but > >>also the package and version of the jar, because in my > situation it's > >>possible that I have different servers running different > revisions of > >>the code. > >> > >>Your class-load order comment is a good point, but I > actually see this > >>as a bonus for the JAR argument, in that I can quickly > patch a library > >>or over-ride a log4j properties file without > re-deploying... not that > >>I would tend to do this if I could help it, but I've seen > the need for > >>it recently (in an emergency). > >> > >>- Brill Pappin > >> > >> > >> > > - > 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]
Re: RFE for the war plugin
Yes, I thought of doing that very thing :) however I then have problems with Eclipse as it doesn't understand multi-project builds, and you really want all the parts of an application in the same place. Still doable, but less than optimum. - Brill Charles Daniels wrote: If you really want to create a jar file instead of deploying your classes in WEB-INF/classes, just split your project into 2 subprojects. One subproject will create your jar file. The other subproject will build your war file and will include the jar file as a dependency, with the property set to true (just like any other dependency that you bundle into your war file). -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 2:21 PM To: Maven Users List Subject: Re: RFE for the war plugin To clarify; I'm not asking that the classes dir go away, I'm just asking for the ability to use a jar instead. Which should be a fairly simple addition to the war goal. Doing this allows me to use the manifest versioning, labeling and dependency parts of the manifest. For example, my code currently logs not only the file and line number that an exception happened in, but also the package and version of the jar, because in my situation it's possible that I have different servers running different revisions of the code. Your class-load order comment is a good point, but I actually see this as a bonus for the JAR argument, in that I can quickly patch a library or over-ride a log4j properties file without re-deploying... not that I would tend to do this if I could help it, but I've seen the need for it recently (in an emergency). - Brill Pappin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
If you really want to create a jar file instead of deploying your classes in WEB-INF/classes, just split your project into 2 subprojects. One subproject will create your jar file. The other subproject will build your war file and will include the jar file as a dependency, with the property set to true (just like any other dependency that you bundle into your war file). > -Original Message- > From: Brill Pappin [mailto:[EMAIL PROTECTED] > Sent: Monday, June 28, 2004 2:21 PM > To: Maven Users List > Subject: Re: RFE for the war plugin > > > To clarify; I'm not asking that the classes dir go away, I'm just asking > for the ability to use a jar instead. Which should be a fairly simple > addition to the war goal. > > Doing this allows me to use the manifest versioning, labeling and > dependency parts of the manifest. For example, my code currently logs > not only the file and line number that an exception happened in, but > also the package and version of the jar, because in my situation it's > possible that I have different servers running different revisions of > the code. > > Your class-load order comment is a good point, but I actually see this > as a bonus for the JAR argument, in that I can quickly patch a library > or over-ride a log4j properties file without re-deploying... not that I > would tend to do this if I could help it, but I've seen the need for it > recently (in an emergency). > > - Brill Pappin > > Tomasz Pik wrote: > > >On Mon, 28 Jun 2004 16:02:44 +0200, "Göschl,Siegfried" > ><[EMAIL PROTECTED]> wrote: > > > > > >>Hi Tomasz, > >> > >>It is actually very convenient to supply a project specific > log4j.properties since this is the vey first one to be found > regardless of any other log4j.properties found in JARs > >> > >> > > > >Yes, I know. > >And that's why I'm not sure if it's the best idea to package > classes into jar > >file during building war file. > >I understand that it might be useful in case of huge set of > small classes but > >generally packaging classes in 'war' project into jar during > build war file may > >leads to problems. > >So, it there'll be such possibilty in 'war' plugin - please, make it > >not-default. > > > >Regards, > >Tomek > > > > > > > >>Cheers, > >> > >>Siegfried Goeschl > >> > >> > >>-Original Message- > >>From: Tomasz Pik [mailto:[EMAIL PROTECTED] > >>Sent: Montag, 28. Juni 2004 15:03 > >>To: Maven Users List > >>Subject: Re: RFE for the war plugin > >> > >>On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin > <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >>>I'm sure some of us would prefer to keep the WEB-INF/classes dir, so > >>>my suggestion would be to include a switch property that would allow > >>>the user to use one or the other. > >>> > >>> > >>Here's one reason: servlet specs define, that classes from > WEB-INF/classes are loaded before WEB-INF/lib so this may be used > as some kind of 'overloading', for example for classes from > 'third party' libraries (I know it's ugly but it's possible due to spec). > >> > >>Regards, > >>Tomek > >> > >>- > >>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] > >> > >> > >> > >> > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > -- > "Any sufficiently advanced magic is indistinguishable from technology." > - Arthur C Anticlarke > > > - > 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]
Re: RFE for the war plugin
To clarify; I'm not asking that the classes dir go away, I'm just asking for the ability to use a jar instead. Which should be a fairly simple addition to the war goal. Doing this allows me to use the manifest versioning, labeling and dependency parts of the manifest. For example, my code currently logs not only the file and line number that an exception happened in, but also the package and version of the jar, because in my situation it's possible that I have different servers running different revisions of the code. Your class-load order comment is a good point, but I actually see this as a bonus for the JAR argument, in that I can quickly patch a library or over-ride a log4j properties file without re-deploying... not that I would tend to do this if I could help it, but I've seen the need for it recently (in an emergency). - Brill Pappin Tomasz Pik wrote: On Mon, 28 Jun 2004 16:02:44 +0200, "Göschl,Siegfried" <[EMAIL PROTECTED]> wrote: Hi Tomasz, It is actually very convenient to supply a project specific log4j.properties since this is the vey first one to be found regardless of any other log4j.properties found in JARs Yes, I know. And that's why I'm not sure if it's the best idea to package classes into jar file during building war file. I understand that it might be useful in case of huge set of small classes but generally packaging classes in 'war' project into jar during build war file may leads to problems. So, it there'll be such possibilty in 'war' plugin - please, make it not-default. Regards, Tomek Cheers, Siegfried Goeschl -Original Message- From: Tomasz Pik [mailto:[EMAIL PROTECTED] Sent: Montag, 28. Juni 2004 15:03 To: Maven Users List Subject: Re: RFE for the war plugin On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: I'm sure some of us would prefer to keep the WEB-INF/classes dir, so my suggestion would be to include a switch property that would allow the user to use one or the other. Here's one reason: servlet specs define, that classes from WEB-INF/classes are loaded before WEB-INF/lib so this may be used as some kind of 'overloading', for example for classes from 'third party' libraries (I know it's ugly but it's possible due to spec). Regards, Tomek - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Any sufficiently advanced magic is indistinguishable from technology." - Arthur C Anticlarke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFE for the war plugin
On Mon, 28 Jun 2004 16:02:44 +0200, "Göschl,Siegfried" <[EMAIL PROTECTED]> wrote: > > Hi Tomasz, > > It is actually very convenient to supply a project specific log4j.properties since > this is the vey first one to be found regardless of any other log4j.properties found > in JARs Yes, I know. And that's why I'm not sure if it's the best idea to package classes into jar file during building war file. I understand that it might be useful in case of huge set of small classes but generally packaging classes in 'war' project into jar during build war file may leads to problems. So, it there'll be such possibilty in 'war' plugin - please, make it not-default. Regards, Tomek > Cheers, > > Siegfried Goeschl > > > -Original Message- > From: Tomasz Pik [mailto:[EMAIL PROTECTED] > Sent: Montag, 28. Juni 2004 15:03 > To: Maven Users List > Subject: Re: RFE for the war plugin > > On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > > > I'm sure some of us would prefer to keep the WEB-INF/classes dir, so > > my suggestion would be to include a switch property that would allow > > the user to use one or the other. > > Here's one reason: servlet specs define, that classes from WEB-INF/classes are > loaded before WEB-INF/lib so this may be used as some kind of 'overloading', for > example for classes from 'third party' libraries (I know it's ugly but it's possible > due to spec). > > Regards, > Tomek > > - > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
Hi Tomasz, It is actually very convenient to supply a project specific log4j.properties since this is the vey first one to be found regardless of any other log4j.properties found in JARs Cheers, Siegfried Goeschl -Original Message- From: Tomasz Pik [mailto:[EMAIL PROTECTED] Sent: Montag, 28. Juni 2004 15:03 To: Maven Users List Subject: Re: RFE for the war plugin On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > I'm sure some of us would prefer to keep the WEB-INF/classes dir, so > my suggestion would be to include a switch property that would allow > the user to use one or the other. Here's one reason: servlet specs define, that classes from WEB-INF/classes are loaded before WEB-INF/lib so this may be used as some kind of 'overloading', for example for classes from 'third party' libraries (I know it's ugly but it's possible due to spec). Regards, Tomek - 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]
Re: RFE for the war plugin
I don't see any reason to do this. It won't make it any smaller, unless you compress the JAR - but if you are worried about space keep the WAR packed in the container and compressed and you won't gain anything from packing the classes. You can still add a manifest to a WAR. I'd recommend against doing this. - Brett On Mon, 28 Jun 2004 15:03:04 +0200, Tomasz Pik <[EMAIL PROTECTED]> wrote: > > On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > > > I'm sure some of us would prefer to keep the WEB-INF/classes dir, so my > > suggestion would be to include a switch property that would allow the > > user to use one or the other. > > Here's one reason: servlet specs define, that classes from WEB-INF/classes > are loaded before WEB-INF/lib so this may be used as some kind of 'overloading', > for example for classes from 'third party' libraries (I know it's ugly > but it's possible > due to spec). > > Regards, > Tomek > > > > - > 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]
Re: RFE for the war plugin
On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin <[EMAIL PROTECTED]> wrote: > I'm sure some of us would prefer to keep the WEB-INF/classes dir, so my > suggestion would be to include a switch property that would allow the > user to use one or the other. Here's one reason: servlet specs define, that classes from WEB-INF/classes are loaded before WEB-INF/lib so this may be used as some kind of 'overloading', for example for classes from 'third party' libraries (I know it's ugly but it's possible due to spec). Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
