FWIW, we've used that in the past to store and version our PMD & checkstyle rules configs for the organization for example. IMO, indeed more maven-ish in the sense that you only describe the resource you need (/what/), but not the /how/ (which scripting-like things like dependency:unpack tends to do).
HTH 2014-04-14 15:05 GMT+02:00 Dominik Bartholdi <[email protected]>: > > 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 <[email protected]> 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 <[email protected]>: > > > >> 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 > >> > >> > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
