Re: Require site descriptor of parent POM?

[lukewpatterson]

jochen-2 wrote:
> 
> ... because the parent POM doesn't have a site and, in particular, no site
> descriptor.
> 

the parent's site.xml isn't deployed to the site repo, it's deployed to the
end-state repo alongside the primary artifact (jar,pom,etc.)

"If you want your project's site descriptor to be inherited, you need to
attach it to the project's main artifact. You use the site:attach-descriptor
goal to attach the site descriptor to your project's main artifact."
http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
, "Inheritance" section

"In Maven 2 the site descriptor is attached automatically for projects with
packaging set to "pom".
I'd check to see if the site.xml is sitting alongside the parent pom in the
repo
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Require-site-descriptor-of-parent-POM-tp3377537p3378023.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: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

[lukewpatterson]

Marc Rohlfs wrote:
> 
> ... It would e.g. be great if I could activate a profile by the 
> existence of a file whose path contains an interpolatable token (like 
> 'src/main/filters/${target.environment}/something.properties'). But I 
> understand that something like this might lead to confusing 
> interpolation behaviour which sometimes could be hard to maintain. 
> 

I think you're right to be concerned about adding extra confusion.  My guess
is that the only way something like this can have a chance is if the target
is limited to the  section of s.  i.e. nothing that
affects the "build plan?"

I'm a little worried that this discussion will quickly be gaftered if the
scope gets too scary or ambitious.

Hog wild sidenote: it would be nice if  sections could
contain portions that were dynamically generated by other plugins, why stop
at simple properties?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3364574.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: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

[lukewpatterson]

In this thread, things that seem to be in agreement so far:

* Maven 2 and 3 have different interpolation behavior, and the behavior
isn't documented in the compatibility notes
* dynamic variable interpolation doesn't affect determinism, i.e. same input
yields same output
* whether the ability furthers traditional builds or "batch processing"
builds, legitimate use-cases for dynamic interpolation have been identified
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3362278.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: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

[lukewpatterson]

Evgeny Goldin wrote:
> 
> I think this issue opens a wider one: does Maven treat properties like a
> mutable variables ...
> 

Yeah, it would be nice to have some middle ground for allowing plugins to
help configure other plugins.  Right now the "Maven Way" is to use the file
system, right?  The file system route makes if difficult if the plugin
doesn't "opt-in" to that configuration method.

A great use-case for this dynamic property stuff is seen when wrapping the
JaCoCo code coverage library in a plugin.  One of the beauties of that
library is that it pretty much stays out of the way of your testing
configuration except for needing a vm arg instrumentation entry.

When working on the Maven plugin to wrap the library, I really just want to
help the user configure the vm args, and don't want to get in the business
of launching testing frameworks.  Ideally, I would just ask the user for the
property name they want me to configure (e.g. argLine from surefire), and my
plugin would simply help set that property value.

The general argument against dynamic properties is that they make the build
configuration less declarative, right?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3361880.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: Variables interpolation: dynamic in Maven 2, static in Maven 3 ?

[lukewpatterson]

I seem to remember it always being static.  I remember trying that scenario
in Maven 2 and it always remained the same as what was present in
help:effective-pom.  i.e. if it shows up in effective-pom, your plugin can't
change it
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-tp3360336p3360344.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: Create a common/shared task for the maven-antrun-plugin ?

[lukewpatterson]

I'll try to address some of your questions/concerns/suggestions with info on
what I see as practical/supported/reasonable today.  I'll leave the bigger
philosophical and architectural ruminations to those more qualified.  (I
will say though that you might be interested in the "composition versus
inheritance" topic at:
http://www.sonatype.com/people/2009/11/maven-3x-paving-the-desire-lines-part-one-2/)


antrun isn't for creating build logic that _non-inheriting_ poms can use. 
e.g. references like ${project.artifactId} always refer to the
containing/inheriting pom, and are only relevant/resolved/evaluated when the
antrun:run goal is executed on the containing/inheriting pom.  the
antrun:run goal only executes the logic when the containing/inheriting pom
is going through _its_build_process_, not when some other pom depends
(either through  or ) on it.

the quickest way to slap together some ant and wrap a maven plugin around it
is to either use 
groovy+antdsl: http://groovy.codehaus.org/Using+Ant+from+Groovy
or
ant-based-plugin:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html


I mentioned the groovy+antdsl route because it seems easier and more
powerful to me.  You don't have to manually construct the plugin metadata
file (you have to with direct ant-based plugins) and you can use all your
java/groovy/ant knowledge and capability together in the same source file.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Create-a-common-shared-task-for-the-maven-antrun-plugin-tp3346449p3349900.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: Create a common/shared task for the maven-antrun-plugin ?

[lukewpatterson]

morty wrote:
> 
> ... I need to use this "custom" task across different projects. Do you
> suggest that I create a full separate native maven project...

If you want to share build logic across different projects, and especially
if "you code to" (via Ant task markup in your case) the custom logic, the
logic needs to have "coordinates" (groupId, artifactId, version) so you can
reference it.

Yes, the "custom plugin/task" would be a full-blown Maven project.  It would
have its own POM, its own coordinates (groupId, artifactId, version), you
would install/deploy it just like library/consumer jars.  You could make it
a Maven plugin (probably the better choice) or an Ant task.  If you make it
an Ant task, then your consumers would need to route through antrun to use
it.

>From my experience (others may have better ideas), that is really the only
way to go in a case like this.  If the custom logic "codes to you" (put
gmaven or antrun configuration in a parent pom with a bunch of conditionals
to decide what to do), then you can probably get away with not writing a
custom plugin.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Create-a-common-shared-task-for-the-maven-antrun-plugin-tp3346449p3346983.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: Create a common/shared task for the maven-antrun-plugin ?

[lukewpatterson]

if one of your modules _is_ the custom ant task (one of the modules is a
maven project that codes to ant api and contains the ant task), then you can
do this:

   
maven-antrun-plugin 

  
...
 
   
 run special task defined in another
module 
   
 
   
 
 
   
my.groupId 
my-ant-task-project 
   
 
   

the only thing I would wonder about is if the reactor inter-dependency logic
can correctly "see" that the "my-ant-task-project" needs to be built before
its consumers
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Create-a-common-shared-task-for-the-maven-antrun-plugin-tp3346449p3346860.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: Create a common/shared task for the maven-antrun-plugin ?

[lukewpatterson]

you might consider throwing it in a maven plugin (sounds scary, it isn't)

use groovy's ant dsl to slap it together
http://groovy.codehaus.org/Using+Ant+from+Groovy

i'm using that pattern now to wrap around an ant task, you can take a look
at it if you want:

http://code.google.com/p/indoorsdog/source/browse/jacoco/trunk/jacoco-maven-plugin/src/main/groovy/org/indoorsdog/jacoco/maven/plugin/internal/AgentMojo.groovy
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Create-a-common-shared-task-for-the-maven-antrun-plugin-tp3346449p3346458.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: Groovy Maven project and groovy tests

[lukewpatterson]

one thing that sticks out is that you aren't binding the gmaven goals, they
are just in in  not 
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Groovy-Maven-project-and-groovy-tests-tp3344543p3345067.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: Groovy Maven project and groovy tests

[lukewpatterson]

you might be able to glean some help from a groovy-based maven plugin I'm
working on

http://code.google.com/p/indoorsdog/source/browse/#svn%2Fjacoco%2Ftrunk%2Fjacoco-maven-plugin

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Groovy-Maven-project-and-groovy-tests-tp3344543p3344941.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

Code coverage for Invoker pre/post build Groovy scripts

[lukewpatterson]

Has anyone done this before?  Any tricks or hints?  I was hoping to use
JaCoCo, but other tool ideas are welcome.



Links:
http://maven.apache.org/plugins/maven-invoker-plugin/examples/post-build-script.html
http://jacoco.org/jacoco/index.html
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Code-coverage-for-Invoker-pre-post-build-Groovy-scripts-tp3340603p3340603.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: maven-changelog-plugin and submodule scm url

[lukewpatterson]

Stevo Slavić wrote:
> 
> ... appends submodule artifactId and not corresponding module name from
> submodule's
> aggregator modules list when constructing submodule scm ...
> 

Is it a different problem than the many-headed*
http://jira.codehaus.org/browse/MNG-3244 ?


* dive into the "issue links" section
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/maven-changelog-plugin-and-submodule-scm-url-tp3339077p3339098.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: Inline Ant tasks not working - Namespace problem?

[lukewpatterson]

I was fighting the same issue trying to get eclemma reports integrated via
antrun.  Here's a snippet dump that "works":



org.apache.maven.plugins
maven-antrun-plugin
1.6

  
test

  

  


  

  
  

  
  


  
  

  
  

  


  run

  



obviously I don't have my jacocoant.jar properly GAV'd yet, and have too may
hardcoded references, but the important part there is:

""
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Inline-Ant-tasks-not-working-Namespace-problem-tp3246437p3319602.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: Catch 22 with clean phase

[lukewpatterson]

IMHO, a "not horrible" migration path is:

1. use antrun, surely it can do everything (and more) that your batch file
does
2. later, using knowledge of how you accomplished it in ANT, port it to a
groovy-based plugin that uses ANT DSL


I've found the "groovy-based ANT DSL plugin" approach great for one-off
tasks.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Catch-22-with-clean-phase-tp3289922p3291117.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: How to set some variables in archetypes?

[lukewpatterson]

Sonja Stocker wrote:
> 
> I´ve tried it with 
> 
> ${project}
> 
> in the upper POM and using archetype.properties where this property was
> declared: project=PROJECTNAME. But it didn´t work. 
> 

Just to clarify, are you saying that "${project}" wasn't replaced with the
value of the archetype-gathered property?  Or are you fighting a problem
with folder names matching up with module names?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/How-to-set-some-variables-in-archetypes-tp3251703p3251980.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: scm connection in parent pom

[lukewpatterson]

Andreas Sewe wrote:
> 
> ... Would be interesting to know why you are so against using properties
> in 
> /project/scm/*.
> 

Based on what I've experienced, described earlier by Jörg -


Jörg Schaible wrote:
> 
> ... the release plugin will rewrite the SCM URLs during release and 
> reolve all properties with their real values - unfortunately. 
> 
(which I think is http://jira.codehaus.org/browse/MRELEASE-412), 

there is no gain in using properties since the release plugin currently just
resolves/replaces in-place anyways.  You would have to manually edit and
reinsert the property expressions in the trunk's pom after every time you
released.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/scm-connection-in-parent-pom-tp3224641p3228825.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: scm connection in parent pom

[lukewpatterson]

Andreas Sewe wrote:
> 
> But if there are any good workarounds other than 
> copy-and-pasting scm/connection in all the child POMs I would love to 
> hear about them.
> 

A lot of people (30 at last count, including myself) would be interested to
see a solution for this.  Many related bugs funnel to
http://jira.codehaus.org/browse/MNG-3244
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/scm-connection-in-parent-pom-tp3224641p3228537.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: [PLEASE TEST] Apache Maven 3.0-RC1

[lukewpatterson]

Benjamin Bentmann wrote:
> 
>> lukewpatterson wrote:
>> Before, it seems the custom goals were merged with the standard "jar"
>> packaging goals.
> 
> If you can provide a complete example project to show this merging I 
> would be really surprised. 
> 
>> lukewpatterson wrote:
>> Now, it seems like they replace the standard goals.
> 
> Which is the expected behavior, the mapping is supposed to be a full 
> self-contained description, not an overlay.
> 

Thanks Benjamin, everything is working ok.

This was an example of a sleeper-corner-case mixed with a healthy does of
ignorance.

The custom "jar" packaging type was indeed never active with Maven 2.x, I
have no idea why it existed in that plugin's metadata and I have no idea why
it was enabled in the consumer via .

The "overlay" behavior was simply other plugins running which were
explicitly bound to phases.  I forgot that the other phases exist regardless
of whether or not they are listed in the custom lifecycle mappings.

Thanks for your help.

Other than that, everything works great, and seems to be about 33% faster
overall.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/PLEASE-TEST-Apache-Maven-3-0-RC1-tp2841339p2848218.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: [PLEASE TEST] Apache Maven 3.0-RC1

[lukewpatterson]

Seeing different behavior around  enabled on "jar" custom
packaging type.

Using a testing plugin which contains "jar" as a custom packaging type. 
>From the plugin's components.xml:


  

  org.apache.maven.lifecycle.mapping.LifecycleMapping
  jar
 
org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping
  

  some.groupId:some-plugin:run-tests


Did something change/become-fixed around this scenario?

Before, it seems the custom goals were merged with the standard "jar"
packaging goals.  Now, it seems like they replace the standard goals.  I
haven't had time to investigate enough to determine if that description is
fully accurate, but that's what it seems like so far.

I noticed the behavior when the "testing plugin" said it didn't have any
tests to run.  Finally I figured out that the compile goals were never run,
which meant the the .class files were never written, which meant the testing
plugin didn't have any .class files to run.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/PLEASE-TEST-Apache-Maven-3-0-RC1-tp2841339p2847303.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: archetype-catalog.xml and its properties and goals elements, what populates them?

[lukewpatterson]

Anyone have any info/background on the  and  sections of
archetype-catalog.xml ?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/archetype-catalog-xml-and-its-properties-and-goals-elements-what-populates-them-tp2799170p2841463.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: using properties from external files in pom.xml

[lukewpatterson]

Frederic Camblor wrote:
> 
> Looks like this maven plugin could feet your needs :
> http://haroon.sis.utoronto.ca/zarar/properties-maven-plugin/index.html
> 

you can probably get what you're looking for by using that properties plugin
(making sure it runs before cargo), and then rather than adding the property
directly in the  section, use properties plugin to set the
_expression_ the parameter is mapped to

that is, assuming that the parameter is mapped to an expression

e.g. enforcer has a "skip" parameter [1], which is mapped to the expression
${enforcer.skip}, so if you don't directly configure skip in enforcer's
configuration section, but instead have the properties set the
"enforcer.skip" expression before enforcer runs, when enforcer loads you'll
see the value from the file

properties listed directly in the POM get resolved before the plugin runs,
and the plugin will get the same as seen when running help:effective-pom

i think that's how it will work, anyways

how advisable this route is?  i don't know.  will it "work"?  maybe, i think
so


[1]
http://maven.apache.org/plugins/maven-enforcer-plugin/enforce-mojo.html#skip
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/using-properties-from-external-files-in-pom-xml-tp2739646p2740121.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

Is the archetype creation documentation confusing to anyone else?

[lukewpatterson]

Which is the new way?  archetype.xml or archetype-metadata.xml ?

The "Guide to Creating Archetypes"
http://maven.apache.org/guides/mini/guide-creating-archetypes.html

says to use:
"an archetype descriptor (archetype.xml in directory:
src/main/resources/META-INF/maven/)."

but then it also says:
"Note: this mini-guide has been written for archetype plugin version 1.0.x.
Archetype plugin 2.0.x is a new generation that fully supports archetypes
created for 1.0.x, and adds a _new_archetype_descriptor_: it's more fexible,
has more features, but the basis si absolutely the same."

The "_new_archetype_descriptor_ link" takes me to
http://maven.apache.org/archetype/archetype-common/archetype.html
which says: "Maven's model for the old archetype descriptor (ie for
Archetype 1.0.x). "


I hope the new one is archetype-metadata.xml, which is documented here:
http://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-metadata.html
(which has the awkward title "How metadata on an archetype is stored?", yes
it does have a question mark)

The archetype-metadata.xml has the "packaged" option, which I'd like to use
in my archetype.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Is-the-archetype-creation-documentation-confusing-to-anyone-else-tp2739300p2739300.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: Shuttling Property Values between Maven and Ant

[lukewpatterson]

... more background info, trying to be more accurate and complete this time,
if anyone sees anything that should be clarified, please jump in ...


antrun is able to see property value changes during an  run
because of two things:

* it is manually pulling xml out of its own configuration section [1], and
resolving the expressions it each time it comes across them during ant
execution
* during the run, the properties are ant properties (initialized with
corresponding maven property values), and don't get written back to maven
properties unless you explicitly do so [2]


other plugins typically wouldn't be doing this, and instead rely on whatever
is passed in from the container, the stuff passed in from the container is
whatever is seen in help:effective-pom (things explicitly declared in
configuration sections) plus resolutions of default values (if the default
values contain expressions, they are evaluated right before the plugin runs)



[1]
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java?view=markup
(line 457 is a interesting spot)
[2]
http://maven.40175.n5.nabble.com/Exporting-Ant-properties-to-Maven-td510023.html#a510117
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Shuttling-Property-Values-between-Maven-and-Ant-tp2641670p2642018.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: Shuttling Property Values between Maven and Ant

[lukewpatterson]

AFAIK, so if you're trying to configure another plugin with those properties
(i.e. using properties in the plugin's configuration section), you can only
"see" the antrun-updated values if you don't explicitly reference the
properties in the POM, but instead rely on lazily-resolved expressions

i.e./e.g. 

if configuring invoker, and you want to set the ignoreFailures [1]
configuration element, any value you set in the pom, whether direct or
through a property, is resolved once and only once, before validate runs

OTOH, if you leave out the  configuration element, and
instead set ${maven.test.failure.ignore} (its mapped expression) with
antrun, the plugin will see the value as long as it was called after antrun

hope that makes sense, long day, rambling answer


[1]
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#ignoreFailures
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Shuttling-Property-Values-between-Maven-and-Ant-tp2641670p2641691.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: A dependency only for the dependency plugin

[lukewpatterson]

Brian Fox-3 wrote:
> 
> ... It's possible that this would work correctly in M3
> though because of the rework in the resolution.
> 

that would be nice, then the project wouldn't have to be aware of whether or
not it was a module and if the artifact was part of its enclosing
multi-module project
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/A-dependency-only-for-the-dependency-plugin-tp2261982p2265327.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: A dependency only for the dependency plugin

[lukewpatterson]

Benson Margulies wrote:
> 
> process it in the dependency plugin.
> 

what do you mean by "process"? if you mean "copy" or "unpack", m-d-p [1] has
separate goals for working with artifacts listed in the configuration
section and working with project s

e.g. see "copy" [2] vs. "copy-dependencies" [3] 

[1] http://maven.apache.org/plugins/maven-dependency-plugin/
[2] http://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html
[3]
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/A-dependency-only-for-the-dependency-plugin-tp2261982p2262028.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: Passing ${basedir} into Exec plugin

[lukewpatterson]

cowwoc wrote:
> 
> That works (using quotes) but based on what you wrote above I believe this
> is a bug.
> 
> 1. I am expecting this to work without quotes (since my path does not
> contain any spaces)
> 2. I am expecting to be able to put anything inside the quotes
> 
> Do you agree? Should I file a bug report?
> 

I think so.

http://jira.codehaus.org/browse/MEXEC

Minimally, the bug includes the fact that the "escaping" behavior isn't
documented.

Additionally, if due to the implementation of the escaping behavior, certain
strings or expressions can't be passed as arguments, then that needs to be
fixed too.

Either way, might as well file the bug so you can leave some clues to follow
for others experiencing the same obstacle.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Passing-basedir-into-Exec-plugin-tp512272p704257.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: Passing ${basedir} into Exec plugin

[lukewpatterson]

lukewpatterson wrote:
> 
> 
> cowwoc wrote:
>> 
>> ... this looks like a bug in the plugin. What do you think?
>> 
> 
> the parameters are resolved before the plugin even sees them though,
> right?
> 

ok, and then the plugin does some massaging, and '\' is an escape character

http://fisheye.codehaus.org/browse/mojo/trunk/mojo/exec-maven-plugin/src/main/java/org/codehaus/mojo/exec/AbstractExecMojo.java?r=HEAD#l155

try (with the quotes)

"${basedir}${file.separator}target${file.separator}lib"

interestingly though,

"\" or "\a" or "a\"

throw error "args contains not properly formatted string"

but "a\a" is ok

So looks like you can get by if you use the quotes, and then hope the
characters touching the quotes aren't a '\'.  I didn't test for nested
quotes.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Passing-basedir-into-Exec-plugin-tp512272p696586.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: Passing ${basedir} into Exec plugin

[lukewpatterson]

lukewpatterson wrote:
> 
> 
> cowwoc wrote:
>> 
>> ... one of the arguments equal to "${basedir}/target". 
>> 
> 
> maybe I'm missing something here, but why won't ${project.build.directory}
> work?
> 

nevermind, I see what you are saying now, you want a general way to create a
String parameter value containing proper file separators


cowwoc wrote:
> 
> ... this looks like a bug in the plugin. What do you think?
> 

the parameters are resolved before the plugin even sees them though, right?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Passing-basedir-into-Exec-plugin-tp512272p696574.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: Passing ${basedir} into Exec plugin

[lukewpatterson]

cowwoc wrote:
> 
> ... one of the arguments equal to "${basedir}/target". 
> 

maybe I'm missing something here, but why won't ${project.build.directory}
work?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Passing-basedir-into-Exec-plugin-tp512272p696566.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: standardized Maven GAV URN?

[lukewpatterson]

Stan Devitt-2 wrote:
> 
> Why would the recommended format here be different than the format used by
> the dependency plugin?
> (e.g.  junit:junit:jar:3.8.1:test )
> 

I was looking more for a URN for Maven coordinates, which is slightly
different than the flattened form of  elements.  e.g. the
 portion isn't part of what I'm looking for, it is more a statement
of how I rely upon it


Brian Fox-3 wrote:
> 
> Group:artifact:version:classifier:extension is pretty common
> 

I'm trying to wrap my mind around the differences and pros/cons of that vs.
a format listed in the Maven docs[1] 

groupId:artifactId:packaging:classifier:version

The format Brian listed seems to work better when some portions are
optional.

so maybe urn:maven:groupId:artifactId:version:classifier:extension ?

[1] http://maven.apache.org/pom.html#Maven_Coordinates
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p512112.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

standardized Maven GAV URN?

[lukewpatterson]

It would be nice to be able to represent any Maven GAV in a string.  Does
such a standard exist?

A good use case is for plugins that allow input configuration file paths. 
If there was a reusable component that took an ArtifactResolver and a
String, then any plugins that currently accept file locations as Strings
could passively add GAV capability.

e.g. with Clover plugin, I can give the path for the license file, but if I
want to store the license in the company's internal Maven repo (and thus get
the advantage of Maven versioning), I have to jump through some dependency
plugin hoops to get it in the right place at the right time.  I'd like to be
able to just give the Clover plugin a GAV URN and have it download what it
needs


-- 
View this message in context: 
http://maven.40175.n5.nabble.com/standardized-Maven-GAV-URN-tp511480p511480.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: Checkstyle Plugin doesn't recognize config file URL

[lukewpatterson]

Néstor Boscán wrote:
> 
> ... custom checkstyle
> configuration file. ... But the plugin generates:
> 
> Could not find resource 
> 


is this http://jira.codehaus.org/browse/MCHECKSTYLE-129 the problem?

remember to take into account this http://jira.codehaus.org/browse/MSITE-443
when trying to set version of that reporting plugin

-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Checkstyle-Plugin-doesn-t-recognize-config-file-URL-tp510248p510249.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: Exporting Ant properties to Maven

[lukewpatterson]

not sure how to with antrun, here's a way with gmaven/ant:

http://pastebin.com/XsAdbbcY

two commands of interest:

mvn initialize - you'll see that the property gets changed to the value
retrieved from ant

mvn help:effective-pom - if you look at the project name, just a
reinforcement that if you explicitly use the property in your pom, it gets
eagerly resolved
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Exporting-Ant-properties-to-Maven-tp510023p510117.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

I want Maven to fail

[lukewpatterson]

I'm looking for a plugin which has a "fail" goal, something like:

mvn fail-maven-plugin:fail -Dfail.maven.plugin.message="you failed!"


I've seen how enforcer or antrun can fail "on-demand", but I'm looking for
something I can fully configure from the command line


Thanks
-- 
View this message in context: 
http://old.nabble.com/I-want-Maven-to-fail-tp28706080p28706080.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: enforcer BeanShell script, retrieving escaped stuff from ExpressionEvaluator

[lukewpatterson]

lukewpatterson wrote:
> 
> evaluateBeanshell rule:
> http://maven.apache.org/plugins/maven-enforcer-plugin/rules/evaluateBeanshell.html
> 
> ... ${project.basedir} results in a String with '\' characters, which must
> be escaped in Java/BeanShell
> 

I created http://jira.codehaus.org/browse/MENFORCER-100


lukewpatterson wrote:
> 
> ... I'm trying to verify that my projects only have /pom.xml and /src/**
> on the root
> 

a cookbook hack with gmaven: http://pastebin.com/ddFZJj0e
-- 
View this message in context: 
http://old.nabble.com/enforcer-BeanShell-script%2C-retrieving-escaped-stuff-from-ExpressionEvaluator-tp28626298p28633372.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

enforcer BeanShell script, retrieving escaped stuff from ExpressionEvaluator

[lukewpatterson]

evaluateBeanshell rule:
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/evaluateBeanshell.html

want to do something like this:

directoryScanner = new org.codehaus.plexus.util.DirectoryScanner();
directoryScanner.setBasedir(new java.io.File(${project.basedir}));
...

but ${project.basedir} results in a String with '\' characters, which must
be escaped in Java/BeanShell

it doesn't look like any project objects are passed into the
bsh.Interpreter, e.g. like gmaven does when passing in "project" instance

ideas?


background: I'm trying to verify that my projects only have /pom.xml and
/src/** on the root
-- 
View this message in context: 
http://old.nabble.com/enforcer-BeanShell-script%2C-retrieving-escaped-stuff-from-ExpressionEvaluator-tp28626298p28626298.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: How to set maven property using GMaven?

[lukewpatterson]

dahoffer wrote:
> 
> I want to set the value of a maven property using GMaven, what is the
> syntax of this?
> 

I've successfully used:

project.properties.setProperty('propertyName',propertyValue)
-- 
View this message in context: 
http://old.nabble.com/How-to-set-maven-property-using-GMaven--tp28099241p28099382.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

aligning goal configuration ordering with lifecycle ordering

[lukewpatterson]

What is the likelihood that Maven will someday support multiple configuration
sections of the same plugin? ( http://jira.codehaus.org/browse/MNG-1701
helps restrict the practice )

Here's the use case: In my POM, I want to list the s in the order that
they occur in the build.  It seems like it should be possible (and would
feel natural), since Maven is all about ordering and lifecycle phases.

Or maybe there is another way to get ordering without needing multiple
configuration sections, I'm not sure.

-- 
View this message in context: 
http://old.nabble.com/aligning-goal-configuration-ordering-with-lifecycle-ordering-tp28062295p28062295.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: Deploying site to svn repo (google code)

[lukewpatterson]

justinedelson wrote:
> 
> Did you look at wagon-svn?
> 

wagon-svn would be great but it doesn't support mime-type auto-props, which
is crucial for site deployment

https://wagon-svn.dev.java.net/issues/show_bug.cgi?id=4
-- 
View this message in context: 
http://old.nabble.com/Deploying-site-to-svn-repo-%28google-code%29-tp28020109p28021955.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: How to perform ordered tasks in Maven2 build

[lukewpatterson]

rperez wrote:
> 
> ... I can accomplish each task at a time but fail to achieve them all in
> that order.
> 

It is unfortunate that one can't compose the build section of the pom to
reflect the actual order the goals will be executed.  It's not uncommon that
one goal will create the input for the next.

Maybe you could redeploy the plugins you want to use under custom GAVs so
you can reuse them in the build section.  Yes I know that's a horrible idea.
-- 
View this message in context: 
http://old.nabble.com/How-to-perform-ordered-tasks-in-Maven2-build-tp27942368p27951030.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: List of XML _attributes_ supported in the POM

[lukewpatterson]

lukewpatterson wrote:
> 
> Is there a complete list of XML _attributes_ supported in the POM?
> 

I think the following are better questions than my previous one:

Can my plugins use XML attributes as part of their configuration?  If so,
are there any special attribute names that I need to avoid?  Will I run into
any Maven 2v3 issues?
-- 
View this message in context: 
http://old.nabble.com/List-of-XML-_attributes_-supported-in-the-POM-tp27917908p27931837.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

List of XML _attributes_ supported in the POM

[lukewpatterson]

Is there a complete list of XML _attributes_ supported in the POM?

e.g. 
 [1]
 [2]

[1]
http://www.sonatype.com/people/2007/06/how-to-merge-sub-items-from-parent-pom-to-child-pom-in-a-maven-plugin-configuration-2/
[2] http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html
-- 
View this message in context: 
http://old.nabble.com/List-of-XML-_attributes_-supported-in-the-POM-tp27917908p27917908.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: [Maven embedder] How to retrieve the list of available versions of a given plugin?

[lukewpatterson]

xavier.seignard wrote:
> 
> I would like to know how to retrieve list of available versions of a given  
> plugin with the maven embedder.
> 
> In input I only have a groupId, an artifactId, a local repo and a list of  
> remote repos.
> 
> In output I would like to have a list containing all the available
> versions  
> of the given artifact from the local repo or from the remote repos.
> 

Can't tell if you're asking about programmatic access.  If so, here is some
pseudo-code that will get you close enough:


org.codehaus.groovy.maven
gmaven-plugin
1.0


find-versions
initialize

execute



projectArtifact = project.artifact
localRepository = 
session.localRepository
remoteRepositories = 
project.remoteArtifactRepositories
artifactMetadataSource =
session.lookup('org.apache.maven.artifact.metadata.ArtifactMetadataSource')
versions =
artifactMetadataSource.retrieveAvailableVersions(projectArtifact,
localRepository, remoteRepositories)
for(version in versions){
log.info(' found version: ' + 
version)
}






-- 
View this message in context: 
http://old.nabble.com/-Maven-embedder--How-to-retrieve-the-list-of-available-versions-of-a--given-plugin--tp27848494p27849878.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: API to find "effective-direct" dependencies

[lukewpatterson]

ronatartifact wrote:
> 
> How is this different from what Eclipse shows?
> Can you use their code from the Pom editor?
> 

Thanks, Ron, I'll look into that too.

My initial investigations lead me to DependencyNode:
org.apache.maven.shared.dependency.tree.DependencyNode

It needs a few other components to be instantiated:
org.apache.maven.shared.dependency.tree.DependencyTreeBuilder
org.apache.maven.project.MavenProject
org.apache.maven.artifact.repository.ArtifactRepository (local repository)
org.apache.maven.artifact.factory.ArtifactFactory
org.apache.maven.artifact.metadata.ArtifactMetadataSource
org.apache.maven.artifact.resolver.filter.ArtifactFilter
org.apache.maven.artifact.resolver.ArtifactCollector

I need to check if those remain stable between Maven 2 and 3.  If I find
some answers, I'll post back.
-- 
View this message in context: 
http://old.nabble.com/API-to-find-%22effective-direct%22-dependencies-tp27637812p27653141.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

API to find "effective-direct" dependencies

[lukewpatterson]

-- It was suggested [1] that I ask this question in a new thread, it might
have gotten lost in the noise --

I'm looking for existing API that will give me a MavenProject's
"effective-direct" dependencies, taking into account "grouped dependencies"
[2].

By "effective-direct" dependencies, I mean: all direct and all directly
listed in pom dependencies (recursively in pom dependencies, e.g. if pom
dependency has pom dependency)

I can get either direct-only [3] or all (direct and transitive) [4]
dependencies from MavenProject, but I don't see how I can get
effective-direct dependencies.

I see there is DepedencyNode [5] API, but I don't know if that will remain
stable with Maven 3 on the way.  I was hoping someone already had this part
figured out and I could just leech off their work.

Thanks


[1]
http://old.nabble.com/Some-questions-about-%22grouped-dependencies%22-tt27615566.html#a27625014
[2]
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps
[3] getDependencyArtifacts() at
http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-project/src/main/java/org/apache/maven/project/MavenProject.java
[4] getArtifacts() at
http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-project/src/main/java/org/apache/maven/project/MavenProject.java
[5]
http://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/maven/shared/dependency/tree/DependencyNode.html
-- 
View this message in context: 
http://old.nabble.com/API-to-find-%22effective-direct%22-dependencies-tp27637812p27637812.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: Some questions about "grouped dependencies"

[lukewpatterson]

Anders Hammar wrote:
> 
> Regarding the changes you propose, please file a jira for that.
> 

done: https://issues.sonatype.org/browse/MVNREF-134

Thanks for the help, Anders.

As for the second part of my original questions (question b), is there any
API that will give me a hierarchical view of the dependencies?  Should I be
using DependencyNode [1]?  I'm writing a plugin that needs to retrieve the
nearest jars.  I was hoping I could reuse some existing API that would do
all the hard work for me.  Something that will give me "effective-direct"
dependencies.



[1]
http://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/maven/shared/dependency/tree/DependencyNode.html
 
-- 
View this message in context: 
http://old.nabble.com/Some-questions-about-%22grouped-dependencies%22-tp27615566p27624313.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: Some questions about "grouped dependencies"

[lukewpatterson]

Anders Hammar wrote:
> 
> a) This is the limitation/drawback of grouped dependencies. The
> dependencies
> you get through a grouped dependencies will be a level down (actually they
> will be transient deps).
> 

The description in "grouping dependencies" should probably be changed then
from:
"You can now add this project as a dependency and all of its dependencies
will be added to your project."
to:
"You can now add this project as a dependency and all of its dependencies
will be added as transitive dependencies to your project."

On a related note, consider:

from "Maven By Example" book:
"A good rule of thumb in Maven is to always declare explicit dependencies
for classes referenced in your code." [1]
That seems to contradict "Maven: The Complete Reference" book when it places
"grouping dependencies" in the "Best Practices" section.


It seems that composition has some major drawbacks compared to inheritance.


[1]
http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html

-- 
View this message in context: 
http://old.nabble.com/Some-questions-about-%22grouped-dependencies%22-tp27615566p27623469.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

Some questions about "grouped dependencies"

[lukewpatterson]

Some questions about "grouped dependencies" [1]:

a) Should dependencies introduced through "grouped dependencies" be
considered first-order dependencies?  In the description of a grouped
dependency pom project: "You can ... add this project as a dependency and
all of its dependencies will be added to your project."  The
dependency:analyze goal doesn't seem to understand grouped dependencies. 
The "used undeclared" list can contain entries from the grouped dependency
project.

b) How can I get the "nearest" non-pom artifacts from MavenProject?  e.g.
I'd like to get the jars that this project directly depends on, and any jars
that are directly listed in the grouped dependencies


Thanks


[1]
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps
-- 
View this message in context: 
http://old.nabble.com/Some-questions-about-%22grouped-dependencies%22-tp27615566p27615566.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: unit testing archetypes

[lukewpatterson]

Sounds like there are two separate problems:

Problem 1:

Stephen Connolly-2 wrote:
> 
> however, when you create from an archetype in a directory which
> conatins a pom, the created module gets added as a new child module,
> so that the build will build the parent and the newly created child
> 

I think this should do it, it would involve separating your it projects into
with-pom and without-pom subdirectories.  Not super-elegant but it works.

for the generate goal

  with-pom/*/pom.xml
  without-pom/*


for the verify goal

 with-pom/*/pom.xml
 without-pom/pom.xml


So you would have src/it/projects/with-pom and src/it/projects/without-pom
directories

Problem 2:

Max Spring wrote:
> 
> We have a parent POM design where the multi-module POM in the parent 
> directory != parent POM.
> 

This is a capability/configurability problem with the archetype plugin, not
with the testing methods, right?

-- 
View this message in context: 
http://old.nabble.com/unit-testing-archetypes-tp27544824p27571519.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: unit testing archetypes

[lukewpatterson]

Max Spring wrote:
> 
> One missing piece: If the instantiated archetype fails to build, I want 
> the integration test to fail.
> So far a failure result is not getting propagated to the "outer" Maven 
> execution.
> 

Hmm, I didn't know archetype would ignore failures, I pasted another
solution below.


Stephen Connolly-2 wrote:
> 
> in invoker.properties you will need to specify multiple executions, eg
> invoker.goals.1=archetype:generate
> invoker.goals.2=verify
> the first one generates your project, the second builds it
> 

I think that setup will be "off by one".  It will run "verify" on the
folders that just have "test.properties" in them, not one more level deep
which contains the generated projects.

But a setup like this should work:


  org.apache.maven.plugins
  maven-invoker-plugin
  

  generate-projects
  
install
run
  
  
   
${project.build.directory}/it/projects

 
org.apache.maven.plugins:maven-archetype-plugin:generate


  *

${basedir}/src/it/projects

  ${project.artifactId}
  ${project.groupId}
  local
  ${project.version}
  false

  


  verify-projects
  
run
  
  

  verify


  */*/pom.xml

   
${project.build.directory}/it/projects
  

  
  
   
${project.build.directory}/it/repo
true
  


-- 
View this message in context: 
http://old.nabble.com/unit-testing-archetypes-tp27544824p27564451.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: generated sources/resources path conventions

[lukewpatterson]

mihobson wrote:
> 
> ... I'd probably also ditch 'src' since 'generated' conceptually replaces
> this. 
> 

Good point, updated example:

${project.build.directory}/generated//main/java
${project.build.directory}/generated//test/scala
${project.build.directory}/generated//main/resources

A question about the current standard: are generated *test* sources placed
in 
${project.build.directory}/generated-test-sources/ ?

And for *test resources*, is it
${project.build.directory}/generated-test-resources/ ?

I couldn't find any examples (haven't exhaustively search though) of
generators that produce on both main and test sides.
-- 
View this message in context: 
http://old.nabble.com/generated-sources-resources-path-conventions-tp27145545p27179217.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

generated sources/resources path conventions

[lukewpatterson]

It seems like 
  ${project.build.directory}/generated-sources/
and 
  ${project.build.directory}/generated-resources/
have been mentioned [1][2], but I wonder if something like this
  ${project.build.directory}/generated/
is more consistent.

With ${project.build.directory}/generated/, I could have
good consistency like:
${project.build.directory}/generated//src/main/java
${project.build.directory}/generated//src/test/scala
${project.build.directory}/generated//src/main/resources


[1]
http://old.nabble.com/generated-sources-convention-td14430527.html#a14430527
[2]
http://old.nabble.com/maven-antrun-plugin%3A-Java-classes-don%27t-compile-after-an-Ant-task-td24300991.html#a24301576
-- 
View this message in context: 
http://old.nabble.com/generated-sources-resources-path-conventions-tp27145545p27145545.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: xmltask-equivalant Maven plugin

[lukewpatterson]

Stephen Connolly-2 wrote:
> 
> perhaps versions-maven-plugin can help. (depends on what you want to edit)
> 

Stephen, my use-case is that I rely on some plugins which are configured
exclusively via xml files, and I want to move the
creation/documentation/source of the configuration to the pom.  In other
cases, I want to append project-specific configuration to files retrieved
from the parent pom's actions.
-- 
View this message in context: 
http://old.nabble.com/xmltask-equivalant-Maven-plugin-tp26803518p26812406.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: xmltask-equivalant Maven plugin

[lukewpatterson]

stug23 wrote:
> 
> There is a Maven XML plugin that uses XSLT to transform a document that
> you may want to have a look at:
> 
> 

Thanks Pat, I have found that plugin to be helpful in several scenarios. 
Side note, I am waiting for an enhancement of it:
http://jira.codehaus.org/browse/MOJO-1447

In the current scenario I'm working on, I'd like to directly edit xml from
the pom without needing an XSLT file.
-- 
View this message in context: 
http://old.nabble.com/xmltask-equivalant-Maven-plugin-tp26803518p26811752.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

xmltask-equivalant Maven plugin

[lukewpatterson]

Does anyone know of a Maven plugin which provides functionality similar to
the "xmltask" [1] Ant Task?

description:
"
Uses include:
* modifying configuration files for applications during builds
...
"

usage example:
---
original file, src/blah.xml:
  

  
inserting the "name"
   
 
  
which results in:
  
Tiger
  
---

If there isn't a direct Maven plugin, I'll try wrapping in a
maven-antrun-plugin call.  The only problem then is that xmltask isn't in
central.  I logged an enhancement request [2] for that issue.


Thanks,

Luke

[1] http://www.oopsconsultancy.com/software/xmltask/
[2]
http://sourceforge.net/tracker/?func=detail&aid=2914839&group_id=27398&atid=390338
-- 
View this message in context: 
http://old.nabble.com/xmltask-equivalant-Maven-plugin-tp26803518p26803518.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: Maven Plugin to detect duplicate class files in a e.g. WAR

[lukewpatterson]

Mirko Friedenhagen wrote:
> 
> goal to check classpath for duplicate resources/classes
> 

I haven't tried it yet, but recently I was looking for the same
functionality and ran across JBoss' tattletale tool:

http://www.jboss.org/tattletale http://www.jboss.org/tattletale 

"JBoss Tattletale is a tool that can help you get an overview of the project
you are working on or a product that you depend on.
 
The tool will provide you with reports that can help you
Identify dependencies between JAR files
Find missing classes from the classpath
Spot if a class/package is located in multiple JAR files
Spot if the same JAR file is located in multiple locations
With a list of what each JAR file requires and provides
Verify the SerialVersionUID of a class
Find similar JAR files that have different version numbers
Find JAR files without a version number
Find unused JAR archives
Identify sealed / signed JAR archives
Locate a class in a JAR file
Get the OSGi status of your project
Remove black listed API usage
"

-- 
View this message in context: 
http://old.nabble.com/Maven-Plugin-to-detect-duplicate-class-files-in-a-e.g.-WAR-tp26658458p26760767.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

Maven repo reverse dependency search

[lukewpatterson]

Is there a Maven repo search site that can look up consumers of
plugins/dependencies?  I would find that useful when I'm trying to use a
plugin that isn't documented that well, I could look at the existing
consumers' usage patterns.
-- 
View this message in context: 
http://www.nabble.com/Maven-repo-reverse-dependency-search-tp24924547p24924547.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: Deploying Maven site to SVN repo while applying MIME types and using pure-Java

[lukewpatterson]

If anyone else wants this functionality, I think my patch should do the job:

https://wagon-svn.dev.java.net/issues/show_bug.cgi?id=4

Please consider voting or commenting.
-- 
View this message in context: 
http://www.nabble.com/Deploying-Maven-site-to-SVN-repo-while-applying-MIME-types-and-using-pure-Java-tp24550094p24882796.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

dependency:tree in XML format

[lukewpatterson]

Is there a build plugin that can generate the dependency list/tree in XML
format?

I found this open issue
  http://jira.codehaus.org/browse/MDEP-145
but it hasn't been released yet.


Thanks,

Luke
-- 
View this message in context: 
http://www.nabble.com/dependency%3Atree-in-XML-format-tp24550574p24550574.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

Deploying Maven site to SVN repo while applying MIME types and using pure-Java

[lukewpatterson]

Ideally, I'd like to find a pure-Java Wagon that can deploy to an SVN repo
and can be configured to accept a file path for the svn:mime-type/auto-props
[1] file.  I can deploy my end-states (jars) fine, but deploying the site
has been difficult without automatic mime-type application.

So far, I found two contenders:

a) org.apache.maven.wagon:wagon-scm and
org.apache.maven.scm:maven-scm-manager-plexus and
org.apache.maven.scm:maven-scm-provider-svnexe [2]
This won't work for me because it relies on a native installation of SVN. 
Also, I couldn't figure out how to specify the location of the auto-props
file.

b) org.jvnet.wagon-svn:wagon-svn [3]
I couldn't figure out [4] how to specify the location of the auto-props
file.


This is for a Google Code project.  I'm not sure if that factor affects the
solutions available.

Any suggestions?


Thanks,

Luke


[1] http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.props.auto
[2] see usage page at
http://maven.apache.org/wagon/wagon-providers/wagon-scm/index.html
[3] https://wagon-svn.dev.java.net/
[4] https://wagon-svn.dev.java.net/issues/show_bug.cgi?id=4 and
https://wagon-svn.dev.java.net/issues/show_bug.cgi?id=5
-- 
View this message in context: 
http://www.nabble.com/Deploying-Maven-site-to-SVN-repo-while-applying-MIME-types-and-using-pure-Java-tp24550094p24550094.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: maven / osgi / repositories

[lukewpatterson]

Jason van Zyl-5 wrote:
> 
> 
> On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote:
> 
>>> repositories. They might become OBRs at some point when OSGi becomes
>>> more "mainstream".
>>
>> One thing I have been toying with for a while is to auto-magically
>> extend maven-jar-plugin to add the OSGi headers.
>>
> 
> I really don't think this is a great idea. I think for a bundle to be  
> useful someone needs to provide proper imports and exports.
> 
>> I haven't given a lot of thought into what I need to do, but if I
>> recall correctly, getting a simple OSGified jar isn't much work and if
>> Maven did this out of the box then the maven repository would become
>> OSGified over time as projects release their artifacts.
>>
> 
> We've toyed around with this idea, but if you want something useful I  
> think it's really hard to infer something useful. Making a manifest  
> that is workable with OSGi is not that hard and the author of a  
> package is probably the person to do it. I think what we can do is  
> give a brief guideline as to what's commonly expected and help people  
> create correct and useful bundles. Maven central is the biggest bundle  
> repository in waiting :-)
> 
> 

I'm sure my views aren't unique, and I'm probably rehashing what someone
else already said, but here goes:

When you see that a dependency isn't OSGi-ified, first put yourself in the
shoes of its authors, and consider the possible reasons:

* "No one has requested OSGi-ification."  This is pretty common.  The
author's don't even know that there is a demand because no one asked.  Even
if there is no time to wait on the authors and you have to custom-deploy a
wrapped-version, at least file a bug to get the ball rolling.

* "It's just a packaging concern, you can download a wrapped bundle from
www.blah.."  The Maven community has the most to lose from this approach
to OSGi-ification.  This wreaks havoc with the coordinate system.  Sometimes
the authors don't even know that others (1..*) have published wrapped
versions of their jars.  The dependency authors should be made aware that
these workarounds do not serve the Maven+OSGi community well.

* "We would add it, but how could we test it and maintain it?"  This is very
common too and I don't think there is an easy answer yet.  Much of the
testing infrastructure isn't even OSGi-ified yet.


When filing requests for OSGi-ification, it would be nice if I could direct
the dependency authors to a site/mailing-list where all their
OSGi-ification/Maven-alignment questions could be answered.  Does such a
resource exist?

I recently filed a request with Mockito, please take a look and let me know
if I should have done anything differently:
http://code.google.com/p/mockito/issues/detail?id=67
-- 
View this message in context: 
http://www.nabble.com/maven---osgi---repositories-tp21683632p22770424.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

Ecosystem Component Categories/Acronyms

[lukewpatterson]

What is a good generic term and acronym for Nexus?  Would it be "repository
manager" / "rm"
What about repo browsers (viewvc, fisheye)? 

examples:

source code management - scm
continuous integration - ci
issue management system - ims


I'm trying to set up friendly URLs and dns redirects for use in development.
e.g. http://scm.someteam.somecompany.com/svn/ points to our svn repo,
http://ci.someteam.somecompany.com/hudson/ points to our Hudson instance


Luke
-- 
View this message in context: 
http://www.nabble.com/Ecosystem-Component-Categories-Acronyms-tp21731367p21731367.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: How to get all dependecy in a mojo ?

[lukewpatterson]

Here is a snippet from something I'm currently working on.  It can see the
transitive dependencies with getArtifacts().


in the mojo:

 * @goal add-externalized-properties
 * @phase process-resources
 * @requiresDependencyResolution compile
 */
public class AddExternalizedPropertiesMojo extends AbstractMojo {
...
/**
 * @parameter expression="${project}"
 * @required
 * @readonly
 */
private MavenProject project;

--

in resulting META-INF\maven\plugin.xml:


  ...
  

  add-externalized-properties
  ...
  compile
  ...
  process-resources
-- 
View this message in context: 
http://www.nabble.com/How-to-get-all-dependecy-in-a-mojo---tp19533728p19544802.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to get all dependecy in a mojo ?

[lukewpatterson]

Is this what you are looking for?

[1]
/**
 * All dependencies that this project has, including transitive ones.
 * Contents are lazily populated, so depending on what phases have run
dependencies in some scopes won't be included.
 * eg. if only compile phase has run, dependencies with scope test won't
be included.
 *
 * @return [EMAIL PROTECTED] Set} < [EMAIL PROTECTED] Artifact} >
 * @see #getDependencyArtifacts() to get only direct dependencies
 */
public Set getArtifacts()
{
return artifacts == null ? Collections.EMPTY_SET : artifacts;
}



Also keep in keep in mind effects of @requiresDependencyResolution [2]


[1] -
http://svn.apache.org/viewvc/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?view=markup
[2] - http://maven.apache.org/developers/mojo-api-specification.html

-- 
View this message in context: 
http://www.nabble.com/How-to-get-all-dependecy-in-a-mojo---tp19533728p19534612.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem of resolving eclipse swt linux library

[lukewpatterson]

Andrew Robinson-5 wrote:
> 
> BTW, if you plan on using JFace, do not use the libraries from maven,
> use your own from eclipse. The maven pom files for the uploaded SWT
> and JFace jars are incompatible. I found it much easier to install my
> own jars into my local repo than trying to fight the versions that are
> in the central repositories.
> 

Sounds like a good recommendation.  I regret using the stuff from central
repo. [1]

Best Regards,

Luke

[1] -
http://www.nabble.com/Re%3A-Dependency-problem-for-org.eclipse.core%3Aruntime%3A3.3.100-v20070530-p19332764.html
-- 
View this message in context: 
http://www.nabble.com/Problem-of-resolving-eclipse-swt-linux-library-tp19103219p19332992.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependency problem for org.eclipse.core:runtime:3.3.100-v20070530

[lukewpatterson]

On a related note, you might want to use the
someEclipseGroupId:Bundle-SymbolicName flavor of the Eclipse dependencies.

I have been looking for "official" answers to the "official" Eclipse
coordinates question, but haven't found any.  From my understanding of a
discussion [1] on the dev list, the use of 
  someEclipseGroupId
  someEclipseArtifactId
is discouraged in favor 
  someEclipseGroupId
  Bundle-SymbolicName
So in the case of "runtime", you would use
org.eclipse.core:org.eclipse.core.runtime instead of
org.eclipse.core:runtime.

For the Eclipse stuff, there are no relocation poms deployed in the central
repo which form a relationship between the
someEclipseGroupId:someEclipseArtifactId and
someEclipseGroupId:Bundle-SymbolicName flavors.  I don't know if that is a
good thing or a bad thing.  In my projects, I chose to use the
someEclipseGroupId:someEclipseArtifactId flavor, and that might have been a
mistake.  Now I have deployed projects which contain exclusion filters for
the someEclipseGroupId:Bundle-SymbolicName flavor.



[1] -
http://www.nabble.com/What-is-the-official-Eclipse-repo-layout-(was%3A-How-to-use-central-repo-into-an-Eclipse-project-)-td17396298.html#a17396578
-- 
View this message in context: 
http://www.nabble.com/Dependency-problem-for-org.eclipse.core%3Aruntime%3A3.3.100-v20070530-tp19327179p19332764.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem of resolving eclipse swt linux library

[lukewpatterson]

These are in the repo

org.eclipse.swt.gtk.linux
x86_64
[1]

org.eclipse.swt.gtk.linux
x86
[2]

The (groupId/artifactId)s are different than what you had listed.



[1] -
http://repo1.maven.org/maven2/org/eclipse/swt/gtk/linux/x86_64/3.3.0-v3346/
[2] -
http://repo1.maven.org/maven2/org/eclipse/swt/gtk/linux/x86/3.3.0-v3346/
-- 
View this message in context: 
http://www.nabble.com/Problem-of-resolving-eclipse-swt-linux-library-tp19103219p19106859.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]