Community
Participate
Working Groups
Build Identifier: m2e-wtp configures the Maven Classpath Library for export, when dealing with Web projects. When jars from a classpath library are exported /published, the original file name is used. When using pure maven, you have the possibility to export referenced jars under a different name. For instance, my web app references some-external-library-x.y.z.jar but I want to deploy it under WEB-INF/lib/some-external-library.jar instead. Current workaround in m2e-wtp is to copy some-external-library-x.y.z.jar from the original local maven repository to a temporary location (project/target/some-external-library.jar), change the path directly in the classpath entry in the maven library, so that the source file name is the same as the deployed name. Not very elegant right? What I would like to see is the ability for WTP to use an extra classpath attribute, such as deployedName="some-external-library.jar", that would be used during export/deployment on a server. Even better, we could attach a IFileNameMappingStrategy implementation to the library itself. But that probably requires more changes, since it'd require some new API. Obviously, the same would go for projects (if they were to be supported) Reproducible: Always
I have a patch that I tested with tomcat 7.0 and jboss as 7.1.1 : https://github.com/fbricon/webtools.javaee/compare/359385-archive-name (or in git patch format https://github.com/fbricon/webtools.javaee/compare/359385-archive-name.patch) I can attach it here, if you think it's good enough. Otherwise, comments are welcome. I couldn't figure out were to add Unit/Integration tests for that one. But I'm confident the patch is harmless as it doesn't change existing behavior. Adding IClasspathDependencyConstants.CLASSPATH_ARCHIVENAME_ATTRIBUTE makes it an API change. This part could easily be ommitted from the patch, if that poses any problem. I'd very much like that bug to be fixed for Kepler M7 as that would help m2e-wtp solve a number of file locking issues on windows (see bug 406173).
I have reviewed the patch, and it looks very safe. The addition of the constant does make it an API change, and thus requires PMC approval for m7. Even if the constant was not in an interface, it would still technically count as supported API since .classpath files with this flag would be expected to maintain their behaviour indefinitely. So this must be treated as an API change. I vote +1.
Created attachment 230406 [details] Add support for an archiveName classpath attribute Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. m2e-wtp configures the Maven Classpath Library for export, when dealing with Web projects. When jars from a classpath library are exported /published, the original file name is used. When using pure maven, you have the possibility to export referenced jars under a different name. For instance, my web app references some-external-library-x.y.z.jar but I want to deploy it under WEB-INF/lib/some-external-library.jar instead. Because of the workaround explained below causes file handle leaks, a proper solution is needed. Is there a work-around? If so, why do you believe the work-around is insufficient? Current workaround in m2e-wtp is to copy some-external-library-x.y.z.jar from the original local maven repository to a temporary location (project/target/some-external-library.jar), change the path directly in the classpath entry in the maven library, so that the source file name is the same as the deployed name. Unfortunately, this workaround causes file handle leaks on windows, under certain conditions. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The fix was tested locally. No JUnit was added Give a brief technical overview. Who has reviewed this fix? The fix adds a new IClasspathDependencyConstants.CLASSPATH_ARCHIVENAME_ATTRIBUTE constant (org.eclipse.jst.component.archivename). Then ClasspathDependencyUtil.getArchiveName(entry) checks for the presence of that key in the classpath entry attributes. If the key is found, the value is returned as the entry's archive name, else the usual archive name is returned. The fix was reviewed by Rob Stryker. What is the risk associated with this fix? The risk is low. Existing behavior is unchanged when the new attribute is unused.
Created attachment 230407 [details] Add support for an archiveName classpath attribute new patch without the html garbage
Created attachment 230409 [details] Add support for an archiveName classpath attribute I seem to be unable to correctly attach a patch to BZ...sigh. New try.
approved
Not to belabor the point, but this is technically an api change ;)
Yes - thanks for following the process! I approve its an api change, but non-breaking - and safe....
Removing the hotbug_request, as per WTP's hotbug policy. I am also bumping the priority to P1, since this is deemed extremely important by the committers.
I've committed this, but, as usual, am not capable of releasing / tagging.
If there are plans to do a 3.4.next release, any chance this bugfix can be backported?
Chuck, this is already committed and available since Kepler M7. I was wondering if a backport was in order.
We don't have plans on a new release, but do public patch builds from time to time... We can nominate this for that.
We don't have plans to backport this fix... already in the Kepler stream.. resolving for now.. please reopen if you have further plans.
