Re: How to include only certain test packages in a maven test-jar & all non test code in a non test jar?

[Stanimir Stamenkov]

Sat, 30 Mar 2024, /Debraj Manna/:

As suggested by Stanimir if I remove the test-jar type and also the 
includes like below then mvn package --projects=:agent -T 2 --also-make 
works

[...]
But if I add back the below inclusion it again starts throwing the 
NoClassDefFoundError

[...]


At least for me, it is already hard to follow.  Without accessible full 
example setup I can only suggest you follow Gary's and the official 
documentation advice to factor the necessary classes into their own 
module, declaring their dependencies explicitly:


 * 
https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html#the-preferred-way



*The preferred way*

In order to let Maven resolve all |test|-scoped transitive dependencies 
you should create a separate project.


  * Move the sources files from |src/test/java| you want to share from the 
original project to the |src/main/java| of this project...


--
Stanimir

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

Re: How to include only certain test packages in a maven test-jar & all non test code in a non test jar?

[Stanimir Stamenkov]

Thu, 28 Mar 2024, /Debraj Manna/:

Ok I can try that but I can see the type test-jar from the below 
documentation


https://maven.apache.org/guides/mini/guide-attached-tests.html


I hadn't been aware of it.  It could be specific to the ear-plugin:

* https://issues.apache.org/jira/browse/MEAR-216



On Thu, Mar 28, 2024 at 3:11 PM Stanimir Stamenkov wrote:

Thu, 28 Mar 2024, /Debraj Manna/:



com.spotnana
synapse
0.0.1-SNAPSHOT
tests
test-jar


This doesn't seem right.  I'm not aware of test-jar – 
should be just jar (or just omit it as it is implied).


--

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

Re: How to include only certain test packages in a maven test-jar & all non test code in a non test jar?

[Stanimir Stamenkov]

Thu, 28 Mar 2024, /Debraj Manna/:


But I am still facing issues in the below case.
[...]


   com.spotnana
   synapse
   0.0.1-SNAPSHOT
   tests
   test-jar


This doesn't seem right.  I'm not aware of test-jar – 
should be just jar (or just omit it as it is implied).



   test


Now if I am trying to do mvn package --projects=:agent -T 2 --also-make

I am getting NoClassDefFound for common/C.java while tests are being
executed in the agent module...


--
Stanimir

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

Re: How to include only certain test packages in a maven test-jar & all non test code in a non test jar?

[Stanimir Stamenkov]

See my reply below the quote...

Fri, 22 Mar 2024, /Debraj Manna/:


[...]
I tried the below


   

 org.springframework.boot
 spring-boot-maven-plugin
 
   true
 


  org.apache.maven.plugins
  maven-jar-plugin
  3.3.0
  
   
 common/**
   
 
 
   
 
   test-jar
 
   
 
   
  
   

I am observing that the test-jar is getting created as expected containing
only the code from test/java/common but the non-executable, non-test jar
does not contain the code from main/java/package1.


The easiest way is probably what Gary Gregory has suggested – extract 
the common code in its own module.


Your main JAR is likely missing classes as you've applied  
configuration globally to the maven-jar-plugin, and not just to the 
"test-jar" execution:



  

  test-jar


  
common/**
  

  


You may wish to give the execution a non-default ID, and produce 
additional JAR with a different classifier:



  
common-test-jar

  test-jar


  tests-common
  
common/**
  

  


You'll then use the given classifier when specifying this JAR as a test 
dependency to other modules.


See also: "How to create an additional attached jar artifact from the 
project" 



--
Stanimir

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

Re: Publishing to Maven Central and non-OSS plugin dependencies

[Stanimir Stamenkov]

Fri, 1 Mar 2024, /Olivier Lamy/:


users will not be able to rebuild from sources.
is it a requirement? No real idea as already said in this thread, you 
need to ask Sonatype.

But it breaks the concept of opensource as you cannot build from the sources :)


The sources uploaded to Maven Central are generally not sufficient for a 
rebuild.  They are convenient for debugging and quick look up, however 
one almost always need to go to the project's website, and download full 
sources necessary for a complete build.  The project's website could be 
just a source repository with a top-level README.


I don't think Sonatype has or can have a requirement of "online project 
site available".  There are older artifacts people still rely on, that 
may never be rebuilt because the original sites are long gone.  Does it 
mean they should be removed from Maven Central, for example?  I think it 
should be mainly up to the users to decide whether they want to use a 
particular artifact.


As far as I'm aware there could be Free Open-source and Non-free 
Open-source.  I don't know if complete build instructions are 
requirement for the latter, and Open-source in general?


--
Stanimir

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

Re: Maven resilience to interrupted install to local repository

[Stanimir Stamenkov]

Thu, 29 Feb 2024, /Tamás Cservenák/:


am not Windows user, but we had several reports about issues, like this one:
https://issues.apache.org/jira/browse/MRESOLVER-372


I see.  Thank you for the reference.

As far as I'm aware, such "access denied" exceptions on Windows are not 
specific to atomic moves.  It could happen one process has opened a file 
for reading, preventing another from overwriting it immediately.  I 
guess such updates need a retry mechanism, at least for the atomic move 
part.




On Thu, Feb 29, 2024 at 1:40 PM Stanimir Stamenkov wrote:

Thu, 29 Feb 2024, /Tamás Cservenák/:


Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target 
file is, and then atomically moves the file to its place

(unless OS is windows, for obvious reasons).


Doesn't atomic file move/replace work on Windows?  I'm using 
Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same 
technique on Windows successfully.


[1] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption..
.)
[2] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE


--

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

Re: Maven resilience to interrupted install to local repository

[Stanimir Stamenkov]

Thu, 29 Feb 2024, /Tamás Cservenák/:


Resolver 1.9.18 uses the temp file technique you describe:
copies to (random) temp file located in the same directory where target 
file is, and then atomically moves the file to its place

(unless OS is windows, for obvious reasons).


Doesn't atomic file move/replace work on Windows?  I'm using 
Files.move() [1] with ATOMIC_MOVE [2] option to achieve the same 
technique on Windows successfully.


[1] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/Files.html#move(java.nio.file.Path,java.nio.file.Path,java.nio.file.CopyOption...)
[2] 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/file/StandardCopyOption.html#ATOMIC_MOVE


--
Stanimir

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

Re: Can't test a package with Surefire?

[Stanimir Stamenkov]

Mon, 5 Feb 2024, /sebb/:


Under Windows,
mvn test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.ArchiveTest
fails with
Unknown lifecycle phase
".apache.commons.compress.harmony.pack2000.tests.ArchiveTest".
but the following works:
mvn test 
-Dtest="org.apache.commons.compress.harmony.unpack200.tests.ArchiveTest"
I think this shows that '.' *is* treated as a separator on Windows.


All right.  What you describe appears happening using PowerShell vs. the 
standard Command Prompt.  Using Command Prompt the former works just 
fine, and the later fails:


=org.apache.commons.compress.harmony.unpack200.tests.ArchiveTest"" was 
unexpected at this time.


I don't use (never liked) PowerShell and I'm not aware of its parsing rules.

--
Stanimir

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

Re: Can't test a package with Surefire?

[Stanimir Stamenkov]

Mon, 5 Feb 2024, /sebb/:


That looks like a Windows quoting issue; Windows does not like '.' in
parameter values

Try

mvn clean test -D"test=org.apache.commons.compress.harmony.unpack200.tests.*"


Dot (.) doesn't appear a standard delimiter on Windows:

* https://ss64.com/nt/syntax-esc.html#delimiters

and the the suggested quoting doesn't work for me.

However I've tried alternative syntax I've noticed in the referenced 
documentation:


pkg/**/Ci*leTest.java

and the following worked for me:

> mvn clean test 
-Dtest=org/apache/commons/compress/harmony/unpack200/tests/*

[...]
[WARNING] Tests run: 168, Failures: 0, Errors: 0, Skipped: 10

Maybe it is just the plugin documentation wrong?



On 2024/02/05 15:22:09 "Gary D. Gregory" wrote:


[...]
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test 
(default-test) on project commons-compress: No tests matching pattern 
"org.apache.commons.compress.harmony.unpack200.tests.*" were executed! (Set 
-Dsurefire.failIfNoSpecifiedTests=false to ignore this error.) -> [Help 1]

What am I doing wrong?

Does this page not say what I think it's saying? 
https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html

"As of Surefire Plugin 2.19.1, the syntax with fully qualified class names or 
packages can be used ..."

Reproduce me:

git clone https://gitbox.apache.org/repos/asf/commons-compress.git
cd commons-compress
mvn clean test -Dtest=org.apache.commons.compress.harmony.unpack200.tests.*


--

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

Re: Pause not working in batch file

[Stanimir Stamenkov]

Mon, 8 Jan 2024 22:05:42 +0200, /Stanimir Stamenkov/:

Mon, 8 Jan 2024 13:49:41 -0600, /Neil Aggarwal/:

call mvn exec:exec -Dexec.executable="java" 
-Dexec.args="-Djava.library.path=C:\OneDrive\Dev\Jacob -cp %%classpath 
com.fiscalassets.tax.PrintForm1098s application.properties.FiscalAssets"


I'm speculating you may need to double escape the % like (%-tripled):

   -cp %%%classpath


It should more likely be %-quadrupled:

   -cp classpath


See: https://ss64.com/nt/call.html#advanced


This one (%-tripled) appears to apply when using CALL with an internal 
batch command.


--
Stanimir

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

Re: Pause not working in batch file

[Stanimir Stamenkov]

Mon, 8 Jan 2024 13:49:41 -0600, /Neil Aggarwal/:

I am trying to put my Maven command in a batch file so I can click 
on the icon to run it.

[...]
If I try putting call before the mvn command:

call mvn exec:exec -Dexec.executable="java"
-Dexec.args="-Djava.library.path=C:\OneDrive\Dev\Jacob -cp %%classpath
com.fiscalassets.tax.PrintForm1098s application.properties.FiscalAssets"

pause

I get an error:

Error: Could not find or load main class com.fiscalassets.tax.PrintForm1098s

Caused by: java.lang.ClassNotFoundException: 
com.fiscalassets.tax.PrintForm1098s


but the pause works.

Anyone know what is happening here?


I'm speculating you may need to double escape the % like (%-tripled):

  -cp %%%classpath

See: https://ss64.com/nt/call.html#advanced

--
Stanimir

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

Re: How to pass java.library.path to mvn exec?

[Stanimir Stamenkov]

Sat, 6 Jan 2024 00:29:57 -0600, /Neil Aggarwal/:


OK, so I changed to try to use the exec:exec goal.
I updated the goal in my pom.xml (Attached) and tried this command line:

mvn exec:exec -Dexec.executable="java" -Dexec.args="-cp %classpath
com.fiscalassets.tax.PrintForm1098s application.properties.FiscalAssets"

I still get this error:
[...]

It is not using the java.library.path I am giving it.


As far as I get you should pass java.library.path in the java executable 
arguments:


mvn exec:exec -Dexec.executable="java" 
-Dexec.args="-Djava.library.path=... application.properties.FiscalAssets"


Alternatively, with exec:java try setting MAVEN_OPTS:

set MAVEN_OPTS=-Djava.library.path=...
mvn exec:java ...

--
Stanimir

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

Re: Fatal error compiling: basedir .../target/generated-sources/annotations does not exist

[Stanimir Stamenkov]

Thu, 21 Dec 2023 09:10:44 +0100, /Slawomir Jaranowski/:


Release under vote ... you can check candidate version:
https://lists.apache.org/thread/scb8qw1or396l4hqgf5h78z5h0km60z4


Tried maven-compiler-plugin 3.12.1 from the staging repository – no 
error during the build.


--
Stanimir

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

Fatal error compiling: basedir .../target/generated-sources/annotations does not exist

[Stanimir Stamenkov]

Following "Maven Compiler Plugin 3.12.0 Released" [1] I'm trying it out 
in a small project of mine [2].  After updating the 
maven-compiler-plugin 3.11.0 -> 3.12.0 I've noticed the following error 
occurring in my dirty(!) working copy:


   > mvn -V package
   Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
   Maven home: ...\apache-maven-3.9.6
   Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: ...\jdk-21
   Default locale: en_US, platform encoding: UTF-8
   OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
   ...
   [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.12.0:compile 
(java9-compile) on project xbrz-core: Fatal error compiling: basedir 
C:\...\xbrz-java\xbrz-core\target\generated-sources\annotations does not 
exist -> [Help 1]


that doesn't occur with the compiler plugin 3.11.0.  The local change 
that appears to trigger the error with the compiler plugin 3.12.0 is 
I've deleted "module-info.java" sources:


   del /s module-info.java   # or with bash

   find -name module-info.java -print -delete

Funny enough, if I restore "xbrz-core/src/main/java9/module-info.java" 
both of "xbrz-core" and "xbrz-awt" get built successfully, then 
"xbrz-tool" fails the same.


Does this behavior appear a regression?  I've found a similar symptom 
fixed long time ago:


*   https://issues.apache.org/jira/browse/MCOMPILER-379

[1] https://lists.apache.org/thread/9x7p7k5n7vptopqrt55o7c2pg7pnznh2
[2] https://github.com/stanio/xbrz-java

   Note, "xbrz-java" currently requires JDK 21 for building just for 
the javadoc generation.  One may edit .mvn/enforcer-extension.xml to 
relax this requirement for the purpose of `mvn package` alone.


--
Stanimir

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

Re: mvn as used in Eclipse m2e gets parse error because of mistake in Maven 4.0.0 schema

[Stanimir Stamenkov]

Tue, 17 Oct 2023 22:11:29 +0300, /Stanimir Stamenkov/:

I'm not familiar with this attribute but looking at 
<https://maven.apache.org/xsd/maven-4.0.0.xsd>:


You can control how child POMs inherit configuration from parent POMs 
by adding combine.children or combine.self 
attributes to the children of the configuration element...


If I'm reading this correctly, it says the attribute could/should be 
added to the children of the  element, and not on that 
element itself.  Then I don't know why it works in the command-line run.  
I guess others would provide more detail.


This also appears suggested by the documentation referenced in the same 
 element description:


https://maven.apache.org/pom.html#advanced_configuration_inheritance

--
Stanimir

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

Re: mvn as used in Eclipse m2e gets parse error because of mistake in Maven 4.0.0 schema

[Stanimir Stamenkov]

Tue, 17 Oct 2023 11:56:12 -0700, /David Karr/:


[...]
 cvc-complex-type.3.2.2: Attribute 'combine.self' is not allowed to
appear in element 'configuration'.

I, along with multiple other people, assumed that this indicates a bug in 
m2e, because it clearly works in the command-line build.  However, it was 
pointed out that m2e is actually USING the defined schema defined in the 
boilerplate of a pom.xml, instead of ignoring it, and if you open up that 
schema, it clearly shows the lack of an "attribute" element in the 
"configuration" complex-type.


So, clearly mvn is using that attribute, but I'm guessing it's not doing 
any schema validation, or builds using that attribute would fail.


I'm not familiar with this attribute but looking at 
:


You can control how child POMs inherit configuration from parent POMs by 
adding combine.children or combine.self 
attributes to the children of the configuration element...


If I'm reading this correctly, it says the attribute could/should be 
added to the children of the  element, and not on that 
element itself.  Then I don't know why it works in the command-line run. 
 I guess others would provide more detail.


--
Stanimir

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

Re: "First time caller..." javadoc taglet dependencies?

[Stanimir Stamenkov]

Wed, 4 Oct 2023 15:52:14 +, /Joseph Kesselman/:

My only other real gripe with Maven at the moment is that I haven't 
yet found a way to tell the javadoc plugin "Yes, I know there's lots 
that can be improved, but for now please consider that a Warning 
rather than an Error."


If I'm not mistaken it is not the Maven plugin but the standard Javadoc 
tool in newer JDK versions (1.8+) that errors out by default:


https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html#BEJEFABE

By default, the -Xdoclint option is enabled. Disable it with the 
option -Xdoclint:none.


For maven-javadoc-plugin:3.0.0+ this could be configured 
, 
like:


  
none
  

You may try excluding only certain checks, also:

  
all,-missing
  

For older javadoc plugin versions there's "failOnError" property 
 
that's true by default:


  
false
  

The latter is more crude approach but if everything else fails that one 
is likely to help.


--
Stanimir

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

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 20:01:14 +0200, /Thomas Broyer/:


ErrorProne itself doesn't support @file arguments, so I think the question
remains unanswered: can Maven load a property's value from a file?
(possibly through a plugin; I have looked at build-helper-maven-plugin and
apparently it doesn't support it)


There's also a "Properties Maven Plugin":

https://www.mojohaus.org/properties-maven-plugin/

--
Stanimir

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

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 18:04:51 +0200, /Delany/:


Thank you. Its not happening though. I also tried it from the pom, so
-Xplugin:ErrorProne
-XepExcludedPaths:.*/target/.* @${build.root}/ep.config


@files are Java 9+ feature for tools other than javadoc – just making 
sure you're not using Java 8 here.


If @file is specified it must exist, although it could be empty.  If the 
file doesn't exist the tool would fail.


I've just noticed you're providing multiple arguments in a single  
element – I'm not sure if this is supposed to work like that.  Maybe try:


  -Xplugin:ErrorProne
  -XepExcludedPaths:.*target.*
  @${build.root}/ep.config


Made more difficult by lack of visibility what's going on with the javac
processors.


mvn -X (--debug) could be overwhelming but could possibly provide 
insight of what's happening.


--
Stanimir

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

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

[With some more context from the original message.]

Sun, 24 Sep 2023 15:45:49 +0200, /Stanimir Stamenkov/:

Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:

I can also quickly run a build to catch on issue 
that I'm trying to eradicate by adding

-Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"

But having all those rules on one line makes reviewing changes a pain.
I don't really want to config the whole build with the compiler arguments.

Is there a way to specify these in a properties file and have each 
argument on its own line?


Have you tried using @file (a-la javadoc options):

https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files


Maybe:

   -Dep=@myoptions

And in "myoptions" file:

-XepDisableAllChecks
-Xep:ReferenceEquality:ERROR

--
Stanimir

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

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:


[...]
Is there a way to specify these in a properties file and have each argument 
on its own line?


Have you tried using @file (a-la javadoc options):

https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files

--
Stanimir

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

Re: Others have posted on this but I think this time it's different.

[Stanimir Stamenkov]

Thu, 1 Jun 2023 18:49:59 +0300, /Stanimir Stamenkov/:

Thu, 1 Jun 2023 13:07:01 +, /Geoffry Roberts/:

[ERROR] Internal error: java.nio.file.InvalidPathException: Illegal 
char <:> at index 3: 
jar:file:\C:\Program%20Files\apache-maven-3.9.2\lib\maven-core-3.9.2.jar!\org\apache\maven\project -> [Help 1]


I see the error has to do with a ":".  "Index 3" implies 0=j 1=a 2=r 3=:


java.nio.file.InvalidPathException suggests it happens while processing 
the path part of the jar:file: URL, that is:


\C:\Program%20Files\...

I guess it complains about "\C:".


Nope, you appear correct it is about the "jar:" part:

Paths.get("\\C:\\Program%20Files");

java.nio.file.InvalidPathException: Illegal char <:> at index 2: 
\C:\Program%20Files


while:

Paths.get("jar:file:\\C:\\Program%20Files");

Illegal char <:> at index 3: jar:file:\C:\Program%20Files

--
Stanimir

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

Re: Others have posted on this but I think this time it's different.

[Stanimir Stamenkov]

Thu, 1 Jun 2023 13:07:01 +, /Geoffry Roberts/:


[ERROR] Internal error: java.nio.file.InvalidPathException: Illegal char <:> at 
index 3: 
jar:file:\C:\Program%20Files\apache-maven-3.9.2\lib\maven-core-3.9.2.jar!\org\apache\maven\project
 -> [Help 1]

I see the error has to do with a ":".  "Index 3" implies 0=j 1=a 2=r 3=:


java.nio.file.InvalidPathException suggests it happens while processing 
the path part of the jar:file: URL, that is:


\C:\Program%20Files\...

I guess it complains about "\C:".  What is really weird to me the file: 
URL uses backslashes instead of forward ones:


file:/C:/Program%20Files/...

--
Stanimir

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

Re: MalformedInputException: Input length = 1

[Stanimir Stamenkov]

Fri, 20 Jan 2023 13:38:32 +0200, /Delany/:


Hi Tom,
You can turn off filtering if you don't need it. The docs suggest having
separate folders for plaintext/binary resources
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html


The docs also mention a configuration to explicitly exclude certain file 
extensions from filtering:


https://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html

The plugin will prevent binary files filtering without adding some 
excludes configuration for the following file extensions jpg, jpeg, gif, 
bmp and png.


If you like to add supplemental file extensions this can simply achieved 
by using a configuration like the following:


  
org.apache.maven.plugins
maven-resources-plugin
3.3.0

  ...
  
pdf
swf
  
  ...

  


--
Stanimir

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

Re: testCompile with multiReleaseOutput main classes

[Stanimir Stamenkov]

Sun, 31 Jul 2022 14:18:52 +0300, /Stanimir Stamenkov/:

Sat, 23 Jul 2022 19:28:50 +0300, /Stanimir Stamenkov/:

I want to produce a Java 8 compatible library that provides some Java 
9+ classes, packaged as a Multi-Release JAR:


  * 
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html


O.k.  From the very same page:


*Challenges*

  * The Multi-Release: true attribute is only recognized when the 
classes are in a jar. In other words, you cannot test the classes put 
in target/classes/META-INF/versions/${release}/.


I may try adding target/classes/META-INF/versions/${release}/ as a 
test-resource directory using the build-helper-maven-plugin and see 
how far I could get it.


All right. Not using build-helper-maven-plugin this time around, just 
the maven-compiler-plugin:



default-testCompile



-Xbootclasspath/a:${project.build.outputDirectory}/META-INF/versions/9




and maven-surefire-plugin:



${project.build.outputDirectory}/META-INF/versions/9



It is working fine so far [1].  Then I've noticed if I add to the 
configuration of the maven-compiler-plugin:



default-testCompile

9
9


-Xbootclasspath/a:${project.build.outputDirectory}/META-INF/versions/9




the extra compiler arg stopped being effective, so I've though the 
compiler may have switched to a module path (vs. class path). So I've 
further tried:



default-testCompile

9
9

--patch-module

${module.name}=${project.build.outputDirectory}/META-INF/versions/9




and then I've observed the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile 
(default-testCompile) on project xbrz-core: Execution default-testCompile of goal 
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile failed: Cannot invoke 
"java.util.Map.get(Object)" because the return value of 
"org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is null -> 
[Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile ...
...
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.Map.get(Object)" 
because the return value of 
"org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is null
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
(AbstractCompilerMojo.java:1126)
at org.apache.maven.plugin.compiler.TestCompilerMojo.execute 
(TestCompilerMojo.java:183)
...

that looks more like a bug in the compiler plugin itself.

[1] https://github.com/stanio/xbrz-java/commit/9e0fdf03c

--
Stanimir

Remove .INVALID from my address to reply directly to me, but it is possibly 
best to reply just to the list.


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

Re: testCompile with multiReleaseOutput main classes

[Stanimir Stamenkov]

Sat, 23 Jul 2022 19:28:50 +0300, /Stanimir Stamenkov/:

I want to produce a Java 8 compatible library that provides some Java 9+ 
classes, packaged as a Multi-Release JAR:


  * https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html


O.k.  From the very same page:


*Challenges*

  * The Multi-Release: true attribute is only recognized when the 
classes are in a jar. In other words, you cannot test the classes put in 
target/classes/META-INF/versions/${release}/.


I may try adding target/classes/META-INF/versions/${release}/ as a 
test-resource directory using the build-helper-maven-plugin and see how 
far I could get it.


I've taken a slimmed down _Multi-Release Parent_ 
<http://www.russgold.net/sw/2018/04/easier-than-it-looks/> approach, and 
the main compilation and packaging seems just right:


The following may be of use to someone.  I've noticed the following 
shortcoming with the original configuration suggested in the given 
approach – the sources JAR and javadoc don't include the extra source 
compiled.  I've used the build-helper-maven-plugin [1] to add 
src/main/java9/ as source directory and adjusted the default-compile 
execution similarly to compile only the main sources:




default-compile

${base.java.version}


${project.build.sourceDirectory}





See: https://github.com/stanio/xbrz-java/commit/61b352e94

Also, I had to fix the javadoc tool version > base.java.version (which 
is fine):


  * https://github.com/stanio/xbrz-java/blob/da1264fbd/pom.xml#L131-L135


     
     maven-compiler-plugin
     3.10.1
     
     8
     8
     
     
     
     compile-java9
     compile
     
     compile
     
     
     9
     
     9
     
     
     
${project.basedir}/src/main/java9
     
     true
     
     
     
     
     
     maven-jar-plugin
     3.2.2
     
     
     
     true
     
     
     
     

Now I've added some test sources exercising the Java 9+ only classes, 
but the `testCompile` goal seems unable to find them.  Is it possible to 
configure the `default-testCompile` execution to see the classes from 
the `multiReleaseOutput` of the main compile?


[1] https://www.mojohaus.org/build-helper-maven-plugin/

--
Stanimir

Remove .INVALID from my address to reply directly to me, but it is 
probably best to reply just to the mailinig list.


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

testCompile with multiReleaseOutput main classes

[Stanimir Stamenkov]

I want to produce a Java 8 compatible library that provides some Java 9+ 
classes, packaged as a Multi-Release JAR:


 * https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

I've taken a slimmed down _Multi-Release Parent_ 
 approach, and 
the main compilation and packaging seems just right:



maven-compiler-plugin
3.10.1

8
8



compile-java9
compile

compile


9

9



${project.basedir}/src/main/java9

true





maven-jar-plugin
3.2.2



true





Now I've added some test sources exercising the Java 9+ only classes, 
but the `testCompile` goal seems unable to find them.  Is it possible to 
configure the `default-testCompile` execution to see the classes from 
the `multiReleaseOutput` of the main compile?


FWIW, my current work-in-progress could be seen at:

 * https://github.com/stanio/xbrz-java/commit/8c9564ee874

--
Stanimir


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

Re: JPMS – Test sources extra Java SE module dependencies

[Stanimir Stamenkov]

Thank you for the wonderful reference and summary, Daniel!

While I'm parsing the information along with all its references, indeed 
it seems a well-known path.  I'm glad people have taken it to that great 
extent, and have provided guidelines and solutions to newcomers like me.


– Stanimir


Sat, 02 Jul 2022 21:00:41 -0700, /Daniel Widdis/:


You are traveling a well-known path to many of us.

I highly recommend taking a look at junit-platform-maven-plugin:
https://github.com/sormuras/junit-platform-maven-plugin

Blog post outlining how to do what you'e doing is here:
https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html

TLDR:
1. you keep the one module-info.java in your main project
2. you add a module-info.test in your test directory with 
appropriate command line entries for add-opens (to see your source 
code) and add-reads (essentially replacing the additional 
"requires")



On 7/2/22, 4:46 PM, "Stanimir Stamenkov"  wrote:

 I can't figure out what's the best practice or just proper way for
 setting up a JPMS Maven project with test sources that have additional
 Java SE module dependencies to those of the main sources.
[...]


--

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

JPMS – Test sources extra Java SE module dependencies

[Stanimir Stamenkov]

I can't figure out what's the best practice or just proper way for 
setting up a JPMS Maven project with test sources that have additional 
Java SE module dependencies to those of the main sources.


I have the following basic project structure:

pom.xml
src/
├─ main/
│  └─ java/
│ ├─ module-info.java
│ └─ net/example/stanio/jpms/
│└─ HelloJPMS.java
└─ test/
   └─ java/
  └─ net/example/stanio/jpms/
 └─ HelloJPMSTest.java

The `module-info.java` is:

module net.example.stanio.jpms {
exports net.example.stanio.jpms;
}

That is the main sources don't have any dependencies other than 
`java.base`, but the tests use some JAXP (`java.xml`).


My `pom.xml` is like:


4.0.0

net.example.stanio
maven-jpms
0.0.1-SNAPSHOT

maven-jpms


UTF-8
9

true




junit
junit
4.13.2
test






   maven-compiler-plugin
   3.10.1





Running `mvn -V clean test` I'm getting:

```
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: C:\...
Java version: 11.0.12, vendor: Oracle Corporation, runtime: C:\...
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
...
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @ 
maven-jpms ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\...\maven-jpms\target\test-classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[7,17]
 package javax.xml.transform is not visible
  (package javax.xml.transform is declared in module jdk.pack, but module 
net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[8,27]
 package javax.xml.transform.sax is not visible
  (package javax.xml.transform.sax is declared in module jdk.pack, but module 
net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[9,27]
 package javax.xml.transform.sax is not visible
  (package javax.xml.transform.sax is declared in module jdk.pack, but module 
net.example.stanio.jpms does not read it)
[ERROR] 
/C:/.../maven-jpms/src/test/java/net/example/stanio/jpms/HelloJPMSTest.java:[10,27]
 package javax.xml.transform.stream is not visible
  (package javax.xml.transform.stream is declared in module jdk.pack, but 
module net.example.stanio.jpms does not read it)
[INFO] 4 errors
[INFO] -
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  2.668 s
[INFO] Finished at: 2022-07-03T01:49:22+03:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile 
(default-testCompile) on project maven-jpms: Compilation failure: Compilation 
failure:
...
```

So I've added `src/test/java/module-info.java` like:

module net.example.stanio.jpms {
requires java.xml;
requires junit;
}

that appears to have solved the test compilation failure.  Note, I had 
to re-declare the other test dependencies (junit), as well. I would 
really like to avoid that double dependency bookkeeping, and then having 
duplicated `module-info.java` completely breaks importing the project 
into Eclipse (m2e).


Is there an established approach to this (or similar) setup? Maybe I 
need to fiddle with the `default-testCompile` `` – haven't 
tried yet, but I've just seen this javac option:


  --add-modules (,)*
Root modules to resolve in addition to the initial modules, or all 
modules
on the module path if  is ALL-MODULE-PATH.

--
Stanimir



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

Re: How to avoid forking in a maven build?

[Stanimir Stamenkov]

Wed, 01 Jan 2020 03:14:25 +0100, /Steinar Bang/:

Karl Heinz Marbaise:


(The purpose of the javadoc aggregate is to get a javadoc jar
attached to the parent pom artifact, that I can link to with a javadoc
banner in the README.)


The question is also why running javadoc everytime?


Hm... I don't understand...? Could you clarify?


I guess it is more common to have the javadoc jar (and sources jar) 
packaged just with a "release" profile, speeding up development builds:


mvn package/verify/install (local build w/o javadoc and sources artifacts)

mvn -P release install (local build w/ javadoc and sources artifacts)

mvn -P release deploy (CI build w/ javadoc and sources artifacts)

--
Stanimir

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

Re: Configure default execution phase

[Stanimir Stamenkov]

Tue, 24 Dec 2019 09:34:05 -0600, /Jeff Jensen/:

Perhaps your specific example requires no further profile configuration, 
however, since a profile enables configuring many things and calling one 
goal/mojo is only one, Manfred generally suggests that it's no more effort 
to run a profile with multiple plugins configured than 1.


Perhaps this could help clarify the intended use case a bit – from my 
original post:


I don't want the plugin executed as part of the build but I want to be 
able to execute its goals explicitly.


And the example configuration I've given uses just  
section.  So no, I'm not interested into setting up a profile for an 
automated build.


--
Stanimir

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

Re: Configure default execution phase

[Stanimir Stamenkov]

Tue, 24 Dec 2019 17:27:18 +0100 (CET), /Manfred Moser/:


Typically a separate invocation like needing to update the data schema involves 
more than one plugin.

The best and most common example is a release profile. It often includes things 
like javadoc, signing, obfustcating, creating additional files and so on. And 
you just run it with a profile.


If you truly want to invoke only the one plugin, it wont matter. But in 
practice .. most of time it will be more than one plugin at a time.


In my use case the (liquibase) maven plugin is only used for 
development.  The development of a new database change generally 
involves multiple command invocations:


# Prepare source change
mvn liquibase:update
mvn liquibase:rollback
# Update the change in the source, then
mvn liquibase:updateTestingRollback

Rinse and repeat, and mix other goals into the cycle.  This would happen 
even if the plugin is otherwise programmed into a release profile.  So 
I've asked if it is possible to configure the default behavior to always 
execute process-resources phase with this plugin, but seems it is 
currently not.


--
Stanimir

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

Re: Configure default execution phase

[Stanimir Stamenkov]

Mon, 23 Dec 2019 21:43:36 +0100 (CET), /Manfred Moser/:


well... with using the profile you can add more plugins and all sorts of other 
stuff and the command will stay that long


I must admit I'm completely puzzled by your suggestion – why I would be 
adding all sorts of stuff gaining nothing but adding complexity to the 
build script.  Anyway, thanks for your comments.


--
Stanimir

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

Re: Configure default execution phase

[Stanimir Stamenkov]

Mon, 23 Dec 2019 18:16:13 +0100 (CET), /Manfred Moser/:


Just make a profile and add it all in there.


Are you suggesting adding something like:



liquibase-update



org.liquibase
liquibase-maven-plugin


process-resources

update









then using command like:

mvn process-resources -P liquibase-update

?

It doesn't appear shorter than:

mvn process-resources liquibase:update

and I guess I'll have to replicate the profile for all possible 
liquibase goals (possibly 5-10 of them).  All in all, it doesn't appear 
feasible unless I'm missing something with your suggestion?




Stanimir Stamenkov wrote on 2019-12-22 09:04 (GMT -08:00):


I'm having a POM like:

 
 
 
 
 org.liquibase
 liquibase-maven-plugin
 3.8.3
 
 ...
 
 
 
 
 

I don't want the plugin executed as part of the build but I want to be 
able to execute its goals [1] explicitly.  The goals get executed 
directly (no build phases get triggered), f.e.:


 mvn liquibase:update

but then it usually (while not necessarily, depending on project 
configuration) require "process-resources" to be completed, so I have to:


 mvn process-resources liquibase:update

Is it possible to trigger "process-resources" automatically via plugin 
configuration in POM (a`la Gradle's dependsOn [2]), or this is just 
hard-coded in the plugin itself?


[1] https://www.liquibase.org/documentation/maven/index.html
[2] https://docs.gradle.org/current/userguide/more_about_tasks.html


--
Stanimir

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

Re: Configure default execution phase

[Stanimir Stamenkov]

Mon, 23 Dec 2019 11:37:19 +0100, /Thomas Broyer/:


It's hardcoded in the plugin (and this is why you have things like
sources:jar and sources:jar-no-fork depending on how you need/want to
invoke it)


I see now – thanks for clarifying.  I've always wondered what those 
*-no-fork goals are for – I've thought it has to do something with 
forking the JVM process but seems I've been completely wrong. :-)  In 
any case, I think dynamic "executePhase" configuration would be really 
nice to have, the same way one could dynamically bind a goal to a 
specific phase.




Le dim. 22 déc. 2019 à 18:04, Stanimir Stamenkov a écrit :


I'm having a POM like:

  
  
  
  
  org.liquibase
  liquibase-maven-plugin
  3.8.3
  
  ...
  
  
  
  
  

I don't want the plugin executed as part of the build but I want to be
able to execute its goals [1] explicitly.  The goals get executed
directly (no build phases get triggered), f.e.:

  mvn liquibase:update

but then it usually (while not necessarily, depending on project
configuration) require "process-resources" to be completed, so I have to:

  mvn process-resources liquibase:update

Is it possible to trigger "process-resources" automatically via plugin
configuration in POM (a`la Gradle's dependsOn [2]), or this is just
hard-coded in the plugin itself?

[1] https://www.liquibase.org/documentation/maven/index.html
[2] https://docs.gradle.org/current/userguide/more_about_tasks.html


--
Stanimir

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

Configure default execution phase

[Stanimir Stamenkov]

I'm having a POM like:





org.liquibase
liquibase-maven-plugin
3.8.3

...






I don't want the plugin executed as part of the build but I want to be 
able to execute its goals [1] explicitly.  The goals get executed 
directly (no build phases get triggered), f.e.:


mvn liquibase:update

but then it usually (while not necessarily, depending on project 
configuration) require "process-resources" to be completed, so I have to:


mvn process-resources liquibase:update

Is it possible to trigger "process-resources" automatically via plugin 
configuration in POM (a`la Gradle's dependsOn [2]), or this is just 
hard-coded in the plugin itself?


[1] https://www.liquibase.org/documentation/maven/index.html
[2] https://docs.gradle.org/current/userguide/more_about_tasks.html

--
Stanimir

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

Re: is it safe to upgrade maven from v3.0.4 to v3.2.1 ?

[Stanimir Stamenkov]

Sat, 5 Apr 2014 22:45:59 -0700 (PDT), /ghostwolf59/:


Just wonder if I could expect issues to crop up by upgrading maven from
v3.0.4 to the most recent stable version available (v3.2.1 while writing
this)


Note sure if this could affect you:

https://jira.codehaus.org/browse/MNG-5591

(fixed for 3.2.2)

--
Stanimir

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

Re: Changes in how exclusions are applied transitively ?

[Stanimir Stamenkov]

[See my reply below the quote.]

Wed, 24 Jul 2013 20:20:49 +0200, /Grégory Joseph/:


I can't seem to find an accurate trace of this in the release notes,
so I thought I'd just ping the list - Changes in how exclusions are
applied transitively between Maven 2.2.1 and 3.1 ?

Here's a situation: A has dependencies on B and C. Both transitively
depend on D  (through X, which is irrelevant, I think)  but B excludes
it (on its dep declaration of X)

With 2.2.1, D was (wrongly imo) excluded from A (depending on
dependency order, seemingly)

With 3.1, it appears to behave correctly.

Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
where I need to work around the bug, currently by removing the
exclusions. That's currently OK, but at some point, those exclusions
will be re-added (in A or in a new project) and we'll face the same
issue again, without any clue as to why.

How have people dealt with this so far ?


I'm not sure I fully understand you, but I'm also stuck with Maven 
2.2.1 currently, and I've noticed when excluding a transitive 
dependency it excludes it from other dependencies which have it as a 
transitive dependency.  The other dependencies I don't want to 
exclude the transitive dependency from are either test or 
provided (needed only during build, actually).  To workaround this 
I've declared the dependency I want to exclude as provided in a 
'dependencyManagement' section, so it doesn't get included 
automatically in WAR and similar packages.  See if this approach 
might help you, too.


--
Stanimir

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

Re: Javadoc: single configuration

[Stanimir Stamenkov]

Mon, 3 Jun 2013 07:04:58 -0700 (PDT), /Evan/:


http://maven.apache.org/plugins/maven-javadoc-plugin/usage.html#Javadoc_Configuration


That section warns me that the behaviour is different, but not *how* it
differs. In the example at the bottom of that page the javadoc:javadoc uses
elements from the configuration defined in the build *and* reporting
sections:

|mvn javadoc:javadoc
|It will generate the Javadoc for private members (defined in build/)
|using the stylesheet (defined in reporting/), and with no help page
|(defined in build/).

This is the documented behaviour that I can not reproduce. ( mvn
javadoc:javadoc only looks at the configuration in the build section instead
of both build and reporting sections)


I see your point now.  The documentation, including at the linked:

http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_reporting_Tag_VS_build_Tag

states it should behave as you expect.  May be it is a bug in the 
javadoc plugin, but I can't say for sure.  Do you use the latest 
(2.9) plugin version?  Does it happen with Maven 2 or 3, or both?



Ultimately I'm trying to define the javadoc configuration once and have it
apply to all invocations of the javadoc plugin.


You may try defining the common configuration in a 
build/pluginManagement section, but again I don't know if it's 
supposed to work that way (for the reporting configuration).


--
Stanimir

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

Re: Copy an artifact with its transitive dependencies to a specified location

[Stanimir Stamenkov]

Mon, 3 Jun 2013 19:46:11 +0200, /Baptiste MATHUS/:


From my understanding of your need you should use dependency:get and use
destination parameter.


Seems like, but the transitive dependencies get only downloaded to 
the local repository and not copied to the specified `destination`, 
as far as I understand and as far as I've observed.



Dependency:copy-dependencies inadequately forces you to have a pom which I
understand you don't have.


I have a POM where I would like to include the given dependency goal 
at certain phase (like `package`), but the dependency I would like 
to set up (copying it to a specified location, including its 
transitive dependencies) is not a declared dependency in/of the POM.



There's a feature hole here that might be filled. Could you please file a
jira abt this so that it can be fixed?


I'll post back a reference.


I suppose we need to figure out where this feature would be located: either
by undeprecating destination param some way , either removing the
requirement for a maven pom for copy-deps or by creating a brand new goal.

Thanks a lot.


Le 2 juin 2013 17:13, Stanimir Stamenkov s7a...@netscape.net a écrit :


I want to copy an artifact with its transitive dependencies to a specified
location.  The artifact is not a dependency of the project the given build
step would be part of.

I've tried the copy goal of the maven-dependency-plugin [1], but it
doesn't have a transitive option.  I've also tried the get goal, but
its destination parameter is deprecated and after all it doesn't copy the
transitive dependencies to that destination.

I've also tried using the copy-dependencies goal by first declaring the
needed artifact as runtime dependency to the project, which I don't really
want to, and then specifying includeGroupIds and includeArtifactIds
parameters, but this is mostly the same as copy specifying all artifacts
explicitly, which I don't want to manually resolve and hard-code.

Is there an easy way to achieve what I'm after?

[1] http://maven.apache.org/plugins/maven-dependency-plugin/


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

Copy an artifact with its transitive dependencies to a specified location

[Stanimir Stamenkov]

I want to copy an artifact with its transitive dependencies to a 
specified location.  The artifact is not a dependency of the project 
the given build step would be part of.


I've tried the copy goal of the maven-dependency-plugin [1], but 
it doesn't have a transitive option.  I've also tried the get 
goal, but its destination parameter is deprecated and after all it 
doesn't copy the transitive dependencies to that destination.


I've also tried using the copy-dependencies goal by first 
declaring the needed artifact as runtime dependency to the project, 
which I don't really want to, and then specifying includeGroupIds 
and includeArtifactIds parameters, but this is mostly the same as 
copy specifying all artifacts explicitly, which I don't want to 
manually resolve and hard-code.


Is there an easy way to achieve what I'm after?

[1] http://maven.apache.org/plugins/maven-dependency-plugin/

--
Stanimir

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

Re: Javadoc: single configuration

[Stanimir Stamenkov]

Fri, 31 May 2013 17:14:31 -0400, /Evan Ward/:


I'm trying to configure the javadoc report plugin so that I get the same
output with `mvn javadoc:jar` and `mvn site`. I've read the usage page
[1] which suggests that configuring the plugin in the reporting
section will apply the same configuration to the javadoc:jar invocation.


Hm, I fail to find such reference, and I'm actually reading `mvn 
site` and `mvn javadoc:javadoc` behave differently, given they are 
configured in different sections (reporting vs. build):


| IMPORTANT NOTE: configuring the Javadoc plugin in the
| reporting/ or build/ elements in the pom have NOT the same
| behavior as described in the Guide to Configuring Plug-ins.


[1]
http://maven.apache.org/plugins/maven-javadoc-plugin/usage.html#Javadoc_Configuration


--
Stanimir

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

Re: [ANN] Maven Compiler Plugin 3.1 Released

[Stanimir Stamenkov]

Mon, 15 Apr 2013 22:10:19 +1000, /Olivier Lamy/:


+  excludes
+exclude**/package-info.java/exclude
+  /excludes
[...]
As all package-info.java files never go to
${project.build.outputDirectory} a compilation is triggered.


This is really untrue generally and in all cases, and I can't accept 
the proposed solution as serious.


--
Stanimir

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

Re: [ANN] Maven Compiler Plugin 3.1 Released

[Stanimir Stamenkov]

Sat, 13 Apr 2013 20:55:17 +0300, /Stanimir Stamenkov/:

Thu, 11 Apr 2013 23:38:17 -0500, /Wayne Fay/:


I'm not sure it could be a clue but it happens for some (I haven't
verified all) WAR modules.

[...]
Is this a project you can share via Github? Or can you make a
sample that
(consistently) exhibits the behavior, and share just that part?


All right.  Doesn't appear WAR-related, but consistently happens if
there are package-info.java files with no annotations (at least
@Retention(RUNTIME) ones) to cause a package-info.class generated
in the target/classes directory.


I don't use Git but here's a Hg source:

https://bitbucket.org/stanio/maven-compiler-sample

One could download a zipped bundle from:

https://bitbucket.org/stanio/maven-compiler-sample/downloads

(select Tags or Branches)

--
Stanimir

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

Re: [ANN] Maven Compiler Plugin 3.1 Released

[Stanimir Stamenkov]

Thu, 11 Apr 2013 23:38:17 -0500, /Wayne Fay/:


I'm not sure it could be a clue but it happens for some (I haven't
verified all) WAR modules.


What code are you compiling in a WAR module? Best practice says to move the
Java code to a Jar module. Are you precompiling jsps with jspc or ...?


No JSPs or the like.  It's a WAR module with JAX-RS classes 
implementing REST services.  If we move the Java code to a JAR 
module, the WAR would become pretty much hollow.  I don't think I 
like having extra modules, as a workaround.  We already have some of 
the Java code (the client interfaces) in a JAR which is meant for 
inclusion elsewhere, besides the WAR.



Is this a project you can share via Github? Or can you make a sample that
(consistently) exhibits the behavior, and share just that part?


Unfortunately I can't share the code, but I'll try to make a minimal 
sample which consistently exhibits the behavior.


--
Stanimir

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

Re: [ANN] Maven Compiler Plugin 3.1 Released

[Stanimir Stamenkov]

Thu, 11 Apr 2013 23:38:17 -0500, /Wayne Fay/:


I'm not sure it could be a clue but it happens for some (I haven't
verified all) WAR modules.

[...]
Is this a project you can share via Github? Or can you make a sample that
(consistently) exhibits the behavior, and share just that part?


All right.  Doesn't appear WAR-related, but consistently happens if 
there are package-info.java files with no annotations (at least 
@Retention(RUNTIME) ones) to cause a package-info.class generated 
in the target/classes directory.


I think I had seen this exact case not causing recompilation before, 
but may be it was just those package-info.java files recompiled.


--
Stanimir

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

Re: [ANN] Maven Compiler Plugin 3.1 Released

[Stanimir Stamenkov]

Mon, 8 Apr 2013 20:15:15 +1000, /Olivier Lamy/:


Release Notes - Apache Maven 2.x Compiler Plugin - Version 3.1

** Bug
 * [MCOMPILER-187] - incremental stuff detect changes even if
nothing has changed means too much compilation


I'm not sure it is the same, but it seems I'm still observing 
instance of this.  I perform `mvn clean compile`, then immediately 
`mvn compile` after it and I still see:


[INFO] Changes detected - recompiling the module!

It doesn't appear for all modules I've tried with, though.  I'm not 
sure it could be a clue but it happens for some (I haven't verified 
all) WAR modules.


--
Stanimir

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

Re: Manifest

[Stanimir Stamenkov]

Sat, 5 Jan 2013 14:58:45 -0800, /Rajwinder Makkar/:


How can i pass property/value pair a part of maven build process on the
command line which insert things in manifest file ? Something like mvn
clean install --manifestdefineproperty property=value


Note, depending on the purpose of this property you might not be 
doing something considered a good practice, but I can say from the 
description you've given.


On the command-line you should be able to set a system property like:

mvn -Dproperty=value ...

and then refer ${property} in the archive configuration.  One should 
be able to set the necessary property in his settings.xml [1], in 
a profile active by default [2], also.  In any case, you might want 
to add enforcer configuration to verify the necessary property has 
been set:


http://maven.apache.org/enforcer/maven-enforcer-plugin/
http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html

[1] http://maven.apache.org/settings.html#Properties
[2] http://maven.apache.org/settings.html#Activation

--
Stanimir

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

Re: Manifest

[Stanimir Stamenkov]

Sun, 06 Jan 2013 23:46:05 +0200, /Stanimir Stamenkov/:


Note, depending on the purpose of this property you might not be
doing something considered a good practice, but I can say from the
description you've given.


I've really meant to say: ... but I *can't* say from the 
description you've given.


--
Stanimir

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

Attached artifacts and dependencies

[Stanimir Stamenkov]

Is it true attached artifacts, that is artifacts with a non-empty 
classifier, inherit their dependencies from the main artifact? 
Stated otherwise - is it possible to specify different set of 
dependencies for an attached artifact such that when included in 
another project, that different set of dependencies get resolved for 
it, instead of the dependencies declared for the main artifact?


It doesn't really matter for many of the commonly attached artifacts 
like sources and javadoc, or the main set of dependencies is 
just fine for classes (of a WAR), but here are some cases it makes 
sens if the dependencies for an attached artifact could be specified 
differently from the main one:


1. jar-with-dependencies - an assembly packaging all required 
dependencies in the JAR, already.  In this case no dependencies 
should be resolved for such an artifact, I guess;


2. client - such as produced by the EJB plugin [1].  In this case 
resolving all dependencies from the main implementation is not 
desired.  Adding some runtime dependencies for the attached 
client, not declared for the main implementation, may be desired too.


So is achieving different set of dependencies possible with using 
attached artifacts vs. just different artifacts?


[1] 
http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html


--
Stanimir

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

Re: Attached artifacts and dependencies

[Stanimir Stamenkov]

Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/:


If the dependencies are not applicable for this artifact (e.g. the pom is
not valid for it because it is generated against Maven convention) then it
should not be an artifact in the same coordinates but rather be a
different module with different GAV coordinates


All right.  That's pretty much what I've thought, but then revisit 
the EJB plugin case I've given:


http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html

Seems like not the best practice - why it has been introduced, then?

--
Stanimir

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

Re: Attached artifacts and dependencies

[Stanimir Stamenkov]

Sat, 5 Jan 2013 23:52:50 +0100, /Anders Hammar/:


I always argue for having the API (e.g. ejb client) as a separate module
and then the impl (e.g. the ejb) as a separate module.


That's what we're using after all, but I've recently discovered this 
ejb-client option and started wondering if there's something I'm 
missing about how things are supposed to work/be used.


--
Stanimir

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

Re: How to include WAR dependency in project

[Stanimir Stamenkov]

Tue, 1 May 2012 11:44:27 -0700, /Daivish Shah/:


I have following dependency declared in my UNIT Testing module project.

dependency
groupIdsample-project-ws/groupId
artifactIdsample-project-ws/artifactId
version${project.version}/version
typewar/type
scopetest/scope
/dependency
[...]


If you control the POM of sample-project-ws you could produce 
additional 'classes' jar artifact:


http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses

which you could then refer to as dependency from other modules:

dependency
groupIdsample-project-ws/groupId
artifactIdsample-project-ws/artifactId
version${project.version}/version
classifierclasses/classifier
scopetest/scope
/dependency

--
Stanimir

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

Re: Configure 'finalName' pattern for all child modules

[Stanimir Stamenkov]

Wed, 12 Oct 2011 17:42:59 -0700, /Manfred Moser/:

11-10-12 05:30 PM, Yuen-Chi Lian wrote:


 parent
 groupIdy/groupId
 artifactIdx/artifactId
 versionv/version
 relativePath../parent/relativePath


  Dont use relative path  ...


Why it is not good?  I ask because the m2e plugin for Eclipse 
automatically generates:


  parent
...
relativePath../relativePath
  /parent

for new child modules.  As far as I understand the above is the 
default - is there a difference if it is specified explicitly?


--
Stanimir

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

Re: Activate profile with property set in a file

[Stanimir Stamenkov]

Fri, 14 Oct 2011 09:35:26 +0200, /Jörg Schaible/:


Any property used
to activate a profile must be given on the command line or be defined in the
settings.xml.


Thanks.  That confirms my suspicions.  The point I want properties 
read from external file, but not settings.xml, is to maintain a 
configuration specific to a project.  Using setting.xml for all 
projects could cause conflicts if two projects use the same named 
property for different purposes, or one just wants two projects 
configured differently.  Having to always specify the properties on 
the command-line is not the best convenience, also.


--
Stanimir

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

Re: Activate profile with property set in a file

[Stanimir Stamenkov]

Sat, 15 Oct 2011 19:45:25 +0200, /Ansgar Konermann/:

Am 15.10.2011 18:35 schrieb Stanimir Stamenkov:


The point I want properties read
from external file, but not settings.xml, is to maintain a configuration
specific to a project.  Using setting.xml for all projects could cause
conflicts if two projects use the same named property for different
purposes, or one just wants two projects configured differently.  Having to
always specify the properties on the command-line is not the best
convenience, also.


You could use project specific settings.xml, using command line switch -s.
Not sure if this fits your use case though.


Thanks.  I haven't realized it is possible.  My ultimate goal is not 
having to specify anything more than 'mvn 
clean/compile/package/install' on the command-line, but if it's not 
otherwise possible specifying '-s settings.xml' additionally could 
be bearable.


--
Stanimir

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

Activate profile with property set in a file

[Stanimir Stamenkov]

I'm trying to activate a build profile in a project, like:

  profiles
profile
  idunpack/id
  activation
property
  namedev.explode/name
  valueyes/value
/property
  /activation
  build
pluginManagement
  plugins
...
  /plugins
/pluginManagement
  /build
/profile
  /profiles

Specifying the system property on the command-line like:

mvn package -D dev.explode=yes

seems to trigger the profile o.k. but I would like to have that 
configured in a build.properties file which gets read by the build. 
 So I've tried the Properties Maven Plugin [1] by including it in 
the default build:


  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
version1.0-alpha-2/version
executions
  execution
phaseinitialize/phase
goals
  goalread-project-properties/goal
/goals
configuration
  files
filebuild.properties/file
  /files
/configuration
  /execution
/executions
  /plugin

I didn't appear to have any effect and I've realized project and 
system properties might be different beasts, and trying to include 
the property like:


  properties
dev.explodeyes/dev.explode
  /properties

didn't change anything - the profile doesn't get activated.  I've 
further tried moving the execution of the properties plugin to the 
validate phase, and using its set-system-properties goal:


  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
version1.0-alpha-2/version
executions
  execution
phasevalidate/phase
goals
  goalset-system-properties/goal
/goals
configuration
  properties
property
  namedev.explode/name
  valueyes/value
/property
  /properties
/configuration
  /execution
/executions
  /plugin

with no luck.  Does one have experience with using external 
properties file for the purposes of configuring the activation of 
profiles?


[1] http://mojo.codehaus.org/properties-maven-plugin/

--
Stanimir

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

Configure 'finalName' pattern for all child modules

[Stanimir Stamenkov]

I want to configure the 'finalName' for a parent module and all its 
child modules as:


build
finalName${artifactId}/fileName
/build

Is there a way to configure this as a default pattern in the parent 
and avoid repeating it in the 'build' section for all child modules?


--
Stanimir

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

Re: Configure 'finalName' pattern for all child modules

[Stanimir Stamenkov]

Thu, 13 Oct 2011 08:30:49 +0800, /Yuen-Chi Lian/:


Yes. Have you tried?

$ cat parent/pom.xml | grep finalName

finalName${project.artifactId}-${project.version}-b${buildNumber}/finalName


Ah, yes - thank you.  I've already tried it before but for some 
reason I had determined it doesn't work, but seems I've been wrong.


--
Stanimir

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

Re: Maven Compiler Plugin - Incremental compile problem -- because of directory structure.

[Stanimir Stamenkov]

Fri, 23 Sep 2011 14:12:00 -0400, /Gupta, Narendra/:


1. I have following directory for java source code

--lion

  --com

   test1 --  contains pom.xml and java source code with package
com.test1

   test2 -  contains pom.cml and java source code with pakage
com.test2

when compiler plugin compiles it does directory scanning and compiles
only java code that are modified from previous build. But In above
directory structure case it is recompiles the all source code in
subsequent builds. How to overcome this ? I found that it is because of
basedirectory do not follow maven standard direcotry layout. Please
advise.


It is not a recommended practice but we use it as workaround for one 
of our core modules which has multiple source directories and we 
haven't yet retrofitted to a standard Maven layout.


Set the source directory to test1 and then add test2 using the 
Build Helper Maven Plugin:


http://mojo.codehaus.org/build-helper-maven-plugin/

http://mojo.codehaus.org/build-helper-maven-plugin/usage.html

--
Stanimir

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

Re: Git or Mercurial

[Stanimir Stamenkov]

Wed, 6 Jul 2011 13:00:00 +0800, /Ben Caradoc-Davies/:


Mercurial allegedly has some space-performance problems handling
renames of directories, which end up doubling the space used in the
repo. This might make the current implementation inefficient for
large projects.
http://evadeflow.com/2011/04/why-not-mercurial/


Mercurial 1.9 already includes support to improve the situation in 
that direction 
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_1.9_.282011-07-01.29:



1.1. Major features

  * Experimental generaldelta storage scheme


--
Stanimir

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

Artifact[ejb:org.jboss.seam:jboss-seam] is not a dependency of the project.

[Stanimir Stamenkov]

Could someone tell me what's wrong with the attached POM.  It 
should basically build an EAR with application.xml defining 
jboss-seam as only EJB module.  The problem is I'm getting:

$ mvn package
[INFO] Scanning for projects...
[INFO] 
[INFO] Building seam-ear
[INFO]task-segment: [package]
[INFO] 
[INFO] [ear:generate-application-xml {execution: 
default-generate-application-xml}]
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Artifact[ejb:org.jboss.seam:jboss-seam] is not a dependency of the 
project.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time:  1 second
[INFO] Finished at: Sun Jun 26 12:46:16 EEST 2011
[INFO] Final Memory: 8M/154M
[INFO] 

I've really included jboss-seam as a dependency and I even expect 
I don't need to define it as ejbModule in the EAR plugin 
configuration, as it is already declared as packagingejb/packaging, 
but without defining it as ejbModule it ends up packaged as 
ordinary lib and not included in the application.xml (this might 
be related to the main problem).

I'm using Maven 2.2.1 on Windows.

-- 
Stanimir
?xml version=1.0 encoding=UTF-8 ?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion

groupIdnet.example.ear/groupId
artifactIdseam-ear/artifactId
version0.0.1-SNAPSHOT/version
packagingear/packaging

nameseam-ear/name

build
finalName${project.artifactId}/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
version5/version
defaultLibBundleDirlib/defaultLibBundleDir
fileNameMappingno-version/fileNameMapping
modules
ejbModule
groupIdorg.jboss.seam/groupId
artifactIdjboss-seam/artifactId
/ejbModule
/modules
/configuration
/plugin
/plugins
/build

dependencies
dependency
groupIdorg.jboss.seam/groupId
artifactIdjboss-seam/artifactId
version2.0.2.SP1/version
!-- typeejb/type --
/dependency
/dependencies

repositories
repository
idpublic-jboss/id
urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url
/repository
/repositories

/project


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

Re: Artifact[ejb:org.jboss.seam:jboss-seam] is not a dependency of the project.

[Stanimir Stamenkov]

Sun, 26 Jun 2011 12:59:10 +0300, /Stanimir Stamenkov/:

I've really included jboss-seam as a dependency and I even 
expect I don't need to define it as ejbModule in the EAR plugin 
configuration, as it is already declared as 
packagingejb/packaging, but without defining it as ejbModule 
it ends up packaged as ordinary lib and not included in the 
application.xml (this might be related to the main problem).


O.k.  I've tried with my own EJB module and I've found I have to 
specify typeejb/type for the dependency to get automatically 
included as EJB module in the EAR.  So the attached pom.xml 
appears to build as expected.


However I seem to get problem when jboss-seam is declared in 
dependencyManagement in a parent POM.  Place the attached 
parent-pom.xml and ear-pom.xml in a same directory (the same 
happens using standard layout having the EAR pom.xml in a child 
directory) and build using either one of them:


$ mvn -f parent-pom.xml install

or

$ mvn -f ear-pom.xml install

I get:

[INFO] Scanning for projects...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: net.example.ear:seam-ear
POM Location: ...\ear-pom.xml
Validation Messages:

[0]  'dependencies.dependency.version' is missing for 
org.jboss.seam:jboss-seam:ejb


Reason: Failed to validate POM for project net.example.ear:seam-ear at 
...\ear-pom.xml

Specifying the jboss-seam version additionally in the EAR POM 
seems to fix the things, but why one has to do it given the version 
is specified in the parent POM?


--
Stanimir
?xml version=1.0 encoding=UTF-8 ?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion

groupIdnet.example.ear/groupId
artifactIdseam-ear/artifactId
version0.0.1-SNAPSHOT/version
packagingear/packaging

nameseam-ear/name

build
finalName${project.artifactId}/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
version5/version
defaultLibBundleDirlib/defaultLibBundleDir
fileNameMappingno-version/fileNameMapping
/configuration
/plugin
/plugins
/build

dependencies
dependency
groupIdorg.jboss.seam/groupId
artifactIdjboss-seam/artifactId
version2.0.2.SP1/version
typeejb/type
/dependency
/dependencies

repositories
repository
idpublic-jboss/id
urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url
/repository
/repositories

/project
?xml version=1.0 encoding=UTF-8 ?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion

groupIdnet.example.ear/groupId
artifactIdseam-ear-parent/artifactId
version0.0.2-SNAPSHOT/version
packagingpom/packaging

nameseam-ear-parent/name

modules
module./ear-pom.xml/module
/modules

properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
ejb.ejbVersion3.0/ejb.ejbVersion
jboss.seamVersion2.0.2.SP1/jboss.seamVersion
/properties

build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
version2.3/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
/plugin
/plugins
/pluginManagement
/build

dependencyManagement
dependencies
dependency
groupIdorg.jboss.seam/groupId
artifactIdjboss-seam/artifactId
version${jboss.seamVersion}/version
!-- typeejb/type --
/dependency
/dependencies
/dependencyManagement

repositories
repository
idpublic-jboss/id
urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url
/repository

Re: Artifact[ejb:org.jboss.seam:jboss-seam] is not a dependency of the project.

[Stanimir Stamenkov]

Sun, 26 Jun 2011 16:00:35 +0300, /Stanimir Stamenkov/:


O.k. I've tried with my own EJB module and I've found I have to
specify typeejb/type for the dependency to get automatically
included as EJB module in the EAR. So the attached pom.xml appears
to build as expected.

However I seem to get problem when jboss-seam is declared in
dependencyManagement in a parent POM.
[...]
Specifying the jboss-seam version additionally in the EAR POM
seems to fix the things, but why one has to do it given the version
is specified in the parent POM?


So, as far as I've been able to find out, I have to declare 
typeejb/type in the dependencyManagement of the parent POM and 
in every child POM I refer to the given dependency.  This appears 
mentioned in Introduction to the Dependency Mechanism - Dependency 
Management 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management:



NOTE: In two of these dependency references, we had to specify the
type/ element. This is because the minimal set of information for
matching a dependency reference against a dependencyManagement
section is actually {groupId, artifactId, type, classifier}...


This makes me wonder how Maven distinguish between ejb and jar 
types (they are both packaged as JARs)?


--
Stanimir

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

Dependency transitivity - compilation vs. packaging

[Stanimir Stamenkov]

As far as I've found, currently it is not possible to specify a 
dependency scope which will cause a dependency normally packaged 
along with its compile scope dependencies in a final product like 
EAR, but will not resolve its compile scope dependencies when 
compiling the project which includes it as dependency.  That's it, I 
would like to use the APIs provided by a given dependency, but I 
don't want to allow compiling against APIs provided by its 
implementation dependencies (unless given as dependencies 
explicitly), and then I want those implementation dependencies 
packaged automatically in a final product.


I hope I've explained it good enough.  Is what I'm after currently 
possible?  If not, has this been thought about before?


--
Stanimir

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

Re: Dependency transitivity - compilation vs. packaging

[Stanimir Stamenkov]

Wed, 22 Jun 2011 15:07:02 -0700, /Manfred Moser/:


Use a dependency to the api with provided scope on jar or whatever code
projects you have.

And then use the implementation of the api as dependency on the ear.


Yeah, that's exactly what I'm currently doing, but it easily becomes 
a nightmare with a larger project with large amount of modules, with 
even larger amount of dependencies - tracking and declaring 
explicitly the dependencies of these dependencies for packaging.  I 
want to avoid specifying implementation detail dependencies for 
packaging (which may change in a next version of the main 
dependency).  As far as I'm aware Maven encourages the practice of 
don't repeat yourself and the given solution obviously involves a 
lot of repetitions (in terms of dependency declarations).


Say I have an EJB module which depends on the X dependency which 
itself depends on DOM4J for certain parts of its implementation.  I 
don't want to allow my EJB module using DOM4J APIs, but I want this 
dependency automatically packaged in an EAR which packages my EJB 
module.  I think this is quite important part of the dependency 
transitivity for it to be useful.


--
Stanimir

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