Thanks Babtiste, I never used the m-remote-resource-p so far, but after reading through the docu it seem to fit into my needs. …maybe the name is a bit misleading - I think m-shared-resources-p would disci be it a lot better. I’ll take a closer look at it and if it fits, I have to start a lengthy discussion in our organization :) Domi
On 14.04.2014, at 14:20, Baptiste Mathus <bmat...@batmat.net> wrote: > Sorry, coming in a bit late here, but isn't is more a use-case for > m-remote-resources-p? > > Cheers > > > 2014-04-13 15:43 GMT+02:00 Dominik Bartholdi <d...@fortysix.ch>: > >> 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 >> >> > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
