The app loads all resources from the classpath. IIRC, Tomcat requires the exploded WAR. I think the Tomcat plugin also requires file system files for config, e.g. </warSourceDirectory>, </warDirectory>, and </contextFile>.
On Sun, Apr 13, 2014 at 10:19 AM, Jason van Zyl <[email protected]> wrote: > 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 > > > > > > > > > >
