You don't think it's odd to bury a WSDL in a WAR file that you deploy and then turn around and retrieve again to grab the WSDL that you had in the first place? Are you making a general purpose server that has varying client service entry points depending on the customer? So you have the same WAR that is used by many customers and customer A may use REST and customer B may use SOAP and you produce different builds for these different customers?
On Apr 13, 2014, at 12:51 PM, Dominik Bartholdi <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <[email protected]> >>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> 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: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
