Re: Continuous Delivery with Maven now possible?

[Curtis Rueden]

Hi Dan, Karl & everyone,

> See Karl's Blog

Link, please?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, May 3, 2017 at 7:54 PM, Dan Tran <dant...@gmail.com> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <ebenza...@gmail.com> wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Charles & everyone,

> To prevent SNAPSHOT churn you can use a plugin like
> exists-maven-plugin
> (https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html
> <https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html>)
> to prevent re-releasing unchanged artifacts.

Thanks for the suggestion. I think exists-maven-plugin is really useful for
some scenarios.

However, I want to comment that I think one should not use
exists-maven-plugin in this way to address a symptom—400 forbidden errors
when redeploying same version to remote repository—rather than the root
problem of having two commits with the same release version number. With
this scheme, any time you build a commit from the history including the
"install" phase (e.g., if testing something with "git bisect"), you may end
up overwriting the release version in your local repository cache with
something which is _not_ actually the release build of the component. So I
think it is dangerous to lean on exists-maven-plugin in this way. I
actually _want_ the build to fail in the CI at the deploy step, to give me
a heads up that there are two commits like this, so that the problem can be
fixed before even more commits are made at that same version number.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Mon, Apr 24, 2017 at 9:09 PM, Charles Honton <c...@honton.org> wrote:

> To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin (
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html <
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html>) to
> prevent re-releasing unchanged artifacts.
>
> chas
>
> > On Apr 24, 2017, at 1:52 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > because every release concludes
> > with a "bump to next development cycle" commit
>
>

Re: javafx-maven-plugin seems to ignore finalName parameter

[Curtis Rueden]

Hi Uwe,

The javafx-maven-plugin is not a core Maven plugin, nor a Mojohaus one, so
you are probably better off filing an issue in the repository (
https://github.com/javafx-maven-plugin/javafx-maven-plugin/issues). I am
not sure whether FibreFoX even subscribes to this mailing list, and he
would be the best person to answer you.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Apr 27, 2017 at 8:23 AM, Uwe <uwe.ander...@amsde.com> wrote:

> I want the javafx-maven-plugin to create a jar file but without the version
> number in the file name.
> So I added
> ${project.artifactId}
> to the configuration section but the plugin seems to ignore that.
> What is wrong?
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/javafx-maven-plugin-seems-to-ignore-finalName-parameter-tp5907231.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

es?

Moreover, I don't see the value of discontinuing these special keywords. It
breaks backwards compatibility for no technical or social advantage that I
can see. I am not trying to be difficult—if there was a rationale written
somewhere for why these keywords are bad, I would love to see it!—but the
only rationale I have actually found are vague and brief statements
repeated second-hand that these keywords are somehow harmful to
reproducibility. But as I argued in this thread's first post:
reproducibility is still in danger thanks to version ranges and snapshots.
The better solution here to encourage reproducibility is to actually
encourage it via warnings—see below.

> And what do you think is constructive to address the problem of
> reproducibility ?

Generally speaking, I think it should be illegal to deploy release versions
whose dependencies result in irreproducible builds. To enforce that, we
went so far as to write a new enforcer rule (part of
org.scijava:scijava-maven-plugin):

https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/maven/plugin/enforcer/
RequireReproducibleBuilds.java#L53-L69
https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/
maven/plugin/SnapshotFinder.java#L46-L61

This rule fails the build if it finds a SNAPSHOT parent, or any SNAPSHOT
dependencies, recursively throughout the dependency tree. Because of this,
we actually found some problematic releases on Central which have snapshot
dependencies deep in their dependency trees. I cannot recall whether this
rule currently fails the build if there are any version ranges, but I think
it ought to do so.

Our projects all require reproducible builds always on the master branch.
Among other benefits, this allows "git bisect" to work reliably. See
http://imagej.net/Architecture#Reproducible_builds for further discussion.

I think that by default, Maven should warn if a build is irreproducible
like this. That way, people new to Maven will be less likely to suffer pain
later due to ignorance of this issue. People need to know when their builds
are vulnerable. As things stand, I think many people just use a "snapshots
all the time" approach because it is initially easier, without realizing
how this will burn them in the future.

That said, I also think there should be a property to disable the warning,
since there are valid use cases (see above) for using rolling versions.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Mon, Apr 24, 2017 at 2:24 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi,
>
> On 24/04/17 19:46, Curtis Rueden wrote:
>
>> Hi Jesse,
>>
>> Prefer to harden the version # in a corporate pom. Then use
>>> versions-m-p to detect and update bulk dependencies across all our
>>> projects. We manage about 350 dependencies in the corporate pom
>>>
>>
>> Definitely agreed. I am managing a similar number, and indeed versions-m-p
>> is super nice for displaying which dependencies have new versions
>> available. (Must remember to feed -U to mvn, though!)
>>
>>
> Not only for displaying...you can also use it to update them...
>
> Yes I know there are issues in that plugin (I'm currently working on an
> larger update https://github.com/mojohaus/versions-maven-plugin/commits/ma
> ster)...
>
> Also updating to newer release versions can be done with that and
> correctly checked in into version control.
>
> I am still looking for an easy way to answer the other question: "Have
>> there been changes to this component since the last release" -- i.e. "Does
>> this component need a new release"
>>
>
> Maybe I misunderstand a thing here but the first part can be answered by
> using your version control? Make a diff between latest release tag and the
> current trunk/master ? If a component needs a release is something which
> only can being answered by a human...
>
> But might it be a good idea for a plugin ? If we could get more concrete
> I'm willing to implement such things if this will help...
>
>
> > -- since we use release-ready master
>
>> branches.
>>
>
> > I think the allowSnapshots property is not sufficient in my case,
>
>> since the CI will always deploy a new SNAPSHOT in response to the "Bump to
>> next development cycle" commit which does nothing else besides bump the
>> version on master after each release.
>>
>
> What is the problem with that? Your repository manager should be
> configured in that way that SNAPSHOT's will automatically being removed
> after a time ?
>
>
>
>
>> And eve

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Jesse,

> Prefer to harden the version # in a corporate pom. Then use
> versions-m-p to detect and update bulk dependencies across all our
> projects. We manage about 350 dependencies in the corporate pom

Definitely agreed. I am managing a similar number, and indeed versions-m-p
is super nice for displaying which dependencies have new versions
available. (Must remember to feed -U to mvn, though!)

I am still looking for an easy way to answer the other question: "Have
there been changes to this component since the last release" -- i.e. "Does
this component need a new release" -- since we use release-ready master
branches. I think the allowSnapshots property is not sufficient in my case,
since the CI will always deploy a new SNAPSHOT in response to the "Bump to
next development cycle" commit which does nothing else besides bump the
version on master after each release.

And even if somehow the versions-m-p had a magicallySolveAllMyProblems flag
here, I still believe there are other use cases where RELEASE and LATEST
are useful -- and that deprecating/removing them does not do anything
constructive to address the problem of irreproducible builds.

Regards,
Curtis

P.S. to Rick Huff: Thanks for taking the time to reply. :-)

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Mon, Apr 24, 2017 at 12:37 PM, jieryn <jie...@gmail.com> wrote:

> Prefer to harden the version # in a corporate pom. Then use
> versions-m-p to detect and update bulk dependencies across all our
> projects. We manage about 350 dependencies in the corporate pom, and
> that doesn't even include the huge number that are scope=import for
> Arquillian and Selenium, etc.
>
> On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:
> >> I would like to argue for the inclusion / restoration / continued
> >> support of the RELEASE and LATEST tags.
> >
> > Really? No one else cares enough to respond?
> >
> > I am very often running into use cases where the easiest solution seems
> to
> > be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
> > and I need to know things like "which components have new releases
> > available" and "which components have SNAPSHOT builds since the last
> > release." How do other people answer these questions without custom
> > tooling, and without using LATEST or RELEASE tags?
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://loci.wisc.edu/software
> > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> >
> >
> > On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <ctrue...@wisc.edu>
> wrote:
> >
> >> Hi Maven developers,
> >>
> >> I would like to argue for the inclusion / restoration / continued
> support
> >> of the RELEASE and LATEST tags.
> >>
> >> Reasons:
> >>
> >> 1) There are many valid use cases for them. For example, my script jrun
> >> [1] uses RELEASE right now to make it easier to launch a Maven GAV.
> >> Launching e.g. the Jython REPL is as easy as "jrun
> >> org.python:jython-standalone" from the CLI. But this relies on RELEASE
> >> working. I know that Maven is traditionally viewed as primarily a
> >> build-time tool, but it is also extremely useful for synthesizing
> runtime
> >> environments, and IMHO underutilized in this regard.
> >>
> >> 2) For LATEST, you can achieve basically the same behavior using a
> version
> >> range like [0,). There is no other way (that I know of) to achieve what
> the
> >> RELEASE tag does.
> >>
> >> 3) The argument that they harm reproducibility is totally valid. But so
> do
> >> SNAPSHOTs, and so do version ranges. And those have not been
> deprecated. So
> >> why are RELEASE and LATEST eschewed so heavily?
> >>
> >> Orthogonally: I think it would be awesome to warn about irreproducible
> >> builds, be they from SNAPSHOTs, version ranges, or these special
> keywords.
> >> People need to know when their builds are vulnerable. But there should
> >> probably also be a property to disable this warning, for the cases when
> the
> >> developer intentionally wants/needs to use them, and knows what they are
> >> doing. If the issue is just that no ones has time to work on e.g.
> MNG-6206,
> >> I could try to make some time for it—I feel strongly enough about this
> >> issue.
> >>
> >> Thanks for any insig

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

> I would like to argue for the inclusion / restoration / continued
> support of the RELEASE and LATEST tags.

Really? No one else cares enough to respond?

I am very often running into use cases where the easiest solution seems to
be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
and I need to know things like "which components have new releases
available" and "which components have SNAPSHOT builds since the last
release." How do other people answer these questions without custom
tooling, and without using LATEST or RELEASE tags?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Maven developers,
>
> I would like to argue for the inclusion / restoration / continued support
> of the RELEASE and LATEST tags.
>
> Reasons:
>
> 1) There are many valid use cases for them. For example, my script jrun
> [1] uses RELEASE right now to make it easier to launch a Maven GAV.
> Launching e.g. the Jython REPL is as easy as "jrun
> org.python:jython-standalone" from the CLI. But this relies on RELEASE
> working. I know that Maven is traditionally viewed as primarily a
> build-time tool, but it is also extremely useful for synthesizing runtime
> environments, and IMHO underutilized in this regard.
>
> 2) For LATEST, you can achieve basically the same behavior using a version
> range like [0,). There is no other way (that I know of) to achieve what the
> RELEASE tag does.
>
> 3) The argument that they harm reproducibility is totally valid. But so do
> SNAPSHOTs, and so do version ranges. And those have not been deprecated. So
> why are RELEASE and LATEST eschewed so heavily?
>
> Orthogonally: I think it would be awesome to warn about irreproducible
> builds, be they from SNAPSHOTs, version ranges, or these special keywords.
> People need to know when their builds are vulnerable. But there should
> probably also be a property to disable this warning, for the cases when the
> developer intentionally wants/needs to use them, and knows what they are
> doing. If the issue is just that no ones has time to work on e.g. MNG-6206,
> I could try to make some time for it—I feel strongly enough about this
> issue.
>
> Thanks for any insight, workarounds, counterarguments, agreement.
> (Especially if you agree: please speak up, so the core Maven devs know I'm
> not just an outlier here!)
>
> Regards,
> Curtis
>
> [1] https://github.com/ctrueden/jrun
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>

Re: understanding maven version resolution: minor and snapshots

[Curtis Rueden]

Hi Jörg,

As far as I know, Maven has no notion of "major" vs. "minor" vs. "patch"
versions in the style of e.g. SemVer.

It simply judges which version is the newest via its algorithm, and uses
the newest, since it is assumed that a dependency on e.g. 3.2.0 means
"version must be at least as new as 3.2.0".

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Fri, Apr 21, 2017 at 6:18 PM, Jörg Wille <joerg.wi...@gmail.com> wrote:

> In a project 2 "different" versions of the same library A are used. One, as
> a direct dependency with a snapshot version *3.2.1-SNAPSHOT* and the same
> library - but with version *3.2.0* -  is being used as a transient
> dependency in yet another library B. So, the 2 dependencies of A only
> differ in the minor version.
> When I build/install this project only the 3.2.1-SNAPSHOT version of
> library A gets downloaded.
> Is this correct behaviour for maven since it evaluates the 3.2.1-SNAPSHOT
> to be compatible with the 3.2.0 release version or should maven download
> the 3.2.0 release version since it is explicit mentioned as a transient
> dependency in the pom of a  library B?
>

Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Maven developers,

I would like to argue for the inclusion / restoration / continued support
of the RELEASE and LATEST tags.

Reasons:

1) There are many valid use cases for them. For example, my script jrun [1]
uses RELEASE right now to make it easier to launch a Maven GAV. Launching
e.g. the Jython REPL is as easy as "jrun org.python:jython-standalone" from
the CLI. But this relies on RELEASE working. I know that Maven is
traditionally viewed as primarily a build-time tool, but it is also
extremely useful for synthesizing runtime environments, and IMHO
underutilized in this regard.

2) For LATEST, you can achieve basically the same behavior using a version
range like [0,). There is no other way (that I know of) to achieve what the
RELEASE tag does.

3) The argument that they harm reproducibility is totally valid. But so do
SNAPSHOTs, and so do version ranges. And those have not been deprecated. So
why are RELEASE and LATEST eschewed so heavily?

Orthogonally: I think it would be awesome to warn about irreproducible
builds, be they from SNAPSHOTs, version ranges, or these special keywords.
People need to know when their builds are vulnerable. But there should
probably also be a property to disable this warning, for the cases when the
developer intentionally wants/needs to use them, and knows what they are
doing. If the issue is just that no ones has time to work on e.g. MNG-6206,
I could try to make some time for it—I feel strongly enough about this
issue.

Thanks for any insight, workarounds, counterarguments, agreement.
(Especially if you agree: please speak up, so the core Maven devs know I'm
not just an outlier here!)

Regards,
Curtis

[1] https://github.com/ctrueden/jrun

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Tue, Apr 11, 2017 at 4:56 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi,
>
>
> On 11/04/17 23:38, Stephen Connolly wrote:
>
>> On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote:
>>
>> Hi Stephen,
>>>
>>> There is a special version keyword LATEST which means the very newest
>>>>> version, snapshot or otherwise. And RELEASE means the newest release
>>>>> (non-SNAPSHOT) version.
>>>>>
>>>>
>>>> Support for those were dropped in Maven 3
>>>>
>>>
>>> By "support" do you mean "social support" as opposed to technical
>>> functionality?
>>>
>>
>>
>> They were supposed to be removed.
>>
>> If they are working now, that's a bug
>>
>
> Unfortunately they are working ;-(..
>
> https://issues.apache.org/jira/browse/MNG-6206
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>>
>>> Because they are still present in the codebase, and they still work
>>> technically:
>>>https://github.com/apache/maven/blob/master/maven-
>>> resolver-provider/src/main/java/org/apache/maven/repository/internal/
>>> DefaultVersionResolver.java#L188-L197
>>>
>>> Regards,
>>> Curtis
>>>
>>> --
>>> Curtis Rueden
>>> LOCI software architect - https://loci.wisc.edu/software
>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>>
>>>
>>> On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:
>>>>
>>>> Hi Hector,
>>>>>
>>>>> This is fine as long as the dependency is always set to
>>>>>>
>>>>> x.y.z-Snapshot
>>>
>>>> and the dependency is always overwritten this way.  What if the
>>>>>> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot,
>>>>>>
>>>>> x.y.z.3-Snapshot
>>>
>>>> and I want the dependent build to always get the latest in this case,
>>>>>> x.y.z.3-Snapshot ?
>>>>>>
>>>>>
>>>>> There is a special version keyword LATEST which means the very newest
>>>>> version, snapshot or otherwise. And RELEASE means the newest release
>>>>> (non-SNAPSHOT) version.
>>>>>
>>>>
>>>>
>>>> Support for those were dropped in Maven 3
>>>>
>>>> *and* anyway they were only for *plugin* versions because the plugin
>>>> version does not support ranges.
>>>>
>>>> For dependency versions, define a range
>>>>
>>>>
>

Re: dependency question

[Curtis Rueden]

Hi Stephen,

> > There is a special version keyword LATEST which means the very newest
> > version, snapshot or otherwise. And RELEASE means the newest release
> > (non-SNAPSHOT) version.
>
> Support for those were dropped in Maven 3

By "support" do you mean "social support" as opposed to technical
functionality?

Because they are still present in the codebase, and they still work
technically:
   https://github.com/apache/maven/blob/master/maven-
resolver-provider/src/main/java/org/apache/maven/repository/internal/
DefaultVersionResolver.java#L188-L197

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi Hector,
> >
> > > This is fine as long as the dependency is always set to x.y.z-Snapshot
> > > and the dependency is always overwritten this way.  What if the
> > > producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot
> > > and I want the dependent build to always get the latest in this case,
> > > x.y.z.3-Snapshot ?
> >
> > There is a special version keyword LATEST which means the very newest
> > version, snapshot or otherwise. And RELEASE means the newest release
> > (non-SNAPSHOT) version.
>
>
> Support for those were dropped in Maven 3
>
> *and* anyway they were only for *plugin* versions because the plugin
> version does not support ranges.
>
> For dependency versions, define a range
>
> >
> >
> > Similar to version ranges, Maven will have to ask the remote repository
> > about the latest known version in these cases, and will then use that.
> >
> > I want to emphasize, as others have mentioned, that using any of these
> > strategies will result in _irreproducible builds_. That is, your code
> might
> > build today, and then the same code will fail to build in the future,
> > because the versions will resolve differently. The only way (I know of)
> to
> > achieve reproducible builds is to use fixed release versions, always.
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://loci.wisc.edu/software
> > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> >
> >
> > On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
> hector.magna...@sap.com
> > >
> > wrote:
> >
> > > This is fine as long as the dependency is always set to x.y.z-Snapshot
> > and
> > > the dependency is always overwritten this way.  What if the producer
> > > produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I
> want
> > > the dependent build to always get the latest in this case,
> > > x.y.z.3-Snapshot ? The difference with this scenario is that the
> producer
> > > will always have a new build number.
> > > As for your solution of using the range,  do I always have to change
> the
> > > pom file in the dependent build whenever a new build is produced by the
> > > producer ?
> > >
> > > -Original Message-
> > > From: Benson Margulies [mailto:bimargul...@gmail.com]
> > > Sent: Monday, April 10, 2017 10:39 AM
> > > To: Maven Users List <users@maven.apache.org>
> > > Subject: Re: dependency question
> > >
> > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > > <hector.magna...@sap.com> wrote:
> > > > I'm still a little confused about the answers I'm getting.  So, if
> > build
> > > A is being updated with a new build number(even for a snapshot), and
> > build
> > > B has it as a dependency in it's pom.file, how does the pom file in
> > Build B
> > > need to look like in the dependency section so that it does get the
> > latest
> > > snapshot build of build A ?
> > >
> > > This conversation seems to keep mixing up SNAPSHOT version processing
> > > with various conventions for using version ranges.
> > >
> > > If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
> > > dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
> > > to the repositories to look for the latest snapshot build.
> > >
> > > Snapshots have risks and do not provide a repeatable build. Then
> > > again, neither do ranges.
> > >
> > > If you don't want to use snapshots, then you wr

Re: dependency question

[Curtis Rueden]

Hi Hector,

> This is fine as long as the dependency is always set to x.y.z-Snapshot
> and the dependency is always overwritten this way.  What if the
> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot
> and I want the dependent build to always get the latest in this case,
> x.y.z.3-Snapshot ?

There is a special version keyword LATEST which means the very newest
version, snapshot or otherwise. And RELEASE means the newest release
(non-SNAPSHOT) version.

Similar to version ranges, Maven will have to ask the remote repository
about the latest known version in these cases, and will then use that.

I want to emphasize, as others have mentioned, that using any of these
strategies will result in _irreproducible builds_. That is, your code might
build today, and then the same code will fail to build in the future,
because the versions will resolve differently. The only way (I know of) to
achieve reproducible builds is to use fixed release versions, always.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <hector.magna...@sap.com>
wrote:

> This is fine as long as the dependency is always set to x.y.z-Snapshot and
> the dependency is always overwritten this way.  What if the producer
> produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want
> the dependent build to always get the latest in this case,
> x.y.z.3-Snapshot ? The difference with this scenario is that the producer
> will always have a new build number.
> As for your solution of using the range,  do I always have to change the
> pom file in the dependent build whenever a new build is produced by the
> producer ?
>
> -Original Message-
> From: Benson Margulies [mailto:bimargul...@gmail.com]
> Sent: Monday, April 10, 2017 10:39 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
>
> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> <hector.magna...@sap.com> wrote:
> > I'm still a little confused about the answers I'm getting.  So, if build
> A is being updated with a new build number(even for a snapshot), and build
> B has it as a dependency in it's pom.file, how does the pom file in Build B
> need to look like in the dependency section so that it does get the latest
> snapshot build of build A ?
>
> This conversation seems to keep mixing up SNAPSHOT version processing
> with various conventions for using version ranges.
>
> If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
> dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
> to the repositories to look for the latest snapshot build.
>
> Snapshots have risks and do not provide a repeatable build. Then
> again, neither do ranges.
>
> If you don't want to use snapshots, then you write the dependency in
> the consumer with a range
>
> (1.0-2.0]
>
> or whatever makes sense. This will cause builds of the consumer to go
> out to repositories and try to find the newest version within the
> range. it's up to you to bump the version in the producer, manually or
> with the maven-release-plugin.
>
>
>
>
> >
> > Scenario:
> >
> > Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot
> and they are all being uploaded to a repository.
> >
> > What will the pom file in build B look like so that the next time build
> B is executed,  3-snapshot for build A will be picked up ?
> >
> > -Original Message-
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Friday, April 7, 2017 10:50 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: dependency question
> >
> > Hi Russlel,
> > On 07/04/17 17:29, Russell Gold wrote:
> >
> >> That’s the way it works: when you specify a snapshot, it takes the
> latest.
> >
> > This is not 100% true, cause it depends on the update policy you have
> > defined in your settings either explicit or by default the updates will
> > be checked every 24 hours...
> >
> > If you like to force this you can use mvn -U ...or define a different
> > updatePolicy in your settings.xml for the appropriate repository.
> >
> > By using mvn -U you make sure for running this build Maven will check if
> > there are newer SNAPSHOT version available for dependencies which have
> > defined a SNAPSHOT version
> >
> > This is working for a single module project...but if you have a multi
> > module build (Project C: A1 build before A2) which takes for example 5
> > minutes to build ...this is no lo

Re: Set Windows File Version metadata?

[Curtis Rueden]

Hi James,

Did you have a look at the packaging system of JavaFX?
http://docs.oracle.com/javafx/2/deployment/self-contained-
packaging.htm#A1324980

This is a separate thing from JavaFX the UI library; it can be used to
deploy non-JFX-based (e.g., Swing) desktop applications.

There is a pretty nice Maven plugin for it, too:
https://github.com/javafx-maven-plugin/javafx-maven-plugin

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Mon, Apr 10, 2017 at 6:03 AM, James Green <james.mk.gr...@gmail.com>
wrote:

> Is this possible?
>
> I'm looking at wrapping my jar file in a Windows installer package and it
> would be a lot easier if the jar on disk had a version attribute set by
> Maven.
>
> Can't see much beyond Google answers about how to use Maven on Windows :(
>
> Thanks,
>
> James
>

Re: How to add class file to build & classpath?

[Curtis Rueden]

Hi Dave,

I cooked up an example of the multi-module approach which I hope helps:

https://github.com/ctrueden/adhoc-classes

The adhoc-dependency modules just generates a class file by some arbitrary
means via the exec-maven-plugin. In my case, this is a shell script which
calls javac, but in your case it will be your javassist-based approach of
course.

The main-project module depends on the adhoc-dependency module just fine,
and is able to see the generated class without issue.

Does it work for you?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Apr 6, 2017 at 12:45 PM, David Hoffer <dhoff...@gmail.com> wrote:

> Yes that is the location the class file(s) are being created in.  And yes I
> am binding the exec-maven-plugin to the compile phase in my pom (see prior
> email).  Also the class(s) file is being included in the resulting jar.
> However all this is not sufficient for Maven to notice the class(s) file
> was generated and add to the build and classpath.
>
> I think part of the reason is that in multi-module maven builds it does not
> use the jars for the classpath but rather the pre-jar content (not 100%
> certain of that).  However I don't know why Maven doesn't add/use all files
> in the ./target/classes folder but only uses files that it put there
> itself.
>
> What am I missing here?  It seems this should just work because the files
> are in the ./target/classes folder.
>
> -Dave
>
> On Thu, Apr 6, 2017 at 10:55 AM, Robert Patrick <robert.patr...@oracle.com
> >
> wrote:
>
> > Can't you generated class files in the expected location (in
> > ${project.build.directory}/classes directory) during the compile phase?
> > I would expect these classes to be included in classpath for later pahses
> > and in the JAR created during the packaging phase of the module build
> > (assuming packaging type is "jar").  Have you tried that?
> >
> >
> >
> > -Original Message-
> > From: Curtis Rueden [mailto:ctrue...@wisc.edu]
> > Sent: Thursday, April 06, 2017 11:34 AM
> > To: Maven Users List
> > Subject: Re: How to add class file to build & classpath?
> >
> > Hi Dave,
> >
> > > I'm using exec-maven-plugin to call a main in my code that uses
> > > javassist to generate a class file at build time.
> >
> > The more common pattern is to generate .java source files, and then
> > include them in the build.
> >
> > Since you are generating .class file(s), could you do it in a separate
> > module of a multi-module build, then add that module as a dependency to
> > your main project module?
> >
> > Could you post an MCVE, particularly your POM, which shows your current
> > approach?
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://urldefense.proofpoint.
> > com/v2/url?u=https-3A__loci.wisc.edu_software=DwIBaQ=
> > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
> > Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=
> > sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M=
> > yDl8PjVnueV1WAKs6W36AGN5yriHr-5eTXTPZi_k0kk=
> > ImageJ2 lead, Fiji maintainer - https://urldefense.proofpoint.
> > com/v2/url?u=https-3A__imagej.net_User-3ARueden=DwIBaQ=
> > RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=
> > Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=
> > sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M=
> > biFYk60WuoVvD5FQonUNvMwQmBxfAOcXn6XyvvRRVDw=
> >
> >
> > On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer <dhoff...@gmail.com>
> wrote:
> >
> > > I'm using exec-maven-plugin to call a main in my code that uses
> javassist
> > > to generate a class file at build time.  My code places the class file
> in
> > > the ./target/classes folder so it gets included in the modules normal
> > > binary jar.
> > >
> > > However the rest of the build and other code needs to know that the
> class
> > > exists.  I've added that module/artifact as a dependency but the build
> > and
> > > the runtime classpath has no idea that class exists.
> > >
> > > How do I add it to the build and runtime classpath?
> > >
> > > -Dave
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: How to add class file to build & classpath?

[Curtis Rueden]

Hi Dave,

> I'm using exec-maven-plugin to call a main in my code that uses
> javassist to generate a class file at build time.

The more common pattern is to generate .java source files, and then include
them in the build.

Since you are generating .class file(s), could you do it in a separate
module of a multi-module build, then add that module as a dependency to
your main project module?

Could you post an MCVE, particularly your POM, which shows your current
approach?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer <dhoff...@gmail.com> wrote:

> I'm using exec-maven-plugin to call a main in my code that uses javassist
> to generate a class file at build time.  My code places the class file in
> the ./target/classes folder so it gets included in the modules normal
> binary jar.
>
> However the rest of the build and other code needs to know that the class
> exists.  I've added that module/artifact as a dependency but the build and
> the runtime classpath has no idea that class exists.
>
> How do I add it to the build and runtime classpath?
>
> -Dave
>

Re: Getting maven to create a bundle manifest incrementally in eclipse

[Curtis Rueden]

Hi Bill,

Since this is an M2E question, consider asking on the m2e-users list:
https://dev.eclipse.org/mailman/listinfo/m2e-users

Personally, I do not know the answer. You obviously have "
true" so you would think that Eclipse
would re-execute it every time an incremental build occurs. But I don't
have a deep understanding of the M2E integration.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Tue, Mar 21, 2017 at 10:01 AM, Bill Mair <b...@billmairsolutions.ltd.uk>
wrote:

> Hi,
>
> I'm attempting to switch to maven to create my packages but I have hit a
> snag that I can't find a solution for.
>
> Up until now, I have been controlling the dependencies of my ant build
> process with the contents of "META-INF/MANIFEST.MF". Maven works the
> other way around and generates that based on what I have actually used,
> which I think is fantastic.
>
> I already have the git hash being included by buildnumber-maven-plugin
> (which required the additional pluginManagement section to work
> correctly in eclipse).
>
> My problem is that this is only generated when I build the bundle and
> not during incremental saves.
>
> What do I have to change in this pom.xml to make eclipse, m2e, maven and
> the maven-bundle-plugin play nicely together?
>
> --
> Bill Mair
>
> pom.xml
> 
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>
> 
> test.iface
> test.iface
> UTF-8
> /MM/dd HH:mm:ss
> z
> 
>
> 4.0.0
> test
> test.iface
> 1.0.1
>
> 
> scm:git:file://.
> scm:git:file://.
> scm:git:file://.
> HEAD
> 
>
> 
> 
>  
> org.osgi
> org.osgi.core
> 5.0.0
> provided
> true
> 
> 
> org.osgi
> org.osgi.compendium
> 4.3.0
> provided
> true
> 
> 
> javax.jws
> jsr181-api
> 1.0-MR1
> 
> 
> junit
> junit
> 4.12
> compile
> true
> 
> 
>
> bundle
>
> 
> 
> 
> org.apache.felix
> maven-bundle-plugin
> 3.0.1
> true
> 
> META-INF
> 
>
> ${bundle.symbolicName}
> ${project.vers
> ion}
>
> ${project.organization.name}
> Copyright (C)
> ${project.organization.name}
>
>
> ${maven.build.timestamp} ntation-Build-Time>
>
> ${buildNumber}
>
> 
>
>
> !${bundle.namespace}.internal.*,${bundle.
> namespace}.*;version="${project.version}"
>
> 
> 
> 
> 
> 
> org.codehaus.mojo
> buildnumber-maven-plugin
> 1.4
> 
> 
> validate
> 
> create
> 
> 
> 
> 
> false
> false
> 
> 
>   
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.4
> 
> 
> attach-javadocs
> 
> jar
> 
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.1
> 
> 
> attach-sources
> 
> jar
> 
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.6.1
> 
> 1.7
>

Re: Gentoo packaging / reproducibility of Maven-based Java projects

[Curtis Rueden]

Hi Mark,

Thanks for the response.

> This is probably why you have so much trouble:  two package managers
> fighting for control.

I don't really think of Maven as a "package manager" but rather as a
structural tool, which should help make Portage's job _easier_, not harder.
Maven documents how the package dependencies are organized, and also makes
the actual build trivial (unless the Maven project in question requires
something non-standard, of course).

> The middle path might be:  package the dependencies individually, work
> out a way for Maven to see them as being present in the local
> repository, build the dependent happily using Maven.

Right, that is what we were discussing already on the linked issue thread.

> I don't know the guts of Maven well enough to say how hard it would be
> to plug in a new local-repository provider that uses the Gentoo
> /usr/share/*/lib layout.

We could do that, sure. Or we could just cheat with symlinks, to
manufacture a transient, lightweight local repository in a shape that Maven
knows already. :-)

The main question I have is about Maven plugins: since Maven builds do some
bootstrapping, but Gentoo builds are not supposed to download things from
the network, it means we might need a pre-baked Maven local repository
containing all commonly used plugins at various release versions? If so,
that would be unfortunate. I was hoping for some insight from others here.

> Binary dependencies are going to be a royal pain no matter how you do
> them.  Ugh!

Well, they need to be built from source. If they are cleanly Maven-based,
then we do things recursively the "easy" way. Otherwise, we need a custom
build script for each dependency with custom build requirements.
Dependencies which are too arduous to build from source will kill
downstream potential for inclusion with Gentoo, but that's always/already
true for a 100% source-based distro.

Regards,
Curtis

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


On Mon, Mar 20, 2017 at 8:45 AM, Mark H. Wood <mw...@iupui.edu> wrote:

> On Fri, Mar 17, 2017 at 02:11:20PM -0500, Curtis Rueden wrote:
> > I am currently discussing on GitHub with one of the Gentoo packagers the
> > possibility of packaging my group's Maven-based projects for Gentoo.
> >
> > The relevant issue is here:
> >  https://github.com/imagej/imagej/issues/162
> >
> > However, the issues are hardly unique to my projects. This has become a
> > very general discussion of rebuilding and packaging Maven projects.
> >
> > My questions are:
> > * Does anyone here use Gentoo?
>
> I do.
>
> > * Has anyone packaged their Maven-based stuff for it?
>
> No, I haven't contributed any packages to Gentoo yet.
>
> > * Does anyone know of a _general_ process for doing so?
>
> Typically a Gentoo package specifies all of its dependencies as Gentoo
> packages, and Portage does the dependency management.  This is
> probably why you have so much trouble:  two package managers fighting
> for control.  The "Gentoo Way" would seem to be:  first package all of
> the dependencies individually, get them into Portage, then add the
> dependent, adjust the POM to assume all dependencies will be supplied
> at runtime, and let Portage calculate the classpath.  Ick.
>
> There are some Gentoo packages based on projects which for some reason
> cannot or will not use stable releases of their dependencies, but
> instead package all of the source for those dependencies with the
> dependent code.  It's grating, but it works.  This is probably the
> easier route when using Maven in a Portage environment:  ship
> everything as subprojects and build it all together.
>
> The middle path might be:  package the dependencies individually, work
> out a way for Maven to see them as being present in the local
> repository, build the dependent happily using Maven.  I don't know the
> guts of Maven well enough to say how hard it would be to plug in a new
> local-repository provider that uses the Gentoo /usr/share/*/lib
> layout.
>
> Binary dependencies are going to be a royal pain no matter how you do
> them.  Ugh!  One thing this means is that your package can never exist
> for any architecture that the binary is not built for.  That's sadly
> not without precedent.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Gentoo packaging / reproducibility of Maven-based Java projects

[Curtis Rueden]

Hello Maven aficionados!

I am currently discussing on GitHub with one of the Gentoo packagers the
possibility of packaging my group's Maven-based projects for Gentoo.

The relevant issue is here:
 https://github.com/imagej/imagej/issues/162

However, the issues are hardly unique to my projects. This has become a
very general discussion of rebuilding and packaging Maven projects.

My questions are:
* Does anyone here use Gentoo?
* Has anyone packaged their Maven-based stuff for it?
* Does anyone know of a _general_ process for doing so?

I am very interested in creating such a process if it does not already
exist. I believe that Maven is poised to make doing this very easy -- much
easier than without it -- even for Java projects with a large number of
dependencies, due to its well-structured nature and clear metadata
declarations in the POM.

Do others agree? Disagree? I have seen other threads here in the past about
building an entire Java dependency hierarchy from source, and how the
-sources JARs are not intended for that. But nothing about real-world tools
for actually doing it, which are driven by the POM metadata and package
things recursively in a way that works for source-oriented Linux
distributions, or otherwise for reproducibility.

Comments and ideas very welcome.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden

Re: Maven password encryption by project

[Curtis Rueden]

Hi Alix,

For what it's worth, here is how the ImageJ project does it for Travis CI
builds:

https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f7114604e8485a75/.travis.yml
https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f7114604e8485a75/.travis/build.sh
https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f7114604e8485a75/.travis/settings.xml

To summarize the key points:

* The build invokes mvn with "--settings .travis/settings.xml", which is a
settings.xml committed to SCM
* This settings.xml uses "${env.MAVEN_PASS}" for the password.
* This MAVEN_PASS environment variable is stored encrypted in the
.travis.yml file; see:
  https://docs.travis-ci.com/user/environment-variables/

In our case, we are fine hardcoding the Maven deploy user as "travis", but
of course you could also make that configurable with MAVEN_USER variable or
similar.

For manual deployment, developers use their own ~/.m2/settings.xml with
their own credentials—i.e., for us, the .travis/settings.xml is _only_ for
Travis builds.

HTH,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Fri, Mar 17, 2017 at 8:38 AM, Alix Lourme <alix.lou...@gmail.com> wrote:

> Dear community,
>
> I'm searching the best practice for password encryption in a maven POM
> file *by
> project*, could by used by properties (like in ANT or WAGON). Sample :
> ---
> 
> maven-antrun-plugin
> 1.8
> 
> 
> 
> 
>  todir="cert" trust="yes" />
> 
> 
> 
> ---
>
> In this case, my *docker.password* could be a properties (pom or
> settings.xml) but must not be in clear text.
>
> The problem with Maven encryption
> <https://maven.apache.org/guides/mini/guide-encryption.html>:
> - I have a master password defined in *settings-security.xml* (locally) for
> my user need (like proxy password encryption in MY *settings.xml*)
> - The CI tools contains the same mechanism (own *settings-security.xml*)
> for global needs, like server encryption used in *settings.xml* for jar
> publication in repository ; and I can't retrieve this file
>
> => I can't use this mechanism for password encryption who works locally and
> on the CI server.
>
> *Is there a way to have a encryption mechanism for the project's perimeter
> ?* (and not for user's perimeter, current Maven encryption works perfectly
> for that).
>
> ---
>
> Using -s and -gs Maven options (=> user/global settings override) could be
> a workaround but :
> - Server item definition or properties defining password must be in clear
> text
> - Using this Maven settings for each build depending the project workspace
> is a little boring
>
> Perhaps is there a best way like a "private key by project" ... but I
> didn't found entry point about that.
>
> Thanks in advance. Best regards
> *NB*: This question was firstly on stackoverflow
> <https://stackoverflow.com/questions/33784790/maven-
> password-encryption-by-project>,
> but no really interest ^^.
> --
> Alix Lourme
>

Re: Plugin assembly: Howto use 'single' goal as an agregator ?

[Curtis Rueden]

Hi Alix,

Why not stick with the old version of maven-assembly-plugin until you have
to refactor your build more thoroughly?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Tue, Mar 14, 2017 at 1:06 PM, Alix Lourme <alix.lou...@gmail.com> wrote:

> Hello,
>
> Even if using aggregator is not a good practice in this case ... if there
> is a technical possibility to force the aggregation for a goal by pom
> configuration, I'll take it.
> Because after continuing to dig, I am in a dead-end ^^
>
> Many thanks.
> Best regards
>
> 2017-03-14 10:45 GMT+01:00 Alix Lourme <alix.lou...@gmail.com>:
>
> > Hi Karl Heinz,
> >
> > Thanks for your answer (and sorry for mine late).
> >
> > the best thing to create a separate module in your build with packaging
> >> pom and only put the maven-assembly-plugin in it and bind it to the life
> >> cycle
> >> This is simply a good way of following single responsibility principle.
> >>
> > try to get it as simple as possible which will result in just: mvn clean
> >> package.
> >>
> >
> > I'm fully agree with you (there is no debate), and this is an objective
> to
> > achieve in the future ...
> >
> > But ... when you have many projects (multiple hundred) using this bad
> way (*mvn
> > install assembly:attached*):
> > * Upgrading a parent (company pom) & changing a 'goal' is simple
> > * Reviewing completely the archive generation process (new module,
> > descriptor content) is a little bit more complicated
> >
> > So I hoped for a consensus to accompagn the transition
> > (maven-assembly-plugin v3.0.0) without project structure change :-).
> > I will affine pro & cons and ruling on the possibilities.
> >
> >
> > What I don't understand is your reference to maven-release-plugin and
> >> maven-invoker-plugin ?
> >>
> >
> > When you are using the previous (bad) way on maven-release-plugin, you
> > could define goals
> > <https://maven.apache.org/maven-release/maven-release-
> plugin/perform-mojo.html#goals>
> > with: *-Dgoals="install assembly:attached".* The result is "one Maven
> > command" like:
> > --
> >
> > [DEBUG] Executing: cmd.exe /X /C ""C:\[...]\mvn.bat" -B -X -D
> > maven.repo.local=C:\[...]\.m2\repository -f myApp -s
> > C:\[...]\AppData\Local\Temp\release-settingsXXX.xml -D
> > performRelease=true -P someProfiles install assembly:attached"
> > --
> > This reference to maven-release-plugin or invoker was just an argument
> for
> > a "only one Maven command" need ; avoiding ideas like: "*Just do two step
> > command, 'mvn install' and after 'mvn assembly:attached*'"
> >
> > Thanks
> > Best regards
> >
> > 2017-03-11 16:31 GMT+01:00 Karl Heinz Marbaise <khmarba...@gmx.de>:
> >
> >> Hi,
> >>
> >> If you like to produce a package (zip/tar/whatever kind of
> >> archive/bundle) which contains some modules/artifacts etc. from your
> multi
> >> module build it is the best thing to create a separate module in your
> build
> >> with packaging pom and only put the maven-assembly-plugin in it and
> bind it
> >> to the life cycle. This project contains all the needed dependencies in
> >> your assembly project pom...which should be packaged into your resulting
> >> archive (zip/tar/whatever).
> >>
> >> The assembly descriptor contains the appropriate
> >> dependencySets/moduleSets/sources etc. entries as needed.
> >>
> >> This makes it absolutely sure that using a simple:
> >>
> >> mvn clean package
> >>
> >> or
> >>
> >> mvn install
> >>
> >> everything is correctly packaged into the resulting bundle you would
> like
> >> to build.
> >>
> >> This is simply a good way of following single responsibility principle.
> >>
> >>
> >> This produces each time a correct and the same result in contradiction
> to
> >> your supplemental goal calling from command line (you just simply miss
> it?).
> >>
> >> Apart from that using fileSets is usually not the correct way cause it
> >> relies on the content which is on the file system which might sometimes
> not
> >> what you really like if you don't do:
> >>
> >> mvn clean
> >>
> >> before.
>

Re: uber source jar

[Curtis Rueden]

Hi Ben,

> Is there a well-known way to create an uber source jar? In other
> words, a jar of all the source code for a project and all its
> dependencies (or at least those that have a -sources.jar)?

Good question. The way I have done it is to explicitly enumerate all the
sources classifier JARs in a profile [1]. This is of course very yucky, and
I would love to know if there is a better way.

I definitely suggest you avoid uber-JARs (with or without embedded sources)
when possible, though; for a rationale, see http://imagej.net/Uber-JAR.

Regards,
Curtis

[1] https://github.com/imagej/imagej/blob/imagej-2.0.0-rc-
59/pom.xml#L395-L626

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, Mar 8, 2017 at 4:05 PM, Ben Tatham <bentat...@nanometrics.ca> wrote:

> Is there a well-known way to create an uber source jar? In other words, a
> jar of all the source code for a project and all its dependencies (or at
> least those that have a -sources.jar)?
>
> I've looked into doing it with the maven-assembly-plugin, but using a
> dependencySet with includes of *.*.*.sources.* doesn't work because those
> are not actually dependencies of the project.
>
> I perhaps could look into using dependency:sources, and specifying an
> alternate repository to download them into (in target, eg), and then use a
> fileSet of maven-assembly-plugin to add them all, but there must be a
> better way...
>
> Thanks,
> Ben
> --
> --
> Ben Tatham
> Software Architect
>
> *Nano**metrics* *Inc.*
>
> Ottawa * I*  Calgary  *I*  Houston  *I*  Beijing
>
> T: +1 613 505 5065  *I*  bentat...@nanometrics.ca
>  www.nanometrics.ca  *I  *www.microseismicmonitoring.com
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged, confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, or have been inadvertently
> and erroneously referenced in the address line, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>

Re: Enforcer requirePropertyDiverges not propagated to descendants?

[Curtis Rueden]

Hi,

For what it's worth, I agree that the requirePropertyDiverges rule is
difficult to use (and maybe buggy?). After playing with it some months ago,
I concluded that it was not going to work for me. That's why I ended up
writing my own rule.

If you want to ensure that the description is set in each child POM, maybe
the scijava-maven-plugin's requireElements rule _can_ help you here? Or do
you, again, only want to set the description in some intermediate POM layer?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Sun, Mar 5, 2017 at 3:31 AM, <org.apache.maven.u...@io7m.com> wrote:

> Hello.
>
> On 2017-03-05T01:18:34 +0100
> Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>
> > first, you'll have to talk about rules, not only the plugin: there are
> many
> > rules, some implemented by the plugin and some implemented by MojoHaus
> extra-
> > enforcer-rules
>
> Right, yes. It's the requirePropertyDiverges rule in the
> extra-enforcer-rules package in this case.
>
> >
> > then: MojoHaus requirePropertyDiverges [1] requires that the property
> value is
> > different, not that it is not empty
> >
> > IIUC what you're trying to do, you'll need both Maven requireProperty
> [2] and
> > MojoHaus requirePropertyDiverge [1]
>
> That seems wrong, somehow, and it doesn't match the behaviour that I
> posted. If I don't define a property, then the property (if any) will
> be inherited from an ancestor project, yes? The problem I'm having is
> that the requirePropertyDiverges rule seems to stop working after one
> level of inheritance. See these three example cases:
>
> 0. Project A defines a property P. Project B inherits from
>A and doesn't redefine or declare P. The requirePropertyDiverges rule
>correctly rejects this case and the build fails.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-0
>
>^^ Building this project should fail, and it does.
>
> 1. Project A defines a property P. Project B inherits from A and
>redefines P with a different value. The requirePropertyDiverges rule
>correctly accepts this case and the build succeeds.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-1
>
>^^ Building this project should succeed, and it does.
>
> 2. Project A defines a property P. Project B inherits from A and
>redefines P with a different value. Project C inherits from B
>and doesn't redefine or declare P. This case *should* fail,
>because in C, P is inherited from B and therefore has not diverged.
>
>https://github.com/io7m/requirePropertyDiverges-20170305/tr
> ee/master/case-2
>
>^^ Building this project should fail, but it doesn't.
>
> M
>

Re: Download an artifact and its dependencies without a pom.xml

[Curtis Rueden]

Hi everyone,

> My use case is that I want to run a class from a Maven artifact.

I turned my "synthesize a dummy POM" approach into a full-blown shell
script called jrun [1].

You can use it to conveniently run Java code from any remote Maven
repository. For example, to spin up the Jython REPL:

$ jrun org.python:jython-standalone

If you add the ImageJ Maven repository to your ~/.jrunrc:

[repositories]
imagej.public = https://maven.imagej.net/content/groups/public

Then you can launch ImageJ (https://imagej.net/):

$ jrun net.imagej:imagej

Or even the entire Fiji distribution of ImageJ (https://fiji.sc/), which as
of this writing consists of 346 components!

$ jrun sc.fiji:fiji:LATEST

All without explicitly downloading or installing anything apart from Maven
and this one shell script [2].

If anyone knows a better / standard / best-practices way of doing this,
please let me know! But I am pretty pumped about how convenient this is. I
hope that jrun is useful to other developers too.

Regards,
Curtis

P.S. If the Mojohaus devs are interested, perhaps we could fold in
something like this as a new goal of the exec-maven-plugin.

[1] https://github.com/ctrueden/jrun

[2] Windows users need POSIX-compliant shell, though. I did not test it yet.

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 9:50 AM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi everyone,
>
> Is there an easy way to download an artifact and its dependencies to a
> folder locally?
>
> * dependency:get will download a single artifact without needing a pom.xml.
> * dependency:copy-dependencies will copy the dependencies of the current
> project to a target location.
>
> But can these two functionalities be combined?
>
> My use case is that I want to run a class from a Maven artifact.
>
> The best I have come up with so far is to synthesize a dummy POM:
>
> g=org.scijava; a=scijava-common; v=RELEASE; m=org.scijava.script.ScriptREPL;
> echo "4.0.0x pId>x0<
> dependencies>$g$a<
> version>$v" > pom.xml;
> mvn -DoutputDirectory=. dependency:copy-dependencies; rm pom.xml; java -cp
> '*' "$m"
>
> Can this be done more elegantly?
>
> Thanks,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> I get the sense that adding  is something that would
> upset IDEs (my experience has been that they cope relatively poorly
> with anything uncommon like that).

My group uses "" a lot in IDEs including Eclipse, NetBeans
and IDEA, and it works for us. I suggest giving it a try and seeing if it
causes you any problems. Of course, in your case, since you have
multi-module builds, you probably actually _want_ the default behavior of
".." for your submodules, so maybe you don't want to change anything.

> Can a module name contain slashes?

Sure can! It's a relative directory path.

> I will give it a go. I've had somewhat poor experiences with the Maven
> APIs as they tend not to be documented too well.

Yeah, me too. I've found it pretty hard to get into Maven plugin
development, especially since the APIs have gone through a few major
iterations from 2.x to 3.0.x to 3.1.x etc. And in some cases, plugins mix
and match APIs from those different iterations. :-O

That said, this list (and the Maven dev list) is here for you. Others on
this list know a lot more about it, and can help you win awards.

> I may end up living with just not enforcing these things...

Well, since this rule is mostly for you yourself, and not some nebulous
cloud of community developers consuming your stuff, you can probably get
away with a nice shell script that calls grep over your POMs, and barfs
when various things are not found. Easy, right?

Regards,
Curtis

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


On Thu, Mar 2, 2017 at 1:34 PM, <org.apache.maven.u...@io7m.com> wrote:

> On 2017-03-02T11:12:58 -0600
> Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi,
> >
> > > I'd need to think a bit more about it, but I personally dislike
> > > relativePath and have never used it (across hundreds of projects),
> > > pretty much for the sorts of reasons you've described. Hard-coding
> > > paths that represent links to other modules seems like a
> > > horrendously bad idea.
> >
> > That is fair. I will point out, though, that if you do not specify the
> > relativePath, then it is ".." by default. Best practice is to write
> > "" if you explicitly do _not_ want Maven to check for the
> > parent in the parent directory. Hence, if we implemented my
> requireElements
> > enhancement, the relativePath would be treated as ".." when one is not
> > explicitly specified.
>
> Right.
>
> I get the sense that adding  is something that would
> upset IDEs (my experience has been that they cope relatively poorly
> with anything uncommon like that).
>
> > I will also point out that each "" of a multi-module build is
> also
> > a hard-coded link to another module, which according to your reasoning,
> > makes multi-module projects in general a horrendous idea. (And I am not
> > being totally facetious here—I personally prefer never to use
> multi-module
> > projects at all. Though I would not go so far as to call them
> > "horrendous"—they definitely have their uses.)
>
> Hehe, I probably overstated it a touch. I tend to think of the 
> entries slightly differently though: I consider them to be module names
> that match the artifact ID of the submodule and also just happen to
> correspond to the directory that contains the module's sources. They
> don't inspire the same revulsion because they don't exist in my mental
> model as filesystem paths. I'm not actually sure they are in Maven's
> model either... Can a module name contain slashes?
>
> > > I've written a few plugins, but I'm not intimately familiar with the
> > > Maven API: Shouldn't it be possible to recursively retrieve the parent
> > > POMs from the reactor (and failing that, the local and remote
> > > repositories) within the plugin? That would remove the need for
> > > .
> >
> > Sure. You are absolutely welcome to file a PR against the
> > scijava-maven-plugin adding this feature. The complication is just that
> > instead of loading POMs from local files, you now also need to resolve
> them
> > from the appropriate remote repositories, for which there is certainly
> > Maven API, but I am also not familiar enough with it to tell you what it
> is
> > off the top of my head. Hopefully someone else here can comment in more
> > detail, and/or suggest alternative solutions here. In any case, if you
> > pursue this, it should work to test locally by installing the plugin into
> > your local repo cache using the "install" phase, and then using
> > "org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs.
>
> I will give it a go. I've had somewhat poor experiences with the Maven
> APIs as they tend not to be documented too well. I may end up living
> with just not enforcing these things...
>
> M
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> I'd need to think a bit more about it, but I personally dislike
> relativePath and have never used it (across hundreds of projects),
> pretty much for the sorts of reasons you've described. Hard-coding
> paths that represent links to other modules seems like a
> horrendously bad idea.

That is fair. I will point out, though, that if you do not specify the
relativePath, then it is ".." by default. Best practice is to write
"" if you explicitly do _not_ want Maven to check for the
parent in the parent directory. Hence, if we implemented my requireElements
enhancement, the relativePath would be treated as ".." when one is not
explicitly specified.

I will also point out that each "" of a multi-module build is also
a hard-coded link to another module, which according to your reasoning,
makes multi-module projects in general a horrendous idea. (And I am not
being totally facetious here—I personally prefer never to use multi-module
projects at all. Though I would not go so far as to call them
"horrendous"—they definitely have their uses.)

> I've written a few plugins, but I'm not intimately familiar with the
> Maven API: Shouldn't it be possible to recursively retrieve the parent
> POMs from the reactor (and failing that, the local and remote
> repositories) within the plugin? That would remove the need for
> .

Sure. You are absolutely welcome to file a PR against the
scijava-maven-plugin adding this feature. The complication is just that
instead of loading POMs from local files, you now also need to resolve them
from the appropriate remote repositories, for which there is certainly
Maven API, but I am also not familiar enough with it to tell you what it is
off the top of my head. Hopefully someone else here can comment in more
detail, and/or suggest alternative solutions here. In any case, if you
pursue this, it should work to test locally by installing the plugin into
your local repo cache using the "install" phase, and then using
"org.scijava:scijava-maven-plugin:1.0.1-SNAPSHOT" in your test POMs.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 11:02 AM, <org.apache.maven.u...@io7m.com> wrote:

> On 2017-03-02T10:29:30 -0600
> Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > > it seems that I can only require that the XML elements be overridden
> > > in *all* descendant POMs, and this introduces too much redundancy.
> >
> > I see.
> >
> > Would it be sufficient if the requireElements rule had a multiModule flag
> > which, if set, green-lighted the build when the stated elements are
> defined
> > in the local parent POM? This feature would assume you are using the
> > aggregator==parent scheme, and follow the  declared in the
> >  of each POM. If it finds a POM there, it would parse it and then
> > check for the required elements in _that_ POM instead of the initial one.
> > And do this recursively, in case you have a multi-layered multi-module
> > build.
> >
> > The downside of this approach: modules of a project would only build if
> the
> > parent is available locally. E.g.: if you try to build one module of a
> > multi-module build which has been physically disconnected from its parent
> > (e.g., a partial SVN checkout), the enforcer would fail because it would
> > not find the local parent POM to validate against. One can also imagine
> > various "aggegator != parent" organizations where the parent is not
> > available locally, which would also all fail to support this scheme.
> >
>
> I'd need to think a bit more about it, but I personally dislike
> relativePath and have never used it (across hundreds of projects),
> pretty much for the sorts of reasons you've described. Hard-coding
> paths that represent links to other modules seems like a horrendously
> bad idea.
>
> I've written a few plugins, but I'm not intimately familiar with the
> Maven API: Shouldn't it be possible to recursively retrieve the parent
> POMs from the reactor (and failing that, the local and remote
> repositories) within the plugin? That would remove the need for
> .
>
> If that is possible, then I think the pseudocode is:
>
>   let root(p) be the root POM of project p
>   let parent(p) be the parent of p
>   let definesElements(p) return true if p defines the required elements
>
>   Project q = p
>   while (!done) {
> if (q == root(p)) {
>   throw RequiredElementsMissing()
> }
>
> if (definesElements(q)) {
>   done = true
> }
>
> q = parent(p)
>   }
>
> This feels like it would achieve what I need with only minimal
> assumptions about the hierarchy of projects.
>
> M
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

> it seems that I can only require that the XML elements be overridden
> in *all* descendant POMs, and this introduces too much redundancy.

I see.

Would it be sufficient if the requireElements rule had a multiModule flag
which, if set, green-lighted the build when the stated elements are defined
in the local parent POM? This feature would assume you are using the
aggregator==parent scheme, and follow the  declared in the
 of each POM. If it finds a POM there, it would parse it and then
check for the required elements in _that_ POM instead of the initial one.
And do this recursively, in case you have a multi-layered multi-module
build.

The downside of this approach: modules of a project would only build if the
parent is available locally. E.g.: if you try to build one module of a
multi-module build which has been physically disconnected from its parent
(e.g., a partial SVN checkout), the enforcer would fail because it would
not find the local parent POM to validate against. One can also imagine
various "aggegator != parent" organizations where the parent is not
available locally, which would also all fail to support this scheme.

Thoughts?

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 9:13 AM, <org.apache.maven.u...@io7m.com> wrote:

> 'Ello.
>
> On 2017-03-02T08:16:43 -0600
> Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi,
> >
> > > I do actually want to enforce this, the issue is that I only want to
> > > enforce it as far as the first ancestor.
> >
> > Sorry if you stated otherwise in your writeup, but my understanding is
> that
> > you want to define some empty properties in your new root POM, and then
> > ensure they are _not_ empty in the next level down. Right?
>
> Yes, but additionally some XML elements as well.
>
> I'd like to enforce that:
>
>   1. Some properties that are defined as empty in the root POM are
>  non-empty in all descendants.
>
>   2. Some XML elements that are defined in the root POM (such as
>  issueManagement) are overridden _at least once_ between the root
>  and any leaf project.
>
> The requireProperty rule you provided does seem to properly handle point
> 1, but I think that the options we've discussed are too heavy-handed
> for point 2. Unless I've missed something obvious, it seems that I can
> only require that the XML elements be overridden in *all* descendant
> POMs, and this introduces too much redundancy.
>
> M
>

Download an artifact and its dependencies without a pom.xml

[Curtis Rueden]

Hi everyone,

Is there an easy way to download an artifact and its dependencies to a
folder locally?

* dependency:get will download a single artifact without needing a pom.xml.
* dependency:copy-dependencies will copy the dependencies of the current
project to a target location.

But can these two functionalities be combined?

My use case is that I want to run a class from a Maven artifact.

The best I have come up with so far is to synthesize a dummy POM:

g=org.scijava; a=scijava-common; v=RELEASE;
m=org.scijava.script.ScriptREPL; echo
"4.0.0xx0$g$a$v"
> pom.xml; mvn -DoutputDirectory=. dependency:copy-dependencies; rm
pom.xml; java -cp '*' "$m"

Can this be done more elegantly?

Thanks,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> I do actually want to enforce this, the issue is that I only want to
> enforce it as far as the first ancestor.

Sorry if you stated otherwise in your writeup, but my understanding is that
you want to define some empty properties in your new root POM, and then
ensure they are _not_ empty in the next level down. Right?

If so, then I think the requireProperty rule should be sufficient. You can
write:

  

  
  

  
org.apache.maven.plugins
maven-enforcer-plugin
1.4.1

  
enforce-property

  enforce


  

  io7m.previous.version
  You must define the io7m.previous.version
property!
  .+
  You must set the io7m.previous.version
property!

  
  true

  

  

  

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Thu, Mar 2, 2017 at 2:50 AM, <org.apache.maven.u...@io7m.com> wrote:

> Hello!
>
> On 2017-03-01T15:49:10 -0600
> Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > If what you want is to ensure the property is simply non-empty, or
> matching
> > a particular regex, then take a look at the requireProperty enforcer rule
> > [1].
> >
> > Or if your goal is to make sure that a property value _differs_ from the
> > value defined in an ancestor, the requirePropertyDiverges rule [2] might
> be
> > for you.
>
> I do actually want to enforce this, the issue is that I only want to
> enforce it as far as the first ancestor. My current projects look like
> this (where indentation indicates inheritance):
>
>   + io7m-jtensors
> + io7m-jtensors-core
> + io7m-jtensors-tests
> + io7m-jtensors-ieee754b16
> + ...
>   + io7m-r2
> + io7m-r2-core
> + io7m-r2-shaders
> + ...
>
> I want to move to:
>
>   + io7m-ancestor
> + io7m-jtensors
>   + io7m-jtensors-core
>   + io7m-jtensors-tests
>   + io7m-jtensors-ieee754b16
>   + ...
> + io7m-r2
>   + io7m-r2-core
>   + io7m-r2-shaders
>   + ...
>
> So I want to enforce that io7m-jtensors and io7m-r2 override the
> required properties (and elements such as issueManagement), but I don't
> want to propagate that requirement to the individual submodules of
> io7m-jtensors such as io7m-jtensors-core, because this would introduce
> pointless redundancy. I have around 50 top-level projects to manage in
> this form, so any redundancy that can be eliminated really needs to be!
>
> I'm not sure the enforcer plugin is able to express this "only redefine
> once" aspect of the above. Am I wrong?
>
> M
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> Note how this is a module of the root project and therefore it'd be
> redundant to have to re-specify all of the information such as the
> contributors, SCM location [0], etc. I only provide the information
> that's specific to that module such as the OSGi manifest,
> dependencies, etc.

If what you want is to ensure the property is simply non-empty, or matching
a particular regex, then take a look at the requireProperty enforcer rule
[1].

Or if your goal is to make sure that a property value _differs_ from the
value defined in an ancestor, the requirePropertyDiverges rule [2] might be
for you.

In my case, I really wanted to make sure that all those properties were
(re)defined in the child POM, because otherwise, it was too easy for
downstream developers to accidentally forget to override things propertly.
E.g., the parent POM defines  as the issue tracker for
that parent POM itself—but this should never be inherited by the child;
instead, every child should define its own  for its own
issue tracker. (If you don't have an issue tracker, you can write
None to satisfy the
enforcer.)

Regards,
Curtis

[1] https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
[2] http://www.mojohaus.org/extra-enforcer-rules/
requirePropertyDiverges.html

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


On Wed, Mar 1, 2017 at 2:17 PM, <org.apache.maven.u...@io7m.com> wrote:

> On 2017-03-01T12:46:45 -0600
> Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > In this way, I ensure that all projects which extend our parent add all
> the
> > useful metadata and properties needed for successful builditude.
> >
>
> Hm, slight issue with this.
>
> If you take a look at how my projects are usually designed:
>
>   https://github.com/io7m/jtensors/blob/develop/pom.xml
>
> That's the root pom for the project. It defines all of the project's
> information such as plugin versions, dependency versions, metadata such
> as the SCM location, site, etc.
>
> Then, each module looks like this:
>
>   https://github.com/io7m/jtensors/blob/develop/io7m-jtensors-core/pom.xml
>
> Note how this is a module of the root project and therefore it'd be
> redundant to have to re-specify all of the information such as the
> contributors, SCM location [0], etc. I only provide the information
> that's specific to that module such as the OSGi manifest, dependencies,
> etc.
>
> Using the scijava-maven-plugin RequireElements rule would seem to
> require me to specify all of this information again in each module.
> Is there a way to avoid this?
>
> M
>
> [0] Although I do actually have to re-specify the SCM location due to
> an utterly ancient bug/design flaw in the site plugin.
>

Re: Defining a property designed to be overridden?

[Curtis Rueden]

Hi,

> if a project forgets to override the property value, it won't get a
> sensible "You didn't define this property" error because it's already
> defined with an empty value in the parent.

The way I solved this problem with my project builds is to create a custom
requireElements enforcer rule, part of the scijava-maven-plugin [1], which
lets you require the existence of particular elements in the POM itself—not
an ancestor. Here is the configuration we use:

https://github.com/scijava/pom-scijava-base/blob/pom-
scijava-base-3.0.0/pom.xml#L610-L628

In this way, I ensure that all projects which extend our parent add all the
useful metadata and properties needed for successful builditude.

We released scijava-maven-plugin 1.0.0 on Maven Central; feel free to use
it if it helps you.

Regards,
Curtis

[1] https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/maven/plugin/enforcer/
RequireElements.java#L55-L61

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, Mar 1, 2017 at 12:35 PM, <org.apache.maven.u...@io7m.com> wrote:

> Hello.
>
> I'm looking to move to an organization-wide parent POM but am not sure
> how to handle the following configuration case.
>
> The japicmp [0] plugin takes a configuration parameter that specifies
> the previous version of a module against which the current version of
> the module will be checked for API compatibility. I believe it can
> sometimes infer the correct version by itself, but for the sake of
> explanation here, let's assume that it can't and that I need to specify
> it myself. This isn't a japicmp plugin issue, it's just a specific
> example of a more general problem regarding the scope and definitions
> of properties.
>
> I have a parent pom:
>
> https://github.com/io7m/maven-parent-properties-20170301/blo
> b/develop/pom.xml
>
> ... which contains a definition like this:
>
> 
>   ...
>   
> 
>   
>
>   ...
>
>   
> 
>   
> 
> 
>   com.github.siom79.japicmp
>   japicmp-maven-plugin
>   0.9.4
>   
> 
>   verify
>   
> cmp
>   
>   
> 
>   
> ${project.groupId}
> ${project.artifactId}
> ${io7m.previousVersion}
> jar
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>
> I then have an example project that inherits from the parent:
>
> https://github.com/io7m/maven-parent-properties-20170301/blo
> b/develop/mod-a/pom.xml
>
> 
>   
> com.io7m.experimental
> maven-parent-properties-20170301
> 1.0.0
>   
>
>   mod-a
>   
> 0.9.0
>   
>
>   
> 
>   
> com.github.siom79.japicmp
> japicmp-maven-plugin
>   
> 
>   
> 
>
> Note that the child project must override the io7m.previousVersion
> property from the parent. Is this the correct way to handle this? The
> downside to this is that if a project forgets to override the property
> value, it won't get a sensible "You didn't define this property" error
> because it's already defined with an empty value in the parent. If I
> don't define the property in the parent, many IDEs get upset at the
> presence of an undefined property in the POM.
>
> Any advice would be appreciated.
>
> M
>
> [0] https://siom79.github.io/japicmp/MavenPlugin.html
>

Re: jaxb archetype (newbie)

[Curtis Rueden]

Hi Gary,

> If I'm looking for an archetype of a particular type, how do I find it?

Sorry, I do not know a good way.

> Do all archetypes have "archetype" in the group or artifact name?

I do not think it is a hard requirement, but the convention is to put
"archetype" in the artifactId [1]. And for these projects to focus on
serving the archetype and nothing else.

Note that there is an edict [2] stating that unofficial Maven plugins are
supposed to be named -maven-plugin and not maven--plugin; I do
not know if the rule is similar regarding archetypes.

Personally, I never use archetypes. I find them confusing, and a bit
neglected in the Maven developer community. (Anecdotal evidence: even the
tutorial for creating new archetypes [3] does not use the
maven-archetype-archetype to create the new archetype, until the end as an
"alternative way"!) I find it easier to just copy and paste an existing
POM, studying each piece to understand what it does, and editing it as
needed. And most Maven tutorials I've seen are structured with that idea in
mind.

Regards,
Curtis

[1] Example project: https://github.com/maven-nar/maven-archetype-nar-lib
[2]
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html
"Important Notice"
[3] https://maven.apache.org/guides/mini/guide-creating-archetypes.html
"Alternative way to start creating your Archetype"

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 17, 2017 at 12:20 AM, Gary Aitken <ma...@dreamchaser.org> wrote:

> Thanks;
> still in need of a clarification...
>
> >> 1.  Is com.sun.xml.bind:jaxb what I want for an archetype?
> >
> > I cannot comment on whether a good archetype for JAXB exists, since I
> > personally have not used it. But perhaps this plugin is all you need:
> > http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.
> 2/index.html
>
> That's a big help.
>
> > I also found this nice blog post which might be close to what you want:
> > http://memoverkill.com/2013/09/02/jaxb-maven-xml/
> >
> >> 2.  What's wrong with the above mvn command to generate the project?
> >
> > The artifact com.sun.xml.bind:jaxb is not a Maven archetype—just a
> regular
> > dependency of type JAR.
>
> ok, I see that if I download the pom.
> If I'm looking for an archetype of a particular type, how do I find it?
> Do all archetypes have "archetype" in the group or artifact name?
>
> >> 3.  Pointers to how to convert a custom ant task into a maven goal?
> >
> > You can use the maven-antrun-plugin:
> > http://maven.apache.org/plugins/maven-antrun-plugin/
>
> Thanks, that will help
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: jaxb archetype (newbie)

[Curtis Rueden]

Hi Gary,

> 1.  Is com.sun.xml.bind:jaxb what I want for an archetype?

I cannot comment on whether a good archetype for JAXB exists, since I
personally have not used it. But perhaps this plugin is all you need:
http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.2/index.html

I also found this nice blog post which might be close to what you want:
http://memoverkill.com/2013/09/02/jaxb-maven-xml/

> 2.  What's wrong with the above mvn command to generate the project?

The artifact com.sun.xml.bind:jaxb is not a Maven archetype—just a regular
dependency of type JAR.

> 3.  Pointers to how to convert a custom ant task into a maven goal?

You can use the maven-antrun-plugin:
http://maven.apache.org/plugins/maven-antrun-plugin/

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Jan 16, 2017 at 6:02 PM, Gary Aitken <ma...@dreamchaser.org> wrote:

> Trying to convert an old project from using ant to maven; having
> issues getting off the ground.  I've gone through the sonatype
> maven-by-example but am pretty confused.
>
> Starting with just a piece which will be its own project.
> I want to generate a project which uses jaxb during the compile/build
> phase; in ant I had to make my own ant task for one step.
>
> Searching the central repository to find a jaxb archetype, I am
> guessing com.sun.xml.bind:jaxb should work.
>
> I tried to get a simple jaxb project laid out using
>
> mvn archetype:generate -DarchetypeGroupId=com.sun.xml.bind
>   -DarchetypeArtifactId=jaxb
>
> The generator came back with the full list of 1750 archetypes,
> so I filtered using com.sun:
> and got a short list with no com.sun.xml archetypes.
> Obviously I'm doing something wrong here?
>
> Questions:
>
> 1.  Is com.sun.xml.bind:jaxb what I want for an archetype?
> 2.  What's wrong with the above mvn command to generate the project?
> 3.  Pointers to how to convert a custom ant task into a maven goal?
>
> Thanks for any and all clues,
>
> Gary
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Managing offline links across a multi-module project with javadoc

[Curtis Rueden]

Hi Benson,

This sounds like one of several situations where it is helpful to have a
property pointing to your multi-module project root.

See:
* http://stackoverflow.com/q/3084629/1207769
* http://stackoverflow.com/q/4146638/1207769

In short, you could try one of:
* ${session.executionRootDirectory}
* directory:execution-root goal (via https://github.com/jdcasey/
directory-maven-plugin)
* scijava:set-rootdir goal (via https://github.com/scijava/
scijava-maven-plugin)

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Jan 16, 2017 at 11:48 AM, Benson Margulies <bimargul...@gmail.com>
wrote:

> I just tried to configure some offline links in pluginManagement. I
> find that this doesn't not seem to be possible, since the pathnames
> are interpreted relative to each module. Has anyone else come up with
> a solution to this?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Excluding -beta-N from a range

[Curtis Rueden]

Hi Benson,

> I did not know how to tell them how to write a range that has the
> desired effect. Is there one?

Would it work to use a hacky range like:
[1.0.0,1..]
?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Thu, Jan 12, 2017 at 4:52 PM, Mark Derricutt <m...@talios.com> wrote:

> Our rule of thumb at $work is NEVER, EVER, E V E R release a .0 artefact
> for this exact reason.
>
> Always start with .1
>
> Mark
>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
> On 13 Jan 2017, at 11:22, Benson Margulies wrote:
>
> > I did not know how to tell them how to write a range that has the
> > desired effect. Is there one?
>

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

Detecting cycles at the class level seems like a less common use case, and
thus harder to achieve out of the box.

I played a bit with jdeps -- from the docs, it seems like it should be able
to emit output along the lines you are looking for -- but I could not get
it to behave within 10 minutes. Maybe someone else here has more experience
with it.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Wed, Jan 11, 2017 at 6:10 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> all:
>  I need to catch a class cycle for example:
>
> package fubar;
>
> class classA
>
> {
>
>  classB classb; //i need to detect this cycle
>
> }
>
>
> package fubar;
>
> class classB extends classA
> {
>  classA classa; //ok since child class can reach to base class
>
> }
>
>
> does maven-enforcer-plugin have a rule which will detect class cycle
> illustrated above?
>
> Thanks!
>
> Martin
> __
>
>
>
> ____
> From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of
> Curtis Rueden <ctrue...@wisc.edu>
> Sent: Tuesday, January 10, 2017 12:13 PM
> To: Maven Users List
> Subject: Re: maven-enforcer-plugin rules question
>
> Hi Martin,
>
> I do not see how your example constitutes a "package cycle"? Both ClassA
> and ClassB belong to the same package.
>
> Put ClassA or ClassB into a different package, and see if the rule
> complains.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>
>
> On Tue, Jan 10, 2017 at 11:05 AM, Martin Gainty <mgai...@hotmail.com>
> wrote:
>
> > i couldnt get it this cycle failure:
> >
> > Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerfor
> man
> > ceTest
> > 
> > ---
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> > - in de.andrena.tools.nopackagecycles.PackageCycleCollectorPerfor
> manceTest
> >
> >
> >
> > package de.andrena.tools.nopackagecycles;
> > import static org.hamcrest.MatcherAssert.assertThat;
> > import static org.hamcrest.Matchers.empty;
> > import static org.hamcrest.Matchers.is;
> > import java.util.ArrayList;
> > import java.util.Collections;
> > import java.util.HashSet;
> > import java.util.List;
> > import java.util.Set;
> > import jdepend.framework.JavaPackage;
> > import org.junit.Before;
> > import org.junit.Test;
> > import de.andrena.tools.nopackagecycles.ClassB;
> >
> > public class ClassB extends ClassA
> > {
> >  public ClassA classA=null; //OK
> > }
> >
> >
> >
> > public class PackageCycleCollectorPerformanceTest {
> >
> >
> > //add one obvious cycle
> >
> >
> > public void findRealPackageCycle() throws Exception {
> > JavaPackage javaPackage =new JavaPackage("de.andrena.tools.
> > nopackagecycles");
> > JavaClass javaClassA=new JavaClass("ClassA");
> > javaPackage.addClass(javaClassA);
> > JavaClass javaClassB=new JavaClass("ClassB");
> > javaPackage.addClass(javaClassB);
> > allPackages.add(javaPackage);
> >List<Set> cycles = new PackageCycleCollector().
> > collectCycles(allPackages);
> > assertThat(cycles, is(empty()));
> > }
> > ...
> > }
> >
> >
> > package de.andrena.tools.nopackagecycles;
> > import static org.hamcrest.MatcherAssert.assertThat;
> > import static org.hamcrest.Matchers.empty;
> > import static org.hamcrest.Matchers.is;
> > import java.util.ArrayList;
> > import java.util.Collections;
> > import java.util.HashSet;
> > import java.util.List;
> > import java.util.Set;
> > import jdepend.framework.JavaPackage;
> > import org.junit.Before;
> > import org.junit.Test;
> > import de.andrena.tools.nopackagecycles.ClassB;
> > public class ClassA
> > {
> >  public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect
> > this cycle!
> > }
> >
> >
> > what am i doing wrong?
> >
> >
> > Thanks Curtis
> >
> > Martin
> > __
> >
> >
> > 
> > From: ctrueden.w...@gmail.com <ctrueden.w..

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

I do not see how your example constitutes a "package cycle"? Both ClassA
and ClassB belong to the same package.

Put ClassA or ClassB into a different package, and see if the rule
complains.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 10, 2017 at 11:05 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> i couldnt get it this cycle failure:
>
> Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerforman
> ceTest
> 
> ---
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> - in de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest
>
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
>
> public class ClassB extends ClassA
> {
>  public ClassA classA=null; //OK
> }
>
>
>
> public class PackageCycleCollectorPerformanceTest {
>
>
> //add one obvious cycle
>
>
> public void findRealPackageCycle() throws Exception {
> JavaPackage javaPackage =new JavaPackage("de.andrena.tools.
> nopackagecycles");
> JavaClass javaClassA=new JavaClass("ClassA");
> javaPackage.addClass(javaClassA);
> JavaClass javaClassB=new JavaClass("ClassB");
> javaPackage.addClass(javaClassB);
> allPackages.add(javaPackage);
>List<Set> cycles = new PackageCycleCollector().
> collectCycles(allPackages);
> assertThat(cycles, is(empty()));
> }
> ...
> }
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
> public class ClassA
> {
>  public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect
> this cycle!
> }
>
>
> what am i doing wrong?
>
>
> Thanks Curtis
>
> Martin
> __
>
>
> 
> From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of
> Curtis Rueden <ctrue...@wisc.edu>
> Sent: Tuesday, January 10, 2017 11:02 AM
> To: Maven Users List
> Subject: Re: maven-enforcer-plugin rules question
>
> Hi Martin,
>
> A quick Google search revealed this:
> https://github.com/andrena/no-package-cycles-enforcer-rule
> [https://avatars2.githubusercontent.com/u/1824230?v=3=400]<https://
> github.com/andrena/no-package-cycles-enforcer-rule>
>
> GitHub - andrena/no-package-cycles-enforcer-rule ...<https://github.com/
> andrena/no-package-cycles-enforcer-rule>
> github.com
> no-package-cycles-enforcer-rule - Shamelessly copied and improved from
> http://stackoverflow.com/questions/3416547/maven-
> jdepend-fail-build-with-cycles
>
>
>
>
> I haven't tried it personally. Though now that I know about it, I'm sorely
> tempted-it would certainly improve the API design.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> [https://gravatar.com/avatar/63df759e2779af56fd050a968ff98d09]<
> http://imagej.net/User:Rueden>
>
> User:Rueden - ImageJ<http://imagej.net/User:Rueden>
> imagej.net
> What is Curtis working on? Primary projects. Here is a summary of my
> current projects, in priority order. I try to keep this list up to date.
> The ImageJ2 paper.
>
>
>
>
>
> On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com>
> wrote:
>
> > I need to detect package cycles such as what is seen here:
> >
> > class ClassA
> >
> > {
> >
> >  ClassB classB; //detect this package cycle!
> >
> > }
> > class ClassB extends ClassA
> >
> > {
> >
> > }
> >
> >
> > which maven-enforcer-plugin ru

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

A quick Google search revealed this:
https://github.com/andrena/no-package-cycles-enforcer-rule

I haven't tried it personally. Though now that I know about it, I'm sorely
tempted—it would certainly improve the API design.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> I need to detect package cycles such as what is seen here:
>
> class ClassA
>
> {
>
>  ClassB classB; //detect this package cycle!
>
> }
> class ClassB extends ClassA
>
> {
>
> }
>
>
> which maven-enforcer-plugin rule will allow me to detect package cycle?
>
>
> http://maven.apache.org/enforcer/enforcer-rules/index.html
>
> Apache Maven Enforcer Rules - Standard Rules<http://maven.apache.org/
> enforcer/enforcer-rules/index.html>
> maven.apache.org
> Standard Rules. The following standard rules ship along with the enforcer
> plugin: alwaysFail - Always fail... used to test plugin configuration.
> alwaysPass - Always ...
>
>
>
>
> Thanks!
>
> Martin
> __
>
>

Re: Slightly more advanced resource filtering (templating)?

[Curtis Rueden]

Hi,

In addition to the suggestion of others to use parse-version, the
build-helper-maven-plugin also has the regex-property goal, which lets you
assign a property based on a regex. Here is an example:


  sanitize-version
  
regex-property
  
  
sanitizedVersion
${project.version}
^([0-9]+)\.([0-9]+)\.([0-9]+).*$
$1.$2.$3
false
  


Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 3, 2017 at 12:32 PM, Guillaume Boué <guillaume_b...@orange.fr>
wrote:

> Hi,
>
> It sounds like you're looking for the parse-version goal of the
> build-helper-maven-plugin: http://www.mojohaus.org/build-
> helper-maven-plugin/parse-version-mojo.html. It can decompose the project
> version into several Maven properties. There is an example of usage here
> http://www.mojohaus.org/build-helper-maven-plugin/usage.html
> #Access_the_parsed_components_of_a_project_version.
>
> Guillaume
>
>
>
> Le 03/01/2017 à 19:25, org.apache.maven.u...@io7m.com a écrit :
>
>> Hello.
>>
>> I have a small project that contains a plugin for Blender[0]. Plugins
>> in Blender are Python files that must contain a hash value at the top
>> of the file containing version information. The version information has
>> to be numeric constants as Blender actually parses this data rather
>> than evaluating it in an interpreter.
>>
>> https://github.com/io7m/smf/blob/develop/io7m-smfj-blender/
>> src/main/resources/__init__.py
>>
>> Right now, I'm having to remember to manually insert the right version
>> number each time I increment the Maven version. I'd much rather filter
>> the Python source file as a resource instead, but unfortunately I'd
>> need to transform the Maven version string:
>>
>>2.3.1 → (2, 3, 1)
>>
>> Is there an existing plugin that can do this? I assume that it'd be
>> some sort of templating engine. Unfortunately, all of the search
>> results for that seem to be in regards to the site plugin.
>>
>> M
>>
>> [0] http://blender.org
>>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-jar-plugin

[Curtis Rueden]

Hi,

> I add this plugin to my project ,but it doesn't work ,the generated
> jar package doesn't  contain dependcy jars

The maven-jar-plugin does not aggregate dependencies.

To do that, check out these plugins:

* http://maven.apache.org/plugins/maven-assembly-plugin/
* https://maven.apache.org/plugins/maven-shade-plugin/
* http://one-jar.sourceforge.net/

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Wed, Dec 21, 2016 at 5:52 AM, 亢龙不悔 <1016460...@qq.com> wrote:

> I add this plugin to my project ,but it doesn't work ,the generated jar
> package doesn't  contain dependcy jars
> who can help me?
>
>
> 
> org.apache.maven.
> plugins
> maven-jar-plugin
> 2.4
> 
> 
> 
>
> cn.com.epicc.StartMain
>
> true
>
> lib/
> <
> addDefaultImplementationEntries>true
> 
> 
> 
> 
> 
> 

Re: ${project.parent.parent.version} does not work

[Curtis Rueden]

Hi Flo,

> Is there any other chance to get the grandparent version - preferably
> without writing another maven plugin ;-)

If you control the grandparent POM, you can put a property there and set it
to ${project.version} and then it should be inherited in the descendants.

If you don't control the grandparent, then sorry, I don't know a simple
way. Although you could elaborate on why you need this, and perhaps there
is a different/better/simpler approach.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Fri, Dec 2, 2016 at 12:30 PM, Florian Schätz <m...@florian-schaetz.de>
wrote:

> Hello,
>
> Was it expected to work with Maven 2, before the whole effective pom
>> calculation was rewritten?
>> Did you try?
>>
>
> No, don't have Maven 2 here, it was just referenced as a workaround in
>
> https://issues.apache.org/jira/browse/MASSEMBLY-367
>
> and in a comment in...
>
> http://stackoverflow.com/questions/6948091/maven-retrieving-
> the-main-module-version-from-a-sub-module
>
> Is there any other chance to get the grandparent version - preferably
> without writing another maven plugin ;-)
>
> Regards,
>
> Flo
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Need to fully understand bad implications of combined aggregator and parent pom

[Curtis Rueden]

Hi David,

> The fact is, when I ensured that both the local and intranet repo is
> EMPTY of build artifacts, including the parent pom, the child modules
> fail to build because they can't find the parent pom, which just
> resides in the parent directory of each child module.

I have never had that problem with multi-module projects that use a
combined parent/aggregator in the top-level directory. This sounds like a
bug to me. Can you please create an SSCCE / MCVE? Then maybe the community
can comment further on what is going wrong for you.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID <dk0...@att.com> wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, November 30, 2016 5:10 PM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > Correct we dont ever enter relativePath. The implicit one should work
> > and should never see warning that a module can't find its parent
>
> Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
> just confuses things.
>
> The fact is, when I ensured that both the local and intranet repo is EMPTY
> of build artifacts, including the parent pom, the child modules fail to
> build because they can't find the parent pom, which just resides in the
> parent directory of each child module.
>
> I never tried adding a ".. to all of the
> parent pom references, but I was able to get it to work by splitting out
> the parent pom responsibilities into a separate child module pom, and
> having all the references specify the relative path to that.
>
> > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID <dk0...@att.com> wrote:
> >
> > > > -Original Message-
> > > > From: Dan Tran [mailto:dant...@gmail.com]
> > > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > > To: Maven Users List <users@maven.apache.org>
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > I concur with Ben,  aggregator module is banned at my work. Top
> > > > level parent hosts all modules
> > >
> > > So does this mean that you utilize "relativePath" in the child
> > > module's parent definitions?  Otherwise, the child modules are being
> > > built before the POM for the top-level POM is installed (which happens
> > > at the end of the build).
> > >
> > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID <dk0...@att.com> wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > > To: Maven Users List <users@maven.apache.org>
> > > > > > Subject: Re: Need to fully understand bad implications of
> > > > > > combined aggregator and parent pom
> > > > > >
> > > > > > You do have relativePath set correctly for the separate parent
> > > > > > from aggregator?
> > > > >
> > > > > Not sure whether you're addressing Benson or me, but setting
> > > > > relativePath is definitely a requirement, and I think the error
> > > > > message you get is pretty clear when you don’t have it, so I
> > > > > imagine
> > > > that's not Benson's issue.
> > > > >
> > > > > In my case, I did some cut/pasting and some global replaces to
> > > > > separate the POM into parent and aggregator, and now my build
> > > > > works from the top with empty repositories.
> > > > >
> > > > > I don't use the site plugin.
> > > > >
> > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > > <bimargul...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > My experience is precisely the opposite of yours. The most
> > > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > > hard to get the site plugin, for example, to work right with
> > > > > > > your preferred structure where they are different.
> > > > > > >
> > > > > > > I have built many proj

Re: Dependency convergence errors - how to resolve?

[Curtis Rueden]

Hi Niranjan,

> We do set this because we have been burned many times where wrong
> classes from older jar files were getting loaded.
...
> This caused all sort of interesting crashes at runtime.

Runtime... of your application? That would be caused by your deployment
mechanism, which is past where Maven is involved. How do you generate your
final application? How is it decided what gets included on your classpath?

Or do you mean that the wrong dependency JAR(s) are selected at compile
time by Maven?

Personally, I do not see the value in enforcing dependency convergence. In
practice you are going to continually run into problems where you depend on
components A and B and they each depend on a different version of C... and
then what? Lots of exclusions? Much easier if you can just let Maven pick
the newest.

My strong suggestion would be to understand exactly the root cause of your
previous issue, and find out how to solve it without using this enforcer
rule.

Or maybe someone else who uses this rule can comment further on its
intended use, and a way to achieve what you want.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Wed, Nov 23, 2016 at 6:25 PM, Niranjan Rao <nhr...@gmail.com> wrote:

> Hi Curtis,
>
> Sorry for the late reply.
>
> We do set this because we have been burned many times where wrong classes
> from older jar files were getting loaded. For most part this is ok, but if
> memory serves right, we faced few problems with spring/hibernate where it's
> internal dependencies conflicted with some other dependencies. This caused
> all sort of interesting crashes at runtime.
>
> I am not sure and it was long time (couple of years) back, but I think
> root cause was wrong type of proxy class getting created and dependencies
> not getting injected correctly.
>
> Regards,
>
> Niranjan
>
> On 11/19/2016 01:09 PM, Curtis Rueden wrote:
>
>> Hi Niranjan,
>>
>> I have set maven enforcer plugin with dependency convergence.
>>>
>> Naive question: why do this? One of the (IMHO) great things about Maven is
>> that it resolves conflicting dependency versions in a generally desirable
>> way. As long as the newer version of the dependency is backwards
>> compatible
>> with the old at runtime, there should be no problem. The only issue is
>> when
>> there are backwards incompatibilities, no? But in the case of
>> websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer
>> version,
>> which means it should be backwards compatible, right?
>>
>> Regards,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - http://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>>
>>
>> On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao <nhr...@gmail.com> wrote:
>>
>> Greetings,
>>>
>>> I have set maven enforcer plugin with dependency convergence. Usually I
>>> solve these errors with exclusion entries.
>>>
>>> With recent upgrade to selenium 3.0.1 I am getting dependency convergence
>>> error that I am not sure how to resolve. It's selenium-java that has two
>>> conflicting dependencies. If I add exclusion entry, I'll have most
>>> probably
>>> will have to add the required dependencies myself and might break future
>>> upgrades and/or increase maintenance work.
>>>
>>>
>>> Dependency convergence error for org.eclipse.jetty.websocket:we
>>> bsocket-client:9.2.18.v20160721 paths to dependency are:
>>> +-mygroupId:artifact:4.0-SNAPSHOT
>>>+-org.seleniumhq.selenium:selenium-java:3.0.1
>>>  +-net.sourceforge.htmlunit:htmlunit:2.23
>>> +-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
>>> and
>>> +-mygroupId:artifact:4.0-SNAPSHOT
>>>+-org.seleniumhq.selenium:selenium-java:3.0.1
>>> +-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210
>>>
>>> Regards,
>>>
>>> Niranjan
>>>
>>>
>>> -
>>> 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: Use same jar (different version) in one project

[Curtis Rueden]

> How to depend on the same jars with different versions in one project?

Maven's whole design is centered around each GA having only one associated
V. Hence, it performs dependency convergence during builds etc. You can do
a structure like Anders described, which will solve it at compile time, but
it does not address runtime deployment, where presumably you will have one
single classpath. You can of course put both versions of the library in
question on your classpath via some mechanism, but if you want to lean on
Maven for this, it will not be easy.

The solution I've seen which works well is to use a different artifactId
for the new version—as long as the classes are indeed different. For
example, Apache Commons Math 3 is org.apache.commons:commons-math3 [1],
whereas the older Commons Math 2 is org.apache.commons:commons-math [2].
This is really nice because then you can use both artifacts freely in a
single Maven project.

If you use a Maven repository manager in your organization, you can always
redeploy one of the project versions under a different GA in your
repository, and depend on that, so that Maven does the "right thing" for
your needs here.

Regards,
Curtis

[1]
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.commons%22%20AND%20a%3A%22commons-math3%22
[2]
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.commons%22%20AND%20a%3A%22commons-math%22

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Nov 28, 2016 at 9:14 PM, big data <bigdatab...@outlook.com> wrote:

> Dear all,
>
> How to depend on the same jars with different versions in one project?
> Our project is used to deploy on different customer side, which has
> different jar version environments. The codes depends the jar, which has
> two different version 1.0 and 2.0, these two versions are not compatible
> (eash one has own unique API), so our code should support these two
> versions, and can build to different release package to support 1.0 or 2.0.
>
> how to configure pom to support this situation?
>
> Thanks.
>

Re: Dependency convergence errors - how to resolve?

[Curtis Rueden]

Hi Niranjan,

> I have set maven enforcer plugin with dependency convergence.

Naive question: why do this? One of the (IMHO) great things about Maven is
that it resolves conflicting dependency versions in a generally desirable
way. As long as the newer version of the dependency is backwards compatible
with the old at runtime, there should be no problem. The only issue is when
there are backwards incompatibilities, no? But in the case of
websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer version,
which means it should be backwards compatible, right?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao <nhr...@gmail.com> wrote:

> Greetings,
>
> I have set maven enforcer plugin with dependency convergence. Usually I
> solve these errors with exclusion entries.
>
> With recent upgrade to selenium 3.0.1 I am getting dependency convergence
> error that I am not sure how to resolve. It's selenium-java that has two
> conflicting dependencies. If I add exclusion entry, I'll have most probably
> will have to add the required dependencies myself and might break future
> upgrades and/or increase maintenance work.
>
>
> Dependency convergence error for org.eclipse.jetty.websocket:we
> bsocket-client:9.2.18.v20160721 paths to dependency are:
> +-mygroupId:artifact:4.0-SNAPSHOT
>   +-org.seleniumhq.selenium:selenium-java:3.0.1
> +-net.sourceforge.htmlunit:htmlunit:2.23
> +-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
> and
> +-mygroupId:artifact:4.0-SNAPSHOT
>   +-org.seleniumhq.selenium:selenium-java:3.0.1
> +-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210
>
> Regards,
>
> Niranjan
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Strategies for augmenting jar manifest with source provenance info?

[Curtis Rueden]

Hi,

> what could be interesting is to include the exact git commit at point
> of packaging

Use the buildnumber-maven-plugin for this, together with maven-jar-plugin
manifestEntries config:

https://github.com/scijava/pom-scijava-base/blob/pom-scijava-base-1.0.0/pom.xml#L233-L238
https://github.com/scijava/pom-scijava-base/blob/pom-scijava-base-1.0.0/pom.xml#L383-L400

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 Thu, Nov 10, 2016 at 6:38 PM, KARR, DAVID <dk0...@att.com> wrote:

> > -Original Message-
> > From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > Sent: Thursday, November 10, 2016 4:20 PM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: Strategies for augmenting jar manifest with source
> > provenance info?
> >
> > Look in META-INF/maven of the jars made with Maven, which should include
> > a copy of pom.xml. Then just make sure your project has an updated 
> > block.
>
> Ah, and even better would be the info about the people working on the
> project.  That looks like a good strategy.
>
> > Now what could be interesting is to include the exact git commit at
> > point of packaging, which I believe could be possible to add using the
> > release plugin..? (It already rewrites the scm tag of the pom).
>
> One step at a time. :)
>
> > On 10 Nov 2016 11:35 pm, "KARR, DAVID" <dk0...@att.com> wrote:
> >
> > > I'm thinking of augmenting builds to add provenance info to the
> > > manifest of the artifacts we produce, to indicate what git url the
> > > current artifact is associated with (a "ContactInfo" tag might also be
> > > useful).  Is this something that anyone has ever tried to do?  If so,
> > > what strategies have you used?
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
>

RE: Maven Compiler Plugin 3.5.1 bug

[Curtis Rueden]

You can add source directories using the build-helper-maven-plugin.

On Oct 22, 2016 4:39 PM, "Robert Patrick"  wrote:

> I am using the  section of the POM, not my own plugin, to
> populate some tokens in a Java source file that we use to get build
> information (version, git commit/branch info, build timestamp, etc).
>
> 
> 
> src/main/resources/templates
> 
> *.java
> 
> true
> ${project.build.directory}/generated-sources/
> annotations
> 
>   
>
> The documentation claims that the default value for the
> generatedSourcesDirectory is this directory so you are saying that somehow
> the fact that the maven-compiler-plugin no longer includes the directory in
> the build is a feature?
>
> I looked through the compiler plugin's documentation and couldn't figure
> out a way to add a directory to the build.  I know how to add the directory
> to the build if I write my own plugin but that seems pretty heavy-handed
> for something that should be trivial.  What am I missing?
>
>
> -Original Message-
> From: Thomas Broyer [mailto:t.bro...@gmail.com]
> Sent: Saturday, October 22, 2016 4:29 PM
> To: Maven Users List
> Subject: Re: Maven Compiler Plugin 3.5.1 bug
>
> This is not a bug, it's a bug fix! Bug introduced in 3.2, fixed in 3.5.1
> (see release notes for that version).
>
> Your plugin should use its own output directory and add it as a source
> root.
>
> Le sam. 22 oct. 2016 23:18, Robert Patrick  a
> écrit :
>
> > Periodically, I update the versions of the Maven plugins for my projects.
> > Today was one of those days.  What I found is that the
> > maven-compiler-plugin 3.5.1's compile goal no longer seems to not be
> > including the ${project.build.directory}/generated-sources/annotations
> >
> > directory in the compile.
> >
> >
> >
> > My project generates a Java file in the process-resources phase and
> > puts the file in this directory.  Other files in the normal
> > src/main/java location include/depend on this generated file.  When I
> > run my build with 3.5, it works perfectly.  When I run the exact same
> > build with 3.5.1, it fails.
> >
> >
> >
> > I logged into my Apache Jira account but the compiler plugin project does
> > not seem to want to let me create an issue for this.   Is there some sort
> > of special permission required to create an issue on the
> > maven-compiler-plugin?
> >
> >
> >
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Comparing specifying repositories in pom vs. settings.xml?

[Curtis Rueden]

> I'm trying, without success, to imagine why you do not simply
> accumulate  elements as required.

Wouldn't that cause Maven to ping every server sequentially for every
needed artifact?

Better to set up a Maven repository manager (Nexus, Artifactory, etc.) and
proxy all the needed sources, no? Then your settings.xml is always
constant, pointing at your master Nexus, which groups all your needed
repositories. Your build is reproducible and remains resilient to otherwise
disruptive remote repository changes -- as long as your master Nexus does
not change.


On Tue, Oct 18, 2016 at 8:03 AM, Mark H. Wood  wrote:

> On Mon, Oct 17, 2016 at 08:03:03PM +, KARR, DAVID wrote:
> > One thing I run into when jumping between different projects is
> different expectations for what maven repos I need to be using.  In the
> past, I had to have multiple copies of "~/.m2/settings.xml" lying around,
> and I would hack the specified repos when I needed to.
>
> I'm trying, without success, to imagine why you do not simply
> accumulate  elements as required.  Before long you should reach
> a state in which new additions are extremely rare.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Re: Comparing specifying repositories in pom vs. settings.xml?

[Curtis Rueden]

Hi everyone,

I have an OSS project with "mixed" dependencies—some in central, and some
in our public Maven repo (because they are still in incubation or
beta). Every time this discussion arises, I find myself wondering the same
thing: how can you achieve an "out-of-the-box" build for such a project,
without specifying ? All the alternatives I see people
suggest (e.g., checking in settings.xml to the repository) would require
each and every new developer to perform some one-time bootstrap before the
project will build. This will turn away many new & inexperienced developers
if they try to import the project into their favorite IDE and it fails to
build.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Mon, Oct 17, 2016 at 4:48 PM, Manfred Moser <manf...@simpligility.com>
wrote:

> If you really feel you need to control the source of where you download
> components from within the source control system
> I would still NOT use the repositories definition in the POM since that is
> them transferred to the target repo on deployment (unless you use flatten).
>
> Instead I would check in a specific settings.xml as part of the project...
> or even multiple ones for different build scenarios..
>
> Manfred
>
> KARR, DAVID wrote on 2016-10-17 14:42:
>
> >> -Original Message-
> >> From: Manfred Moser [mailto:manf...@simpligility.com]
> >> Sent: Monday, October 17, 2016 1:35 PM
> >> To: users@maven.apache.org
> >> Subject: Re: Comparing specifying repositories in pom vs. settings.xml?
> >>
> >> http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-
> >> is-a-bad-idea/
> >
> > The point about open-source projects is well-taken.  I would never
> specify
> > repositories in a POM for a public project.
> >
> > The section about "Enterprise" just seems odd to me.  It seems very
> focused on
> > "central", when that might not be the case at all.  We use many
> open-source
> > projects, but those aren't very volatile.  We use dozens of internal
> artifacts,
> > and there isn't a lot of doubt about what repos to get particular kinds
> of
> > artifacts from.  I find build repeatability more important (specifying
> all
> > requirements in the build script).  The requirement about "generally
> will want
> > all your developers using the same set of repositories" is pretty
> important to
> > me, but the recommended solution just seems counterproductive.
> Specifying it
> > in the POM for the project seems to be the most direct way to ensure
> that.
> >
> >> KARR, DAVID wrote on 2016-10-17 13:03:
> >>
> >> > One thing I run into when jumping between different projects is
> >> > different expectations for what maven repos I need to be using.  In
> >> > the past, I had to have multiple copies of "~/.m2/settings.xml" lying
> >> > around, and I would hack the specified repos when I needed to.
> >> >
> >> > Recently, I saw a situation where the required repositories were
> >> > simply defined in the top-level pom for the project.  If this is done
> >> > consistently, there's no longer any need to hack the settings.xml
> >> file.
> >> >
> >> > I seem to remember seeing some advice that specifying repositories in
> >> > the POM is a bad practice.  If I'm remembering this correctly, this
> >> > seems odd.  Forcing the correct repos to be defined in the
> >> > settings.xml works against "repeatable builds".
> >> >
> >> > What is the recommended advice here?
> >> >
> >> > -
> >> > 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
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Injecting a transitive dependency via dependencyManagement

[Curtis Rueden]

Hi everyone,

I have a project [1] which depends on
org.apache.xmlgraphics:batik-bridge:1.8, which in turn requires
org.apache.xmlgraphics:xmlgraphics-commons:2.1 at runtime.

Unfortunately, the POM for batik-bridge somehow does not declare the
xmlgraphics-commons dependency [2], even though it definitely needs it [3].

Of course, as a good citizen I should contact upstream and ask about this.
But in the meantime, I want to work around it. I could add a runtime
dependency on xmlgraphics-commons to my project POM, but what would be
really nice would be the ability to declare additional transitive
dependencies in the dependencyManagement section, as has been discussed
here previously [4], since I want to ensure that any project which depends
on batik-bridge via our parent POM will inherit a transitive
xmlgraphics-common dependency.

Unfortunately, based on the previous discussion, I surmise that there is
currently no mechanism for this? Is there an existing issue? If not, should
I file one? Or is what I'm looking for here fundamentally undesirable?

Regards,
Curtis

[1] https://github.com/fiji/IO
[2]
https://repo1.maven.org/maven2/org/apache/xmlgraphics/batik-bridge/1.8/batik-bridge-1.8.pom
[3]
https://github.com/apache/batik/blob/batik-1_8/sources/org/apache/batik/bridge/PaintServer.java#L46-L53
[4]
http://maven.40175.n5.nabble.com/How-to-manage-dependency-quot-includes-quot-td5857771.html

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden

Re: [EXTERNAL] Re: help with version range

[Curtis Rueden]

Hi Robert,

> most people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included.  I have yet to
> hear you or anyone else give me a use case where you want this.

Personally, I want prerelease versions included.

I think it is unsubstantiated to claim "most people" here.

> There should be a simple way to achieve this

I agree. Why not propose a new syntax, or even a patch? Maven is open
source.

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, Sep 23, 2016 at 3:41 PM, Robert Patrick <robert.patr...@oracle.com>
wrote:

> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included.  I have yet to hear you or anyone
> else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now.  There should be a simple way to
> achieve this that does not require me to do something like this:
>
> [1.0,1.
> 999)
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> >
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
>  > a valid use case for why Maven should consider  > pre-released versions
> as within the "not including 2.0" version  > range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> -
> 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: [EXTERNAL] Re: help with version range

[Curtis Rueden]

Hi Justin,

> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> has excluded 1.2.0 from their range? If I explicitly don't want the
> release version why would I want the pre-release versions?

I think it really depends how you use those version suffixes. For example,
I have a component which is currently at 2.0.0-rc-55 (yeah, yeah, 55
"release candidates" is insane, I know). To me, it makes sense that
[1.0.0,2.0.0-rc-55) should match 2.0.0-rc-54.

Anyway, it is way too late to change the behavior. But you're right that an
enhancement to the syntax here might be doable. I leave it to the Maven
core folks to comment on that though.

Regards,
Curtis



On Fri, Sep 23, 2016 at 10:11 AM, Justin Georgeson <jgeorge...@lgc.com>
wrote:

> Yeah, I was hoping there was something more elegant like 1.1+ or
> something, so I can at least move forward with that.
>
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release
> version why would I want the pre-release versions?
>
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
> Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
>
> Hi Justin,
>
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
> versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson" <jgeorge...@lgc.com> wrote:
>
> > I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> > had been going well. However I wanted to start working on 1.2.0 of the
> > parent, so I published a 1.2.0-alpha-1 version. And all the projects
> > with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> > keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> > x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> > want 1.2.0, and second that once I do release 1.2.0 the projects which
> > were receiving the alpha builds will not get 1.2.0. I tried with both
> > 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >
> >
> >
> > *Justin Georgeson*
> > Landmark Cloud Platforms & DevOps - RM
> >
> > Email: *jgeorge...@lgc.com* <jgeorge...@lgc.com>
> >
> > Follow Halliburton: *LinkedIn*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton=DQIFaQ&
> > c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OV
> > ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=
> > 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> > | *Facebook*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton=DQIFaQ=Pskv
> > ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> > i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-wO
> > jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> > | *Twitter*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__twitter.com_halliburton=DQIFaQ=PskvixtEU
> > DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> > mBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=-swEvm-8NW2
> > 18tPAkOpg46kdPblTNts2y7dbe_w82wM= >
> > | *YouTube*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__youtube.com_halliburton=DQIFaQ=PskvixtEUDK
> > 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> > CjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=dTvvV1RKdjYSK
> > _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU= >
> > | *Blog*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__halliburtonblog.com=DQIFaQ=PskvixtEUDK7wuW
> > U-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> > EiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=Or-LJ9tIt99DaFT0-
> > BpnvVYmC73xtz0gLUBwIg5Woho= >
> >
> >
> >

Re: SNAPHOST Depedency of plugin not found

[Curtis Rueden]

Hi Oliver,

Can you share your POM?

Did you configure the ?

Regards,
Curtis

On Sep 23, 2016 3:54 AM, "Oliver B. Fischer"  wrote:

> Hi,
>
> I have a plugin dependency (currently only available as SNAPSHOT) declared
> for the Maven dependency plugin.
>
> If I declare it only as dependency of the plugin Maven is tries to find it
> at http://repository.apache.org/snapshots.
>
> If I declare it also as normal dependency of the project Maven is able to
> find and to download it from the correct snapshot repository.
>
> So, it is needed to declare it twice? I doubt. Or is it a bug?
>
> Oliver
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: help with version range

[Curtis Rueden]

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it had
> been going well. However I wanted to start working on 1.2.0 of the parent,
> so I published a 1.2.0-alpha-1 version. And all the projects with te
> “[1.1.0,1.2.0)” picked it up. I recognize that this is in keeping with the
> implementation that x.y.z-(alpha|beta|…) precedes x.y.z, but it is
> unintuitive to me. First in that I’ve stated I don’t want 1.2.0, and second
> that once I do release 1.2.0 the projects which were receiving the alpha
> builds will not get 1.2.0. I tried with both 3.2.5 and 3.3.9. Can the
> version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
> 
> | *Facebook*
> 
> | *Twitter*
> 
> | *YouTube*
> 
> | *Blog*
> 
>
>
> 
>
>
>
>
> --
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>

Re: Help with transitive shading

[Curtis Rueden]

Hi James,

> I want A's shaded classes to carry over to B.

So, your A component shades all of guava 12?

In that case, when you depend on A from B, B should also be able to depend
on guava 16 with no conflict. That is the whole point of shading
dependencies, right?

I don't understand what you mean by "A's shaded classes to carry over to B"
here. Let's say you shaded com.google.common ->
com.mycompany.com.google.common. Then in project B, you certainly should be
able to e.g. "import com.mycompany.com.google.common" although I think that
should be a rare use case, no?

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, Sep 16, 2016 at 12:21 PM, James Johansville <
james.johansvi...@gmail.com> wrote:

> Hello,
>
> I'm having trouble with shading, haven't had any successful answers at my
> SO post at
> http://stackoverflow.com/questions/39521622/getting-
> maven-transitive-shading-to-work
> .
>
> I have a problem where I have 2 Maven projects, A and B.
>
> A depends on hbase-client which in turn depends on guava 12.0 which is not
> compatible with later guava packages. B depends on A and also on guava
> 18.0, and on another package (curator-recipes) which uses guava 16.0.
>
> So the dependencies are like this:
>
> A -> hbase-client -> guava 12
> B -> A
> B -> guava 18
> B -> curator-recipes -> guava 16
>
> I can easily shade hbase-client within A's pom.xml and that works fine, but
> I'm having trouble figuring out how to get that to work within B's pom.xml.
> I want A's shaded classes to carry over to B. How do I do that?
>

Re: build no.

[Curtis Rueden]

Hi Kashif,

Have a look at the buildnumber-maven-plugin from mojohaus:

http://www.mojohaus.org/buildnumber-maven-plugin/usage.html

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Tue, Aug 30, 2016 at 3:36 AM, Kashif BHATTI <kashifz...@gmail.com> wrote:

> for the POM.xml there is a parameter for buildNumber in the
> maven-cucumber-reporting part...is it possible to somehow have that be
> automatically populated from GitHub by picking up the build Number on my
> source code?
>
>
> Thanks.
>

Re: Property interpolation in child pom

[Curtis Rueden]

Hi Michael,

Just a shot in the dark, but Maven properties of the form ${a.b.c} are
generally shorthand for XML data i.e. something. So
the fact that you are using a property ${site.url} intended to fill in a
section ... is perhaps of concern. Did you try
changing your property names to see whether that makes a difference? If it
does not matter, then (from my non-expert perspective) I am inclined to
agree this seems like a defect, and you could file an issue in JIRA.

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 Wed, Aug 10, 2016 at 11:58 PM, Michael <mlgir...@gmail.com> wrote:

> I wish to define the distributionManagement values for all my projects in
> a common parent pom.
>
> parent pom.xml
>
>${site.url}
>
>
>   file:///Users/macuser/Sites
>   ${site.base.url}/${project.artifactId}
>
>
>
>   
>  local
>  ${site.url}
>   
>
>
>
> The effective pom for this is as expected:
>
>   file:///Users/macuser/Sites/parent-pom
>   
> 
>   local
>   file:///Users/macuser/Sites/parent-pom
> 
>   
>   
> file:///Users/macuser/Sites
> file:///Users/macuser/Sites/parent-pom
>   
>
>
> In child pom, I specify the parent pom only, no other elements.  I expect
> the distributionManagement to inherit from the parent.
>
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://
> maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>   4.0.0
>   
> mlgiroux
> parent-pom
> 0.0.1-SNAPSHOT
> 
>   
>   parent-pom-test
>   pom
> 
>
> The effective pom is strange:
>
>   file:///Users/macuser/Sites/parent-pom-test/parent-pom-test
>   
> 
>   local
>   file:///Users/macuser/Sites/parent-pom-test/parent-
> pom-test
> 
>   
>   
> file:///Users/macuser/Sites
> file:///Users/macuser/Sites/parent-pom-test
>   
>
> The site.url property has been resolved as I expected, but the 
> elements for project.url and distributionManagement.site.url that were
> defined in the parent as ${site.url} have the artifactId twice.  As if I
> had specified ${site.base.url}/${project.artifactId}/${project.artifactId}
>
> Now, if I add the url and distributionManagement to the child pom as:
>${site.url}
>
>
>   
>  local
>  ${site.url}
>   
>
>
>
> The effective pom is exactly as I expect with the artifactId specified
> exactly once in the effective values.
>
>   file:///Users/macuser/Sites/parent-pom-test
>   
> 
>   local
>   file:///Users/macuser/Sites/parent-pom-test
> 
>   
>
>
> I think it is important to point out that the child is NOT a sub module of
> the parent.  It specifies a parent, but it is itself a root module.
>
> This feels like a defect to me.
>
> Michael Giroux
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Curtis Rueden]

Hi Christian & Stephane,

Christian Schulte wrote:
> It has never been possible to override a property in the BOM from the
> imorting POM.

Thanks Christian, I stand corrected!

So it is a consequence of the fact that my projects' managed dependency
versions previously came in through inheritance, but now (with the new
Maven 3.4.0 behavior) the imported versions always take precedence.

Stephane Nicoll wrote (in a different thread):
> Your parent would become a parent for pluginsManagement and all the
> dependencyManagement would move to a separate BOM that you would
> manage the same way as the two others. In Spring Boot we have done
> both actually (because we don't have the same requirement that you
> explain here). "spring-boot-dependencies" is the bom and
> "spring-boot-parent" is the parent pom. The latter extends from the
> former. If you use the parent you get everything. If you don't,
> there's still a separate pom that you can use as a BOM.

Thanks Stephane for this—together with Christian's comment above, it makes
me realize that we will need to use that scheme for our updated POM
structure as well: our pom-base will need to extend our BOM as you say. And
the BOM will need to manage _all_ component versions directly, not via
composition using imports, or else it will not be possible to override
version properties in downstream consumers to change dependency versions.

Or perhaps that behavior is not so important... but if we stop supporting
it, our community will need some time to get used to it.

In general, thanks to you both for investing so much time in this
discussion.

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 Wed, Aug 24, 2016 at 12:15 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 24.08.2016 um 19:05 schrieb Curtis Rueden:
> > One nuance I do not discuss is how importing a BOM under the new scheme
> now
> > resolves all version properties, such that overriding them in the
> consuming
> > POM has no effect anymore. I still feel this is a bug (or at least
> > undesired quality) of the new approach.
>
> It has never been possible to override a property in the BOM from the
> imorting POM.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Curtis Rueden]

Hi everyone,

For those who just can't get enough Maven BOM goodness, here are a couple
of threads in my community (SciJava/ImageJ/Fiji) where we are discussing
the impact these changes will have for us:

* http://forum.imagej.net/t/maven-3-4-0-may-break-imagej-
and-fiji-project-builds/2471/2
* http://forum.imagej.net/t/split-boms-from-parent-configuration/2563

The second link in particular details how we will need to change our base
POM structure to avoid "version clashes" caused when extending a parent POM
while importing another BOM when both manage the same component.

If anyone in the Maven community here has the time, interest and stamina to
read it and offer their thoughts and suggestions, I would greatly
appreciate it.

One nuance I do not discuss is how importing a BOM under the new scheme now
resolves all version properties, such that overriding them in the consuming
POM has no effect anymore. I still feel this is a bug (or at least
undesired quality) of the new approach.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Sun, Aug 21, 2016 at 10:12 AM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/21/16 um 16:35 schrieb Christian Schulte:
> > There is no other proposal I can make.
>
> Call the new behaviour 'include' scope and both scopes could co-exist. I
> forgot the name of that person who said it's not possible to introduce a
> new scope in 3.4.0 :-)
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Curtis Rueden]

Hi Robert,

> Keep in mind that Maven is not the only tool/application using the
> pom.xml. Some of them probably never check the xsd or the
> modelVersion, so we need to be very carefull with this.

Are there specific tools in mind which you believe would be broken by the
4.1.0 model bump? If no one has concrete use cases, I do not think it is
worthwhile to be too concerned about this. Most external tools which
consume POMs do not perform complex dependency resolution outside Maven,
and if they do, it is likely there are other bugs and subtleties and
differences. Worth discussing only case by case IMHO.

> If we introduce a new major modelVersion, that should probably result
> in a new file including a backported to the current 4.0.0 so all tools
> will keep working, including older versions of Maven.

I don't understand... the point of going to model version 4.1.0 is
specifically so that older versions of Maven barf on it. This is good
thing, right?

> What is important it that we must keep a pom in the repository
> understandable for all other tools. If somehow the Maven repository
> becomes useless by introducing changes to the current pom we shouldn't
> do that, but think of a new file-format being extra
> installed/deployed.

In general, I like the idea of a "consumer POM" intended to be easier to
consume. That's what tools like the flatten-maven-plugin are trying to
provide more easily, right?

But I don't think model version 4.1.0 makes the Maven repository useless.
At least in my use cases, I have written significant external tooling
(various shell scripts, perl scripts and Java code) that consume POMs and
glean info from them, and I know none of my cases will be broken by the
4.1.0 changes. Because I don't try to perform my own complete dependency
resolution—it's much simpler and more robust to lean on the Maven CLI and
parse the results of e.g. "mvn dependency:list" or some such.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Sun, Aug 21, 2016 at 7:36 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi,
>
> Keep in mind that Maven is not the only tool/application using the pom.xml.
> Some of them probably never check the xsd or the modelVersion, so we need
> to be very carefull with this.
> If we introduce a new major modelVersion, that should probably result in a
> new file including a backported to the current 4.0.0 so all tools will keep
> working, including older versions of Maven.
> In this case 4.1.0 doesn't change the xsd but the handling of
> dependencies. I have no idea yet about the impact of such change. The last
> thing we want is that it'll destroy the Maven repository eco system.
>
> Hervé and I plan to work on the consumer-pom, but that requires a good
> roadmap.
> First of all we need to separate the build-pom with the distribution-pom.
> They are now exactly the same, but this needs to be separated to be able to
> move forward. On the the things we can finally fix is the absence of the
> version in the parent in case of a multimodule project. So the build-pom
> you don't have to define the version, only the relativePath unless the
> default value is already okay. The distribution-pom can replace
> relativePath with the actual version.
>
> Next we need to think of the consumer-pom. The idea of this file is that
> it contains only relevant transitive information. The original idea was
> about a new format for speed and and having a list of all resolved
> dependencies. This way Maven doesn't have to go to a repository for every
> artifact, since this file already has all the required information. Based
> on some suggested changed in Aether it seems that distance still matters,
> so maybe the dependencies should keep its tree structure within this
> consumer-pom.
> Another advantage of this is that the file already contains the fully
> resolved tree, so you don't depend on the implementation of any tool
> anymore regarding resolution rules.
>
> What is important it that we must keep a pom in the repository
> understandable for all other tools. If somehow the Maven repository becomes
> useless by introducing changes to the current pom we shouldn't do that, but
> think of a new file-format being extra installed/deployed.
>
> Robert
>
>
> On Sun, 21 Aug 2016 02:16:34 +0200, Christian Schulte <c...@schulte.it>
> wrote:
>
> Am 08/21/16 um 00:30 schrieb Mark Derricutt:
>>
>>> Christian, is there anywhere describing what changes there are/or planned
>>> in Model version 4.1.0 at all?
>>>
>>
>> Nothing is documented yet. There have never been any plans. It's more
>> about having to revert a bunch of useful things to stay backwards
>> compatible or increase the model version and be

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" <ctubb...@apache.org> 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 <ctrue...@wisc.edu> 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 <ctubb...@apache.org>
> 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 <gordon.c...@zafin.com>
> > 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
> > > > >
> > > > >
> > > > > 
> -
> >

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 <ctubb...@apache.org> 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 <gordon.c...@zafin.com> 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
> >
> > <http://zafin.com/>
> >
> > --
> >
> > Connect with us
> >
> > <http://www.youtube.com/user/ZafinGlobal>
> > <http://www.linkedin.com/company/Zafin>  <http://twitter.com/Zafin>
> >
> > 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: 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 <c...@schulte.it> 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:
> <https://builds.apache.org/view/All/job/maven-3.3-release-status-build/>
>
> 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)

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

> On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ctrue...@wisc.edu> 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 "

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

[Curtis Rueden]

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?

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 <c...@schulte.it> 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
>
>

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

[Curtis Rueden]

Hi David,

Just a shot in the dark, but does it work to write:

${baseDir}/src/docker

instead?

Regards,
Curtis


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

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

[Curtis Rueden]

producibility.

If you actually made it through this whole thing: thank you for reading.

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 1:12 PM, Stephane Nicoll <stephane.nic...@gmail.com>
wrote:

> Hello Curtis,
>
> I have no opinion on your project (To be honest, I haven't looked in
> details yet, quite a large setup) but if you expect the parent to override
> something you've defined in the child, that's not the expected behaviour at
> all. That's still a problem for you though, I am not denying that.
>
> Of course, if the issue you're having is some sort of different regression,
> we should fix it for sure.
>
> Thanks,
> S.
>
> On Mon, Aug 15, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi Stephane,
> >
> > Why can't we have the best of both worlds? Backwards compatibility, but
> > with a "stop sucking" flag which enables the new better behavior?
> >
> > As I said previously, unless the previous behavior is preserved, all of
> my
> > communy's existing releases (hundreds of projects, thousands of tags)
> will
> > no longer build as intended at time of release.
> >
> > It could be as simple as the required minimum maven version being set to
> > 3.4 to trigger the new behavior.
> >
> > Regards,
> > Curtis
> >
> > On Aug 15, 2016 2:21 PM, "Stephane Nicoll" <stephane.nic...@gmail.com>
> > wrote:
> >
> > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <c...@schulte.it>
> > wrote:
> > >
> > > > Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > > > > reviewing things. So current state of this is: "That's the
> behaviour
> > > > > requested and tested during commiting to MNG-5971. Cannot override
> > > > > properties? Really requested behaviour? Maybe incorrect. Need to
> look
> > > at
> > > > > it again. There was a reason it got implemented the way it is."
> > > >
> > > > The current behaviour is on purpose.
> > > >
> > > > 1. Read POM.
> > > > 2. Recursivley read all parent POMs.
> > > > 3. Include (import) dependency declarations top-down at each level.
> > > > 4. Apply inheritance processing.
> > > >
> > > > There is no way to use an overridden property value when importing
> the
> > > > depdency declarations because the import happens before inheritance
> > > > processing. Benefit is the imported dependency declarations will be
> > > > available to inheritance processing that way.
> > > >
> > >
> > > I agree and I need to draw the attention to the opposite problem (even
> if
> > > it was already explained here).
> > >
> > > The spring ecosystem heavily uses BOMs to define the versions for
> Spring
> > > related modules. We have those for the framework, spring data, spring
> > boot
> > > and cloud. I took us quite some time to get those BOMs right and this
> > > effort lead to the creation of MNG-5971.
> > >
> > > For those asking for a revert, please consider that without it, the BOM
> > > feature is pretty much useless (in the sense it does not enforce
> > anything).
> > > When you have a dependency management section in a project, you want to
> > > make sure that those versions are going to be used in child projects
> (and
> > > you do so by not specifying any version at all). In a given child
> project
> > > you can deviate from that rule by overriding the dependency management
> > for
> > > particular module(s). But it wasn't working with a BOM until now.
> > >
> > > So, something you couldn't do by importing a BOM is actually working by
> > > copy/pasting the content of the BOM in the project! I understand that
> > this
> > > may feel a regression for those who were relying on the current
> behaviour
> > > but I think the current status is much more consistent.
> > >
> > > Cheers,
> > > S.
> > >
> > >
> > > >
> > > > 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)

[Curtis Rueden]

Hi Christian,

Thank you for all your time and effort.

> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT

In my tests, setting a version property in the POM still does not override
the version as it did in 3.3.9:

   https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929

(Apologies if I misunderstood what you were asking to be tested.)

Regards,
Curtis

P.S. The "Multiple conflicting imports" warning is very helpful.

--
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 12, 2016 at 7:03 PM, Christian Schulte <c...@schulte.it> wrote:

> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT available from
> <https://builds.apache.org/job/maven-3.3-release-status-build/>. It
> should have been fixed by this commit
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 814b5166123c54b21545038038536063ce8dba1c>.
>
> 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)

[Curtis Rueden]

Hi Stephane,

Why can't we have the best of both worlds? Backwards compatibility, but
with a "stop sucking" flag which enables the new better behavior?

As I said previously, unless the previous behavior is preserved, all of my
communy's existing releases (hundreds of projects, thousands of tags) will
no longer build as intended at time of release.

It could be as simple as the required minimum maven version being set to
3.4 to trigger the new behavior.

Regards,
Curtis

On Aug 15, 2016 2:21 PM, "Stephane Nicoll" 
wrote:

> On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte  wrote:
>
> > Am 08/13/16 um 00:28 schrieb Christian Schulte:
> > > reviewing things. So current state of this is: "That's the behaviour
> > > requested and tested during commiting to MNG-5971. Cannot override
> > > properties? Really requested behaviour? Maybe incorrect. Need to look
> at
> > > it again. There was a reason it got implemented the way it is."
> >
> > The current behaviour is on purpose.
> >
> > 1. Read POM.
> > 2. Recursivley read all parent POMs.
> > 3. Include (import) dependency declarations top-down at each level.
> > 4. Apply inheritance processing.
> >
> > There is no way to use an overridden property value when importing the
> > depdency declarations because the import happens before inheritance
> > processing. Benefit is the imported dependency declarations will be
> > available to inheritance processing that way.
> >
>
> I agree and I need to draw the attention to the opposite problem (even if
> it was already explained here).
>
> The spring ecosystem heavily uses BOMs to define the versions for Spring
> related modules. We have those for the framework, spring data, spring boot
> and cloud. I took us quite some time to get those BOMs right and this
> effort lead to the creation of MNG-5971.
>
> For those asking for a revert, please consider that without it, the BOM
> feature is pretty much useless (in the sense it does not enforce anything).
> When you have a dependency management section in a project, you want to
> make sure that those versions are going to be used in child projects (and
> you do so by not specifying any version at all). In a given child project
> you can deviate from that rule by overriding the dependency management for
> particular module(s). But it wasn't working with a BOM until now.
>
> So, something you couldn't do by importing a BOM is actually working by
> copy/pasting the content of the BOM in the project! I understand that this
> may feel a regression for those who were relying on the current behaviour
> but I think the current status is much more consistent.
>
> Cheers,
> S.
>
>
> >
> > 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)

[Curtis Rueden]

Hi Christian,

Thank you very much for looking at my example, and your speedy reply.

> Can you please add your objections to MNG-5971 in JIRA.

Done. I also added the same comments to MNG-6079, which I believe is a
legitimate regression caused by the fixing of MNG-5971.

> > 2) I do not know how to restructure my components for Maven 3.4.0 to
> > avoid this problem.
>
> Simply by applying inheritance. This is what MNG-5971 is about.
> Imported dependencies have not been part of inheritance processing
> prior 3.4 but should. Think about the import scope as a way to just
> include some dependencies in the dependency management where it is
> used.
...
> You could just update your poms to make use of inheritance. You would
> just need to declare the dependency in question in the dependency
> management of the inheritance level in question.

So if I understand correctly: with the new approach, it is no longer
possible to override the version of a transitive dependency, without adding
it as a direct dependency of the current project, even though it actually
isn't? Or is there still a way?

I would like to draw your attention to another use case my community has.
Check out this profile:

* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.3.0/pom.xml#L1064-L1214

It overrides all managed version properties in the BOM to LATEST, to make
snapshot coupling in IDEs (particularly Eclipse) less painful.

My understanding of the MNG-5971 change is that the above hack will no
longer work. And I cannot see any new way to achieve something similar? How
do other projects achieve temporary snapshot couplings during development,
without requiring changes to the local dev environment?

Yet another wrinkle which occurs to me: What about cases where the version
property is used in some configuration somewhere, _besides_ in the
dependency declaration? For example, consider the following configuration
block:


maven-jar-plugin
3.0.2




${scijava-common.version}





Of course, the above example is a little contrived, but surely there are
real builds in the wild where a dependency version is fed to a plugin
configuration somewhere? Won't these versions now be "wrong" from the
perspective of the human -- not matching what is actually in the dependency
tree?

> It will also fix builds.

My main beef is the breakage of backwards compatibility. All my old builds
which used to work will no longer work. Wouldn't it be better to have some
new configuration to achieve the desired result for previously broken
builds? Maven component releases are immutable -- I can't go back and fix
all my old releases to work with Maven 3.4.0, ever.

Thanks,
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 12, 2016 at 12:46 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 12.08.2016 um 19:16 schrieb Curtis Rueden:
>
>> Hi all,
>>
>> Concerned by this thread, I did some tests. And I have to say, the new
>> Maven 3.4.0 dependency resolution rules seem like a step backwards.
>>
>> == REAL-WORLD EXAMPLE ==
>>
>> Consider the following project:
>> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d61475
>> 9fb6e78e359d4f/pom.xml
>>
>> Amongst many other dependencies, this project has:
>>
>> 
>> ca.mcgill
>> Sholl_Analysis
>> runtime
>> 
>>
>> This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
>>
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
>>
>> 
>> 
>> 3.6.2
>>  ...
>> 
>> 
>> 
>>  ca.mcgill
>> Sholl_Analysis
>> ${Sholl_Analysis.version} 
>> 
>> 
>>
>> With Maven 3.3.9, we have:
>>
>>   $ mvn dependency:list|grep Sholl
>>   [INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
>>
>> But with Maven 3.4.0-20160806.181437-172, we get:
>>
>>   $ mvn dependency:list|grep Sholl
>>   [INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
>>
>> !!!
>>
>> I believe this surprising behavior is caused by the fact that the toplevel
>> fiji POM needs to also include other BOMs via import scope:
>>
>> *
>> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d61475
>> 9fb6e78e359d4f/pom.xml#L49-L68
>>
>> 
>> 
>> 
>> 
>> sc.fiji
>> pom-bigdataviewer
>> ${pom-bigdataviewer.version}
>> pom
>> import
>> 
>> 
>> 
>> sc.fiji
>> pom-trakem2
>> ${pom-trakem2.version}
>> pom
>> import
>> 
>

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

[Curtis Rueden]

Hi all,

Concerned by this thread, I did some tests. And I have to say, the new
Maven 3.4.0 dependency resolution rules seem like a step backwards.

== REAL-WORLD EXAMPLE ==

Consider the following project:
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml

Amongst many other dependencies, this project has:


ca.mcgill
Sholl_Analysis
runtime


This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:

* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256



3.6.2
 ...



 ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version} 



With Maven 3.3.9, we have:

  $ mvn dependency:list|grep Sholl
  [INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime

But with Maven 3.4.0-20160806.181437-172, we get:

  $ mvn dependency:list|grep Sholl
  [INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime

!!!

I believe this surprising behavior is caused by the fact that the toplevel
fiji POM needs to also include other BOMs via import scope:

*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68





sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import



sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import




The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136

Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9

And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262

== GIST OF THE PROBLEM ==

So, with Maven 3.4.0, dependency management brought in from import scope is
now trumping that brought in from the parent POM itself. This is
problematic because:

- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs
from these subtrees.
- It is now not possible to override version properties _in the POM itself_
to trump the dependencyManagement versions.

But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.

I understand and appreciate that I am naive of the deepest nuances of the
Maven project model and how it gets synthesized. But:

1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid
this problem.

My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing
it till Maven 4, since it will surely break a lot of existing builds.

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 12, 2016 at 10:58 AM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/12/16 um 14:41 schrieb Samuel Langlois:
> > Hello
> >
> > I noticed a change of behaviour in Maven 3.4, which made one of our
> builds
> > fail.
> > It may be a bit of a corner case, so I'll let someone else decide whether
> > it's a regression or a bug fix...
>
> You can read all about it here:
>
> <https://issues.apache.org/jira/browse/MNG-5971>
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Increasing Java Heap Size

[Curtis Rueden]

Hi Kal,

>From the POM file, it looks like a NetBeans application which uses the
nbm-maven-plugin? So maybe this blog post helps you?

https://netbeansscribbles.wordpress.com/2013/11/27/changing-vm-options-for-netbeans-rcp-applications/

(Caveat emptor: I have not actually worked on this sort of application,
personally.)

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 Mon, Aug 8, 2016 at 8:47 PM, lando <lan...@gmail.com> wrote:

> I'm rather lost on this maven installation and not sure what goal I should
> be running.   What is happening is that the java file is compiling to an
> exe and the application is running from there.  The reason I need more heap
> space is because I'm working with awt Images and they gobble down the
> memory, the 64m max heap I currently have is too small.If exec.java
> plugin is meant for this kind of work I'll take a look at it.
>
> The codebase I am working with is at
> https://github.com/sebbrudzinski/Open-LaTeX-Studio if that helps to look
> at
> the pom files.   I'm also looking at the oreilly book maven to try to get
> up to speed.
>
> On Mon, Aug 8, 2016 at 8:25 PM, Jeff Jensen <
> jeffjen...@upstairstechnology.com> wrote:
>
> > What Maven goal are you running that requires additional memory?
> >
> > On Mon, Aug 8, 2016 at 7:14 PM, lando <lan...@gmail.com> wrote:
> >
> > > Sorry if this is a double post haven't seen the original being sent out
> > > yet.
> > >
> > > Hello,
> > > I'm trying to increase the heap size in the executable that maven
> > produces
> > > without much luck  I've tried -Xmx512m in the
> surefire
> > > plugin, but from what I can tell this is only for tests and not for the
> > > final package.  I'm new to maven and having difficulty finding a
> > solution.
> > > I'm using Netbeans 8.1 as my IDE.
> > >
> > > On Mon, Aug 8, 2016 at 8:03 PM, lando <lan...@gmail.com> wrote:
> > >
> > > > Hello,
> > > > I'm trying to increase the heap size in the executable that maven
> > > produces
> > > > without much luck  I've tried -Xmx512m in the
> > surefire
> > > > plugin, but from what I can tell this is only for tests and not for
> the
> > > > final package.  I'm new to maven and having difficulty finding a
> > > solution.
> > > >
> > >
> >
>

Re: How does maven internally manages package dependency?

[Curtis Rueden]

> Maven does manage dependencies at the package level

By which I meant "Maven does _not_ manage dependencies at the package level"


On Thu, Jun 16, 2016 at 10:41 AM, Curtis Rueden <ctrue...@wisc.edu> wrote:

> I almost responded to this question with "Maven does manage dependencies
> at the package level. Use OSGi for that." But then I realized that Debraj
> is specifically asking about how the Maven project itself keeps track of
> its package interdependencies.
>
> Debraj, I am an outsider, so do not know for certain, but my guess is that
> it is ad hoc. In other words: they probably don't. Various Maven artifacts
> probably just add dependencies and use whatever classes are available in
> them. It is possible (likely?) that someone(s) have used package analysis
> tools in the past to check the package interdependencies, but I would be
> surprised if there is any sort of formal tooling in place surrounding that.
>
> I agree with Benson that you could probably find out if you delve into the
> POMs, since any such formal tooling would likely be codified in there
> somehow, e.g. in a profile.
>
> Regards,
> Curtis
>
>
> On Thu, Jun 16, 2016 at 7:47 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>
>> What do you mean by 'manage package dependencies'? By 'package' do you
>> mean 'java package' (e.g. com.foo.bar), or do you mean an artifact in
>> the dependency graph?
>>
>> Maven is open source. If you want to learn how it works, you need to
>> read the code.
>>
>> If you want to learn how to use it, the sonatype online book is useful.
>>
>>
>>
>> On Wed, Jun 15, 2016 at 2:14 PM, Debraj Manna <subharaj.ma...@gmail.com>
>> wrote:
>> > Can some let me know how does maven internally manages package
>> dependency?
>> > Is there any architecture diagram available on the net for the same? I
>> also
>> > asked this in Quora
>> > <https://www.quora.com/unanswered/How-does-Apache-Maven-work-internally>
>> but
>> > did not get any response their nor I am able to find any suitable
>> resources
>> > in the web that explains the working of maven and even better if I can
>> find
>> > some class diagram?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

Re: How does maven internally manages package dependency?

[Curtis Rueden]

I almost responded to this question with "Maven does manage dependencies at
the package level. Use OSGi for that." But then I realized that Debraj is
specifically asking about how the Maven project itself keeps track of its
package interdependencies.

Debraj, I am an outsider, so do not know for certain, but my guess is that
it is ad hoc. In other words: they probably don't. Various Maven artifacts
probably just add dependencies and use whatever classes are available in
them. It is possible (likely?) that someone(s) have used package analysis
tools in the past to check the package interdependencies, but I would be
surprised if there is any sort of formal tooling in place surrounding that.

I agree with Benson that you could probably find out if you delve into the
POMs, since any such formal tooling would likely be codified in there
somehow, e.g. in a profile.

Regards,
Curtis


On Thu, Jun 16, 2016 at 7:47 AM, Benson Margulies 
wrote:

> What do you mean by 'manage package dependencies'? By 'package' do you
> mean 'java package' (e.g. com.foo.bar), or do you mean an artifact in
> the dependency graph?
>
> Maven is open source. If you want to learn how it works, you need to
> read the code.
>
> If you want to learn how to use it, the sonatype online book is useful.
>
>
>
> On Wed, Jun 15, 2016 at 2:14 PM, Debraj Manna 
> wrote:
> > Can some let me know how does maven internally manages package
> dependency?
> > Is there any architecture diagram available on the net for the same? I
> also
> > asked this in Quora
> > 
> but
> > did not get any response their nor I am able to find any suitable
> resources
> > in the web that explains the working of maven and even better if I can
> find
> > some class diagram?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven and Eclipse

[Curtis Rueden]

Hi Michael,

> Failure to find org.apache.maven:maven-plugin-api:jar:2.0.9 in
>
https://swimrepo.faa.gov/nexus/content/repositories/Repo-jboss-fuse-06-02-01-Releases
> was cached in the local repository, resolution will not be reattempted
> until the update interval of SwimRepo has elapsed or updates are
> forced -> [Help 1]

Firstly, you need to check the "Force updates of snapshots and releases"
option. Otherwise, Maven is telling you that this step failed _earlier_ and
so it's not going to even try and do it again this time, unless you force
it to.

Once you force it, you should see a different error message if indeed that
artifact is not present in that repository.

Do you by chance have a  block in your settings.xml? If so, then
perhaps your swimrepo.faa.gov mirror does not in fact contain that
org.apache.maven:maven-plugin-api:2.0.9 artifact as it is supposed to?

-Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Tue, Jun 14, 2016 at 12:35 PM, <michael.ctr.taru...@faa.gov> wrote:

> And one last thing on this.
>
> So now that I have resolved the Maven Dependencies problem, which it
> appears I created myself, I am back to the original problem which is when I
> compile from Eclipse (regardless of whether I upgraded to Mars 2 from Luna
> as in my Windows environment or fresh installed Mars 2 as in my Linux
> environment) I get the following error:
>
> Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> (default-compile) on project queue.producer: Execution default-compile of
> goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile failed:
> Plugin org.apache.maven.plugins:maven-compiler-plugin:2.5.1 or one of its
> dependencies could not be resolved: Failure to find
> org.apache.maven:maven-plugin-api:jar:2.0.9 in
> https://swimrepo.faa.gov/nexus/content/repositories/Repo-jboss-fuse-06-02-01-Releases
> was cached in the local repository, resolution will not be reattempted
> until the update interval of SwimRepo has elapsed or updates are forced ->
> [Help 1]
>
> And if I recall, this is what both Curtis was explaining (fresh install
> vs. upgrade) and Barrie wanted to know about in terms of outcome.
>
> So thus far the outcome is the same for the upgrade and fresh install
> environments, albeit the former is a Windows platform and the later a Linux
> platform.  I will try a fresh install of Mars 2 in Windows as soon as I
> have time to work on it.
>
> Michael Tarullo
> Contractor (Engility Corp)
> Software Engineer
> FAA WJH Technical Center
> (609)485-5294
>
>
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: Wednesday, June 08, 2016 7:33 PM
> To: Maven Users List
> Subject: Re: Maven and Eclipse
>
> On 9 June 2016 at 01:00, <michael.ctr.taru...@faa.gov> wrote:
>
> > Thanks Curtis!
> >
> > That's exactly what I did.
> >
> > As soon as I get a chance, I'll try a fresh install of Mars 2 and see
> > how it goes.  I usually do my Eclipse upgrades with fresh installs,
> > this is the first time I tried to upgrade from a previous version.
> >
> > Mike
>
>
> And when you resolve the issue, can you post back your findings for search
> engines to find.
>
> Thanks.
>

Re: Maven and Eclipse

[Curtis Rueden]

Hi Michael,

> I removed the Maven Dependencies entry from the Java Build Bath
> Libraries tab

I don't understand why you are doing this step. It should never be
necessary in my experience, and my intuition is that it could hose things
up. The Maven > Update Project... command in the Package Explorer context
menu (when you right-click a Maven project) should rebuild the contents of
the Maven Dependencies list automatically, and hence keep your build path
up to date.

The workflow to get up and running on a target system (Windows, Linux or
otherwise) should be the same:

- Clone the project from your SCM to a local directory
- File > Import > Existing Maven Project...
- Select the local directory you just cloned
- Next a couple of times, and you're done.

And updating should be as simple as:

- Update from your SCM
- *Maybe* quick-fix to "Update Project..." if Eclipse complains about the
pom.xml being out of sync. This will likely depend on how you updated from
your SCM: through Eclipse or externally.

Glad that you figured out about the settings.xml 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 Tue, Jun 14, 2016 at 10:53 AM, <michael.ctr.taru...@faa.gov> wrote:

> Further information on this issue:
>
> I earlier reported that my fresh install of Eclipse Mars 2 in a Linux
> environment did create a Maven Directories entry when executing Maven ->
> Update Project, but that I noticed a problem with the actual jar files this
> entry was pointing to and that they were not loaded into my local repo from
> my remote repo.
>
> It appears this behavior was because I neglected to port my settings.xml
> file to the .m2 directory and this file contains the credentials to log in
> to my remote repo.
>
> So, I copied my settings.xml file from my Windows environment and updated
> the location of my local repo in settings.xml with my Linux path to my
> local repo.  Then I removed the Maven Dependencies entry from the Java
> Build Bath Libraries tab, removed all the directories in my local repo and
> executed Maven -> Update Project.; this time I received the same
> results that I did in my Windows environment where my Eclipse upgrade to
> Mars 2 was not from a fresh install.
>
> Once again, I hope this is helpful.  And sorry for any confusion the first
> post may have caused.  I just completely forgot about the settings.xml file.
>
> Michael Tarullo
> Contractor (Engility Corp)
> Software Engineer
> FAA WJH Technical Center
> (609)485-5294
>
>
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: Wednesday, June 08, 2016 7:33 PM
> To: Maven Users List
> Subject: Re: Maven and Eclipse
>
> On 9 June 2016 at 01:00, <michael.ctr.taru...@faa.gov> wrote:
>
> > Thanks Curtis!
> >
> > That's exactly what I did.
> >
> > As soon as I get a chance, I'll try a fresh install of Mars 2 and see
> > how it goes.  I usually do my Eclipse upgrades with fresh installs,
> > this is the first time I tried to upgrade from a previous version.
> >
> > Mike
>
>
> And when you resolve the issue, can you post back your findings for search
> engines to find.
>
> Thanks.
>

Re: Maven and Eclipse

[Curtis Rueden]

Hi Michael,

> That is why I was wondering if the problem was either the new Mars 2
> version of Eclipse or possibly the m2e plugin.

For what it's worth, M2E works great on my system with Eclipse Mars.2. I
would suggest testing with a fresh installation of Eclipse and a clean
workspace -- if you migrated your workspace from Luna it might be that
something got hosed up there.

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 Wed, Jun 8, 2016 at 9:58 AM, <michael.ctr.taru...@faa.gov> wrote:

> Yes the compile (of course with the exact same POM) works from the command
> line.  That is why I was wondering if the problem was either the new Mars 2
> version of Eclipse or possibly the m2e plugin.  As per the question in your
> reply and my answer here, I will post something to the m2e mailing list, as
> you suggest.
>
> Michael Tarullo
> Contractor (Engility Corp)
> Software Engineer
> FAA WJH Technical Center
> (609)485-5294
>
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: Tuesday, June 07, 2016 5:13 PM
> To: Maven Users List
> Subject: Re: Maven and Eclipse
>
> On 8 June 2016 at 01:33, <michael.ctr.taru...@faa.gov> wrote:
>
> > I have recently been doing Maven builds from Eclipse Luna with no
> problems.
> >
> > Recently I upgraded Eclipse to Mars 2 and Maven builds that worked in
> > the past no longer work.  I have posted the error I'm getting at the
> > end of this email.  In addition, it appears that the Maven -> Update
> project
> > Feature is no longer working.  When I do this from Eclipse Mars 2 on
> > an empty local repo, the local repo is populated from my remote repo
> > fine, but the Java Build Path Libraries are not populated, when I
> > start with both an empty local repo and no libraries other than the JDK.
> >
> > I am using the m2e-workspace v0.3.1.  Does this need to be changed as
> > a result of my upgrade from Luna to Mars 2?
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> > (default-compile) on project queue.producer:
> > Execution default-compile of goal
> > org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile failed:
> > Plugin org.apache.maven.plugins:maven-compiler-plugin:2.5.1 or
> > one of its dependencies could not be resolved:
> > Failure to find org.apache.maven:maven-plugin-api:jar:2.0.9 in
> >
> https://swimrepo.faa.gov/nexus/content/repositories/Repo-jboss-fuse-06-02-01-Releases
> > was cached in the local repository, resolution will not be
> > reattempted until the update interval of SwimRepo
> > has elapsed or updates are forced -> [Help 1]
>
>
> Does this work on the command line ?
> If yes, then you need to email the m2e mailing list to troubleshoot
> further.
> https://dev.eclipse.org/mailman/listinfo/m2e-users
>
> This error doesn't look like a problem with maven or m2e.
> This looks like org.apache.maven:maven-plugin-api:jar:2.0.9 is not in your
> organisations nexus proxy.
>
> From the path in the url to the nexus repo it looks like a jboss fuse
> cache.
> My last recollection of the jboss caches were they were bastardized copies
> of central to work with jboss.
> I'd recommend making that cache the last thing the nexus proxy attempts to
> check.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Dealing with .jars that have overlapping .classes

[Curtis Rueden]

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

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, Apr 22, 2016 at 1:23 PM, Kevin Burton <bur...@spinn3r.com> wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
>

Re: Anyone using annotationProcessorPaths in maven-compiler-plugin

[Curtis Rueden]

Hi Mark,

The javadoc of annotationProcessorPaths [1] is not very reassuring for your
intended use case:

"Classpath elements to supply as annotation processor path. If specified,
the compiler will detect annotation processors only in those classpath
elements."

That makes it sounds like it merely limits which classpath elements are
allowed to provide annotation processors—not expand annotation processing
capabilities outside of the normal classpath.

However, the integration test exercising this feature [2] does exactly that
[3], declaring org.issue:annotation-processor as an
annotationProcessingPath but not declaring it in the dependencies at all.
In that case though, unlike your use case, the whole shebang is part of a
multi-module reactor... maybe that makes a difference in whether it works?


Regards,
Curtis

[1]
https://github.com/apache/maven-plugins/blob/cb254e434a40b7ff58c936abbb3f823029a0e466/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L227-L254

[2]
https://github.com/apache/maven-plugins/tree/cb254e434a40b7ff58c936abbb3f823029a0e466/maven-compiler-plugin/src/it/MCOMPILER-203-processorpath

[3]
https://github.com/apache/maven-plugins/blob/cb254e434a40b7ff58c936abbb3f823029a0e466/maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/pom.xml#L58-L64


On Thu, Mar 24, 2016 at 7:21 PM, Christopher  wrote:

> The only annotation processor I use is Google's auto-service. I didn't find
> this to be setting to be useful at all in that case, because I still need
> the auto-service on the classpath (as an optional dependency) so I can
> actually use the @AutoService annotation in my source. I didn't try it with
> any other annotation processor, which would work without being on the
> classpath.
>
> On Wed, Mar 23, 2016 at 7:37 PM Mark Derricutt  wrote:
>
> > Hey all,
> >
> > Has anyone successfully used the new  setting
> > in the maven-compiler-plugin at all?
> >
> > I'm adding:
> >
> > 
> >   
> > com.google.dagger
> > dagger-compiler
> > 2.1
> >   
> >
> > to my compiler plugins configuration but it doesn't seem to work, when
> > running maven with -X I see the configuration is picked up, but it
> doesn't
> > seem to get passed to the compiler at all?
> >
> > [DEBUG] Goal:
> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
> (default-compile)
> > [DEBUG] Style: Regular
> > [DEBUG] Configuration:  encoding="UTF-8"?>
> >   
> > 
> >   com.google.dagger
> >   dagger-compiler
> >   2.1
> > 
> >   
> >   
> >   
> >default-value="${project.compileClasspathElements}"/>
> >   
> >default-value="javac">${maven.compiler.compilerId}
> >default-value="${reuseCreated}">${maven.compiler.compilerReuseStrategy}
> >   ${maven.compiler.compilerVersion}
> >   ${maven.compiler.debug}
> >   ${maven.compiler.debuglevel}
> >default-value="${project.build.sourceEncoding}">${encoding}
> >   ${maven.compiler.executable}
> >default-value="true">${maven.compiler.failOnError}
> >default-value="false">${maven.compiler.forceJavacCompilerUse}
> >   ${maven.compiler.fork}
> >default-value="${project.build.directory}/generated-sources/annotations"/>
> >   ${maven.compiler.maxmem}
> >   ${maven.compiler.meminitial}
> >   
> >   ${maven.compiler.optimize}
> >   
> >   
> >   
> >   
> >default-value="false">${maven.compiler.showDeprecation}
> >default-value="false">${maven.compiler.showWarnings}
> >   ${maven.main.skip}
> >default-value="false">${maven.compiler.skipMultiThreadWarning}
> >   ${maven.compiler.source}
> >   ${lastModGranularityMs}
> >   ${maven.compiler.target}
> >default-value="true">${maven.compiler.useIncrementalCompilation}
> >default-value="false">${maven.compiler.verbose}
> >
> > When running the compiler with true I don't see the
> > dagger-compiler artefact anywhere on the paths mentioned ( to be expected
> > since it should be on the annotation path not class-path, but we don't
> > print out the annotation path ).
> >
> > Am I missing something simple? Including dagger-compiler as a normal
> > dependency works fine, but then bleeds into the class path.
> >
> > Mark
> >
> > --
> > Mark Derricutt
> > http://www.theoryinpractice.net
> > http://www.chaliceofblood.net
> > http://plus.google.com/+MarkDerricutt
> > http://twitter.com/talios
> > http://facebook.com/mderricutt
> >
>

Re: "conditional" parent POM?

[Curtis Rueden]

Hi Max,

Why do you need two different parents? What configuration is different
between your "wild" parent and your internal one?

Would it be sufficient to enclose the internal-specific configuration
(e.g., distributionManagement) in a profile? This technique is what my OSS
projects do [1].

Regards,
Curtis

[1]
https://github.com/scijava/pom-scijava/blob/pom-scijava-9.6.0/pom.xml#L1686-L1701


On Thu, Mar 10, 2016 at 2:20 PM, Max Spring  wrote:

> What's the best structure for a (multi-module) Maven project which should
> build "in the wild" without any Maven repository manager and can easily
> build within my organization where deployments should happen to my Maven
> repository manager?
>
> Ideally, I would have two different paren POMs for each situation. But
> unfortunately, I can't use a Maven property to pass the correct value for
> each situation, because the property expression in the parent POM reference
> doesn't get interpolated, if I try something like
>
>   
> org.example
> ${root.pom}
> 1.0-SNAPSHOT
> 
>   
>   ...
>   
> wild-parent
>   
>
> Added a minimalistic project which shows a crude approach to solve this by
> patching the parent POM via sed:
> https://github.com/m2spring/wild-inhouse-hybrid-example
>
> -Max
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Installation issue

[Curtis Rueden]

Hi Patric,

I suggest installing Maven on OS X using Homebrew (http://brew.sh/).
Installation is as simple as "brew install maven" and then the "mvn"
command exists in /usr/local/bin.

Regards,
Curtis


On Tue, Feb 16, 2016 at 4:52 AM, Patric Hindenberger <
patric.hindenber...@gmail.com> wrote:

> Hello
>
> i try to install MAVEN on MAC OS X EL CAPITAN and have downloaded and
> extracted the most recent maven- files.
> I have set up the $JAVA_HOME correctly to
> /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home
>
>
>
> But if i try to double check the install i get by
>
> mvn --version
>
>
>
> the result
>
>
>
> -bash: mvn: command not found
>
>
> Does somebody has a hint to me?
>
>
> Thx
> Patric
>
>

Re: Way Java 8 resolves interface dependencies seems to play havoc

[Curtis Rueden]

Hi Shaddy,

> Is it as significant a change in behaviour as I think it, for pom.xml
> authors to update their definitions to no longer specify that
> interfaces are "provided"?

Personally, I have never heard of interface/API JARs being scoped as
provided in this manner, until you pointed out the jboss example. I would
be surprised if this is a common practice, especially since it seems like a
hack: in this case, the interfaces are _not_ actually "provided" at
runtime, right? They just end up not actually being needed with Java 7 or
earlier runtime?

Anyway, it seems very dangerous to me to rely on class loading subtleties
like that when scoping Maven artifacts -- I would always put these things
at compile or runtime scope in my own projects, to maximize compatibility.
The fact is that those interfaces _are_ dependencies. I would call this a
"bug" in the JBoss BOM.

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 Wed, Feb 3, 2016 at 11:07 PM, Shaddy Baddah <
beryllium-b...@shaddybaddah.name> wrote:

> Hi,
>
> I was working through a problem where my local build of a project, using
> Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
> dependency problem. Whilst our continuous integration server was not.
>
> The continuous integration server is running JDK 1.7.0_80.
>
> The problem being encountered was:
>
> [ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
> access TransactionLocalDelegate
>
> Before I dive head first into my investigation into the problem, I
> am fairly certain the problem is because there has been a change to how
> javac in Java 8 resolves interface dependencies; in contrast to previous
> versions.
>
> My understanding is pre Java 8, you did not need to include in the
> classpath to javac, paths to the interfaces that are dependencies of
> precompiled classes.
>
> According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
> changed (my understanding, due to a language spec change) with Java 8.
>
> I know this seems late in the game, but considering how I encountered
> the problem, how it seems so obscure and random, I thought it important
> to have something on record about how Java 8's changed behaviour may
> have been potentially crippling user experience of Maven. Through no fault
> of Maven, or artifact creators themselves. But through a change in
> the goal-posts.
>
> To illustrate my point, if you can follow this. The code in question is:
>
> import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
> import com.arjuna.ats.jta.transaction.Transaction;
> ...
>
> TransactionManagerDelegate tx =
> (TransactionManagerDelegate) TransactionManager.transactionManager();
> try {
> Transaction transaction = (Transaction)
> tx.getTransaction();
>
>
> Tracing this to see where there was a reference to
> TransactionLocalDelegate, I found that it was in a base class
> com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
>
> public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
> extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.naming.spi.ObjectFactory {
>   public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
>   public int getTransactionTimeout() throws
> javax.transaction.SystemException;
>
> Now this base class implements interface
> org.jboss.tm.TransactionLocalDelegate:
>
> public abstract class
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,
> org.jboss.tm.TransactionTimeoutConfiguration
>
> With Java 1.7 and below, javac would not chase down the definition of
> this interface (confirmed with javac -verbose). But with Java 1.8 it
> does.
>
> Now the artifact is:
>
> 
> org.jboss.jbossts.jts
> jbossjts-integration
> 
>
>
> and the pom.xml for this artifact has this section:
>
> 
>   org.jboss
>   jboss-transaction-spi
>   provided
> 
> 
> org.jboss.logging
> jboss-logging-spi
> 
> 
> 
>
> Artifact jboss-transaction-spi would have provided the definition to
> interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
> perhaps for greatest efficiency), the pom.xml definition has it scoped
> provided.
>

Re: Extracting classes from a separate project?

[Curtis Rueden]

Great question!

I see a couple of approaches:

1) Technical solution: I think you are on the right track to use the
maven-shade-plugin. But you shouldn't need the maven-dependency-plugin. The
shade plugin is pretty powerful. Why not just make your single-module
library artifact an "uber-JAR" consisting only of its own sources plus the
relocated+minimized fastutil classes, using true?

2) Social solution: start a discussion with the fastutil team about
modularizing their library for a future (breaking) release. Right now the
packages are divided by primitive type, which seems backwards to me. Better
would be to divide by data structure, with all primitive types in each data
structure package. Then you could cherry pick only the needed data
structure(s) of interest. Obviously this is a longer-term solution.

3) Punt. Just depend on fastutil and make no apologies. 16MB is really not
that big of a deal these days. Is slimming ~10MB from your footprint really
worth the developer time investment of mucking around with shade etc.?

Regards,
Curtis

On Tue, Dec 1, 2015 at 10:16 AM,  wrote:

> Hello.
>
> I'm intending to use some classes from the fastutil package[0]. Due
> to the size of the artifact(s), it's assumed that anyone using the
> package will use ProGuard on their application to remove unneeded
> classes. However:
>
> 1. I'm writing a library.
> 2. I'm using the fastutil classes in a way that does not expose them
>in the public API of the library.
> 3. I do not want everyone that uses my library to have to use something
>like ProGuard to reduce the resulting size increases caused by
>a dependency on fastutil.
>
> Therefore, I feel like the correct way to proceed is to create
> a module in my project that solely exists to extract a few classes
> from fastutil an expose them to the other modules that need them.
>
> One way to do this would be to use the maven-dependency-plugin to
> extract sources from the fastutil package and treat them as "generated
> sources" so that they're compiled and packaged as part of the artifact.
>
> However! This would obviously then result in conflicts (duplicate
> classes) if someone using my library also used the fastutil package.
>
> It seems like the maven-shade-plugin is capable of moving classes
> into different packages, but it seems as though it's only capable
> of working with compiled classes and therefore may not play nicely
> with IDEs.
>
> Does anyone have a better/preferred way to achieve this?
>
> M
>
> [0] http://fastutil.di.unimi.it/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Compilation Error -Incompatible Types

[Curtis Rueden]

Hi Adrien,

> most of the time differences between eclipse and command line
> compilation are due to scopes problems.

I agree that Eclipse's handling of scopes is a common reason for code which
works in Eclipse, but actually fails on the CLI.

However, there are also significant differences in the compilers
themselves, which I have encountered quite frequently. In particular,
Eclipse tends to be laxer about complex generics expressions than javac is.

Regards,
Curtis

On Thu, Nov 26, 2015 at 9:06 AM, Adrien Rivard 
wrote:

> I'm not sure this is the case here, but most of the time differences
> between eclipse and command line compilation are due to scopes problems.
> Eclipse is merging various scopes (test/compile ..) when compiling while
> command line is enforcing strict separation.
> Have a look at the scopes of the libraries of both problematics objects.
>
>
> On Thu, Nov 26, 2015 at 3:54 PM, Jörg Schaible 
> wrote:
>
> > pradeepkumar wrote:
> >
> > > I have tried compile form console , even i am facing the same error
> from
> > > command prompt.
> >
> > That simply means your code is not Java compliant. It does not matter
> that
> > the Eclipse compiler has no problem.
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
> Adrien Rivard
>

Re: animal-sniffer-maven-plugin repo missing

[Curtis Rueden]

You mean this?
https://github.com/mojohaus/animal-sniffer/tree/master/animal-sniffer-maven-plugin

On Thu, Nov 26, 2015 at 9:44 PM, Martin Gainty  wrote:

> anyone know what happened to animal-sniffer-maven-plugin repo?
> https://github.com/mojohaus/animal-sniffer.git/animal-sniffer-maven-plugin
>
>
> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/source-repository.htmlsays
> this is the repo for animal-sniffer-maven-plugin?
>
> Thanks,
> Martin
> ___
>
>

Re: regex-property goal of build-helper-maven-plugin documentation is incorrect

[Curtis Rueden]

Hi Steve,

> Can someone fix it?

I was going to respond with "You can!" But it seems it was already fixed
almost a year ago:

https://github.com/mojohaus/build-helper-maven-plugin/commit/cdaa047253fdcb64f94e81a6e8575191b5919ab0

The site just hasn't been regenerated and uploaded, I guess?

-Curtis

On Mon, Nov 16, 2015 at 5:41 PM, Steve Cohen  wrote:

> Documentation on the regex-property goal of build-helper-maven-plugin at
> http://www.mojohaus.org/build-helper-maven-plugin/usage.html has an
> error.  This error has persisted for some time and has proliferated around
> the Internet, for example in several Stack Overflow posts.
>
> The error is this:
>
> In the section marked "Set a property by applying a regex replacement to a
> value",
> under , we see the  element exampled as
>
> $\{project.version}
>
> This is incorrect.  The goal will fail if the backslash is included and
> succeed if it is omitted.  From my basic understanding of regex and of
> Maven, it seemed wrong and I have verified that it is.
>
> It's probably a typo, one that has confused some people, for example, on
> Stack Overflow:
>
>
> http://stackoverflow.com/questions/17516313/possible-bug-when-parsing-properties-with-goal-regex-property-of-build-helper
>
> Can someone fix it?
>
> Steve Cohen
>

Re: Please reopen MNG-4533 Add an always active profile activator

[Curtis Rueden]

Hi Arend,

> The idea is to have a profile which is always active, unless
> explicitly deactivated.

To achieve that use case, I like to activate based on a property value.
Then you can change the property value from the CLI to deactivate it,
without affecting any other profiles. This is more flexible than using the
-P flag (which I avoid whenever possible).

Regards,
Curtis

On Sat, Nov 14, 2015 at 3:06 PM, Arend v. Reinersdorff 
wrote:

> Hi Karl Heinz,
>
> good point. I'll try to elaborate more:
>
> The idea is to have a profile which is always active, unless explicitly
> deactivated. One can nearly achieve this with
> true, but not quite because an
> activeByDefault profile is deactivated if another profile from the same
> pom.xml is activated.
>
> So this is needed when:
> - one profile should always be active, but can be turned off explicitly
> - another profile can be activated, and activating it should not deactivate
> the always active profile
>
>
> Here's a concrete example. Solution taken from this answer on Stackoverflow
>
> http://stackoverflow.com/questions/5539348/how-to-exclude-a-module-from-a-maven-reactor-build/11429945#11429945
>
> - a multi module project
> - normally all modules are included in a build
> - in some cases certain modules (data-foo and data-bar) should be excluded
> from the build (in the Stackoverflow question because the tests took a long
> time, I was researching it to exclude modules from Javadoc generation) The
> modules are excluded with "mvn -!Pfull-build"
> - also, there's another profile to change the target directory. Activating
> this should not interfere with module exclusion. "mvn -PtargetInTemp clean
> install" should still build all modules.
>
> 
> 
> common
> foo
> bar
> 
>
> 
> 
> full-build
> 
>
> 
> 
> pom.xml
> 
>
> 
> 
> data-foo
> data-bar
> 
> 
>
> 
> 
> targetInTemp
> 
>
> ${env.TEMP}/${project.groupId}/${project.artifactId}
> 
> 
> 
>
>
> Best regards,
> Arend
>
>
> On Sat, Nov 14, 2015 at 2:20 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 11/14/15 2:03 PM, Arend v. Reinersdorff wrote:
> >
> >> Hi,
> >>
> >> could issue MNG-4533 "Add an always active profile activator" please be
> >> reopened?
> >> https://issues.apache.org/jira/browse/MNG-4533
> >>
> >> The issues was automatically closed in 2014.
> >>
> >> I find the current workarounds to create an always active profile (check
> >> for non existing property, check for always existing file) quite ugly.
> >>
> >
> >
> > The question is why do you need a profile which is always active ? In
> > consequence i would ask why do you need a profile at all in such case? If
> > it is always active you don't need a profile
> >
> >
> > May be you can elaborate more what you like to achieve and what the use
> > case is?
> >
> >
> > 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: Build Number Maven Plugin branch naming

[Curtis Rueden]

Hi Victor,

> I would like to change the way $svnVersion is set for my branches.
> That is, I would like to shorten it a bit

Not sure if the buildnumber-maven-plugin has a direct way, but the
build-helper-maven-plugin has a regex-property goal for manipulating
properties.


http://www.mojohaus.org/build-helper-maven-plugin/usage.html#Set_a_property_by_applying_a_regex_replacement_to_a_value

Here is an example usage:


https://github.com/scijava/pom-scijava/blob/pom-scijava-8.5.0/pom.xml#L1066-L1097

Regards,
Curtis


On Wed, Nov 11, 2015 at 1:53 AM, Neiman, Victor  wrote:

> Hi all,
>
> Working on a project that generates RPM's using rpm-maven-plugin, the
> RPM's then have the build number appended to them using the
> buildnumber-maven-plugin.
>
> Currently using SVN. I would like to change the way $svnVersion is set for
> my branches. That is, I would like to shorten it a bit, currently my branch
> is located at
> http:///repos//branches/dev/
>
> I compile the RPM and add the build number using $svnVersion to get the
> following:
>
> -1.0-branches_dev_BuildModule_MainRPMs_Standalone_TerminalDriver.9057.noarch.rpm
>
> so
> $svnVersion=branches_dev_BuildModule_MainRPMs_Standalone_TerminalDriver.9057
>
> I understand that the reason for this is that the branch itself has the
> path /branches/dev/ and the RPM sources are located at
> /BuildModule/MainRPMs/Standalone/TerminalDriver.
>
> What I'd like to get to is truncating the branch name to something like
> branches_dev, so the resulting RPM would be named
> -1.0-branches_dev.9057.noarch.rpm
>
> So my question is whether there is a way I can manipulate $svnVersion
> somehow to make it @svnVersion=branches_dev, which is a substring of the
> original?
>
> Regards and thanks
> Vic
> To read FirstRand Bank's Disclaimer for this email click on the following
> address or copy into your Internet browser:
> https://www.fnb.co.za/disclaimer.html
>
> If you are unable to access the Disclaimer, send a blank e-mail to
> firstrandbankdisclai...@fnb.co.za and we will send you a copy of the
> Disclaimer.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Installing on Solaris

[Curtis Rueden]

Hi James,

Probably you meant to set JAVA_HOME, not CLASSPATH.

The JAVA_HOME variable points to your Java installation, whereas CLASSPATH
points to .jar files (and/or directories of .class files) you want to be
available to Java after it starts up.

Regards,
Curtis

On Fri, Nov 6, 2015 at 12:24 PM, james pruett  wrote:

> Greg, thanks for that.
> Yes, I downloaded SE Solaris Sparc 64bit version from where you
> mentioned...
> Note I am not admin but I read that it should still be possible for me to
> run java from userspace.
>
> Q: I set my CLASSPATH, but perhaps incorrectly
>
> % env | grep CLASSPATH
>
> CLASSPATH=/export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9
>
> % ls $CLASSPATH
> jspawnhelper libdcpr.so   libj2gss.so  libjava.so
> libjdgaSUNWffb.solibjsdt.so   libmlib_image.so
> libsaproc.so libt2k.soserver
>
>
> mktpricing:/export/home/e0857723/aaa_bonita % javac -version
> Error: could not find libjava.so
> Error: Could not find Java SE Runtime Environment.
>
>
>
> mktpricing:/export/home/e0857723/aaa_bonita % which javac
> /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/bin/javac
>
>
> I realize this is not a maven problem I am having but I am begging help
> help.
> I can go to Solaris help if you think necessary.
>
> Thanks for helping!
> jim
>
>
>
>
> On Fri, Nov 6, 2015 at 11:50 AM, Greg Trasuk 
> wrote:
>
> >
> > Hi James:
> >
> > Based on your class path, it looks like you installed the “Java Runtime
> > Environment”.  That’s just the Java virtual machine without the Java
> > Compiler.  Maven is going to need the Java Compiler, so you’ll need to
> get
> > the Java SE version (Standard Edition, appears to be at
> >
> http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
> > ).
> >
> > Having said that, it looks odd that it’s having trouble finding
> > ‘libjava.so’.  There might be something funny about your JDK
> installation.
> > Maybe that gives you a place to start looking…
> >
> > Basically, before Maven has any chance at working, you need to make sure
> > that you can run ‘javac -version’ and it comes back with 1.7 or higher.
> >
> > Cheers,
> >
> > Greg Trasuk
> > http://www.webagesolutions.com
> >
> >
> > > On Nov 6, 2015, at 12:36 PM, james pruett  wrote:
> > >
> > > Hi,
> > >
> > > I get this error. Any help appreciated.
> > >
> > >
> > > % mvn
> > > Error: could not find libjava.so
> > > Error: Could not find Java SE Runtime Environment.
> > >
> > > % env | grep -i CLASSPATH
> > >
> >
> CLASSPATH=/export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9
> > >
> > >
> > > % ls -las $CLASSPATH/libjava.so
> > > 524 -rwxrwxrwx   1267912 Apr 10  2015
> > >
> >
> /export/home/e0857723/aaa_bonita/jdk17/jdk1.7.0_79/jre/lib/sparcv9/libjava.so
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Add third party jars from the file system to final executable jar without adding the third party jars in local maven repo

[Curtis Rueden]

Hi Reena,

Stephen Connelly wrote a great blog post a couple of years ago addressing
similar use cases. The URL is/was:

http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html

Unfortunately, it seems the CloudBees Developer Blog is currently not
working (it redirects to the main CloudBees page). But you can use Google's
cache to read it:

http://webcache.googleusercontent.com/search?q=cache:g6o4OFBnC9wJ:developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html+=1=en=clnk=us

HTH,
Curtis

On Mon, Oct 26, 2015 at 11:50 AM, Wayne Fay  wrote:

> Sounds like you know the answer. Use the "mvn install" file command.
>
> Wayne
>
> On Mon, Oct 26, 2015 at 9:53 AM, reena upadhyay 
> wrote:
> > Can you please provide some code snippet, how to add it to local repo
> > through pom.xml. I don't want it add to my local maven repo using mvn
> > install file command.
> >
> > On Mon, Oct 26, 2015 at 8:21 PM, Anders Hammar 
> wrote:
> >
> >> The system scope is deprecated and the issues you're running into is
> likely
> >> due to that. The solution is to add the library to your internal
> (remote)
> >> repo or at least your local repo.
> >>
> >> /Anders
> >>
> >> On Mon, Oct 26, 2015 at 3:26 PM, reena upadhyay 
> >> wrote:
> >>
> >> > I want dependencies that are having system scope to be part of my
> project
> >> > final executable jar. I tried maven-assembly, maven-shade and
> >> > maven-dependency plugin. But using these plugins, only those
> dependency
> >> of
> >> > my project which were present in my local maven repository were
> getting
> >> > added. Dependency with system scope (not present in my local maven
> repo)
> >> > are not getting added in the final executable jar.
> >> >
> >> > I tried searching over google, but most of the links are suggesting to
> >> add
> >> > it local maven repo first. I have some limitations so I cannot add
> those
> >> > dependency on local repo. I want it to picked from file system
> directly,
> >> > and wanted it to be part of final executable jar.
> >> >
> >> > 
> >> > 
> >> > org.teradata
> >> > teradata
> >> > 4.0
> >> > system
> >> >
> >> >
> >>
> ${basedir}/../../../lib/terajdbc4.jar
> >> >
> >> > Above dependency is not getting added in the final jar that maven is
> >> > building.
> >> >
> >> > Please suggest me the right plugin with its usage for this use case.
> >> >
> >> > Any help on this would be really appreciated.
> >> >
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: publishing sub-modules without requiring the parent module to be published?

[Curtis Rueden]

Hi Kevin,

Having a public project extend a private one seems fundamentally
broken/impossible to me.

Presumably your "parent project" is just a POM and not a JAR, right?

Can you use a structure like:

toplevelPublicPOM
 - publicProject1
 - publicProject2
 - privateParentPOM
  -- privateProjectA
  -- privateProjectB

?

Regards,
Curtis

On Mon, Oct 12, 2015 at 1:31 PM, Kevin Burton  wrote:

> That's a good point.  It's a tough call because we're trying to move as
> fast as possible but this means that the code can bitrot and not get
> updates from the community.
>
> The other thing I was thinking about was using the maven updates plugin to
> automatically detect when new versions are released.
>
> The problem with this is that releases get cascaded as libs move up the
> dependency tree.  We have about 150 modules so this could get confusing  if
> we're not careful.
>
> On Mon, Oct 12, 2015 at 5:00 AM, Ron Wheeler <
> rwhee...@artifact-software.com
> > wrote:
>
> > You are probably going to want to make your open source project
> completely
> > separate with its own versions and parent.
> >
> > If third parties are actually going to file issues,  provide updates and
> > create new minor versions as they fix bugs, you are going to either be
> > forced to release versions of your private project before you are ready
> or
> > have to fork your own open source project to maintain a consistent
> version
> > between the 2 parts of your product.
> >
> > Having a successful open source project requires a new way of thinking
> > about your baby.
> >
> > Ron
> >
> >
> >
> > On 12/10/2015 2:49 AM, Baptiste Mathus wrote:
> >
> >> I'm pretty sure you can't. At least on Central who IIRC checks that kind
> >> of
> >> things.
> >> It's indeed needed for the dependency resolution mechanism to work.
> >> Cheers
> >> Le 11 oct. 2015 11:50 PM, "Kevin Burton"  a écrit :
> >>
> >> I'm trying to open source a bunch of code in our stack.
> >>>
> >>> Is it possible to have a parent module private, and the child module
> >>> public?
> >>>
> >>> The problem I have now is that if our customers or the open source
> >>> community imports our modules, it needs to fetch the parent, which is
> >>> private.
> >>>
> >>> I assume this is required due to maven inheritance because it needs to
> >>> determine dependencies.
> >>>
> >>> I can just not specify a  but that causes other problems like
> the
> >>> maven versions problem skipping it for some reason (though maybe this
> is
> >>> a
> >>> bug).
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> We’re hiring if you know of any awesome Java Devops or Linux Operations
> >>> Engineers!
> >>>
> >>> Founder/CEO Spinn3r.com
> >>> Location: *San Francisco, CA*
> >>> blog: http://burtonator.wordpress.com
> >>> … or check out my Google+ profile
> >>> 
> >>>
> >>>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

Re: War file name and sftp to server

[Curtis Rueden]

Hi K R,

> How do I sftp it to the server?

What kind of server? Web server? Maven repository? Something else?

== Web server ==

If it's just a web server, typically that is done outside of the Maven
build. You can also rename the file at that point. Alternately, you can use
the exec-maven-plugin to automate whatever steps you want during any
phase(s) of your Maven build.

== Maven repository ==

If you want to transfer the final artifact to a Maven repository, this is
called "deploying" the artifact, and is done by Maven's deploy phase. You
have to configure the "wagon" plugin you want to use. For SFTP you'd use
wagon-ssh [1].

You have to add a distributionManagement section to your POM, and put your
credentails in your ~/.m2/settings.xml. See:
https://maven.apache.org/plugins/maven-deploy-plugin/usage.html

However, note that you cannot override the final name of the artifact in
your remote Maven repository, since Maven repos use a standard naming
scheme which includes the version suffix.

== Something else ==

Feel free to elaborate on your question. ;-)
http://stackoverflow.com/help/how-to-ask

Regards,
Curtis

[1] https://maven.apache.org/wagon/wagon-providers/wagon-ssh/

On Thu, Oct 8, 2015 at 3:16 PM, K R  wrote:

> I have this in pom.xml
>
> 0.0.1-SNAPSHOT
> YT-100_ATU_Controller
>
> and I get YT-100_ATU_Controller-0.0.1-SNAPSHOT.war how do I get
>  YT-100_ATU_Controller.war?
>
> How do I sftp it to the server?
>

Re: Copy-dependencies goal error

[Curtis Rueden]

Hi Wayne,

> I'm glad Greg was able to help you solve your problem.

Greg's response was great. But in fairness, it was Bernd who actually
stated the solution to Michael's problem. It would be nice if this thread
could wrap up with Michael acknowledging that Bernd's fix actually does the
job.

Regards,
Curtis

On Tue, Oct 6, 2015 at 3:11 PM, Wayne Fay  wrote:

> If you disagree with almost everything I said, there's really no point
> in continuing to discuss it. The possibility of either of us being
> convinced to change our minds is vanishingly small.
>
> I'm glad Greg was able to help you solve your problem.
>
> Respectfully,
> Wayne
>
> On Tue, Oct 6, 2015 at 2:17 PM,   wrote:
> > Wayne,
> >
> > Thank you for your reply.  I think I disagree with almost everything you
> said.
> >
> > First I did not attack anyone.  Was my attitude bad, yes.  Did it get
> worse when I felt like I was not getting the explanation I needed, most
> assuredly.  I called no one a name, nor insulted anyone's intelligence, and
> when I came close to it I apologized.  That's more than I got from several
> of the responders.  Just check the thread, its all there.
> >
> > Second, are you implying that you only support people that are happy
> with the product?  It sounds to me that you are on the defensive already
> and as soon as you get someone that is frustrated or displeased.   Like it
> is somehow their fault.
> >
> > Third, how do you know how much time I've invested in trying to learn
> Maven?  How much is enough before I can have this "intelligent" Maven
> dialog with the Maven community?  Users don't want to ask people for help
> (i.e. at least I like to try and figure things out for myself), but there
> comes a time when you are just plain stuck.  Maybe its because of a mental
> block and maybe something you've read and researched just does not make any
> sense.  Yes I understand that there are some people that probably post
> questions without having made an effort to learn anything.  How do you
> determine that?  How do you differentiate someone who has made an effort
> from someone who is just trying to get an easy answer?
> >
> > With respect to vocabulary and the lingua franca, does "bogus" fit in
> that category.
> >
> > Your comment about the Maven 4.0.0 POM model is particularly
> frustrating.  When you told me to do the research on the original version I
> did exactly as you instructed.  That is how I determined that it was
> 2.2.1.  I'm sorry but I think the POM model version question is valid.  In
> your original reply you did not know the time frame.  I replied to you that
> it goes back at least five years.  You did not respond.  So while I was
> doing the research on the version and I found out it was 2.2.1 I thought
> the POM model version could be a problem.  To tell me now after the fact
> that I should not have been concerned would mean that I would either have
> to assume that you know that or I would have to be a mind reader.
> >
> > And finally I demanded nothing from anyone.  I asked if two of the
> repliers were contributors, and I reiterated a basic question I asked from
> the beginning, several times.
> >
> > Yes I am partly to blame here.  But many of the Maven User List
> responders have a little dirt on their hands too.  I don't see any of you
> acknowledging that.
> >
> > Regards,
> > Mike
> >
> > Michael Tarullo
> > Contractor (Engility Corp)
> > Enterprise Architect
> > NSRR System Administrator
> > FAA WJH Technical Center
> > (609)485-5294
> >
> >
> > -Original Message-
> > From: Wayne Fay [mailto:wayne...@gmail.com]
> > Sent: Tuesday, October 06, 2015 12:30 PM
> > To: Maven Users List
> > Subject: Re: Copy-dependencies goal error
> >
> > Maven is a rather complex piece of software. Many problems cannot be
> simply distilled to "here's your simple problem, and here's your simple
> solution." I understand this is what you want, but it is rarely that
> simple. And attacking the people on this list who are trying to help you
> when you are frustrated with the type of support they are providing is a
> really bad approach to problem solving. Also recognize that many people on
> this list are not US-born native English speakers, so there is sometimes a
> language barrier even when we are all writing English.
> >
> > By using a free product, you (and your employer) should recognize that
> you are trading off dollar costs for other costs - including your own time.
> Please don't complain about people asking you to do something very simple
> like install a couple other versions to see if that fixes your build issue.
> It doesn't sound like you went back and tried 2.2.1 as I originally
> recommended - simply to get more information about what happened, certainly
> not intending to guarantee that would fix your issue. I'd be curious about
> the error message you say that you got in 3.0.5.
> >
> > (Also, as a side-note, the POM model has been 

Re: Copy-dependencies goal error

[Curtis Rueden]

Hi Michael,

> Can you explain " you are using dependencyManagement with dependencies
> declared with scope "import""?

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

> I don't see anything in either my settings.xml or pom.xml that
> explicitly declares this.

Agreed -- I don't see any uses of import scope in the POM attachment you
sent.

Regards,
Curtis

On Mon, Oct 5, 2015 at 1:21 PM,  wrote:

> What is "import scope"?
>
> I don't see anything in either my settings.xml or pom.xml that explicitly
> declares this.  (And I call this my POM, but I inherited it from someone
> else).
>
> Can you explain " you are using dependencyManagement with dependencies
> declared with scope "import""?
>
> Michael Tarullo
> Contractor (Engility Corp)
> Enterprise Architect
> NSRR System Administrator
> FAA WJH Technical Center
> (609)485-5294
>
>
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> Sent: Monday, October 05, 2015 1:51 PM
> To: users@maven.apache.org
> Subject: RE: Copy-dependencies goal error
>
> Hi Michael,
>
> michael.ctr.taru...@faa.gov wrote:
>
> > My apology about part of this reply.  I did not understand part of
> > your suggestion.
> >
> > I thought you were saying 3.0.5 is the latest release.
> >
> > That said, I don't see how using the latest release or an older
> > release makes any difference.
> >
> > I have a requirement to use 3.1.1 from a COTS product vendor, so that
> > is probably not an option.  And "bogus" is just not a good enough
> > explanation for me.  What specifically is wrong with what I am doing
> > that does not work in this release?
>
> I just cite my original mail:
>
> > IIRC you have problems with 3.1.x when using dependencies with import
> > scope, because it ignores then your settings then for transitive deps
> > declaring their own repository in the POM.
>
> AFAICS, you are using dependencyManagement with dependencies declared with
> scope "import"".
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: License Auditing

[Curtis Rueden]

Hi Jim,

I struggled with licensing-related tooling too when I researched it awhile
back—and my needs were simpler than yours. We ended up using
license-maven-plugin to programmatically manage license headers of all our
sources, with a single header with unified copyright date range and
contributors list, which made things much easier. It sounds like your
licensing situation is substantially more heterogeneous.

I do not know of any excellent licensing-related tutorials for license
management, auditing or both. Maybe you could take the bull by the horns
and write a guide somewhere? It would surely be of great benefit to the
Maven community.

Regards,
Curtis

On Mon, Sep 28, 2015 at 11:13 AM, Jim Klo  wrote:

> Hi,
>
> Looking for some guidance on doing some source license auditing.  My needs
> are two fold.  I need to track down all the licenses of all our
> dependencies, which there seems to be an abundance of plugins. But I also
> need to audit the licenses of our committed source, as many come from open
> and non-open projects, I need to track the individual files as well.
>
> I’ve started by using Apache RAT [1], which seems to be okay for auditing
> the source, but given that we have a significant number of modules,
> configuration of RAT is somewhat a pain (I have a bunch of custom license
> definitions and matchers) which seem to have to be added to every POM file
> (doesn’t like going into the parent POM likely because of the way we are
>  using Tycho).
>
> Can anyone recommend a plugin that might be better for my use case?  I’d
> like to be able to have a single config file (or artifact) that contains
> the license declarations, and then be able to reference that from all my
> modules.  The Codehaus License Maven Plugin [2] seems close to what I want,
> but I can’t seem to figure out how to get it to show me files that are
> missing license headers or even show me a per file license summary.  If
> anyone can point me to some examples or tutorials that explain this that
> would be much appreciated.
>
> [1]
> http://creadur.apache.org/rat/apache-rat-plugin/examples/custom-license.html
> [2]
> http://www.mojohaus.org/license-maven-plugin/examples/example-thirdparty.html
>
> Thanks,
>
> JK
>
> *Jim KloSenior Software EngineerCenter for Software EngineeringSRI
> International*
> *t. @nsomnac*
>
>

Re: MRELEASE: Release only modules, not project itself

[Curtis Rueden]

Hi Wouter,

Is the top-level POM also the parent pom of the modules? Or only an
aggregator?

If it's the parent, then you have to release it [1], because consuming the
modules later will require the parent POM as a "dependency" of sorts in
order to fully interpolate each module POM.

If it's only the aggregator, then I agree with you that releasing it is
unnecessary. But I don't have an answer regarding whether that is possible.
On the deployment side, it certainly doesn't hurt anything to release it,
but from an SVN tagging perspective I see how it could be problematic. To
avoid that problem, as a wild guess: maybe you could set
suppressCommitBeforeTag [2] to true (and/or other similar configuration
flags) in the aggregator, but false in the individual modules?

Regards,
Curtis

[1] Unless you use a trick like the flatten-maven-plugin:
http://www.mojohaus.org/flatten-maven-plugin/

[2]
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#suppressCommitBeforeTag


On Thu, Sep 24, 2015 at 5:34 AM, Wouter Lievens 
wrote:

> First of all, the top-level pom has no real meaning. It just aggregates
> the modules, and the "end deliverable" projects (that uses maven-shade to
> build an executable jar etc) are among the modules. I take advantage of the
> top-level pom's topological sorting of the modules that way, of course.
>
> Secondly, our SVN repo is set up with tags/trunk/branches per project (so
> not at the root), and we use SVN externals to pull all (relevant) projects
> into a workspace, which is where the top-level pom sits. In other words,
> the top-level pom doesn't have a tags/trunk/branches hierarchy.
>
> Regards
> Wouter
>
>
> - Original Message -
> From: "Jeff MAURY" 
> To: "Maven Users List" 
> Sent: Thursday, September 24, 2015 12:28:49 PM
> Subject: Re: MRELEASE: Release only modules, not project itself
>
> What is the problem with releasing the parent pom ?
>
> Jeff
> Le 24 sept. 2015 10:58, "Wouter Lievens"  a
> écrit :
>
> > Hello,
> >
> > I would like to run the release plugin (prepare/perform) for a top-level
> > POM (packaging "pom") that has a big list of modules.
> > The top project itself doesn't need to be tagged, released and deployed,
> > because it's there only to build the modules in good order.
> > So, I want the release plugin run over each module, and only on those
> > modules.
> >
> > Is this possible? Could this be added as a feature?
> >
> > Best regards,
> > Wouter Lievens
> >
> >
> > --
> > Wouter Lievens
> > Senior Software Architect
> > CMOSIS bvba
> > Phone +32 3 260 17 58
> >
> > -
> > 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: Best strategy for using lots of modules/projects with some private and some OSS

[Curtis Rueden]

Hi Kevin,

My projects opt for independent versioning of modules to facilitate
"release early, release often." To do this for large sets of components
like yours requires a Bill of Materials -- i.e., common parent POM with
dependencyManagement section.

FWIW, the docs we have about our projects that work this way are at:
* http://imagej.net/Architecture

And in particular:
* http://imagej.net/Architecture#Bill_of_Materials
* http://imagej.net/Architecture#How_SciJava_achieves_reproducible_builds
* http://imagej.net/Philosophy#Release_early.2C_release_often

And the BOM stuff is at:
*
https://github.com/scijava/pom-scijava/blob/pom-scijava-8.3.0/pom.xml#L103-L819

The downside, as you point out, of all components being release version
coupled is that it is annoying to have to do a "release cascade" to
propagate a bug fix from the lowest level components to the highest level
ones. We have some tooling to make that easier (I personally live in the
"releases should be as easy/automated/fast as possible" camp), but the
modularity does cost time sometimes. Hopefully a lot less time than
building your huge multi-module project from scratch every time, though!

I also recently wrote a "melting pot" script to do end-to-end testing of
large component collections:

https://github.com/scijava/scijava-scripts/blob/d892adc0092c220ee1e597b9fb5a1fb067e4509b/melting-pot.sh

This script builds and runs unit tests for all components of a large
collection at their respective versions, all in the same Java runtime, to
ensure that everything _really does_ work together at the versions you are
currently deploying to end users.

I would be happy to know about other tooling people have created to help
with this sort of project structure.

Regards,
Curtis

On Tue, Sep 22, 2015 at 12:47 PM, Kevin Burton  wrote:

> We have a multi-module setup whereby we have about 150 independent modules.
>
> Our build takes a long time and actually slows down development as we have
> to do a compile of a LOT of source code to rebuild the project.
>
> Additionally, we have a lot of code that we want to Open Source.
>
> This has meant git submodules the IMO git submodules really don’t work when
> using branches.  They break and require a whole bunch of custom works and
> hack and when they DO break it’s confusing how to resolve them.
>
> This has meant that we’ve not really done a good job of OSSing our code
> base as its just too hard.
>
> What we’ve done to date is just have one major version number across all
> our projects.  So upgrading them and fixing their dependencies means that I
> just have to change a version number everywhere and I’m done.
>
> What I was thinking of is changing this strategy to use the maven
> "versions:use-latest-versions” plugin.
>
> What i would do is have a parent directory named ‘spinn3r’ which just has a
> bunch of git submodules.  We NEVER branch in this directory.
>
> It also means that any of our developers can check it out so that they have
> all of our source code.
>
> At this point I can use a normal development strategy for each project.
> They don’t use submodules which enables us to branch/merge easily.
>
> I can also have a dedicated IntelliJ or Eclipse project for each one and
> switch between them.
>
> Now the main issue I have is how do I bump releases easily and make sure
> all my code is using the latest version of its sibling projects.
>
> In the parent directory I can just run versions:use-latest-versions … on
> each one of the projects so that it automatically pulled in the latest
> version after a release.
>
> The only problem here is that there’s a dependency graph that needs to be
> considered.
>
> for example, if project A depends on project B, then we have to bump the
> version and push project B into maven before we upgrade dependencies on
> project A.
>
> This is a frustrating issue…
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>

Re: Parent snapshot pom questions

[Curtis Rueden]

Hi Dave,

Maven is not safe for concurrent builds from the same local repository
cache. Do these CI jobs share the same cache? If so that would explain the
nondeterminism you are seeing.

It is best practice if each job has its own local repo cache, as expensive
as that is disk-wise.

Or you can use only a single executor on each node doing Maven builds. But
of course that doesn't scale particularly well.

Also: is there some reason you don't just have a single job that builds the
whole multi-module project? What is the point of having a multi-module
project then? Or: if I misunderstood and these projects are each
single-module, why not use release couplings always (i.e., a release
version of the parent POM)? Then you won't have issues with SNAPSHOTs
getting nondeterministically overwritten etc.

Regards,
Curtis

On Thu, Jul 30, 2015 at 9:45 AM, David Hoffer dhoff...@gmail.com wrote:

 I've got a case where we get random CI build failures.  The error is:

 [FATAL] Non-resolvable parent POM: Could not find artifact

 com.issinc.jms.jms-thirdparty.installers:installer-parent:pom:11.8.0-SNAPSHOT
 in nexus (https://mavenserver/nexus/content/groups/public) and
 'parent.relativePath' points at wrong local POM @ line 43, column 13

 Here is the pom and build layout.

 - pom.xml (parent) This pom has level1 as module but does not have the
 others
 - level1 module
 -- pom.xml
 - level2 module (Has top level pom as parent)
 -- pom.xml
 - level3 module (Has top level pom as parent)
 -- pom.xml
 - level4 module (Has top level pom as parent)
 -- pom.xml

 Now for our CI builds they build this as 4 separate builds, here are what
 they checkout and build.

 - pom.xml (parent)
 - level1
 -- pom.xml

 - level2
 -- pom.xml

 - level3
 -- pom.xml

 - level4
 -- pom.xml

 The first build, builds pointing to the parent and deploys the parent pom
 to Nexus, this build always works.  The level2 to level4 builds don't
 checkout the parent pom as that is not part of the reactor of the build,
 yet it is still the parent.  What we expected to happen is that it would
 pull the parent pom from Nexus.  We have verified that it does exist in
 Nexus yet it can't find it.

 This error is random sometimes it works and sometimes it does not.  We have
 several build agents (14 or so).  The error might be agent specific, e.g.
 if the same agent did the parent/level1 build then it works but not if a
 different agent did it (not sure if that is the case yet).

 What I'm wondering is what is the Maven rules for finding parent (snapshot)
 poms that are not part of the current reactor's build?  We assumed it would
 follow the normal search order, e.g. local repo first, then Nexus but that
 does not seem to be happening.  The error says it is looking in Nexus but
 it doesn't appear to be doing that rather it seems to be looking on the
 local hard drive for the pom via 'parent.relativePath' but we don't even
 use relativePath at all in any of these poms.

 Any idea what is going on?
 .
 -Dave

Re: build error on strutsel

[Curtis Rueden]

Hi Hector,

 how do I find out what version of those libraries are set of code
 compatible with ?  For instance, in my old ant lib folder,  I have a
 struts and struts-el.jar.

For JARs managed in this old Ant way, the versioning is at the whim of each
particular library.

You could check the JAR manifest to see if they put the relevant version
string in there.

You could just try all available versions of the library by changing the
version of your pom.xml until it compiles successfully. You can do a
binary version search to find the version in O(log n) steps instead of
O(n).

You could compare file sizes of the JARs again those of known versions
(e.g., from a fresh download). But you have to be careful with the latter
because the file size may not exactly match depending on exactly how the
JAR was built. Maybe safer would be to diff the output of jar tf and
javap on all the classes?

Perhaps someone here knows a better way.

 should I load those into my own local repository ?

Almost certainly not. Depend on the correct version from Maven Central
whenever possible.

Regards,
Curtis

On Mon, Jul 27, 2015 at 10:16 AM, Magnanao, Hector hector.magna...@sap.com
wrote:

 Curtis,  can you elaborate on this ?  if the libraries I uploaded in my
 pom file are newer, how do I find out what version of those libraries are
 set of code compatible with ?  For instance, in my old ant lib folder,  I
 have a struts and struts-el.jar.  should I load those into my own local
 repository ?

 Hector

 -Original Message-
 From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
 Of Curtis Rueden
 Sent: Friday, July 24, 2015 4:13 PM
 To: Maven Users List
 Subject: Re: build error on strutsel

 Hi Hector,

 Maybe you are depending on the wrong version of those libraries? API change
 and evolve; you have to depend on a version compatible with what was
 originally coded against.

 -Curtis

 On Fri, Jul 24, 2015 at 3:04 PM, Magnanao, Hector hector.magna...@sap.com
 
 wrote:

  Hi Curtis,
 
  I have these remaining errors on my compilation.  I can't figure out if
  this is code or package errors.  Can you help me out ?
 
  [ERROR] COMPILATION ERROR :
  [INFO] -
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[351,53]
  cannot find symbol
symbol:   method getName()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[352,18]
  cannot find symbol
symbol: method setName(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[360,54]
  cannot find symbol
symbol:   method getScope()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[361,18]
  cannot find symbol
symbol: method setScope(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[375,53]
  cannot find symbol
symbol:   method getType()
location: class foundation.web.taglib.struts.html.FormTagEl
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[376,18]
  cannot find symbol
symbol: method setType(java.lang.String)
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,23]
  cannot find symbol
symbol:   class License
location: package aspose.pdf
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,59]
  cannot find symbol
symbol:   class License
location: package aspose.pdf
  [INFO] 8 errors
 
  -Original Message-
  From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
  Of Curtis Rueden
  Sent: Friday, July 24, 2015 1:13 PM
  To: Maven Users List
  Subject: Re: build error on strutsel
 
  Hi Hector,
 
   package com.aspose.cells does not exist
 
  Looks like Aspose.Cells is in its own Maven repo from that company:
 
 
 
 http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html
 
  Found by searching Google for com.aspose.cells maven
 
  Repeat these tricks for all packages you need to find.
 
  -Curtis
 
  On Fri, Jul 24, 2015 at 12:39 PM, Magnanao, Hector 
  hector.magna...@sap.com
  wrote:
 
   Hi Curtis,  that’s ok, I got past that error.  Now I get this one.
  
   [ERROR] Failed to execute goal
   org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
   (default-compile) on project foundation: Compilation failure:
 Compilation
   failure:
   [ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[3,24

Re: build error on strutsel

[Curtis Rueden]

Hi Hector,

Maybe you are depending on the wrong version of those libraries? API change
and evolve; you have to depend on a version compatible with what was
originally coded against.

-Curtis

On Fri, Jul 24, 2015 at 3:04 PM, Magnanao, Hector hector.magna...@sap.com
wrote:

 Hi Curtis,

 I have these remaining errors on my compilation.  I can't figure out if
 this is code or package errors.  Can you help me out ?

 [ERROR] COMPILATION ERROR :
 [INFO] -
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[351,53]
 cannot find symbol
   symbol:   method getName()
   location: class foundation.web.taglib.struts.html.FormTagEl
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[352,18]
 cannot find symbol
   symbol: method setName(java.lang.String)
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[360,54]
 cannot find symbol
   symbol:   method getScope()
   location: class foundation.web.taglib.struts.html.FormTagEl
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[361,18]
 cannot find symbol
   symbol: method setScope(java.lang.String)
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[375,53]
 cannot find symbol
   symbol:   method getType()
   location: class foundation.web.taglib.struts.html.FormTagEl
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[376,18]
 cannot find symbol
   symbol: method setType(java.lang.String)
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,23]
 cannot find symbol
   symbol:   class License
   location: package aspose.pdf
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[35,59]
 cannot find symbol
   symbol:   class License
   location: package aspose.pdf
 [INFO] 8 errors

 -Original Message-
 From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
 Of Curtis Rueden
 Sent: Friday, July 24, 2015 1:13 PM
 To: Maven Users List
 Subject: Re: build error on strutsel

 Hi Hector,

  package com.aspose.cells does not exist

 Looks like Aspose.Cells is in its own Maven repo from that company:


 http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html

 Found by searching Google for com.aspose.cells maven

 Repeat these tricks for all packages you need to find.

 -Curtis

 On Fri, Jul 24, 2015 at 12:39 PM, Magnanao, Hector 
 hector.magna...@sap.com
 wrote:

  Hi Curtis,  that’s ok, I got past that error.  Now I get this one.
 
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
  (default-compile) on project foundation: Compilation failure: Compilation
  failure:
  [ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[3,24]
  package com.aspose.cells does not exist
 
  From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
  Of Curtis Rueden
  Sent: Friday, July 24, 2015 12:35 PM
  To: Maven Users List
  Subject: Re: build error on strutsel
 
  Hi Hector,
 
   I clicked on the link and it returns nothing.
   How do I search for it in the repository ?
 
  That's baffling. I see this:
 
  [Inline image 1]
 
  I have no clue why it would be different for you...
 
  Regards,
  Curtis
 
  On Fri, Jul 24, 2015 at 12:31 PM, Magnanao, Hector 
  hector.magna...@sap.commailto:hector.magna...@sap.com wrote:
  Hi Curtis,
 
  I clicked on the link and it returns nothing.  How do I search for it in
  the repository ?
 
  -Original Message-
  From: ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com [mailto:
  ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com] On Behalf Of
  Curtis Rueden
  Sent: Friday, July 24, 2015 12:17 PM
  To: Maven Users List
  Subject: Re: build error on strutsel
 
  Hi Hector,
 
   I can't find it in the maven repository.
 
 
 
 http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.apache.strutsel.taglib.utils%22
 
  -Curtis
 
  On Fri, Jul 24, 2015 at 12:11 PM, Magnanao, Hector 
  hector.magna...@sap.commailto:hector.magna...@sap.com
  wrote:
 
   How do I resolve this package error ?  I can't find it in the maven
   repository.
  
   ERROR] Failed to execute goal
   org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
   (default-compile) on project foundation: Compilation failure:
 Compilation
   failure:
   ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[64,40]
   package org.apache.strutsel.taglib.utils does not exist
   ERROR]
  
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web

Re: build error on strutsel

[Curtis Rueden]

Hi Hector,

 package com.aspose.cells does not exist

Looks like Aspose.Cells is in its own Maven repo from that company:

http://www.aspose.com/blogs/aspose-products/aspose-total-product-family/archive/2014/08/12/aspose-for-maven-aspose-cloud-maven-repository.html

Found by searching Google for com.aspose.cells maven

Repeat these tricks for all packages you need to find.

-Curtis

On Fri, Jul 24, 2015 at 12:39 PM, Magnanao, Hector hector.magna...@sap.com
wrote:

 Hi Curtis,  that’s ok, I got past that error.  Now I get this one.

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
 (default-compile) on project foundation: Compilation failure: Compilation
 failure:
 [ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/cache/LicenseService.java:[3,24]
 package com.aspose.cells does not exist

 From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
 Of Curtis Rueden
 Sent: Friday, July 24, 2015 12:35 PM
 To: Maven Users List
 Subject: Re: build error on strutsel

 Hi Hector,

  I clicked on the link and it returns nothing.
  How do I search for it in the repository ?

 That's baffling. I see this:

 [Inline image 1]

 I have no clue why it would be different for you...

 Regards,
 Curtis

 On Fri, Jul 24, 2015 at 12:31 PM, Magnanao, Hector 
 hector.magna...@sap.commailto:hector.magna...@sap.com wrote:
 Hi Curtis,

 I clicked on the link and it returns nothing.  How do I search for it in
 the repository ?

 -Original Message-
 From: ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com [mailto:
 ctrueden.w...@gmail.commailto:ctrueden.w...@gmail.com] On Behalf Of
 Curtis Rueden
 Sent: Friday, July 24, 2015 12:17 PM
 To: Maven Users List
 Subject: Re: build error on strutsel

 Hi Hector,

  I can't find it in the maven repository.


 http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.apache.strutsel.taglib.utils%22

 -Curtis

 On Fri, Jul 24, 2015 at 12:11 PM, Magnanao, Hector 
 hector.magna...@sap.commailto:hector.magna...@sap.com
 wrote:

  How do I resolve this package error ?  I can't find it in the maven
  repository.
 
  ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
  (default-compile) on project foundation: Compilation failure: Compilation
  failure:
  ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[64,40]
  package org.apache.strutsel.taglib.utils does not exist
  ERROR]
 
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/bean/MessageTagEl.java:[72,40]
  package org.apache.strutsel.taglib.utils does not exist
 
  Hector Magnanao Jr.
  SCM Analyst
 
  Fieldglass, Inc.
  O: (331) 702-6142tel:%28331%29%20702-6142
  M: (773) 474-3051tel:%28773%29%20474-3051
  hector.magna...@sap.commailto:hector.magna...@sap.com
  www.fieldglass.comhttp://www.fieldglass.com
 
  Fieldglass is now part of SAP
 
  This email contains confidential information.  If you are not the
 intended
  recipient, do not read, distribute or reproduce this transmission
  (including any attachments). If you have received this email in error,
  please notify the sender by email reply.
 
 

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

Re: How to delete certain snapshots from Nexus

[Curtis Rueden]

Hi Dave,

 1. I didn't set requireReproducibleBuilds as I wasn't sure how or if
 that is done internally by the verify-no-snapshots goal.  (Worked
 really well w/o setting it.)

Use either the verify-no-snapshots goal (as you are doing now), _or_ the
scijava-maven-plugin as a set of extra enforcer rules. You don't need both.
The latter is nice if you are already using enforcer and want to keep all
those sorts of checks together. Here is how my projects configure the
enforcer:


https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L1112-L1221

You of course wouldn't need all those rules. The important block is:

requireReproducibleBuilds
implementation=org.scijava.maven.plugin.RequireReproducibleBuilds
  groupIdsorg.scijava/groupIds
/requireReproducibleBuilds

Replacing groupIds with the groupIds you want to check.

 2. How to skip per pom?  I didn't see any skip configuration option
 so as a workaround I set the groupId in configuration to be 'skip'
 and that works.

That seems like a reasonable workaround.

If you want to add a more proper skip flag, PRs are warmly welcomed. :-)

 3. How to disable globally via command line argument?  I tried
 -Denforcer.skip=true but it doesn't seem to work...still testing that
 again.

If you use the requireReproducibleBuilds rule of the enforcer, instead of
binding the verify-no-snapshots goal, then -Denforcer.skip=true will do
the job for you. That's how we skip it during local development. Of course,
this skips _all_ enforcer checks, so would be highly discouraged for
production.

 4. How to exclude a few groupIds from enforcement?  We have a couple
 cases where we do consume an approved snapshot so I need a way to
 configure allowed snapshot groupIds.

Yeah, there's an open issue for that:
   https://github.com/scijava/scijava-maven-plugin/issues/8

 5. How to ignore certain points of failure such as a artifact pom (not
 a snapshot one) that has two organizational sections currently causes
 a build failure, I'd like to just warn on those types of issues.

Hmm, this may be another use case for issue #8 linked above. If you had
full GA(V) include/exclude filtering, you could filter out that particular
POM from consideration.

 Again, works super well but I just need to tweak its configuration a
 bit.

Really glad to hear it is helpful!

Regards,
Curtis

On Fri, Jul 24, 2015 at 11:55 AM, David Hoffer dhoff...@gmail.com wrote:

 Hi Curtis,

 First I want to say this plugin works great, I added it to the build and it
 caught a number of issues before we went to release.

 I do have a few questions.  First I'm not sure I have it fully configured
 correctly, my usage is below.  With this usage it found all the cases where
 the build was consuming a snapshot not being generated in the reactor which
 is exactly what I was looking for.

 There are a few other options I need as well and was hoping you could
 provide some guidance on how to support them.

 1. I didn't set requireReproducibleBuilds as I wasn't sure how or if that
 is done internally by the verify-no-snapshots goal.  (Worked really well
 w/o setting it.)
 2. How to skip per pom?  I didn't see any skip configuration option so as a
 workaround I set the groupId in configuration to be 'skip' and that works.
 3. How to disable globally via command line argument?  I tried
 -Denforcer.skip=true but it doesn't seem to work...still testing that
 again.
 4. How to exclude a few groupIds from enforcement?  We have a couple cases
 where we do consume an approved snapshot so I need a way to configure
 allowed snapshot groupIds.
 5. How to ignore certain points of failure such as a artifact pom (not a
 snapshot one) that has two organizational sections currently causes a build
 failure, I'd like to just warn on those types of issues.

 Again, works super well but I just need to tweak its configuration a bit.

 plugin
 artifactIdmaven-enforcer-plugin/artifactId
 version1.3.1/version
 dependencies
 dependency
 groupIdorg.codehaus.mojo/groupId
 artifactIdextra-enforcer-rules/artifactId
 version1.0-beta-3/version
 /dependency
 dependency
 groupIdorg.scijava/groupId
 artifactIdscijava-maven-plugin/artifactId
 version${scijava-maven-plugin.version}/version
 /dependency
 /dependencies
 /plugin
 plugin
 groupIdorg.scijava/groupId
 artifactIdscijava-maven-plugin/artifactId
 executions
 execution
 idverify-no-nonreactor-snapshots/id
 phasevalidate/phase
 goals
 goalverify-no-snapshots/goal
 /goals
 configuration
 /configuration
 /execution
 /executions
 /plugin



 On Wed, Jul 22, 2015 at 10:12 PM, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Dave,
 
   if you have a plugin that solves the same problem that is fine.
   If you could elaborate on your solution that would

Re: build error on strutsel

[Curtis Rueden]

Hi Hector,

 I can't find it in the maven repository.

http://search.maven.org/#search%7Cga%7C1%7Cfc%3A%22org.apache.strutsel.taglib.utils%22

-Curtis

On Fri, Jul 24, 2015 at 12:11 PM, Magnanao, Hector hector.magna...@sap.com
wrote:

 How do I resolve this package error ?  I can't find it in the maven
 repository.

 ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
 (default-compile) on project foundation: Compilation failure: Compilation
 failure:
 ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/html/FormTagEl.java:[64,40]
 package org.apache.strutsel.taglib.utils does not exist
 ERROR]
 /C:/Foundation/foundation/src/main/java/com/mycompany/app/web/taglib/struts/bean/MessageTagEl.java:[72,40]
 package org.apache.strutsel.taglib.utils does not exist

 Hector Magnanao Jr.
 SCM Analyst

 Fieldglass, Inc.
 O: (331) 702-6142
 M: (773) 474-3051
 hector.magna...@sap.com
 www.fieldglass.com

 Fieldglass is now part of SAP

 This email contains confidential information.  If you are not the intended
 recipient, do not read, distribute or reproduce this transmission
 (including any attachments). If you have received this email in error,
 please notify the sender by email reply.