Re: Create test jar during build without attaching

[jieryn]

Would src/test/resources be included in the src artifact? I suspect not.

On Thu, Aug 18, 2016 at 9:47 PM, Christopher  wrote:
> If this were a personal project, I'd probably do that... but this is for an
> ASF project, and I don't want to put us in a position where we are
> releasing with binaries in the source artifact.
>
> On Thu, Aug 18, 2016 at 9:39 PM jieryn  wrote:
>
>> Create the jar and then put it under src/test/resources/my.jar and
>> then refer to that my.jar in your testcase. It seems like an awful lot
>> of trouble to dynamically create this test artifact, when you could
>> just create it once and then add it to your repository. Yes, adding
>> jars to your scm is generally bad, but this seems like a perfect
>> exception.
>>
>> On Thu, Aug 18, 2016 at 9:36 PM, Christopher  wrote:
>> > Hi Maven Users list,
>> >
>> > What's the best way to create a jar during a build without attaching it?
>> >
>> > Currently, our pom is configured to use the maven-jar-plugin to create
>> it,
>> > but that plugin attaches an artifact, which gets deployed. We don't want
>> > that. That doesn't seem to be configurable.
>> >
>> > We could create a mini project and use maven-invoker-plugin to package
>> it,
>> > but that's a lot of overhead (configuration and processing time) for a
>> very
>> > small test jar containing a single file (used to test a classloader).
>> >
>> > We've also considered just using maven-exec-plugin to execute the jar
>> > command-line tool, but that's tricky to get right, accounting for
>> > JAVA_HOME, toolchains, etc.
>> >
>> > Any suggestions, or is maven-invoker-plugin the best option?
>> >
>> > I think the maven-assembly-plugin might be able to do it, and it has an
>> > false option, but I've never used it like this before.
>> If
>> > that's the best option, does anybody have any examples of that kind of
>> > thing?
>> >
>> > Thanks.
>>
>> -
>> 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

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

[jieryn]

Sorry I am so late to this party.

I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be overriden by any actual parameters that I specify on the
command line.

Specifically, I am trying to override the maven.config --fail-at-end
via --fail-fast, and also --threads 2.0C with --threads 1. When I
invoke mvn, it seems the maven.config options are taken instead of my
local cli invocation. These have a bad effect on my invocation and
cause a lot of trouble. We do not check in our .mvn/maven.config, so I
can not simply rm -rf it and then check it out after... it's a pita,
and bad karma. Please examine it :) thank you.

On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise  wrote:
> Hi to all Maven users,
>
> If you like to help making the next Maven release better it would be nice if
> you could help a little bit.
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
>
> Windows: https://s.apache.org/vG4r
> Linux/Mac: https://s.apache.org/FfRw
>
> Every kind of feedback is helpful.
>
> Important hint:
>
> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
> It would be nice if those who had found issues to retest their scenarios.
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Create test jar during build without attaching

[Christopher]

If this were a personal project, I'd probably do that... but this is for an
ASF project, and I don't want to put us in a position where we are
releasing with binaries in the source artifact.

On Thu, Aug 18, 2016 at 9:39 PM jieryn  wrote:

> Create the jar and then put it under src/test/resources/my.jar and
> then refer to that my.jar in your testcase. It seems like an awful lot
> of trouble to dynamically create this test artifact, when you could
> just create it once and then add it to your repository. Yes, adding
> jars to your scm is generally bad, but this seems like a perfect
> exception.
>
> On Thu, Aug 18, 2016 at 9:36 PM, Christopher  wrote:
> > Hi Maven Users list,
> >
> > What's the best way to create a jar during a build without attaching it?
> >
> > Currently, our pom is configured to use the maven-jar-plugin to create
> it,
> > but that plugin attaches an artifact, which gets deployed. We don't want
> > that. That doesn't seem to be configurable.
> >
> > We could create a mini project and use maven-invoker-plugin to package
> it,
> > but that's a lot of overhead (configuration and processing time) for a
> very
> > small test jar containing a single file (used to test a classloader).
> >
> > We've also considered just using maven-exec-plugin to execute the jar
> > command-line tool, but that's tricky to get right, accounting for
> > JAVA_HOME, toolchains, etc.
> >
> > Any suggestions, or is maven-invoker-plugin the best option?
> >
> > I think the maven-assembly-plugin might be able to do it, and it has an
> > false option, but I've never used it like this before.
> If
> > that's the best option, does anybody have any examples of that kind of
> > thing?
> >
> > Thanks.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Create test jar during build without attaching

[jieryn]

Create the jar and then put it under src/test/resources/my.jar and
then refer to that my.jar in your testcase. It seems like an awful lot
of trouble to dynamically create this test artifact, when you could
just create it once and then add it to your repository. Yes, adding
jars to your scm is generally bad, but this seems like a perfect
exception.

On Thu, Aug 18, 2016 at 9:36 PM, Christopher  wrote:
> Hi Maven Users list,
>
> What's the best way to create a jar during a build without attaching it?
>
> Currently, our pom is configured to use the maven-jar-plugin to create it,
> but that plugin attaches an artifact, which gets deployed. We don't want
> that. That doesn't seem to be configurable.
>
> We could create a mini project and use maven-invoker-plugin to package it,
> but that's a lot of overhead (configuration and processing time) for a very
> small test jar containing a single file (used to test a classloader).
>
> We've also considered just using maven-exec-plugin to execute the jar
> command-line tool, but that's tricky to get right, accounting for
> JAVA_HOME, toolchains, etc.
>
> Any suggestions, or is maven-invoker-plugin the best option?
>
> I think the maven-assembly-plugin might be able to do it, and it has an
> false option, but I've never used it like this before. If
> that's the best option, does anybody have any examples of that kind of
> thing?
>
> Thanks.

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

Create test jar during build without attaching

[Christopher]

Hi Maven Users list,

What's the best way to create a jar during a build without attaching it?

Currently, our pom is configured to use the maven-jar-plugin to create it,
but that plugin attaches an artifact, which gets deployed. We don't want
that. That doesn't seem to be configurable.

We could create a mini project and use maven-invoker-plugin to package it,
but that's a lot of overhead (configuration and processing time) for a very
small test jar containing a single file (used to test a classloader).

We've also considered just using maven-exec-plugin to execute the jar
command-line tool, but that's tricky to get right, accounting for
JAVA_HOME, toolchains, etc.

Any suggestions, or is maven-invoker-plugin the best option?

I think the maven-assembly-plugin might be able to do it, and it has an
false option, but I've never used it like this before. If
that's the best option, does anybody have any examples of that kind of
thing?

Thanks.

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

[Curtis Rueden]

Hi Stephane,

> The problem is that "pom-whiz" extends from "pom-base". You have a
> scenario where a "whiz" project extends from "pom-base" and then
> import "pom-whiz". Said "pom-whiz", via inheritance, "imports"
> "pom-base" again.

Yep, you got it.

> Independently on the issue described in this thread, this setup is
> broken IMO.

If you read the existing documentation on import scope [1], AFAICS, nowhere
does it say that what my projects do is disallowed or broken or discouraged.

In fact, nowhere does it talk about what happens when dependencyManagement
comes in through both the parent and through imports. It does say, however:

"In the example above Z imports the managed dependencies from both X and Y.
However, both X and Y contain dependency a. Here, version 1.1 of a would be
used since X is declared first and a is not declared in Z's
dependencyManagement."

The explicit claim there is that when there are version conflicts between
the same GA in multiple imported POMs, the first imported POM wins. It's
true that the parent is not an imported POM, it is an _inherited_ POM. But
it's declaration comes before the imported POMs. So by similar logic, its
dependency versions were declared first, so they should win.

I'm not arguing that "I am right and you are wrong" here—I'm saying that
the docs make no promises and there is room for doubt here. I do not think
it is a clear-cut situation. And therefore, we cannot simply write off the
breaking change as a "bug-fix".

>  I already said we spent a lot of time in Spring land to tune our BOMs

Sure. And so did I. And so did many other projects, I'm sure.

>  and one rule of thumb was that you should _never ever_ provide
>  dependency management for something that you're not managing
>  yourself. You should let the component responsible for it drive it.

I absolutely agree that in retrospect, it is much cleaner to have separate
BOMs, and that is certainly what my projects will do moving forward.

I am just looking for a solution which will keep everyone's projects
working as intended while also letting us move Maven forward the way it
should. It sounds like Christian's proposal to bump the POM model version
to 4.1.0 may be the way to go. Maybe that is a discussion for the dev list?

Regards,
Curtis

[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Thu, Aug 18, 2016 at 3:04 AM, Stephane Nicoll 
wrote:

> On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden  wrote:
>
> > Hi Stephane,
> >
> > Apologies up front for my long reply here. I divided into sections to
> help
> > break things up.
> >
> >
> > *== Expected behavior? Or a defect? ==*
> >
> > > if you expect the parent to override something you've defined
> > > in the child, that's not the expected behaviour at all.
> >
> > It certainly _has_ been the expected behavior in my community for the
> past
> > 5 years. Here is a simplified rundown:
> >
> > - pom-base is the parent POM for everything, locking down plugin
> versions,
> > and managing common dependency versions.
> > - pom-whiz extends pom-base to manage dependency versions of "whiz"
> > components.
> > - pom-bang extends pom-base to manage dependency versions of "bang"
> > components.
> > - Whiz-based projects extend pom-whiz to gain dependency management of
> all
> > base and whiz components.
> > - Bang-based projects extend pom-bang to gain dependency management of
> all
> > base and bang components.
> > - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
> > to gain dependency management of all base, whiz and bang components.
> >
> > In this scenario, because we use "release early, release often" style
> > development where components are released individually, it is untenable
> for
> > the pom-base version to be totally aligned between the most recent
> > pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do
> not
> > want to force releases of bang, and vice versa, just to keep all pom-base
> > versions consistent.
> >
>
> OK, after more coffee I finally managed to get my head around your project.
> The problem is that "pom-whiz" extends from "pom-base". You have a scenario
> where a "whiz" project extends from "pom-base" and then import "pom-whiz".
> Said "pom-whiz", via inheritance, "imports" "pom-base" again.
>
> Independently on the issue described in this thread, this setup is broken
> IMO. I already said we spent a lot of time in Spring land to tune our BOMs
> and one rule of thumb was that you should _never ever_ provide dependency
> management for something that you're not managing yourself. You should let
> the component responsible for it drive it.
>
> Let's take an example in Spring land: Spring 

RE: Building Docker image works in subproject, not from aggregator

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID
> Sent: Wednesday, August 17, 2016 11:46 AM
> To: Maven Users List 
> Subject: RE: Building Docker image works in subproject, not from
> aggregator
> 
> > -Original Message-
> > From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
> > Behalf Of Curtis Rueden
> > Sent: Wednesday, August 17, 2016 11:37 AM
> > To: Maven Users List 
> > Subject: Re: Building Docker image works in subproject, not from
> > aggregator
> >
> > Hi David,
> >
> > Just a shot in the dark, but does it work to write:
> >
> > ${baseDir}/src/docker
> 
> Thanks for the reply.
> 
> Since I posted this, I removed the "resource" entry that references
> "src/docker" because I realized it wasn't needed, but I still get the
> error, so the issue is likely due to the "dockerDirectory" value.  In
> any case, I tried changing the value to "${basedir}/src/docker", but it
> made no difference.

Correction.  I tested the "${basedir}" change in the wrong place (I have the 
project checked out in two locations in my Eclipse workspace, to make it easier 
to test this).  Changing the "dockerDirectory" reference to use 
"${basedir}/src/docker" worked.

Would this be considered a bug?  Wouldn't it make sense for a project to build 
the same way whether spawned from the project directory, or from the 
aggregator, without having to add extra syntax?  I think I've seen this sort of 
notation in other places, so I have a feeling this is a common problem.

> > On Wed, Aug 17, 2016 at 1:04 PM, KARR, DAVID  wrote:
> >
> > > I'm using the "docker-maven-plugin" to build a simple image based on
> > > TomEE.  This is one subproject in a small multiproject build.  Two
> > > other subprojects build the webapps that are installed into the
> > > TomEE
> > instance.
> > >
> > > I've been able to get the image to build by building from the
> "image"
> > > subproject.  However, when I start the build from the parent
> > > aggregator, it gets confused about path references, and fails.
> > >
> > > The following is the relevant excerpt from the POM:
> > > ---
> > > 
> > > com.spotify
> > > docker-maven-plugin
> > > 
> > > 
> > > build-image
> > > package
> > > 
> > > build
> > > 
> > > 
> > > 
> > > 
> > > src/docker
> > > ordersimage
> > > 
> > > 
> > > ${project.build.dir
> > > ectory}/dependencies
> > > 
> > > ordersService.war
> > > ordersGUI.war
> > > ojdbc6.jar
> > > 
> > > 
> > > 
> > > src/docker
> > > adjustTomEEXml.sh
> > > 
> > > 
> > > 
> > > ${tzoffset}
> > > 
> > > 
> > > 
> > > --
> > >
> > > Again, when I build this project from the project directory, it
> > > builds the image properly.  However, when I run the build from the
> > > parent aggregator, the image subproject fails with the following:
> > > 
> > > [ERROR] Failed to execute goal
> > > com.spotify:docker-maven-plugin:0.4.11:build
> > > (build-image) on project ordersImage: Exception caught: basedir
> > > src/docker does not exist -> [Help 1]
> > > ---
> > >
> > > It appears that one or both of the two "src/docker" references in
> > > the plugin configuration end up being dereferenced relative to the
> > > directory the main build is run from, instead of the project
> > directory.
> > >
> > > Based on those results, any idea what I should do to fix this?
> > >
> > > 
> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> B
> CB 
> [  X  ܚX KK[XZ[
> 
>  \ \  ][  X  ܚX PX] [  \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
> 
>  \ \  Z[X] [  \X K ܙ B

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

[Stephane Nicoll]

On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden  wrote:

> Hi Stephane,
>
> Apologies up front for my long reply here. I divided into sections to help
> break things up.
>
>
> *== Expected behavior? Or a defect? ==*
>
> > if you expect the parent to override something you've defined
> > in the child, that's not the expected behaviour at all.
>
> It certainly _has_ been the expected behavior in my community for the past
> 5 years. Here is a simplified rundown:
>
> - pom-base is the parent POM for everything, locking down plugin versions,
> and managing common dependency versions.
> - pom-whiz extends pom-base to manage dependency versions of "whiz"
> components.
> - pom-bang extends pom-base to manage dependency versions of "bang"
> components.
> - Whiz-based projects extend pom-whiz to gain dependency management of all
> base and whiz components.
> - Bang-based projects extend pom-bang to gain dependency management of all
> base and bang components.
> - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
> to gain dependency management of all base, whiz and bang components.
>
> In this scenario, because we use "release early, release often" style
> development where components are released individually, it is untenable for
> the pom-base version to be totally aligned between the most recent
> pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do not
> want to force releases of bang, and vice versa, just to keep all pom-base
> versions consistent.
>

OK, after more coffee I finally managed to get my head around your project.
The problem is that "pom-whiz" extends from "pom-base". You have a scenario
where a "whiz" project extends from "pom-base" and then import "pom-whiz".
Said "pom-whiz", via inheritance, "imports" "pom-base" again.

Independently on the issue described in this thread, this setup is broken
IMO. I already said we spent a lot of time in Spring land to tune our BOMs
and one rule of thumb was that you should _never ever_ provide dependency
management for something that you're not managing yourself. You should let
the component responsible for it drive it.

Let's take an example in Spring land: Spring Boot is the base for
application development: it brings Spring Framework and dependency
management for a bunch of third parties. Spring Cloud is built on top of
Spring Boot.

Initially, the Spring Cloud BOM was (indirectly) importing dependency
management from some components managed by Spring Boot. Here's the setup:
you have a Spring Boot project (with the spring boot parent that provides
you all that's required to build with it and let's say Spring Framework
4.2.2). You decide to include some cloud stuff so you import the
"spring-cloud-dependencies" bom. When you do that, that BOM MUST NOT have
any opinion about the boot or framework version to use. If you do, cloud is
basically overriding the decision of the user. Previously, that BOM had
some dependency management for boot that would bring, say, Spring Framework
4.2.1. So by adding cloud to your project, you know override the framework
version that the base component provides.

I took us a long time to figure this out but we've managed to structure our
BOM that way and it works quite well. Because we've done so, we're already
shielded from this problem but we need this in other contexts (typically
when a service has to force a dependency change for whatever reason).

HTH,
S.



>
> With Maven 3.3, all of the above works in a very nice way. The dependency
> versions of base components come from pom-base, while the dependency
> versions of whiz components come from the pom-whiz import, and versions of
> bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
> (assuming it is declared before the pom-bang import) wins over the pom-base
> parent for the base component versions.
>
> There are a couple of ways to avoid this:
>
> - Add an import of pom-base just before pom-whiz and pom-bang, but this was
> previously redundant with the parent declaration.
>
> - Split out the dependency version management part of each POM -- i.e.,
> create a bom-base, bom-whiz and bom-bang. These boms would all be
> parentless, and manage only their own respective component sets. Then,
> hybrid projects which want managed versions of both whiz and bang can
> continue to import them without inheriting a conflicting set of versions
> for base components.
>
> I like the nice separation of concerns which this second solution offers.
> But it is more components -- additional complexity which might confuse new
> developers.
>
>
> *== Still a bug in property overrides? ==*
>
> Setting aside the issue above, there still seems to be a bug in property
> overrides, as illustrated by my earlier gist:
>
>https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
>
> Here we see that with Maven 3.4.0, setting the imagej.version property to
> 2.0.0-rc-49 in the  section of the project POM has no effect 

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

[Stephane Nicoll]

On Wed, Aug 17, 2016 at 10:16 PM, Curtis Rueden  wrote:

> Hi Christian & Stephane,
>
> Thanks for your replies.
>
> Christian Schulte wrote:
> > I am thinking about introducing model version "4.1.0" in Maven 3.4.
>
> I like this idea. Thanks for putting it forward!
>
> One question: for POM hierarchies with mixed model versions -- a 4.0.0 POM
> which imports or extends a 4.1.0 POM or vice versa -- do you foresee any
> complications?
>
> Stephane Nicoll wrote:
> > Assume "foo" is managed by "pom-base". The minute you want to override
> > the version of "foo", your bom import scenario falls appart.
>
> Why? You simply override the value of foo.version in your POM properties.
> This worked in Maven 3.3, but is currently broken in 3.4.0-SNAPSHOT. My
> understanding is that this is a bug distinct from the parent-vs-BOM
> versioning issue. No?
>

I was trying to show the inconsistency. If you have foo in a bom it doesn't
work but if you override the dependency manually (or override the version
for foo in properties) it works.

If we can't no longer override a version from the parent using a property
that's really bad because Spring Boot does that a lot. Is there a link to
an issue so that I can try on other projects?

Thanks!
S.


>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte  wrote:
>
> > Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> > >
> > >> There is an easy way to solve this. Maven validates the model version
> in
> > >> the POM to match "4.0.0". Based on that version, Maven can decide how
> to
> > >> behave. I am thinking about introducing model version "4.1.0" in Maven
> > >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> > >
> > > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> > long time ago when we were doing the Google Hangouts discussions about a
> > mental separation of build/deploy POM.
> >
> > Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> > with Maven < 3.4. Tools parsing the POMs themselves (not using
> > maven-model-builder) would need to support that as well.
> >
> > >
> > > If deployed as 4.1.0 then you'd be forcing all consumers of that
> > dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ),
> but
> > that might hurt any consuming applications like Sonar, Jenkins, or other
> > build tools.
> > >
> >
> > That's the drawback I am seeing as well. It's the same syntax with
> > different semantics. That's why Maven < 3.4 would need to abort.
> > Everything < 3.4 cannot provide the behaviour for that model version and
> > thus must not e.g. silently ignore XML elements leading to e.g.
> > different dependency trees when used with >= 3.4. It's a question of how
> > to progress Maven core when it comes to changes in behaviour making
> > sense. "Has always been that way -> must not change." Means we can never
> > change anything and must provide new features for changing things (e.g.
> > keep the import scope the way it always has been and introduce an
> > include scope with the new behaviour and document the import scope is
> > considered deprecated). It's not always possible to introduce a change
> > as a new feature. We recently discussed the addition of some kind of
> > feature toggles or knobs. That won't work, in my opinion, because Maven
> > would behave differently based on command line options. It's not
> > possible to deploy a POM to central whose correct/intended behaviour
> > depends on a specical command line option in use. I see no other way to
> > incrementing the model version for such things. Maven needs to know how
> > to behave solely based on what is in the POM. Nothing syntax related.
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>