I really don’t understand what’s odd about this case - I agree, it would be better off in a zip or jar (or any other format), but it seem quite natural to put these resources in an archive and have it versioned and released the normal way as any other artifact. After all, there is not only JavaCode which can be generated by the WSDLs and it is not possible to know which which client technology might use the WSDLs to generate its service layer with it. In my point of view this is not just handy but an absolut must of a functionality. Domi
On 13.04.2014, at 16:57, Jason van Zyl <ja...@takari.io> wrote: > Sure, if you have odd cases like that it comes in handy. > > Seems counter productive to put the WSDL in a WAR, deploy/install it only to > retrieve the WAR again and pull out the WSDL to generate your client code. > > On Apr 13, 2014, at 9:43 AM, Dominik Bartholdi <d...@fortysix.ch> wrote: > >> We use the dependency:unpack to get hold on a couple of WSDL files packaged >> within a WAR (or jar, zip). >> These WSDLs the are the input to generate the client site code with >> jaxws-m-p - coping these files into our repo is definitely nothing we want >> to do and accessing these files nine via http is not an option either. >> Domi >> >> >> On 12.04.2014, at 18:38, Jason van Zyl <ja...@takari.io> wrote: >> >>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bimargul...@gmail.com> >>> wrote: >>> >>>> >>>> I'm much more here. For example, I might have 250,000 words of text >>>> annotated for training a statistical model. I have a maven build that >>>> needs to grab unpack that pile into some location, run a plugin that >>>> performs some data normalization, and then feed the location into a >>>> maven plugin of mine that trains the model. >>> >>> This definitively seems like the wrong place to do this, in the build >>> system. This is not a build time activity, it seems like part of an ETL >>> flow of a data acquisition application. >>> >>>> I guess I could model this >>>> as dependencies, if the scope system allowed me to manage all of this >>>> at a safe distance from the classpath, but as it is it works fine as >>>> 'putting together a bunch of files.' >>> >>> The question is why would you model something like this at all in Maven. >>> Just because you might be able to doesn't mean you should. You can, but >>> your specific use case doesn't seem appropriate for a build system. >>> >>>> >>>>> >>>>> >>>>>> I think that Hervé is trying to help me by suggesting that I shouldn't >>>>>> need the dependency: that just calling out the coordinates to >>>>>> something like :unpack should result in resolution via injection. >>>>>> >>>>>> Then what changes? >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jason >>>>> >>>>> ---------------------------------------------------------- >>>>> Jason van Zyl >>>>> Founder, Apache Maven >>>>> http://twitter.com/jvanzyl >>>>> http://twitter.com/takari_io >>>>> --------------------------------------------------------- >>>>> >>>>> To think is easy. To act is hard. But the hardest thing in the world is >>>>> to act in accordance with your thinking. >>>>> >>>>> -- Johann von Goethe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> --------------------------------------------------------- >>> >>> Our achievements speak for themselves. What we have to keep track >>> of are our failures, discouragements and doubts. We tend to forget >>> the past difficulties, the many false starts, and the painful >>> groping. We see our past achievements as the end result of a >>> clean forward thrust, and our present difficulties as >>> signs of decline and decay. >>> >>> -- Eric Hoffer, Reflections on the Human Condition >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
