Maven Resolver Ant task - debug option

[Rune Gellein]

Hi,
I have managed to get maven resolver ant tasks to work.  I have some
problems on some build servers and would like to run effectively mvn -X.  Is
it possible to enable debug mode when using resolver ant tasks?

Alternatively is it some way of reading which settings.xml it is using? E.g.
in a property ref I can echo in the ant script?

regards,
Rune



--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html

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

Re: missing dependency version

[Rune Gellein]

Thanks for your reply, Mark.

Seeing that path to that jaxb jar made me check my maven config again. 
Turns out I had the repository duplicated.  I thought I was using one in [my
user]/.m2, but as the path shows it is actually in [my user]/m

The pm file it was using in the 'm' repository had some HTML failure content
instead of the actual pom content for that jar.  Hence the error.  I had
checked the pom in the other repo many times and found it correct.
My build works now with correct settings.xml.


Rune



--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html

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

Re: Getting started with Resolver Ant Tasks

[Rune Gellein]

I found an article on  codesaying
  to help build a fat
jar with all its dependencies.

Might be an idea to include something like that on the resolver ant task
page on apache.org

regards,
Rune



--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html

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

Re: Best Practice for distributing test utilities?

[Nick Stolwijk]

Put the testutils and the tests in the same project as foo in src/test/java
and make the tests package private (JUnit Jupiter). Other projects can
depend on the test artifact of foo and only use the test-utils.

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Fri, Mar 13, 2020 at 12:01 PM Zak Mc Kracken 
wrote:

> On 12/03/2020 13:55, Andreas Sewe wrote:
>
> If the test utilities are simple enough and are somehow specific to foo,
> I would put them into foo, under src/main/java, in a package like
> com.foo.testing. If they are more general, so that they could be used to
> write tests for some other package not related to foo, I would create a
> test-utils module. For instance, a utility to verify that an SQL string
> parameter yields a given result parameter would go into such a module.
>
> If the test utils so complex that foo would become too big and would
> drag too many not-often-used dependencies, but they're foo-specific, I
> would create the module foo-test-utils and both foo and foo-testing
> would depend on it. This is similar to creating test-utils.
>
> Option 3 creates a circular dependency and it's not to clean anyway
> (even if you had a way to remove the circularity from the technical
> point of view, it would remain at conceptual level). Attaching tests
> seems to be less clear and forces a dependant to link all the tests just
> to be able to include some utility. I happened to do it only for already
> existing and hard-to-refactor projects, and only for the purpose making
> the dependant extract some common files inside test/resources.
>
> Hope it helps,
> Marco
>
> > 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] 
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Best Practice for distributing test utilities?

[Zak Mc Kracken]

On 12/03/2020 13:55, Andreas Sewe wrote:

If the test utilities are simple enough and are somehow specific to foo, 
I would put them into foo, under src/main/java, in a package like
com.foo.testing. If they are more general, so that they could be used to 
write tests for some other package not related to foo, I would create a
test-utils module. For instance, a utility to verify that an SQL string 
parameter yields a given result parameter would go into such a module.


If the test utils so complex that foo would become too big and would 
drag too many not-often-used dependencies, but they're foo-specific, I 
would create the module foo-test-utils and both foo and foo-testing 
would depend on it. This is similar to creating test-utils.


Option 3 creates a circular dependency and it's not to clean anyway 
(even if you had a way to remove the circularity from the technical 
point of view, it would remain at conceptual level). Attaching tests 
seems to be less clear and forces a dependant to link all the tests just 
to be able to include some utility. I happened to do it only for already 
existing and hard-to-refactor projects, and only for the purpose making 
the dependant extract some common files inside test/resources.


Hope it helps,
Marco


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] 




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

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?

[Anders Hammar]

You need to remove the compile time dependency from foo-test-utils to foo.
Obviously you will have a runtime dependency, but that's ok. One simple way
is to use reflection in foo-test-utils when instantiating the Foo object.
Not pretty, but a simple solution. There are more elegant solutions but
they could be overkill in this case.

/Anders

On Fri, Mar 13, 2020 at 10:29 AM Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> 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
>
>

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

RE: Problem with the maven-compiler-plugin

[Nelligan, Steven M]

Thank you for the feedback.

I should have been using –verbose not –version.  When using –verbose the plugin 
is working as expected.

Thank you for your time.


From: Thomas Broyer 
Sent: Friday, March 13, 2020 3:02 AM
To: Maven Users List 
Subject: Re: Problem with the maven-compiler-plugin

What is it that you think is not working?

(fwiw, javaP -version prints the version of javaP, not the version the class 
was compiled with/to; that would be a 51.0 or similar anyway, not a 1.7)
Le ven. 13 mars 2020 à 08:26, Nelligan, Steven M 
mailto:snell...@illinois.edu>> a écrit :
It appears that the maven-compiler-plugin is not working or I am doing 
something wrong.

I have the following in the POM file.



org.apache.maven.plugins
maven-compiler-plugin
3.8.1

true
1.7
1.7
1.7






MAVEN INFORMATION:
C:\dev\Projects\accountentry_js22>mvn -version
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 
2019-08-27T10:06:16-05:00)
Maven home: C:\Program Files\apache-maven-3.6.2\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Default JAVA INFORMATION:
C:\dev\Projects\accountentry_js22>java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)

MVN Command:
mvn clean install –U
(see attached mvn_output.txt which contains the maven output)

JAVAP returns the following:

C:\dev\Projects\accountentry_js22\target\classes\edu\uiuc\fs\accountentry>javaP 
-version AccountContainer.class
1.8.0_242
Compiled from "AccountContainer.java"
public interface edu.uiuc.fs.accountentry.AccountContainer {
  public abstract void 
setSelectedFundingCode(org.apache.wicket.ajax.AjaxRequestTarget, 
java.lang.String);
  public abstract java.lang.String getSelectedFundingCode();
  public abstract java.lang.String getCollegeCode();
  public abstract java.lang.String getDeptCode();
  public abstract boolean showFSPays();
}



Steven M Nelligan
APPLICATION DEVELOPER

Facilities and Services
Information Technology Services
University of Illinois at Urbana-Champaign
Facilities and Services
1501 S. Oak Street | M/C 800
Champaign, IL 61820
217.244.8097 | other: 217.244.8097 | 
snell...@illinois.edu
www.fs.illinois.edu

[facebook]
[twitter]  [instagram] 
 [youtube] 


[https://webtools.illinois.edu/webservices/js/ds/signature_logo.png]

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.



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

Re: Problem with the maven-compiler-plugin

[Thomas Broyer]

What is it that you think is not working?

(fwiw, javaP -version prints the version of javaP, not the version the
class was compiled with/to; that would be a 51.0 or similar anyway, not a
1.7)

Le ven. 13 mars 2020 à 08:26, Nelligan, Steven M  a
écrit :

> *It appears that the maven-compiler-plugin is not working or I am doing
> something wrong.*
>
>
>
> *I have the following in the POM file.*
>
> 
>
> 
>
> 
>
> org.apache.maven.plugins
>
> maven-compiler-plugin
>
> 3.8.1
>
> 
>
> true
>
> 1.7
>
> 1.7
>
> 1.7
>
> 
>
> 
>
> 
>
> 
>
>
>
>
>
> *MAVEN INFORMATION:*
>
> C:\dev\Projects\accountentry_js22>mvn -version
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-27T10:06:16-05:00)
>
> Maven home: C:\Program Files\apache-maven-3.6.2\bin\..
>
> Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.7.0_80\jre
>
> Default locale: en_US, platform encoding: Cp1252
>
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>
>
>
> *Default JAVA INFORMATION:*
>
> C:\dev\Projects\accountentry_js22>java -version
>
> openjdk version "1.8.0_242"
>
> OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
>
> OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)
>
>
>
> *MVN Command:*
>
> mvn clean install –U
>
>
> (see attached mvn_output.txt which contains the maven output)
>
>
>
> *JAVAP returns the following:*
>
>
>
> C:\dev\Projects\accountentry_js22\target\classes\edu\uiuc\fs\accountentry>javaP
> -version AccountContainer.class
>
> 1.8.0_242
>
> Compiled from "AccountContainer.java"
>
> public interface edu.uiuc.fs.accountentry.AccountContainer {
>
>   public abstract void
> setSelectedFundingCode(org.apache.wicket.ajax.AjaxRequestTarget,
> java.lang.String);
>
>   public abstract java.lang.String getSelectedFundingCode();
>
>   public abstract java.lang.String getCollegeCode();
>
>   public abstract java.lang.String getDeptCode();
>
>   public abstract boolean showFSPays();
>
> }
>
>
>
>
>
>
>
> *Steven M Nelligan*
> *APPLICATION DEVELOPER*
>
>
> Facilities and Services
>
> Information Technology Services
> University of Illinois at Urbana-Champaign
> Facilities and Services
> 1501 S. Oak Street | M/C 800
> Champaign, IL 61820
> 217.244.8097 | *other*: 217.244.8097 | snell...@illinois.edu
> www.fs.illinois.edu
>
> [image: facebook]
> [image:
> twitter] [image: instagram]
> [image: youtube]
> 
>
> [image: https://webtools.illinois.edu/webservices/js/ds/signature_logo.png]
> 
>
> *Under the Illinois Freedom of Information Act any written communication
> to or from university employees regarding university business is a public
> record and may be subject to public disclosure.*
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

Problem with the maven-compiler-plugin

[Nelligan, Steven M]

It appears that the maven-compiler-plugin is not working or I am doing 
something wrong.

I have the following in the POM file.



org.apache.maven.plugins
maven-compiler-plugin
3.8.1

true
1.7
1.7
1.7






MAVEN INFORMATION:
C:\dev\Projects\accountentry_js22>mvn -version
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 
2019-08-27T10:06:16-05:00)
Maven home: C:\Program Files\apache-maven-3.6.2\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

Default JAVA INFORMATION:
C:\dev\Projects\accountentry_js22>java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)

MVN Command:
mvn clean install -U
(see attached mvn_output.txt which contains the maven output)

JAVAP returns the following:

C:\dev\Projects\accountentry_js22\target\classes\edu\uiuc\fs\accountentry>javaP 
-version AccountContainer.class
1.8.0_242
Compiled from "AccountContainer.java"
public interface edu.uiuc.fs.accountentry.AccountContainer {
  public abstract void 
setSelectedFundingCode(org.apache.wicket.ajax.AjaxRequestTarget, 
java.lang.String);
  public abstract java.lang.String getSelectedFundingCode();
  public abstract java.lang.String getCollegeCode();
  public abstract java.lang.String getDeptCode();
  public abstract boolean showFSPays();
}



Steven M Nelligan
APPLICATION DEVELOPER

Facilities and Services
Information Technology Services
University of Illinois at Urbana-Champaign
Facilities and Services
1501 S. Oak Street | M/C 800
Champaign, IL 61820
217.244.8097 | other: 217.244.8097 | 
snell...@illinois.edu
www.fs.illinois.edu

[facebook]
[twitter]  [instagram] 
 [youtube] 


[https://webtools.illinois.edu/webservices/js/ds/signature_logo.png]

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.


C:\dev\Projects\accountentry_js22>mvn clean install -U
[INFO] Scanning for projects...
[INFO]
[INFO] --< edu.uiuc.fs:accountentry >--
[INFO] Building Account Entry Panel (js22) 2.2.1
[INFO] [ jar ]-
Downloading from java.net-Public: 
https://maven.java.net/content/groups/public/edu/uiuc/fs/ParentPom/0.0.1-SNAPSHOT/maven-metadata.xml
Downloading from third-party-libraries: 
http://artifactory.fs.illinois.edu/artifactory/third-party-libraries/edu/uiuc/fs/ParentPom/0.0.1-SNAPSHOT/maven-metadata.xml
Downloading from maven2-repository.dev.java.net: 
https://download.java.net/maven/2/edu/uiuc/fs/ParentPom/0.0.1-SNAPSHOT/maven-metadata.xml
Downloaded from third-party-libraries: 
http://artifactory.fs.illinois.edu/artifactory/third-party-libraries/edu/uiuc/fs/ParentPom/0.0.1-SNAPSHOT/maven-metadata.xml
 (585 B at 1.9 kB/s)
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ accountentry ---
[INFO] Deleting C:\dev\Projects\accountentry_js22\target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
accountentry ---
[INFO] Using 'Cp1252' encoding to copy filtered resources.
[INFO] Copying 12 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ accountentry 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 12 source files to 
C:\dev\Projects\accountentry_js22\target\classes
[parsing started 
RegularFileObject[C:\dev\Projects\accountentry_js22\src\main\java\edu\uiuc\fs\accountentry\AimAccountPanel.java]]
[parsing completed 16ms]
[parsing started 
RegularFileObject[C:\dev\Projects\accountentry_js22\src\main\java\edu\uiuc\fs\validators\AimAccountValidator.java]]
[parsing completed 0ms]
[parsing started 
RegularFileObject[C:\dev\Projects\accountentry_js22\src\main\java\edu\uiuc\fs\validators\GarValidator.java]]
[parsing completed 15ms]
[parsing started 
RegularFileObject[C:\dev\Projects\accountentry_js22\src\main\java\edu\uiuc\fs\accountentry\GarPanel.java]]
[parsing completed 0ms]
[parsing started 
RegularFileObject[C:\dev\Projects\accountentry_js22\src\main\java\edu\uiuc\fs\validators\CfoapalValidator.java]]
[parsing completed 16ms]
[parsing started