If never sad anything about REST… Don’t hang me just because I sad we used the WAR, thats just a shortage of one specific use case - in general we use ZIP or JAR for this and the archive contains nothing else then the WSDLs. In fact these WSDLs do not describe any JavaServices, but COBAL services, even more, the provider code in COBOL does get generated from these WSDLs too. So consumer and provider (Stub) get generated by these WSDLs. …and these clients are by far not all Java based... So yes I’ don’t think its odd to have these service interfaces well defined and provided as WSDLs packed up in an archive in a maven repo. Domi
On 13.04.2014, at 19:42, Jason van Zyl <ja...@takari.io> wrote: > 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 <d...@fortysix.ch> 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 <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 >> > > 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. > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
