Hi,
The vote has passed with the following result:
+1 (binding): Hervé Boutemy, Robert Scholte, Dennis Lundberg
+1 (non binding): Karl Heinz Marbaise, Mirko Friedenhagen
I will promote the artifacts to the central repo. Thanks for your help!
On Thu, Apr 10, 2014 at 9:35 PM, Dennis Lundberg wr
+1 from me
On Thu, Apr 10, 2014 at 9:35 PM, Dennis Lundberg wrote:
> Hi,
>
> We solved 12 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212&version=19130&styleName=Html
>
> The most important one being that the plugin can now (again) be used
> to generate announcements fr
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
Isn't the point here that compile scope would turn into runtime scope *when
transitive*?
So this is not the same as the current trick of putting
true on a dependency.
In general I am in favour if demoting dependencies to runtime when
transitive (we always warned this was the long term plan)... Bu
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
On Apr 13, 2014, at 8:11 AM, Lennart Jörelid wrote:
> Hello all,
>
> Let’s see if we can focus on the issue at hand here.
>
> 12 apr 2014 kl. 16:59 skrev Jason van Zyl :
>
>>
>> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid
>> wrote:
>>
>>> Oh I know it is the recommended practise, but I b
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
Hello all,
Let’s see if we can focus on the issue at hand here.
12 apr 2014 kl. 16:59 skrev Jason van Zyl :
>
> On Apr 12, 2014, at 7:24 AM, Lennart Jörelid
> wrote:
>
>> Oh I know it is the recommended practise, but I believe that particular
>> recommendation is flawed since it does not con
+1
Op Thu, 10 Apr 2014 21:35:10 +0200 schreef Dennis Lundberg
:
Hi,
We solved 12 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212&version=19130&styleName=Html
The most important one being that the plugin can now (again) be used
to generate announcements from JIRA fo
16 matches
Mail list logo
