Re: Create test jar during build without attaching

[Christopher]

Thanks. That sounds perfect. Thanks, all, for your help.

On Fri, Aug 19, 2016, 20:07 Guillaume Boué  wrote:

> Hi,
>
> It sounds like the simplest answer would be to use the
> maven-assembly-plugin and generate the JAR in the
> generate-test-resources phase. You can configure the plugin not to
> attach the artifact with false.
>
> Then, still in the generate-test-resources phase, you bind an execution
> of build-helper-maven-plugin:add-test-resource and configure it to add
> the generated JAR as a test resource:
>
> http://www.mojohaus.org/build-helper-maven-plugin/usage.html#Add_more_resource_directories_to_your_project
>
>
> Le 19/08/2016 à 23:37, Curtis Rueden a écrit :
> > Generate it during generateSources using a groovy script via gmaven? Or
> in
> > Java within the test code itself?
> >
> > On Aug 19, 2016 4:21 PM, "Christopher"  wrote:
> >
> >> We're not going to add the jar to SCM there's many reasons, and I
> could
> >> go into depth about all of them (I've tried to enumerate some already),
> but
> >> again... that's not the question. We're not going to do that. and I've
> >> already stated that. I appreciate the advice... really, I do... but
> we're
> >> not going to do that. Responding with that suggestion does not help
> answer
> >> the question asked.
> >>
> >> The purpose of this thread is to figure out the best way to create a jar
> >> during the build without attaching. That's the requirement. That's the
> >> goal.
> >>
> >> On Fri, Aug 19, 2016 at 5:09 PM Curtis Rueden 
> wrote:
> >>
> >>> Hi Christopher,
> >>>
> >>> The point of this JAR is for use in a unit test, right?
> >>>
> >>> So if it's in src/test/resources, it will only end up lumped into the
> >> test
> >>> JAR, not the main JAR. Do you guys deploy your test JAR for downstream
> >>> consumption? If so, do you actually need all the unit tests to pass
> _when
> >>> run from the test JAR outside the project_? Or only during the actual
> >> Maven
> >>> build? Because if you don't need that, then you could just put the JAR
> >>> resource outside of src/test/resources (in, say,
> >> ${basedir}/src/test/extra
> >>> or some such) and just access it from that relative path during the
> unit
> >>> tests. You get your unit test, your test JAR does not get bloated by
> this
> >>> nested JAR resource, and life goes on.
> >>>
> >>> That said, I agree with the others that naively, it does not seem bad
> to
> >>> have this tiny test JAR embedded in your deployed test JAR. It is a
> >> binary
> >>> test resource, very similar to an image file.
> >>>
> >>> 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 Fri, Aug 19, 2016 at 1:46 PM, Christopher 
> >> wrote:
>  We don't want to skip deployment of all the artifacts, just one jar
> >> built
>  in one module for one test, which is not intended to be one of the
>  artifact's modules. *maybe* we could move it to a separate module, and
> >>> skip
>  deploy, but we've already got a lot of module bloat, and I'd prefer
> not
> >>> to
>  make it worse.
> 
>  On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody 
> >>> wrote:
> > Perhaps I don't understand what is meant by "not attaching" but if
> >> all
>  you
> > want to do is skip deployment, the maven-deploy-plugin has this
> >>> feature:
> >  
> >  true
> >  
> > which can be added to the module you do not wish to deploy. We use
> >> this
>  in
> > order to not deploy .ear files to our artifactory.
> >
> > Regards, Gord Cody
> >
> > On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise <
> >>> khmarba...@gmx.de>
> > wrote:
> >
> >> Hi,
> >>
> >> On 19/08/16 03:36, 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.
> >>>
> >> Can you describe why you would like to create a jar which shouldn't
> >>> be
> >> deployed ? May be we can enhance maven-jar-plugin to support such a
> >>> use
> >> case?
> >>
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >>
> >> 
> >> -
> >> 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

[Guillaume Boué]

Hi,

It sounds like the simplest answer would be to use the 
maven-assembly-plugin and generate the JAR in the 
generate-test-resources phase. You can configure the plugin not to 
attach the artifact with false.


Then, still in the generate-test-resources phase, you bind an execution 
of build-helper-maven-plugin:add-test-resource and configure it to add 
the generated JAR as a test resource: 
http://www.mojohaus.org/build-helper-maven-plugin/usage.html#Add_more_resource_directories_to_your_project



Le 19/08/2016 à 23:37, Curtis Rueden a écrit :

Generate it during generateSources using a groovy script via gmaven? Or in
Java within the test code itself?

On Aug 19, 2016 4:21 PM, "Christopher"  wrote:


We're not going to add the jar to SCM there's many reasons, and I could
go into depth about all of them (I've tried to enumerate some already), but
again... that's not the question. We're not going to do that. and I've
already stated that. I appreciate the advice... really, I do... but we're
not going to do that. Responding with that suggestion does not help answer
the question asked.

The purpose of this thread is to figure out the best way to create a jar
during the build without attaching. That's the requirement. That's the
goal.

On Fri, Aug 19, 2016 at 5:09 PM Curtis Rueden  wrote:


Hi Christopher,

The point of this JAR is for use in a unit test, right?

So if it's in src/test/resources, it will only end up lumped into the

test

JAR, not the main JAR. Do you guys deploy your test JAR for downstream
consumption? If so, do you actually need all the unit tests to pass _when
run from the test JAR outside the project_? Or only during the actual

Maven

build? Because if you don't need that, then you could just put the JAR
resource outside of src/test/resources (in, say,

${basedir}/src/test/extra

or some such) and just access it from that relative path during the unit
tests. You get your unit test, your test JAR does not get bloated by this
nested JAR resource, and life goes on.

That said, I agree with the others that naively, it does not seem bad to
have this tiny test JAR embedded in your deployed test JAR. It is a

binary

test resource, very similar to an image file.

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 Fri, Aug 19, 2016 at 1:46 PM, Christopher 

wrote:

We don't want to skip deployment of all the artifacts, just one jar

built

in one module for one test, which is not intended to be one of the
artifact's modules. *maybe* we could move it to a separate module, and

skip

deploy, but we've already got a lot of module bloat, and I'd prefer not

to

make it worse.

On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody 

wrote:

Perhaps I don't understand what is meant by "not attaching" but if

all

you

want to do is skip deployment, the maven-deploy-plugin has this

feature:

 
 true
 
which can be added to the module you do not wish to deploy. We use

this

in

order to not deploy .ear files to our artifactory.

Regards, Gord Cody

On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise <

khmarba...@gmx.de>

wrote:


Hi,

On 19/08/16 03:36, 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.


Can you describe why you would like to create a jar which shouldn't

be

deployed ? May be we can enhance maven-jar-plugin to support such a

use

case?


Kind regards
Karl Heinz Marbaise




-

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




--
Best Regards, Gord Cody

Release Manager  Zafin Labs Americas Inc.
179 Colonnade Road-Suite 100, Ottawa ON, Canada
Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1

613-601-2734

Web: http://zafin.com  Email: gordon.c...@zafin.com

--
Zafin - Canada

--
http://zafin.com



--

Connect with us


  

News and Events

Zafin announces 100 person Center of Excellence in Toronto
<
http://zafin.com/press-releases/zafin-announces-new-

100-person-centre-excellence-toronto/

For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and

Fast

500 rankings
<
http://zafin.com/press-releases/zafin-named-deloitte-

technology-fast-50-fast-500-lists/

<
http://zafin.com/press-releases/zafin-ranks-16th-on-

Re: Create test jar during build without attaching

[Curtis Rueden]

Generate it during generateSources using a groovy script via gmaven? Or in
Java within the test code itself?

On Aug 19, 2016 4:21 PM, "Christopher"  wrote:

> We're not going to add the jar to SCM there's many reasons, and I could
> go into depth about all of them (I've tried to enumerate some already), but
> again... that's not the question. We're not going to do that. and I've
> already stated that. I appreciate the advice... really, I do... but we're
> not going to do that. Responding with that suggestion does not help answer
> the question asked.
>
> The purpose of this thread is to figure out the best way to create a jar
> during the build without attaching. That's the requirement. That's the
> goal.
>
> On Fri, Aug 19, 2016 at 5:09 PM Curtis Rueden  wrote:
>
> > Hi Christopher,
> >
> > The point of this JAR is for use in a unit test, right?
> >
> > So if it's in src/test/resources, it will only end up lumped into the
> test
> > JAR, not the main JAR. Do you guys deploy your test JAR for downstream
> > consumption? If so, do you actually need all the unit tests to pass _when
> > run from the test JAR outside the project_? Or only during the actual
> Maven
> > build? Because if you don't need that, then you could just put the JAR
> > resource outside of src/test/resources (in, say,
> ${basedir}/src/test/extra
> > or some such) and just access it from that relative path during the unit
> > tests. You get your unit test, your test JAR does not get bloated by this
> > nested JAR resource, and life goes on.
> >
> > That said, I agree with the others that naively, it does not seem bad to
> > have this tiny test JAR embedded in your deployed test JAR. It is a
> binary
> > test resource, very similar to an image file.
> >
> > 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 Fri, Aug 19, 2016 at 1:46 PM, Christopher 
> wrote:
> >
> > > We don't want to skip deployment of all the artifacts, just one jar
> built
> > > in one module for one test, which is not intended to be one of the
> > > artifact's modules. *maybe* we could move it to a separate module, and
> > skip
> > > deploy, but we've already got a lot of module bloat, and I'd prefer not
> > to
> > > make it worse.
> > >
> > > On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody 
> > wrote:
> > >
> > > > Perhaps I don't understand what is meant by "not attaching" but if
> all
> > > you
> > > > want to do is skip deployment, the maven-deploy-plugin has this
> > feature:
> > > > 
> > > > true
> > > > 
> > > > which can be added to the module you do not wish to deploy. We use
> this
> > > in
> > > > order to not deploy .ear files to our artifactory.
> > > >
> > > > Regards, Gord Cody
> > > >
> > > > On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise <
> > khmarba...@gmx.de>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On 19/08/16 03:36, 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.
> > > > >>
> > > > >
> > > > > Can you describe why you would like to create a jar which shouldn't
> > be
> > > > > deployed ? May be we can enhance maven-jar-plugin to support such a
> > use
> > > > > case?
> > > > >
> > > > >
> > > > > Kind regards
> > > > > Karl Heinz Marbaise
> > > > >
> > > > >
> > > > > 
> -
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Gord Cody
> > > >
> > > > Release Manager  Zafin Labs Americas Inc.
> > > > 179 Colonnade Road-Suite 100, Ottawa ON, Canada
> > > > Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1
> > > 613-601-2734
> > > > Web: http://zafin.com  Email: gordon.c...@zafin.com
> > > >
> > > > --
> > > > Zafin - Canada
> > > >
> > > > --
> > > > http://zafin.com
> > > >
> > > > 
> > > >
> > > > --
> > > >
> > > > Connect with us
> > > >
> > > > 
> > > >   
> > > >
> > > > News and Events
> > > >
> > > > Zafin announces 100 person Center of Excellence in Toronto
> > > > <
> > > > http://zafin.com/press-releases/zafin-announces-new-
> > > 

Re: Create test jar during build without attaching

[Christopher]

We're not going to add the jar to SCM there's many reasons, and I could
go into depth about all of them (I've tried to enumerate some already), but
again... that's not the question. We're not going to do that. and I've
already stated that. I appreciate the advice... really, I do... but we're
not going to do that. Responding with that suggestion does not help answer
the question asked.

The purpose of this thread is to figure out the best way to create a jar
during the build without attaching. That's the requirement. That's the goal.

On Fri, Aug 19, 2016 at 5:09 PM Curtis Rueden  wrote:

> Hi Christopher,
>
> The point of this JAR is for use in a unit test, right?
>
> So if it's in src/test/resources, it will only end up lumped into the test
> JAR, not the main JAR. Do you guys deploy your test JAR for downstream
> consumption? If so, do you actually need all the unit tests to pass _when
> run from the test JAR outside the project_? Or only during the actual Maven
> build? Because if you don't need that, then you could just put the JAR
> resource outside of src/test/resources (in, say, ${basedir}/src/test/extra
> or some such) and just access it from that relative path during the unit
> tests. You get your unit test, your test JAR does not get bloated by this
> nested JAR resource, and life goes on.
>
> That said, I agree with the others that naively, it does not seem bad to
> have this tiny test JAR embedded in your deployed test JAR. It is a binary
> test resource, very similar to an image file.
>
> 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 Fri, Aug 19, 2016 at 1:46 PM, Christopher  wrote:
>
> > We don't want to skip deployment of all the artifacts, just one jar built
> > in one module for one test, which is not intended to be one of the
> > artifact's modules. *maybe* we could move it to a separate module, and
> skip
> > deploy, but we've already got a lot of module bloat, and I'd prefer not
> to
> > make it worse.
> >
> > On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody 
> wrote:
> >
> > > Perhaps I don't understand what is meant by "not attaching" but if all
> > you
> > > want to do is skip deployment, the maven-deploy-plugin has this
> feature:
> > > 
> > > true
> > > 
> > > which can be added to the module you do not wish to deploy. We use this
> > in
> > > order to not deploy .ear files to our artifactory.
> > >
> > > Regards, Gord Cody
> > >
> > > On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise <
> khmarba...@gmx.de>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On 19/08/16 03:36, 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.
> > > >>
> > > >
> > > > Can you describe why you would like to create a jar which shouldn't
> be
> > > > deployed ? May be we can enhance maven-jar-plugin to support such a
> use
> > > > case?
> > > >
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Best Regards, Gord Cody
> > >
> > > Release Manager  Zafin Labs Americas Inc.
> > > 179 Colonnade Road-Suite 100, Ottawa ON, Canada
> > > Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1
> > 613-601-2734
> > > Web: http://zafin.com  Email: gordon.c...@zafin.com
> > >
> > > --
> > > Zafin - Canada
> > >
> > > --
> > > http://zafin.com
> > >
> > > 
> > >
> > > --
> > >
> > > Connect with us
> > >
> > > 
> > >   
> > >
> > > News and Events
> > >
> > > Zafin announces 100 person Center of Excellence in Toronto
> > > <
> > > http://zafin.com/press-releases/zafin-announces-new-
> > 100-person-centre-excellence-toronto/
> > > >
> > >
> > > For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and
> > Fast
> > > 500 rankings
> > > <
> > > http://zafin.com/press-releases/zafin-named-deloitte-
> > technology-fast-50-fast-500-lists/
> > > >
> > >
> > > <
> > > http://zafin.com/press-releases/zafin-ranks-16th-on-
> > the-2014-deloitte-technology-fast-50-list/
> > > >
> > >
> >
>

Re: Create test jar during build without attaching

[Curtis Rueden]

Hi Christopher,

The point of this JAR is for use in a unit test, right?

So if it's in src/test/resources, it will only end up lumped into the test
JAR, not the main JAR. Do you guys deploy your test JAR for downstream
consumption? If so, do you actually need all the unit tests to pass _when
run from the test JAR outside the project_? Or only during the actual Maven
build? Because if you don't need that, then you could just put the JAR
resource outside of src/test/resources (in, say, ${basedir}/src/test/extra
or some such) and just access it from that relative path during the unit
tests. You get your unit test, your test JAR does not get bloated by this
nested JAR resource, and life goes on.

That said, I agree with the others that naively, it does not seem bad to
have this tiny test JAR embedded in your deployed test JAR. It is a binary
test resource, very similar to an image file.

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 Fri, Aug 19, 2016 at 1:46 PM, Christopher  wrote:

> We don't want to skip deployment of all the artifacts, just one jar built
> in one module for one test, which is not intended to be one of the
> artifact's modules. *maybe* we could move it to a separate module, and skip
> deploy, but we've already got a lot of module bloat, and I'd prefer not to
> make it worse.
>
> On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody  wrote:
>
> > Perhaps I don't understand what is meant by "not attaching" but if all
> you
> > want to do is skip deployment, the maven-deploy-plugin has this feature:
> > 
> > true
> > 
> > which can be added to the module you do not wish to deploy. We use this
> in
> > order to not deploy .ear files to our artifactory.
> >
> > Regards, Gord Cody
> >
> > On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise 
> > wrote:
> >
> > > Hi,
> > >
> > > On 19/08/16 03:36, 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.
> > >>
> > >
> > > Can you describe why you would like to create a jar which shouldn't be
> > > deployed ? May be we can enhance maven-jar-plugin to support such a use
> > > case?
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> > Best Regards, Gord Cody
> >
> > Release Manager  Zafin Labs Americas Inc.
> > 179 Colonnade Road-Suite 100, Ottawa ON, Canada
> > Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1
> 613-601-2734
> > Web: http://zafin.com  Email: gordon.c...@zafin.com
> >
> > --
> > Zafin - Canada
> >
> > --
> > http://zafin.com
> >
> > 
> >
> > --
> >
> > Connect with us
> >
> > 
> >   
> >
> > News and Events
> >
> > Zafin announces 100 person Center of Excellence in Toronto
> > <
> > http://zafin.com/press-releases/zafin-announces-new-
> 100-person-centre-excellence-toronto/
> > >
> >
> > For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and
> Fast
> > 500 rankings
> > <
> > http://zafin.com/press-releases/zafin-named-deloitte-
> technology-fast-50-fast-500-lists/
> > >
> >
> > <
> > http://zafin.com/press-releases/zafin-ranks-16th-on-
> the-2014-deloitte-technology-fast-50-list/
> > >
> >
>

Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

The EventDispatcher support was completely removed with the commit 
https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4 

 for Maven 3.0.
Currently I instead use a JVM Shutdown Hook to perform some tasks at the end of 
the build which is not recommended either for obvious reasons (see 
https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks
 
).

What is the recommended way on how to perform some tasks at the end of the 
reactor build?
Thanks,
Konrad

Re: Create test jar during build without attaching

[Christopher]

We don't want to skip deployment of all the artifacts, just one jar built
in one module for one test, which is not intended to be one of the
artifact's modules. *maybe* we could move it to a separate module, and skip
deploy, but we've already got a lot of module bloat, and I'd prefer not to
make it worse.

On Fri, Aug 19, 2016 at 2:34 PM Gordon Cody  wrote:

> Perhaps I don't understand what is meant by "not attaching" but if all you
> want to do is skip deployment, the maven-deploy-plugin has this feature:
> 
> true
> 
> which can be added to the module you do not wish to deploy. We use this in
> order to not deploy .ear files to our artifactory.
>
> Regards, Gord Cody
>
> On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 19/08/16 03:36, 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.
> >>
> >
> > Can you describe why you would like to create a jar which shouldn't be
> > deployed ? May be we can enhance maven-jar-plugin to support such a use
> > case?
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Best Regards, Gord Cody
>
> Release Manager  Zafin Labs Americas Inc.
> 179 Colonnade Road-Suite 100, Ottawa ON, Canada
> Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1 613-601-2734
> Web: http://zafin.com  Email: gordon.c...@zafin.com
>
> --
> Zafin - Canada
>
> --
> http://zafin.com
>
> 
>
> --
>
> Connect with us
>
> 
>   
>
> News and Events
>
> Zafin announces 100 person Center of Excellence in Toronto
> <
> http://zafin.com/press-releases/zafin-announces-new-100-person-centre-excellence-toronto/
> >
>
> For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and Fast
> 500 rankings
> <
> http://zafin.com/press-releases/zafin-named-deloitte-technology-fast-50-fast-500-lists/
> >
>
> <
> http://zafin.com/press-releases/zafin-ranks-16th-on-the-2014-deloitte-technology-fast-50-list/
> >
>

Re: Create test jar during build without attaching

[Christopher]

It is a test resource, built from source. I think it's substantively
different from a jpg, because it is derived from the creative work (source
code), and does not itself represent the creative work like a jpg does.
Compiled code does not meet the definition of open source from the Open
Source Initiative (https://opensource.org/osd), and we'd prefer to keep our
source code free from compiled code as much as possible. So, even if it
would be an "acceptable" case, we're trying to find a solution which avoids
that. We were actually doing that until recently, and we're trying to take
positive action to correct it.

In any case, my goal for this thread was to find solutions which allow me
to avoid having the binary in SCM, not to convince myself I don't need to.
:)

On Fri, Aug 19, 2016 at 4:44 AM Mirko Friedenhagen 
wrote:

> Hello Christopher,
>
> it seems the jar is a test resource, so it is not different from a jpg
> which could be included as well in this way IMO.
>
> Regards
> Mirko
> --
> Sent from my mobile
>
> Am 19.08.2016 03:47 schrieb "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

[Gordon Cody]

Perhaps I don't understand what is meant by "not attaching" but if all you
want to do is skip deployment, the maven-deploy-plugin has this feature:

true

which can be added to the module you do not wish to deploy. We use this in
order to not deploy .ear files to our artifactory.

Regards, Gord Cody

On Fri, Aug 19, 2016 at 1:37 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 19/08/16 03:36, 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.
>>
>
> Can you describe why you would like to create a jar which shouldn't be
> deployed ? May be we can enhance maven-jar-plugin to support such a use
> case?
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Best Regards, Gord Cody

Release Manager  Zafin Labs Americas Inc.
179 Colonnade Road-Suite 100, Ottawa ON, Canada
Phone: +1 (613) 216-2504  Fax: +1 (613) 688-1374  Mobile: +1 613-601-2734
Web: http://zafin.com  Email: gordon.c...@zafin.com

-- 
Zafin - Canada

-- 
http://zafin.com



--

Connect with us

  
  

News and Events

Zafin announces 100 person Center of Excellence in Toronto 


For the 2nd consecutive year, Zafin named to the Deloitte Fast 50 and Fast 
500 rankings 

Re: Create test jar during build without attaching

[jieryn]

Confirmed. Is it so bad, though? :) I like the argument comparing
putting .jpeg files in there.

On Fri, Aug 19, 2016 at 2:13 PM, Christopher  wrote:
> src/test/resources are included in the source-release artifact, yes.
>
> On Fri, Aug 19, 2016 at 1:56 AM jieryn  wrote:
>
>> 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
>>
>>

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

src/test/resources are included in the source-release artifact, yes.

On Fri, Aug 19, 2016 at 1:56 AM jieryn  wrote:

> 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: Create test jar during build without attaching

[Christopher]

On Fri, Aug 19, 2016 at 1:38 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 19/08/16 03:36, 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.
>
> Can you describe why you would like to create a jar which shouldn't be
> deployed ? May be we can enhance maven-jar-plugin to support such a use
> case?
>

The goal is to test a classloader during the integration-test phase. For
the same reason that most people don't deploy the test-jar (or even create
it), we don't want to deploy this jar.

Another reason why we wouldn't want to deploy is that the contents of the
jar might be dynamically generated, so that we can verify that the
classloader is loading classes from this particular execution of the test,
and isn't being loaded from somewhere else on the classpath. Deploying it
to maven would be suitable for reuse, but we wouldn't want reuse in this
case.

The more I think about it, I think the maven-jar-plugin isn't necessarily
appropriate for this. I think the maven-assembly-plugin is better suited to
create the jar, and that does have an option to not attach.

Re: Create test jar during build without attaching

[Karl Heinz Marbaise]

Hi,

On 19/08/16 03:36, 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.


Can you describe why you would like to create a jar which shouldn't be 
deployed ? May be we can enhance maven-jar-plugin to support such a use 
case?



Kind regards
Karl Heinz Marbaise

-
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

[Jeff Jensen]

I had the same need on a prior product, needed two jars to test the
processing.

After trying to find built-in Maven features/plugins to solve, including
Embedder and other "Maven runners" I found with Google, I found the
clearest and simplest approach was to make a nearly empty pom for each jar
in separate subdirectories in src/test/resources (along with the needed
files) and run Maven for each pom at test startup to install into local
repo.
I found the easiest way to run Maven was
final Runtime runtime = Runtime.getRuntime();
runtime.exec(mvnCommand, envp, dir);

* Creating mvnCommand required and used Maven home env var, detected which
OS for the script (to run mvn or mvn.cmd), and included "clean install".
* envp was null.
* dir was the respective pom.xml directory.

HTH


On Thu, Aug 18, 2016 at 8: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
> >
> >
>

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

[Curtis Rueden]

Hi Christian,

This is awesome.


== What works ==

With model version 4.0.0, Maven 3.4.0 now behaves exactly as before. And
the property overriding bug no longer occurs, either. This maintains build
reproducibility for my projects, for which I am very thankful.

With model version 4.1.0, Maven 3.4.0 complains about my project thusly:

[ERROR] Cannot inherit from parent 'org.scijava:pom-scijava:pom:10.6.0'
with different model version '4.0.0'. Expected model version '4.0.0'.

Followed by many of:

[WARNING] Multiple conflicting imports of dependency ...

And after updating all POM ancestors to model 4.1.0, the build succeeds
again, but with the new Maven 3.4.0 behavior.


== What doesn't work ==

The only remaining problem is that with model version 4.1.0, version
property overrides in the POM still do not win over imported BOMs.

That is, with the addition of something like:

$ git diff -U1
diff --git a/pom.xml b/pom.xml
index d04c102..c75eb45 100644
--- a/pom.xml
+++ b/pom.xml
@@ -38,2 +38,3 @@
net.imagej.Main
+   2.0.0-rc-49


With model version 4.0.0 the override works:

$ mvn dependency:list|grep 'net.imagej:imagej:'
[INFO]net.imagej:imagej:jar:2.0.0-rc-49:compile

Whereas with model version 4.1.0 there is no override anymore:

$ mvn340 dependency:list|grep 'net.imagej:imagej:'
[WARNING] Multiple conflicting imports of dependency
'net.imagej:imagej:jar' into model '[inherited]:fiji:jar:2.0.0-SNAPSHOT' @
'/Users/curtis/code/fiji/fiji/pom.xml' ('256 : 16,
net.imagej:pom-imagej:15.5.0
/Users/curtis/.m2/repository/net/imagej/pom-imagej/15.5.0/pom-imagej-15.5.0.pom',
'256 : 16, net.imagej:pom-imagej:15.6.0
/Users/curtis/.m2/repository/net/imagej/pom-imagej/15.6.0/pom-imagej-15.6.0.pom').
To resolve this conflict, either declare the dependency directly in the
dependency management of model '[inherited]:fiji:jar:2.0.0-SNAPSHOT' to
override what gets imported or, as of Maven 3.4, rearrange the causing
imports in the inheritance hierarchy to apply standard override logic based
on artifact coordinates. Without resolving this conflict, your build relies
on indeterministic behaviour.
[INFO]net.imagej:imagej:jar:2.0.0-rc-48:compile

I can create an MCVE if that would be helpful; just let me know.

Regards,
Curtis

P.S. Thanks and kudos to Herve Boutemy et al. for the colorized output. So
beautiful!

--
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 Fri, Aug 19, 2016 at 3:05 AM, Christian Schulte  wrote:

> Am 08/17/16 um 22:16 schrieb Curtis Rueden:
> > 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?
>
> Parent and child need to use the same model version. There is no way to
> support inheritable import scope when a parent is 4.0.0 and a child is
> 4.1.0. Importing a 4.0.0 model into a 4.1.0 and vice versa is possible.
> Current master already has been updated. You can grab a recent
> 3.4.0-SNAPSHOT from here:
> 
>
> It would be great if you could test that existing 4.0.0 projects behave
> exactly as before and that updating the model version to 4.1.0 you get
> the new behaviour. Thanks.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Replacement for org.apache.maven.monitor.event.EventDispatcher?

[Konrad Windszus]

The EventDispatcher support was completely removed with the commit 
https://github.com/apache/maven/commit/505423e666b9a8814e1c1aa5d50f4e73b8d710f4 
for Maven 3.0.
Currently I instead use a JVM Shutdown Hook to perform some tasks at the end of 
the build which is not recommended either for obvious reasons (see 
https://maven.apache.org/plugin-developers/common-bugs.html#Using_Shutdown_Hooks).

What is the recommended way on how to perform some tasks at the end of the 
reactor build?
Thanks,
Konrad



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

Exchange data in memory between different mojo executions in different modules of the same plugin

[Konrad Windszus]

To exchange data between several executions of my mojo I wanted to leverage 
AbstractMojo.getPluginContext(). Unfortunately although the map is being shared 
among multiple executions targeting the same project it is not shared among 
different projects in a multi-module build. 
Which API can I leverage to share data between multiple mojo executions even 
across project borders?

The only way I could get that working was using 
MavenSession.getExecutionProperties(), but that was deprecated a long time ago 
and also that doesn't seem to be thread-safe (i.e. if the modules are built at 
the same time in different threads you run into issues, because multiple 
modules could get a different Properties object.

Any hints onto which object I could bind myself to share arbitrary Java objects 
among all mojo executions?

Maybe there is some existing Plexus Component (which is only instantiated once) 
which I could inject and which allows to write/read arbitrary objects from/to 
it.
Thanks for any help,
Konrad
-
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

[Mirko Friedenhagen]

Hello Christopher,

it seems the jar is a test resource, so it is not different from a jpg
which could be included as well in this way IMO.

Regards
Mirko
-- 
Sent from my mobile

Am 19.08.2016 03:47 schrieb "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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 08/17/16 um 22:16 schrieb Curtis Rueden:
> 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?

Parent and child need to use the same model version. There is no way to
support inheritable import scope when a parent is 4.0.0 and a child is
4.1.0. Importing a 4.0.0 model into a 4.1.0 and vice versa is possible.
Current master already has been updated. You can grab a recent
3.4.0-SNAPSHOT from here:


It would be great if you could test that existing 4.0.0 projects behave
exactly as before and that updating the model version to 4.1.0 you get
the new behaviour. Thanks.

Regards,
-- 
Christian


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

[Stephane Nicoll]

On Thu, Aug 18, 2016 at 5:24 PM, Curtis Rueden  wrote:

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

I agree that both the doc and the code are missing a piece. I am not
blaming you (or anyone, we did it too!) for creating such project structure
:)


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


Fully agree.



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


Sounds good to me!

Cheers,
S.




> 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 <
> stephane.nic...@gmail.com>
> 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 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