It really sounds to me like this should be done with a profile that is
triggered
by the presence of a specific file (i.e. "db-changeset.sql"), as can be
seen
at http://maven.apache.org/guides/introduction/introduction-to-profiles.html
At least this is the way most people handle this, which ensures that the
db-upgrade procedure has a well-defined set of actions attached to it
that can be inferred from reading the poms.
Was there something specific that prevented you from using profiles?
Kristian
Den 07.02.2011 04:46, skrev Kalyan Akella:
A few days back, I was working with the Liquibase Maven
Plugin<http://www.liquibase.org/manual/maven>for doing DB upgrades in
my project. This plugin has 2 specific goals, among
others, which I was using,
update<http://www.liquibase.org/manual/maven_update>&
rollback<http://www.liquibase.org/manual/maven_rollback>. 'update' goal
executes all the Liquibase change-sets& 'rollback' undoes the applied
change-sets.
So here's my scenario. I need update& rollback to happen on my local test
DB during the integration-test phase. Moreover, I want them to execute only
when I introduce a Liquibase changeset. The idea was to verify whether my
change-set is a valid one by doing an upgrade->rollback->upgrade cycle on
the test DB. Because, there were a large number of updates, I only wanted
this to happen if I introduce a change-set in the first place.
Initially, I wanted to control this behavior at the plugin level (in the
POM) where I choose to execute the Liquibase plugins or not based on whether
I pass in a system property (ala, -DskipTests) or through some other
mechanism. Unfortunately, both the Liquibase plugins do not support the skip
flag (as others do, like the surefire plugin). I had to later achieve this
result by moving these two plugins inside a Maven profile and skip the
profile altogether using the activation tag.
So, here's my point. Whatever reasoning was behind the introduction of
'skip' flag functionality in some plugins like surefire, is the same very
reason we need this support to be built across all plugins in a generic way.
We can achieve this at the Maven level either through the CLI or through the
POM as my implementation proves. It is of course, up to the community to
decide when this should be rolled out as a feature.
Sincere Regards,
Kalyan C. Akella
On Sun, Feb 6, 2011 at 8:32 PM, Jason van Zyl<ja...@sonatype.com> wrote:
Out of curiosity what is the first thing you used this feature for?
On Feb 6, 2011, at 8:06 AM, Kalyan Akella wrote:
Hi,
Thank you for the comments.
First of all, these changes DO NOT affect the existing integration test
suite. I verified this by running the ENTIRE suite with& without my
patches. The *results are the same*.
Secondly, I am in no urgent need to get these changes to Maven 3.0.x. Do
it
as you see fit. My request for applying the patches was only from a pure
code review perspective.
Lastly, I shall update the JIRA ticket with the specific use cases where
this feature helps. If my time permits, I'll update the usage&
documentation.
Sincere Regards,
Kalyan C. Akella
On Sun, Feb 6, 2011 at 3:28 AM, Jason van Zyl<ja...@sonatype.com>
wrote:
On Feb 5, 2011, at 7:43 AM, Kalyan Akella wrote:
Hi,
I attached the revised patches to the issues that implement the
following:
1. ability to skip multiple plugins& their executions at CLI,
2. ability to skip plugins& their executions in POM using the<skip>
element
I'm still working on the documentation. Please apply the patches and
let
me
know your comments.
These patches are not going to be applied to trunk right away.
I would suggest using the Github Maven tree, make a branch and apply
your
changes there if you would like people to try them. This is something
that
would greatly change the behavior of Maven so it's not going into 3.0.x.
It
may go into Maven 3.1 but that's a discussion. Changes like this aren't
going in without a discussion. I also asked that explanations be
provided
about why this patch is useful and the use cases surrounding its
functionality.
If you haven't already, we can show you how the integration test suite
works, as any changes you make must not affect the operation of the
existing
integration tests.
Sincere Regards,
Kalyan C. Akella
On Wed, Feb 2, 2011 at 9:27 AM, Kalyan Akella<kalyan.ake...@gmail.com
wrote:
Hi,
Thank you for the patch review comments. I hope it is integrated to
the
trunk.
My next steps:
1. Implement support for skipping multiple plugins/executions at the
CLI.
2. Implement ability to skip plugin execution through the POM as
required
by http://jira.codehaus.org/browse/MNG-3102
3. Add documentation (with the proper reasoning) for both these
approaches.
Sincere Regards,
Kalyan C. Akella
On Wed, Feb 2, 2011 at 3:17 AM, Kristian Rosenvold<
kristian.rosenv...@gmail.com> wrote:
Our main topic of discussion on irc was initially if this *should* be
a
3.0.X or 3.1 issue due to being somewhat of a borderline between
improvement/new feature. It seems to me like the way this discussion
is
heading, it should probably be tagged 3.1.
I agree very much about getting some well defined use cases and
John's comments on the issue are also very good.
I will leave the issue at "3.1" for now, and request well defined
use-cases on the issue.
Kristian (I have all the skip options I need already)
ti., 01.02.2011 kl. 15.44 -0500, skrev Jason van Zyl:
So the technical work was done implementing this but no where in the
issue does it describe why this feature is useful.
This fundamentally changes the behaviour of the lifecycle and the
example listed in the issue is skipping tests. Some explanation of
why
this
is good would be nice, there's nothing about the reasoning of the
feature in
the issue. Possibly something like:
- As a user I would like to skip the test phase locally, and only
from
the command line so it's easier while I experiment putting new test
features
in place. But I would like to guarantee that these can only be done
from the
command line and never in the presence of the release plugin so that
skipping phases is not done inadvertently during a release.
The second case in a issue doesn't strike me as useful without an
explanation, to run to the install phase but not package the JAR?
I think a fundamental alteration of behaviour requires an
explanation
of
reasoning. I believe that is reasonable. It initially strikes me as a
potentially bad idea. Maybe you talked about the reasoning in IRC,
which I
think is perfectly fine, just toss the discussion or salient points
of
the
reasoning into the issue.
On Feb 1, 2011, at 3:00 PM, Kristian Rosenvold wrote:
I have looked at the patch diffs and it looks really great, one of
the
better patches I've seen in the issue trackers !
We had a quick chat about this patch on irc and we figured we could
take
this patch for 3.0.x.
One thing we would like though, is to be able to specify multiple
exclusions, not just one plugin/execution. Any chance you could fix
that ?
As for the documentation, that would be something
like https://svn.apache.org/repos/asf/maven/site/trunk
and the document
src/site/apt/guides/mini/guide-configuring-maven.apt
Sorry for not replying immediately; been busy preparing
my trip to the alps tomorrow ;)
Kristian
ti., 01.02.2011 kl. 09.16 +0530, skrev Kalyan Akella:
Hi,
Any updates on the patch. Did it apply cleanly ? Any comments,
changes ??
Sincere Regards,
Kalyan C. Akella
On Sat, Jan 29, 2011 at 8:01 AM, Kalyan Akella<
kalyan.ake...@gmail.com>wrote:
Hi,
Thank you for the comments. I updated the issue,
http://jira.codehaus.org/browse/MNG-3321 with the modified
patches.
Regarding your point about documentation, will you please point
me
to the
exact location where I should include the usage instructions for
this
feature and other info (perhaps a wiki ?).
Sincere Regards,
Kalyan C. Akella
On Fri, Jan 28, 2011 at 12:55 PM, Kristian Rosenvold<
kristian.rosenv...@gmail.com> wrote:
Thanks for the patch, which looks good. I added some comments to
the
issue, http://jira.codehaus.org/browse/MNG-3321
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver
might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
