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: Repository Order

[Zak Mc Kracken]

Thanks Stephen,

that's very interesting.
Marco.

On 30/10/2012 10:23, Stephen Connolly wrote:

On 30 October 2012 10:14, Zak Mc Kracken  wrote:


On 25/10/2012 02:47, Barrie Treloar wrote:


Maven will needless contact all five of your repositories looking for
artifacts that probably aren't even there.
This will require a tcp/ip connection for each one and when you have
large dependencies this can significantly slow down your build.
Which is why we all recommend putting a Maven Repository Manager (MRM)
in between you and the rest of the w
orld.


I've always had a doubt about this and it's about giving the world the
option to do just 'mvn install/deploy' to build a project, after having
downloaded the sources.
If my project depends on some non-common repository, such as the company
repository, putting it in the POM makes external users/developers's life as
easy as that, if such repo is in some local settings only, you need at
least to document the extra-step about the need to add it in anyone else's
local configuration.


If your artifacts are available to others, just push them to central. That
makes *everyone's* life easier. One repo fast resolving.

If your artifacts are not redistributible, then they need the details for
your repository anyway, and they should be using a MRM.



Does anyone know a compromise between these two extremes? Can repositories
declared in the POM be disabled by, eg, a profile in settings?


Yes they can, but it won't work how you think it will work, as the
repository that an artifact was resolved from is part of the details stored
by newer versions of Maven, so that once the profile is turned off, the
artifacts will not be found.



Thanks in advance,



The mistake was in letting there be a repository definition in the pom in
the first place.

One of the things we would like to add in the future to maven is better
routing rules. What I would like to see is something that was kind of
auto-discoverable, so that, for example, DNS entries could give Maven hints
as to where to find repository managers and what scope of groupIds those
repository managers resolve, thereby decentralizing central... but that is
just a personal opinion, and I would like something that helps for when
off-line too!



Marco.


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





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

Re: Repository Order

[Zak Mc Kracken]

On 25/10/2012 02:47, Barrie Treloar wrote:

Maven will needless contact all five of your repositories looking for
artifacts that probably aren't even there.
This will require a tcp/ip connection for each one and when you have
large dependencies this can significantly slow down your build.
Which is why we all recommend putting a Maven Repository Manager (MRM)
in between you and the rest of the w
orld.
I've always had a doubt about this and it's about giving the world the 
option to do just 'mvn install/deploy' to build a project, after having 
downloaded the sources.
If my project depends on some non-common repository, such as the company 
repository, putting it in the POM makes external users/developers's life 
as easy as that, if such repo is in some local settings only, you need 
at least to document the extra-step about the need to add it in anyone 
else's local configuration.


Does anyone know a compromise between these two extremes? Can 
repositories declared in the POM be disabled by, eg, a profile in settings?


Thanks in advance,

Marco.

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

Re: Getting profile settings values in a Java class

[Zak Mc Kracken]

Hi Javix,

yes, this is what I mean. You may want to consider what emerged in this 
thread about the goodness of this practice.


Cheers,
M.


On 21/09/2012 10:55, Javix wrote:

Finally, I achived (I hope so, tell me if I'm wrong by pointing at some
pitfalls). Here is the updated version of the POM file:





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

Re: Getting profile settings values in a Java class

[Zak Mc Kracken]

Hi Roy,

that's a useful addition. Indeed I do something similar with with some 
command-line tools. I ship them as a zip which contains: a .jar a 
.sh/.bat invoking commands and a default .properties file. For the 
latter, I want different defaults depending on the environment where I 
deploy final zip. I could just ask the users to point to the right 
.properties file, but the fact is that we have the dev/test/production 
environments and in the first two we want a situation that is as close 
as possible to the third.


Thanks anyway.
Marco.

On 21/09/2012 01:32, Lyons, Roy wrote:

I would like to say that there is definitely a better way.  You *could*
continue to use maven for filtering your properties, but I wouldn't use it
as part of the build of the application.
  
If you are simply using scp or other similarly crude method of deployment

(meaning you are just deploying as a file transfer), I would say that you
could set up a maven project on the server side which handle the
deployment.  You can setup a pom.xml with all of the maven objects as
dependencies (including your jar/war/ear files you already built) and then
use the assembly plugin to create a staged application environment
including a variable replacement on template-ized external property files
which your application can reference (the replacement being done by
filtering within assembly directives).  As a matter of fact, I would argue
that this could be all stuffed in a git repository and your installation
could be done with:

ssh $servername "git clone -b $branchname $gitprojecturl \; cd 
$targetdir
\; mvn -P $envname dependency:resolve assembly:assembly \; $startscript"

Or

ssh $servername "cd $targetdir \; $stopscript \; git clean -f \; git 
pull
origin \; mvn -P $envname dependency:resolve assembly:assembly \;
$startscript"

Long and short is that it is still possible to do what you want with
maven, but not inside of the box you are thinking in.  As a configuration
engineer, I know that environment specific properties (and usually other
properties too) should always be stored in files external to your jar.
"The Maven Way" will tell you to make re-usable stuff.  Your deployment
artifacts are no exception.  Don't force a rebuild when a property has to
change.  Your QA folks will be extra thankful since the jar/war/ear will
maintain a constant md5sum that they can use to justify not performing
full regression tests.

Disclaimer:  We are using a highly sophisticated and expensive tool for
deployments and can't use this method due to auditing needs.  However we
still have our tool perform a post-process interpolation of variables
within config files based on environment to achieve a similar end result.

Also, to prevent a flame-war -- I am presenting this as a feasible
alternative way to use maven for the purpose of filtering properties based
on a profile being set (the original poster's intention) that will perhaps
help the original poster think outside of the box to achieve their goals.

Thanks,

Roy






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

Re: Getting profile settings values in a Java class

[Zak Mc Kracken]

OK, I understand that in general it should be considered an 
anti-pattern. Despite that, in my organisation we deploy a number of 
internal tools on a couple of servers and with different configurations 
(dev, test, production). To achieve this we do what it was originally 
asked in this thread.


I think the only way for that with the assistance of Maven is how it was 
suggested: use property files with ${placeholders} and tell Maven to 
resolve them, then define the corresponding properties in the profiles. 
This is an example:


  http://github.com/EBIBioSamples/core_model/blob/master/pom.xml

Note that the  and  sections have: 
true and then there are parametrised files like:


http://github.com/EBIBioSamples/core_model/blob/master/src/test/resources/hibernate.properties

In this particular module, things are set only to change the 
configuration that JUnit tests receive, but the trick works the same way 
if you have another property file in src/main/resources. Yes, it makes 
the final jar dependent on Maven profiles and on a particular 
environment, however it may be acceptable in certain situations (like ours).


Marco.


On 20/09/2012 21:16, Ron Wheeler wrote:

Maven is not the place to set run-time information.
Trying to use profiles in this way, will only lead you to heartache 
and a dislike of Maven.


http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58

Ron






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

Re: Using Maven 1 repositories with Maven 3

[Zak Mc Kracken]

On 24/10/2010 22:29, Arnaud Héritier wrote:
> As some others said, the real solution for you is to use a repository 
manager.
> It will bring many advantages to manage binaries coming from outside 
and it will give you a transparent access to maven 1 and 2 repositories



On 24/10/2010 22:54, Wayne Fay wrote:

thank you for your reply. Do you mean I can do the conversion as a
repository user? I need to access 3rd party repositories, I cannot change




Thanks Arnaud, Wayne for your replies. Now I too have clear that I 
should use this repository manager, I don't think I should by ashamed of 
not knowing that before. Or should I? :-)


I feel a bit like having to install something like that on my laptop is 
overhead work that one nees to do just because a simpler solution for 
this M1 repo support in M3 doesn't exist, but I'll try it.


I guess this should be enough to start with that:

http://maven.apache.org/repository-management.html
http://nexus.sonatype.org/
http://www.andrejkoelewijn.com/wp/2010/03/09/getting-started-with-nexus-maven-repository-manager/

Should someone have more links about, I (and probably many others in 
this mailing list) would really appreciate.


Thanks,

Marco.

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

Re: Using Maven 1 repositories with Maven 3

[Zak Mc Kracken]

Hi Anders,

thank you for your reply. Do you mean I can do the conversion as a 
repository user? I need to access 3rd party repositories, I cannot 
change them. By the way, this also means that "The 5 years is up" is not 
a message for me :-) Maybe I could stop using java.net, but I have other 
dependencies in the same situation that are not so easy to be moved out 
or upgraded (I should trace all of them, check if there is a more recent 
version in M2 repos, transitively check all the dependency tree, it was 
becoming a nightmare when I decided that for the moment I won't migrate 
to M3, unless I can arrange M1 support in that version too).


Marco.



On 24/10/2010 20:25, Anders Hammar wrote:

And by the way, you should really try to stop using the java.net repo. I'll
quote Stephen Connolly, "friends don't let friends use the java.net maven
repositories". :-)

/Anders

On Sun, Oct 24, 2010 at 21:22, Anders Hammar  wrote:


You need to get a repo manager like Nexus set up, which is able to convert
from Maven 1 to Maven 2 repo format.

/Anders

On Sun, Oct 24, 2010 at 20:35, Zak Mc Kracken  wrote:


Hi all,

sorry if the question has already been asked, I cannot find anything on
the mailing list archive.

Subject should be clear enough, I have a project with many dependencies on
Maven 1 3rd-party repositories that I cannot migrate (e.g.: java.net).
Isn't there a way to continue to use them? Like a plug-in to be declared in
my POM? If yes, please, could someone provide a usage example?

I really need that, otherwise I will need to stay with Maven 2, until more
people migrate to the 3.

Thanks in advance for any help.

Marco.


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








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

Using Maven 1 repositories with Maven 3

[Zak Mc Kracken]

Hi all,

sorry if the question has already been asked, I cannot find anything on 
the mailing list archive.


Subject should be clear enough, I have a project with many dependencies 
on Maven 1 3rd-party repositories that I cannot migrate (e.g.: 
java.net). Isn't there a way to continue to use them? Like a plug-in to 
be declared in my POM? If yes, please, could someone provide a usage 
example?


I really need that, otherwise I will need to stay with Maven 2, until 
more people migrate to the 3.


Thanks in advance for any help.

Marco.


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

surefire summary

[Zak Mc Kracken]

Hi all,

Since today "mvn test" does not report the list of failed tests at the 
end. I have:



Results :

Failed tests: 


Tests run: 74, Failures: 3, Errors: 0, Skipped: 4

[ERROR] 

Mojo: 


org.apache.maven.plugins:maven-surefire-plugin:2.4.2:test

FAILED for project: 


:jar:1.0-SNAPSHOT

Reason:

There are test failures.


while it used to list the 3 failed test classes, under "Failed Tests". 
Such a list is very useful and I cannot understand why it's no longer 
printed, I didn't change the POM.


Thanks in advance for any help.

Marco.

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