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 d
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
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 :
> 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
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 service
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
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 JavaC
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 elements to
limit it to the war artifact only. However, the war module is not
currently a dep.
Some
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. ,
, and .
On Sun, Apr 13, 2014 at 10:19 AM, Jason van Zyl wrote:
> On Apr 13, 2014, at 11:14 AM, Jeff Jensen <
> jeffjen...@upst
On Sunday, 13 April 2014, Jeff Jensen
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
> te
On Apr 13, 2014, at 11:14 AM, Jeff Jensen
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 (acceptanc
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 exp
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 wrote:
> We use the dependency:unpack
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
On Apr 12, 2014, at 11:32 AM, Benson Margulies 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 normal
On Sat, Apr 12, 2014 at 11:14 AM, Jason van Zyl wrote:
>
> On Apr 12, 2014, at 8:16 AM, Benson Margulies wrote:
>
>> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY wrote:
>>> after thinking more at it, it seems the "scope" for such artifacts is the
>>> plugin parameter name
>>>
>>
>> I'm forking
On Apr 12, 2014, at 8:16 AM, Benson Margulies wrote:
> On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY 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 plac
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY 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 on
17 matches
Mail list logo
