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
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
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
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
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 d...@fortysix.ch wrote:
We use the
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
On Apr 13, 2014, at 11:14 AM, Jeff Jensen jeffjen...@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
On Sunday, 13 April 2014, Jeff Jensen jeffjen...@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
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
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
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
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
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
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY herve.bout...@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
On Apr 12, 2014, at 8:16 AM, Benson Margulies bimargul...@gmail.com wrote:
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY herve.bout...@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
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 bimargul...@gmail.com wrote:
On Sat, Apr 12, 2014 at 8:07 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
after thinking more at it, it seems the scope for such artifacts is the
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
17 matches
Mail list logo
