You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2014/04/12 14:16:15 UTC
Why is dependency:unpack evil
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> after thinking more at it, it seems the "scope" for such artifacts is the
> plugin parameter name
>
I'm forking off a new thread here.
A maven repository is a lovely place to keep all sorts of data used in
builds: test data, templates of one sort of another. Data pushed to a
repo is accessible from Maven, ant, and plain old command lines via
just plain wget.
However, for large objects, the Maven local repo can avoid a whole lot
of time spent shoving bytes around the network. So, using 'wget' or
some sort of wagon plugin is not as nice as dependency:copy or
:unpack.
If I'm following this thread, some people dislike this because it is
our of the usual maven pattern of declaring rather than instructing: I
should declare that I need a:b:1.0:zip.
However, I'm failing to see the great advantage of being required to
specify _both_ a dependency and then a slug of XML configuration to a
plugin to specify the details of how something gets unpacked.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is dependency:unpack evil
Posted by Baptiste Mathus <bm...@batmat.net>.
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 <do...@fortysix.ch>:
>
> 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 <bm...@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 <do...@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 <bi...@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-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Why is dependency:unpack evil
Posted by Dominik Bartholdi <do...@fortysix.ch>.
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 <bm...@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 <do...@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 <bi...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is dependency:unpack evil
Posted by Baptiste Mathus <bm...@batmat.net>.
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 <do...@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 <bi...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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 !
Re: Why is dependency:unpack evil
Posted by Dominik Bartholdi <do...@fortysix.ch>.
If never sad anything about REST…
Don’t hang me just because I sad we used the WAR, thats just a shortage of one specific use case - in general we use ZIP or JAR for this and the archive contains nothing else then the WSDLs. In fact these WSDLs do not describe any JavaServices, but COBAL services, even more, the provider code in COBOL does get generated from these WSDLs too. So consumer and provider (Stub) get generated by these WSDLs. …and these clients are by far not all Java based...
So yes I’ don’t think its odd to have these service interfaces well defined and provided as WSDLs packed up in an archive in a maven repo.
Domi
On 13.04.2014, at 19:42, Jason van Zyl <ja...@takari.io> wrote:
> You don't think it's odd to bury a WSDL in a WAR file that you deploy and then turn around and retrieve again to grab the WSDL that you had in the first place? Are you making a general purpose server that has varying client service entry points depending on the customer? So you have the same WAR that is used by many customers and customer A may use REST and customer B may use SOAP and you produce different builds for these different customers?
>
> On Apr 13, 2014, at 12:51 PM, Dominik Bartholdi <do...@fortysix.ch> wrote:
>
>> I really don’t understand what’s odd about this case - I agree, it would be better off in a zip or jar (or any other format), but it seem quite natural to put these resources
>> in an archive and have it versioned and released the normal way as any other artifact. After all, there is not only JavaCode which can be generated by the WSDLs and it is not possible to know which which client technology might use the WSDLs to generate its service layer with it. In my point of view this is not just handy but an absolut must of a functionality.
>> Domi
>>
>> On 13.04.2014, at 16:57, Jason van Zyl <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
>>>>
>>>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is dependency:unpack evil
Posted by Jason van Zyl <ja...@takari.io>.
You don't think it's odd to bury a WSDL in a WAR file that you deploy and then turn around and retrieve again to grab the WSDL that you had in the first place? Are you making a general purpose server that has varying client service entry points depending on the customer? So you have the same WAR that is used by many customers and customer A may use REST and customer B may use SOAP and you produce different builds for these different customers?
On Apr 13, 2014, at 12:51 PM, Dominik Bartholdi <do...@fortysix.ch> wrote:
> I really don’t understand what’s odd about this case - I agree, it would be better off in a zip or jar (or any other format), but it seem quite natural to put these resources
> in an archive and have it versioned and released the normal way as any other artifact. After all, there is not only JavaCode which can be generated by the WSDLs and it is not possible to know which which client technology might use the WSDLs to generate its service layer with it. In my point of view this is not just handy but an absolut must of a functionality.
> Domi
>
> On 13.04.2014, at 16:57, Jason van Zyl <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
>>>
>>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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
>>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
Re: Why is dependency:unpack evil
Posted by Dominik Bartholdi <do...@fortysix.ch>.
I really don’t understand what’s odd about this case - I agree, it would be better off in a zip or jar (or any other format), but it seem quite natural to put these resources
in an archive and have it versioned and released the normal way as any other artifact. After all, there is not only JavaCode which can be generated by the WSDLs and it is not possible to know which which client technology might use the WSDLs to generate its service layer with it. In my point of view this is not just handy but an absolut must of a functionality.
Domi
On 13.04.2014, at 16:57, Jason van Zyl <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
>>
>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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
>>
>
> 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
>
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is dependency:unpack evil
Posted by Jeff Jensen <je...@upstairstechnology.com>.
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 <
stephen.alan.connolly@gmail.com> wrote:
> On Sunday, 13 April 2014, Jeff Jensen <je...@upstairstechnology.com>
> 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 <ja...@takari.io> 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 <do...@fortysix.ch>
> 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 <ja...@takari.io> wrote:
> > > >
> > > >> On Apr 12, 2014, at 11:32 AM, Benson Margulies <
> bimargulies@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-unsubscribe@maven.apache.org
> > > >>>>> For additional commands, e-mail: dev-help@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 unsubscri
>
>
>
> --
> Sent from my phone
>
Re: Why is dependency:unpack evil
Posted by Stephen Connolly <st...@gmail.com>.
On Sunday, 13 April 2014, Jeff Jensen <je...@upstairstechnology.com>
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 <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
> > >
> > >> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bimargulies@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-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@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 unsubscri
--
Sent from my phone
Re: Why is dependency:unpack evil
Posted by Jeff Jensen <je...@upstairstechnology.com>.
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 <ja...@takari.io> wrote:
> On Apr 13, 2014, at 11:14 AM, Jeff Jensen <
> jeffjensen@upstairstechnology.com> 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 <ja...@takari.io> 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 <do...@fortysix.ch>
> 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 <ja...@takari.io> wrote:
> >>>
> >>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bimargulies@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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@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
> >>>
> >>
> >> 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
>
>
>
>
>
>
>
>
>
>
Re: Why is dependency:unpack evil
Posted by Jason van Zyl <ja...@takari.io>.
On Apr 13, 2014, at 11:14 AM, Jeff Jensen <je...@upstairstechnology.com> 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 <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
>>>
>>>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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
>>>
>>
>> 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
Re: Why is dependency:unpack evil
Posted by Jeff Jensen <je...@upstairstechnology.com>.
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.
On Sun, Apr 13, 2014 at 9:57 AM, Jason van Zyl <ja...@takari.io> 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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
> >
> >> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@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
> >
>
> 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
>
>
>
>
>
>
>
>
>
>
Re: Why is dependency:unpack evil
Posted by Jason van Zyl <ja...@takari.io>.
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 <do...@fortysix.ch> 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 <ja...@takari.io> wrote:
>
>> On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
>
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
Re: Why is dependency:unpack evil
Posted by Dominik Bartholdi <do...@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 <bi...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
Re: Why is dependency:unpack evil
Posted by Jason van Zyl <ja...@takari.io>.
On Apr 12, 2014, at 11:32 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
Re: Why is dependency:unpack evil
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Apr 12, 2014 at 11:14 AM, Jason van Zyl <ja...@takari.io> wrote:
>
> On Apr 12, 2014, at 8:16 AM, Benson Margulies <bi...@gmail.com> wrote:
>
>> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>>> after thinking more at it, it seems the "scope" for such artifacts is the
>>> plugin parameter name
>>>
>>
>> I'm forking off a new thread here.
>>
>> A maven repository is a lovely place to keep all sorts of data used in
>> builds: test data, templates of one sort of another. Data pushed to a
>> repo is accessible from Maven, ant, and plain old command lines via
>> just plain wget.
>>
>> However, for large objects, the Maven local repo can avoid a whole lot
>> of time spent shoving bytes around the network. So, using 'wget' or
>> some sort of wagon plugin is not as nice as dependency:copy or
>> :unpack.
>>
>> If I'm following this thread, some people dislike this because it is
>> our of the usual maven pattern of declaring rather than instructing: I
>> should declare that I need a:b:1.0:zip.
>>
>> However, I'm failing to see the great advantage of being required to
>> specify _both_ a dependency and then a slug of XML configuration to a
>> plugin to specify the details of how something gets unpacked.
>>
>
> This can also be declarative.
>
> If you're talking about build time the AAR example in Android is an example of the requirement to download something, move some bits around, and add it to the classpath. Same as a normal dependency except there are some bit swizzling instructions. In the pure build I believe any requirement to use the dependency plugin can be removed. This would be implemented as a smarter artifact handler that knows how to deal with AARs. Can still be purely declarative so we can analyze, reason about and execute.
>
> If you're talking about making a distribution where you're putting together a bunch of files the dependency plugin is very handy.
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. 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.'
>
>
>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why is dependency:unpack evil
Posted by Jason van Zyl <ja...@takari.io>.
On Apr 12, 2014, at 8:16 AM, Benson Margulies <bi...@gmail.com> wrote:
> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>> after thinking more at it, it seems the "scope" for such artifacts is the
>> plugin parameter name
>>
>
> I'm forking off a new thread here.
>
> A maven repository is a lovely place to keep all sorts of data used in
> builds: test data, templates of one sort of another. Data pushed to a
> repo is accessible from Maven, ant, and plain old command lines via
> just plain wget.
>
> However, for large objects, the Maven local repo can avoid a whole lot
> of time spent shoving bytes around the network. So, using 'wget' or
> some sort of wagon plugin is not as nice as dependency:copy or
> :unpack.
>
> If I'm following this thread, some people dislike this because it is
> our of the usual maven pattern of declaring rather than instructing: I
> should declare that I need a:b:1.0:zip.
>
> However, I'm failing to see the great advantage of being required to
> specify _both_ a dependency and then a slug of XML configuration to a
> plugin to specify the details of how something gets unpacked.
>
This can also be declarative.
If you're talking about build time the AAR example in Android is an example of the requirement to download something, move some bits around, and add it to the classpath. Same as a normal dependency except there are some bit swizzling instructions. In the pure build I believe any requirement to use the dependency plugin can be removed. This would be implemented as a smarter artifact handler that knows how to deal with AARs. Can still be purely declarative so we can analyze, reason about and execute.
If you're talking about making a distribution where you're putting together a bunch of files the dependency plugin is very handy.
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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