On Apr 13, 2014, at 11:14 AM, Jeff Jensen <[email protected]> wrote:
> Agreed, we put the WSDL and related schemas in a domain module and its > build generates these domain classes in its build. Then other modules use > the domain jar... > > The only place we currently use dependency:unpack is in an AT (acceptance > test) module that retrieves the war and unpacks it to an exploded war dir > for then starting embedded Tomcat for the tests. > Is this only because the WAR needs to be exploded to work? In that you expect resources to be in the file system vs the classpath? > > On Sun, Apr 13, 2014 at 9:57 AM, 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 >> >> >> >> >> >> >> >> >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
