I'm not sure but seems like it could work. They both pull artifacts from repo but unpack processes only the named ones and unpack-dependencies does the listed deps. Would need to use one of the </include*> elements to limit it to the war artifact only. However, the war module is not currently a dep.
Some more notes on the AT module setup: - It only has the tests and the test infrastructure. - Its build starts a few things, including embedded Tomcat. The tests run against the Tomcat instance (which is running the war). - Its deps are only those required for the tests - other modules and 3rd party. The WAR module is not in the list of deps. On Sun, Apr 13, 2014 at 10:49 AM, Stephen Connolly < [email protected]> wrote: > 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 >
