Hi,
first many thanks four your feedback...
> I share these doubts.
> Why wrapping a Maven plugin with a Maven Plugin? I haven't watched the
code, but to make it work, you probably need to reuse pluginManagement
from Maven Core. This will make it unnecessary complex.
It isn't easy and currently not solved completely (only the plugin
versions seemed to be solved)...is there a good example how to solve in
the right way ?
I'd prefer to fix it in the target plugin.
Also keep in mind that for instance the maven-release-plugin doesn't
analyse plugin configuration, so if you use a SNAPSHOT as
plugin-version, the result will be unstable after release.
Wasn't aware of that? Good to know...
Maybe I'm misunderstanding the examples, but both can be done without
the iterator-plugin and with less xml.
Yes you can do those examples without iterator-plugin...but there are
two prerequisites:
First the item list is static which means is not dynamically created
(which i had in mind; read from special files CSV don't laugh;-))
and
Secondly only has a few elements like 1-5 elements. I know that i can do
that with an appropriate number of executions ...
https://github.com/khmarbaise/multiple-artifacts/tree/master/war
But with less xml i have my doubts...may be i can learn something i
didn't know about Maven how to do such things in a better way?
I'm wondering which issue you hit when writing this plugin, maybe
there's another solution to the core problem.
I will explain my problems a little bit more...
The problems i stumbled over is related to
configuration/environments/servers parts which I'm aware of being an
anti-pattern and furthermore if I'm really accurate out of scope of
Maven (getting into deployment directions..)..but having a large number
of projects (ca. 150) must be build for particular
environments/configurations/servers isn't such that easy to persuade
people to go the right way via JNDI/whatever etc. to pick up
configurations. Currently it's a large jungle of shell scripts/ant
scripts etc. which doing this which is currently a horror in handling
releases/dependencies etc. and produces many other problems...
so the plugin is the lesser evil thing in this context....afterwards
cleaning up the builds/deployments etc. i can persuade the people to go
into the right direction (like using chef, puppet for the real
deployment job).
I have concerns that the plugin would either interact poorly with the
reactor, or encourage patterns of use where poor interaction with the
reactor is encouraged.
Additionally, the primary use cases, from what I can see, are all
about configuring things for specific environments, which is an
anti-pattern in my experience.
I'm having exactly the same opinion and from my experience as
well...that's what I'm telling the people all the time ...this will
strengthen the case against building for different environments...
Having said that, I'm not going to block people pursuing this line,
just that I worry it will create a support burden that we may find
difficult to meet given our current inability (to my mind) to meet the
requirements existing plugins need.
My view is we should concentrate on maven's core competences and make
life easier for users within that sphere... So for example the
templating maven plugin makes it very easy to do something that many
people want to do (and given the JavaEE annotations requiring JNDI
names that include the jar name... This is a real problem even if we
might view as an anti-pattern)
Similarly the non-maven-jar plugin I released from my GitHub account
last week addresses issues a lot of people hit, but in a way that is
as close to best practice as possible.
It's really sad that I'm becoming aware of that plugin by coincidence
(in relationship with this thread) and not earlier, cause it would have
helped me several times in discussions with others about exactly those
problems...
Do you have reasons why not making an announcements here on the lists,
to get people informed that solutions like this exist which make life
easier?
From what I can see, I don't see a way of using this that isn't at
least 2-3 anti- patterns at the same time... Perhaps you can enlighten
me to the contrary
I wouldn't enlighten you to the contrary, cause I'm the same opinion...;-)
Many thanks for sharing your thought with me.
Kind regards
Karl-Heinz Marbaise
Sent from my iPhone
On 31 Mar 2013, at 14:40, Karl Heinz Marbaise <[email protected]> wrote:
Hi to all developers,
i wan't to know what Maven developers think about this plugin...
Based on the name it can iterate through a list of values and with
the values it can call other plugins or a separate maven instance
(currently not very well documented I'm working on that).
The plugin code can be found here:
https://github.com/khmarbaise/iterator-maven-plugin
You can do things like this
(http://khmarbaise.github.com/iterator-maven-plugin/executor-overview.html):
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>iterator-maven-plugin</artifactId>
<version>0.1.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>executor</goal>
</goals>
<configuration>
<items>
<item>test</item>
<item>prod</item>
<item>dev</item>
</items>
<pluginExecutors>
<pluginExecutor>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
</plugin>
<goal>single</goal>
<configuration>
<descriptors>
<descriptor>${project.basedir}/@[email protected]</descriptor>
</descriptors>
</configuration>
</pluginExecutor>
</pluginExecutors>
</configuration>
</execution>
</executions>
</plugin>
and other things.
An example for invoking a Maven instance can be looked at an
integration test:
https://github.com/khmarbaise/iterator-maven-plugin/blob/master/src/it/invokerBasicTest/pom.xml
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
