Re: Improving the speed of ‘deploy’ ?

[Curtis Rueden]

Hi Kevin,

 I think the issue is that I”m using scpexe for my
 distributionManagement repository.

Is there some reason you can't just use wagon-ssh?

http://stackoverflow.com/a/14404990

Regards,
Curtis

On Fri, Sep 12, 2014 at 1:11 PM, Kevin Burton bur...@spinn3r.com wrote:

 mvn package” on my code , without tests, is actually pretty fast.  Takes
 about one minute.  (I don’t need the tests btw as I’m using continuous
 integration and the code is already tested).

 One minute is pretty darn good…

 The problem is that ‘deploy’ takes about 7 minutes.

 That’s kind of not fun.

 I think the issue is that I”m using scpexe for my distributionManagement
 repository.

 Any options for improving the performance here?

 I think the issue is creating new SSH connections each time.  I could use
 ControlPersist I think… which is an SSH feature to keep the SSH connection
 in the background and re-use it.

 Downside: This will require me to use a custom SSH config everywhere.

 Another option is to use a file:// repository which is local and then rsync
 the binaries over in one pass.

 Downside: kind of jacky and requires an additional step.

 Any other options ?



 --

 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
 http://spinn3r.com

Re: retrying flakey tests?

[Curtis Rueden]

Hi Kevin,

 Is there a way to retry a flakey test?

In general I agree with Martin Todorov that tests should be small and
atomic, and flakiness is a sign of larger problems. However, I also agree
with you that sometimes flaky tests are a reality: my group has run into
this with behavior of the JVM garbage collector differing on Windows, for
example, in a rather nondeterministic way. In that case, retrying tests
~5-10 times was a good solution for us.

But rather than configuring Surefire or Failsafe to do this, I'd suggest
(if possible) to write it into the test itself. Put the test in a for loop,
and then assert at the end that numSuccesses  0 or whatever. You then also
issue a warning if numSuccesses != numAttempts, as you requested. In short:
it gives you the flexibility you need.

Regards,
Curtis

On Fri, Sep 19, 2014 at 11:24 AM, Kevin Burton bur...@spinn3r.com wrote:

 Is there a way to retry a flakey test?

 I’d basically like to have a flag that retries a failing test 2 or 3 times.

 Flakey and non deterministic tests are a fact of life in more complicated
 systems.

 The main problem being that they are impossible to setup again because
 they’re usually race conditions.

 If I could just retry the test a second time , that would solve this issue.

 Would be nice to have the build warned that the test is failing though..

 --

 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
 http://spinn3r.com

Re: usage with Jenkins

[Curtis Rueden]

Hi Grover,

 CI build/packages successfully but not
 artifacts are listed on the jobs page

For Jenkins to publish artifacts (for any build, not just Maven-based ones)
you must use the publish artifacts option and specify the file path
patterns to publish.

Also, stay away from the Jenkins Maven style job. Freestyle is more
flexible and less buggy.

Regards,
Curtis
On Sep 22, 2014 4:21 PM, Grover Blue grover.b...@gmail.com wrote:

 Is there anything special that needs to be added to a pom in order to work
 with Jenkins?  For some reason, by CI build/packages successfully but not
 artifacts are listed on the jobs page (they are hidden on the file-system
 in a default/* directory).

Re: usage with Jenkins

[Curtis Rueden]

The Maven style build will also lock you in to a small subset of Jenkins's
usual features. And when you eventually need a feature not available with a
Maven-style build, there is no conversion path from Maven-style to
Freestyle -- you have to recreate the job (losing the build history etc.).

-Curtis
On Sep 23, 2014 7:33 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 Freestyle does not mess with your build and change it from building the way
 maven intends. Google stephen's java adventures Jenkins maven considered
 evil for a more detailed discussion

 On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com
 wrote:

  On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu
  javascript:; wrote:
  
  
   Also, stay away from the Jenkins Maven style job. Freestyle is more
   flexible and less buggy.
  
 
  Based on ..?
 


 --
 Sent from my phone

Re: usage with Jenkins

[Curtis Rueden]

Hi James,

 I can no longer see Deploy artifacts to Maven repository
 as a post-build action.

Just add a build step that does mvn deploy or similar.

 Dare I ask what I'm missing having chosen the full-fat option..?

If you're asking what you cannot do with freeform jobs: I don't know of
anything. I think the Maven-style job is just a convenience to get very
basic CI set up as quickly as possible, for people without much technical
know-how.

If you're asking for more details on limitations of the Maven-style job:
it's been awhile, but IIRC my group had several problems. One such was that
the Jenkins Git plugin did not fire Maven-style jobs upon receiving the
push notification from GitHub. Another really serious problem is that you
can't add arbitrary shell script as a post-build step. And needing to do
this is, in my experience, extremely common.

It wouldn't be that big of an issue if there were an easy way to later
convert a Maven-style job to a freestyle job should the need arise. But
try a web search on that topic and you'll see what I mean about it being a
highly non-trivial problem.

Regards,
Curtis

On Tue, Sep 23, 2014 at 8:56 AM, James Green james.mk.gr...@gmail.com
wrote:

 News to me. Ironically I'm just setting up a new Jenkins job so tried the
 freeform style - I can no longer see Deploy artifacts to Maven repository
 as a post-build action.

 Dare I ask what I'm missing having chosen the full-fat option..?

 On 23 September 2014 14:02, Curtis Rueden ctrue...@wisc.edu wrote:

  The Maven style build will also lock you in to a small subset of
 Jenkins's
  usual features. And when you eventually need a feature not available
 with a
  Maven-style build, there is no conversion path from Maven-style to
  Freestyle -- you have to recreate the job (losing the build history
 etc.).
 
  -Curtis
  On Sep 23, 2014 7:33 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com
  wrote:
 
   Freestyle does not mess with your build and change it from building the
  way
   maven intends. Google stephen's java adventures Jenkins maven
 considered
   evil for a more detailed discussion
  
   On Tuesday, 23 September 2014, James Green james.mk.gr...@gmail.com
   wrote:
  
On 23 September 2014 02:23, Curtis Rueden ctrue...@wisc.edu
javascript:; wrote:


 Also, stay away from the Jenkins Maven style job. Freestyle is
 more
 flexible and less buggy.

   
Based on ..?
   
  
  
   --
   Sent from my phone
  
 

Announcing the NAR plugin for Maven 3.2.0

[Curtis Rueden]

-- Forwarded message --
From: Johannes Schindelin johannes.schinde...@gmx.de
Date: Thu, Oct 2, 2014 at 12:05 PM
Subject: [maven-nar] Announcing the NAR plugin for Maven 3.2.0
To: maven-...@googlegroups.com


Dear Maven users,

it is a great honor to announce a new version of the NAR plugin for Maven,
designed to support cross-platform development using JNI libraries.

As always, this release would not be possible without a thriving developer
community.  Here is the shortlog:

26  Johannes Schindelin
21  Fredrik Orderud
14  Curtis Rueden
 8  HongKee Moon
 5  Benson Margulies
 2  Sevag Doniguian
 1  Wouter Pasman
 1  Ivan Drobyshevskyi
 1  Mark Hiner
 1  Philippe Marschall
 1  Tomasz Krakowiak
 1  Trevor Robinson

These are the changes since version 3.1.0 (the parenthesized numbers refer
to pull requests of https://github.com/maven-nar/nar-maven-plugin).

Bug fixes:

- The description of the examples now mentions explicitly that they are
  integration tests (#109)

- We use a newer maven-site-plugin version to fix a breakage (#113)

- The documentation now talks about narSystemPackage where it talked
  about the non-existent packageName before (#110)

- The licensing was cleaned up (#120)

- We now use the more appropriate msvc label for Microsoft Visual C/C++
  instead of devstudio (#123)

- The history.xml file included into the .nar artifacts is now actually
  properly named, and as a consequence properly populated, too (#114)

- The documentation no longer references the incorrect arch tag but
  correctly calls it architecture (#132)

- The web site no longer suggests that the NAR plugin is an official
  Apache project (this was the original intention, but it never became
  reality) (#133)

- On Windows, inconsistent usage of the environment variable Path was
  fixed (#134)

- Fixed dead links in the documentation (#136)

- Grammar sweep of the documentation (#137)

Improvements:

- A new integration test demonstrates how to use a JNI .nar from a .jar
  file (#112)

- The AOL properties are now documented (#115)

- It is now possible to filter which headers are included in the
  artifacts (#124)

- We joined the 21st century by using generics now (#127)

- It is now possible to develop NAR projects in Eclipse even if they use
  the NarSystem class (#130)

- We now use the Maven 3.0.4 platform (#118)

- Support was added for the VisualAge compiler on AIX (#131)

- The web site now uses the very pretty fluido skin and sports the NAR
  logo prominently (#133)

The new look of the web site can be adored here:
https://maven-nar.github.io/

On behalf of all the developers making the NAR plugin awesome,
Johannes

--
You received this message because you are subscribed to the Google Groups
NAR Maven plugin group.
To unsubscribe from this group and stop receiving emails from it, send an
email to maven-nar+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pre-verify over deploy]

[Curtis Rueden]

Hi Fay,

 Could i define a intermediate repository, everytime they deploy,
 jenkins will verify it.

Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
has deploy permission to your remote repository. So your devs can no longer
run mvn deploy from the CLI and expect it to work, but instead just push
to master (or whatever integration branch) and then Jenkins runs the build.

Once Jenkins does your deploys, you can set up your jobs to test for more
stringent conditions before actually doing the deploy. E.g.:

$ git clean -fdx
$ mvn clean install
$ bin/verify-artifacts.sh
$ mvn deploy

And verify-artifacts.sh does whatever further programmatic testing you
need.

OTOH, in many cases, you don't need a shell script -- often times, you can
get what you need using Maven plugins like Surefire, Failsafe, and
Enforcer. If you go that route, it might be enough so that devs running
mvn deploy won't deploy bad stuff to the repo by default (unless they are
aggressive enough to run e.g. mvn -DskipTests deploy which would be
pretty bold).

Regards,
Curtis

On Wed, Oct 29, 2014 at 3:18 AM, Fay Wong philip584...@gmail.com wrote:

 Many thanks to Barrie.

 I think what you have clarified is the normal flow of maven practice.

 The deploy in the context of my previous post means: our developer invoke
 a mvn deploy command to share the output(bytecode) through the repository
 so as to shorten the build time of whole project(as its code base is too
 large). Our goal is modular compiling and packaging.

 Currently my pain is our developer would deploy broken bytecode to our dev
 repository and broken others work. Could i define a intermediate
 repository, everytime they deploy, jenkins will verify it. if pass, then
 depoy it into dev repository, otherwise, revert the intermediate repository
 to keep sync with dev repository.

 Is there a easier way to achieve this?

 2014-10-29 13:07 GMT+08:00 Barrie Treloar baerr...@gmail.com:

  On 29 October 2014 14:00, Fay Wong philip584...@gmail.com wrote:
 
   Hi all,
  
   Is there any solution to pre-verify the deploy before it actually got
  into
   the repository?
  
   Take this usecase for example:
  
   In a team of 40 developer, every developer will deploy their module at
  any
   time, once there's a error,
  
   the final output software won't work and blocks other developer's flow.
  
   So is there any pre-verify solution(such as jenkins CI-server) to be
   enforced before the deploy overlapped the previous deploy?
 
 
  Not really, this is a process issue.
 
  You need to decide what is in a state of flux, and then when people
 should
  consume it.
 
  I'm assuming by deploy you mean a released artifact and not a snapshot
  one.
  Generally, you should not be deploying your snapshots for consumption by
  other developers, as snapshots could break at any time and you impact
  anyone who depends upon them.
  Instead, when a developer needs a snapshot version they check out the
 code
  and building it themselves, then when they need to import new changes
 they
  pull in the changes to the code and rebuild. That way the developer gets
 to
  choose when they will consume potentially breaking changes.
 
  If these are released artifacts then you have lots of choices on how to
 do
  this.
  *) By using your version control system and some form of isolation (e.g.
  branches).
 When the new version is released the developer still needs to pull
 those
  changes in, and if there are breaking changes can revert back to the
  previous version.
  *) Have someone in a QA role validate that the artifact works prior to
  promoting that version in you parent pom.
 
  The act of deploying into your Maven Repository is independent from the
  consumption of that artifact, it shouldn't be breaking peoples build
 until
  they start using it.
 

Re: [pre-verify over deploy]

[Curtis Rueden]

Hi Barrie,

 Whether its Jenkins, or a developer, you've still pushed a release
 that could break the build.

 This is where you need some isolation available to your workflow.

Agreed!

However, for Fay's stated requirement, it may be sufficient to have a
broken master branch as long as the latest deployed SNAPSHOT is not broken,
since he stated:

 Currently my pain is our developer would deploy broken bytecode to our
 dev repository and broken others work.

Regards,
Curtis

On Wed, Oct 29, 2014 at 5:15 PM, Barrie Treloar baerr...@gmail.com wrote:

 On 30 October 2014 08:38, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Fay,
 
   Could i define a intermediate repository, everytime they deploy,
   jenkins will verify it.
 
  Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
  has deploy permission to your remote repository. So your devs can no
 longer
  run mvn deploy from the CLI and expect it to work, but instead just
 push
  to master (or whatever integration branch) and then Jenkins runs the
 build.
 
  Once Jenkins does your deploys, you can set up your jobs to test for more
  stringent conditions before actually doing the deploy. E.g.:
 
  $ git clean -fdx
  $ mvn clean install
  $ bin/verify-artifacts.sh
  $ mvn deploy
 
  And verify-artifacts.sh does whatever further programmatic testing you
  need.
 
  OTOH, in many cases, you don't need a shell script -- often times, you
 can
  get what you need using Maven plugins like Surefire, Failsafe, and
  Enforcer. If you go that route, it might be enough so that devs running
  mvn deploy won't deploy bad stuff to the repo by default (unless they
 are
  aggressive enough to run e.g. mvn -DskipTests deploy which would be
  pretty bold).
 
  Regards,
  Curtis


 Whether its Jenkins, or a developer, you've still pushed a release that
 could break the build.

 This is where you need some isolation available to your workflow.

 Stuff breaks - it happens, Fay needs to determine how they want to deal
 with it.

maven-javadoc-plugin: resource folders interpreted as illegal package names

[Curtis Rueden]

Hi everyone,

I am trying to generate an aggregated set of javadocs from a collection of
related projects, like so:

https://github.com/imagej/imagej-javadoc/blob/83d2fe7f2d546cdc0971f323dfaf56d0089e715d/pom.xml

Basically, this POM project declares a bunch of dependencies and then uses
the maven-javadoc-plugin's
includeDependencySourcestrue/includeDependencySources option.

Some of the dependencies have a script-templates folder in their
resources, which gets lumped into the -sources JAR by the
maven-source-plugin.

Unfortunately, the javadoc tool hates seeing folders with violate java
package naming conventions. So my build ultimately fails with:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs)
on project imagej-javadoc: MavenReportException: Error while creating
archive:
[ERROR] Exit code: 1 - javadoc: error - Illegal package name:
script-templates.Java

I tried adding excludePackageNamesscript-templates/excludePackageNames
to the maven-javadoc-plugin configuration, but it seemed to have no effect.

Does anyone have ideas how to work around this problem?

Thanks,
Curtis

P.S. I could rename the script-templates folders in all of the
dependencies, and then update the code to handle both the old and new
resource locations, and then release new versions of them all, but that
would be a substantial amount of work. And the problem could still crop up
again later if any other incompatibly-named folders appear in any
-sources JARs.

Re: maven-javadoc-plugin: resource folders interpreted as illegal package names

[Curtis Rueden]

Hi all,

OK, given the deafening silence, I posted it on SO:
http://stackoverflow.com/q/26787825/1207769

Regards,
Curtis

On Wed, Nov 5, 2014 at 12:42 PM, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi everyone,

 I am trying to generate an aggregated set of javadocs from a collection of
 related projects, like so:


 https://github.com/imagej/imagej-javadoc/blob/83d2fe7f2d546cdc0971f323dfaf56d0089e715d/pom.xml

 Basically, this POM project declares a bunch of dependencies and then uses
 the maven-javadoc-plugin's
 includeDependencySourcestrue/includeDependencySources option.

 Some of the dependencies have a script-templates folder in their
 resources, which gets lumped into the -sources JAR by the
 maven-source-plugin.

 Unfortunately, the javadoc tool hates seeing folders with violate java
 package naming conventions. So my build ultimately fails with:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs)
 on project imagej-javadoc: MavenReportException: Error while creating
 archive:
 [ERROR] Exit code: 1 - javadoc: error - Illegal package name:
 script-templates.Java

 I tried adding excludePackageNamesscript-templates/excludePackageNames
 to the maven-javadoc-plugin configuration, but it seemed to have no effect.

 Does anyone have ideas how to work around this problem?

 Thanks,
 Curtis

 P.S. I could rename the script-templates folders in all of the
 dependencies, and then update the code to handle both the old and new
 resource locations, and then release new versions of them all, but that
 would be a substantial amount of work. And the problem could still crop up
 again later if any other incompatibly-named folders appear in any
 -sources JARs.

Re: Little documentation issues

[Curtis Rueden]

Hi all,

 Can someone suggest a description of plugin and Mojo that is
 written from a developer's point of view but sufficiently close to the
 technical reality that it will not cause trouble when someone starts
 to read the Plugin Developer's sections.

Here's my first cut at it:

A *plugin* is an extension of Maven that provides additional behavior
during a build. Nearly every aspect of a Maven build is defined as plugins.
For example, the maven-compiler-plugin provides the logic needed to compile
Java classes from sources, and the maven-jar-plugin knows how to packages
those Java classes into JAR files.

Plugins that are part of the official Maven project are named according to
the pattern maven-foo-plugin, where foo relates to the plugin's
purpose (e.g., compiler or jar as described above). Unofficial plugins,
such as those produced by the Codehaus project, are typically named
according to the pattern foo-maven-plugin to avoid any implication that
they are somehow official Maven(TM) products.

Every plugin consists of a collection of *goals*, each of which defines
specific behavior. Some goals automatically become part of the build when
the plugin is declared in your POM, injecting themselves at the appropriate
phase in the build's default lifecycle
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.
Others need to be explicitly bound to the desired phase(s) as *executions*.
Some sophisticated plugins (such as the nar-maven-plugin
https://github.com/maven-nar/nar-maven-plugin) even define new phases of
the lifecycle. Each plugin goal is implemented as a mojo
http://maven.apache.org/developers/mojo-api-specification.html: a Java
class providing the code necessary to accomplish that specific goal. For
that reason, people sometimes use the terms goal and mojo
interchangeably.

The ecosystem of available plugins makes Maven an exceptionally versatile
and powerful tool for managing nearly every imaginable aspect of your
project's build process.

Regards,
Curtis

P.S. I disclaim all copyright interest in the above. Please use / steal /
edit / tear apart / throw away as you wish.



On Tue, Dec 9, 2014 at 1:58 PM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 I have made some of the changes in the attached file.

 There is not much that can be done until the plugin definition is added.
 This definition will clarify a few things and may make it easier to fix
 some of the other things.

 There are sentences like this one:
  The second way to add goals to phases is to configure plugins in your
 project. Plugins are artifacts that provide
   goals to Maven.
 that is written from an odd point of view.

 If I am a Java developer, why would adding more goals be something that I
 want to do?

 Each entire sections should be written from a developers point of view.
 Rather than adding goals, I may want to perform some special processing
 during the build.
 This may require the configuration of additional plugins which in turn
 might get activated by invoking additional goals (or not).
 As a Java developer, I can not add goals unless the goals are part of the
 plugin and I would only add goals
 a) if the goals were not already in the standard maven build flow AND
 b) the goal is available in the plugin.

 I suspect that this is a common problem with the Introductory
 documentation that makes it hard for a Java developer to read.

 Can someone suggest a description of plugin and Mojo that is written
 from a developer's point of view but sufficiently close to the technical
 reality that it will not cause trouble when someone starts to read the
 Plugin Developer's sections.

 Ron




 On 09/12/2014 11:42 AM, Ron Wheeler wrote:

 After using maven for 7+years, I decided that I finally knew enough about
 it to read the docs.
 I started here - http://maven.apache.org/guides/getting-started/index.
 html - and this led to other pages.

 I have found some places where a little cleaning up might help new users.
 There is one BIG issue and a few smaller ones.

 1) http://maven.apache.org/guides/introduction/
 introduction-to-the-lifecycle.html
 1a)
  Packaging

 The first, and most common way, is to set the packaging for your project
 via the equally named POM element packaging. Some of the valid packaging
 values are jar, war, ear and pom.
 
 Could we have the full list here or a link to a page with the full list
 of the normal ones?
 Could we have a mention that plug-ins can provide new packaging. There is
 an example after the table of the Plexus. This discussion would be better
 if held together rather than split up with a discussion of binding and a
 table between the two parts of the story.


 1b) In the table following this line Each packaging contains a list of
 goals to bind to a particular phase. For example, thejarpackaging will bind
 the following goals to build phases of the default lifecycle. a heading
 row would be nice.

 1c)
 Plugins are mentioned well before they are defined 

Re: [scala-debate] Emotional Support Group for Typesafe Maven Users

[Curtis Rueden]

Hi Eric,

 Is there some alternative to Play, such that we can migrate existing
 Play projects to something that is Maven friendly?

Grails?

http://grails.org/doc/latest/guide/commandLine.html#antAndMaven
http://raibledesigns.com/rd/entry/play_vs_grails_smackdown_at

Regards,
Curtis

On Tue, Dec 9, 2014 at 3:12 PM, Eric Kolotyluk eric.koloty...@gmail.com
wrote:

 Ouch, I was afraid someone would say something like that.

 Is there some alternative to Play, such that we can migrate existing Play
 projects to something that is Maven friendly?

 Cheers, Eric


 On 2014-12-04 5:31 AM, Martijn Verburg wrote:

 Play *very* firmly wants you to use the activator framework to control
 your
 build and deploy - I'd seriously not try and fight against it.  It's one
 of
 the reasons we dropped the Play framework for a community project we're
 working on, that and the constant breaking of APIs etc :-).

 Cheers,
 Martijn

 On 4 December 2014 at 12:58, Jeff Jensen jeffjensen@
 upstairstechnology.com
 wrote:

  If you want to publish to Maven Central I recommend

 https://www.packtpub.com/application-development/
 getting-started-apache-maven-video

 In case it helps, I've helped a few deploy to Central and recommend this
 (and the other pages on the Producers menu); makes it very easy:
 http://central.sonatype.org/pages/ossrh-guide.html


 On Wed, Dec 3, 2014 at 3:53 PM, Eric Kolotyluk eric.koloty...@gmail.com
 
 wrote:

  Ha ha ha. Very good :-)

 I have published to Maven Central, so I know how daunting this can be at
 first.

 If you want to publish to Maven Central I recommend
 https://www.packtpub.com/application-development/
 getting-started-apache-maven-video

 Cheers, Eric

 On 12/3/2014 11:27 AM, Jon Pretty wrote:

  I can offer you this:

 http://play.textadventures.co.uk/Play.aspx?id=zv-wer8keey6rnhk4am25q

 It's a create-your-own-adventure about my experience of trying to

 publish

 a library to Maven Central. It's a couple of years old now, so the
 landscape might have improved a little in patches.

 Jon


 On 3 December 2014 at 19:11, Eric Kolotyluk eric.koloty...@gmail.com
 mailto:eric.koloty...@gmail.com wrote:

  Does anyone know of a good emotional support group for people
  trying to use Maven with Typesafe projects such as Akka and Play?

  I was thinking maybe there could a buddy/sponsor system, such as
  used in AA and other self help groups. Maybe there might be group
  sessions where people can talk about their trauma, especially by
  being constantly invalidated by comments such as you should use
  the simple build tool SBT, cause, well you know, it's simple and
  easy to use.

  Seriously though, is there a community of people who are
  successfully using Maven with Akka an Play projects? I would love
  to meet you.

  I can see why people who have tried Maven naturally think oh,
  its' too complicated, anyone can write a simple build tool that
  does what Maven does. Clearly they do not appreciate what Maven
  is or what it does. SBT and Gradle are two great examples of
  projects that attempted to do something more simple, but in the
  end, really don't measure up.

  I personally think the Scala community would be been better served
  if more investment was made in developing better Scala build tools
  within the Maven framework. More and better plugins for Scala,
  Akka, Play, etc.  Better use of

  http://books.sonatype.com/mcookbook/reference/sect-
 scala-script-inline.html
  http://books.sonatype.com/mcookbook/reference/ch03s03.html

  I don't know if there is a Scala template for writing Maven
  plugins (or mojos), but there should be.

  The more I use SBT, the less I like it. It is not what I consider
  a serious build tool for build engineers, it is a toy or
  playground for Scala hackers who thrive on the abstruse. Don't get
  me wrong, I love Scala, but creating a build tool around .scala
  files just invites the use of chicken tracks and obscure overly
  concise cleverness that leads to one WTF experience after another.
  /It is actually possible to write Scala code that you can reason
  about,/ but it just as easy to write Scala code that resembles
  APL, and reasoning about build engineering was clearly not a
  priority with the designers of SBT.

  The Scala-IDE was a really great approach because it leveraged off
  of an existing IDE infrastructure such as Eclipse, rather than
  trying to write an IDE from scratch the way SBT does. I wish the
  Scala/Typesafe community had taken the same approach with

 build-tools.

  - Eric
  -- You received this message because you are subscribed to the
 Google
  Groups scala-debate group.
  To unsubscribe from this group and stop receiving emails from it,
  send an email to scala-debate+unsubscr...@googlegroups.com
  

Re: Best practice for optional dependencies?

[Curtis Rueden]

Hi Mark,

 I'm working on a project which has an optional transitive
 dependency.  That is: we depend on someone else's artifact (let's call
 it A), which itself depends *in some circumstances* on a third
 artifact (from a third source) which I'll call B.  That is:  if you
 never trigger a certain feature of A then it doesn't really need B.  A
 expresses this by making B a dependency with scopeprovided/scope.

Wouldn't it make more sense for A to declare the dependency on B as
optionaltrue/optional rather than abusing the provided scope?

http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

 I think that A should use Class.forName to probe for B and (if not
 found) gracefully explain why it cannot perform the requested
 function.

I have historically had a lot of trouble with things done that way. The
problem is that Class.forName is very easy to mess up when custom
ClassLoaders are in use. Personally I think it is better to use a
compile-time dependency, and write the actual direct Java code, catching
ClassNotFoundException in the appropriate places to handle the situation
where the dependency is not present at runtime. Then you lean on the
compiler, and avoid subtle reflection-related bugs and problems. Since the
dependency is declared as optionaltrue/optional, you do not infect
downstream code with the dependency in every case -- instead, people can
choose for themselves whether to use it.

 We are thus faced with a choice: declare a transitive dependency as if
 it were a direct dependency, to support an unusable feature, and leave
 notes all over our POMs to explain why dependency:analyze is wrong and
 you should not remove this dependency; or keep explaining to people
 why they get NoClassDefFoundError when processing some of their files.

Could you work around their design issue by catching NoClassDefFoundError,
and handle the error in a more appropriate way for your users?

Regards,
Curtis

On Thu, Jan 22, 2015 at 10:48 AM, Mark H. Wood mw...@iupui.edu wrote:

 I'm working on a project which has an optional transitive
 dependency.  That is: we depend on someone else's artifact (let's call
 it A), which itself depends *in some circumstances* on a third
 artifact (from a third source) which I'll call B.  That is:  if you
 never trigger a certain feature of A then it doesn't really need B.  A
 expresses this by making B a dependency with scopeprovided/scope.

 I feel that this is an abuse of the dependency mechanism, and that
 optional dependencies should not be declared to Maven as dependencies
 at all.  I think that A should use Class.forName to probe for B and
 (if not found) gracefully explain why it cannot perform the requested
 function.  What do you think?

 The feature in question is decryption of a file, which is triggered
 when A recognizes an encrypted file, and that is out of our control.
 Decryption requires key material, and in our application there is no
 reasonable opportunity to provide it, so we can't actually make use of
 the decryption function.  We are thus faced with a choice: declare a
 transitive dependency as if it were a direct dependency, to support an
 unusable feature, and leave notes all over our POMs to explain why
 dependency:analyze is wrong and you should not remove this dependency;
 or keep explaining to people why they get NoClassDefFoundError when
 processing some of their files.

 --
 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: How to activate a profile when -offline?

[Curtis Rueden]

Hi Andreas,

 Now, one might argue that the m-jarsigner-p needs to become smarter
 and aware of Maven's offline mode, but that would require it to deal
 with special cases, like localhost URLs being reachable even in
 offline mode

I would argue that, yeah. And that it should ignore such special cases, and
just do nothing (or fail the build maybe) when in offline mode. Though
special casing file:// would be trivial to do. Maybe worth filing a JIRA
issue for it? Doesn't look like there are any issues relating to this in
the system yet [1].

 being able to activate a profile on ${settings.offline} doesn't
 preclude that as, AFAIK, that magic property can only be set before
 Maven starts doing things like resolving parent POMs, i.e., on the
 command line or in the settings.xml itself.

Sure, that makes sense to me too. After all, settings.xml is always there
on the local machine and intuitively, it seems like it would be easy to add
support for profile activation based on settings. But I am naive there!

Regards,
Curtis

[1]
https://jira.codehaus.org/issues/?jql=project%20%3D%20MJARSIGNER%20AND%20text%20~%20offline

On Thu, Feb 5, 2015 at 3:05 PM, Andreas Sewe 
s...@st.informatik.tu-darmstadt.de wrote:

 Hi Curtis,

 many thanks for your detailed reply.

 You wrote:
  Is this by design, i.e., is ${settings.offline} different from,
  say, a property ${my.offline} that I activate with -D?
 
  For better or for worse, Maven profiles cannot be activated based on
 Maven
  properties, only based on Java system properties and/or environment
  variables. That is, anything you pass in via -Dfoo.bar can be used for
  activation, but all those properties you put in the properties section
 of
  your POM, or in settings.xml, cannot trigger profiles. The Maven offline
  property is one of the latter, not the former.

 Yes, but settings.offline is arguably different from things in a
 properties section because it is, as you point out below, a top-level
 element in settings.xml (/settings/offline rather than
 /settings/properties/offline). As such, it at least seems plausible that
 settings.* properties act the same as env.* properties.

  does there exist a different way to achieve the same thing,
  i.e., activate a profile when -offline?
 
  After 30+ minutes of thinking about this and trying things and grepping
  Maven source code, I do not think what you want to do is obviously
 possible.
 
  Pragmatically, I thought maybe you could enable offline mode using a
  profile in your settings.xml activated on an environment variable, but
 you
  cannot toggle the offline setting in such a profile, because offline
 is a
  toplevel element (i.e., not declared beneath properties).

 Maybe I phrased my original question not clearly enough: I don't want to
 *enable* offline mode. I simply want to configure some plugin (the
 maven-jarsigner-plugin's tsa configuration option, to be precise) iff
 I am running Maven with -offline. The problem is that, with a Time
 Stamping Authority URL configured, the m-jarsigner-p tries to connect to
 the TSA, even if -offline, which cannot succeed and causes the build to
 fail.

 Now, one might argue that the m-jarsigner-p needs to become smarter and
 aware of Maven's offline mode, but that would require it to deal with
 special cases, like localhost URLs being reachable even in offline mode,
 etc. IMHO, it is thus far simpler to just be able to configure an
 offline profile that adapts your plugin configurations if -offline is
 used.

  The greater design issue is that Maven needs to know whether it is
 offline
  mode before it starts doing things like resolving parent POMs. But that
  resolution is necessary in order to fully interpolate the POM and hence
  know which profiles are activated.

 I get that. But being able to activate a profile on ${settings.offline}
 doesn't preclude that as, AFAIK, that magic property can only be set
 before Maven starts doing things like resolving parent POMs, i.e., on
 the command line or in the settings.xml itself.

 Do you agree? If so, do you think this might be worth an enhancement
 request? (I think the m-jarsigner-p use case is pretty compelling, but
 then again that's the problem I am facing at work right now, so I may be
 a bit biased. ;-)

 Best wishes,

 Andreas


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

Re: How to activate a profile when -offline?

[Curtis Rueden]

Hi Andreas,

 Is this by design, i.e., is ${settings.offline} different from,
 say, a property ${my.offline} that I activate with -D?

For better or for worse, Maven profiles cannot be activated based on Maven
properties, only based on Java system properties and/or environment
variables. That is, anything you pass in via -Dfoo.bar can be used for
activation, but all those properties you put in the properties section of
your POM, or in settings.xml, cannot trigger profiles. The Maven offline
property is one of the latter, not the former.

 does there exist a different way to achieve the same thing,
 i.e., activate a profile when -offline?

After 30+ minutes of thinking about this and trying things and grepping
Maven source code, I do not think what you want to do is obviously possible.

Pragmatically, I thought maybe you could enable offline mode using a
profile in your settings.xml activated on an environment variable, but you
cannot toggle the offline setting in such a profile, because offline is a
toplevel element (i.e., not declared beneath properties).

The greater design issue is that Maven needs to know whether it is offline
mode before it starts doing things like resolving parent POMs. But that
resolution is necessary in order to fully interpolate the POM and hence
know which profiles are activated.

Regards,
Curtis

On Thu, Feb 5, 2015 at 7:43 AM, Andreas Sewe 
s...@st.informatik.tu-darmstadt.de wrote:

 Hi,

 sometimes it's useful to configure a Maven plugin depending on whether
 the build runs in online or offline mode (-offline command-line option).
 Now, using

   mvn help:effective-settings -offline

 shows that ${settings.offline} == true. Alas, I cannot get the following
 profile to activate:

  profile
idoffline/id
activation
  property
namesettings.offline/name
valuetrue/value
  /property
/activation
  /profiles

 Is this by design, i.e., is ${settings.offline} different from, say, a
 property ${my.offline} that I activate with -D? Or is this a bug?

 Last but not least, does there exist a different way to achieve the same
 thing, i.e., activate a profile when -offline?

 Best wishes,

 Andreas

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

Re: Best practice for optional dependencies?

[Curtis Rueden]

Hi Ron,

 Why not just mock the classes and have the mock classes take the
 appropriate actions when they are called by mistake.

To clarify my earlier comments: I like your solution here, and agree that
it would work well in this circumstance. It gives more control than my
suggestion to catch NoClassDefFoundError, and would only cause problems if
there might be a downstream project that legitimately wants to include the
real B for any reason.

My comments were mostly orthogonal to yours, in that:
A) I think the A project should declare B as an optional dependency, not
provided; and
B) I do not think the A project should use reflection to access B, but
rather let the compiler do its job, and catch ClassNotFoundException to
handle B being missing.

But neither of those comments are really under the control of Mark's
project. I just mentioned them because he asked why A wasn't using
reflection to access B.

Regards,
Curtis

On Thu, Feb 5, 2015 at 1:11 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:


 Why not just mock the classes and have the mock classes take the
 appropriate actions when they are called by mistake.
 Seems easier to manage and you just provide the right jar at run-time as
 part of the install or deploy.
 The developers don't have to worry about dependencies and maven works
 nicely.
 You could have a testing mock version that jumps up and down when it is
 called by mistake so that the programmers know that they missed the test
 for the option.


 Ron



 On 04/02/2015 5:32 PM, Curtis Rueden wrote:

 Hi Mark,

  I'm working on a project which has an optional transitive
 dependency.  That is: we depend on someone else's artifact (let's call
 it A), which itself depends *in some circumstances* on a third
 artifact (from a third source) which I'll call B.  That is:  if you
 never trigger a certain feature of A then it doesn't really need B.  A
 expresses this by making B a dependency with scopeprovided/scope.

 Wouldn't it make more sense for A to declare the dependency on B as
 optionaltrue/optional rather than abusing the provided scope?

 http://maven.apache.org/guides/introduction/introduction-to-optional-and-
 excludes-dependencies.html

  I think that A should use Class.forName to probe for B and (if not
 found) gracefully explain why it cannot perform the requested
 function.

 I have historically had a lot of trouble with things done that way. The
 problem is that Class.forName is very easy to mess up when custom
 ClassLoaders are in use. Personally I think it is better to use a
 compile-time dependency, and write the actual direct Java code, catching
 ClassNotFoundException in the appropriate places to handle the situation
 where the dependency is not present at runtime. Then you lean on the
 compiler, and avoid subtle reflection-related bugs and problems. Since the
 dependency is declared as optionaltrue/optional, you do not infect
 downstream code with the dependency in every case -- instead, people can
 choose for themselves whether to use it.

  We are thus faced with a choice: declare a transitive dependency as if
 it were a direct dependency, to support an unusable feature, and leave
 notes all over our POMs to explain why dependency:analyze is wrong and
 you should not remove this dependency; or keep explaining to people
 why they get NoClassDefFoundError when processing some of their files.

 Could you work around their design issue by catching NoClassDefFoundError,
 and handle the error in a more appropriate way for your users?

 Regards,
 Curtis

 On Thu, Jan 22, 2015 at 10:48 AM, Mark H. Wood mw...@iupui.edu wrote:

  I'm working on a project which has an optional transitive
 dependency.  That is: we depend on someone else's artifact (let's call
 it A), which itself depends *in some circumstances* on a third
 artifact (from a third source) which I'll call B.  That is:  if you
 never trigger a certain feature of A then it doesn't really need B.  A
 expresses this by making B a dependency with scopeprovided/scope.

 I feel that this is an abuse of the dependency mechanism, and that
 optional dependencies should not be declared to Maven as dependencies
 at all.  I think that A should use Class.forName to probe for B and
 (if not found) gracefully explain why it cannot perform the requested
 function.  What do you think?

 The feature in question is decryption of a file, which is triggered
 when A recognizes an encrypted file, and that is out of our control.
 Decryption requires key material, and in our application there is no
 reasonable opportunity to provide it, so we can't actually make use of
 the decryption function.  We are thus faced with a choice: declare a
 transitive dependency as if it were a direct dependency, to support an
 unusable feature, and leave notes all over our POMs to explain why
 dependency:analyze is wrong and you should not remove this dependency;
 or keep explaining to people why they get NoClassDefFoundError when
 processing some

Re: maven 3.0.6 release date

[Curtis Rueden]

Hi David,

I feel compelled to throw out the obligatory It's open source; scratch
your itch response here. It sounds like your team could really use this
feature, you seem to think it would be easy to implement, you have an
existing template for how another related build tool already does this, and
it is not a feature already being worked on by the core Maven developers.
It might be worth the development effort for your team to contribute the
feature upstream.

-Curtis
On Feb 2, 2015 11:17 AM, David Hoffer dhoff...@gmail.com wrote:

 Here is a link to how Gradle does this

 http://gradle.org/docs/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html
 looks like it does a build tool download and builds against that version.
 Not sure if this allows simultaneous builds to use different versions but I
 assume it does.

 -Dave


 On Mon, Feb 2, 2015 at 9:58 AM, David Hoffer dhoff...@gmail.com wrote:

  It looks like http://mvnvm.org/ configures a system for a version of
  Maven which is nice but not really what I'm asking for.  What I'm asking
  for is no system config.  We want to run multiple Maven builds on the
 same
  box at the same time with different Maven versions.  E.g. pom specifies
  everything, system defines nothing.
 
  -Dave
 
  On Mon, Feb 2, 2015 at 9:50 AM, David Hoffer dhoff...@gmail.com wrote:
 
  For the first question, there is not one answer.  As an example one
  current project is on 3.0.4.  I did upgrade that one to 3.2.5 and I
 found I
  had to update several plugins (unfortunately I don't recall which ones
  those were).  In trunk I made those changes so we could use 3.2.5 but I
  can't make those same plugin changes for branch builds (no one wants to
  assume the risk of those changes there).  So because this would force
 devs
  to have 2 different Maven system configs...we decided to stay at 3.0.4
 for
  both builds.
 
  Yes we have a top level pom that defines plugin versions but that is
  included in the branch...it's the branch one we don't want to
  change...trunk one is generally okay to update.  (We also have a global
  company pom...that contains company global things like license,
  distributionManagement, etc.)
 
  I'm not clear why you think this feature couldn't work in Maven or
  Gradle...seems pretty simple to me.  Something like a small bootstraper
 is
  the kernel of the build tool and Maven or Gradle itself is downloaded
 as a
  'bundle'...or a 'plugin' if I can reuse that term.  With this approach
 the
  build is guaranteed to be using exactly the same build bits every
 time...no
  risk of any changes...and the pom defines everything.  That being
 said...I
  have not looked at how Gradle accomplishes this.
 
  -Dave
 
 
 
 
 
  On Mon, Feb 2, 2015 at 9:10 AM, Karl Heinz Marbaise khmarba...@gmx.de
  wrote:
 
  Hi David,
 
  unfortunately you really didn't answer my question...
 
  From which versions of Maven would you like to update...? And what are
  the problems you/devs have been faces with?
 
 
  You can test it via CI ...
 
  BTW: Jenkins was just an example for any kind of CI solution is doesn't
  matter if you use Jenkins, TeamCity, Bamboo, or what ever... etc. the
  process is always the same...
 
 
  On 2/2/15 4:30 PM, David Hoffer wrote:
 
  Hi Karl,
 
  Our posts crossed.  We use several different Maven versions
 
 
  Which ones?
 
   but upgrading
 
  has always been problematic because it's hard if not impossible to
  upgrade
  all projects to the latest.
 
 
  Why not? What where/are the exact issues?
 
   It's easy to upgrade the trunk (usually) but
 
  we have older branches where we do not want to upgrade because we want
  minimal changes in that branch build (e.g. no plugin changes).
 
 
  What kind of plugin changes ? Haven't you defined a company pom which
  contains all the plugin definitions and is continiously maintained to
  update them.
 
 
  We can't use Jenkins...but that's not an issue...as for CI we have no
  problem running the version we want.  The issue is for developers...I
  don't
  want devs to have to constantly switch their environment around just
 to
  run
  different maven versions.  We often have to run both at the same time
  as we
  are fixing something in a branch and the same in trunk after the
 merge.
 
  This is a standard feature of Gradle and lots of folks here are
 pushing
  for
  that.  If Maven had this feature it would remove their argument.
 
 
  That sounds like two things
 
  First downloading Maven version (however this can be identified) and
  switching to the downloaded instances...
 
 
  Apart from that. Downloading automatically some version does not solve
  the real problem here. The builds have not been well maintained and
  upgraded/improved as the usualy source code as well...
 
  I have my doubts that this will work all the time with Gradle as
  well...cause in the meantime you have several differernt gradle
 versions as
  wellI think you will faces the same thing with Gradle cause using 

Re: Avoiding situations where duplicate classnames are imported?

[Curtis Rueden]

Hi Kevin,

 The main situation I see is when the artifact and group ID differ …

The Maven Enforcer Plugin is the first party plugin solution. The rule
you want, banDuplicateClasses, is part of the Mojo project's Extra Enforcer
Rules:

http://mojo.codehaus.org/extra-enforcer-rules/banDuplicateClasses.html

Regards,
Curtis

On Mon, Jan 19, 2015 at 8:37 PM, Steven Schlansker 
stevenschlans...@gmail.com wrote:

 This is exactly the situation that the plugin I referenced resolves :)
 https://github.com/basepom/duplicate-finder-maven-plugin

 On Jan 19, 2015, at 8:47 AM, Adrien Rivard adrien.riv...@gmail.com
 wrote:

  Then you need to explicitely exclude one of them. Eclipse can help for
 that
  via the pom editor in the dependency Hierarchy tab.
 
  On Mon, Jan 19, 2015 at 9:24 AM, Kevin Burton bur...@spinn3r.com
 wrote:
 
  The main situation I see is when the artifact and group ID differ …
 
  so  an older version of jdom used just jdom and the newer version used
  org.jdom and then I ended up with both :)
 
  On Sun, Jan 18, 2015 at 10:31 PM, Adrien Rivard 
 adrien.riv...@gmail.com
  wrote:
 
  Hi,
 
  if youre artifacts have the same artifactId/groupId/type/classifier  it
  should'nt happen,Maven should pick only one of the two. If one of
  the artifactId/groupId/type/classifier is not the same, it could happen
  because it's not the same jar for maven.
 
 
  On Mon, Jan 19, 2015 at 4:32 AM, Steven Schlansker 
  stevenschlans...@gmail.com wrote:
 
  Check out
  https://github.com/basepom/duplicate-finder-maven-plugin
 
  On Jan 18, 2015, at 6:12 PM, Kevin Burton bur...@spinn3r.com wrote:
 
  It looks like I’ve accidentally ended up in a situation where I have
  duplicate class names in separate .jars with different versions.
 
  So I’ll have Foo.class in foo-1.0.0.jar and foo-3.0.0.jar …
 
  Shouldn’t Maven fail in this scenario?  IE assert that you have
  conflicting
  dependencies and that you should resolve them by hand.
 
  This usually happens with two projects (usually an older one) depends
  on
  an
  older version of a library.
 
  I may be foolishly using a few older libs which, while stable, don’t
  really
  work with some of their more modern dependencies.
 
 
 
  --
 
  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
  http://spinn3r.com
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
  --
  Adrien Rivard
 
 
 
 
  --
 
  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
  http://spinn3r.com
 
 
 
 
  --
  Adrien Rivard


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

Re: copy resources to other places after build

[Curtis Rueden]

Hi James,

 i would like maven can move the packaged jar to some place specified
after build

The dependency:copy goal might work for your use case. But as Dan says, be
careful with this route: there can be subtle consequences.

http://stackoverflow.com/q/7063475/1207769

Regards,
Curtis

On Thu, Feb 12, 2015 at 11:46 AM, Dan Tran dant...@gmail.com wrote:

 You can hook up maven-antrun-plugin to do the copy, use vfs-maven-plugin,
 or wagon-maven-plugin to do remote copy. But think twice before going for
 this route.

 -D

 On Thu, Feb 12, 2015 at 5:03 AM, James Teng tenglinx...@outlook.com
 wrote:

  Due to some causes, i would like maven can move the packaged jar to some
  place specified after build, does it have a plugin for that except
 directly
  letting the jar dumped to the target place using maven jar plugin?
  thanks!
  uknow.

Re: access to license node

[Curtis Rueden]

Hi Andreas and Philipp,

 Have a look at http://jira.codehaus.org/browse/PLXUTILS-37. While it
 is marked as fixed, apparently things like
 ${project.licenses.0.license.name} did not (and still do not; I just
 checked) work. :-(

The following works for me:

${project.licenses[0].name}

Alternately, as a workaround (at least for some use cases), you could do:

  properties
licenseNameGNU General Public License 3/licenseName
  /properties
  ...
  licenses
license
  name${licenseName}/name
  urlhttp://www.gnu.org/licenses/gpl-3.0.en.html/url
/license
  /licenses

And then reuse the ${licenseName} elsewhere as needed, too.

Regards,
Curtis

On Thu, Feb 19, 2015 at 9:14 AM, Andreas Sewe 
s...@st.informatik.tu-darmstadt.de wrote:

 Hello,

  I’m using Maven 3.2 with the pom definition
 
  project xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=
 http://maven.apache.org/POM/4.0.0;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
  modelVersion4.0.0/modelVersion
 
 
  I have added this items to my pom
 
  licenses
  license
  nameGNU General Public License 3/name
  urlhttp://www.gnu.org/licenses/gpl-3.0.en.html/url
  /license
  /licenses
 
  and I would like to reference to the items with
 
  ${project.licenses.license.url}
  ${project.licenses.license.name}
 
  but these lines does not work - empty result, so I would like to reread
 the items of my license node, how can I do this?

 Have a look at http://jira.codehaus.org/browse/PLXUTILS-37. While it
 is marked as fixed, apparently things like
 ${project.licenses.0.license.name} did not (and still do not; I just
 checked) work. :-(

 Best wishes,

 Andreas


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

Re: access to license node

[Curtis Rueden]

Hi Baptiste,

 Sorry cannot check just now, but off the top of my head, shouldn't it
 be more something along: ${project.licenses[0].license.name}

I checked. It is:

   ${project.licenses[0].name}

Regards,
Curtis

On Thu, Feb 19, 2015 at 11:00 AM, Baptiste Mathus bapti...@codehaus.org
wrote:

 Le 19 févr. 2015 16:16, Andreas Sewe s...@st.informatik.tu-darmstadt.de
 
 a écrit :
 
  Hello,
 
   I’m using Maven 3.2 with the pom definition
  
   project xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=
 http://maven.apache.org/POM/4.0.0;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/maven-4.0.0.xsd;
   modelVersion4.0.0/modelVersion
  
  
   I have added this items to my pom
  
   licenses
   license
   nameGNU General Public License 3/name
   urlhttp://www.gnu.org/licenses/gpl-3.0.en.html/url
   /license
   /licenses
  
   and I would like to reference to the items with
  
   ${project.licenses.license.url}
   ${project.licenses.license.name}
  
   but these lines does not work - empty result, so I would like to reread
 the items of my license node, how can I do this?
 
  Have a look at http://jira.codehaus.org/browse/PLXUTILS-37. While it
  is marked as fixed, apparently things like
  ${project.licenses.0.license.name} did not (and still do not; I just

 Sorry cannot check just now, but off the top of my head, shouldn't it be
 more something along:
 ${project.licenses[0].license.name}

 ?

  checked) work. :-(
 
  Best wishes,
 
  Andreas
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 

Re: Question about Java version range using in Maven Enforcer Plugin

[Curtis Rueden]

Hi Sandra,

 I discussed with my team how they interprets the range value
 [1.6,1.8]. They would interpret this as every Java 8 version is
 possible. Is this a misinterpretation of us?

For the most part, the RequireMavenVersion and RequireJavaVersion rules
use the standard Maven version range syntax [1].

So try writing:
[1.6, 1.9)

Where the closing paren means up to, but not including, 1.9.

Regards,
Curtis

[1] http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

On Tue, Jan 27, 2015 at 3:18 PM, Sandra Kosmalla skosma...@web.de wrote:

 Hi,

 I want to set the RequiredJavaVersion rule in Maven Enforcer Plugin with
 the requirement that using Java in versions 1.6, 1.7 and 1.8 is possible
 (independent of update version). So I set the value [1.6,1.8] in the
 property version in the RequiredJavaVersion rule. If I configure Java
 8 in my JAVA_HOME, the build failed because of the rule
 RequiredJavaVersion.

 The goal enforcer:display-info prints following information

 [INFO] --- maven-enforcer-plugin:1.3.1:display-info (default-cli) @  ---
 [INFO] Maven Version: 3.2.5
 [INFO] JDK Version: 1.8.0_31 normalized as: 1.8.0-31
 [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
 3.13.0-37-generic

 I have to set the range value to [1.6,1.8.0.*] so that the build runs
 successfully.

 I discussed with my team how they interprets the range value [1.6,1.8].
 They would interpret this as every Java 8 version is possible. Is this a
 misinterpretation of us? What do you say about it?

 Thanks and best regards,

 Sandra Kosmalla

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

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

[Curtis Rueden]

Hi Kevin,

I agree with Steven. One way of resolving this sort of problem without OSGi
is to use a consistent, meaningful versioning system such as Semantic
Versioning (http://semver.org/).  Once you have the ability to reason about
forwards and backwards compatibility, it is easier to resolve version
conflicts in a more reliable (ideally automated) way.

Of course, all the tools you are using do not necessarily abide by such
versioning standards. So then conflict resolution becomes more complicated.
Steven's suggestion of managing them upwards to the latest needed is
often good enough...

Regards,
Curtis

On Mon, Jan 5, 2015 at 3:20 PM, Steven Schlansker 
stevenschlans...@gmail.com wrote:


 On Jan 5, 2015, at 1:03 PM, Kevin Burton bur...@spinn3r.com wrote:

  I spent a ton of time tonight in classpath hell.
 
  Basically, Apache Spark, Cassandra, and Cassandra Unit, and Guava,
 Jackson
  JSON, and Jetty have an INSANE dependency graph.  They're all trampling
 on
  each other with broken
  dependencies.  This results in a lot of exclusion work to get them to
 use
  sane bindings.
 
  Has anyone done any work with only allowing a library to use the version
 of
  a class it requested?
 
  So what would happen is every dependency would only be sourced from the
  version you require.
 
  This could be done via a hierarchical class loader. Of course this would
  probably end up burning up some memory but probably worth it.
 
  The main issue, is it WORTH it.. would this introduce new bugs?

 You are basically talking about OSGi or some other such module system.
 https://en.wikipedia.org/wiki/OSGi

 In my opinion, it is actually easier to resolve the dependency conflicts
 among
 the modules (usually by managing them upwards to the latest needed by any
 dependency)
 and tracking this via a plugin [1]

 Having such complicated class loader situations just leads to even more
 subtle and confusing bugs IMO.

 [1] https://github.com/ning/maven-dependency-versions-check-plugin



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

Re: Cleaning source code repositories

[Curtis Rueden]

Hi Viktor,

 Do you actually consider this situation as a problem or is it just a
 perfectionist talking to me? ;-)

I would say it is a very real challenge of managing projects with many
components.

 how would you approach determining those, which are required for final
 deliveries, and those, which might break if another module changes
 (sort of reverse dependency management)?

That reverse dependency management need in particular is the most
important of those on your list, I think. (Detecting obsolete modules and
build jobs is nice and helps declutter, but often has little consequence
beyond that.)

My project [1] is still looking for better ways to be notified in advance
when code changes somehow affect downstream projects. (Of course, you
cannot be responsible for the entire world -- but you can define a known
set of downstream code that you want to help maintain.)

We use release couplings for reproducible builds [2], SemVer for versioning
[3], and Jenkins for CI [4]. Because of the release dependency couplings,
Jenkins cannot tell you when upstream changes to master (or even new
release versions) break downstream projects, until such projects attempt to
update to the new release. What we are working towards creating is a
melting pot Jenkins job that switches everything to snapshot couplings
using a profile [5] in a giant synthetic multi-module build. Then the java
compiler would tell you directly if you broke backwards compatibility -- at
least compile-time compatibility, which is more than half the battle.

If anyone knows of a better established best practice for this sort of
thing, that would be awesome.

Regards,
Curtis

[1] http://imagej.net/Architecture
[2] http://imagej.net/Reproducible_builds
[3] http://imagej.net/Versioning
[4] http://imagej.net/Jenkins
[5]
https://github.com/scijava/pom-scijava/blob/pom-scijava-5.7.0/pom.xml#L1048-L1051

On Fri, Feb 13, 2015 at 7:09 AM, Viktor Sadovnikov vik...@jv-ration.com
wrote:

 Good day,

 I wonder if this community can provide some hints on handling the
 following.

 At a few last projects I was asked to set (or clean) automated builds up,
 so they can get (at least) deployable software package(s) after code
 changes in a minimum time. Starting from the final desirable results, I was
 able to trace down every module, which is needed to build the master CD.
 It was especially easy for Maven-based projects. However discovering these
 modules in source repositories were always highlighting:

- lack of knowledge if a certain module in repository is needed or even
used in multiple products;
- duplications of modules with similar purposes - sometimes a conscious
decision to copy in order to avoid breaking backward compatibility with
unknown dependents;
- existence of build jobs for obsolete modules;
- absence of builds for stable modules, which are not changed during the
last couple of years
- and things like these

 Assuming all projects in the repositories are maven-ized, how would you
 approach determining those, which are required for final deliveries, and
 those, which might break if another module changes (sort of reverse
 dependency management)?

 Do you actually consider this situation as a problem or is it just a
 perfectionist talking to me? ;-)

 Thank you for your attention,
 Viktor

Analyzing dependencies of a project with a non-Maven build

[Curtis Rueden]

Hi everyone,

I am trying to interface with a largish project that publishes artifacts to
a Maven repository, but does not do its builds using Maven. (It uses
Ant+Ivy.)

The problem is that the published POM dependencies have problems in both
directions: undeclared-but-used dependencies, and declared-but-unused
dependencies.

Ideally, I would like to use the maven-dependency-plugin's excellent
dependency:analyze goal, but on these already-deployed artifacts.

Is there some flag I can pass to a dependency:whatever goal to accomplish
this? Or another recommended approach or tool for doing this?

Thanks,
Curtis

Re: Why would maven download a pom and not a jar?

[Curtis Rueden]

Hi Dan,

 What I really need is a way to determine only the deps (and sub deps)
 for the application itself.

Maven makes this really easy. As others have said, the dependency plugin
has several helpful goals.

If all you need is to _list_ the dependencies, then you already found
dependency:tree. There is also dependency:list which gives you a flat list.
And then there is Eclipse (via the M2E plugin), which has a beautiful and
searchable Dependencies view if you double-click the pom.xml file.

If what you need is all the JAR files in a single place, then try:

mvn dependency:copy-dependencies

This actually copies all JAR files of your project's dependencies into the
target/dependencies folder. You can then ZIP them up or do whatever with
them.

If you want to automate that process, then the maven-assembly-plugin is
your best friend. You can tell it to make an archive containing your
application JAR, dependency JARs, and other resources. It is highly
configurable. The documentation is a bit arcane, but it is really worth
learning. If you get stuck, just ask for help here!

If what you want is to use Maven to _launch_ your application, then the
exec-maven-plugin is what you need. It has an exec:java goal that launches
the given Java main class, with all the dependencies on your classpath.

And in all cases, you should never need to do anything crazy with
~/.m2/repository. Please understand that that is a _cache_ used by the mvn
tools, and not intended for use facilitating your build or deployment
processes. I would strongly suggest working with Maven for a bit longer
before you decide to try doing anything clever with the repo cache.

Regards,
Curtis

On Wed, Mar 11, 2015 at 10:22 AM, Dan dc12...@gmail.com wrote:

 Thanks again for the help.  I understand that what I'm doing is not
 standard, but I still have to implement.
 So I know if i run dependency:tree on a simple pom with no deps, I still
 get well over 200 artifacts downloaded. So I am also under the assumption
 that the majority are requirements of maven or the dep plugin rather then
 my app.

 What I really need is a way to determine only the deps (and sub deps) for
 the application itself.

 I have two approaches I'm thinking of taking.
 1. (Doesn't meet the all the requirements, but gets me out of a jam
 temporarily).   Instead of creating rpms for every artifact, only package
 up the ones which actually have a jar file in the directory.

 2. Parse the output of dependency:tree, and package up only what is listed
 in that visual ascii tree. (ie: grep '^\[INFO\]').  I'm just don't know if
 I can be 100% sure that the tree does in fact list everything that I need.



 Here are the somewhat sanitized pom files, and the output i'm getting.

 # App 1
 http://pastebin.com/raw.php?i=Dg3Fbaue
 http://pastebin.com/raw.php?i=NEhrtwF4


 # App 2
 http://pastebin.com/raw.php?i=180zUFLe
 http://pastebin.com/raw.php?i=VEueXysC












 On 03/11/2015 02:19 AM, Baptiste Mathus wrote:

 Oh right, I didn't get your meaning. You're right, could be that, indeed.
 Should check the plugin sources to be sure.

 2015-03-11 7:06 GMT+01:00 Cintia Del Rio miladyarte...@gmail.com:

  When you invoke the dependency:tree, maven will download the dependency
 tree plugin and all the dependencies it needs to run that plugin.


 So I'd expect that every jar you now have in your local repository
 (~/.m2)
 is a dependency of the dependency:tree plugin.

 On 11 March 2015 at 17:02, Baptiste Mathus m...@batmat.net wrote:

  Could you rephrase? You think pom.xml is a dependency of the
 dependency:tree goal? If so, then the answer is no.

 Cheers

 2015-03-11 6:59 GMT+01:00 Cintia Del Rio miladyarte...@gmail.com:

  Isn't it a dependency of the dependency plugin itself?

 On 11 March 2015 at 16:51, Baptiste Mathus bmat...@batmat.net wrote:

  Well, in that case, since you're asking for the dependency:tree I'm

 even

 surprised there's any jar downloaded. Maven would only need pom to

 compute

 that. Downloading Jars is only done when needed (say for compiling,

 etc.)

 Btw, do you really type mvn dependency:tree pom.xml ? What do you

 expect?

 The pom.xml part is gonna lead to an error since pom.xml is not a

 goal

 and that's what's supposed to be listed after mvn.

 As for your question: I suppose oro is a transitive dependency of one

 of

 the things you depend on. mvn dependency:tree should generally show

 it

 btw.

 Cheers

 2015-03-10 15:22 GMT+01:00 D C dc12...@gmail.com:

  I am trying to download all dependencies from a pom file.  My steps

 are:

 1. delete .m2/repository
 2. mvn dependency:tree pom.xml

 Everything looks good, however as I browse the .m2 directory I can

 see

 that

 for some artifacts  maven only downloaded the pom file, and did not
 download the associated jar.  I then repeat the process on another

 pom

 file.  This time the jar file is present for that same artifact.

 There are multiple artifacts that this happens on, but for

 

Re: artifactasc/artifactId missing ?

[Curtis Rueden]

Hi Martin,

org.sonatype.flexmojos:flexmojos-flex-compiler:3.8-SNAPSHOT is ancient.
There are several new major versions, including a groupId change to
net.flexmojos.oss:

https://repository.sonatype.org/#nexus-search;quick~flexmojos-flex-compiler

The latest on Maven Central is:
net.flexmojos.oss:flexmojos-flex-compiler:7.0.1

http://search.maven.org/#artifactdetails%7Cnet.flexmojos.oss%7Cflexmojos-flex-compiler%7C7.0.1%7Cjar

Regards,
Curtis

On Thu, Mar 12, 2015 at 6:57 PM, Martin Gainty mgai...@hotmail.com wrote:




  Subject: Re: artifactasc/artifactId missing ?
  From: manf...@mosabuam.com
  To: users@maven.apache.org
  Date: Thu, 12 Mar 2015 23:38:41 +0100
 
  I can not find it on https://oss.sonatype.org/ or
 https://repository.sonatype.org/ even when logged in.
 
  Manfred

 MGno tooling trickery unfortunately/MG

 MGThis is Marvin Froeder's flexmojos-flex-compiler which compiles
 mxml/MG
 MGcurrently packaged as org.sonatype.flexmojos/MG
 MGthe GAV/MG
 groupIdorg.sonatype.flexmojos/groupId
 artifactIdflexmojos-flex-compiler/artifactId
 version3.8-SNAPSHOT/version

 MG org.sonatype.flexmojos:asc:3.0 is requested in original
 dependency/MG

 
  Martin Gainty wrote on 12.03.2015 15:07:
 
   flex-compiler-mojo identitifies dependency
   dependency
  groupIdorg.sonatype.flexmojos/groupId
  artifactIdasc/artifactId
  version3.0/version
  /dependency
  
   which I cannot locate
   any suggestions where to find this artifact would be GREATLY
 appreciated
  
   thanks/bedankt
   Martin
   __
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 

Re: artifactasc/artifactId missing ?

[Curtis Rueden]

Hi Martin,

 flex-compiler-mojo identitifies dependency
 asc
 which I cannot locate

Which flex-compiler-mojo?

This one?
https://repository.sonatype.org/service/local/repositories/atlassian/content/info/flex-mojos/flex-compiler-mojo/2.0.3/flex-compiler-mojo-2.0.3.pom

No asc in there as far as I can see.

And the name asc is suspicious because that is one of the file extensions
for files in Maven repositories. Perhaps some string mangling happened
somewhere in your tooling?

Regards,
Curtis

On Thu, Mar 12, 2015 at 5:07 PM, Martin Gainty mgai...@hotmail.com wrote:

 flex-compiler-mojo identitifies dependency
  dependency
 groupIdorg.sonatype.flexmojos/groupId
 artifactIdasc/artifactId
 version3.0/version
 /dependency

 which I cannot locate
 any suggestions where to find this artifact would be GREATLY appreciated

 thanks/bedankt
 Martin
 __

Re: write developers contributors into Jar

[Curtis Rueden]

Hi Phillipp,

 If you want to just have the information in the jar somewhere,
 the pom file will already be in the jar by default.

I second Manfred's suggestion, if using the POM works for your use case.

I'm sure other projects have invented their own version of this, but just
in case it's useful, here's some code to ease working with POMs:

https://github.com/scijava/scijava-common/blob/scijava-common-2.38.2/src/main/java/org/scijava/util/POM.java#L163-L170

You can easily obtain the POM associated with a given Class, and extract
whatever information you desire via XPath queries.

Regards,
Curtis

On Sun, Mar 1, 2015 at 10:25 PM, Manfred Moser manf...@mosabuam.com wrote:

 If you want to just have the information in the jar somewhere, the pom
 file will already be in the jar by default. This is due to the archiver
 config addMavenDescriptor set to true.

 See http://maven.apache.org/shared/maven-archiver/index.html for the
 location of the pom file and further archiver config details.

 manfred

 Philipp Kraus wrote on 01.03.2015 03:41:

 
  Hello,
 
  I use Maven 3.0 with the developers and contributors inside the pom.xml.
 I use
  also the manifestEntries with the maven-assembly-plugin to add some
 flags to
  the Jar manifest file.
  I would like to add the developer and contributors list to the Jar, but I
  don’t know in which way I can add a list with name, email, and role
 types. My
  idea is that I create a comma separated list
  list with the data, but how can I create within the pom.xml the correct
 output
  list? E.g. the pom.xml stores:
 
  developers
developer
idmyID/id
namemyName/id
emailmyName@myDomain/email
roles
 rolearchitect/role
 roledeveloper/role
   /role
/developer
  /developers
 
  so in the manifest should be a line e.g.
 
  Developers = myName - myName@myDomain - architect / developer,
 
  I have tried to define it with
 
  manifestEntries
  Developers${project.developers}/Developers
  /manifestEntries
 
  but this writes only the Java object items to the entry. How can I
 create a
  loop / xquery within the pom.xml to iterate over the developer items?
 
  Thanks
 
  Phil
 
 
 

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

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Curtis Rueden]

Hi Jason,

Absolutely, my apologies. I didn't mean to imply anything about Takari
specifically. Your efforts, as always, are fantastic and a real credit to
the OSS community. I was speaking more philosophically about the scope of
the list in general.

And actually, I think Manfred and I are not really disagreeing: my point
was more pragmatic that sometimes more targeted forums will provide better
assistance for individual issues. But I agree that a varied and robust
discussion on this list is good for the community. I personally  have
already learned about several great technologies because of it.

Best regards,
Curtis
On Feb 27, 2015 6:13 PM, Jason van Zyl ja...@takari.io wrote:


 On Feb 27, 2015, at 3:15 PM, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Manfred,
 
  I think the same should apply for all other plugins.
 
  By that logic, an Ubuntu Linux mailing list should answer all questions
  about all packages available for Ubuntu, even multiverse packages. Seems
  impossible to me.
 
  That said, of course the people here are friendly and make a best effort
 to
  help. But you can't really help much with some random third party closed
  source Maven plugin.

 In this particular case it's not some random closed source plugin, not
 sure how that was conveyed. The plugin referred to is open source and
 written by the two most active core Maven developers. Myself and Igor.

  I agree with Olivier that asking the authors in cases
  like that would be much more likely to yield a solution.
 
  Regards,
  Curtis
 
  On Fri, Feb 27, 2015 at 1:18 PM, Manfred Moser manf...@mosabuam.com
 wrote:
 
 
 
  Olivier Lamy wrote on 26.02.2015 15:26:
 
  As it looks the question is related to an other project which is not
  hosted
  within the Apache Maven project neither developed by Apache Maven
  committers.
  I believe this mailing list is related to the Apache Maven project.
  So my goal was only to help Cristiano and tell him to ask in the place
  where this project is hosted and to the people who maintained it.
  It's probably better to have more accurate answers.
 
  Hm.. I tend to disagree. Imho this mailing list is about using Apache
  Maven. Not matter what plugins your are using, where they are hosted, or
  whatever. If there is a more specific mailing list then we can redirect,
  but generally this should be the big bucket of it all.
 
  E.g. the Android Maven Plugin and related projects has its own mailing
  list, but I still send release announcements here and answer questions
 here
  as well and I think the same should apply for all other plugins.
 
  Manfred
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -

 The modern conservative is engaged in one of man's oldest exercises in
 moral philosophy; that is,
 the search for a superior moral justification for selfishness.

  -- John Kenneth Galbraith













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

Re: takari-plugin-integration-testing requires one takari-jar project ?

[Curtis Rueden]

Hi Manfred,

 I think the same should apply for all other plugins.

By that logic, an Ubuntu Linux mailing list should answer all questions
about all packages available for Ubuntu, even multiverse packages. Seems
impossible to me.

That said, of course the people here are friendly and make a best effort to
help. But you can't really help much with some random third party closed
source Maven plugin. I agree with Olivier that asking the authors in cases
like that would be much more likely to yield a solution.

Regards,
Curtis

On Fri, Feb 27, 2015 at 1:18 PM, Manfred Moser manf...@mosabuam.com wrote:



 Olivier Lamy wrote on 26.02.2015 15:26:

  As it looks the question is related to an other project which is not
 hosted
  within the Apache Maven project neither developed by Apache Maven
  committers.
  I believe this mailing list is related to the Apache Maven project.
  So my goal was only to help Cristiano and tell him to ask in the place
  where this project is hosted and to the people who maintained it.
  It's probably better to have more accurate answers.

 Hm.. I tend to disagree. Imho this mailing list is about using Apache
 Maven. Not matter what plugins your are using, where they are hosted, or
 whatever. If there is a more specific mailing list then we can redirect,
 but generally this should be the big bucket of it all.

 E.g. the Android Maven Plugin and related projects has its own mailing
 list, but I still send release announcements here and answer questions here
 as well and I think the same should apply for all other plugins.

 Manfred

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

Re: Plugin dependency resolution from plugin pom?

[Curtis Rueden]

Hi Gary,

 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because
 it's not important)

Since the workaround is temporary, could you not simply clone the plugin's
SCM repository to a local Git repository, then create a branch with your
changes? Then rebuild the plugin whenever you like and use it. No need for
all the hoop-jumping it sounds like you're doing now...

Regards,
Curtis

On Mon, Mar 23, 2015 at 5:41 PM, Gary Kennedy g...@apnic.net wrote:

 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because it's
 not important)

 So I currently have a 'patch project' that depends on the plugin, uses the
 maven-dependency-plugin to unpack the dependant plugin (without the
 replacement files), contains the replacement files, does some replacer
 magic on the extracted plugin.xml to fixup the version/etc, and then
 package it all.

 This all works fine, in that the new project jar is a good content copy of
 the old plugin with all the changes needed.

 However, when using the new plugin, several dependency errors occur.
 (i.e., the dependencies of the old plugin are not pulled in).

 This confused me for a while because the maven plugin.xml file correctly
 lists all the dependencies. After a bit more playing around I worked out
 that this is because the plugin dependency resolution comes from the
 plugins pom.xml and NOT the plugin.xml file.

 So my main question for the group is: How/Can I, at build time, add the
 dependency (and properties, if possible) section from the old plugin pom
 into my new plugin's artefact pom? (So not the project pom itself, but the
 one written to the maven repository)

 And because I'm curious, does anyone know,
a) why the plugin.xml contains the dependencies if they are not used?
 or b) why the pom.xml is used instead of the plugin.xml to resolve
 dependencies? (I suspect aether + coding simplicity for this one)

 Cheers,
 Gary


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

Re: dependency plug-in docs wrong or misleading.

[Curtis Rueden]

Hi Ron,

 This should be added as a configuration and explanation to the main
 examples page

IIUC, we can submit patches for this sort of change. The repo on GitHub is:

https://github.com/apache/maven-plugins/blob/trunk/maven-dependency-plugin/src/site/apt/examples/copying-artifacts.apt.vm

As of this writing, the lines in question are:

https://github.com/apache/maven-plugins/blob/a2943b37832f8787147b1bfd292e1a13be2ec672/maven-dependency-plugin/src/site/apt/examples/copying-artifacts.apt.vm#L43-L67

And looking at the repo, it seems that PRs are being accepted. So I filed
one:
https://github.com/apache/maven-plugins/pull/52

Cheers,
Curtis

On Thu, May 7, 2015 at 10:56 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 In
 http://maven.40175.n5.nabble.com/copy-libraries-to-classpath-td110698.html,
 Brian Fox wrote a key response with a reference to an obscure reference in
 the dependency FAQ athttps://
 maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html

 Buried in the FAQ under copying from the command line it states you must
 not put the configuration inside the/executions/tag.

 This should be added as a configuration and explanation to the main
 examples page  at
 https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html

 project
   [...]
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.10/version
 executions
   execution
 idcopy-dependencies/id
 phasepackage/phase
 goals
   goalcopy-dependencies/goal
 /goals
 configuration

 outputDirectory${project.build.directory}/alternateLocation/outputDirectory
   overWriteReleasesfalse/overWriteReleases
   overWriteSnapshotsfalse/overWriteSnapshots
   overWriteIfNewertrue/overWriteIfNewer
 /configuration
   /execution
 /executions
   /plugin
 /plugins
   /build
   [...]
 /project

 If you are running from the command line of from an IDE, you need to
 change the position of the configuration section to be a sibling of the
 executions element

 project
   [...]
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.10/version
 configuration

 outputDirectory${project.build.directory}/alternateLocation/outputDirectory
 overWriteReleasesfalse/overWriteReleases
 overWriteSnapshotsfalse/overWriteSnapshots
 overWriteIfNewertrue/overWriteIfNewer
 /configuration
 executions
   execution
 idcopy-dependencies/id
 phasepackage/phase
 goals
   goalcopy-dependencies/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
   [...]
 /project



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: (Very basic) Command line completion for Fish-Shell

[Curtis Rueden]

Hi Johannes,

 https://github.com/jschneider/fish-maven-completion/blob/master/mvn.fish

FWIW, zsh is also a great modern shell, with many plugins available,
including pretty nice completion for Maven [1] from the Oh My Zsh! project.

Using a plugin manager like zgen [2] with zsh, you can easily cherry-pick
desired plugins from all over the web [3].

Regards,
Curtis

[1]
https://github.com/robbyrussell/oh-my-zsh/blob/140034605edd0f72c548685d39e49687a44c1b23/plugins/mvn/mvn.plugin.zsh
[2] https://github.com/tarjoilija/zgen
[3] E.g., my config:
https://github.com/ctrueden/dotfiles/blob/e8bc3d2f4b7913a55844265b31d7c5bedb129598/zshrc

On Thu, May 14, 2015 at 9:04 AM, Johannes Schneider maili...@cedarsoft.com
wrote:

 A lot is missing, but much better than nothing:

 https://github.com/jschneider/fish-maven-completion/blob/master/mvn.fish

 Install by copying to ~/.config/fish/completions/mvn.fish


 Pull requests very welcome.


 Regards,

 Johannes

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

Re: [ANN] Apache Maven Verifier Plugin Version 1.1 Released

[Curtis Rueden]

Hi Karl,

 The Apache Maven team is pleased to announce the release of the Apache
 Maven Verifier Plugin, version 1.1

Congratulations on the release. Out of curiosity, I was wondering...

What is the purpose of the maven-verifier-plugin, compared to the
maven-enforcer-plugin? From the Verifier plugin's web site, it sounds very
much like a specific enforcer rule: fail the build if these particular
resource files are not found. Or am I missing some critical distinction
there?

Furthermore, after doing a web search for maven verifier enforcer, the
first hit is actually the maven-enforcer-plugin's Usage page:
http://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html

Where it gives a specific example that flags the maven-verifier-plugin as a
banned plugin (!!!), and suggests to use the maven-invoker-plugin instead.
I know it was only a theoretical example, but the implication is that the
XML snippet has some grounding in reality somehow...

So I was wondering if there is a writeup anywhere with best practice
recommendations concerning these plugins? Comparison, pros  cons, etc.? In
a nutshell: I had not heard of the Verifier plugin before your
announcement, and was wondering what use cases it covers that the enforcer
plugin does not also cover.

Thanks,
Curtis

On Thu, Apr 16, 2015 at 12:24 PM, Karl Heinz Marbaise khmarba...@apache.org
 wrote:

 The Apache Maven team is pleased to announce the release of the
 Apache Maven Verifier Plugin, version 1.1

 Useful for integration tests - verifies the existence of certain
 conditions.

 http://maven.apache.org/plugins/maven-verifier-plugin/

 Please be aware of the new location of our issue tracker
 which has been moved from Codehaus to Apache Software Foundation

 The new location is:

 https://issues.apache.org/jira/browse/MVERIFIER

 Release Notes - Apache Maven Verifier Plugin - Version 1.1


 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318120version=12331744

 Improvements:

  * [MVERIFIER-15] - Upgrade to Maven 2.2.1 compatiblity
  * [MVERIFIER-16] - Change execution of goals cause currently the
 integration tests running twice

 New Feature:

  * [MVERIFIER-10] - Print the absolute path to the input file when
 verification fails

 Task:

  * [MVERIFIER-13] - use maven-plugin-tools' java 5 annotations


 Enjoy,

 -The Apache Maven team

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

Re: Maven + Jenkins not packaging war with jars

[Curtis Rueden]

Hi Murthy,

You might get a better response on a Jenkins mailing list:
https://jenkins-ci.org/content/mailing-lists

That said, I do have one question/suggestion: are you using the
Maven-style job? Or Freestyle job? If you are using the Maven-style job,
try switching to Freestyle, and use the Invoke top-level Maven targets
build step. Then Jenkins behaves faithfully with Maven CLI calls.
Conversely, the Maven-style job does some wacky things which can result in
different behavior than calling Maven from the command line.

Regards,
Curtis

On Fri, Apr 17, 2015 at 10:48 AM, Gandikota, Murthy 
mgandik...@westechmed.com wrote:

 Hi All
 Using Jenkins 1.596, the jar files are not included in the WAR by maven
 which is given the following goals:
 clean dependency:tree install -P component clover2:setup test
 clover2:aggregate clover2:clover
 When I run maven on the command line the WAR is built correctly by
 including all the dependent jars. Also, when an upstream project invokes
 build, the WAR is built correctly. Can anyone figure out why this is so?
 Many thanks for your help

Re: What is all this junk?

[Curtis Rueden]

Hi Steve,

 What's an MCVE?

http://lmgtfy.com/?q=mcve

-Curtis

On Wed, Apr 8, 2015 at 12:23 PM, Steve Cohen stevec...@comcast.net wrote:

 What's an MCVE?


 On 04/08/2015 11:45 AM, Curtis Rueden wrote:

 Hi Steve,

 I don't see that stuff with my builds. Post an MCVE somewhere.

 -Curtis

 On Wed, Apr 8, 2015 at 11:36 AM, Steve Cohen sco...@javactivity.org
 wrote:

  I finally got around to making the warnings about slf4j static logger
 disappear from my Eclipse builds and now I get this, instead with every
 build step Maven executes?



 -[explicit bindings]-
 --

 0. ProviderInstanceBinding{key=Key[type=com.google.inject.Injector,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=ProviderInjector}

 1. ProviderInstanceBinding{key=Key[type=java.util.logging.Logger,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=ProviderLogger}

 2. ProviderInstanceBinding{key=Key[type=org.slf4j.Logger,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=Providerorg.slf4j.Logger}

 3. InstanceBinding{key=Key[type=com.google.inject.Stage,
 annotation=[none]], source=[unknown source], instance=DEVELOPMENT}

 4. InstanceBinding{key=Key[type=org.codehaus.plexus.context.Context,
 annotation=[none]], source=org.codehaus.plexus.DefaultPlexusContainer$
 ContainerModule.configure(DefaultPlexusContainer.java:800),
 instance={plexus=org.codehaus.plexus.DefaultPlexusContainer@3b8b49}}

 ...

 111. InstanceBinding{key=Key[type=org.sonatype.guice.plexus.
 config.PlexusBeanConverter,
 annotation=[none]], source=org.codehaus.plexus.DefaultPlexusContainer$
 DefaultsModule.configure(DefaultPlexusContainer.java:836),
 instance=org.sonatype.guice.plexus.converters.
 PlexusXmlBeanConverter@1581593}

 What is all this junk and how do I make it disappear?








 -
 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: What is all this junk?

[Curtis Rueden]

Hi Steve,

I don't see that stuff with my builds. Post an MCVE somewhere.

-Curtis

On Wed, Apr 8, 2015 at 11:36 AM, Steve Cohen sco...@javactivity.org wrote:

 I finally got around to making the warnings about slf4j static logger
 disappear from my Eclipse builds and now I get this, instead with every
 build step Maven executes?



 -[explicit bindings]-
 --

 0. ProviderInstanceBinding{key=Key[type=com.google.inject.Injector,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=ProviderInjector}

 1. ProviderInstanceBinding{key=Key[type=java.util.logging.Logger,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=ProviderLogger}

 2. ProviderInstanceBinding{key=Key[type=org.slf4j.Logger,
 annotation=[none]], source=[unknown source], scope=Scopes.NO_SCOPE,
 provider=Providerorg.slf4j.Logger}

 3. InstanceBinding{key=Key[type=com.google.inject.Stage,
 annotation=[none]], source=[unknown source], instance=DEVELOPMENT}

 4. InstanceBinding{key=Key[type=org.codehaus.plexus.context.Context,
 annotation=[none]], source=org.codehaus.plexus.DefaultPlexusContainer$
 ContainerModule.configure(DefaultPlexusContainer.java:800),
 instance={plexus=org.codehaus.plexus.DefaultPlexusContainer@3b8b49}}

 ...

 111. 
 InstanceBinding{key=Key[type=org.sonatype.guice.plexus.config.PlexusBeanConverter,
 annotation=[none]], source=org.codehaus.plexus.DefaultPlexusContainer$
 DefaultsModule.configure(DefaultPlexusContainer.java:836),
 instance=org.sonatype.guice.plexus.converters.
 PlexusXmlBeanConverter@1581593}

 What is all this junk and how do I make it disappear?








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

Re: Force install of dependent modules before package

[Curtis Rueden]

Hi Eric,

 project A mvn package

 such that modules 1  2 will automatically be installed before the
 shade plugin runs for module 3?

My understanding is that you would need to run mvn install (not mvn
package) from the project A base directory, if you want 1 and 2 to be
installed. But it should happen in the order you desire, no?

-Curtis

On Wed, Apr 8, 2015 at 11:23 AM, Anders Hammar and...@hammar.net wrote:

 Not sure I follow. Isn't Project A a multi-module project? Then if you do
 mvn package, module 1 and 2 should build before 3 if you have declared
 the dependencies correctly.

 /Anders

 On Wed, Apr 8, 2015 at 6:17 PM, Eric Kolotyluk eric.koloty...@gmail.com
 wrote:

  I have
 
  Project A
  - module 1
  - module 2
  - module 3 (depends on 1  1)
  -- creates shaded artifact
 
  Is there a way that I can configure my poms to do
 
  project A mvn package
 
  such that modules 1  2 will automatically be installed before the shade
  plugin runs for module 3?
 
  Cheers, Eric
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: -P overrides activeByDefault in pom.xml

[Curtis Rueden]

Hi Alexander,

Personally I avoid using activeByDefault, since as you encountered, it can
be confusing.

Instead, you can use activation based on system properties. That tends to
behave in a more intuitive way, and is also much more flexible, IMO.

Then instead of writing -PmyProfile you write -DmyFeature=active or
whatever.

Regards,
Curtis

On Mon, Jun 8, 2015 at 3:07 PM, Alexander Kriegisch 
alexan...@kriegisch.name wrote:

 -P+abc does not work in the context described in Anders' answer: the
 profile in question is also declared in the same POM as the
 active-by-default one. I would have expected the '+' syntax to do what I
 want, but it does not.

 --
 Alexander Kriegisch


  Am 08.06.2015 um 14:18 schrieb Stephen Connolly 
 stephen.alan.conno...@gmail.com:
 
  -Pabc,xyz
 
  Means you are saying the following profiles are to be active: abc, xyz.
 By
  specifying profiles you are saying do not use the default profiles
 
  -P+abc
 
  Means activate the profile abc in addition to the defaults
 
  -P-xyz
 
  Or
 
  -P!xyz
 
  Means ensure profile xyz is not active even if active by default
 
  On Monday, June 8, 2015, Alexander Kriegisch alexan...@kriegisch.name
  wrote:
 
  Hi Jenkins experts.
 
  When I do something like
 
 mvn help:active-profiles
 
  for a module defining a profile inside its pom.xml with activeByDefault
  set to true, the corresponding profile is indeed active in addition to
 any
  profiles defined in settings.xml.
 
  Now when I do
 
 mvn help:active-profiles -P Foo
 
  I see that Foo is active, the profiles from settings.xml are, too, but
 the
  profile from pom.xml is inactive. I would expect it to remain active
  because I have not specified anything like -P !MyPomProfile.
 
  I have tested with Maven 3.2.5, 3.3.1, 3.3.3, same behaviour in each
  version.
 
  Is my expectation wrong (the manual does not contradict it, at least) or
  is this a bug?
 
  Regards
  --
  Alexander Kriegisch
  http://scrum-master.de
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 javascript:;
  For additional commands, e-mail: users-h...@maven.apache.org
  javascript:;
 
  --
  Sent from my phone

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

Re: Help needed with a strange fixed filename

[Curtis Rueden]

Hi Thomas,

 it's name cannot be changed because during runtime it is checked and
 if changed a runtime exception is thrown

IMHO, the fact that your third party JAR does that is incredibly terrible.

 Yes, we could change the code with the filename check. But I'm loath
 to do it since it is a 3rd party jar file and we had to do this every
 time a new version is released...

One big hammer way to work around this, and other horrible third party
behaviors, is bytecode manipulation using a library such as Javassist or
ASM. Also called runtime patching, you can make a surgical change to the
stupid exception thrown by the 3rd party library, which will be resistant
to future upgrades of that library. It does require careful use of
ClassLoaders, though. It would be much more ideal to work with the upstream
vendor/developers to fix the problem there.

Regards,
Curtis

On Mon, Jun 8, 2015 at 8:10 AM, Thomas Klöber 
thomas.kloe...@securintegration.com wrote:

 Hi Karl Heinz,

 thanks for your answer.

 Yes, we could change the code with the filename check. But I'm loath to do
 it since it is a 3rd party jar file and we had to do this every time a new
 version is released...

 I'm just surprised that there is no other way or means to tell Maven that
 a different naming scheme should be used...

 Deployment at customer site is no problem, the nexus and naming issue only
 affects us during development.


 -Ursprüngliche Nachricht-
 Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
 Gesendet: Freitag, 5. Juni 2015 14:34
 An: Maven Users List
 Betreff: Re: Help needed with a strange fixed filename

 Hi Thomas,


 That the file is names in Nexus is the default naming schema within a
 maven repository so there is no chance to change it.

 So first question: Why not changing the code which checks the filename
 and follow the naming convention..?

 What you can do is to get the appropriate artifact via plugin (like
 maven-dependency-plugin) and rename it during the packaging of your
 distribution archive (which i assume you have?) Or are we talking about
 an EAR file?




 On 6/5/15 1:58 PM, Thomas Klöber wrote:
  Hi folks'es,
 
  I am having some problems, getting an external jar-file into my Maven
 project.
  Here is the issue:
 
  · the jar file has a fixed name, lets say jarfile3.jar (digit 3
 is important!)
 
  · it's name cannot be changed because during runtime it is
 checked and if changed a runtime exception is thrown
 
  ·  if I create an artefact for it in my nexus, the file name is
 changed to jarfile-3.x.x
 
  · adding this to my pom.xml as a dependency everything builds
 just fine
 
  · however, if I run my application now, it falls over with the
 above runtime exception
 
  What would be the best way of incoorporating an external jar into my
 project without having hard-coded pathnames?
  We are using Eclipse Kepler as IDE and Maven 3
 
  Thanks,
  _
  SecurIntegration
  Thomas Klöber
  Software Engineer
  Rösrather Str. 702
  51107 Köln
  Fon: +49 (221) 71 99 00-0
  Fax: +49 (221) 71 99 00-23
 
  www.SecurIntegration.comhttp://www.SecurIntegration.com
 
  Amtsgericht Köln HRB 35063
  Geschäftsführer: Guido Schneider
 
  Determine your actual SAP license needs
 http://www.securintegration.com/slc
 
 

 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: Codehaus Mojo repository

[Curtis Rueden]

Hi Olivier,

 Have a look here https://github.com/mojohaus/

Mojo was split up? Fantastic! Thank you so much, nice work!

Regards,
Curtis

On Wed, Jun 3, 2015 at 9:01 AM, Olivier Lamy ol...@apache.org wrote:

 Hi
 Have a look here https://github.com/mojohaus/

 Olivier

 On 3 June 2015 at 16:57, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi everyone,
 
  It looks like Codehaus SVN is finally kaput:
 
  $ svn checkout http://svn.codehaus.org/mojo
  svn: E175011: Unable to connect to a repository at URL '
  http://svn.codehaus.org/mojo'
  svn: E175011: Repository moved temporarily to '
 http://www.codehaus.org
  ';
  please relocate
 
  But the mojo repository is not yet populated on GitHub:
  https://github.com/codehaus/mojo
 
  Is it planned to populate that repository? Where does the code live in
 the
  meantime?
 
  Thanks,
  Curtis
 



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy

Codehaus Mojo repository

[Curtis Rueden]

Hi everyone,

It looks like Codehaus SVN is finally kaput:

$ svn checkout http://svn.codehaus.org/mojo
svn: E175011: Unable to connect to a repository at URL '
http://svn.codehaus.org/mojo'
svn: E175011: Repository moved temporarily to 'http://www.codehaus.org';
please relocate

But the mojo repository is not yet populated on GitHub:
https://github.com/codehaus/mojo

Is it planned to populate that repository? Where does the code live in the
meantime?

Thanks,
Curtis

Re: Use of Multiple Local Repositories

[Curtis Rueden]

Hi Mehdi,

 it could be great if we can use multiple local reposiry for a build

That has been discussed before on the list [1]. It was an interesting
discussion but ultimately Maven does not support such a feature. I think it
would be useful if a motivated party pursued it, though.

Regards,
Curtis

[1] 
*http://mail-archives.apache.org/mod_mbox/maven-users/201310.mbox/%3C1617140979.4777131.1383039481273.JavaMail.root%40imag.fr%3E
http://mail-archives.apache.org/mod_mbox/maven-users/201310.mbox/%3C1617140979.4777131.1383039481273.JavaMail.root%40imag.fr%3E*

On Thu, Jun 4, 2015 at 10:30 AM, Mehdi Hayani hayani.mehdi...@gmail.com
wrote:

 Hello,

 I'm actually working on a continuous integration platform, and most of the
 projects are using Maven as a build tool.

 We've found that there is a list of dependencies and plugins most of the
 projects have to download in addition of there specific dependencies.
 Therefore, I though it could be great if we can use multiple local reposiry
 for a build, the idea is:

- Local repo 1 : Is the shared folder where we will put dependencies
that are download by each project.
- Local repo 2 : this one is created for each project and it will
contains dependencies that are specific to that project.


 So while running the build, maven will check in local repo 1, if it can't
 find the required librairy it will download it and put it in local repo 2


 It there a way to implement this solution :) ?

 Thanks in advance

Re: Maven Shad Plugin with AWS Java SDK

[Curtis Rueden]

Hi Matt and Michael,

Matt Benson wrote:
 In my experience you must relocate each individual package; simply
 relocating org.apache.http is not sufficient.

In my experience, the maven-shade-plugin will process subpackages which
match the given patterns. Here is a working example that shades all of
Jython's dependencies:

https://github.com/scijava/jython-shaded/blob/jython-shaded-2.5.3/deps/pom.xml#L56-L93

Regards,
Curtis

On Thu, Jun 25, 2015 at 7:25 AM, Matt Benson gudnabr...@gmail.com wrote:

 In my experience you must relocate each individual package; simply
 relocating org.apache.http is not sufficient.

 Matt
 On Jun 25, 2015 6:11 AM, mmccar...@tribloom.com mmccar...@tribloom.com
 wrote:

  I have been attempting to shade[1] the AWS Java SDK[2] version 1.10.1,
  specifically the S3 SDK, to relocate the Apache HTTPCompontents[3]
  libraries. I am attempting to do this in order to resolve a dependency
  conflict with another more complicated project which is also dependent on
  an older version of HTTPComponents. So far I have been unsuccessful and
  can't determine if it is misconfiguration or an issue with the plugin. I
  hope it is the former.
 
  First I added a Maven Shade configuration to the aws-java-sdk-core
 pom.xml:
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-shade-plugin/artifactId
 version2.4/version
 configuration
artifactSet
   includes
  includecom.amazonaws:*/include
  includeorg.apache.httpcomponents:*/include
   /includes
/artifactSet
relocations
   relocation
  patternorg.apache.http/pattern
  shadedPatternorg.shaded.http/shadedPattern
   /relocation
/relocations
 /configuration
 executions
execution
   phasepackage/phase
   goals
  goalshade/goal
   /goals
/execution
 /executions
  /plugin
 
  This seems to work fine and produces a jar that seems to be as expected
  when I build the project using mvn clean install -Dgpg.skip=true
  -DskipTests=true, although I haven't tested it. Second, I modify the
  aws-java-sdk-s3 pom.xml as follows:
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-shade-plugin/artifactId
 version2.4/version
 configuration
shadeSourcesContenttrue/shadeSourcesContent
createSourcesJartrue/createSourcesJar
artifactSet
   includes
  includecom.amazonaws:*/include
  includeorg.apache.httpcomponents:*/include
   /includes
/artifactSet
relocations
   relocation
  patternorg.apache.http/pattern
  shadedPatternorg.shaded.http/shadedPattern
   /relocation
/relocations
 /configuration
 executions
execution
   phasepackage/phase
   goals
  goalshade/goal
   /goals
/execution
 /executions
  /plugin
 
  By itself this produces build errors like this:
  [ERROR]
 
 \dev\CSJ\aws\aws-sdk-java-1.10.1\aws-java-sdk-s3\src\main\java\com\amazonaws\services\s3\model\S3ObjectInputStream.java:[20,29]
  error: package org.apache.http.client does not exist
 
  So I added an explicit dependency on HTTPComponents to the S3 pom.xml:
  dependency
 groupIdorg.apache.httpcomponents/groupId
 artifactIdhttpclient/artifactId
 version4.3.6/version
  /dependency
 
  When I build I get only one error:
  [ERROR]
 
 \dev\CSJ\aws\aws-sdk-java-1.10.1\aws-java-sdk-s3\src\main\java\com\amazonaws\services\s3\internal\S3ObjectResponseHandler.java:[54,26]
  error: no suitable constructor found for
 
 S3ObjectInputStream(InputStream,org.shaded.http.client.methods.HttpRequestBase)
 
  It appears to me that the shading is not actually relocating the
  http.client.methods.HttpRequestBase argument to the S3ObjectInputStream
  class within the code. Running javap confirms this:
  $ javap
  target/classes/com/amazonaws/services/s3/model/S3ObjectInputStream.class
  Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
  Compiled from S3ObjectInputStream.java
  public class com.amazonaws.services.s3.model.S3ObjectInputStream extends
  com.amazonaws.internal.SdkFilterInputStream {
public
  com.amazonaws.services.s3.model.S3ObjectInputStream(java.io.InputStream,
  org.apache.http.client.methods.HttpRequestBase);
public
  com.amazonaws.services.s3.model.S3ObjectInputStream(java.io.InputStream,
  org.apache.http.client.methods.HttpRequestBase, boolean);
public void abort();
public org.apache.http.client.methods.HttpRequestBase getHttpRequest();
public int available() throws java.io.IOException;
  }
 
  Can anyone point out if my configuration is wrong, my methodology is
  wrong, or the Maven Shade plugin is actually not behaving as expected?
 
  [1] http://maven.apache.org/plugins/maven-shade-plugin/index.html
  [2] https://github.com/aws/aws-sdk-java
  [3] https://hc.apache.org/
 
  Thanks,
  --
  Michael
 

Re: Why are extensions project based and not global?

[Curtis Rueden]

Hi,

 Even with a single organization having config outside the project is a
 right pain. Instead of it's maven, you know what to do, you have
 some weird site specific ritual to perform, and this creates friction.

FWIW, in general, I agree 100%. One of the beautiful things about Maven is
that for every project, you can:

$ git clone git://github.com/myorg/myproj
$ cd myproj
$ mvn

And good things happen! So awesome!

As soon as you also have to start tweaking ~/.m2/settings.xml or
settings-security.xml or extensions.xml or whatever, the beauty is gone...

Regards,
Curtis

On Thu, May 28, 2015 at 1:21 PM, Graham Leggett minf...@sharp.fm wrote:

 On 28 May 2015, at 16:58, Manfred Moser manf...@mosabuam.com wrote:

  I think having a global config for this would be good. Personally I
 think having .m2/extensions.xml would be a good way to do it.

 Can you describe the use case?

 It seems this only makes sense if you only ever do work for one
 organization, ever. As soon as you need to do work for multiple clients, or
 perhaps your corporate client and an open source project, using maven
 becomes difficult.

 Even with a single organization having config outside the project is a
 right pain. Instead of it's maven, you know what to do, you have some
 weird site specific ritual to perform, and this creates friction.

 Regards,
 Graham
 --


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

Re: Skill set to maintain a enterprise build system using Maven

[Curtis Rueden]

Hi Dan,

 PS.  Would love to hear other experiences from community rather me
 sucking out Mirko's :-)

Not sure how relevant my scenario is, but here goes:

My group consists of an international collaboration of OSS developers at
universities etc., rather than a company. But a lot of our needs are the
same.

- We have 2-3 core DevOps who maintain our Maven architecture
(corporate POM [1] etc.), with several others in the community who have
been trained enough on how things work to understand and occasionally
contribute to it.

- The projects encompass several GitHub orgs, each of which has its own
primary maintainer(s) who at least understand how their Maven POM hierarchy
works.

- We have Jenkins jobs for everything. http://jenkins.imagej.net/

- We use Nexus to manage our Maven artifacts. http://maven.imagej.net/

 - is java skill set to develop plugin a must?

No, although it is occasionally useful. I think knowing Java can make you a
better Maven community member though because you can contribute bug-fixes
to the plugins you find useful. E.g., we use license-maven-plugin, but it
wouldn't have behaved the way we needed if I hadn't helped it get patched
upstream.

 - do you have a team or just a few of deep understanding of Maven
developers?

2-3 with deep understanding and several others worldwide with moderate
understanding has been sufficient for us. And a whole community with next
to no understanding of Maven, for whom things just work in their IDE of
choice.

 - will a none java RelEng able to perform Maven release?

I don't see why not, although in my scenario everyone who knows about Maven
also knows about Java. So for us it is the converse: lots of Java
developers who know little about Maven but want to do their own releases.
And the beauty of it is: they can! http://imagej.net/Releases

 - does your RelEng maintains the pom or developers?

My group has no dedicated RelEng—just two core developers who also wear the
RelEng hat among many others. In practice, for the most part, the same
people who ultimately maintain the most root-level POMs also end up doing
the releases of the most root-level software projects.

 - what are your challenges?

Maven makes it possible for a small number of developers to maintain 300+
Git repositories. This is a two edged sword, though: Maven only solves the
project management side of things, not the other aspects (software
design/architecture, coding of new features, community support, etc.).

It is important to note that there are many project management challenges
that Maven makes easier to solve but does not itself fully solve in a
turn-key way. In particular, continuous integration (thank you Jenkins!)
and versioning (we use SemVer and carefully managed BOMs) spring to mind.

Since everything we do is OSS, if you care you can read about it yourself:

  http://imagej.net/Architecture
  http://imagej.net/Governance

Regards,
Curtis

On Sun, May 31, 2015 at 4:06 AM, Dan Tran dant...@gmail.com wrote:

 Hi Mirko,

 Looks like the topic getting very interesting here, but I would like to
 refocus on the skillset

 How did you form up your team?, did you all pickup Java before joining this
 devops team?

 Thanks for all the sharing

 -Dan

 PS.  Would love to hear other experiences from community rather me sucking
 out Mirko's :-)


 On Sun, May 31, 2015 at 1:03 AM, Mirko Friedenhagen 
 mfriedenha...@gmail.com
  wrote:

  Hello Dan,
 
  we treat tooling like software as well. Ticket creation is an automated 2
  click process and the package qa will not take more than 5 minutes for
  small changes.
 
  External libraries from central may be used at free will, but we
 recommend
  stuff in a so called toolbox, these dependencies are managed in the
  department pom.
 
  The (programming) architects and we help discovering alternatives in our
  toolbox, stuff from repositories outside central is mostly put in a
  third-party repo in Artifactory.
 
  Regards
  Mirko
  --
  Sent from my mobile
  Am 31.05.2015 00:06 schrieb Dan Tran dant...@gmail.com:
 
   Hi Mirko
  
   Looks like you have Artifactory to store all of release artifacts and
   another 'release' repo to store the final approved release
  
   Is internal tooling, thirdparty upload  going thru the same release
   process?
  
   Thanks
  
   -Dan
  
   On Sat, May 30, 2015 at 2:41 PM, Mirko Friedenhagen 
   mfriedenha...@gmail.com
wrote:
  
Hello Dan,
   
- Every developer may deploy SNAPSHOTs, however this is normally done
by Jenkins.
- We do not enforce staging from Jenkins, however almost all projects
do this. We do not enforce this, so Jenkins outages do not inhibit
releasing hot fixes.
- Releases are deployed to a staging repository in Artifactory and we
have a process called package-qa where for every staged release a
corresponding JIRA ticket has to be created with information
 (changes,
Wiki page, diff link since last release, ticket queue). This is a
central 

Re: Maven Shad Plugin with AWS Java SDK

[Curtis Rueden]

Hi Michael,

Sorry, I've been too busy to follow up on this in detail.

My strong intuition is that you don't need to hack the Amazon S3 source
code or POMs at all. Rather, you can create another project downstream
whose whole purpose is to shade the contents of
com.amazonaws:aws-java-sdk-s3 as you desire, producing an uber-jar artifact
with GAV of your choosing.

This is how I shaded org.python:jython-standalone to fix some of its
embedded libraries. In your case, you'd be creating an uber-jar for
aws-java-sdk-s3 that includes all (or some) of its dependencies, some of
which (of your choosing) get shaded/renamed.

I pushed the start of such a project:
https://github.com/ctrueden/aws-java-sdk-s3-shaded

Unfortunately, I don't have time to get it working right now. But maybe you
can solve it. I am not convinced this is a problem with Shade (though I
suppose it might be).

Regards,
Curtis

On Sat, Jun 27, 2015 at 12:22 PM, mmccar...@tribloom.com 
mmccar...@tribloom.com wrote:

 Curtis,

 I have checked in my code to github: g...@github.com:
 tribloom/aws-sdk-java.git.

 You can check out my shaded version by doing a git clone 
 g...@github.com:tribloom/aws-sdk-java.git
 followed by a git checkout -b test origin/1.10.2 (test can be changed
 to whatever branch name you would like to use locally) in the newly created
 repository directory (aws-java-sdk).

 You should see three modified files, pom.xml, ./aws-java-sdk-core/pom.xml,
 and ./aws-java-sdk-s3/pom.xml.

 Then run maven to build the project (narrowed down to just
 aws-java-sdk-core, aws-java-sdk-kms, and aws-java-sdk-s3 using the top
 level pom.xml):
 mvn install -DskipTests=true

 You should get the core and kms to build properly and then s3 will fail
 with:
 [INFO] AWS SDK for Java .. SUCCESS [0.380s]
 [INFO] AWS SDK for Java - Core ... SUCCESS
 [10.438s]
 [INFO] AWS Java SDK for AWS KMS .. SUCCESS [2.942s]
 [INFO] AWS Java SDK for Amazon S3  FAILURE [3.733s]
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 17.646s
 [INFO] Finished at: Sat Jun 27 11:12:55 MDT 2015
 [INFO] Final Memory: 33M/518M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3:compile
 (default-compile) on project aws-java-sdk-s3: Compilation failure
 [ERROR]
 \dev\CSJ\aws\temp\aws-sdk-java\aws-java-sdk-s3\src\main\java\com\amazonaws\services\s3\internal\S3ObjectResponseHandler.java:[54,26]
 error: no suitable constructor found for
 S3ObjectInputStream(InputStream,org.shaded.http.client.methods.HttpRequestBase)

 The way I understood the shade plugin to work, it would relocate the
 dependencies and rewrite the code that called those dependencies. I
 thought it would fix the constructor for S3ObjectInputStream to match the
 newly relocated org.apache.http.client.methods.HttoRequestBase class. If
 this isn't the way it should work, how then do I get the shaded project to
 build?

 Thanks,
 Michael

 On 6/26/2015 5:52 AM, Curtis Rueden wrote:

 Hi Michael,

 Your error message refers to the maven-compiler-plugin. Are you sure the
 shade plugin is the culprit? Normally shade is bound to a later phase. If
 you need further detailed assistance, share your project (or an MCVE) with
 us.

 Regards,
 Curtis
 On Jun 25, 2015 5:16 PM, mmccar...@tribloom.com mmccar...@tribloom.com
 
 wrote:

Matt/Curtis,

 I tried using both packages and a higher package with no luck, I get the
 same error message:
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3:compile
 (default-compile) on project aws-java-sdk-s3: Compilation failure[ERROR]

 \dev\CSJ\aws\aws-sdk-java-1.10.1\aws-java-sdk-s3\src\main\java\com\amazonaws\services\s3\internal\S3ObjectResponseHandler.java:[54,26]
 error: no suitable constructor found for

 S3ObjectInputStream(InputStream,org.shaded.http.client.methods.HttpRequestBase)

 I tried:
  relocations
  relocation
  patternorg/pattern
  shadedPatternshaded/shadedPattern
  /relocation
  /relocations
 and:
  relocations
  relocation
  patternorg.apache/pattern
  shadedPatternorg.shaded/shadedPattern
  /relocation
  relocation
  patternorg.apache.http/pattern

  shadedPatternorg.shaded.http/shadedPattern
  /relocation
  relocation
  patternorg.apache.http.methods/pattern

Re: mvn -nsu (--no-snapshot-updates) is still downloading SNAPSHOT versions

[Curtis Rueden]

Hi Robert,

 Is there a way to let a maven build fail if we depend on nonexistent
 or SNAPSHOT dependencies?

Check out the requireReleaseDeps rule of the Maven Enforcer plugin:
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html

Regards,
Curtis

On Tue, May 26, 2015 at 6:55 AM, Robert Metzger rmetz...@apache.org wrote:

 Thank you Nick.
 Your solution would work, but would require us to let users call a bash
 script which is calling versions:display-dependency-updates and then doing
 the regular build.
 We would like to run our builds directly by mvn clean install.


 Is there a way to let a maven build fail if we depend on nonexistent or
 SNAPSHOT dependencies?
 So what happened in our project is the following: We renamed a module from
 flink-compiler to flink-optimizer.
 While merging some older patches, a new module was still depending on
 flink-compiler (the old name) and we didn't notice this because maven was
 getting the flink-compiler file from apache's snapshot repository.

 Ideally, the maven build should fail when somebody is doing mvn clean
 install.

 On Tue, May 26, 2015 at 11:30 AM, Nick Stolwijk nick.stolw...@gmail.com
 wrote:

  Maven is not downloading updates, but only the SNAPSHOTS it is missing.
 If
  you build another time it won't download anything and even if your update
  window (mostly daily) has been passed Maven will not look for new updates
  but use the ones it has locally.
 
  If you want to know which dependencies needs updates you can use the
  versions plugin.
 
 
 - versions:display-dependency-updates
 
 
 http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html
  
  scans
 a project's dependencies and produces a report of those dependencies
  which
 have newer versions available.
 - versions:display-plugin-updates
 
 
 http://mojo.codehaus.org/versions-maven-plugin/display-plugin-updates-mojo.html
  
  scans
 a project's plugins and produces a report of those plugins which have
  newer
 versions available.
 - versions:display-property-updates
 
 
 http://mojo.codehaus.org/versions-maven-plugin/display-property-updates-mojo.html
  
  scans
 a projectand produces a report of those properties which are used to
 control artifact versions and which properies have newer versions
  available.
 
  Hth,
 
  Nick Stolwijk
 
  ~~~ Try to leave this world a little better than you found it and, when
  your turn comes to die, you can die happy in feeling that at any rate you
  have not wasted your time but have done your best ~~~
 
  Lord Baden-Powell
 
  On Tue, May 26, 2015 at 11:18 AM, Robert Metzger rmetz...@apache.org
  wrote:
 
   Hi,
  
   At our project we recently had an issue where we accidentally included
   outdated artifacts (which were still available on snapshot
 repositories).
   To detect those issues in the future by our integration tests, I want
 to
   instruct maven not to download snapshot updates, using the -nsu command
   line argument.
  
   However, doing
  
   mvn clean install -nsu -DskipTests -Dmaven.repo.local=/tmp/test-mvn
  
  
   will still lead to:
  
   [INFO]
  
 
   [INFO] Building flink-language-binding-generic 0.9-SNAPSHOT
   [INFO]
  
 
   Downloading:
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/maven-metadata.xmlDownloaded
   :
  
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/maven-metadata.xml
   (2 KB at 0.8 KB/sec)Downloading:
  
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.pomDownloaded
   :
  
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.pom
   (4 KB at 5.7 KB/sec)Downloading:
  
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.jarDownloaded
   :
  
  
 
 http://repository.apache.org/snapshots/org/apache/flink/flink-compiler/0.9-SNAPSHOT/flink-compiler-0.9-20150313.122611-190.jar
   (2660 KB at 379.7 KB/sec)
  
  
   I've added the steps to reproduce here:
  
  
 
 https://issues.apache.org/jira/browse/MNG-5064?focusedCommentId=14551952page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14551952
  
   I would like to know whether I misunderstood the feature or if this is
 a
   bug.
  
   Best,
   Robert
  
 

Re: Maven Shad Plugin with AWS Java SDK

[Curtis Rueden]

Hi Michael,

Your error message refers to the maven-compiler-plugin. Are you sure the
shade plugin is the culprit? Normally shade is bound to a later phase. If
you need further detailed assistance, share your project (or an MCVE) with
us.

Regards,
Curtis
On Jun 25, 2015 5:16 PM, mmccar...@tribloom.com mmccar...@tribloom.com
wrote:

  Matt/Curtis,

 I tried using both packages and a higher package with no luck, I get the
 same error message:
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3:compile
 (default-compile) on project aws-java-sdk-s3: Compilation failure[ERROR]
 \dev\CSJ\aws\aws-sdk-java-1.10.1\aws-java-sdk-s3\src\main\java\com\amazonaws\services\s3\internal\S3ObjectResponseHandler.java:[54,26]
 error: no suitable constructor found for
 S3ObjectInputStream(InputStream,org.shaded.http.client.methods.HttpRequestBase)

 I tried:
 relocations
 relocation
 patternorg/pattern
 shadedPatternshaded/shadedPattern
 /relocation
 /relocations
 and:
 relocations
 relocation
 patternorg.apache/pattern
 shadedPatternorg.shaded/shadedPattern
 /relocation
 relocation
 patternorg.apache.http/pattern
 shadedPatternorg.shaded.http/shadedPattern
 /relocation
 relocation
 patternorg.apache.http.methods/pattern

 shadedPatternorg.shaded.http.methods/shadedPattern
 /relocation
 /relocations

 Has anyone else had luck with trying to shade the AWS Java SDK? Can anyone
 with more experience try and build the project given my configuration and
 tell me the results?

 Thanks,
 Michael
  On 6/25/2015 10:27 AM, Curtis Rueden wrote:

 Hi Matt and Michael,

  Matt Benson wrote:
  In my experience you must relocate each individual package; simply
  relocating org.apache.http is not sufficient.

  In my experience, the maven-shade-plugin will process subpackages which
 match the given patterns. Here is a working example that shades all of
 Jython's dependencies:


 https://github.com/scijava/jython-shaded/blob/jython-shaded-2.5.3/deps/pom.xml#L56-L93

  Regards,
 Curtis

 On Thu, Jun 25, 2015 at 7:25 AM, Matt Benson gudnabr...@gmail.com wrote:

 In my experience you must relocate each individual package; simply
 relocating org.apache.http is not sufficient.

 Matt
 On Jun 25, 2015 6:11 AM, mmccar...@tribloom.com mmccar...@tribloom.com
 
 wrote:

  I have been attempting to shade[1] the AWS Java SDK[2] version 1.10.1,
  specifically the S3 SDK, to relocate the Apache HTTPCompontents[3]
  libraries. I am attempting to do this in order to resolve a dependency
  conflict with another more complicated project which is also dependent
 on
  an older version of HTTPComponents. So far I have been unsuccessful and
  can't determine if it is misconfiguration or an issue with the plugin. I
  hope it is the former.
 
  First I added a Maven Shade configuration to the aws-java-sdk-core
 pom.xml:
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-shade-plugin/artifactId
 version2.4/version
 configuration
artifactSet
   includes
  includecom.amazonaws:*/include
  includeorg.apache.httpcomponents:*/include
   /includes
/artifactSet
relocations
   relocation
  patternorg.apache.http/pattern
  shadedPatternorg.shaded.http/shadedPattern
   /relocation
/relocations
 /configuration
 executions
execution
   phasepackage/phase
   goals
  goalshade/goal
   /goals
/execution
 /executions
  /plugin
 
  This seems to work fine and produces a jar that seems to be as expected
  when I build the project using mvn clean install -Dgpg.skip=true
  -DskipTests=true, although I haven't tested it. Second, I modify the
  aws-java-sdk-s3 pom.xml as follows:
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-shade-plugin/artifactId
 version2.4/version
 configuration
shadeSourcesContenttrue/shadeSourcesContent
createSourcesJartrue/createSourcesJar
artifactSet
   includes
  includecom.amazonaws:*/include
  includeorg.apache.httpcomponents:*/include
   /includes
/artifactSet
relocations
   relocation
  patternorg.apache.http/pattern
  shadedPatternorg.shaded.http/shadedPattern
   /relocation
/relocations
 /configuration
 executions
execution
   phasepackage/phase
   goals
  goalshade/goal
   /goals

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: How to delete certain snapshots from Nexus

[Curtis Rueden]

Hi Dave,

 Our IT group handles managing Nexus and they say there is no Nexus
 interface/feature to do this.

You can use the Remove Snapshots from Repository scheduled task.

See:
https://books.sonatype.com/nexus-book/reference/scheduled-tasks.html

Regards,
Curtis

On Tue, Jul 21, 2015 at 1:20 PM, David Hoffer dhoff...@gmail.com wrote:

 Our IT group handles managing Nexus and they say there is no Nexus
 interface/feature to do this.  The last time we requested this they ended
 up deleting these directly on the file system.  Ideally I'd like to find a
 way developers could do this, either using a Maven plugin or something
 similar, or by a Nexus API if that exists.

 -Dave

 On Tue, Jul 21, 2015 at 12:07 PM, Jeff MAURY jeffma...@jeffmaury.com
 wrote:

  Nexus tasks ?
  Jeff
  Le 21 juil. 2015 18:03, David Hoffer dhoff...@gmail.com a écrit :
 
   We use Nexus as our corporate Maven repository and would like to
   periodically delete certain SNAPSHOT artifacts.  We need to be able to
   filter/select by groupId and by version...so delete all where
   groupId=com.mycomp.mygroupid.* and version=X.SNAPSHOT.
  
   Our use case is that when we refactor part of the build to use new
  groupIds
   the old ones are not valid anymore however sometimes there is a
 lingering
   reference to the old groupId, if we can delete all the old SNAPSHOTS we
   could find those errors now instead of when we release.
  
   Any ideas on how to do this are much appreciated.
  
   -Dave
  
 

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.

Re: build error on strutsel

[Curtis Rueden]

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:

[image: 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.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.com [mailto: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.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.
 
 

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

Re: How to delete certain snapshots from Nexus

[Curtis Rueden]

Hi Dave,

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

The plugin I mentioned, scijava-maven-plugin [1], has a
verify-no-snapshots goal—and corresponding enforcer rule
requireReproducibleBuilds—which is more thorough than the enforcer's
built-in no snapshots rule: it recursively scans dependencies for
snapshot dependencies and parents, and fails the build if any are found.
This is important because some releases on Maven Central are actually
tainted, containing snapshot dependencies somewhere upstream.

My group's projects use one Git repo = one single-module Maven project =
one JAR file. Projects use release couplings between components so that
builds are reproducible [2]. We avoid multi-module builds because they are
more complex and make it harder to release components individually
[3]—although it is still possible [4]. The requireReproducibleBuilds rule
understands multi-module builds and will not fail the build unless there is
a snapshot dependency outside the reactor.

The requireReproducibleBuilds rule would go a long way toward solving your
use case, but might not catch every scenario such as old GAVs referenced
from an unpack goal config. However, the proper way to solve that is to
declare version properties in the parent for all your GAs, then use those
properties everywhere that version is needed. E.g.:

-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L133-L134
-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L815-L819
-
https://github.com/scijava/pom-scijava/blob/pom-scijava-7.5.2/pom.xml#L1094-L1099

Then your chances of out-of-sync versions will be drastically reduced.

Regards,
Curtis

[1] https://github.com/scijava/scijava-maven-plugin

[2] http://imagej.net/Reproducible_builds

[3] http://imagej.net/Philosophy#Release_early.2C_release_often

[4] We do have one exception (https://github.com/trakem2/TrakEM2) which is
a multi-module build, but with separately versioned components. Cutting a
release of (some subset of) those modules is unintuitive:
- We comment out the irrelevant modules in the aggregator POM (which
doubles as the parent POM), leaving only the modules to be released; then
- bump the versions of those modules forward to their new release versions;
and
- bump the version properties of the not-being-released modules _backward_
to their last release versions.
Then the (reduced in size) reactor has no snapshot dependencies in the
released modules. But we cannot release in this fashion using the
maven-release-plugin, unfortunately. So there are lots of downsides. The
upside is that you maintain a reproducible build on master always, with
tightly coupled modules normally, and proper release couplings for each set
of released modules.

On Wed, Jul 22, 2015 at 9:49 AM, David Hoffer dhoff...@gmail.com wrote:

 Hi Curtis,

 Yes that is the issue I'm trying to solve, except that we are less formal
 than your description implies.  We don't have 'approved' and 'non-approved'
 snapshots, rather we have valid ones and ones made obsolete by the
 refactor.

 Leaning on Nexus doesn't seem like a bad solution as after the refactor, as
 it does no one any good (including Nexus) to continue to retain the old
 artifacts, it would just clean things up if they could be deleted.  That
 being said...if you have a plugin that solves the same problem that is
 fine.  If you could elaborate on your solution that would be great.  I'd
 actually prefer to 'fix' this in the pom rather than Nexus as our Nexus is
 managed by IT and it's difficult for devs to get more than read privileges.

 -Dave

 On Wed, Jul 22, 2015 at 8:24 AM, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Dave,
 
  This problem strikes me as just a particular incarnation of make sure
 only
  approved deps are used where old snapshot versions of 1st party modules
  are no longer approved after a refactoring.
 
  As such, I would suggest looking for tools intended to support such
  dependency analysis more generally, rather than leaning on Nexus in the
 way
  you are trying to do.
 
  I personally also prefer no snapshot deps ever outside the reactor, as it
  will result in irreproducible builds. My group actually wrote an enforcer
  rule to detect exactly that situation; it is part of the
  scijava-maven-plugin. Happy to elaborate if you are interested.
 
  -Curtis
  On Jul 22, 2015 8:47 AM, Ron Wheeler rwhee...@artifact-software.com
  wrote:
 
   Glad you have found a solution even if I can not understand the source
 of
   the problem.
   It does not seem to a general problem which is why you have to develop
 a
   custom solution.
   This is a pretty big mailing list and attracts a lot of experienced
   developers and if there was a general solution, someone would have
 chimed
   in by now.
  
   Good luck.
   Ron
  
  
   On 22/07/2015 1:11 AM, David Hoffer wrote:
  
   Apparently our communication has broken down

Re: Fetch all remote dependencies NOT in my pom?

[Curtis Rueden]

Hi Kevin,

 What I want to do is just download all artifacts not in com.spinn3r.* “
 group ID.

Did you try:

mvn dependency:go-offline -DexcludeGroupIds=com.spinn3r ...

?

Regards,
Curtis

On Wed, Jul 22, 2015 at 10:50 PM, Kevin Burton bur...@spinn3r.com wrote:

 What I want to do is just download all artifacts not in com.spinn3r.* “
 group ID.

 They aren’t built yet or in any repositories yet.  This is for a continuous
 integration systems so I want to pre-cache them.  After this they’re just
 restored from cache to build faster.


  Is your repo on the same computer as the CI system?
 
 
 No.. different.


  Maven does cache dependencies locally after they are downloaded from your
  repo.
 

 Yes.  But this is a hosted CI build system (CircleCI) so everything is a
 container and wiped out each time.


 --

 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: How to delete certain snapshots from Nexus

[Curtis Rueden]

Hi Dave,

This problem strikes me as just a particular incarnation of make sure only
approved deps are used where old snapshot versions of 1st party modules
are no longer approved after a refactoring.

As such, I would suggest looking for tools intended to support such
dependency analysis more generally, rather than leaning on Nexus in the way
you are trying to do.

I personally also prefer no snapshot deps ever outside the reactor, as it
will result in irreproducible builds. My group actually wrote an enforcer
rule to detect exactly that situation; it is part of the
scijava-maven-plugin. Happy to elaborate if you are interested.

-Curtis
On Jul 22, 2015 8:47 AM, Ron Wheeler rwhee...@artifact-software.com
wrote:

 Glad you have found a solution even if I can not understand the source of
 the problem.
 It does not seem to a general problem which is why you have to develop a
 custom solution.
 This is a pretty big mailing list and attracts a lot of experienced
 developers and if there was a general solution, someone would have chimed
 in by now.

 Good luck.
 Ron


 On 22/07/2015 1:11 AM, David Hoffer wrote:

 Apparently our communication has broken down, it seems your not
 understanding the issue/question.



 I did find that Nexus does have an API we can use for this...I sure wish
 there was a more 'packaged' solution but I've discussed it with our IT
 department and between us I think we can solve this issue using that
 approach.  If anyone knows of a better solution please let me know.

 -Dave

 On Tue, Jul 21, 2015 at 10:32 PM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:

  If you have SNAPSHOTs specified, you will get SNAPSHOTs in the build.
 When you remove the SNAPSHOT from the parent, there should not be any way
 for a SNAPSHOT to be included.


 I am not sure where the SNAPSHOTS are being brought in to a x.x.x release
 unless you are allowing modules to specify the versions of their
 dependencies.
 Stop that.
 Modules should have no versions on an dependency unless it is a reference
 to a property in the parent.
 Modules should have no references to a version on a dependency that is
 one
 of the modules that your wrote - version${project.version}/version

 Ron


 On 21/07/2015 11:40 PM, David Hoffer wrote:

  I didn't say x.x.x is the only version in the parent.  I said it is a
 SNAPSHOT.  The version varies (of course) but in my prior example I said
 it
 was 1.0-SNAPSHOT.

 -Dave

 On Tue, Jul 21, 2015 at 9:36 PM, Ron Wheeler 
 rwhee...@artifact-software.com

  wrote:
 Where are the possible SNAPSHOT versions creeping into the build if
 x.x.x
 is the only versions in your parent and the dependencies do not have
 any
 versions (as I suggested).

 Ron


 On 21/07/2015 10:54 PM, David Hoffer wrote:

   Yes we use one version for all modules...comes from top level.  What
 I

 mean
 is this is a non-release build so by maven definition is a snapshot.
 E.g.
 x.x.x is built only once at release, x.x.x-SNAPSHOT is built on every
 CI
 build.

 -Dave

 On Tue, Jul 21, 2015 at 8:38 PM, Ron Wheeler 
 rwhee...@artifact-software.com

   wrote:

 On 21/07/2015 5:53 PM, David Hoffer wrote:

I'm not sure I understand your reply.  We use dependency
 management
 to

  specify versions (for both external  project dependencies), however
 that's
 not the issue, we have no problem specifying the version to use for
 both
 of
 those.  What is only in view here are the multi-module project
 dependencies
 and by definition they are all SNAPSHOTS as we have not released
 yet.

What do you mean by definition?

  If the modules use the parent version as their version, they will
 be
 SNAPSHOTS or releases depending on the parent pom having a version of
 x.x.x-SNAPSHOT or x.x.x.
 i.e. the module version is missing so that the parent's version is
 the
 version of the module.
 Any dependency in another module that is part of the project is set
 to
 version${project.version}/version
 dependency
groupIdcom.example/groupId
artifactIdanything-core/artifactId
version${project.version}/version
scopeprovided/scope
/dependency

 Ron




Let me give an example that might help.  The multi-module project
 is

  large
 and is growing...you start out with these modules (all the versions
 are
 1.0-SNAPSHOT).

 groupId=com.mycompany.myproject
 artifactId=artifactA, artifactB, artifactC, artifact1, artifact2,
 artifact3

 This has been building with your CI system for 1 month when you
 realize
 you
 really want these modules.

 groupId=com.mycompany.myproject
 artifactId=app-parent

 groupId=com.mycompany.myproject.service
 artifactId=artifactA, artifactB, artifactC

 groupId=com.mycompany.myproject.transform
 artifactId=artifact1, artifact2, artifact3

 This too builds fine, however in reality somewhere in this new build
 is
 a
 reference to
 com.mycompany.myproject:artifactA:1.0-SNAPSHOT...perhaps
 for
 an unpack goal.  The build is fine 

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

> 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: 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: 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: 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: "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: 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: 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: 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: 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: 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: 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 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 & 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: 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: 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: 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 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: 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: 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
> > > > >
> > > > >
> > > > > 
> -
> >