Configuring a build step in the default lifecycle
Hello, I want to create a new packaging type (for ConnId connectors) with a lifecycle that is very similar to the default (jar) lifecycle, but with a assembly build step for the packaging phase. I have a plugin-project with a 'plexus/components.xml' which defines the lifecycle and the artefact handler. The packaging is now recognised and the build works fine. Now I would like to move the configuration for the assembly build step to a shared location in the plugin project. I have tried to setup a lifecycle.xml with the definition in the plugin project but it is not being picked up. What would be the best way to implement this? Thanks and regards, -Maarten Winkels - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Configuring a build step in the default lifecycle
What do you mean by configuration for the assembly build step? You can't provide the configuration for a plugin through a custom packaging type (unfortunately). But you could create a shared assembly descriptor that should be used: http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html All projects need to specify this in their configuration of the assembly plugin though. Maybe you could provide an archetype to simplify this? /Anders On Mon, Apr 15, 2013 at 9:22 AM, Maarten Winkels maarten.wink...@iwelcome.com wrote: Hello, I want to create a new packaging type (for ConnId connectors) with a lifecycle that is very similar to the default (jar) lifecycle, but with a assembly build step for the packaging phase. I have a plugin-project with a 'plexus/components.xml' which defines the lifecycle and the artefact handler. The packaging is now recognised and the build works fine. Now I would like to move the configuration for the assembly build step to a shared location in the plugin project. I have tried to setup a lifecycle.xml with the definition in the plugin project but it is not being picked up. What would be the best way to implement this? Thanks and regards, -Maarten Winkels - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Compiler Plugin 3.1 Released
mb-olamy:maven-compiler-sample olamy$ hg diff
diff -r 282cd9fe95c4 pom.xml
--- a/pom.xml Sun Apr 14 14:48:37 2013 +0300
+++ b/pom.xml Mon Apr 15 22:06:35 2013 +1000
@@ -41,6 +41,9 @@
encoding${project.build.sourceEncoding}/encoding
source${maven.compiler.source}/source
target${maven.compiler.target}/target
+ excludes
+exclude**/package-info.java/exclude
+ /excludes
/configuration
/plugin
/plugins
the compiler plugin compare timestamp (and or new file **/*.java from
${project.build.sourceDirectory} to ${project.build.outputDirectory}
as long as there is any timestamp change or new file a compilation is
triggered.
As all package-info.java files never go to
${project.build.outputDirectory} a compilation is triggered.
HTH
2013/4/14 Stanimir Stamenkov s7a...@netscape.net:
Sat, 13 Apr 2013 20:55:17 +0300, /Stanimir Stamenkov/:
Thu, 11 Apr 2013 23:38:17 -0500, /Wayne Fay/:
I'm not sure it could be a clue but it happens for some (I haven't
verified all) WAR modules.
[...]
Is this a project you can share via Github? Or can you make a
sample that
(consistently) exhibits the behavior, and share just that part?
All right. Doesn't appear WAR-related, but consistently happens if
there are package-info.java files with no annotations (at least
@Retention(RUNTIME) ones) to cause a package-info.class generated
in the target/classes directory.
I don't use Git but here's a Hg source:
https://bitbucket.org/stanio/maven-compiler-sample
One could download a zipped bundle from:
https://bitbucket.org/stanio/maven-compiler-sample/downloads
(select Tags or Branches)
--
Stanimir
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
JXR: any plans to fix some parsing related issues?
Hi all, I've sketched a rough plugin https://github.com/davidecavestro/gradle-jxr-plugin to spread JXR even to gradle users. It just works, but it is limited by some parsing issues. I've filed JXR-101 https://jira.codehaus.org/browse/JXR-101 and JXR-100 https://jira.codehaus.org/browse/JXR-100 more than a month ago but I still got no response at all. Is there any roadmap for jxr? Is there any chance to get them (and other issues) fixed? I hope the project is not going to be discontinued. Cheers Davide PS: Please also let me know if I've written to the wrong mailing list. -- View this message in context: http://maven.40175.n5.nabble.com/JXR-any-plans-to-fix-some-parsing-related-issues-tp5753771.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
CC'ing users@maven because I think my point applies to the entire Maven
community:
Well my view is that such practice is bad practice, there are good ways to
do things and bad ways to do things. Hard-coding references between
projects using the file system is bad practice. For one thing it fails to
take into account the reactor mode and how people may not want the
filesystem changes being picked up when using the reactor mode (it's not
just build speed that draws people to the reactor mode of building)
Now if there are specific use cases for these things, then I think it is
better to ask why they think they need to use the filesystem to resolve
their intra-module stuff and why they cannot use the reactor as was
intended.
My conjecture is 90% of the time an existing plugin can provide what they
need while using the reactor metaphor.
The remaining 10% is divided between things [one should not be doing/one is
only doing this once] and [things that need a new maven plugin]
Additionally, of the 90% there's maybe 20-30% where the existing plugin
could be re-engineered or replaced to do things better.
A case in point of the improving (though not related to the idea of being
able to get a property exposing the root (never mind the which root:
reactor/inheritence/inheritence within reactor) but more related to
re-engineering to make life easier) is the templating maven pluging. In the
case of templating java source, one could do that already... just with
about 30-50 lines of pom.xml config... now with the templating plugin
you're looking at about 5-10 lines and 5 of those are just the standard
plugingroupIdartifactIdversion/plugin boilerplate.
My worry in providing such a property is that we enable people to hack
together something, instead of them screaming for a better way to do XYZ
and then the community providing that solution.
I do think it is sad that the Maven community has focused too much on reuse
for reuse's sake irrespective of the pom-bloat cost.
The point of trying to reuse is to keep the standard way of doing things...
but once we know the standard way, we should codify that standard way into
a simple to use plugin and let people use that instead...
* hacking around 3rd party jars which you cannot get into a repo =
non-maven-jar-maven-plugin (saves tons of xml lines)
* templating in .java source code = templating maven plugin (saves 100kg
of xml lines)
By all means we need to direct people to best practice... and my all means
we should try to get out of the way when people need to *Get Things Done*™
but if staying out of the way means that they get to leave the technical
debt there and not know its technical debt... then we have not been kind to
them.
People having to use ${basedir}/../.. and feeling uneasy about it... to my
mind that is the perfect balance. It's quick... it's dirty... you know it's
a hack... you know you should do better... you have the job done for now...
SPOT ON
If we have an official (because that's what mojo is... the offical side
project for plugins) plugin that gives the property they want... well
people will now have the quick and dirty hack and the job done for now, but
they won't know it's a hack, they won't know they should do better... and
we have lost another user's use case to assist.
We can do better as a community, and we should.
That means that we need to spot when somebody is involved in a *Get Things
Done*™ mode and help them get the damn thing working with the least pain,
but the proviso that they know and acknowledge this is technical debt that
they are building and once the time pressure is off, they should help us
help them remove the technical debt by finding a more *Maven Way*™ to do
it.
-Stephen
On 15 April 2013 16:00, avaz d...@andersonvaz.com wrote:
Hi,
As suggestion, this plugin could have a goal that set's the 'root parent
dir', I see this pretty useful for sharing plugin configuration based in
properties files located in the main parent in a multi module projets.
There is a lot of anxiety of it around web as can be seen:
http://stackoverflow.com/questions/1012402/maven2-property-that-indicates-the-parent-directory
http://stackoverflow.com/questions/1012402/maven2-property-that-indicates-the-parent-directory
http://stackoverflow.com/questions/3084629/finding-the-root-directory-of-a-multi-module-maven-reactor-project
http://stackoverflow.com/questions/3084629/finding-the-root-directory-of-a-multi-module-maven-reactor-project
http://stackoverflow.com/questions/8700097/how-to-get-the-super-pom-basedir-in-a-child-module-pom
http://stackoverflow.com/questions/8700097/how-to-get-the-super-pom-basedir-in-a-child-module-pom
http://stackoverflow.com/questions/4146638/maven-variable-for-reactor-root
http://stackoverflow.com/questions/4146638/maven-variable-for-reactor-root
http://stackoverflow.com/questions/1231561/how-to-share-common-properties-among-several-maven-projects/1265428#1265428
Re: JXR: any plans to fix some parsing related issues?
if anybody submits patches, I can review and commit Regards, Hervé Le lundi 15 avril 2013 06:03:19 davide.cavestro a écrit : Hi all, I've sketched a rough plugin https://github.com/davidecavestro/gradle-jxr-plugin to spread JXR even to gradle users. It just works, but it is limited by some parsing issues. I've filed JXR-101 https://jira.codehaus.org/browse/JXR-101 and JXR-100 https://jira.codehaus.org/browse/JXR-100 more than a month ago but I still got no response at all. Is there any roadmap for jxr? Is there any chance to get them (and other issues) fixed? I hope the project is not going to be discontinued. Cheers Davide PS: Please also let me know if I've written to the wrong mailing list. -- View this message in context: http://maven.40175.n5.nabble.com/JXR-any-plans-to-fix-some-parsing-related- issues-tp5753771.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Hi,
based on the requirement which has been made to introduce a new property
for the root of the reactor I 100% agree with Stephens argumentation.
I have taken a look into those question on SO and all of those things
can be solved in better ways than suggested on SO, cause many people
didn't understand Maven and it's concepts...sorry to say that in that
harsh way...I have to admit those concepts are not that simple...
A case in point of the improving (though not related to the idea of being
able to get a property exposing the root (never mind the which root:
reactor/inheritence/inheritence within reactor) but more related to
re-engineering to make life easier) is the templating maven pluging. In the
case of templating java source, one could do that already... just with
about 30-50 lines of pom.xml config... now with the templating plugin
you're looking at about 5-10 lines and 5 of those are just the standard
plugingroupIdartifactIdversion/plugin boilerplate.
I made often the experience that there is always a solution but often
it's not really short
My worry in providing such a property is that we enable people to hack
together something, instead of them screaming for a better way to do XYZ
and then the community providing that solution.
Yes...
People having to use ${basedir}/../.. and feeling uneasy about it... to my
mind that is the perfect balance. It's quick... it's dirty... you know it's
a hack... you know you should do better... you have the job done for now...
SPOT ON
Yeah that's a good point !
If we have an official (because that's what mojo is... the offical side
project for plugins) plugin that gives the property they want... well
people will now have the quick and dirty hack and the job done for now, but
they won't know it's a hack, they won't know they should do better... and
we have lost another user's use case to assist.
That's exactly the consequence out of it...
Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Compiler Plugin 3.1 Released
Mon, 15 Apr 2013 22:10:19 +1000, /Olivier Lamy/:
+ excludes
+exclude**/package-info.java/exclude
+ /excludes
[...]
As all package-info.java files never go to
${project.build.outputDirectory} a compilation is triggered.
This is really untrue generally and in all cases, and I can't accept
the proposed solution as serious.
--
Stanimir
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On 15 April 2013 20:42, Karl Heinz Marbaise khmarba...@gmx.de wrote: A case in point of the improving (though not related to the idea of being able to get a property exposing the root (never mind the which root: reactor/inheritence/**inheritence within reactor) but more related to re-engineering to make life easier) is the templating maven pluging. In the case of templating java source, one could do that already... just with about 30-50 lines of pom.xml config... now with the templating plugin you're looking at about 5-10 lines and 5 of those are just the standard plugingroupIdartifactId**version/plugin boilerplate. I made often the experience that there is always a solution but often it's not really short And those cases are the warning shots that the Maven community is letting its users down. Where there is a Maven Way™ solution, we should be making that solution as easy and pain free as possible. Too often we have taken easy ways out by saying things like: Use these 5 plugins in your pom and attach them to the following 5 phases like so for reasons of magic and you are following the Maven Way™ Add this pile of boilerplate and lay your folders out like so, that's the Maven Way™ The reality is that the true goal of the Maven Way™ is that your pom should be as close as possible to the following project groupId.../groupId artifactId.../artifactId version.../version packaging.../packaging dependencies ... /dependencies /project Every line you add to the above is moving further from the Maven Way™ Some additions are necessary, and don't move you more than 1mm, such as the parent reference, or adding an extension to support a custom packaging type. Some move you 1m or so, such as adding additional plugin definitions Some move you 1,000km, such as profiles Some move you 500m or so, such as adding additional plugin definitions with multiple executions with their own configuration and a default configuration When you are building a new type of project it is to be expected that you will be moved far from the Maven Way™ *because* it is a new type of project and we have not discovered the way *yet*, such explorers wander far from the Maven Way™ and then they find their way back again and tell us the paths to follow... at that point we should be stepping up and creating packaging types or well written plugins that enable people to build that type of project as close to the minimal pom as possible. The power of Maven comes from the minimal pom with just dependencies, where a project is just set out on disk according to convention and everything just works. I think we have forgotten that...
Re: configuration maven-judaa
mirror idartifactory/id mirrorOf*/mirrorOf url file:///home/diop/artifactory-2.6.7.zip /url This url is completely wrong. Point the url not to the Artifactory zip file on your disk, but to the running Artifactory instance on a server (which may be localhost or another). You have to actually install and run Artifactory to use it as a Maven mirror. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
