Please release maven-dependency-plugin 3.3.1

[Andreas Sewe]

Hi,

would it be possible to please release the next version of the 
maven-dependency-plugin, 3.3.1?


Besides bug-fix updates to its maven-dependency-analyzer and 
maven-dependency-tree dependencies, version 3.3.1 also introduces the 
new  configuration options which I need in a project of mine. 
(FYI, I've built and tested a 3.3.1-SNAPSHOT myself and can confirm that 
the option works as advertised. :-)


Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Users of Mercurial (Hg) SCM provider

[Andreas Sewe]

Michael Osipov wrote:
> Can you explain the benefit for you compared to Git (another DVCS)?
> I don't have any experience with Mercurial.

Speaking only for myself and not Václav and desperately hoping not to
start a Git vs. Mercurial flamewar, for me the one-and-a-half things
Mercurial does better are its safe approach to history rewriting (aka
changeset evolution [1]) and its far less confusing CLI, which still has
really powerful query capabilities [2,3].

Hope this helps.

Best wishes,

Andreas

[1] 
[2] 
[3] 



OpenPGP_signature
Description: OpenPGP digital signature

Re: Users of Mercurial (Hg) SCM provider

[Andreas Sewe]

Hi Michael,

>> I use it (with Mercurial 4.5.3), both with the maven-release-plugin and
>> for some basic operations like scm:tag in scripts (although that would
>> be easily replaceable with a direct invocation).
> 
> Any reason why you are not on 5.x? I don't even know what changes were
> introduced in 5.0 which do not properly work with Maven SCM.

no reason in particular. It's just the version that ships with Ubuntu
18.4 LTS version I am using.

But I would not expect the Maven SCM developers to test against older
Mercurial versions. Hence, just testing against 5.x is fine by me.

That being said, from a Maven SCM standpoint, I would not expect to see
any breakage with Mercurial 4.x give that Maven just forks the Mercurial
process and parses results. AFAICT, this interface is kept very stable
by the Mercurial team precisely because a lot of people use Mercurial
like that in their scripts. If Maven SCM would use, say, Jython to
access Mercurial internals directly in the JVM process, things would, of
course, be different, but you don't and should hence be quite safe.

Hope that helps.

Best wishes,

Andreas



OpenPGP_signature
Description: OpenPGP digital signature

Re: Users of Mercurial (Hg) SCM provider

[Andreas Sewe]

Hi,

> are there any Maven users who use Maven SCM Hg provider directly or
> indirectly through Maven Release Plugin?
> We are currently reviewing the vast amount of code in Maven SCM and try
> to reduce what cannot reasonable maintain.
> 
> Please raise your voice and tell us about your usecase and the Mercurial
> version you use.

I use it (with Mercurial 4.5.3), both with the maven-release-plugin and
for some basic operations like scm:tag in scripts (although that would
be easily replaceable with a direct invocation).

Best wishes,

Andreas




OpenPGP_signature
Description: OpenPGP digital signature

Re: maven-gpg-plugin SHA512

[Andreas Sewe]

Andreas Sewe wrote:
> Michael Osipov wrote:
>>> Michael Osipov wrote:
>>>> Don't waste your time. Read [1]: aether.checksums.algorithms
>>>>
>>>> [1] https://maven.apache.org/resolver/configuration.html
>>>
>>> Thank you for the pointer. Just found this post when searching for a way
>>> to create .sha256 and .sha512 files during a "mvn deploy" but can't get
>>> it to work:
>>>
>>>   mvn deploy -Daether.checksums.algorithms=SHA-512,SHA-256,SHA1,MD5
>>>
>>> The above still only created .sha1 and .md5 files in my staging
>>> repository. What am I doing wrong?
>>
>> You need to update the bundled Maven Resolver version and it will work.
>> Mark Thomas is already using it with Maven Resolver Ant Tasks to push
>> Tomcat releases.
> 
> Thanks Michael. That works like a charm.

Alas, I spoke too soon. It works on the command line, but I can't make
it an permanent part of my parent POM:

  

SHA-512,SHA-256,SHA-1,MD5
  

and

  
org.apache.maven.plugins
maven-deploy-plugin
3.0.0-M1

  
org.apache.maven.shared
maven-artifact-transfer
0.13.1
  
    
  

Can the Maven Resolver be configured by POM  at all, or are
those read too late to make their way into the RepositorySystemSession [1]?

Best wishes,

Andreas Sewe

[1]
<https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L117>



signature.asc
Description: OpenPGP digital signature

Re: maven-gpg-plugin SHA512

[Andreas Sewe]

Michael Osipov wrote:
>> Michael Osipov wrote:
>>> Don't waste your time. Read [1]: aether.checksums.algorithms
>>>
>>> [1] https://maven.apache.org/resolver/configuration.html
>>
>> Thank you for the pointer. Just found this post when searching for a way
>> to create .sha256 and .sha512 files during a "mvn deploy" but can't get
>> it to work:
>>
>>   mvn deploy -Daether.checksums.algorithms=SHA-512,SHA-256,SHA1,MD5
>>
>> The above still only created .sha1 and .md5 files in my staging
>> repository. What am I doing wrong?
> 
> You need to update the bundled Maven Resolver version and it will work.
> Mark Thomas is already using it with Maven Resolver Ant Tasks to push
> Tomcat releases.

(Replying to the Maven Users List as well, in case someone else is
searching for the answer)

Thanks Michael. That works like a charm.

Best wishes,

Andreas Sewe



signature.asc
Description: OpenPGP digital signature

Re: maven-gpg-plugin SHA512

[Andreas Sewe]

Michael Osipov wrote:
> Don't waste your time. Read [1]: aether.checksums.algorithms
> 
> [1] https://maven.apache.org/resolver/configuration.html

Thank you for the pointer. Just found this post when searching for a way
to create .sha256 and .sha512 files during a "mvn deploy" but can't get
it to work:

  mvn deploy -Daether.checksums.algorithms=SHA-512,SHA-256,SHA1,MD5

The above still only created .sha1 and .md5 files in my staging
repository. What am I doing wrong?

Best wishes,

Andreas Sewe



signature.asc
Description: OpenPGP digital signature

Re: Why does POM have precedence over -D property expressions?

[Andreas Sewe]

Andy Feldman wrote:
>> My situation is unfortunately a bit more complex than that, as I have
>> *two* s of the maven-enforcer-plugin, only one of which
>> should be affected by -DskipChecks. The other simply uses the
>>  rule, which IMHO shouldn't easily be disabled (but
>> should still respect -Denforcer.skip)
>> [...]
>> What I want is this:
>> [...]
> 
> -Denforcer.skip, being the more direct option, should
>> take precedence over -DskipChecks.
> 
> Just an idea:
> 
> 
>   false
>   ${enforcer.skip}
> 
> 
> This way if you set -DskipChecks=true, then only checks would be
> skipped, but if you set -Denforcer.skip=true, it would also cause
> skipChecks to be true, so both executions would be skipped. I haven't
> actually tested it though.

Thanks, Andy. The above does have the desired behavior *if* the
maven-enforcer-plugin were the only plugin which should be governed by
-DskipChecks.

But as I said in my initial mail, that property should also control the
maven-checkstyle-plugin, maven-tidy-plugin, and others (kine of like
-DskipTests does for maven-surefire-plugin and maven-failsafe-plugin).
And that's just not doable with

  ${enforcer.skip}

I experimented quite a bit yesterday and have become convinced that the
desired behavior is not possible, at least without profiles (ugh!) --
and even then I am not sure, as the profile would need to affect only
some executions.

But maybe I am missing something.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Why does POM have precedence over -D property expressions?

[Andreas Sewe]

Andy Feldman wrote:
> I guess you don't even need a custom property since each plugin tends to
> have one already. So a simpler property-based approach would just be:
> 
> 
>   ${skipChecks}
> 
> 
> And maybe you'd also need false in your properties
> to provide a default for when skipChecks isn't specified on the command
> line. But like I said, I haven't tried this approach so you'd have to
> experiment and see if it works for you.

Thank you, Andy, for the suggestions.

My situation is unfortunately a bit more complex than that, as I have
*two* s of the maven-enforcer-plugin, only one of which
should be affected by -DskipChecks. The other simply uses the
 rule, which IMHO shouldn't easily be disabled (but
should still respect -Denforcer.skip)

  
org.apache.maven.plugins
maven-enforcer-plugin

  
enforce-maven-version/id>

  enforce


  

  [3.6,4)

  
   
 
 
checks

  enforce


  $[skipChecks}
  

  

  

  

I can't think of a way to use  to get the desired behavior
in this case, at least not without resorting to profiles -- which I am
trying to avoid, as they seem to be frowned upon for this kind of stuff.

What I want is this:

  no property -> enforce-maven-version, checks

  -DskipChecks=false -> enforce-maven-version, checks

  -DskipChecks=true -> enforce-maven-version

  -Denforcer.skip=true -> no executions

  -Denforcer.skip=false, -DskipChecks=true -> enforce-maven-version,
checks (but possibly other checks predicated on skipChecks)

  etc.

In other words, -Denforcer.skip, being the more direct option, should
take precedence over -DskipChecks.

Any ideas?

Best wishes,

Andreas Sewe



signature.asc
Description: OpenPGP digital signature

Re: Why does POM have precedence over -D property expressions?

[Andreas Sewe]

Oliver B. Fischer wrote:
> I had the same question some days back
> (https://mail-archives.apache.org/mod_mbox/maven-users/202009.mbox/%3C922b4efc-3296-d35d-0675-d6c0090cc4b1%40swe-blog.net%3E)
> and Stuart McCulloch sent me a link to this JIRA issue:
> https://issues.apache.org/jira/browse/MNG-4979

Thanks for the pointer, Oliver. I also thought this behavior was a bug
and even tested with different Maven versions, assuming that this was a
regression.

> So, this seems to be a recurring issue that irritates a lot of people.

Yes, it is very irritating and I don't really buy Robert Scholte's
argument [1] that this is a feature rather than a bug.

Yes, it allows you to lock-in critical configuration options and make
them read-only, but to be on the safe side, you would need to do this
for *every* option of your plug-ins, which is obviously undesirable.

Also, if you break something with a manual override via the
command-line, the cause is normally crystal-clear, as you just added the
-D to the invocation; it's not something that snuck in using some
configuration file the user didn't even know about.

I hence really wish MNG-4979 would be reconsidered, maybe for Maven 4.

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Why does POM have precedence over -D property expressions?

[Andreas Sewe]

Hi,

I am currently sprinkling  child elements like the
following through my (parent) POMs for enforcer:enforce, tidy:check and
checkstyle:check :

  ${skipChecks}

This allows me to skip all kinds of checks with a simple
-DskipChecks=true (or even -DskipChecks), just like I am used to for
tests with -DskipTests.

Unfortunately, I cannot selectively override this, as the following
doesn't work:

  mvn install -DskipChecks -Denforcer.skip=false

The above command still uses the ${skipChecks} (with
skipChecks=true).

Further experimentation led me to believe that *any* explicit pom.xml
 cannot be overridden by a property expression given on
the command line.

This was very surprising, as I would have expected Maven to follow a
"command line takes precedence over configuration file" approach like
other tools -- but apparently it doesn't (at least in Maven 3.3.9 and
3.6.3) and thus violates the Principle of Least Astonishment (for one of
its users anyway).

In particular, Maven's handling of property expressions means that
having no  element and making the default explicit behave
differently; a  element like this can never be overridden
on the command-line:

  false

I wonder why it was designed that way?

Or should this be considered a bug?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Namespace-aware alternative to @Parameter PlexusConfiguration

[Andreas Sewe]

Hi,

I am writing a Maven plugin (for XQuery) whose  should
allow variables to be bound to XML fragments. Moreover, the variable
names are XML QNames (like all names in XQuery), i.e., (URI, String) pairs.

An example:

  
http://www.w3.org/2005/xquery-local-functions;
xmlns:html="http://www.w3.org/1999/xhtml/;>
  
Some element
  

  

The above should bind the  element to the QName of
("http://www.w3.org/2005/xquery-local-functions;, "fragment"), as
specified in the query's prolog:

  declare variable local:fragement as element() external;

Now the question is how to get access to the DOM below my mojo's
 parameter.

From the maven-antrun-plugin's  parameter [1], I figured out
that I can use the following:

   @Parameter
   PlexusConfiguration variables;

But this has two shortcomings:

- The element-attribute tree I get isn't aware of namespaces

- And I cannot navigate the XML to  parent in order to work
around this by looking for xmlns attributes on ancestor elements myself.

Granted, PlexusConfiguration does at least allow my to implement the
above example (albeit with manually implemented namespace handling), but
it lacks proper namespace-awareness, as I cannot do the following:

  http://www.w3.org/2005/xquery-local-functions;
 xmlns:html="http://www.w3.org/1999/xhtml/;>

Some element
  

  

Not the best example, but moving the namespace-declarations upwards has
its uses, e.g., all the way to the  element to cover multiple
 configuration elements.

So, does there exist some kind of escape-hatch like the following:

   @Parameter
   XmlDom variables;

The  element itself is in a namespace, after all, so maybe
Maven is internally namespace-aware.

Best wishes,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Injecting ${project.baseUri} as mojo parameter doesn't work

[Andreas Sewe]

Hi,

I think I have encountered a bug (with Maven 3.6.3). While
${project.baseUri} is available during for POM interpolation, it is not
injected into mojos:

Neither

>   @Parameter(defaultValue = "${project.baseUri}", readonly = true, required = 
> true)
>   private String projectBaseUri;

nor

>   @Parameter(defaultValue = "${project.baseUri}", readonly = true, required = 
> true)
>   private URI projectBaseUri;

work, which is (at least to me) surprising.

Is this expected behavior, a bug, or am I simply doing something wrong
in my @Parameter expressions?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Profile activation depending on presence of toolchains file

[Andreas Sewe]

Hi,

Maven allows the user to specify a toolchains file via its --toolchains
parameter (defaulting to ~/.m2/toolchains.xml).

While useful, this ability to override the file's location is
unfortunately a problem if one wants to make the use of the
maven-toolchains-plugin *conditional* upon the presence of said file:

  

  toolchains
  

  ${user.home}/.m2/toolchains.xml

  
  ... use maven-toolchains-plugin ...

  

The above should really check for the presence of the file given via
--toolchains; instead, it *always* checks the *default* file location.

So my question is this: Does Maven set (e.g., during toolchain
initialization [1]) a property that can be queried in a profile?

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

maven-jxr-plugin release please (to generate report without forking lifecycle)

[Andreas Sewe]

Hi,

the maven-javadoc-plugin and maven-surefire-report-plugin both have
goals/reports (javadoc-no-fork and report-only, respectively) that don't
require forking the build lifecycle. But unfortunately, a simpe

  mvn clean deploy site-deploy

still needs to do that because of the maven-jxr-plugin. which forks a
lifecycle to reach the generate-test-sources phase.

AFAICT, the current master contains equivalent goals for the
maven-jxr-plugin as well [1], but there hasn't been a release since,
with version 3.0.0 dating back to 2018.

Would it hence be possible to perform a 3.1.0 release?

Best wishes,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: Best Practice for distributing test utilities?

[Andreas Sewe]

Mark Prins wrote:
> refactor foo to a multimodule one with the test utilities as an artifact
> and one with the code + tests for original foo, you can then depend on
> the test module with scope test in the main module and keep everything
> in source repo making it easy to stay in sync

Grouping everything below an aggregator project is certainly a good
idea, but I doubt having code + tests in the same module will work. If I
understand you correctly, you describe the following module structure
below the "foo" aggregator:

- Project "foo-main" contains a class Foo.

- Project "foo-test-utils" contains a class FooTestDataBuilder, whose
code obviously refers to Foo. Hence, "foo-test-utils" needs a
compile-scoped dependency on "foo".

- Tests in project "foo-main" would like to use the FooTestDataBuilder
and have a test-scoped dependency on "foo-test-utils".

But that leaves me with a cyclic dependency:

  foo-main  --test->  foo-test-utils  --compile->  foo-main.

Or am I missing something?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Best Practice for distributing test utilities?

[Andreas Sewe]

Anders Hammar wrote:
> I'd say option 4 is the way to go. But you need to solve the circular
> dependency problem. One way is to have a third api project/module, which
> foo-test-utils have a compile time dependency on. Here you could use the
> Service Provider Interface pattern.

>> 4. Option 4 is the most natural way, but unfortunately it doesn't work,
>> because it introduces a cyclic dependency: Have "foo" and
>> "foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".

I don't think adding a SPI can be used to make option 4 work.

Simplest case:

- Project "foo" contains a class Foo.

- Project "foo-test-utils" contains a class FooTestDataBuilder, whose
code obviously refers to Foo. Hence, "foo-test-utils" needs a
compile-scoped dependency on "foo"

- Tests in project "foo" would like to use the FooTestDataBuilder.

Even I add a IFooTestDataBuilder interface, I could get the tests of
project "foo" to *compile*, but to actually *run* them, I would need a
FooTestDataBuilder -- which is defined in the *dependent* project
"foo-test-utils".

But maybe I am missing something.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Best Practice for distributing test utilities?

[Andreas Sewe]

Hi,

I am struggling to figure out what the Maven Way is for distributing
test utils.

Say I have a project "foo" along with some unit tests for it. Moreover,
I have some utilities that help in testing "foo" (e.g., test data
builders or test fixtures). These utilities are used by the unit tests
for "foo", but may also be useful to projects depending on "foo" (e.g.,
a FooTestDataBuilder that produces Foo instances could also be used in
the tests of a dependent project "bar").

The question is where to place these test utilities and how to depend on
them.

1. I could follow the "guide to using attached tests" [1], place the
test utilizes in foo/src/test/java, and attach the test-jar to "foo".
Then, a dependent project "bar" could depend on the test-jar in its test
scope. Alas, as the test scope is not transitive, I would need to
declare all test-dependencies of "foo" again in "bar", even though I may
not even use them directly (e.g., if the FooTestDataBuilder uses them
only internally).

2. I could split "foo" into three projects: "foo", "foo-test-utils", and
"foo-tests", with the latter depending on both "foo-test-utils" and
"foo-tests". A project "bar" would then simply depend on "foo" in
compile scope and "foo-test-utils" in test scope. This would make all
dependencies explicit, but would result in some oddities, e.g.,
foo-tests/src/main/java being empty, as all tests need to be placed in
tests/src/test/java to be picked up by Surefire.

3. I could split "foo" into just two projects, "foo" and "foo-testing".
foo-testing/src/main/java would the contain the test utilities for
"foo", whereas foo-testing/src/test/java would contain the actual tests.
This is again somewhat odd, as the tests in foo-testing/src/test/java
are not testing "foo-testing" but "foo".

4. Option 4 is the most natural way, but unfortunately it doesn't work,
because it introduces a cyclic dependency: Have "foo" and
"foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".

Am I missing something? In particular, why is [1] apparently the
recommended approach, even though it requires you to duplicate
dependency information?

Any suggestions are greatly appreciated.

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Writing Maven plug-in: Recommended utils for file-set scanning

[Andreas Sewe]

Hi,

I am currently writing a Maven plugin that transforms some input file
set to some output file set and want to offer all the common goodies
like , , and .

Now I am wondering which utilities to use for this purpose. As far as I
can see, for scanning I could use

- DirectoryScanner from org.codehaus.plexus:plexus-utils
- DirectoryScanner from org.apache.maven.shared:maven-shared-utils
- FileSetManager from org.apache.maven.shared:file-management
- BuildContext.newScanner(...) from plexus-build-api 0.0.7(!)

For file-name mapping, on the other hand, I have found

- FileMapper from org.codehaus.plexus:plexus-io
- FileNameMapper from org.apache.maven.shared:file-management

With so many options available, I'm of course wondering which of them
are deprecated and what the preferred way is to accomplish this fairly
standard task. In particular, I am curious whether the BuildContext
approach is still current or obsolete.

Can someone please point me in the right direction. Thanks.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Handling emails in pom.xml

[Andreas Sewe]

Hi Maxim,

> Recently I noticed the issue with site generation [1]
> 
> 
> mailto:mailaddrr

AFAIK, the  element takes just the plain e-mail address, not a
(mailto) URI:

 j...@example.com

See [1] for a longer example.

Hope that helps.

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: Java 9 modules for Maven components for Java 9 based pluggins

[Andreas Sewe]

Robert Scholte wrote:
> If you still think there's a reliable solution to let Maven use Java
> Modules, I'd like to see your solution, there are probably more people
> interested.

Let me just jump into the discussion at this point:

For all the reasons Robert mention, Maven plugins and the Core would not
only very hard to turn into modules but such a conversion would offer
little benefit.

*But* for more library-like components of Maven (e.g., maven-resolver,
maven-dependency-analyzer, animal-sniffer) providing a module descriptor
may indeed offer some benefit, as I can imagine these being used
*outside* a Maven plugin on the module path of some standalone
application. Also, due to their library-like nature, we may see less
split packages (although maven-resolver is the counter-example here).

Just my 2 cents.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Accessing licenses/license as POM properties?

[Andreas Sewe]

Mark Raynsford wrote:
> Spoke a bit too soon. I'm using the bnd-maven-plugin, but I don't think
> that changes anything. I have:
> 
> 
>   biz.aQute.bnd
>   bnd-maven-plugin
>   ${io7m.bnd-maven-plugin.version}
>   
> 
>   
> 
> 
> Unfortunately, the resulting bundle manifest is:
> 
>   Bundle-Description  Contract checking  
>   Bundle-License  ${project.licenses[0].name}  
> 
> It seems that the array reference isn't being expanded. If I specify
> ${project.licenses}, I instead get:
> 
>   Bundle-License  [org.apache.maven.model.License@3eba57a7]
> 
> ... which is clearly the result of calling toString() on something
> that hasn't overridden it. Point is that the project.licenses property
> is definitely present, it's just that I'm unable to access any of the
> elements.

That is odd. I just rebuild my project [1] again and checked
MANIFEST.MF, as included in the JAR, and everything is as it should be:

> Bundle-License: https://www.eclipse.org/legal/epl-v10.html;description
>  ="Eclipse Public License"

Maybe it depends on the Maven version (here: 3.5.2)? Try to clone the
above Github repository, do a "mvn clean verify" and check what "unzip
-p
bundles/com.ctrlflow.aer.client.dto/target/com.ctrlflow.aer.client.dto-2.0.2-SNAPSHOT.jar
META-INF/MANIFEST.MF" outputs for you.

Also, check what "mvn help:effective-pom" produces on your project vs.
my project.

Hope this helps to diagnose the issue.

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: Accessing licenses/license as POM properties?

[Andreas Sewe]

Hi,

> Is there a way to access the contents of the  element as POM
> properties? I'd like to reference the URL of the first license element
> in a plugin execution, but there doesn't appear to be a
> ${pom.license.url} or anything similar.

here's what I use as an  for the maven-bundle-plugin to
generate a Bundle-License line in my MANIFEST.MF:

> ${project.licenses[0].url};description="${project.licenses[0].name}"

Works like a charm, as long as you have exactly one license.

Hope this helps.

Andreas



signature.asc
Description: OpenPGP digital signature

maven-resolver tread-safe? Calling resolveDependencies in multiple threads

[Andreas Sewe]

Hi,

is maven-resolver (specifically resolveDependencies) thread safe? I know
that it places .lock files to avoid multiple threads trampling on each
others partial downloads, but I seem to have encountered a deadlock (or
some other phenomenon that causes it to hang).

Here's an excerpt from a stack dump I took:

> "BasicRepositoryConnector-uk.maven.org-2-1" #21 daemon prio=5 os_prio=31 
> tid=0x7f80609a6800 nid=0x5803 waiting on condition [0x00011ca65000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.lock(PartialFile.java:113)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.(PartialFile.java:69)
> at 
> org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance(PartialFile.java:278)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:438)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
> at 
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 
> "BasicRepositoryConnector-uk.maven.org-2-0" #20 daemon prio=5 os_prio=31 
> tid=0x7f805e21f800 nid=0x300b waiting on condition [0x00011c962000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.lock(PartialFile.java:113)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.(PartialFile.java:69)
> at 
> org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance(PartialFile.java:278)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:438)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
> at 
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 
> "ForkJoinPool-1-worker-0" #17 daemon prio=5 os_prio=31 tid=0x7f805ea24800 
> nid=0x5507 waiting on condition [0x0001716f3000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.lock(PartialFile.java:113)
> at 
> org.eclipse.aether.connector.basic.PartialFile$LockFile.(PartialFile.java:69)
> at 
> org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance(PartialFile.java:278)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:438)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
> at 
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:259)
> at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:498)
> at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:399)
> at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> 
> "ForkJoinPool-1-worker-3" #16 daemon prio=5 os_prio=31 tid=0x7f805ea34800 
> nid=0x500b waiting on condition [0x00011cb88000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at 
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.awaitTerminationOfAllRunnables(RunnableErrorForwarder.java:137)
> at 
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder.await(RunnableErrorForwarder.java:104)
> at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:262)
> at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:498)
> at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:399)
> at 
> 

Maven Resolver: Finding the primary artifact’s extension for a GAV

[Andreas Sewe]

Hi,

for some analyses of third-party *-tests.jar artifacts I want to build a
test classpath.

My input is an Artifact coordinate like
org.example:example:jar:tests:1.0. I can use this to download the
example-1.0-tests.jar and also to download all test-scoped dependencies
of org.example:example:1.0. Great!

Alas, the test classpath is incomplete without the primary artifact,
which may or may not have the extension "jar". So simply trying to
resolve org.example:example:jar:1.0 won't always work. I may instead
have to look for org.example:example:war:1.0 or some other coordinate.

(FWIW, there are really WARs with *-test.jar in Central [1], so this
isn't a hypothetical problem.)

Now, the question is how to get that extension with the maven-resolver?

Here's what I tried already:

- ArtifactDescriptorResult.getArtifact() simply parrots back the
extension from the request, so if I do a readArtifactDescriptor for
org.example:example:1.0, it always says "jar" (as that is the default).

- I could download the POM, but that would only give me the *packaging*,
not the extension. Also, the set of packagings is extensible, so
hard-coding a mapping may work for common cases like bundle->jar, not is
not a real solution.

Any pointers? Or is what I am after impossible, as there simply is not
enough information in the remote repository to piece this together?

Best wishes,

Andreas

[1] 



signature.asc
Description: OpenPGP digital signature

Re: maven-artifact-transfer: How to build the classpath for arbitrary GAVs?

[Andreas Sewe]

Hi Robert,

> have a look at
> https://maven.apache.org/shared/maven-artifact-transfer/comparison.html
> that should explain the difference between type/package/file-extension
> 
> If it is still not clear enough, please help imrpove the documentation.

One way to improve the documentation is to show what Packages these
types come from (the type Artifact is not exactly unique in Maven-land).

It would also help if these concepts (Dependency, Artifact,
MavenProject) could be related to their Artifact Transfer
"counterparts": ArtifactCoordinate and DependableCoordinate, which I
assume are meant as thin abstractions over the concepts from Maven core
-- although I am not sure.

> I can't explain why you only get a subset of the dependencies.
> It looks like only the compile+runtime dependencies are selected.

Yes, stepping through the actual resolver implementation I found that
the DefaultDependencyCollector gets a DependencySelector from the
current RepositorySession. And that selector excludes the "test" and
"provided" scopes.

So using my own ScopeFilter doesn't matter, as it is only used during
the "resolve" step of resolveDependencies. But the test- and provided
scoped dependencies don't make it that far; they are filtered out during
the "collect dependencies" step by the *session's* DependencySelector.

(AFAICT, there's no way to customize the RepositorySession used by
maven-artifact-transfer, right?)

> There should be no specific logic for this in maven-artifact-transfer,
> since this project is meant to be only a bridge to any Aether
> implementation.

I know have a working Aether based implementation which doesn't even
need to change the DependencySelector, thanks to an explicit
ArtifactDescriptorRequest.

Here's the gist:

  ArtifactDescriptorRequest descriptorRequest = new
  ArtifactDescriptorRequest();
  descriptorRequest.setArtifact(artifact);
  ArtifactDescriptorResult descriptorResult =
  system.readArtifactDescriptor(session, descriptorRequest);

  CollectRequest collectRequest = new CollectRequest();
  collectRequest.setRootArtifact(descriptorResult.getArtifact());
  collectRequest.setDependencies(descriptorResult.getDependencies());
  collectRequest.setManagedDependencies(
  descriptorResult.getManagedDependencies());

  DependencyFilter filter =
  DependencyFilterUtils.classpathFilter(JavaScopes.TEST);
  DependencyRequest dependencyRequest =
  new DependencyRequest(collectRequest, filter);
  system.resolveDependencies(session, dependencyRequest);

The key bit seems to be the explicit CollectRequest.setDependencies
call. If I construct the CollectRequest with a single root dependency
instead...

  CollectRequest collectRequest =
  new CollectRequest(new Dependency(artifact, "test"), repos);

...then my final list of resolved dependencies contains the artifact
itself but *not* its test-scoped dependencies. The problem seems to be
that we are "off by one level" in the dependency graph. As my root
artifact is itself already a Dependency, its test-scoped dependencies
are excluded per the normal scoping rules for *transitive* dependencies
[1]. And test-scoped transitive dependencies are never included.

Hope this makes sense.

As to what it means for maven-artifact-transfer: If you really want to
support this use case (I'm fine with limiting myself to new Maven
Resolver versions; I don't have to use the facade), then you need to
support artifact descriptor requests as well. I could then use the
four-argument version of DependencyResolver.resolveDependencies.

Best wishes,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: maven-artifact-transfer: How to build the classpath for arbitrary GAVs?

[Andreas Sewe]

Hi Robert,

thank you for the pointer.

> This should be the information you were looking for,

Alas, the information doesn't quite solve my problems -- but maybe I'm
just being obtuse.

Let's say I want to built (and resolve) the test-scoped classpath of
org.apache.maven.shared:maven-artifact-transfer:0.9.1. All I have is
this coordinate.

What I do:

  DefaultDependableCoordinate coord = new DefaultDependableCoordinate();
  coord.setGroupId("org.apache.maven.shared");
  coord.setGroupId("maven-artifact-transfer");
  coord.setVersion("0.9.1");
  dependencyResolver.resolveDependencies(
session.getProjectBuildingRequest(), coord, null);

This gives the following list of artifacts (sorted, to allow for better
comparison):

> commons-codec:commons-codec:jar:1.6
> commons-io:commons-io:jar:2.5
> org.apache.maven.shared:maven-artifact-transfer:jar:0.9.1
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1
> org.apache.maven.shared:maven-shared-utils:jar:3.1.0
> org.apache.maven:maven-aether-provider:jar:3.0
> org.apache.maven:maven-artifact:jar:3.0
> org.apache.maven:maven-core:jar:3.0
> org.apache.maven:maven-model-builder:jar:3.0
> org.apache.maven:maven-model:jar:3.0
> org.apache.maven:maven-plugin-api:jar:3.0
> org.apache.maven:maven-repository-metadata:jar:3.0
> org.apache.maven:maven-settings-builder:jar:3.0
> org.apache.maven:maven-settings:jar:3.0
> org.codehaus.plexus:plexus-classworlds:jar:2.2.3
> org.codehaus.plexus:plexus-component-annotations:jar:1.7.1
> org.codehaus.plexus:plexus-interpolation:jar:1.14
> org.codehaus.plexus:plexus-utils:jar:3.0.24
> org.slf4j:slf4j-api:jar:1.7.5
> org.sonatype.aether:aether-api:jar:1.7
> org.sonatype.aether:aether-impl:jar:1.7
> org.sonatype.aether:aether-spi:jar:1.7
> org.sonatype.aether:aether-util:jar:1.7
> org.sonatype.plexus:plexus-cipher:jar:1.4
> org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
> org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7
> org.sonatype.sisu:sisu-inject-bean:jar:1.4.2
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2

This differs quite a bit from what "mvn dependency:list" outputs when
run on a SVN checkout of the maven-artifact-transfer project:

> commons-codec:commons-codec:jar:1.6:compile
> commons-io:commons-io:jar:2.5:compile
> junit:junit:jar:4.11:test
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1:compile
> org.apache.maven.shared:maven-shared-utils:jar:3.1.0:compile
> org.apache.maven:maven-aether-provider:jar:3.0:runtime
> org.apache.maven:maven-artifact:jar:3.0:compile
> org.apache.maven:maven-core:jar:3.0:compile
> org.apache.maven:maven-model-builder:jar:3.0:compile
> org.apache.maven:maven-model:jar:3.0:compile
> org.apache.maven:maven-plugin-api:jar:3.0:compile
> org.apache.maven:maven-repository-metadata:jar:3.0:compile
> org.apache.maven:maven-settings-builder:jar:3.0:compile
> org.apache.maven:maven-settings:jar:3.0:compile
> org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
> org.codehaus.plexus:plexus-component-annotations:jar:1.7.1:compile
> org.codehaus.plexus:plexus-interpolation:jar:1.14:compile
> org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> org.eclipse.aether:aether-api:jar:0.9.0.M2:provided
> org.eclipse.aether:aether-impl:jar:0.9.0.M2:provided
> org.eclipse.aether:aether-spi:jar:0.9.0.M2:provided
> org.eclipse.aether:aether-util:jar:0.9.0.M2:compile
> org.hamcrest:hamcrest-core:jar:1.3:test
> org.slf4j:slf4j-api:jar:1.7.5:compile
> org.sonatype.aether:aether-api:jar:1.7:provided
> org.sonatype.aether:aether-impl:jar:1.7:test
> org.sonatype.aether:aether-spi:jar:1.7:test
> org.sonatype.aether:aether-util:jar:1.7:provided
> org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
> org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile

The list returned by resolveDependencies contains
maven-artifact-transfer (fine), but lacks *some* test-scoped
dependencies (like junit:junit:4.11), while others like
org.sonatype.aether:aether-impl:1.7 are included. However, a lot of
provided-scoped dependency (org.eclipse.aether) are missing, but some
are present (org.sonatype.aether).

Can you explain to me what's going on here? I feel like I am missing an
important conceptual bit.

In a similar vein, can you enlighten me what the "type" of a
DependableCoordinate is? In particular, how does it differ from the
extension or packaging?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: Maven-Indexer 6.0 Release

[Andreas Sewe]

Hi,

> I am "ressurecting" an old topic. I wonder if it is possible to have some 
> news for 6.0 release of maven indexer.
> 
> The old version of maven indexer make a plugin fail at runtime with maven 
> 3.1.1+  (see [2]). And works well with 6.0.

FWIW, I'm also quite keen on proper release of 6.0 (currently working
with a locally-built 6.0 snapshot).

Best wishes,

Andreas





signature.asc
Description: OpenPGP digital signature

maven-artifact-transfer: How to build the classpath for arbitrary GAVs?

[Andreas Sewe]

Hi,

I am currently struggling with the maven-artifact-transfer 0.9.1 API.
Here's what I am trying to accomplish: Given an arbitrary GAV and a
scope (compile or test), construct the compile- or test-scoped flat
classpath for that GAV.

DependencyResolver seems to be the class I am after, but I haven't found
 out whether to use the Dependency-based or DependableCoordinate-based
overload of resolveDependencies (the Model-based overload won't work, as
I have just a GAV and no Model for it). Also, I haven't figured out how
to specify the scope I am after (dependency:build-classpath doesn't use
maven-artifact-transfer but rather get its information out of the
current project's Model).

And pointers are greatly appreciated.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: How to get a Wagon TransferListener wrapping the default Aether TransferListener

[Andreas Sewe]

Hi Robert,

> Sounds like something which has to be added to maven-artifact-transfer[1]

I created MSHARED-662 [2] to track this feature request.

I've also since I asked about this written my own adapter, which I would
be willing to share. Let's discuss this in JIRA.

Best wishes,

Andreas

> [1] https://maven.apache.org/shared/maven-artifact-transfer/

[2] 



signature.asc
Description: OpenPGP digital signature

How to get a Wagon TransferListener wrapping the default Aether TransferListener

[Andreas Sewe]

Hi,

I am writing a Maven plugin that needs a *Wagon* TransferListener
(org.apache.maven.wagon.events.TransferListener). To ensure a consistent
user experience, this Wagon TransferListener should behave exactly like
the (org.eclipse|org.sonatype).aether.transfer.TransferListener which
Maven presumably uses for its other downloads.

The question is thus how to obtain such an instance?

I wasn't able to simply get a Wagon TransferListener injected
(@Component). And while I can get an Aether RepositorySystemSession with
its associated Aether TransferListener injected, I couldn't find a
*public* Aether->Wagon adapter (the one in
maven-resolver-transport-wagon is not public API). And writing this
adapter myself feels kind of silly, as I am pretty sure this kind of
compatibility layer already exists somewhere.

Can you please help me figure out where?

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Maven Archiver: Suppress Built-By header

[Andreas Sewe]

Hi,

in order to increase build reproduciblity, I am looking for a way to
suppress the Built-By manifest header the Maven Archiver automatically
generates. Unfortunately, I couldn't find a  configuration
option to do this. The following didn't work either (it generated an
empty Built-By header instead):

 
   
 
   
 

Does anyone know whether suppressing these headers is possible *without*
resorting to  and doing everything by hand.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Andreas Sewe]

Stephen Connolly wrote:
> Can you create an issue against the MNG project in the issue tracker and we
> will consider it from there

I'll leave that to Justin, as he has the need for this feature and can
probably describe his requirements best:

  

I just pointed out that Eclipse Tycho already does something similar "on
top of" Maven's setting.xml for repository mirrors. Would be great if
the two mechanisms would be similar syntactically as well.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] [ANN] Apache Maven Version 3.5.0-alpha-1 Released

[Andreas Sewe]

Hi,

> Any chance the Aether work would somehow enable declaring server credentials 
> only once in settings.xml and then reusing them for multiple 
> build.repositories.repository nodes in pom.xml (such as when you have 
> multiple independent repositories within the same authentication realm of a 
> single host)? 

FYI, Eclipse Tycho has recently (version 1.0.0) introduced a similar
feature for sharing mirror settings for multiple repositories [1]. As
the above feature request is similar (sharing settings for multiple
repositories), the configuration syntax chosen by the Tycho developers
(treating a URI repository/id specially) may serve as inspiration.

Hope this helps,

Andreas

[1]




signature.asc
Description: OpenPGP digital signature

Re: Clarification needed: is inherited?

[Andreas Sewe]

Hi Robert,

> prerequisites are never inherited, see
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/merge/MavenModelMerger.java#L190

thank you (and other on this thread).

FYI, I filed a bug [1] with the versions-maven-plugin to reword their
log message so that it no longer suggests that  are
inherited.

Best wishes,

Andreas

[1] 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Accessing child of using property syntax?

[Andreas Sewe]

Sebastian Hoß wrote:
> ${project.licenses[0].url} should do the trick

Thanks, Sebastian. Works like a charm.

Now I can generate even nicer OSGi Bundle-License headers than with the
maven-bundle-plugin's defaults:

> ${project.licenses[0].url};description="${project.licenses[0].name}"

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Accessing child of using property syntax?

[Andreas Sewe]

Hi,

I vaguely recall having read the answer to this one years ago, but
googling and searching through the Apache JIRA didn't turn it up again. :-(

Is it possible to access a single child element of  POM
element using ${} property syntax? I tried

  ${project.licenses.1.url}
  ${project.licenses.1.license.url}
  ${project.licenses.license.1.url}
  ${project.licenses.0.url}
  ${project.licenses.0.license.url}
  ${project.licenses.license.0.url}

but to no avail.

Any pointers are greatly appreciated.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Andreas Sewe]

Hi,

> If you like to help making the next Maven release better it would be
> nice if you could help a little bit.
> 
> Please be aware of this *** This is not an official release ***
> 
> Every kind of feedback is helpful.

the good needs is that I found no regressions (testing several large
builds at eclipse.org using Maven + Tycho).

The bad news is that the child.inherit.append.path attribute introduced
with MNG-5951 is not flexible enough for fairy common use cases like
projects on Github. I opened bug MNG-6059 [1] for this.

Hope that helps.

Andreas

[1] 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Clarification needed: is inherited?

[Andreas Sewe]

Hi,

I am confused by the following message of dependency:display-plugin-updates

> [INFO] Project inherits minimum Maven version as: 3.0

and this statement from the  enforcer rule [1]:

> This rule enforces that the prerequisite is specified since it is not 
> inherited from its parent. 

Am I missing something or is one of statements incorrect? If so, which one?

Best wishes,

Andreas

[1]


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Javadocs generated by maven-javadoc-plugin does not include method parameter names for Eclipse

[Andreas Sewe]

Derek Hongar wrote:
> I'm using Eclipse and I would like to attach a library's javadocs to my
> project so that when I implement an interface and choose the option *Add
> unimplemented methods* the *methods parameter names* show up correctly
> instead of *arg0*, *arg1*, etc.

AFAIK, this has nothing to do with what's in the attached Javadoc, but
whether the interface is known to Eclipse in its source form or in its
bytecode form and, if the latter, whether the bytecode contains the
lcoal-variable debug info.

> Problem is:
> 
>-
> 
>When I generate the javadocs through eclipse (Project > Generate
>Javadocs...) and link it to my project *it works*, in other words, I see
>the correct method parameter names.
>-
> 
>When I generate the javadocs through maven-javadoc-plugin and link it to
>my project *it does not work*, in other words, I see *arg0*, *arg1*, etc.

To clarify: The *HTML* produced by Eclipse contains the method names,
but the HTML produced by m-javadoc-p does not?

If so, then this may be an issue with the Maven plugin, but the above
behavior during "Add unimplemented methods" is *not* a symptom of this,
but an unrelated issue.

Hope this helps,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: access to license node

[Andreas Sewe]

Hi,

 Have a look at http://jira.codehaus.org/browse/PLXUTILS-37. While it
 is marked as fixed, apparently things like
 ${project.licenses.0.license.name} did not (and still do not; I just
 checked) work. :-(
 
 The following works for me:
 
 ${project.licenses[0].name}

Yes, I spoke too soon. ${project.licenses[0].name} works! :-)

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: access to license node

[Andreas Sewe]

Hello,

 I’m using Maven 3.2 with the pom definition
 
 project xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xmlns=http://maven.apache.org/POM/4.0.0;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
 modelVersion4.0.0/modelVersion
 
 
 I have added this items to my pom
 
 licenses
 license
 nameGNU General Public License 3/name
 urlhttp://www.gnu.org/licenses/gpl-3.0.en.html/url
 /license
 /licenses
 
 and I would like to reference to the items with
 
 ${project.licenses.license.url}
 ${project.licenses.license.name}
 
 but these lines does not work - empty result, so I would like to reread the 
 items of my license node, how can I do this?

Have a look at http://jira.codehaus.org/browse/PLXUTILS-37. While it
is marked as fixed, apparently things like
${project.licenses.0.license.name} did not (and still do not; I just
checked) work. :-(

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

How to activate a profile when -offline?

[Andreas Sewe]

Hi,

sometimes it's useful to configure a Maven plugin depending on whether
the build runs in online or offline mode (-offline command-line option).
Now, using

  mvn help:effective-settings -offline

shows that ${settings.offline} == true. Alas, I cannot get the following
profile to activate:

 profile
   idoffline/id
   activation
 property
   namesettings.offline/name
   valuetrue/value
 /property
   /activation
 /profiles

Is this by design, i.e., is ${settings.offline} different from, say, a
property ${my.offline} that I activate with -D? Or is this a bug?

Last but not least, does there exist a different way to achieve the same
thing, i.e., activate a profile when -offline?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to activate a profile when -offline?

[Andreas Sewe]

Hi Curtis,

many thanks for your detailed reply.

You wrote:
 Is this by design, i.e., is ${settings.offline} different from,
 say, a property ${my.offline} that I activate with -D?
 
 For better or for worse, Maven profiles cannot be activated based on Maven
 properties, only based on Java system properties and/or environment
 variables. That is, anything you pass in via -Dfoo.bar can be used for
 activation, but all those properties you put in the properties section of
 your POM, or in settings.xml, cannot trigger profiles. The Maven offline
 property is one of the latter, not the former.

Yes, but settings.offline is arguably different from things in a
properties section because it is, as you point out below, a top-level
element in settings.xml (/settings/offline rather than
/settings/properties/offline). As such, it at least seems plausible that
settings.* properties act the same as env.* properties.

 does there exist a different way to achieve the same thing,
 i.e., activate a profile when -offline?
 
 After 30+ minutes of thinking about this and trying things and grepping
 Maven source code, I do not think what you want to do is obviously possible.
 
 Pragmatically, I thought maybe you could enable offline mode using a
 profile in your settings.xml activated on an environment variable, but you
 cannot toggle the offline setting in such a profile, because offline is a
 toplevel element (i.e., not declared beneath properties).

Maybe I phrased my original question not clearly enough: I don't want to
*enable* offline mode. I simply want to configure some plugin (the
maven-jarsigner-plugin's tsa configuration option, to be precise) iff
I am running Maven with -offline. The problem is that, with a Time
Stamping Authority URL configured, the m-jarsigner-p tries to connect to
the TSA, even if -offline, which cannot succeed and causes the build to
fail.

Now, one might argue that the m-jarsigner-p needs to become smarter and
aware of Maven's offline mode, but that would require it to deal with
special cases, like localhost URLs being reachable even in offline mode,
etc. IMHO, it is thus far simpler to just be able to configure an
offline profile that adapts your plugin configurations if -offline is
used.

 The greater design issue is that Maven needs to know whether it is offline
 mode before it starts doing things like resolving parent POMs. But that
 resolution is necessary in order to fully interpolate the POM and hence
 know which profiles are activated.

I get that. But being able to activate a profile on ${settings.offline}
doesn't preclude that as, AFAIK, that magic property can only be set
before Maven starts doing things like resolving parent POMs, i.e., on
the command line or in the settings.xml itself.

Do you agree? If so, do you think this might be worth an enhancement
request? (I think the m-jarsigner-p use case is pretty compelling, but
then again that's the problem I am facing at work right now, so I may be
a bit biased. ;-)

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Activating a profile iff toolchains are configured?

[Andreas Sewe]

Hi,

I wonder whether these is a portable way of activating a profile iff
toolchains are properly configured, i.e., if either ~/.m2/toolchains.xml
is present or, if -t is used, the file specified thereby.

I would like to use toolchains (execute toolchain:toolchain and set the
tycho-compiler-plugin:compile's useJDK parameter accordingly) if the
user has configured them but fall back to not-using toolchains if not.
IMHO, *requiring* everyone setting up toolchains is to big a burden, but
if someone has done so the build should automatically take advantage of it.

The problem seems to be finding out whether -t was use and, if so, to
what file it points. Any ideas?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Breadcrumb inheritance in site.xml

[Andreas Sewe]

Hi,

 that wasn't possible during my time of activity, not sure if anything
 changed since:
 http://mail-archives.apache.org/mod_mbox/maven-users/201104.mbox/%3c4da464c8.2060...@apache.org%3E

yes, https://jira.codehaus.org/browse/MSITE-582 got fixed and I have
used the fix successfully in one of my projects.

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: opinion on obfuscator plugin default execution phase?

[Andreas Sewe]

Hi Richard,

 I can see it both ways... If it runs at
 the packaging phase, it'll start (by default) by processing the packaged
 artifact created by the default packaging and either overwriting the
 artifact or creating a new one with a classifier (e.g. artifact-small).
 If it runs at the pre-packaging phase, I'd have it start processing on the
 output folder from the compile phase.

without taking a stance on which of the two options is better/more
Maven-like, I would also add an option 3: obfuscate the class files in
the process-classes phase [1]. That way the unit tests run against the
obfuscated classes, which may expose problems due to the obfuscation
that would otherwise go unnoticed.

Hope that helps.

Andreas

[1]
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Using scope in dependencyManagement: good idea or bad?

[Andreas Sewe]

Hi all,

the subject say it all: Is declaring scopes in the dependencyManagement
section of your parent POM a good idea or a bad idea?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Using scope in dependencyManagement: good idea or bad?

[Andreas Sewe]

Joachim Van der Auwera wrote:
 In my experience a bad idea (bitten by this in the past). If the same
 dependency is mentioned in dependencyManagement in various places, then
 you may end up with the wrong scope.
 
 I use dependencyManagement to specify the version and possibly
 exclusions. Scope is still managed in the dependency declaration itself.

Makes sense. I was basically wondering if everyone considers this to
*always* be a bad idea or whether there are exceptions (like a
provided-scoped servlet-api, where a different scope might evne be
considered a bug).

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-fluido-skin: How to explicitly set language for syntax highlighting?

[Andreas Sewe]

Hi,

just a quick question that neither the maven-fluido-skin's website nor
Google could answer:

How to set the language (lang-tex in my case) on a XDoc source element
in such a way that it ends up in the correct @class attribute in the
generated HTML for Google Code Prettify to pick up?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Odd failure with maven-checkstyle-plugin in pluginManagement

[Andreas Sewe]

Hi,

I have encountered a very odd failure when adding the
maven-checkstyle-plugin to my pluginManagement section. Below is the
simplest POM that triggers this error (both under Maven 3.0.3 and
3.0.4-RC3):

 project ...
   modelVersion4.0.0/modelVersion
   groupIdorg.example/groupId
   artifactIdexample/artifactId
   version0.0.1-SNAPSHOT/version
   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-ckeckstyle-plugin/artifactId
   version2.8/version
 /plugin
 /pluginManagement
   /build
 /project

A mvn clean install runs just fine, but as soon as someone actually
tries to do something with the pluginManagement entry (a mvn
help:effective-pom already triggers this), I get the following warning.

 [WARNING] The POM for 
 org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 is missing, no 
 dependency information available
 [WARNING] Failed to retrieve plugin descriptor for 
 org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8: Plugin 
 org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8 or one of its 
 dependencies could not be resolved: Failed to read artifact descriptor for 
 org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8

Note the packaging of jar in the above. AFAIK, it should be
maven-plugin instead.

At any rate, the above is really an error rather than a mere warning.
Any attempt to actually use the maven-checkstyle-plugin in build/plugins
uses the plugin's default configuration rather than any configuration
configured build/pluginManagement/plugins.

I strongly suspect this is a bug. Can someone please point me to the
right issue tracker for this? (I don't think it's the plugin's fault.)

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Odd failure with maven-checkstyle-plugin in pluginManagement

[Andreas Sewe]

Stephen Connolly wrote:
 Are you sure you know how to spell checkstyle?

oops, my bad. :-( I thought I had copy-and-pasted the coordinates from
search.maven.org throughout my POMs. Apparently, I missed one
occurrence. Sorry.

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[maven-failsafe-plugin] Augmenting the fork configuration?

[Andreas Sewe]

Hi all,

and sorry for the long post; what I want to acieve is a bit complex:

I am currently integration-testing a tool that allows one to perform a
variety of bytecode instrumentation tasks (for profiling/JVM research).
Said tool consists of two components: a server running in a separate JVM
instance that does the actual instrumentation and a client that
intercepts classloading on the target JVM, sends the classes to the
server to be instrumented, and then inserts the instrumented classes
into the target JVMs class-loading process again.

Currently, I envision testing a particular instrumentation like this:

 pre-integration-test:
   Use a Maven goal similar to jetty:start to start the server process.
   (Writing such a plugin is relatively straight-forward :-)

 integration-test:
   Use the maven-failsafe-plugin to execute the integration test under
   the client's regime, i.e., with instrumentation being build
   activated.

 post-integration-test:
   Use a Maven goal similar to jetty:stop to stop the server process.
   (Again, this is straight-forward.)

The tricky part is the integration-test phase. Ideally, I would like to
re-use the maven-failsafe-plugin here, but in order to make the target
JVM communicate with the instrumentation server I need to pass a whole
bunch of arcane options to the (forked) JVM (-javaagent, -agentpath,
-Xbootclasspath/p, not to mention the paths to the various JARs). What I
would thus like to do is hide these details the the user. (Just like
start/stop goals hide the details of starting/stopping the server.)

Can the Surefire Provider API be used for something like this, e.g., by
extending the existing JUnit-Provider and modifying the ForkConfiguration?

Any pointers are greatly appreciated. The documentation at
http://maven.apache.org/plugins/maven-failsafe-plugin/api.html is
sadly rather brief.

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Difference between build/extensions/extension and build/plugins/plugin/extensions?

[Andreas Sewe]

Hi Vincent,

 As far as I understand, specifying build/plugins/plugin/**extensions set to
 true allows plugins embedding a components.xml to actually declare these
 components as part of the context. In such case you don't need to repeat the
 plugin declaration in the build/extensions/extension section.
 
 The build/extensions/extension is rather used to include jars (non-plugin)
 that declares additional components. In the example you gave, the plugin and
 the artifact declared in build/extensions/extension don't have the same
 coordinates, so they have likely different purposes.

yes, this explains it quite nicely. Thank you!

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-deploy-plugin: package vs deploy phase

[Andreas Sewe]

Hi Greg,

Greg Sandell wrote:
 I have a call to maven-deploy-plugin bound to package phase that works
 correctly when I call maven clean package but if I call maven clean
 deploy I get:
 
 java.lang.IllegalStateException: Cannot add two different pieces of
 metadata for: project com.thomsonreuters.images:icon-Remove
 
 (We are using maven-deploy-plugin to push an image file,
 icon-Remove-1.0.gif, to our maven repo server, Artifactory.)
 
 I'm just wondering if anybody can explain what Maven is tripping over.  

not sure about that.

But you may want to look at the build-helper:attach-artifact goal
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
to push your image. This might be closer to the Maven Way of doing things.

Hope this helps.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Difference between build/extensions/extension and build/plugins/plugin/extensions?

[Andreas Sewe]

Hi all,

what is the difference between build/extensions/extension and 
build/plugins/plugin/extensions set to true. It seems somewhat redundant 
(yes, I could use a property) to have to specify the plugin's version 
twice, as in this snippet from the maven-archetype-plugin's site:



project
  ...
  packagingmaven-archetype/packaging
  ...
  build
extensions
  extension
groupIdorg.apache.maven.archetype/groupId
artifactIdarchetype-packaging/artifactId
version2.1/version
  /extension
/extensions

pluginManagement
  plugins
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-archetype-plugin/artifactId
  version2.1/version
/plugin
  /plugins
/pluginManagement
  /build
/project


And on a similar note: Are extensions plugin-managed or do I really 
have to repeat the version twice in the above? The output of 
help:effective-pom seems to suggest that extensions are not managed: if 
I leave out build/extensions/extension/version in the above, the 
effective POM also lacks the version element.


I hope that somebody can enlighten me.

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Documentation for Maven3

[Andreas Sewe]

Hi Sascha,


Now I specifically need to create a few new packaging types and I didn't
find good resources on how to do that with Maven3 (I read somewhere that
one can now use Java annotations instead of Javadoc ones). I currently
have a first prototype using the Javadoc annotations and a
copied/modified version of a plexus/components.xml which should resemble
the JAR plugin instead of the packaging phase. Maybe I'm missing
something, I hoped that there would be a more unintrusive way to hook
oneself in the build-lifecycle. I for example didn't find any
components.xml for the maven-jar-plugin (or I'm looking at the wrong
places...).


Not entirely sure what you are looking for (should resemble the JAR 
plugin instead of the packaging phase). But maybe the following 
plexus/components.xml is useful to you: 
https://bitbucket.org/scalabench/dacapo-benchmark-maven-plugin/src/3bcdb24c0c95/src/main/resources/META-INF/plexus/components.xml


It is part of a Maven plugin I wrote to assemble so-called DaCapo 
benchmarks (used by JVM researchers for experiments), which are 
basically pimped JARs. It's just a couple of extra goals bound to 
various lifecycle phases: 
http://www.plugins.scalabench.org/modules/dacapo-benchmark-maven-plugin/lifecycle.html.


That being said, if you don't use the dacapo-benchmark packaging defined 
in plexus/components.xml, you can still bind the plugin's goals manually 
to lifecycle phases (that's when the @phase annotation takes effect if 
present).



Any pointer would be really appreciated (even pointers to source code, I
already looked into maven-jar, maven-ear and maven-war but they are all
using the old? Javadoc annotations


AFAIK, Java-5-style annotations are not there yet.

Hope this helps.

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Pretty-printing/compressing HTML in post-site phase

[Andreas Sewe]

Kathryn Huxtable wrote:

My purpose in writing htmlfilter-site-maven-plugin was to better incorporate 
docbkx-tools output into Doxia-generated output.


Yes, that seems to be the rationale for the maven-tidy-plugin 
http://docbook-utils.sourceforge.net/maven-tidy-plugin_1.0/ as well, 
although this plugin seems to allow one to configure JTidy. 
Unfortunately, it is not available in central. :-(


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Pretty-printing/compressing HTML in post-site phase

[Andreas Sewe]

Hi all,

are there any plugins that can be used to prettify or compress the 
output of Doxia/the maven-site-plugin in the post-site phase? I found 
Kathryn Huxtable's htmlfilter-site-maven-plugin, but that only seems to 
be able fix (tidy) malformed HTML.


I remember reading somewhere that Doxia itself deliberatly ignores the 
issue of pretty-printing; instead, it defers this to other plugins. 
Alas, I wasn't able to find such a plugin. Any pointers?


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Nested artifacts

[Andreas Sewe]

Hi,


So the first part of the problem is the zip contains multiple rar files, but 
only one needs to be unpacked and tinkered with.


the maven-external-dependency-plugin might fit the bill: 
http://code.google.com/p/maven-external-dependency-plugin/. If the RAR 
file is not found in the local repository, the plugin tries to download 
the ZIP file, extracts the RAR, and installs it in your local 
repository. You would then bind dependency:unpack to a later phase, 
referring to the RAR artifact just installed. (I use this plugin in a 
similar way, with dependency:copy: 
https://bitbucket.org/scalabench/scalac-dacapo-benchmark/src/4dac488d735c/pom.xml#cl-246.)


The only issue 
http://code.google.com/p/maven-external-dependency-plugin/issues/detail?id=8 
I have found so far with the maven-external-dependency-plugin is that it 
doesn't work well with Maven 3 if the artifacts you want to extract 
(RARs in your case) are among the project dependencies. Unlike Maven 2, 
Maven 3 seems to resolve all project dependencies first, before any 
lifecycle phases are executed; thus, the 
maven-external-dependency-plugin doesn't get a chance of installing the 
missing dependencies first. This is not a problem when using 
dependency:copy or dependency:unpack, however.


I hope this helps.

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to use wagon-ssh-external instead of wagon-ssh?

[Andreas Sewe]

Hi Brett,


I think in the Maven 3 version of the site plugin, you need to add
the wagon as a dependency of the site plugin, instead of as an
extension (which only applies to the core deployment components).


thanks for your suggestion. I am afraid, it didn't help: When declaring 
a plugin dependency, the maven-site-plugin now has both 
org.apache.maven.wagon:wagon-ssh-external:jar:1.0-beta-7 and 
org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-6 as a dependency, but it 
still insists on using the latter for sftp URIs. :-(


Any other suggestions?

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to use wagon-ssh-external instead of wagon-ssh?

[Andreas Sewe]

Hi Wendy,


thanks for your suggestion. I am afraid, it didn't help: When declaring a
plugin dependency, the maven-site-plugin now has both
org.apache.maven.wagon:wagon-ssh-external:jar:1.0-beta-7 and
org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-6 as a dependency, but it
still insists on using the latter for sftp URIs. :-(


Perhaps you need to exclude the one you don't want?  Maven doesn't
recognize one as a replacement for the other, it just sees two
separate artifacts.


good point. Unfortunately, I don't see a way to do that. It looks like I 
can only use exclusions to exclude *transitive* dependencies of a 
plugin. At least the following plugin dependencies clause doesn't work:


  dependencies
dependency
  exclusions
exclusion
  groupIdorg.apache.maven.wagon/groupId
  artifactIdwagon-ssh/artifactId
/exclusion
  /exclusions
/dependency
  /dependencies

org.apache.maven.project.ProjectBuildingException: Some problems were 
encountered while processing the POMs:
[ERROR] 
'build.plugins.plugin[org.apache.maven.plugins:maven-site-plugin].dependencies.dependency.artifactId' 
for null:null:jar is missing. @ line 151, column 27
[ERROR] 
'build.plugins.plugin[org.apache.maven.plugins:maven-site-plugin].dependencies.dependency.groupId' 
for null:null:jar is missing. @ line 151, column 27
[ERROR] 
'build.plugins.plugin[org.apache.maven.plugins:maven-site-plugin].dependencies.dependency.version' 
for null:null:jar is missing. @ line 151, column 27


I am afraid this is an incarantion of 
http://jira.codehaus.org/browse/MNG-2163. :-( Or am I mistaken?


Best wishes,

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to use wagon-ssh-external instead of wagon-ssh?

[Andreas Sewe]

Hi Wayne,


Well, there's always the Version 99 does not exist option...


that's something I couldn't get past Maven 3. Also tried 
optionaltrue/optional and a system-scoped dependency with an invalid 
systemPath, but to no avail.



Could you maybe set a dependency to that jar, and set the scope to
runtime? Don't know if that will help though.


No, it didn't. :-(

Thanks for the suggestions, though.

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

How to use wagon-ssh-external instead of wagon-ssh?

[Andreas Sewe]

Hi,

I am facing some problems deploying my project's site using sftp. For
testing purposes I thus want to switch wagons, namely from
org.apache.maven.wagon:wagon-ssh:1.0-beta-7 to
org.apache.maven.wagon:wagon-ssh-external:1.0-beta-7. However, even
adding the appropriate extension to my POM doesn't convince the
maven-site-plugin:3.0-beta-4-SNAPSHOT to pick a different wagon for the
sftp URI scheme.

 extension
   groupIdorg.apache.maven.wagon/groupId
   artifactIdwagon-ssh-external/artifactId
   version1.0-beta-6/version
 /extension

At least, I still get the same exception, which clearly says that I am
using the JSch-based Wagon and not an external ssh process:

Caused by: 3: Permission denied
at
com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2291)
at com.jcraft.jsch.ChannelSftp.mkdir(ChannelSftp.java:1701)
at
org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdir(SftpWagon.java:204)
at
org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.mkdirs(SftpWagon.java:184)
at
org.apache.maven.wagon.providers.ssh.jsch.SftpWagon.putDirectory(SftpWagon.java:271)
... 25 more
[ERROR]

Any suggestions? How does the maven-site-plugin map URI schemes to wagons?

Also, is there any configuration option / system property to make the
wagon more chatty? Just running mvn site-deploy -X doesn't produce
enough information to track down what's actually going over the wire. :-(

Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: aggregator module includes its own parent as a sub-module

[Andreas Sewe]

Hi Oleg:

Simple tests show that maven will accept such a project without any 
errors or even warnings, but I would like to know whether this kind of 
circular parent-aggregator dependency is bad.

Any opinions why this should not be done?


Not when it comes to the build itself, not. When it comes to site 
generation, however, expect inconsistencies between the modules menu 
and the breadcrumbs. The former will show the parent as a module of the 
aggregator while the latter will show a trail like parent  aggregator. 
While technically correct (from a Maven point of view), this is probably 
something your site's users won't expect. (I have raised an issue about 
this: http://jira.codehaus.org/browse/MSITE-582.)


Just something to keep in mind.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Site breadcrumbs: trouble with inheritance

[Andreas Sewe]

Hi all,

I have the following two projects:

A dedicated website project for my root URL

  org.example:site (with urlhttp://example.org//url)

and an organizational POM

  org.example:parent (with urlhttp://example.org/parent/url)

The parent of org.example:site is the organizational POM, 
org.example:parent. Both projects have their own site.xml.

So far, I think, that's all according to Best Practices.

The trouble starts once I configure breadcrumbs. What I want to generate 
are the following two breadcrumb trails:


  Example.org Site

and

  Example.org Site  Example.org Parent

for org.example:site and org.example:parent, respectively. Note that 
these two trails do not mirror the project's inheritance tree, but 
rather the users' expectations (org.example:site is the main website 
artifact, after all).


But no matter what breadcrumbs I define in the site.xml of both 
projects, I cannot get the desired effect. In particular, the following 
doesn't work:


  !--org.example:parent's site.xml --
  breadcrumbs
item name=Example.org Site href=http://example.org//
item name=Example.org Parent href=http://example.org/parent//
  /breadcrumbs

  !--org.example:site's site.xml --
  breadcrumbs
item name=Example.org Site href=http://example.org//
  /breadcrumbs

While the breadcrumbs of org.example:parent are correct, the trail of 
org.example:site is simply too long:


  Example.org Site  Example.org Parent

It's almost as if not merging occurred at all. But it gets worse:
If I change the site.xml of org.example:site just slightly, the 
breadcrumb trail of org.example:site grows even longer:


  breadcrumbs
item name=Example.org *Main* Site href=http://example.org//
  /breadcrumbs

yields

  Example.org Site  Example.org Parent  Example.org *Main* Site

Can someone please explain to me what's going on here? To me, the 
inheritance behavior of breadcrumbs looks rather random.


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Site breadcrumbs: trouble with inheritance

[Andreas Sewe]

Hi Lukas,

Which version of the site plugin are you using? Please try latest 
snapshots (2.3- or 3.0-beta-4-) and report back.


thanks for the quick reply. Forget to mention that I am using 
3.0-beta-4-SNAPSHOT under Maven 3.0.3. Sorry about that.


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Site breadcrumbs: trouble with inheritance

[Andreas Sewe]

Hi Lukas,


Two things:

1) breadcrumbs always get appended, you cannot override or remove a 
breadcrumb that has been added in a parent


Yes, this explains why we have breadcrumb trails like the following.

Apache  Maven  Apache Maven Site

Here, both Maven and Apache Maven Site point to the same URL.


2) identical breadcrumbs are ignored

In your first case above, you are trying to add the same breadcrumb 
(same name, same href) again that is already defined in the parent, so 
according to 2) it is ignored and you only get the parent breadcrumbs.


In your second case the child breadcrumb is appended according to 1) so 
you get 3 (2 parent + 1 child) breadcrumbs.


Interesting that the notion of equality is based on *both* @href and 
@name; I would have expected it to only consider the former. (But that 
doesn't solve my problem, of course.)


This is the currently expected behavior. The fact that one cannot 
override or remove breadcrumbs is annoying, you might want to file a 
feature request for it.


Done: http://jira.codehaus.org/browse/MSITE-582

Thanks for you explanation.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

site.xml: property interpolation and inheritance

[Andreas Sewe]

Hi all,

I have a question regarding property interpolation and inheritance in 
the case of site descriptors. I looks to my like these behave 
differently than property interpolation and inheritance in the case of 
the POM.


Suppose I have the following element within my parent project's site.xml

  bannerRight
name${project.description}/name
  /bannerRight

Now a child project's site:effective-site contains the following:

  bannerRight
nameDescription of the *parent* project/name
  /bannerRight

Why is that? Inherited elements in the POM (e.g., url) are subject to 
property interpolation in the context of the child project rather than 
the parent project. Why is this different for site descriptors? And is 
there a workaround other than copy-and-pasting the site.xml into the 
child project.


FWIW, I am using Maven 3.0.2, the maven-site-plugin version 3.0-beta-3, 
and have attached my descriptor to the parent project; the attached 
descriptor is already fully interpolated. :-(


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: site.xml: property interpolation and inheritance

[Andreas Sewe]

Hi Lukas,


That's an old bug: http://jira.codehaus.org/browse/MSITE-135


*sigh* I should really check the issue tracker first. :-(


I am currently looking at site inheritance issues, maybe I'll get to it...


That would be great. Thanks.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Chicken-and-egg problem: plugin dependencies as modules

[Andreas Sewe]

Hi Wayne,

thanks for the advice.


What's the best way to resolve this kind of chicken-and-egg problem
without introducing too many extra projects just to break the cycle? Any


This is exactly what you have to do. The rulesets should be packaged
and versioned independent of the project. Ideally you'd have one
corporate ruleset and all your various projects would just use it.


But the ruleset project should inherit from the organizational POM -- as 
all good projects in our organization do. Now, that would imply that the 
organizational POM cannot prescribe the use of the ruleset, as this 
would result in a cyclic dependency.


What's the way out of this? Is something like the following considered 
best practice?


organizational POM
|
+-- ruleset
|
+-- project parent (configures p-pmd-plugin with ruleset dependency)
|
+-...- any other project that should be subject to m-pmd-d checks.

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Chicken-and-egg problem: plugin dependencies as modules

[Andreas Sewe]

Hi Stephen,


The organizational pom can prescribe the use of the most recently
released ruleset.

The next version of the ruleset would technically be checked against
the previous version, but as rulesets are not java code the check will
not be applied on that artifact.


True.

But its a little bit tricky to get this setup off the ground in the 
first place:


1. Release version 1.0 of organizational POM
   (without m-pmd-p)
2. Release version 1.0 of ruleset
   (inheriting from organizational POM, version 1.0)
3. Release version 2.0 of organizational POM
   (with m-pmd-p and ruleset, version 1.0)

And the ruleset is doomed to perpetually lag behind one version of the 
organizational POM.


I think I like the two-parents solution better: the organizational POM 
is restricted to (plugin|dependency)Management, with the other parent 
binding plugins for real.


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Chicken-and-egg problem: plugin dependencies as modules

[Andreas Sewe]

Hi all,

I am experiencing a kind of chicken-and-egg problem in my usage of the
m-pmd-p, the m-checkstyle-p, and the m-license-p. All these plugins are
capable of loading their respective configurations (rulesets or license
headers) from the plugin's classpath. As such it seems sensible to
create dedicated ruleset or license-header Maven projects, which the
respective plugins then depend on.

Problems start, however, if those ruleset or license-header projects are
modules of a common parent project, which configures the respective
plugins for all its descendants:

 parent (configures m-pmd-p with ruleset project as plugin dependency)
 |
 +-- ruleset
 |
 +-...- any other project that should be subject to m-pmd-d checks.

This, of course, introduces a cycle in the projects dependencies; you
cannot build parent without building ruleset first, which itself
inherits from parent.

What's the best way to resolve this kind of chicken-and-egg problem
without introducing too many extra projects just to break the cycle? Any
best practices and recommendations?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven 3 multi-module site

[Andreas Sewe]

Hi Jan,


I have added

build
plugins
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-site-plugin/artifactId
  version3.0-beta-3/version
 configuration
reportPlugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version2.5.1/version
  /plugin
/reportPlugins
  /configuration
/plugin

to the root pom.

When I do 'mvn site', mojo docs are generated fine for each maven-plugin module 
in target/site/plugin-info.html, but the root POM target/site/ folder is empty 
apart from standard css/ and images/ folders.
  
Maybe there is sth fundamental I am missing here?


I think you came across http://jira.codehaus.org/browse/MSITE-484. Try 
adding the m-project-info-reports-p as a reportPlugin as well.


I hope this helps.

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-dependency-plugin: type and classifier for *-test-sources.jar?

[Andreas Sewe]

Hi all,

I need to use the maven-dependency-plugin to copy a *-test-sources.jar 
artifact. Alas, I am unable to find the proper values for the 
artifactItem's type and classifier. I either end up copying 
*-sources-jar or *-tests.jar, but never *-test-sources.jar. :-(


Can anyone please help me with this? How to use type and/or 
classifier to achieve the desired effect?


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven-dependency-plugin: type and classifier for *-test-sources.jar?

[Andreas Sewe]

Hi Justin,


type = jar
classifier = test-sources


yes, that did the trick. Thanks :-)

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reporting plugins: How to report a plugin's configuration?

[Andreas Sewe]

Hi all,

I have written a Maven plugin (custom packaging) which so far works 
fine. :-) Now I want to accompany it with a reporting mojo, which 
presents the plugin's configuration as a project report.


This, alas, proves to be quite difficult; not only is the ${project} 
MavenProject quite unwieldy, but I also need to access the *effective* 
configuration of the plugin, i.e., I need to take executions and active 
profiles into account.


Can someone provide me with some pointers to plugins doing similar 
things? (I already had a look at the m-plugin-p and the 
m-project-info-reports-p, but that didn't help much.)


Best wishes,

Andreas

-
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

[Andreas Sewe]

Hi Phillip,


Does it make sense and will it work to define the scm connection in a
parent pom if all my projects follow the same layout in SVN?

i.e., 
connectionscm:svn:http://mysvnrep.com/svn/projects/${artifactId}/trunk/connection


in theory, the above makes sense, but in practice you will encounter a 
problem: if scm/connection is inherited by a child POM, Maven 
automatically appends the equivalent of /${project.artifactId} to your 
SCM URL.


Thus, you end up with 
scm:svn:http://mysvnrep.com/svn/projects/${artifactId}/trunk/${project.artifactId};, 
which is in all likelihood not what you intended. (You are aiming for a 
flat repository layout here, which parent and child on the same level, 
right?)


Unfortunately, Maven is extremely prejudiced in favour of a hierarchical 
layout. 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.


I hope this helps.

Andreas

-
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

[Andreas Sewe]

Hi Stephen,


IIRC the appending is controlled by the presence of a / at the end of the URI

if the URI ends with a slash then it will not append the module name in children

if the URI does not end with a slash then it will append the module
name in children

of course I could be mistaken and this might only apply to
/project/url but I thought it also applied to /project/scm/*


you are right. This is indeed the case -- at least with Maven 3.0 (just 
tested it), although I do recall that it didn't always work like this 
(see http://jira.codehaus.org/browse/MNG-3244, which Luke pointed to.)


That being said, can you comment on what went wrong in your setup? Would 
be interesting to know why you are so against using properties in 
/project/scm/*.


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-site-plugin 3: how to properly add to inherited reportPlugins?

[Andreas Sewe]

Hi all,

I am currently having trouble configuring the maven-site-plugin 
3.0-beta-2. The setting is slightly more complex than the one described 
in the wiki 
https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html: A parent 
POM configures a some reportPlugins and a child POM wants to add some 
more -- without having to repeat the parent's reportPlugins again.


Configuring an additional execution of site:site doesn't seem the way to 
go; it completely messes up the Project Documentation menu (on some 
pages, Project Information is the only submenu, on others it is 
Project Reports).


Can someone point me in the right direction? Thanks.

Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Property interpolation to access the parent POM?

[Andreas Sewe]

Hi all,

is it possible to access the parent POM by means of property interpolation?

While the help:evaluate goal correctly interpolates
${project.parent.url}, using the property in the child POM doesn't
trigger interpolation (in neither Maven 2.2 nor 3.0); the string stays
as is. I could only get ${project.parent.groupId},
${project.parent.artifactId}, and ${project.parent.version} to work, but
I guess these simply come from the child POM rather than from the parent.

So, is it possible to access the real parent POM at all? And what does
help:evaluate evaluate against?

Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Maven 3.0 Released

[Andreas Sewe]

Thanks a lot for Maven 3.0!


Thanks a lot for all the work and ... can't wait for the pom mixins ;)


Speaking of which, it seems to me that POM mixins would offer a more 
flexible alternative to what is currently achieved by the packaging 
types' lifecycle bindings. Are there any plans to eventually supplant 
the current ad-hoc mechanism with a mixin-based approach? (After all, 
just because I want a JAR doesn't mean I want the Java compiler.)


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Complex-valued maps as plugin parameter possible?

[Andreas Sewe]

Hi all,

any takers for this one?

I am writing a Maven plugin and have trouble getting a parameter defined 
as follows to work:


/**
 * @parameter
 */
private MapString,ComplexObject map;

Not matter how I configure map in my POM, it only ever maps Strings to 
null, not to an instance of ComplexObjext:


map
  key
!-- ComplexObject class lives in same package as mojo --
complexObject
  someField42/someField
complexObject
  /key
/map

But as far a I understand the Guide to Configuring Plug-ins 
http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Maps, 
the above should work. Alas, it doesn't work even if I add an 
appropriate implementation attribute to complexObject (or key, for 
that matter).


What's odd is that ListComplexObject works fine as parameter -- and 
the aforementioned guide simply states that mapping maps works the same 
way. But it seems like this is wrong and having complex-valued maps as 
plugin parameter is impossible. :-(


Can someone please shed light on the issue. Thank you.


Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Complex-valued maps as plugin parameter possible?

[Andreas Sewe]

Hi all,

I am writing a Maven plugin and have trouble getting a parameter defined 
as follows to work:


/**
 * @parameter
 */
private MapString,ComplexObject map;

Not matter how I configure map in my POM, it only ever maps Strings to 
null, not to an instance of ComplexObjext:


map
  key
!-- ComplexObject class lives in same package as mojo --
complexObject
  someField42/someField
complexObject
  /key
/map

But as far a I understand the Guide to Configuring Plug-ins 
http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Maps, 
the above should work. Alas, it doesn't work even if I add an 
appropriate implementation attribute to complexObject (or key, for 
that matter).


What's odd is that ListComplexObject works fine as parameter -- and 
the aforementioned guide simply states that mapping maps works the same 
way. But it seems like this is wrong and having complex-valued maps as 
plugin parameter is impossible. :-(


Can someone please shed light on the issue. Thank you.

Best wishes,

Andreas

-
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

[Andreas Sewe]

Hi,


I need to invoke an external command using the Exec plugin, with one of the
arguments equal to ${basedir}/target. The problem is that under Windows
this expands to c:\\temp\\project/target because ${basedir} uses
Windows-style slashes whereas the rest of the argument uses Unix-style
slashes. Needless to say, the external program fails to run. If I switch the
slash-style to ${basedir}\\target then it will fail under Unix.


Does using ${file.separator} instead of slashes work? After all, these 
standard Java properties are available for interpolation in the POM.


Using a profile as Dan suggested strikes me as a bit of overkill for the 
problem at hand.


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-assembly-plugin: How to make the assembly the primary artifact

[Andreas Sewe]

Hi all,

I have a project which should produce a ZIP, with all contents of 
${project.build.outputDirect} put into a base directory within the ZIP. 
So far, the maven-assembly-plugin with includeBaseDirectory fits the 
bill perfectly.


There is one issue, however, which I haven't been able to solve: I can't 
get the plugin to make the produced assembly the *primary* artifact. 
(There is only a single assembly per project produced this way.)


Is this possible? Or is there another plugin which I can resort to? (The 
 org.apache.maven.plugins:maven-zip-plugin does almost what I want, but 
seems to be not longer supported in favour of the 
maven-assembly-plugin.) Any suggestions?


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: standardized Maven GAV URN?

[Andreas Sewe]

Luke,

are you aiming at IANA registration of the namespace identifier? (If 
not, please use a x- prefix to mark the NID as experimental: 
http://tools.ietf.org/html/rfc3406#section-3.1.)


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Provided-scoped dependencies and transitivity

[Andreas Sewe]

Hi all,

I have a hard time figuring out how provided-scoped dependencies 
interact with transitivity; either the documentation or the 
maven-dependency-plugin seem to get it wrong.


According to the matrix in 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope 
a provided-scoped dependencies of a provided-scoped project dependency 
are themselves of scope provided (w.r.t. the project being built).


The maven-dependency-plugin, however, disagrees. Both dependency:tree 
and dependency:copy-dependencies (with 
includeScopeprovided/includeScope) ignore the transitive 
dependencies of my provided-scoped dependency. :-(


So who's right: the documentation or the plugin?

Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Provided-scoped dependencies and transitivity

[Andreas Sewe]

Hi Jörg,

thanks for the quick reply.


According to the matrix in
http://maven.apache.org/guides/introduction/introduction-to-dependency-

mechanism.html#Dependency_Scope

a provided-scoped dependencies of a provided-scoped project dependency
are themselves of scope provided (w.r.t. the project being built).

The maven-dependency-plugin, however, disagrees. Both dependency:tree
and dependency:copy-dependencies (with
includeScopeprovided/includeScope) ignore the transitive
dependencies of my provided-scoped dependency. :-(

So who's right: the documentation or the plugin?


The plugin.


Well, yes: In a sense, the code is always right, but what's the 
intuition behind the plugin's behavior? After all, if your project 
assumes that X is provided by the environment and X assumes the Y is 
provided by the environment, the environments should better provide both 
X and Y, right? Why ignore this information?


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven-assembly-plugin: outputFileNameMapping and ${artifact.*}

[Andreas Sewe]

Hi all,

here's a report of my progress on this issue, in case others find it 
useful:


The maven-assembly-plugin uses an ObjectBasedValueSource to evaluate
${artifact.*} expressions with respect to the artifact's MavenProject 
(among other things). You can thus access the artifact's properties by 
${artifact.model.properties}. This, however, gives you a map and the 
reflection-based ObjectBasedValueSource is stuck; there is no 
zero-arguments getter to use.


At the moment, I don't see a way to accomplish what I am trying to do, 
even although the documentation hints that this is possible:


   3. Match against the project instance associated with the 
dependency’s Artifact (resolves: mainly POM properties)


Are there any chances of extending the capabilities of the 
maven-assembly-plugin in this respect? Or of at least fixing the 
documentation -- although this does not solve my problem. :-(


Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-assembly-plugin: outputFileNameMapping and ${artifact.*}

[Andreas Sewe]

Hi all,

I am using the maven-assembly-plugin to copy some dependencies around. 
Unfortunately, I have to rename them in some fairly arbitrary fashion, 
i.e., the final name has nothing to do with the dependencies artifactId 
or groupId. (And no, I can't change that!)


According to the Maven Reference it should be possible to use a property 
defined in the dependency's POM as the name of the output file, but 
cannot make enough sense of the following (from 
http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-output-algorithm.html#assemblies-sect-interpolate) 
to figure out how I have to name this property:



If the expression matches the pattern ${artifact.*}:

   1. Match against the dependency’s Artifact instance (resolves: groupId, 
artifactId, version, baseVersion, scope, classifier, and file.*)
   2. Match against the dependency’s ArtifactHandler instance (resolves: 
expression)
   3. Match against the project instance associated with the dependency’s 
Artifact (resolves: mainly POM properties)


If I put artifact.final.namearbitrary/artifact.final.name in the 
dependency's POM and 
outputFileNameMapping{artifact.final.name}.dat/outputFileNameMapping 
in my assembly descriptor's dependencySet I think it should work -- 
only it doesn't. The copied dependency ends up named 
{artifact.final.name}.dat. :-(


Any thoughts?

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven Best Pratices: Where to place generate re(sources)?

[Andreas Sewe]

Hi all,

I have a project which uses dependency:unpack to grab Java sources as 
well as some binary resources from a JAR. The Java sources thus 
generated have then to be compiled, the binary resources must simply 
wind up in the project's artifact.


At the moment, I unpack the Java sources into 
${project.build.sourceDirectory} and the resources into 
src/main/resources in the generate-sources and generate-resources 
phases, respectively. This setup, however, has one disadvantage: neither 
the source nor resource directories are cleaned when in the clean 
lifecycle phase. But this is desirable for generated (re)sources. Of 
course, I can configure the m-clean-p appropriately, but the less 
configuration the better, right?


So, what are best practices to handle a situation like this? Should I 
rather unpack the (re)sources to a directory somewhere below 
${project.build.directory}? (This is what dependency:unpack does by 
default, after all.) But this would require use of the buildhelper-m-p, 
for otherwise the unpacked sources won't be picked up by the compiler. :-(


Any advice?

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: AW: Maven Best Pratices: Where to place generate re(sources)?

[Andreas Sewe]

Hi Eric,


I don't know if my practice is best, but I certainly advise you to unpack to 
the ${project.build.directory}, since
a) it's deleted during clear
b) you don't want to mess up your source directories, especially if you use SCM


true.


And yes, you then need the buildhelper.


Yes, the builderhelper-m-p does the job; the reuslting POM's not pretty, 
though.



However, reading your message makes me wonder why you're unpacking a dependency 
at all. I don't know your use case, but if you use the resources, you could 
just load them from the classpath.


No, unfortunately, I cannot do that. I have to build a JAR which has a 
specific internal structure (a couple of directories containing further 
JARs and sources) which is then unzipped by a third-party application 
during its  execution. Not my design choice, but one I have to live 
with. :-(


Best wishes,

Andreas


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: AW: AW: Maven Best Pratices: Where to place generate re(sources)?

[Andreas Sewe]

Hi Eric,


Seriously, though, it looks like you're only repacking existing dependencies. 
So you might want to look into the Assembly plugin (after reading the chapters 
in the Sonatype book).


I'll have a look at the m-assembly-p. That being said, here's what I try 
to do:


- Grab a couple of dependency JARs so they end up in the final JAR/ZIP.
  (That's the easy part.)
- Download a *-sources JAR and compile *some* .java sources; the
  resulting .class files have to end up in the final JAR/ZIP.
  (Alternatively, extract the correspodning .class files from the
  primary artifact.)
- Copy some other sources (.scala files) verbatim into the final
  JAR/ZIP.

The reason I currently compile the .java sources myself rather than 
simply extracting the resulting classes from the primary artifact is 
that after compilation I can no longer easily distinguish .java and 
.scala files. But only the latter of which have to be copied verbatim 
into the final JAR/ZIP.


That being said, there is one thing that makes me wonder whether the 
m-assembly-p is the right tool for the job: it attaches an additional 
artifact. But in my understanding this project produces only on artifact 
(containing the stuff described above). Simply producing a dummy 
artifact somehow feels wrong to me, like I am abusing the plugin for 
something it wasn't meant to do.


Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Site plugin 2.1 and PMD/CPD don't play nicely

[Andreas Sewe]

Kathryn Huxtable wrote:

My CPD HTML report is empty when I use maven-site-plugin 2.1. The XML report is 
fine. The PMD report is fine.

If I use maven-site-plugin 2.0.1 I get my CPD report.

I don't know if this is a problem with PMD, Site, or Doxia, but I've filed 
MPMD-119 to report it.

Has anyone else experienced this?


Yes, using m-site-plugin 2.1 I see the same problem here. :-( My cpd.xml 
contains a bunch of duplications, but the resulting cpd.html only has a 
h2Duplications/h2 followed by an empty paragraph.


Thanks for reporting the issue. (Already voted for it :-)

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Binding antrun:run to clean phase fails the build after initial project checkout

[Andreas Sewe]

Hi all,

I have a problem with the maven-antrun-plugin in a very simple multi-module
setup (1 parent, 2 modules). I am binding the antrun:run goal to the
clean phase (which seems to be quite a common setup) and run mvn clean
in the (aggregating) parent. The builds fails, however, whenever module1,
which
module2 depends on, has not yet been installed into the local repository
-- in particular after an initial checkout of the three projects.

This is quite unexpected, as the traditional mvn clean install works
*except* for the initial build; then you have to use mvn install. This is
very confusing to my users. Is there a workaround?

FWIW, here's my (almost) complete POM for module2 (which depends on
module1):

project ...
  ...
  parent
artifactIdparent/artifactId
groupIdorg.example/groupId
version0.0.1-SNAPSHOT/version
relativePath../relativePath
  /parent
  artifactIdmodule2/artifactId
  namemodule2/name
  dependencies
dependency
  groupIdorg.example/groupId
  artifactIdmodule1/artifactId
  version0.0.1-SNAPSHOT/version
/dependency
  /dependencies
  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
executions
  execution
idproblematic-clean/id
phaseclean/phase
goalsgoalrun/goal/goals
configuration
  tasks
echo message=Performing clean/
  /tasks
/configuration
  /execution
/executions
  /plugin
/plugins
  /build
/project

Best wishes,

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven-invoker-plugin: reactor build order in multi-module build

[Andreas Sewe]

Hi all,

I have an couple of integration tests (it-with-a and it-with-b) run 
using the maven-invoker-plugin. Each of these integration tests depends 
on some dependencies of their own (a and b, respectively).


Unfortunately, Maven does not consider these dependencies when 
determining the reactor build order during a multi-module build:


aggregator
|
+--a
|
+--b
|
\--module
   |
   +--src/it
  |
  +--it-with-a
  |
  \--it-with-b

Even though it-with-a depends on module a and it-with-b depends on 
module b, Maven happily chooses a build order of module, a, b. 
Of course, this could be solved by making module itself depend on both 
a and b. Alas, this is not possible. I cannot have a and b on 
the classpath at the same time (the two modules build two versions of 
the same project; this results in name clashes).


Is there a way to overcome this problem?

FWIW, the maven-failsafe-plugin doesn't help; I would need to test 
classpaths: on with a and one with b. :-(


Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin executions vs. POM inheritance

[Andreas Sewe]

Thanks Wayne, thanks Ron,

that looks like an alternative way to achieve what I want:

I am not sure what you are trying to do but I am wondering if you can build
several parent POMs and set up each POM have the parent that suits its
needs.


Yes, this is the composition vs inheritance approach to managing your
projects and poms. It can be useful in certain projects where eg the
wars all have one war-parent, etc.


I am still curious, though, what Stephen meant by his reply to Lóránt's 
original question. From what I could gather, Lóránt is in a situation 
similar to myself, but inheritedfalse/inherited doesn't work for me 
at all.


What am I missing? (Neither the POM Reference nor the Guide to 
Configuring Plug-ins were of any help here.)


Best wishes,

Andreas

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Plugin executions vs. POM inheritance

[Andreas Sewe]

Hi Stephen,

I am in a situation similar to the OP's, so your reply made me refactor 
my POMs. (Its never to late to get rid of a little copy-n-paste :-)


But unfortunately I couldn't get your proposal to work. Here's the 
execution I configured in my parent POM, which I want to reuse in *some* 
of my child POMs:


pluginManagement
plugins
plugin
artifactIdmaven-failsafe-plugin/artifactId
version2.5/version
!-- Thrown in for good measure; I suspect I only need the 
execution-level inherited --

inheritedfalse/inherited
executions
execution
idintegration-test-with-foo/id
inheritedfalse/inherited
goals
goalintegration-test/goal
goalverify/goal
/goals
configuration
argLineFOO/argLine
/configuration
/execution
/executions
/plugin
plugins
/pluginManagement

Due to the use of pluginManagement instead of a plain plugins the 
parent POM itself does not use this execution (as desired).


Now, calling the integration-test-with-foo execution from a child POM 
also works fine:


plugins
plugin
artifactIdmaven-failsafe-plugin/artifactId
executions
execution
idintegration-test-with-foo/id
/execution
/executions
/plugin
plugins

But even if I don't call it at all from one of my child POMs, but rather 
use a different plugin execution, integration-test-with-foo still gets 
executed (along with integration-test-with-bar):


plugins
plugin
artifactIdmaven-failsafe-plugin/artifactId
executions
execution
idintegration-test-with-bar/id
goals
goalintegration-test/goal
goalverify/goal
/goals
configuration
argLineBAR/argLine
/configuration
/execution
/executions
/plugin
plugins

And that's something I don't understand. Isn't 
inheritedfalse/inherited supposed to prevent this? (FWIW, this 
happens using either Maven 2.2.0 or a recent 3.0-SNAPSHOT, so I suppose 
its a bug in my understanding of inherited rather than in Maven's.)


Best wishes,

Andreas Sewe


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Sharing Module among Multiple Projects

[Andreas Sewe]

Nick Stolwijk wrote:

Oh, I thought of another way:

Forget the whole profiles, just make one aggregator pom in the root
level (so specify all the modules in there) and call Maven with:

mvn clean install --projects MediaProcessor --also-make

--projects (Shorthand: -pl) specifies which projects should be build
--also-make (Shorthand: -am) specifies that also the dependencies of
the projects should be build


Hey, that's a very useful tip. Thanks for this. :-)

Alas, it doesn't seem to work with a flat module layout. My aggregator 
POM hereby looks as follows:


  modules
module../subproject/module
  /modules

But neither

  mvn clean install --projects '../subproject' --make-also

nor

  mvn clean install --projects subproject --make-also

work; in both cases Maven complains that it couldn't find specified 
project in module list (although the absolute path it prints out in the 
former case points to the correct submodule.) Do you have any idea of 
what I am doing wrong here?


Best wishes,

Andreas Sewe

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org