Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853788 **[Jason van Zyl](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jvanzyl)** commented Patch applied and snapshot deploy, so grab the snapshot and make sure it works correctly for you. I tried it quickly with a webapp I'm working on and it seems to work. There is now a boolean option to archive the classes and the JAR produced follows standard Maven naming conventions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853770 **[David Jencks](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=djencks)** commented I think adding this capability is a very good idea. IIUC the only argument against it is that it is possible to get the same effect by putting the classes into a separate project. I think this ignores the different effects and affect of having 2 projects: 1. Having 2 projects forces you to maintain what you are likely to be thinking of as one project in two places: e.g. even without jsps, the web.xml is going to be far away in the file system and IDE from the classes it is the descriptor for. I think breaking the way people think about their project in this way is inadvisable. 2. If you have jsps, you cannot precompile them and include them in the project classes jar without moving them into the classes project. What should be a packaging option requires major svn changes to your project. 3. With 2 projects you are forced to publish the classes jar. You may not want to pollute your repo with this artifact that you may regard as unnecessary. Also, you are apt to want to name both projects with the same name. 4. If you want 2 profiles, one to pack classes into a jar and the other to leave them in WEB-INF/classes, you are forced to unpack the jar if the jar is from a separate project. This is going to be a bit slower than not creating the jar in the first place. I'm sure there are more, this is just what came to mind during a moments consideration. war files are a pretty strange and perhaps inadvisable construction, but I think it is better for maven to try to adapt to what they are and how they are used rather than trying to force everyone to essentially use something else. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853782 **[Ian P. Springer](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ips)** commented +1 to Torgeir's suggestion. I think having a boolean parameter for enabling the option is more intuitive. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853786 **[Jason van Zyl](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jvanzyl)** commented I agree that there should be a boolean parameter and the JAR name should come out with the standard Maven naming conventions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853773 **[Torgeir Lorange Ostby](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=torgeilo)** commented This feature makes it easier to overlay war files if you have files with the same name and path in the war projects you want to merge (e.g. in src/main/resources). With this, these files will end up in their respective jars instead of replacing each other during the overlay process (take the application context descriptor as an example). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221: URL: https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853764 **[Prasad Kashyap](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=pkashyap)** commented \ bporter: if I had to do something like that in m2.. jar clases into web-inf/lib.. how would you recommend I do that ? \ it probably needs to be an option of the war plugin \ I'm yet to see why this is a good idea \ oh course, you can always put it in 2 projects now, too \let me give you the req'ment from Geronimo.. \we recently ran into a problem where the path names were too long for windows to handle.. \so we jar'ed them into web-inf/lib \ heh \ ok, well you could code up a patch for the war plugin and we'll apply it \ the jira was filed just yesterday I tink \i see it.. this.. http://jira.codehaus.org/browse/MWAR-45 --- patch introduces config parameter "classesArchiveName" -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
Re: [I] [MWAR-45] add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ [maven-war-plugin]
jira-importer commented on issue #221:
URL:
https://github.com/apache/maven-war-plugin/issues/221#issuecomment-2967853780
**[Torgeir Lorange
Ostby](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=torgeilo)**
commented
Would it be better if classesArchiveName defaults to
${project.build.finalName} and then have an additional parameter/flag which
triggers the feature? I guess
```xml
${project.build.finalName}
```
would give the same result, but it is not that intuitive that this is what
actually makes the plugin behave differently.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
