On Sunday, 13 April 2014, 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. Could you replace that usage with dependency:unpack-dependencies (assuming you had a <scope>processing</scope> that kept it off the classpath... Not that WARs go on the classpath - Except for executable ones like Jenkins - but more to be explicit)? > > 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 unsubscri -- Sent from my phone
