War plugin and artifact handling

[hans_d]

At the moment the war plugin is disabling the jar task, adding a war
task and adding this war task to the archive configuration to be
published.

It does not feel right that the war is published by default. It is
usually something that get's deployed and not published. If this is
really wanted you can always add it. There is something even worse about
that. When you have a project dependency on a war project, you get the
war in the classpath. This is a Gradle bug I would say. The project I'm
working on at the moment has scenarios like this. One could argue that
this is not necessarily a good modularization but that is not our cup of
tea.

In the future we want to resolve project dependencies by their classes
directory. That would solve the project dependencies issue. Additionally
we will have a deployable and library plugin (based on the java plugin).
That way there would be no default jar task in a war project, only in
the library project.

But what shall we do on short term (e.g. for 0.9)?

I think we shouldn't publish the war. Additionally if we enable the jar
task, that would solve the project dependency issue. It adds a little
overhead to the project (jar creation), but the behavior would be
correct.

- Hans
--
  Hans Dockter
  [hidden email]


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:

> At the moment the war plugin is disabling the jar task, adding a war
> task and adding this war task to the archive configuration to be
> published.
>
> It does not feel right that the war is published by default. It is
> usually something that get's deployed and not published. If this is
> really wanted you can always add it. There is something even worse about
> that. When you have a project dependency on a war project, you get the
> war in the classpath. This is a Gradle bug I would say. The project I'm
> working on at the moment has scenarios like this. One could argue that
> this is not necessarily a good modularization but that is not our cup of
> tea.
>
> In the future we want to resolve project dependencies by their classes
> directory. That would solve the project dependencies issue. Additionally
> we will have a deployable and library plugin (based on the java plugin).
> That way there would be no default jar task in a war project, only in
> the library project.
>
> But what shall we do on short term (e.g. for 0.9)?
>
> I think we shouldn't publish the war. Additionally if we enable the jar
> task, that would solve the project dependency issue. It adds a little
> overhead to the project (jar creation), but the behavior would be
> correct.
>
>  

I think this is a good plan. When we change project dependencies to use
the classes dir, or when we split up the java plugin a bit, this will
solve the overhead problem.


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Porter]

+1 I like both long term and short term solutions

On Monday, December 7, 2009, Adam Murdoch <[hidden email]> wrote:

>
>
> Hans Dockter wrote:
>
> At the moment the war plugin is disabling the jar task, adding a war
> task and adding this war task to the archive configuration to be
> published.
> It does not feel right that the war is published by default. It is
> usually something that get's deployed and not published. If this is
> really wanted you can always add it. There is something even worse about
> that. When you have a project dependency on a war project, you get the
> war in the classpath. This is a Gradle bug I would say. The project I'm
> working on at the moment has scenarios like this. One could argue that
> this is not necessarily a good modularization but that is not our cup of
> tea.
> In the future we want to resolve project dependencies by their classes
> directory. That would solve the project dependencies issue. Additionally
> we will have a deployable and library plugin (based on the java plugin).
> That way there would be no default jar task in a war project, only in
> the library project.
> But what shall we do on short term (e.g. for 0.9)?
>
> I think we shouldn't publish the war. Additionally if we enable the jar
> task, that would solve the project dependency issue. It adds a little
> overhead to the project (jar creation), but the behavior would be
> correct.
>
>
>
>
> I think this is a good plan. When we change project dependencies to use the classes dir, or when we split up the java plugin a bit, this will solve the overhead problem.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email