Re: Artifacts Versioning Spec. Was: RFE for the war plugin
Sorry John, I've been away for a bit and just got back. I'm not too good with the Jelly script but I'll see what I can come up with and send it though the normal channels. Yes, I do have a day job :) which means that I don't have fixed amount of time to work this problem, particularly not being familiar with Jelly. - Brill Pappin John Casey wrote: Brill, I've been reading along, and I agree that you have a valid use case. However, this is all academic until you send in some sort of patch. I might even use this patch if it were sent in - but I don't have time to develop it myself. Sorry, but you're starting to put the cart before the horse here...submit a patch, _then_ nag (pardon the expression) the committers [on the -dev list, BTW] for attention. If you send in a patch, I'll look at it and discuss it with you...then, maybe I'll help you lobby for it (I'm not certain of my status wrt committing plugins; this is something that's been generally up for debate recently). But understand, the only help I'll offer in any capacity will be subject to my own availability. Just as I'm sure you have, I have a day job that doesn't center on maven. :) HTH, john On Wed, 2004-06-30 at 10:44, Brill Pappin wrote: Ok, let me explain this one more time. What you are saying is indeed part of the servlet spec, and the container may actually read and care about what's in the WAR manifest, however code running in the application context doesn't know, and doesn't care. It doesn't care because for things to be working, the webapp must be working properly already and if it wasn't the code running in the context would have other problems anyway. By allowing a user to jar up and add a manifest for the *application code* you allow the user to specify all sorts of meta information about the code at runtime (as mentioned in the versioning spec). The application code runs in the containers context but the versioning information *for the war* means nothing to the application itself, in fact the versioning API can't even get the WARs versioning information (at least not in any container I use), but it *can* get versioning information for the libraries it depends on which means the user code that was JAR'ed up. An example of where I specifically use this information: I'm sure you've seen how you have have log4j output the file and line number of a log message. Now using the versioning API you can also output other information as well as the file and line number, such as what version it is, the module or company it came from... you can even tell things like what dependencies it has etc. As you can see it would be pretty useless to anything but the webapp container to have all this in the WAR file. Not only would it no longer be relevant to the runtime code, but all libraries in the context would have the same information. I hope I am being clear here because I can't think of a simpler was to describe this. For those interested in more detail, the versioning spec is at: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html As an aside, Maven might be able to use this to determine the dependency structure of a library which I know if a holy-grail for the first release, but I leave that to the folks working on the artifact stuff. - 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
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
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]
Artifacts Versioning Spec. Was: RFE for the war plugin
Ok, let me explain this one more time. What you are saying is indeed part of the servlet spec, and the container may actually read and care about what's in the WAR manifest, however code running in the application context doesn't know, and doesn't care. It doesn't care because for things to be working, the webapp must be working properly already and if it wasn't the code running in the context would have other problems anyway. By allowing a user to jar up and add a manifest for the *application code* you allow the user to specify all sorts of meta information about the code at runtime (as mentioned in the versioning spec). The application code runs in the containers context but the versioning information *for the war* means nothing to the application itself, in fact the versioning API can't even get the WARs versioning information (at least not in any container I use), but it *can* get versioning information for the libraries it depends on which means the user code that was JAR'ed up. An example of where I specifically use this information: I'm sure you've seen how you have have log4j output the file and line number of a log message. Now using the versioning API you can also output other information as well as the file and line number, such as what version it is, the module or company it came from... you can even tell things like what dependencies it has etc. As you can see it would be pretty useless to anything but the webapp container to have all this in the WAR file. Not only would it no longer be relevant to the runtime code, but all libraries in the context would have the same information. I hope I am being clear here because I can't think of a simpler was to describe this. For those interested in more detail, the versioning spec is at: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html As an aside, Maven might be able to use this to determine the dependency structure of a library which I know if a holy-grail for the first release, but I leave that to the folks working on the artifact stuff. - Brill Pappin Maczka Michal wrote: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Artifacts Versioning Spec. Was: RFE for the war plugin
Brill, I've been reading along, and I agree that you have a valid use case. However, this is all academic until you send in some sort of patch. I might even use this patch if it were sent in - but I don't have time to develop it myself. Sorry, but you're starting to put the cart before the horse here...submit a patch, _then_ nag (pardon the expression) the committers [on the -dev list, BTW] for attention. If you send in a patch, I'll look at it and discuss it with you...then, maybe I'll help you lobby for it (I'm not certain of my status wrt committing plugins; this is something that's been generally up for debate recently). But understand, the only help I'll offer in any capacity will be subject to my own availability. Just as I'm sure you have, I have a day job that doesn't center on maven. :) HTH, john On Wed, 2004-06-30 at 10:44, Brill Pappin wrote: Ok, let me explain this one more time. What you are saying is indeed part of the servlet spec, and the container may actually read and care about what's in the WAR manifest, however code running in the application context doesn't know, and doesn't care. It doesn't care because for things to be working, the webapp must be working properly already and if it wasn't the code running in the context would have other problems anyway. By allowing a user to jar up and add a manifest for the *application code* you allow the user to specify all sorts of meta information about the code at runtime (as mentioned in the versioning spec). The application code runs in the containers context but the versioning information *for the war* means nothing to the application itself, in fact the versioning API can't even get the WARs versioning information (at least not in any container I use), but it *can* get versioning information for the libraries it depends on which means the user code that was JAR'ed up. An example of where I specifically use this information: I'm sure you've seen how you have have log4j output the file and line number of a log message. Now using the versioning API you can also output other information as well as the file and line number, such as what version it is, the module or company it came from... you can even tell things like what dependencies it has etc. As you can see it would be pretty useless to anything but the webapp container to have all this in the WAR file. Not only would it no longer be relevant to the runtime code, but all libraries in the context would have the same information. I hope I am being clear here because I can't think of a simpler was to describe this. For those interested in more detail, the versioning spec is at: http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html As an aside, Maven might be able to use this to determine the dependency structure of a library which I know if a holy-grail for the first release, but I leave that to the folks working on the artifact stuff. - Brill Pappin Maczka Michal wrote: 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. - 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
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 war.bundle 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
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 war.bundle 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
-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
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
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
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
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 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
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
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):
j:if test=${maven.war.generate.jar}
attainGoal name=jar:jar/
ant:copy file=${maven.final.name}.jar
todir=${maven.war.webapp.dir}/WEB-INF/lib/
ant:delete dir=${maven.war.webapp.dir}/WEB-INF/classes/
/j:if
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
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
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:
postGoal name=war:webapp
attainGoal name=jar:jar/
ant:copy file=${maven.final.name}.jar
todir=${maven.war.webapp.dir}/WEB-INF/lib/
ant:delete dir=${maven.war.webapp.dir}/WEB-INF/classes/
/postGoal
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
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:
postGoal name=war:webapp
attainGoal name=jar:jar/
ant:copy file=${maven.final.name}.jar
todir=${maven.war.webapp.dir}/WEB-INF/lib/
ant:delete dir=${maven.war.webapp.dir}/WEB-INF/classes/
/postGoal
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
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
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
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
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]
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
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
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
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
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 war.bundle 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]
