Quoting Brett Porter [EMAIL PROTECTED]:
I don't think either of these are cases for 'package resources', but
general lifecycle improvements (Which are in the 2.1 design wiki).
I'm still arguing for a generic lifecycle management (where a mojo can
add any number of additional phases and maven
I don't think either of these are cases for 'package resources', but
general lifecycle improvements (Which are in the 2.1 design wiki).
Is that right?
- Brett
On 06/01/2007, at 7:47 AM, Aaron Digulla wrote:
Brett Porter wrote:
Can anyone think of a use case other than the war plugin, or
Brett Porter wrote:
Can anyone think of a use case other than the war plugin, or should we
just go with the pre-package phase?
I have these use cases:
- Filter or generate files for the site plugin (for example, extract
information out of the sources for apt files)
- Multi-Step source/unit
Can anyone think of a use case other than the war plugin, or should
we just go with the pre-package phase?
On 18/12/2006, at 8:49 PM, Brett Porter wrote:
On 18/12/2006, at 7:02 PM, Kenney Westerhof wrote:
If you put it that way, then it sounds fine. Except it's not
generally appliccable,
Brett Porter wrote:
I read through all these threads, and they kind of ran off into entirely
different tracks on alternate build systems and CM.
On Kenney's points in particular:
On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote:
I'm basically -0 on adding
On 18/12/2006, at 7:02 PM, Kenney Westerhof wrote:
If you put it that way, then it sounds fine. Except it's not
generally appliccable,
only for (currently) war projects (possibly ear projects too).
(Also for non-java projects, resources usually aren't classpath
resources - real resources
Hello,
What about we just change the lifecycle for the war plugin and add
phases there?
Because the same problem crops up time and time again which means the
current solution is part of the problem.
Imagine. I'm generating a database for my tests from XML descriptions.
The intended control
I read through all these threads, and they kind of ran off into
entirely different tracks on alternate build systems and CM.
On Kenney's points in particular:
On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote:
I'm basically -0 on adding generate-package-resources/process-
package-resources
Kenney Westerhof [EMAIL PROTECTED] schrieb am 07.12.2006 15:54:46:
Hi,
What I'm reading below looks exactly like Maven, except for the scope of
the
dependencies.
Just for fun, I'll try to make the differences in your system and maven
more concrete. Correct me if I get anything
Hi,
What I'm reading below looks exactly like Maven, except for the scope of the
dependencies.
Just for fun, I'll try to make the differences in your system and maven
more concrete. Correct me if I get anything wrong.
In Maven we have 2 types of 'dependencies': artifact dependencies, which
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 17:43:29:
As I said before, I've had very good results with a build system in
which
you can specify arbitrary phases and say this phase depends on
that one.
And how much luck have you had showing that system to other people?
And
Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52:
The weakness is that someone, somewhere, has to lay down what those
states are. And what works for simple
ready-to-compile-compiled-packaged-tested-published lifecycle gets
complex if you have to do silly things like throw
[EMAIL PROTECTED] wrote:
Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52:
The weakness is that someone, somewhere, has to lay down what those
states are. And what works for simple
ready-to-compile-compiled-packaged-tested-published lifecycle gets
complex if you have to do
A build tool should make the obvious things simple but it should not
prevent to solve corner cases. The current maven build system just cannot
cope with running mvn deploy for a part of the project so you can run
your tests in another.
The question is not if it's a stupid thing to do, the
Hi,
Some ramblings, trying to analyze a use-case and finding a solution without
modifying the lifecycle:
Michael Horwitz wrote:
Hi,
As a side note it strikes me that the primary problem is that the war:war
goal does a little too much in a single go during the packaging phase.
Could
the
Jason van Zyl wrote:
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful.
But I understand what you are driving at. If there was a way to
register
Kenney Westerhof wrote:
The real problem is that people want an unpacked artifact, probably
since packaging
a war artifact is too slow (lots of dependencies copied, and zipping
up zips is slow).
More or less, in the parallel thread Manipulating the WAR directory
before the WAR file gets built
Simone Gianni wrote:
Kenney Westerhof wrote:
The real problem is that people want an unpacked artifact, probably
since packaging
a war artifact is too slow (lots of dependencies copied, and zipping
up zips is slow).
More or less, in the parallel thread Manipulating the WAR directory
before
On 12/5/06, Kenney Westerhof [EMAIL PROTECTED] wrote:
A solution for this case would be to not allow any code in war projects;
everything that goes in /WEB-INF/classes
should just be in a dependency placed in /WEB-INF/lib.
This would be a pain for things like web framework example apps. (It
Hi...
On Tue, 2006-12-05 at 14:14 -0700, Wendy Smoak wrote:
On 12/5/06, Kenney Westerhof [EMAIL PROTECTED] wrote:
A solution for this case would be to not allow any code in war projects;
everything that goes in /WEB-INF/classes
should just be in a dependency placed in /WEB-INF/lib.
On 03/12/06, Jason van Zyl [EMAIL PROTECTED] wrote:
What else would use it. I'm generally fine with things changing
provided you have the magic three. And can you think of any adverse
affects or conflicts with other phases. I can't think of any off the
top of my head but adding a new lifecycle
On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Pretty sure the issue already exists... should just be done IMO.
Ah-ha, found it.. :)
http://jira.codehaus.org/browse/MNG-2097
Mark
-
To unsubscribe, e-mail: [EMAIL
Hi,
As a side note it strikes me that the primary problem is that the war:war
goal does a little too much in a single go during the packaging phase. Could
the issue be solved by spreading the work of the war:war goal through the
existing phases?
Mike Horwitz
On 12/4/06, Mark Hobson [EMAIL
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may find
other needs.
Currently, *-resources handles class path resources, which are
required to be treated separately to the package because in many
cases, such
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may find
other needs.
Currently, *-resources handles class path resources, which are
required to be treated separately
On 04/12/2006, at 10:24 PM, Mark Hobson wrote:
Sounds good; although in the case of a war, would executing up to the
process-package-resources phase produce the fully exploded war? Or
would the package resources only contain the web resources, omitting
WEB-INF/**?
My use-case would require
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Well, it would be like other archives. By default, it would pull them
from the various added sources straight into the archive - src/main/
webapp, target/generated-package-resources, for example. However, it
would be sensible for the war plugin
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at hand.
While easily solved by pre-package at this point, we may find other needs.
To take these suggestions even further, perhaps the idea of a fixed set
of phases is too limiting. An alternative would be to
Pretty sure we've shouted it down with reasons before, hopefully the
archives will be of some assistance :)
- Brett
On 05/12/2006, at 12:08 AM, Richard van der Hoff wrote:
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by
On 4 Dec 2006, at 14:08, Richard van der Hoff wrote:
Brett Porter wrote:
Actually, before we jump into this, let's consider the use case at
hand. While easily solved by pre-package at this point, we may
find other needs.
To take these suggestions even further, perhaps the idea of a fixed
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful. But
I understand what you are driving at. If there was a way to register
named phases with the numbers that would be better.
OTOH, wouldn't it be
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful.
But I understand what you are driving at. If there was a way to
register named phases with
Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006
14:08:37:
Actually, before we jump into this, let's consider the use case at
hand.
While easily solved by pre-package at this point, we may find other
needs.
To take these suggestions even further, perhaps the idea of a fixed
On 4 Dec 2006, at 16:51, Jason van Zyl wrote:
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems
awful. But I understand what you are driving at. If
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 16:51:30:
You can always make your own lifecycle, which is not that hard if you
really need it.[...]To
allow free form to accommodate the ever shrinking number of cases we
can't handle is just not worth it. The standard lifecycle then
On 4 Dec 06, at 11:14 AM 4 Dec 06, [EMAIL PROTECTED] wrote:
Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006
14:08:37:
Actually, before we jump into this, let's consider the use case at
hand.
While easily solved by pre-package at this point, we may find other
needs.
To take
Hi there,
Has anyone got any objections to adding a new 'pre-package' phase to
the default lifecycle? This is required by goals such as
tomcat:run-war which require package pre-processing (overlaying wars,
etc.) but not necessarily the fully built archive.
I'll raise an issue if no-one
Mark Hobson wrote:
Hi there,
Has anyone got any objections to adding a new 'pre-package' phase to
the default lifecycle? This is required by goals such as
tomcat:run-war which require package pre-processing (overlaying wars,
etc.) but not necessarily the fully built archive.
I would
+1
--
Regards,
Garvin LeClaire
[EMAIL PROTECTED]
On 12/3/06, Trygve Laugstøl [EMAIL PROTECTED] wrote:
Mark Hobson wrote:
Hi there,
Has anyone got any objections to adding a new 'pre-package' phase to
the default lifecycle? This is required by goals such as
tomcat:run-war which
Pretty sure the issue already exists... should just be done IMO.
On 04/12/2006, at 8:28 AM, Mark Hobson wrote:
Hi there,
Has anyone got any objections to adding a new 'pre-package' phase to
the default lifecycle? This is required by goals such as
tomcat:run-war which require package
On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote:
Pretty sure the issue already exists... should just be done IMO.
I did search JIRA for 'lifecycle' and couldn't anything. Let me know
if you can find the issue.
Mark
-
To
On 3 Dec 06, at 4:28 PM 3 Dec 06, Mark Hobson wrote:
Hi there,
Has anyone got any objections to adding a new 'pre-package' phase to
the default lifecycle? This is required by goals such as
tomcat:run-war which require package pre-processing (overlaying wars,
etc.) but not necessarily the
42 matches
Mail list logo
