Alexandre, Thanks for the patch but please open feature requests over at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=M2E-WTP and attach patches using the git format ( http://wiki.eclipse.org/Jetty/Contributor/Contributing_Patches#Git_Format_Patch). You might also need to signe Eclipse's CLA( http://wiki.eclipse.org/Development_Resources/Contributing_via_Git) I know I need to put up some contribution guide somewhere but I'm kinda swamped right now.
Now the technicalities are out of the way, about the actual solution you propose : - first of all, unzip is done only once, unless the source zip changed, in that case it's unzipped again. so there's no performance overhead here - performance overhead could occur while scanning the unzipped folder to determine what's to be published, I grant you that :-) - now if we serve these unzipped folders directly, we lose maven-war-plugin's inclusion/exclusion mechanism. It may be a problem for some. - I'm aware of some issues with Tomcat's "serve without publishing" feature, which doesn't support the overlay components for some reason. - In any case I don't believe naively serving the unzipped folders is the *proper* solution. I may revisit my opinion but I need to spend more time investigating the issue (and please attach a proper patch so I can review the diffs). The whole overlay support in m2e-wtp is rather experimental. so things could be handled completely differently in the future. I'm not excluding anything just yet. Unfortunately, I don't think I'll be able to spend some quality time with your problem before at least mid-august. Regards, Fred Bricon 2013/6/27 Alexandre Palma <alexandre.pa...@gmail.com> > Hello, > My name is Alexandre Palma. I work in the R&D team of company which > produces web-based solutions for the financial market. > We have recently started to adapt our java project's structures to use > Maven, and we have also adhered to m2e and m2e-wtp, from which we greatly > benefit, and they have become vital tools in our development process. > We have, though, a little problem with the way m2e-wtp handles overlays, > which I've been bypassing by making a little modification to it's source > code and building in-house versions of it to fit our need, which I believe > may be the need of other developers as well. > > What happens is that we need our modules to be served without being > published, and the zip files m2e-wtp attaches to the deployment assembly > cannot be deployed in this way. But I noticed that m2e-wtp already extracts > the overlays zip files to the directory "target\m2e-wtp\overlays", and if > those directories be attached to the deployment assembly instead of the zip > files it works both ways, publishing and not publishing modules. > > The modification I made is in the org.eclipse.m2e.wtp.OverlayConfigurator > class (which is attached in this message) is to attach those directories to > the deployment assembly. It was certainly not done in the best possible > way, given my little understanding of m2e-wtp's architecture and the > eclipse API itself, but I hope it'll at least help to illustrate what is > being proposed. > > It'd be greatly appreciated if a change to attach directories instead of > zip files could be incorporated to m2e-wtp. I believe it would have no > impact the way it works and it would also improve performance, since it > would not have to extract zip files every time the application is published. > > I apologize for my poor English and hope that you could understand what I > tried to explain. > > Regards and thanks in advance, > Alexandre > > > _______________________________________________ > m2e-wtp-dev mailing list > m2e-wtp-dev@eclipse.org > http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev > > -- "Have you tried turning it off and on again" - The IT Crowd
_______________________________________________ m2e-wtp-dev mailing list m2e-wtp-dev@eclipse.org http://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev
