Re: Browsing Maven central buggy?

[John Patrick]

search.maven.org also has bugs often and sometimes misses releases in the
search index
also the new sonatype seams very slow and sluggish when trying to use and
often doesn't find things i would expect the previous search to find. i.e.
when using the fully qualified class search
in my view, we need to stop using central as a dumping group and have
something like linux, where it's index by java version or maven major/minor
version, so active projects republish, and dead ld dependencies can be
archieved, and if you need to mirror or proxy central it's a leaner
repository
John


On Wed, 24 Jan 2024 at 17:36, Manfred Moser  wrote:

> Well.. you cant really just show this video without pointing to more
> help. So to get started ...
>
> https://github.com/maveniverse/mima
>
> used with
>
> https://www.jbang.dev/
>
> Any other tips Tamas?
>
> Manfred
>
>
> On 2024-01-24 09:22, Tamás Cservenák wrote:
> > Or something like this:
> > https://asciinema.org/a/0dLOAfWxyxTg6zgcYSDX6FQwm
> >
> > ;)
> >
> > T
> >
> > On Wed, Jan 24, 2024 at 6:13 PM Manfred Moser 
> > wrote:
> >
> >> I suggest to use the maintained search and browse frontend from Sonatype
> >> instead.
> >>
> >> https://search.maven.org/ .. same as https://central.sonatype.com/
> >>
> >> And browse at https://central.sonatype.com/search
> >>
> >> It sits on top of the same data and is very nice indeed .. props to
> >> Brian Fox and team btw!
> >>
> >> Manfred
> >>
> >> On 2024-01-24 08:57, Tamás Cservenák wrote:
> >>> Howdy,
> >>>
> >>> Yes, this is a known problem, but it does not affect Maven, as it does
> >> not
> >>> "browse".
> >>> Basically you have to go directly to the directory you are looking for,
> >> and
> >>> not rely on HTML "index page" as that seems not maintained since a
> while.
> >>>
> >>> T
> >>>
> >>> On Wed, Jan 24, 2024 at 5:50 PM Thorsten Heit 
> >> wrote:
>  Hi,
> 
>  browsing Maven Central using a webbrowser seems, well, a bit buggy:
> 
>  In https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-bom/
>  for example I only see versions 2.x up to 2.22.0 and 3.0.0-alpha1
>  whereas 2.22.1 and 3.0.0-beta1 both exist; they are simply not
> visible.
> 
>  The same happens for a few other GAV coordinates such as
>  https://repo1.maven.org/maven2/org/apache/tika/tika-bom/3.0.0-BETA/
> or
> 
> 
> >>
> https://repo1.maven.org/maven2/me/qoomon/maven-git-versioning-extension/9.7.0
>  :
>  The directories exist, but one level above these versions are not
> shown.
> 
>  Is this a known problem?
> 
> 
>  Thorsten
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Can the jar plugin respect .gitignore?

[John Patrick]

my .gitignore includes target, so that would probably cause more issues
with the assembly plugin.


On Fri, 10 Nov 2023 at 21:34,  wrote:

> I think there are two issues with this, first of all git is not the only
> SCM, so why prefer it’s file.
>
> But secondly it is very common that binary result artifacts are git
> ignored and exactly the stuff you want to package. For example target/
>
> Are you thinking about -src archives, only?
>
> Having said that, supporting the file format and patterns might be a good
> idea (if it can be sorted out which directory level should be relevant) and
> having a easy way to enable .*ignore.
>
> Joseph Kessselman wrote on 10. Nov 2023 19:42 (GMT +01:00):
>
> > (Or, equivalently be told to take exclude list from a file in .gitignore
> > syntax and then be told .gitignore was that file.)
> >
> > If not, I'd consider that worth adding.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven slow

[John Patrick]

 Hi Tommy,

Maybe look at setting up
https://github.com/khmarbaise/maven-buildtime-profiler to see if you can
see where the time is being spent or not being spent.

On Thu, 6 Apr 2023 at 16:29, François Guillot 
wrote:

> Hi
>
> Disclaimer: I'm a engineer @ Gradle
>
> You can also try the Gradle Enterprise Maven extension (
> https://docs.gradle.com/enterprise/maven-extension/)
> Or the new Maven Cache extension
> https://maven.apache.org/extensions/maven-build-cache-extension/
> to benefit from build caching for some goal executions of your project.
>
> I won't dive here into a comparison between the two. Just wanted to share
> this for awareness.
>
> François
>
> Le jeu. 6 avr. 2023, 17:23, Mantas Gridinas  a écrit
> :
>
> > Well maven still has to go through all the lifecycle, which involves
> > generating resources, compiling, packaging, running tests, checking
> > snapshots, etc. So depending on your plugin, repository configuration you
> > could get faster/slower subsequent builds. Unlike gradle, maven doesn't
> > cache steps so the slowness is mostly due to having to go through the
> > lifecycle.
> >
> > As far as I remember, the mailing list mentioned the takari lifecycle
> which
> > changes a bit how maven works. You might want to experiment with it.
> > http://takari.io/book/40-lifecycle.html
> >
> >
> > On Thu, Apr 6, 2023, 18:15 Tommy Svensson  wrote:
> >
> > > Hello maven users,
> > >
> > > I have an observation that does not make sense to me:
> > >
> > > I have a multi module build of about 5 modules.
> > >
> > > I do an "mvn clean install" and it takes 43 seconds.
> > >
> > > I then do an "mvn install" and it takes 43 seconds !
> > >
> > > The second time everything was already built, so no compilation at all
> > > should have been done. So why does it still take 43 seconds ? I can do
> > "mvn
> > > install" over and over again and it takes 43 seconds. No diff between
> > "mvn
> > > clean install" and "mvn install" when everything is already built.
> > >
> > > Is the compile so extremely fast that it doesn't even take a second
> while
> > > everything else maven does takes 43 seconds ?
> > >
> > > I have a Mac M1 with 10 cores and 64 GB of memory (and no buss,
> processor
> > > and memory in same chip). The maven speed difference between my machine
> > and
> > > the work machine (Intel I5 2 cores and 8GB memory) doesn't really
> differ
> > > that much. That is with maven. For other things there is a big
> > difference.
> > >
> > > Is there any good explanation for this ? I have used maven for a very
> > long
> > > time and this is the first time I have noticed this. New faster
> machines
> > > have always improved build speed before.
> > >
> > > I'm running Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> > > That is what the latest version of IDEA gives me.
> > >
> > >
> > > BR,
> > > Tommy Svensson
> > >
> > >
> > >
> > >
> >
>

Polyglot usage of components/Dependency graph API

[Patrick Plenefisch]

Hi,
How can I query a specific dependency's *resolved* transitive dependencies
inside a class executed by a mojo? I have access to session and project,
and that's it.
I looked at DependencyGraphBuilder and the underlying
ProjectDependenciesResolver, but those seem to be injected. While I can
generate a class at runtime, I don't see how to access the injector even if
I have a class

The environment I'm running inside is JRuby inside
https://github.com/takari/polyglot-maven/blob/master/polyglot-maven-plugin/src/main/java/org/sonatype/maven/polyglot/plugin/ExecuteMojo.java
which is why I can't just use an @Inject annotation. But, being JRuby, I
can easily generate classes at runtime if necessary.

How can I go about this?

Thanks,

Patrick

Maven Wrapper merge issues during release

[John Patrick]

Anyone having issues with maven wrapper, when you upgrade the jar as part
of a release?

i.e.
develop branch
.mvn/wrapper/maven-wrapper.jar is 3.1.1

main branch
.mvn/wrapper/maven-wrapper.jar is 3.1.0

I'm using gitflow-maven-plugin (
https://github.com/aleksandr-m/gitflow-maven-plugin) but the merge fails as
the jar is being locked by the running process...

The solution i've got is to do manual commit to main with updated
maven-wrapper.jar, then try the release again.

Anyone else seen this issue or got a better work around?

John

Re: [ANN]switch from maven to gradle

[John Patrick]

Looking at the Snyk Java/JVM ecosystem report 2018 vs 2021, the usage of
Maven is growing still. But yes Gradle growth also grew over the same
period.

2018
- Maven 68%
- Gradle 16%

2021
- Maven 76%
- Gradle 38%

Sources;
https://snyk.io/blog/jvm-ecosystem-report-2018/
https://snyk.io/jvm-ecosystem-report-2021/

Their are also several posts of people moving back to Maven after migrating
to Gradle, see;
https://phauer.com/2018/moving-back-from-gradle-to-maven/

Also I think build tooling is, love it or hate it. I've tried Gradle a few
times but keep coming back to Maven. You get this constantly with lots of
Languages, when will X die, when will Y replace X. Usually people doing
click bate, but after those initial posts they go quite...

John
Maven user since 2004
- It has issues but I prefer these issues over Gradle's.


On Tue, 14 Jun 2022 at 20:59, Andres Almiray  wrote:

> Hi Manuel, welcome to the list.
> Please find answers inlined.
>
> Sent from my primitive tricorder
>
> > On 14 Jun 2022, at 20:10, Manuel Dahmen  wrote:
> >
> > hello,
> > switch from maven to gradle, publish on maven central, is it possible
> from
> > maven?
>
> Yes, it’s possible to switch a project built with Maven to be built with
> Gradle instead. Both build tools offer similar capabilities yet in
> different fashions.
>
> To be fair there’s no 100% automatic, fool-proof way to translate a Maven
> project into a Gradle one due to differences in their models and how
> plugins work. You can try invoking “gradle init” at the root of your
> project then manually edit the generated Gradle files til you get wat you
> need. For this to work you need to know Gradle well.
>
> Gradle can publish artifacts to Maven Central, there are 3rd party plugins
> that take care of that, of which the most popular appears to be
> https://plugins.gradle.org/plugin/io.github.gradle-nexus.publish-plugin
>
> > when will maven be replaced by gradle?
>
> That’s a very broad question but the answer is likely never. If the
> intention of the question is to find out if Maven will be replaced as the
> dominant build tool then the answer is no, not going to happen any time
> soon. An organization/company may deem necessary to make the switch which
> takes lots of effort, there’s no “try me” option, you must complete the
> switch to the best of your abilities in order to measure if making the
> switch was worth it. Chicken-egg problem.
>
> > I m trying to implement a Java desktop /android app. with a common
> library.
> > The basic idea is to name a class or interface wrapper with custom
> > implementations. which are not treated by jdk or Android sdk, I think.
> > But ui are custom too, like  ImageIO or Bitmap, awt Color and android
> Color.
>
> If you’re building a multi-project build with at least one Android
> component then that means you must use Gradle. Why bring Maven into the mix?
>
> > I think it s complicated, where could I find resources on this theme?
>
> Most likely at the Gradle doc site. Also, join their Slack and/or forum to
> ask questions.
>
> > -- sorry for my poor English
>
> You’re doing great!

Re: Determine Maven Dependencies after a build

[John Patrick]

I don't think you can.
The only way would be to use metadata from those GAV and see when it was
released/deployed.
Of if your don't use use " -ntp,--no-transfer-progress" AND a new workspace
per build AND have that log, then you would see what if downloads.
Or you use a local/company repository manager like nexus and still have the
access logs.
Of your creating a artifact which includes it's dependencies, then either
check the dependency checksum or jar metadata

But gut tells me you can't.

John


On Wed, 13 Apr 2022 at 19:26, Creager, Greg 
wrote:

> I am trying to reproduce a build that was done a week ago. Our maven pom
> files use range in many places ([1.0,1.1), when I go look at the pom of the
> published project, it just shows the range, not the actual version chosen:
>
> Published pom:
> 
>com.hp.cp.dfe.shared
>common-types
>[1.0,1.1)
> 
>
>
> How do I determine exact versions of dependencies used in a prior build?
> In Apache ivy the published ivy.xml shows the exact version chosen, I was
> expecting maven to have the same and I am assuming I just am not using the
> right util.
>

Re: Remove SNAPSHOT from all sub-modules, but honor version

[John Patrick]

Try https://github.com/aleksandr-m/gitflow-maven-plugin
So for me dropping the -SNAPSHOT would mean I'm creating a gitflow release
branch for testing, which would be as simply using that plugin as `mvn
gitflow:release-start`.
Not tried it with different modules having different version so it might
not work.
Personally everything in the same repo having the same version number I
find easier, so if you want different modules with different versions then
I would put them if separate repositories.
Cheers,
John


On Sat, 2 Apr 2022 at 11:14, Mantas Gridinas  wrote:

> From what I gather you want versions plugin by mojohaus. "Set" goal has
> flag for removing snapshot declarations as -DremoveSnapshot.
>
> https://www.mojohaus.org/versions-maven-plugin/
>
> On Sat, Apr 2, 2022, 11:32 Mike Deitrick  wrote:
>
> > Any guidance on this matter?
> >
> > On Fri, Mar 4, 2022, 7:53 AM Mike Deitrick 
> > wrote:
> >
> > > Hello,
> > >
> > > A couple days ago I submitted a question on Stack Overflow about this
> > > topic. It can be found here
> > > <
> >
> https://stackoverflow.com/questions/71329400/remove-snapshot-from-all-maven-sub-modules-but-honor-version
> > >.
> > > For the purposes of preserving this conversation, I will also provide
> my
> > > question below, along with some things I've found along the way. The
> > > commenter mentioned that the version of all modules within a
> multi-module
> > > project should be the same to drop -SNAPSHOT with the mvn versions:set
> > command.
> > > Furthermore, a section in the POM file title Aggregation (or
> > Multi-Module)
> > >  seems
> to
> > > provide some insight into what's going on, but my inferences might be
> > > incorrect about versions needing to be consistent based on the content
> in
> > > that section.
> > >
> > > So, what is the official practice for versions of sub-modules in a
> > > multi-module project? Should all versions be the same as the version in
> > the
> > > parent POM? If it's acceptable for sub-module versions to be different,
> > how
> > > does one accomplish stripping -SNAPSHOT from all modules (preferably
> > with a
> > > Maven plugin versus running commands to iterate over all
> sub-directories
> > to
> > > find child POMs and drop -SNAPSHOT from each)?
> > >
> > > Thank you.
> > > Mike
> > >
> > > ---
> > >
> > > I am working on a multi-module project. For the purposes of this
> exercise
> > > we can assume there are two sub-modules. The articles Maven Simple
> > > Project Archetype
> > >  and
> Create
> > > an archetype from a multi-module project
> > > <
> >
> https://maven.apache.org/archetype/maven-archetype-plugin/examples/create-multi-module-project.html
> >
> > can
> > > be referenced to follow along.
> > >
> > > Parent - 1.0.0-SNAPSHOT
> > > ChildA - 1.2.3-SNAPSHOT
> > > ChildB - 1.0.0-SNAPSHOT
> > >
> > > When I run mvn versions:set -D removeSnapshot -D processAllModules I
> > > expect the versions to change as indicated below.
> > >
> > > Parent - 1.0.0
> > > ChildA - 1.2.3
> > > ChildB - 1.0.0
> > >
> > > But, it seems -SNAPSHOT is stripped from all versions except the
> children
> > > that have a different version from the parent.
> > >
> > > Parent - 1.0.0
> > > ChildA - 1.2.3-SNAPSHOT
> > > ChildB - 1.0.0
> > >
> > > Is there any way to run the mvn versions:set command to honor the
> version
> > > number, while stripping the -SNAPSHOT postfix?
> > > --
> > >
> > > *UPDATE #1*
> > >
> > > Running mvn versions:set -D removeSnapshot=true yields the same results
> > > as running mvn versions:set -D removeSnapshot -D processAllModules.
> > >
> > > Parent - 1.0.0
> > > ChildA - 1.2.3-SNAPSHOT
> > > ChildB - 1.0.0
> > >
> > >
> >
>

Re: Getting the groupid, artifact id, and version of the package under test

[John Patrick]

I would do this via a profile, default value and surefire config, so
something like;


  
withJavaAgent

  -javaagent:C:\JARS\agent.jar

  


  


  maven-surefire-plugin
  
${myJavaAgent}
-DtheGroup=${project.groupId} -DtheArtifact=${project.artifactId}
  


Then if you want to override on the command line it's; mvn test
-DmyJavaAgent="-javaagent:C:\JARS\agent.jar"
Or; mvn test -PwithJavaAgent

John


On Wed, 30 Mar 2022 at 06:45, Laurian Angelescu 
wrote:

> I am working on a Java agent that instruments test suites and the code
> under test. The agent runs by invoking the following command on the command
> line:
>
> mvn test -DargLine="-javaagent:C:\JARS\agent.jar"
>
> The apache surefire plugin takes care of running the tests and pushing the
> -DargLine argument to the test JVM.
>
> But for hierarchical projects, I believe multiple JVMs are instantiated,
> one for each child package configured with pom.xml, as *mvn test *is
> recusively invoked downstream. I would like to keep track of each such
> child by capturing in mid-flight the group id, artifact id and version if
> it's available and passing this information into the agent.
>
> Is there a way to accomplish this data capture? Assume JUnit test suites.
>

Re: question java 1.7 support

[John Patrick]

Most people and use cases have the Java Home is the same version you put in
source/target/release.

The part I was trying to highlight was, if you set release and have Java
Home and Path to Java 1.7 (as the title of the email indicates), then it
won't work, so you need to use source and target.
If it was a type and the person has Java Home and Path set to Java 17, then
use release.

Also what I posted is the text from the maven compiler plugin.


On Sat, 26 Mar 2022 at 15:05, Alexander Kriegisch 
wrote:

> John Patrick schrieb am 26.03.2022 16:12 (GMT +07:00):
>
> > I thought maven.compiler.release only supports Java 9 and newer (The
> > -release argument for the Java compiler, supported since Java9).
>
> Small correction: The javac compiler option '--release N' exists since
> JDK 9, but you can also compile to older versions. A little overview,
> quickly compiled from what I happen to have installed locally (no 12):
>
>
> javac | --release
> --|--
>9  | 6-9
>   10  | 6-10
>   11  | 6-11
>   13  | 7-13
>   14  | 7-14
>   15  | 7-15
>   16  | 7-16
>   17  | 7-17
>   18  | 7-18
>
>
> BTW, most people around here probably know, but for those who do not:
> '--release N' is **not** the same as '-source N -target N', but also
> ensures that code is cross-compiled not just to the byte code level N
> like with '-target N', but also to the exact JDK API of that version -
> basically a more user-friendly way to set an older JDK as boot classpath
> for compilation, without the need to install extra JDKs or toolchains.
> Each JDK 9+ contains a compressed set of legacy API descriptions
> utilised by '--release N'.
>
> I.e., while the compiler option really just exists since JDK 9, you can
> still target certain older bytecode and/or JDK API versions. And if you
> need really old bytecode targets in a brandnew and well-maintained
> compiler, you can use ECJ. Current version 3.29.0 still supports source
> and target versions as old as 1.3 (and of course up to 18) - a unique
> selling point in comparison to Javac.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: question java 1.7 support

[John Patrick]

Alexander,
Your email says Java 1.7, your sdkman says 17 and your maven pom says 1.17.

I thought maven.compiler.release only supports Java 9 and newer (The
-release argument for the Java compiler, supported since Java9).

If you are wanting Java 1.7 (released July 2011) then use user properties;
1.7
1.7
also;
delete user property maven.compiler.release
from maven-compiler-plugin configuration, delete source and target.


If you want Java 17 (released September 2021), then use user property;
17
also;
delete user property maven.compiler.source
delete user property maven.compiler.target
from maven-compiler-plugin configuration, delete source and target.

John


On Sat, 26 Mar 2022 at 04:11, Olivier Lamy  wrote:

> On Sat, 26 Mar 2022 at 2:06 pm, Nils Breunese  wrote:
>
> > Olivier Lamy  wrote:
> >
> > > should be 1.7 not 1.17 ;)
> >
> > No, 1.7 is for Java 7. For Java 17 it should be just 17.
>
>
> The email subject says “ question java 1.7 support”
> But yeah should be simply 17
> Use release flag rather than sources and target
>
> >
> >
> > Nils.
> >
> > > On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> > > alexander.ushakov.em...@gmail.com> wrote:
> > >
> > >> Hello!
> > >>
> > >> I am trying to play with Apache Kafka and craft next pom.xml
> > >>
> > >> ```xml
> > >>
> > >>  > >> xmlns="http://maven.apache.org/POM/4.0.0";
> > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > >> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> > >>   4.0.0
> > >>   streams.examples
> > >>   streams.examples
> > >>   0.1
> > >>   jar
> > >>   Kafka Streams Demo Application
> > >>   
> > >>
> UTF-8
> > >>  3.1.0
> > >>  1.7.7
> > >>  1.2.17
> > >>  1.17
> > >>   
> > >>   
> > >>  
> > >> apache.snapshots
> > >> Apache Development Snapshot Repository
> > >> 
> > >> https://repository.apache.org/content/repositories/snapshots/
> > >> 
> > >>false
> > >> 
> > >> 
> > >>true
> > >> 
> > >>  
> > >>   
> > >>   
> > >>  
> > >> 
> > >>org.apache.maven.plugins
> > >>maven-compiler-plugin
> > >>3.1
> > >>
> > >>   1.17
> > >>   1.17
> > >>
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >>  
> > >>   
> > >>   
> > >>  
> > >> org.apache.kafka
> > >> kafka-streams
> > >> ${kafka.version}
> > >>  
> > >>  
> > >> org.slf4j
> > >> slf4j-api
> > >> ${slf4j.version}
> > >>  
> > >>  
> > >> org.slf4j
> > >> slf4j-simple
> > >> ${slf4j.version}
> > >>  
> > >>   
> > >>
> > >> ```
> > >>
> > >> command
> > >>
> > >> ```sh
> > >> mvn clean package
> > >> ```
> > >>
> > >> results with error
> > >>
> > >> ```
> > >> [ERROR] Failed to execute goal
> > >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> > >> (default-compile) on project streams.examples: Fatal error compiling:
> > >> error: invalid target release: 1.17 -> [Help 1]
> > >> ```
> > >>
> > >> Java and Maven has been installed through SdkMan. Java 17.
> > >>
> > >> Can someone, please, suggest the solution?
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Can't get Surefire to run any JUnit 5 tests

[John Patrick]

I've update my example with more of my setup
https://gist.github.com/nhojpatrick/e598205e23ff3ee226673d11bc339bf6

For your example you talk about suite, I've not used suite, based upon
jupiter and vintage, I would expect you would need to add
junit-platfore-suite-engine as a dependency so the suite engine enables and
scans for tests.

All integration tests end IT and for simplicity are under src/test/java,
all component/unit tests are also under src/test/java.

I've got both JUnit v4 and JUnit v5 unit tests and integration tests as I'm
migrating from one to the other when time allows.

I've got maven wrapper so I simply do;
./mvnw clean install

Before anyone comments, I don't do `./mvnw clean verify` because 90% of the
time it causes more issues with multimodule projects, normally when I need
to use `-rf,--resume-from`.

John



On Sun, 20 Mar 2022 at 00:45, David Karr  wrote:

> On Sat, Mar 19, 2022 at 5:06 PM Tibor Digana 
> wrote:
>
> > My advice is not to listen to everyone but rather understand how things
> > work.
> > Open this link in your browser
> > https://repo1.maven.org/maven2/org/junit/platform/
> > It is groupId of some JUnit5 artifacts.
> > Do you see junit-platform-suite-api?
> > Scroll up and you will see junit-platform-suite. What's that? It's the
> impl
> > of the api.
> > So, now you know what you miss in the dependencies.
> >
> > This way just discover the entire hierarchy in
> > https://repo1.maven.org/maven2/org/junit/ and the POMs and their
> > dependencies and transitive dependencies.
> > Then you would understand most of the typical troubles.
> > No magic, the trick is to read the content of the repo and the content of
> > POMs.
> >
> > I always have to do this when I am helping the users. All the time.
> > The job starts with this if it is a simple problem. Always the same, all
> > the time.
> >
>
> Ok, I appreciate that. However, perhaps I didn't emphasize the correct
> thing in my last response. Fixing the compile error was simple to do.  The
> last problem I have is the problem with running a component test suite from
> the command line. This is actually the first problem I was made aware of
> when I first started examining this entire functional area.
>
>
> > T
> >
> >
> >
> >
> > On Sat, Mar 19, 2022 at 10:57 PM KARR, DAVID  wrote:
> >
> > > This is progress.  I at least now see both Junit 5 and Junit 4 tests
> > > running successfully.
> > >
> > > I have a couple of related questions, one of which is likely entirely
> > > Junit-related, but which you might have run into, and the other is more
> > on
> > > Surefire.
> > >
> > > We also have some test suites, which is where we base our "component"
> and
> > > "integration" tests, neither of which run as unit tests.  I'm focusing
> in
> > > the component tests first, but I think whatever we do to fix the
> > component
> > > tests will be the same for the integration tests.
> > >
> > > With the dependencies you specified, that results in compile errors for
> > > missing classes in "org.junit.platform.suite.api.*".  That is in the
> > > "junit-platform-suite-api" dependency.  It's simple enough to include
> > that
> > > dependency, and that resolves that compile error.  I assume that's the
> > best
> > > resolution for that?
> > >
> > > Finally, the issue that is actually one of the first trouble spots we
> > > noticed, which is being able to execute test suites from the mvn
> command
> > > line.
> > >
> > > With Junit4, we would execute our component tests with just this:
> > >
> > > mvn -Dtest=ComponentTestSuite test
> > >
> > > With these new frameworks, this fails with "No tests were executed".
> I've
> > > tried numerous variations of this.
> > >
> > > The minimal class I have is this:
> > >
> > > import org.junit.platform.suite.api.SelectClasses;
> > > import org.junit.platform.suite.api.Suite;
> > >
> > > @Suite
> > > @SelectClasses(NoteResourceCT.class)
> > > public class ComponentTestSuite {
> > > }
> > >
> > > I have heard some mentions of "Tags" in Junit5 and "groups" in
> Surefire.
> > > I have experimented with those, but I still haven't gotten anything to
> > work.
> > >
> > > > -Original Message-
> > > > From: Tibor Digana 
> > > > Sent: Saturday, March 19, 2022 1:55 PM
> > > > To: Maven Users List 
> > > > Subject: Re: Can't get Surefire to run any JUnit 5 tests
> > > >
> > > > No problem, pls see the project again, there is an update.
> > > > T
> > > >
> > > > On Sat, Mar 19, 2022 at 9:32 PM KARR, DAVID  wrote:
> > > >
> > > > > One thing that I see I neglected to mention in this post, but
> which I
> > > > > did mention in the SO posting I linked to, is that I have both
> Junit5
> > > > > and
> > > > > Junit4 tests in scope.  I believe that is at least one element that
> > > > > makes this more complicated.
> > > > >
> > > > > > -Original Message-
> > > > > > From: Tibor Digana 
> > > > > > Sent: Saturday, March 19, 2022 1:27 PM
> > > > > > T

Re: Can't get Surefire to run any JUnit 5 tests

[John Patrick]

>From your stackoverflow post I move your your junit-jupiter-engine
dependency to a project dependency instead of a test dependency.
Eclipse is probably working as it's own IDE logic/dependencies/support, not
maven's.

I've also switched over to using the bom, so have config like.
https://gist.github.com/nhojpatrick/e598205e23ff3ee226673d11bc339bf6

I did have issues with surefire v2.x and early junit v5 but since surfire
v3.0.0-M2 I don't think I've had any issues.

John



On Sat, 19 Mar 2022 at 06:19, Dan Tran  wrote:

> may relate to this  https://issues.apache.org/jira/browse/SUREFIRE-2033
>
> -D
>
> On Fri, Mar 18, 2022 at 10:53 PM David Karr 
> wrote:
>
> > I, along with two other people on my team, have spent days and days now
> > trying to figure out why we cannot get Surefire to execute JUnit 5 tests.
> > We've all been working independently, so we don't all take the same path,
> > but it didn't really matter, as all three of us are pretty much stuck at
> > the same point.  We can execute JUnit 5 tests in Eclipse, but Surefire
> just
> > refuses to have anything to do with JUnit 5 tests.  We've all read
> numerous
> > threads and posts on how to do it, and it just does not work.
> >
> > Most recently, I posted this question with some details of what I had
> done
> > so far:
> >
> >
> https://stackoverflow.com/questions/71531001/why-is-surefire-not-executing-my-junit5-tests
> > .
> >
> > I have no idea whether the problems lie in JUnit 5, or in Surefire, or
> some
> > combination.  I wish I could get some debug output that told me
> SOMETHING.
> > It just does not run JUnit 5 tests.
> >
>

Re: maven cannot find symbol class EJBClientResult

[John Patrick]

Is this an old company project?
As maven-compiler-plugin is showing as v3.5.1 and that was released in Feb
2016.
Also the group id com.mypack is not in maven central so probably in an
internal company nexus or artifactory.
So you might need to search for someone who previous built it.

If you search for EJBClientResult.java within your structure do you find it?

Does `mvn clean verify -DskipTests` work? as it might be it's within a
module of your parent project.

John



On Sun, 6 Mar 2022 at 16:06, albert kao  wrote:

> My codes has these compile errors:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
> (default-compile) on project proj2-war: Compilation failure: Compilation
> failure:
> [ERROR]
>
> /C:/proj2/proj2-parent/proj2-war/src/main/java/com/mypack/web/common/MyClass.java:[220,340]
> cannot find symbol
> [ERROR] symbol: class EJBClientResult
> [ERROR] location: package mypack.ejb.myproj2
>
> when running
>
> cd C:\proj2\proj2-parent
> mvn clean compile
>
>
>
> The missing EJBClientResult class is in the mypack.common-2021.03.jar file.
>
> Another similar project which use the same jar file compile successfully.
>
> cd C:\proj1\proj1-parent
> mvn clean compile
>
> so the same jar file is present in my maven local repository and maven is
> setup properly.
>
> I had done a "mvn clean install" for both projects.
>
> To debug, run
>
> mvn -X clean compile
>
>
> proj1-parent output:
>
> [DEBUG] com.mypack:mypack.common:jar:2021.03:compile
>
> [DEBUG] Adding URL
>
> [file:/C:/Users/ak/.m2/repository/com/mypack/mypack.common/2021.03/mypack.common-2021.03.jar]
>
> [DEBUG] (f) classpathElements
>
> C:\Users\ak\.m2\repository\com\mypack\mypack.common\2021.03\mypack.common-2021.03.jar
>
> BUILD SUCCESS
>
>
> proj2-parent output:
>
> [DEBUG] com.mypack:mypack.common:jar:2021.03:compile
>
> [DEBUG] (f) classpathElements
>
> C:\Users\ak\.m2\repository\com\mypack\mypack.common\2021.03\mypack.common-2021.03.jar
>
>
> [ERROR]
>
> /C:/proj2/proj2-parent/proj2-war/src/main/java/com/mypack/web/common/MyClass.java:[220,340]
> cannot find symbol
> [ERROR] symbol: class EJBClientResult
> [ERROR] location: package mypack.ejb.myproj2
>
>
>
> Both projects have the same dependency in the pom.xml:
>
> 
> com.mypack
> mypack.common
> 2021.03
> 
>
>
>
> How to fix this compile error?
> Please help.
> Thanks.
>

Re: Run all tests (also in dependent modules), fail build at end

[John Patrick]

So yes, using -Dmaven.test.failure.ignore=true changes the exit code from 1
to 0. So if your linking commands you might not spot a previous command
actually silently errored.
As I want jenkins to fail at that step, and not progress to subsequent
steps. Not point wasting computing resources once all compile issues are
know and all tests issues for tests that could be execute are known.
I could probably configure another plugin to parse the output and detect
that no tests have failed, but decided not to investigate that.
John

On Sat, 26 Feb 2022 at 11:41, Falko Modler  wrote:

> John, is there a reason why you don't use
> -Dmaven.test.failure.ignore=true? This has been my Jenkins setup for
> years and with that I don't need two mvn runs.
>
> Apart from that I can relate to Alexander's use case in that locally you
> simply don't have those Jenkins reporting tools, telling you which tests
> failed overall.
> This can be rather annoying, especially when building in parallel, as
> test result will be all over the place.
>
> I'm not convinced though that this should be a general mvn flag.
> Ideally, surefire chould provide something for that (e.g. an extension).
> Next best thing is a separate extension, which I think was discussed
> here before.
>
> Cheers,
>
> Falko
>
> Am 26.02.2022 um 12:18 schrieb John Patrick:
> > So I understand the option, but for the average developer understanding
> the
> > intermixed output might be a nightmare. If someone is building the code
> > they can just do -SkipTests and -fae, fix those, then go back to run the
> > tests.
> >
> > I do a similar setup on Jenkins, with this kind of Jenkinsfile structure;
> >
> > try {
> >withEnv(...)
> >  configFileProvider(...)
> >try {
> >  ./mvnw clean install -DskipTests -fae
> >} finally {
> >  ./mvnw verify -fae
> >}
> >  }
> >}
> > } finally {
> >recordIssues enabledForFailure: true, tools: [mavenConsole()]
> >recordIssues aggregatingResults: true, enabledForFailure: true, tools:
> > [java(pattern: '**/src/main/java/**')]
> >recordIssues aggregatingResults: true, enabledForFailure: true, tools:
> > [junitParser(pattern:
> > '**/target/failsafe-reports/*.xml,**/target/surefire-reports/*.xml')]
> > publishCoverage adapters:
> > [jacocoAdapter('**/target/site/jacoco/jacoco.xml')]
> > }
> >
> > - Every compile error is captured assuming it's dependencies compile
> > - Every test is execute where the module builds
> > - Report issues and coverage for everything that executed
> >
> > John
> >
> >
> > On Sat, 26 Feb 2022 at 10:37, Delany  wrote:
> >
> >> I understand your use case Alex, just not your process. As this is the
> >> users list Im not about to solve the issue of a missing
> --fail-all-at-end
> >> switch, but I could try to think of workarounds.
> >> Delany
> >>
> >>
> >> On Sat, 26 Feb 2022 at 09:32, Alexander Kriegisch <
> >> alexan...@kriegisch.name>
> >> wrote:
> >>
> >>> Delany,
> >>>
> >>> you are completely misunderstanding my use case. I am building with
> >>> every push, that is the pain, because I have a choice to
> >>>
> >>>-- either see all test results with '-fn' but get a wrong build
> result
> >>>   (passed)
> >>>
> >>>-- or fewer test results with '-fae' and a correct build result
> >>>   (failed).
> >>>
> >>> I do *not* wish to run tests in a later phase. I have no idea where you
> >>> got that idea from. I simply want the build to continue for modules
> >>> dependent on ones with failing tests, so I can find out if they build
> >>> successfully and whether or not they also have failing tests. Then in
> >>> the end, after all modules have been built and all tests run (for those
> >>> modules which could actually be built without compile errors, of
> >>> course), I want to see an overall test result and a properly failed
> >>> build. In plain English: I want what '-fae' always should have done to
> >>> begin with. I really don't know what is so difficult to understand
> about
> >>> this simple requirement: build as much as possible, test as much as
> >>> possible, then report the correct result at the end. I want failed
> tests
> >>> to fail the build in the end, but I do

Re: Run all tests (also in dependent modules), fail build at end

[John Patrick]

So I understand the option, but for the average developer understanding the
intermixed output might be a nightmare. If someone is building the code
they can just do -SkipTests and -fae, fix those, then go back to run the
tests.

I do a similar setup on Jenkins, with this kind of Jenkinsfile structure;

try {
  withEnv(...)
configFileProvider(...)
  try {
./mvnw clean install -DskipTests -fae
  } finally {
./mvnw verify -fae
  }
}
  }
} finally {
  recordIssues enabledForFailure: true, tools: [mavenConsole()]
  recordIssues aggregatingResults: true, enabledForFailure: true, tools:
[java(pattern: '**/src/main/java/**')]
  recordIssues aggregatingResults: true, enabledForFailure: true, tools:
[junitParser(pattern:
'**/target/failsafe-reports/*.xml,**/target/surefire-reports/*.xml')]
   publishCoverage adapters:
[jacocoAdapter('**/target/site/jacoco/jacoco.xml')]
}

- Every compile error is captured assuming it's dependencies compile
- Every test is execute where the module builds
- Report issues and coverage for everything that executed

John


On Sat, 26 Feb 2022 at 10:37, Delany  wrote:

> I understand your use case Alex, just not your process. As this is the
> users list Im not about to solve the issue of a missing --fail-all-at-end
> switch, but I could try to think of workarounds.
> Delany
>
>
> On Sat, 26 Feb 2022 at 09:32, Alexander Kriegisch <
> alexan...@kriegisch.name>
> wrote:
>
> > Delany,
> >
> > you are completely misunderstanding my use case. I am building with
> > every push, that is the pain, because I have a choice to
> >
> >   -- either see all test results with '-fn' but get a wrong build result
> >  (passed)
> >
> >   -- or fewer test results with '-fae' and a correct build result
> >  (failed).
> >
> > I do *not* wish to run tests in a later phase. I have no idea where you
> > got that idea from. I simply want the build to continue for modules
> > dependent on ones with failing tests, so I can find out if they build
> > successfully and whether or not they also have failing tests. Then in
> > the end, after all modules have been built and all tests run (for those
> > modules which could actually be built without compile errors, of
> > course), I want to see an overall test result and a properly failed
> > build. In plain English: I want what '-fae' always should have done to
> > begin with. I really don't know what is so difficult to understand about
> > this simple requirement: build as much as possible, test as much as
> > possible, then report the correct result at the end. I want failed tests
> > to fail the build in the end, but I do not want them to keep dependent
> > modules from being built and tested.
> >
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> >
> >
> > Delany schrieb am 26.02.2022 14:17 (GMT +07:00):
> >
> > > Oh its not, im just being thorough.
> > > It just seems like your build iteration isn't frequent enough. If
> you're
> > > not building on every MR/PR or with every push, maybe you need a
> separate
> > > test build. Or maybe your reactor is too large and you need to split it
> > > into separate projects. You could also leave the reactor but build via
> a
> > > script that looks for pom files and tests them one at a time. Ugly, but
> > > effective.
> > > Bottom line is that install and deploy phases don't create dependencies
> > > within a reactor, so its no biggy that they delay their execution until
> > > after. Anything that happens before then does, and its not unreasonable
> > to
> > > expect development to work within that constraint.
> > > Delany
> > >
> > >
> > > On Fri, 25 Feb 2022 at 19:40, Alexander Kriegisch <
> > alexan...@kriegisch.name>
> > > wrote:
> > >
> > >> Thanks for digging, Delany. However, I am failing to see how this is
> > >> meant to solve my problem. Could you elaborate, please?
> > >> --
> > >> Alexander Kriegisch
> > >> https://scrum-master.de
> > >>
> > >>
> > >> Delany schrieb am 25.02.2022 18:05 (GMT +07:00):
> > >>
> > >> > Alexander, here it is: https://github.com/raydac/mvn-finisher
> > >> > Delany
> > >> >
> > >> > On Mon, 7 Feb 2022 at 08:17, Delany 
> > wrote:
> > >> >
> > >> >> Someone already wrote an "at end maven plugin". I used it for a
> while
> > >> but
> > >> >> removed it. Can't for the life of me find it in
> > >> >> github/google/confluence/git log. Sorry!
> > >> >> Delany
> > >> >>
> > >> >>
> > >> >> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch <
> > >> alexan...@kriegisch.name>
> > >> >> wrote:
> > >> >>
> > >> >>> >> In case you are ready to make you own plugin, it is relatively
> > easy.
> > >> >>>
> > >> >>> I am not, Lasse. I also want this to work on the command line and
> > not
> > >> >>> depend on CI-system-specific workarounds. But thank you for your
> > >> >>> insightful ideas, I really appreciate them.
> > >> >>>
> > >> >>> Tibor, actually I wanted to avoid a potentially lengthy debate on
> > basic
> > >> >>> principles, but I agree on havin

Re: How do you get "import in3.*;" to work in a Java program when using Maven?

[John Patrick]

So what I can tell is the documentation got change on 18 Dec 2019 to
mention maven. But the project has never published it into maven
central.

It also looks like it now uses gradle to build and from what I'm aware
of gradle it doesn't have anything configured to even publish.


On Sun, 17 Jan 2021 at 22:35, Alub Quinata  wrote:
>
> Yes, I tried that.  It did not work.
> 
> From: Martin Gainty 
> Sent: Sunday, January 17, 2021 5:05 PM
> To: Maven Users List 
> Subject: Re: How do you get "import in3.*;" to work in a Java program when 
> using Maven?
>
> did you try simplifying version to numeric version
> 2.5.4 ?
>
> 
> From: Alub Quinata 
> Sent: Sunday, January 17, 2021 4:46 PM
> To: users@maven.apache.org 
> Subject: How do you get "import in3.*;" to work in a Java program when using 
> Maven?
>
> I have a working pom.xml file, and I want to use Incubed in3.  I added these 
> lines to my Maven pom.xml file:
>
> 
>   it.slock
>   in3
>   v2.5.4
> 
>
>
> I was trying to follow the directions here: 
> https://github.com/blockchainsllc/in3/packages/72045?version=v2.5.4
>
> I tried different versions of in3 too.  Whenever I ran "mvn install", I got 
> an error like this:
>
> Could not resolve dependencies for project org.foobar:jar:0.1.0: Could not 
> find artifact it.slock:in3:jar:2.5.4 in central 
> (https://repo.maven.apache.org/maven2)
>
> I looked on different Maven repositories for "in3" or "it.slock", but I could 
> not find anything.  How do you use pom.xml to build in3 for Java?

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

Re: Maven 3.6.3 configuration enquiry

[John Patrick]

I use https://github.com/takari/maven-wrapper which is being adopted
and merged into maven as a core plugin as part of maven v3.7.0.

For me it allows each git commit to control what version of maven to
use, the developer and cicd for the same commit will be using the same
version of maven as they will both be building using mvnw.

Setup your maven wrapper for 3.3.9, change your cicd to use mvnw,
check it all works with 3.3.9.
Create a new branch and update maven wrapper to use 3.6.3 (simple
properties file change aka "mvn -N io.takari:maven:0.7.7:wrapper
-Dmaven=3.6.3"), commit and push, check your cicd still passes and
then merge into your develop/main branch.
Need to check or test an older commit or release, checkout that
branch/tag/commit because your using mvnw you don't need to remember
what version of maven was needed to build it as source control and
mvnw will handle it for you.

Some people have mention issues with some maven plugins when using the
maven wrapper, I've not had any issues in the 4 years I've been using
the takari maven wapper. But I don't use the maven release plugin, I
currently use https://github.com/aleksandr-m/gitflow-maven-plugin.

John

On Thu, 7 Jan 2021 at 21:51, Bernd Eckenfels  wrote:
>
> This (setting automatically of M2_HOME) does not work in all cases, 
> especially not if the launch script is not used (IDE or Maven Agents), but it 
> would be best to not set it, if not needed (agreed).
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Jörg Schaible 
> Gesendet: Thursday, January 7, 2021 10:38:45 PM
> An: Maven Users List 
> Betreff: Re: Maven 3.6.3 configuration enquiry
>
> Am Donnerstag, 7. Januar 2021, 20:23:27 CET schrieb Bernd Eckenfels:
> > You did not say what build servers you use, but normally you can have many
> > different maven versions installed in different directories. Usually CI
> > servers are fine to pick one (some like Jenkins can even install them
> > dynamically).
> >
> > If you do it, you need to watch out for not using/inheriting environment
> > variables (especially PATH, java and maven home), when using a user/global
> > settings.xml it should be valid for all versions (it usually is) or specify
> > a unique file for each environment with the -s flag. Also make sure to
> > specify the full path to the mvn launcher. Some plugins like maven release
> > plugin also prefer if you set the correct M2_HOME env variable.
>
> Best is not to set it at all. Then it is automatically set by the individual
> shell script that starts Maven (bin/mvn or bin/mvn.cmd) and will automatically
> point to the current Maven in use.
>
> [snip]
>
> Cheers,
> Jörg
>
>
>
>
> -
> 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: Reporting in maven. help please

[John Patrick]

Is this the documentation you said you are reading
https://maven.apache.org/plugins/index.html, as it has a reporting
section for maven maintained plugins.

but to highlight some, take a look at;
checkstyle https://maven.apache.org/plugins/maven-checkstyle-plugin/
pmd/cpd https://maven.apache.org/plugins/maven-pmd-plugin/
spotbugs (was findbugs) https://spotbugs.github.io/spotbugs-maven-plugin/

harder setup as requires installing separate tooling, and most overlap
with checkstyle, pmd and sportbugs in the free version.
sonarqube 
https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/

for your dependencies look at owasp and
https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html

If you're on github or bitbucket and are an open source project then
they have lots of both apps or integration tooling that can check
dependencies, code coverage. But if it's a closed private repo then it
will cost you something $$$ per month.

John

On Sun, 29 Nov 2020 at 17:47, Aitor Iturriondobeitia
 wrote:
>
> Hello
> i am new using maven and i am reading documentation.
> Can you say me which plugins can i use for reporting the code quality?
> any example?
> thanks

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

Re: Version ranges: bug or feature

[John Patrick]

Ranges can be used in released artifacts which I have done myself, but
it means you won't have reproducible builds. So be careful and be
aware if you use them...

>From your version range I assume you want any v6.7.x and newer but not
any v7.x release. So I would have done
[6.7.0,6.999.999)

I have used open source projects that got it wrong, so my project
worked for a few years then started due to a dependency getting ranges
wrong. So I was depending upon a v4.0.x implementation, then a v4.x.1
release was made and the v4.0.x implementation picked up the v4.1.x
api and they were not compatible so build failures.

To get around the speed if using version ranges etc... I have;
- stopped deploying snapshots into repositories
- each build workspace gets its own local repository
- if a project has dependencies, and the dependency has a branch of
the same name then it is built 1st so that SNAPSHOT version in the
workspace local repository. this save needing to deploy snapshots and
also needing to do extra releases

John

On Wed, 11 Nov 2020 at 00:06, Maxim Solodovnik  wrote:
>
> So ranges can't be used in release artifacts?
>
> I thought maybe `SNAPSHOT` in range will turn on some Maven magic
> and it will check snapshots in addition to releases ...
>
> On Wed, 11 Nov 2020 at 06:29, Tomo Suzuki 
> wrote:
>
> > I expect Maven to check all possible versions that match the range criteria
> > and to pick the highest one. (Sorry if I might not grasp your question)
> >
> > The suffixes (-SNAPSHOT) in version ranges do not work as a filter.
> > (Probably this is not the point?)
> >
> > The mentioned version strings (6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT and
> > 6.7.3-SNAPSHOT) are all higher than “6.7.0” and lower than
> > “7.0.0-SNAPSHOT“.
> >
> >
> > On Tue, Nov 10, 2020 at 10:34 Maxim Solodovnik 
> > wrote:
> >
> > > Thanks for the quick answer Tomo,
> > >
> > > According to out build logs (available for ex. here [1])
> > > `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions
> > in
> > > all snapshot repositories available
> > >
> > > so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked
> > ...
> > > Is this expected
> > >
> > >
> > >
> > https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFull
> > >
> > >
> > >
> > > On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki 
> > > wrote:
> > >
> > > > I avoid using version ranges because it introduces unexpected results
> > in
> > > > the dependency graphs.
> > > >
> > > > > [6.7.0,7.0.0-SNAPSHOT)
> > > >
> > > > I felt the intention of the range is the highest version before
> > > > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version).
> > > > As per [1], this range includes versions such as "7.0.0-alpha" and
> > > > "7.0.0-rc".
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> > https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
> > > > ,
> > > >
> > > >
> > > >
> > > > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik  > >
> > > > wrote:
> > > >
> > > > > Hello Maven experts,
> > > > >
> > > > > one sub-dependencies of our project has following
> > > > >   [6.7.0,7.0.0-SNAPSHOT)
> > > > > [1]
> > > > >
> > > > > as a result metadata for all available SNAPSHOT version is being
> > > checked
> > > > in
> > > > > all SNAPSHOT repositories
> > > > > this takes time
> > > > > (full story is here
> > https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0)
> > > > >
> > > > > this is reproducible using both local build and build at
> > > > > ci-builds.apache.org
> > > > >
> > > > > Is this expected behavior?
> > > > > Is it Ok to use range dependency with SNAPSHOT in release version of
> > > > > library?
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> > https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api-elements-6.15.0.pom
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Maxim
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Tomo
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Best regards,
> Maxim

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

Re: Maven Dependency Plugin

[John Patrick]

I'm out of the loop regarding the 3.7.0 release schedule so can't
answer that myself, you'll need to ask the developers mailing list.

The email about maven-wrapper-plugin v3.0.1 is this one from the
developers mailing list
https://lists.apache.org/thread.html/r7cb5dd04726af22f3c69092a7057e2674383deab09caf3fe80bef98e%40%3Cdev.maven.apache.org%3E

There are a few other emails about maven-wrapper-plugin and was an
issue with v3.0.0 which is why v3.0.1 was released.

I'm 99.999% sure it was only intended to work with v3.7.0 and newer
versions only, so feel free to raise a pr.

John

On Mon, 26 Oct 2020 at 11:33, Markus Karg  wrote:
>
> Thank you for this information. It is a bit misleading that the line says "as 
> introduced" (past tense) for a release that actually does not exist yet. 
> Would it be OK if I file a PR to clarify that? What is the anticipated 
> release date of Maven 3.7.0 that I could announce there?
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: John Patrick 
> Gesendet: Montag, 26. Oktober 2020 12:07
> An: Maven Users List 
> Betreff: Re: Maven Dependency Plugin
>
> If you read the opening line it talks about Maven 3.7.0, which is not yet 
> released.
>
> If you want to use a maven wrapper before v3.7.0, then use this 
> https://github.com/takari/maven-wrapper. The upgrade from takari to maven is 
> easy but does allow you to change your documentation, process and ci process 
> instead of waiting until v3.7.0.
>
> I did test the maven-wrapper-plugin a few months ago and I had to add a 
> staging repo of something like this before it worked 
> https://repository.apache.org/service/local/repositories/maven-XXX/content/.
> But can't remember what XXX it was as I've got ~10 in my settings.xml 
> commented out.
>
> John
>
> On Mon, 26 Oct 2020 at 10:53, Markus Karg  wrote:
> >
> > When I am using this plugin 
> > https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails 
> > because it apparently cannot find needed runtime files on Maven Central. 
> > This limitation is not told on that page. Is that a bug or am I doing 
> > something wrong?
> > -Markus
> >
> >
>
> -
> 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: Maven Dependency Plugin

[John Patrick]

If you read the opening line it talks about Maven 3.7.0, which is not
yet released.

If you want to use a maven wrapper before v3.7.0, then use this
https://github.com/takari/maven-wrapper. The upgrade from takari to
maven is easy but does allow you to change your documentation, process
and ci process instead of waiting until v3.7.0.

I did test the maven-wrapper-plugin a few months ago and I had to add
a staging repo of something like this before it worked
https://repository.apache.org/service/local/repositories/maven-XXX/content/.
But can't remember what XXX it was as I've got ~10 in my settings.xml
commented out.

John

On Mon, 26 Oct 2020 at 10:53, Markus Karg  wrote:
>
> When I am using this plugin 
> https://maven.apache.org/plugins/maven-wrapper-plugin/ then Maven fails 
> because it apparently cannot find needed runtime files on Maven Central. This 
> limitation is not told on that page. Is that a bug or am I doing something 
> wrong?
> -Markus
>
>

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

Re: Build with dependencies + debug in NetBeans in a single Maven invocation

[John Patrick]

So some quick feedback...

You mention maven is rather slow... It's taking me an average of 6
seconds for a command line 'mvn clean install' to build all 4 pom's.
I've got a MacBookPro (2013 model), 2.8 GHz Dual-Core Intel Core i7,
16GB Ram and SSD. I'm using Java 11.0.8 and Maven 3.6.3.

So debugging it within IntelliJ (Ultimate 2020.3 EAP version), I
loaded it as a Maven project. But simply running FileReadTestApp as an
Application and not via Maven, it was opening within 4-6 seconds... I
confirmed changes within JavaCommon were seen by FileReadTest, by
adding a System.out.println in the init method of UserPreferences, and
i saw the latest message i typed only seconds before in the console
output.

Regarding the gui builder you are using, not sure how to get that to
regenerate, but pure java code changes within IntelliJ are only taken
a matter of seconds for the latest changes to be seen and so used
within your app.

Installed NetBeans 12.1, it does feel very slow and sluggish. So
opening FileReadTestApp and selecting Run and it's taking 10-15
seconds before the maven output starts to appear then another 10-15
seconds before your gui appears, doing any changes to UserPreferences
are not picked up. Clicking Build with Dependencies, I'm seeing this;

No output for about 10 seconds
Maven takes about 10 seconds to build dependencies
No output for about 10 seconds
Maven takes about 10 seconds before exec and then another 5 seconds
and the gui appears.

So maybe use IntelliJ when editing java code and switch to NetBeans if
you need to change the gui...

John

On Wed, 21 Oct 2020 at 17:44, R. Diez  wrote:
>
>
> First of all, thanks for your answer.
>
> I did not get your e-mail, I only saw your answer in the mailing list 
> archive, so I hope the e-mail address I found for you somewhere else is the
> right one.
>
>
> > So execute [1] I believe is because you have checked "Build With
> > Dependencies" so it does a force rebuild of all projects
> > [...]
> > Why do you feel you need to do a forced rebuild? I'm sure NetBeans has
> > a compile on depend option. Did you have issues and then checking
> > "Build With Dependencies" fix that issue?
>
> That's correct. If I do not tick that option, then any changes to the common 
> library JavaCommon are not recompiled. So I am not debugging the latest
> source code state.
>
> I have no custom plug-ins, code generation or anything fancy. NetBeans just 
> does not rebuild dependencies automatically for Maven projects as far as I
> can tell. It is yet another reason to migrate away from NetBeans, but like I 
> said, I cannot do it yet because the projects are using the NetBeans GUI
> builder (Matisse). 8-(
>
>
> > [...]
> > Maven can execute the same command line goals to all projects in a
> > single innovation, but it can't execute different command line goals
> > to different projects in a single innovation. So you might need to use
> > a profile or something and push the exec into that profile and then
> > run the profile. So after it does the build, it then does the exec.
>
> That sounds a little complicated, given my very limited experience with Maven.
>
>
> > Might sound a strange question but why do you have to use exec to run
> > your application. If it's loaded into NetBeans as a maven project can
> > you just run the main class manually instead of via exec?
>
> I do not actually know. Those steps are what NetBeans does by default when 
> you create a new Maven project. I haven't figured out yet how NetBeans
> knows from the definition of such actions that a particular action wants to 
> debug and not just build, so it should actually connect the debugger. If
> it is documented at all, I haven't found it yet.
>
> But yes, I gather that it should be possible to start the debugger on the 
> build result without running Maven again. But NetBeans does not seem to
> offer the full flexibility to specify all command-line arguments to some 
> executable. The whole reason why I am using an IDE like NetBeans is that I
> wanted to just point and click! O8-)
>
>
> > Do you have a branch I can look at with your maven build and I'll look
> > it at when free to see if i can spot anything obvious, or push you maven 
> > wip.
>
> Yes, sorry that I forgot to push the changes. I have done it now:
>
> https://sourceforge.net/p/filereadtest/code/ci/master/tree/
>
> Thanks in advance for your help,
>rdiez

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

Re: Build with dependencies + debug in NetBeans in a single Maven invocation

[John Patrick]

Going to be rusty on NetBeans specific bits as not used for maybe 10+
years because it was slow and bugging from memory, switched to Eclipse
and then IntelliJ and not looked back.

So execute [1] I believe is because you have checked "Build With
Dependencies" so it does a force rebuild of all projects and execute
[2] is running your application.

Why do you feel you need to do a forced rebuild? I'm sure NetBeans has
a compile on depend option. Did you have issues and then checking
"Build With Dependencies" fix that issue?

Do you have custom plugins or code generation running on your project
as that would be the only reason I would force a rebuild.

Maven can execute the same command line goals to all projects in a
single innovation, but it can't execute different command line goals
to different projects in a single innovation. So you might need to use
a profile or something and push the exec into that profile and then
run the profile. So after it does the build, it then does the exec.

Might sound a strange question but why do you have to use exec to run
your application. If it's loaded into NetBeans as a maven project can
you just run the main class manually instead of via exec?

If you were using IntelliJ you would just need to do the exec as
everything would have been rebuild automatically as required. The only
limitation is if you have plugins or some kind of code generation
which wouldn't have been execute. I would also just execute the main
class or what ever exec is doing instead of going via a maven wrapper
for exec.

Do you have a branch I can look at with your maven build and I'll look
it at when free to see if i can spot anything obvious, or push you
maven wip.

John







On Tue, 20 Oct 2020 at 00:37, R. Diez  wrote:
>
> Hi all:
>
> I am migrating the following 2 Java applications and 1 "shared" library from 
> NetBeans Ant-based projects to Maven:
>
> https://sourceforge.net/p/filereadtest/code/ci/master/tree/
>
> I have noticed that Maven is rather slow, which bugs me (I am very impatient 
> for a part-time
> Java developer). I suspect the start-up costs are a big factor, and GraalVM 
> is probably not
> quite ready yet to replace the standard JVM.
>
> When I am writing code, I want to press a key in order to immediately start 
> the application
> under the debugger. All modified code, whether in the application or in the 
> common library,
> should be recompiled (if necessary). This is standard in most development 
> environments for
> most computer languages.
>
> So, after starting NetBeans, I went to the project settings, "Actions", 
> "Debug project" and ticked "Build With Dependencies".
>
> I then noticed in the output window that Maven actually runs twice:
>
> 1) [...] mvn -DskipTests=true --also-make --projects QuickDiskTest install
>
> 2) [...] mvn [...] process-classes 
> org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
>
> Is there a way to run Maven just once? Or does Maven not support building and 
> running (under a debugger) in a single invocation?
>
> Inside NetBeans, I could experiment with a new custom 
> BuildWithDependenciesAndDebug action,
> but there does not seem to be a way to fully control the command-line 
> arguments for an action. There are fields for goals, profiles and properties,
> but that is probably not enough. Or am I mistaken here?
>
> I am hoping that someone here could help me. I already posted this question 
> in the NetBeans mailing list, but nobody answered:
>
> http://mail-archives.apache.org/mod_mbox/netbeans-users/202009.mbox/%3C1652543010.678234.1601497297309%40mail.yahoo.com%3E
>
> I cannot migrate this project away from NetBeans yet, because I am using the 
> NetBeans GUI builder (Matisse) for the forms (see the .form files), which
> I guess is only available inside NetBeans.
>
> Thanks in advance,
>rdiez
>
> -
> 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: Need help with maven deploy plugin.

[John Patrick]

Which pom are properties beans.version and rest.version defined?

com.blah.nw.libraries:libraries:1.0.0 or it's parent?

Technically what you're deploying and using looks valid, the consumed
using them should resolve those dependencies and pick up your custom
version property and work it out dynamically.

I've just created a mini project and mine seems to be working how you
want it to do, but i'm deploying to a local directory and not into
artifactory/nexus.

Normally in a multi module project, I collate all dependency version
details into the root multi module parent pom under the
dependencyManagement section. So multi module children only define use
x but never use version y of x.

John

On Wed, 19 Aug 2020 at 08:01, Jai Sharma  wrote:
>
> I am trying to upload multiple jar files to artifactory using "mvn deploy" 
> command for a multi module project. Problem I am facing is generated pom 
> files uploaded with jar files to artifactory contains only property name as 
> version.
>
> Example - This is the part of jar file uploaded to artifactory for module 
> "configuration-entity".
> When i am using this as dependency in another project I am getting error 
> cannot resolve dependencies
> com.blah.infra.libraries:rest:jar:${rest.version}
> com.blah.infra.libraries:beans:jar:${beans.version}
>
> 
> 
>
> 4.0.0
>
> 
> com.blah.nw.libraries
> libraries
> 1.0.0
> 
>
> configuration-entity
>
> 
> 
> com.blah.infra.libraries
> rest
> ${rest.version}
> 
> 
> com.blah.infra.libraries
> beans
> ${beans.version}
> 
>
>
>
> -
> 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: How to disable certain enforcer rules in a child module in a multi-module maven project?

[John Patrick]

So something like the following if all configuration is managed via a
pluginMangement section;


  
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M2

  
alpha


  enforce


  


  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  
  
bravo


  enforce


  

  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  

  

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

  
alpha
validate
  

  


query/pom.xml


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

  
alpha

  
  
bravo
validate
  

  

  


you might also be able to do it via a property and in query define the
bravo execution instead of the alpha. I've used a similar technique
with maven-surefire-plugin, where i define the plugin version using a
property and have a default in the root/parent pom, and in one
specific child pom i define a different surefire version. so this
might work...


  
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M2

  
alpha


  enforce


  


  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  
  
bravo


  enforce


  

  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  

  

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

  
${which-enforcer-id}
validate
  

  


  alpha


query/pom.xml


  bravo


John


On Fri, 14 Aug 2020 at 11:23, Falko Modler  wrote:
>
> I agree that John's solution is more how Maven is expecting you to do things 
> in this case.
> But it is also more verbose in the submodules and it forces you to repeat 
> yourself (I really like the DRY principle), since you basically have to 
> redefine rules.
>
> For me it depends how much you want to manage/maintain centrally (in a root 
> parent or so) and how much you want override or redefine in the submodules.
>
> Sure, if the rule config is simple, redefinition won't hurt much but if you 
> have complex stuff, it can become painful to have those configs scattered 
> over multiple modules.
>
> Just my 2 cents.
>
> PS: Haven't checked, but theoretically you should also be able to prepare all 
> executions in pluginManagement, but set each phase to none. Then in each 
> concrete build plugins section you should then be able to bind the executions 
> you want/need to the right phase.
>
> -
> 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: How to disable certain enforcer rules in a child module in a multi-module maven project?

[John Patrick]

I would do the following snippet, not sure if phase is needed, not
sure if it should be pluginManagement, but i tend to put all
configuration in pluginManagement then only the usage in plugins.

For the query, from what I'm aware I used the same id of default, it
will override that execution from main and use the updated execution
in the query.

I've not had to do this override with enforcer before, but have had to
do something similar with the compiler plugin when building a project
in java 1.8 and 11 and 14.

What my pom's might look like, i've not tested this setup and it might
need some tweaking;

main/pom.xml


  
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M2

  
default
validate

  enforce


  


  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  

  

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


query/pom.xml


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

  
default
validate

  enforce


  

  [1.8,)
  *** This project requires
JDK 1.8/J2SE 8 or later. ***

  
  true

  

  


John

On Thu, 13 Aug 2020 at 11:13, Falko Modler  wrote:
>
> You could split your config into multiple executions and define a custom skip 
> property for each execution.
> In a submodule you could then skip the executions you don't want (or vice 
> versa) by adding the respective properties.
> Skipping all enforcer rules (e.g. for a "quick" local run) is more 
> complicated, but could be achieved if everything ia put in a profile that is 
> activated by default. You could then opt-out of it via -P!my-profile or 
> introduce yet another property for that.
>
> -
> 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: How maven repositories are resolved?

[John Patrick]

The answer depends on the following;

1) is it a release version or snapshot version. As if the release
version is in local repo then no remote repo's are checked.
2) order your pom's are executed

I've simplified your profiles with central repo and company repo, and
Aa, Ab and Ac are the same GAV but it's just so in the explanation
it's easier to know what A i'm talking about.

settings
- central repo (contains Aa)
- company repo (contains Ab)

parent-pom
- alpha
-- A
- bravo (has extra R repository like your cloudera, contains Ac)
-- A
- charlie
-- A

For release version assuming empty local repo.
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list
- Bravo needs A, it sees Aa in local repo and uses it
- Charlie needs A, it sees Aa in local repo and uses it

Same as before but maven believe build order is bravo, alpha, charlie,
i.e. you've changed an internal dependency or reorder you modules
section.
- Bravo needs A, and Ac is downloaded as it's in R repo and that was
1st repo in the order list, which i think it's pom repo's then parent
pom's then settings file.
- Alpha needs A, it sees Ac in local repo and uses it
- Charlie needs A, it sees Ac in local repo and uses it

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-1
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Aa is newer so Aa is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Aa is used.

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-2
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Ac is newer so Ac is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Ac is used.



As you can see it can get very messy when -SNAPSHOT's are being used
and different pom's have repo. This is my hands-on experience of trial
and error, debugging and troubleshooting of build processes.

Hope it was helpful.

John

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

Re: Maven Versions Plugin scans whole Maven repository

[John Patrick]

The maven project doesn't have a code maven versions plugin, mojohaus
formally codehaus has a versions-maven-plugin. Is that the plugin
you're talking about? And I've just noticed they point their users
mailing list to this maven users list.

1) What is the exact command line you are executing? something like this?

$ mvn org.codehaus.mojo:versions-maven-plugin:2.7:display-dependency-updates

2) How many repo's do you point to? via your pom.xml or settings.xml
As each repo will be checked separately which might be why the high
execution time. The maven central calls might be say 10 mins but due
to slow 'snapshots' it might take 50 mins.

3) Is the project public on github or similar? i.e. can i clone it
myself and run the same command to see how long it takes for me?

4) Do you have a slow or high latency internet connection? As your
email implices you might be in the Czech Republic. You might have a
25Mbps connection but if you have multiple users streaming 4K video
and saturating the bandwidth it won't help you.

5) What location does repo1.maven.org resolve to? e.g. ping
repo1.maven.org or nslookup repo1.maven.org. Then put the ip address
into say https://ipinfo.io/ and see if that host is local to you...
mine is resoling to a UK Data Center, yours might be going somewhere
silly and non local

6) Maybe setup a nexus oss on your home/office/work network to cache
this data closer.

7) See where the time is wasted,
https://github.com/khmarbaise/maven-buildtime-profiler would help
confirm where phases/goal/plugin is taking all the time, it might just
show you what you know, which is the versions plugin is taking all the
time.

Hope some of the above is helpful or points towards the problem.
Without knowing the exact command line you're using it is a little
hard to help more. Also without seeing your pom or settings.xml as
your output shows central and something called snapshots being polled.

John

On Sat, 11 Jul 2020 at 07:39, Lukáš Satin  wrote:
>
> Hi,
>
> Maven Versions Plugin scans whole Maven repository.
>
> It takes about 1 hour and scans everything from com.google.* and
> org.springframework.* plus other packages while they are nowhere in the
> pom.xml! There is only org.springbootframework.boot, org.apache.commons,
> com.oracle!
>
> I read all articles, FAQ.
>
> Why is this behavior? How to make it update only actual dependencies
> present in pom.xml and not some transitive stuff?
>
> [INFO] artifact com.google.api.grpc:proto-google-cloud-bigtable-v2:
> checking for updates from snapshots
> [INFO] artifact com.google.api.grpc:proto-google-cloud-billing-v1: checking
> for updates from central
> [INFO] artifact com.google.api.grpc:proto-google-cloud-billing-v1: checking
> for updates from snapshots
> [INFO] artifact com.google.api.grpc:grpc-google-cloud-billing-v1: checking
> for updates from central
> [INFO] artifact com.google.api.grpc:grpc-google-cloud-billing-v1: checking
> for updates from snapshots
> [INFO] artifact com.google.cloud:google-cloud-billing: checking for updates
> from central
> [INFO] artifact com.google.cloud:google-cloud-billing: checking for updates
> from snapshots
> [INFO] artifact
> com.google.api.grpc:grpc-google-cloud-billingbudgets-v1beta1: checking for
> updates from central
> [INFO] artifact
> com.google.api.grpc:grpc-google-cloud-billingbudgets-v1beta1: checking for
> updates from snapshots
> [INFO] artifact
> com.google.api.grpc:proto-google-cloud-billingbudgets-v1beta1: checking for
> updates from central
> [INFO] artifact
> com.google.api.grpc:proto-google-cloud-billingbudgets-v1beta1: checking for
> updates from snapshots
> [INFO] artifact com.google.cloud:google-cloud-billingbudgets: checking for
> updates from central
> [INFO] artifact com.google.cloud:google-cloud-billingbudgets: checking for
> updates from snapshots
> [INFO] artifact com.google.api.grpc:grpc-google-cloud-build-v1: checking
> for updates from central
> [INFO] artifact com.google.api.grpc:grpc-google-cloud-build-v1: checking
> for updates from snapshots
> [INFO] artifact com.google.api.grpc:proto-google-cloud-build-v1: checking
> for updates from central
> [INFO] artifact com.google.api.grpc:proto-google-cloud-build-v1: checking
> for updates from snapshots
> [INFO] artifact com.google.cloud:google-cloud-build: checking for updates
> from central

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

Re: How to download zip instead of jar from maven repo...

[John Patrick]

I meant Java 9 was 2017 not 2019.

The main reason I thought it was a Java 9 issue, was seeing this in
your stacktrace "java.base/java.lang.reflect.Constructor." so it was
showing module/classname.

I've come across lots of plugins that have had issues with Java 9 or
newer, so if something fails, I try it with Java 1.8, or see if a
newer version is available.

John


On Thu, 9 Jul 2020 at 19:55, John Patrick  wrote:
>
> Use Java 1.8 or older.
>
> Because the plugin was last released in 2015, and Java 9 was released
> in 2019, I suspect it doesn't support or handle modules correctly.
>
> I've just tried a simple project and I get the same stacktrace using
> Java 11, but it passes on Java 1.8.
>
> I tried this command line;
> $ mvn compile org.codehaus.mojo:codenarc-maven-plugin:0.22-1:codenarc
>
> Using these files;
> $ cat pom.xml
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> groupId
> artifactId
> 1
> 
>
> $ cat src/main/java/Example.groovy
> Console console=System.console();
> def name=console.readLine("What is your name? ")
> println "Welcome to Groovy, $name!"
>
> John
>
> On Thu, 9 Jul 2020 at 05:44, LINUS FERNANDES  
> wrote:
> >
> > Does anyone have a working Maven configuration for CodeNarc for groovy
> > scripts static analysis?
> > Much appreciated if you share the same.
> >
> > Else, I'll just have to forget about it.
> >
> > On Wed, 8 Jul 2020, 12:58 LINUS FERNANDES, 
> > wrote:
> >
> > > I tried adding the following dependencies to the plugin :
> > >
> > >org.codehaus.groovy
> > > groovy
> > > 3.0.4
> > > 
> > >   org.codehaus.groovy > > groupId>groovy-all > > artifactId>3.0.4
> > >   
> > >
> > > The first doesn't resolve it and the second fails because :
> > >
> > > plugin org.codehaus.mojo:codenarc-maven-plugin:0.22-1 or one of its
> > > dependencies could not be resolved: Could not find artifact
> > > org.testng:testng:jar:7.2.0 in central (
> > > https://repo.maven.apache.org/maven2)
> > >
> > > On Wed, 8 Jul 2020, 12:43 LINUS FERNANDES, 
> > > wrote:
> > >
> > >> I'm using Jdk 11.
> > >>
> > >> On Wed, 8 Jul 2020, 07:11 LINUS FERNANDES, 
> > >> wrote:
> > >>
> > >>> I get the following error for code narc version 0.16 and 0.17 as set in
> > >>> the configuration.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> ERROR: Unable to make
> > >>> jdk.internal.loader.ClassLoaders$AppClassLoader(jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.URLClassPath)
> > >>> accessible: module java.base does not "opens jdk.internal.loader" to
> > >>> unnamed module @7085bdee
> > >>>  [java] java.lang.reflect.InaccessibleObjectException: Unable to
> > >>> make
> > >>> jdk.internal.loader.ClassLoaders$AppClassLoader(jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.URLClassPath)
> > >>> accessible: module java.base does not "opens jdk.internal.loader" to
> > >>> unnamed module @7085bdee   [java] at
> > >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > >>>[java] at
> > >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > >>>[java] at
> > >>> java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:189)
> > >>>  [java] at
> > >>> java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:182)
> > >>>  [java] at
> > >>> org.codehaus.groovy.reflection.CachedConstructor$1.run(CachedConstructor.java:41)
> > >>>[java] at
> > >>> java.base/java.security.AccessController.doPrivileged(Native Method)
> > >>> [java] at
> &

Re: How to download zip instead of jar from maven repo...

[John Patrick]

Use Java 1.8 or older.

Because the plugin was last released in 2015, and Java 9 was released
in 2019, I suspect it doesn't support or handle modules correctly.

I've just tried a simple project and I get the same stacktrace using
Java 11, but it passes on Java 1.8.

I tried this command line;
$ mvn compile org.codehaus.mojo:codenarc-maven-plugin:0.22-1:codenarc

Using these files;
$ cat pom.xml

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
groupId
artifactId
1


$ cat src/main/java/Example.groovy
Console console=System.console();
def name=console.readLine("What is your name? ")
println "Welcome to Groovy, $name!"

John

On Thu, 9 Jul 2020 at 05:44, LINUS FERNANDES  wrote:
>
> Does anyone have a working Maven configuration for CodeNarc for groovy
> scripts static analysis?
> Much appreciated if you share the same.
>
> Else, I'll just have to forget about it.
>
> On Wed, 8 Jul 2020, 12:58 LINUS FERNANDES, 
> wrote:
>
> > I tried adding the following dependencies to the plugin :
> >
> >org.codehaus.groovy
> > groovy
> > 3.0.4
> > 
> >   org.codehaus.groovy > groupId>groovy-all > artifactId>3.0.4
> >   
> >
> > The first doesn't resolve it and the second fails because :
> >
> > plugin org.codehaus.mojo:codenarc-maven-plugin:0.22-1 or one of its
> > dependencies could not be resolved: Could not find artifact
> > org.testng:testng:jar:7.2.0 in central (
> > https://repo.maven.apache.org/maven2)
> >
> > On Wed, 8 Jul 2020, 12:43 LINUS FERNANDES, 
> > wrote:
> >
> >> I'm using Jdk 11.
> >>
> >> On Wed, 8 Jul 2020, 07:11 LINUS FERNANDES, 
> >> wrote:
> >>
> >>> I get the following error for code narc version 0.16 and 0.17 as set in
> >>> the configuration.
> >>>
> >>>
> >>>
> >>>
> >>> ERROR: Unable to make
> >>> jdk.internal.loader.ClassLoaders$AppClassLoader(jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.URLClassPath)
> >>> accessible: module java.base does not "opens jdk.internal.loader" to
> >>> unnamed module @7085bdee
> >>>  [java] java.lang.reflect.InaccessibleObjectException: Unable to
> >>> make
> >>> jdk.internal.loader.ClassLoaders$AppClassLoader(jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.URLClassPath)
> >>> accessible: module java.base does not "opens jdk.internal.loader" to
> >>> unnamed module @7085bdee   [java] at
> >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> >>>[java] at
> >>> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> >>>[java] at
> >>> java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:189)
> >>>  [java] at
> >>> java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:182)
> >>>  [java] at
> >>> org.codehaus.groovy.reflection.CachedConstructor$1.run(CachedConstructor.java:41)
> >>>[java] at
> >>> java.base/java.security.AccessController.doPrivileged(Native Method)
> >>> [java] at
> >>> org.codehaus.groovy.reflection.CachedConstructor.(CachedConstructor.java:39)
> >>>   [java] at
> >>> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:73)
> >>>  [java] at
> >>> org.codehaus.groovy.reflection.CachedClass$2.initValue(CachedClass.java:63)
> >>>  [java] at
> >>> org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
> >>>[java] at
> >>> org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
> >>>  [java] at
> >>> org.codehaus.groovy.reflection.CachedClass.getConstructors(CachedClass.java:257)
> >>> [java] at
> >>> groovy.lang.MetaClassImpl.(MetaClassImpl.java:192)
> >>> [java] at groovy.lang.MetaClassImpl.(MetaClassImpl.java:196)
> >>> [java] at
> >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createNormalMetaClass(MetaClassRegistry.java:149)
> >>>  [java] at
> >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.createWithCustomLookup(MetaClassRegistry.java:139)
> >>> [java] at
> >>> groovy.lang.MetaClassRegistry$MetaClassCreationHandle.create(MetaClassRegistry.java:122)
> >>> [java] at
> >>> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:165)
> >>>   [java] at
> >>> org.codeh

Re: shade plugin modifying string constants

[John Patrick]

>From the views of a another user, relocation should be dumb and should
be exact case sensitive for both pattern and shadedPattern. So I would
not expect PKG to be altered. Yes the output is what your pattern
match lists but but so does; System.out.println ("org.example" +
".pkg."); and I wouldn't expect that to be changed.

Based on your example would you have expect it to be replaced with
either A or B;
a) org.example.shaded.PKG
b) org.example.shaded.pkg

John

On Fri, 26 Jun 2020 at 07:30, Anurag Shekhar
 wrote:
>
> Hi
>
> I am trying to shade a package with following tags
>
> 
>  org.example.pkg
> org.example.shaded.pkg
> 
>
> I also have a string in one of my class which matches the pattern gets
>
> modified during shading
>
>  public static void main (String [] args) {
>  System.out.println ("org.example.pkg."); //prints
> org.example.shaded.pkg.
>  System.out.println ("org.example.PKG.".toLowerCase()); //prints
> org.example.pkg.
>  }
>
> Is this expected behavior ?
>
> I was thinking about making use of this behavior. Will it be safe to do so ?
>
> Or its something undocumented so might change without prior notice ?
>
>
> thanks
>
> Anurag
>
>
> -
> 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: My maven is trying to download artifacts from an incorrect repository

[John Patrick]

I would try building with a temporary local maven repo to see if
something got corrupt/wrong/incorrect in your user's repo, so i would
do;

$ mvn -Dmaven.repo.local=./mvn-repo clean install

that would for that execution download everything into a local
mvn-repo directory

if that works then your project and settings are fine and something is
corrupt/wrong/incorrect in your user's repo, and i would search for
central.maven.org in your users repo to see if i could spot the issue
and maybe then delete those files

if that fails i would create a dummy empty settings.xml so rule out
your users settings file so;

$ mvn -Dmaven.repo.local=./mvn-repo-local-settings -s ./settings.xml
clean install

if that works then something in the settings file picked up by default
is the issue

if that still fails then it's something in your project

or it's a dependency your downloading that has a repo hard coded

too many options to debug, hope some of the above helps

John


On Thu, 4 Jun 2020 at 00:24, Debashish Ghosh
 wrote:
>
> Hi,
>I am trying to run mvn install on a git hub project 
> https://github.com/hapifhir/org.hl7.fhir.core.git .
> I am using maven version 3.6.3 . The gist of the issue is that it tries to 
> download  maven-bundle-plugin  artifact from   
> http://central.maven.org/maven2/ . This repository doesn't exist so it keeps 
> giving error since the artifacts downloaded are empty error files.
>
> I tried changing the settings.xml to use repository 
> https://repo.maven.apache.org/maven2/ but it still keeps trying to get the 
> artifact from  http://central.maven.org/maven2/ . I don't even understand how 
> it gets a reference to that url.
> It keeps giving me the following error :
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for 
> C:\Users\debashish.ghosh\.m2\repository
> [INFO] Scanning for projects...
> [DEBUG] Using mirror remote-repos (https://repo.maven.apache.org/maven2) for 
> central (https://repo.maven.apache.org/maven2).
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for 
> https://oss.sonatype.org/content/repositories/snapshots
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
> https://oss.sonatype.org/content/repositories/snapshots
> Downloading from ossrh: 
> https://oss.sonatype.org/content/repositories/snapshots/org/apache/felix/maven-bundle-plugin/4.2.1/maven-bundle-plugin-4.2.1.pom
> [DEBUG] Writing tracking file 
> C:\Users\debashish.ghosh\.m2\repository\org\apache\felix\maven-bundle-plugin\4.2.1\maven-bundle-plugin-4.2.1.pom.lastUpdated
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for 
> http://central.maven.org/maven2/
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
> http://central.maven.org/maven2/
> Downloading from maven2: 
> http://central.maven.org/maven2/org/apache/felix/maven-bundle-plugin/4.2.1/maven-bundle-plugin-4.2.1.pom
> [WARNING] Checksum validation failed, expected  ef60c65b1b81b55cf3acd6ae57c9ff70e4c22583 from maven2 for 
> http://central.maven.org/maven2/org/apache/felix/maven-bundle-plugin/4.2.1/maven-bundle-plugin-4.2.1.pom
> [WARNING] Could not validate integrity of download from 
> http://central.maven.org
>
> I am also attaching the project's pom.xml and my maven's setting.xml
> I am stuck up with this issue for a while now . Any help is greatly 
> appreciated !
>
> Regards
> Debashish
>
> -
> 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: Pd: inteliJ 2020 + maven error

[John Patrick]

you don't need a settings.xml in your users home .m2 directory, that is optional

does the project build from the command line? yes / no
when you import into intellij do you select it is a maven project?
in your browser do you have a proxy set? as this might need to be
configured for intellij and also maven
in intell under project structure, has a "Project SDK" been set and is
it the java version you expect?
in intelij settings under "Build, Execution, Development" -> "Build
Tools" -> "Maven" -> "Ignored Files" uncheck files you want to import
as this has caused me issues?

can't see the screenshot you mentioned


On Mon, 25 May 2020 at 21:02, Grzegorz Goleniowski  wrote:
>
> Hello,   I have problem with my clean inteliJ 2020 and maven plugin 
> (uninstalled inteliJ 2019, cleaned registry and fles and installed new 2020 
> version).  I tried many of solutions from internet but none of them helped.  
> I don't have settings.xml file in user/.m2/ folder.  Please help me with 
> running maven - I need it to do my exercises at school, but any of teachers 
> knows solution.  I attached some screens with WeTransfer, maybe them help.  
> we.tl we.tl  error_connection file is when i tried to connect  
> repo.maven.apache.org repo.maven.apache.org  I can connct with this page in 
> my browser (Firefox)   --  Best regards  Grzegorz

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

Re: Profile not being activated by default

[John Patrick]

Running `mvn help:active-profiles` does it list your
build-dist-archives profile in the output?
Also `mvn help:all-profiles' is it listed their and does it show the
correct source? so pom or settings

If you add duplicate the executions section into your plugin defined
in the profiles, do you see the plugin executed twice?

Also what version of maven are you using? 3.6.3? or something older?

Sorry not an answer, just things i would do to try and work out if the
config is being seen, seen but ignored, or ignored.

On Wed, 13 May 2020 at 10:37, Adam Retter
 wrote:
>
> I have a build plugin configured like so:
>
> 
> org.apache.maven.plugins
> maven-assembly-plugin
> 
> 
> assemble-archives
> package
> 
> single
> 
> 
> 
> 
> true  
> 
> 
>
>
> I am trying to override its configuration in a profile that I would
> like enabled by default:
>
> 
> 
> build-dist-archives
> 
> true
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-assembly-plugin
> 
> false  
> false
> gnu
> 
>
> src/assembly/dist-assembly-unix.xml
>
> src/assembly/dist-assembly-win.xml
> 
> 
> 
> 
> 
> 
>
>
> I would expect that when I run `mvn package`, the
> `build-dist-archives` profile is active and therefore the
> maven-assembly-plugin SHOULD have skipAssembly=false. In the output
> from Maven I see:
>
> [INFO] --- maven-assembly-plugin:3.3.0:single (assemble-archives) @
> exist-distribution ---
> [INFO] Assemblies have been skipped per configuration of the
> skipAssembly parameter.
>
> This implies that skipAssembly was true.
>
>
> However... if I manually enable the profile by running `mvn package -P
> build-dist-archives`, then the maven-assembly-plugin does indeed have
> skipAssembly=false, and the assembly is correctly built.
>
> Can anyone tell me why the ` true`
> on the profile is being ignored?
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
>
> -
> 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: Build Failed

[John Patrick]

Did it previously work from this machine?
Are you being a firewall or proxy server?
What version of maven are you using?
What version of Java are you using?

I've just deleted org/apache/maven from my local repository and it
downloaded fine.

If you go to other websites do they work? i.e. are you on a public wifi and
it's doing captive portal before allowing you to access the internet...

John



On Thu, 19 Mar 2020 at 11:53, Robert Manikonda 
wrote:

> Hi
>  Please check the attached error and im unable to build maven project
>
> Thanks
>
> Br//
> Robert M
> --
>
>
>
>
> Thanks & Regards
> Robert Manikonda
> 7013207511
>

Re: java 1.8 and java 11 using toolchains plus compiler and surefire

[John Patrick]

Have decided to raise as issue so potential fixes/solutions can move
to their. https://issues.apache.org/jira/browse/SUREFIRE-1731

John

On Wed, 4 Dec 2019 at 10:55, John Patrick  wrote:
>
> So I've created a sample project for Java 1.8 and Java 11, in a Multi
> Release jar setup and with tests that should be run to confirm the
> multi release classes are being loads in the correct jvm.
>
> https://github.com/nhojpatrick/issue-maven-multi-release-jar-testing
>
> The README.md should have all the information needed for execution.
>
> Once the setup for surefire is tweaks, which i've no idea what to do,
> to get it working properly. I've tried looking at;
> https://maven.apache.org/guides/mini/guide-using-toolchains.html
> https://maven.apache.org/surefire/maven-surefire-plugin/java9.html
>
> The surefire java9 setup only executes all tests as that java version
> using toolchains, it doesn't let you do multiple tests executions each
> with a different java version, like the compile plugin allows.
>
> I would expected 3 tests to be executed, 1 test in a Java 1.8 JVM and
> 2 tests in a Java 11 JVM.
>
> Hope this helps you understand what issues i'm having with multi
> release jars and specifically testing when with surefire/failsafe.
>
> I can raise as a defect if needed, it might purely be the
> documentation needs to be made clearer, as things like
> compileSourceRoots within the compile plugin configuration i can't
> find that in the compile plugin documentation e.g. these links;
> https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> John
>
>
> On Thu, 21 Nov 2019 at 21:14, Tibor Digana  wrote:
> >
> > Hi John,
> >
> > Have you used the version 3.0.0-M4?
> > There were important fixes for Java 11/Linux (alt. Docker).
> > The message "The forked VM terminated without properly saying goodbye." is
> > too general error message.
> > Can you post the configuration of the plugin with the latest version in
> > your POM including the test summary? What provider you use?
> >
> > Cheers
> > Tibor17
> >
> >
> >
> > On Sat, Aug 31, 2019 at 7:53 PM John Patrick  wrote:
> >
> > > evening,
> > >
> > > i'm having trouble testing a multi-release jar project using
> > > toolchains. i want to test it using both java 1.8 and java 11.
> > >
> > > i've the following structure;
> > > src/main/java
> > > src/main/java11
> > > src/test/java
> > > src/test/java11
> > >
> > > tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3
> > >
> > > if i set java to 1.8 and do mvn clean install, everything works but it
> > > uses java 1.8 for the testing.
> > >
> > > if i set java to 11 and do maven clean install, it fails starting 
> > > surefire.
> > >
> > > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
> > > The forked VM terminated without properly saying goodbye. VM crash or
> > > System.exit called?
> > > [ERROR] Error occurred in starting fork, check output in log
> > > [ERROR] Process Exit Code: 1
> > > [ERROR] at
> > > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
> > >
> > > How can I test using java 1.8 then execute tests again using java 11.
> > >
> > > What profile or toolchain settings can i configure so for a surefire
> > > execution it uses the java version i choose?
> > >
> > > John
> > >
> > > -
> > > 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: java 1.8 and java 11 using toolchains plus compiler and surefire

[John Patrick]

So I've created a sample project for Java 1.8 and Java 11, in a Multi
Release jar setup and with tests that should be run to confirm the
multi release classes are being loads in the correct jvm.

https://github.com/nhojpatrick/issue-maven-multi-release-jar-testing

The README.md should have all the information needed for execution.

Once the setup for surefire is tweaks, which i've no idea what to do,
to get it working properly. I've tried looking at;
https://maven.apache.org/guides/mini/guide-using-toolchains.html
https://maven.apache.org/surefire/maven-surefire-plugin/java9.html

The surefire java9 setup only executes all tests as that java version
using toolchains, it doesn't let you do multiple tests executions each
with a different java version, like the compile plugin allows.

I would expected 3 tests to be executed, 1 test in a Java 1.8 JVM and
2 tests in a Java 11 JVM.

Hope this helps you understand what issues i'm having with multi
release jars and specifically testing when with surefire/failsafe.

I can raise as a defect if needed, it might purely be the
documentation needs to be made clearer, as things like
compileSourceRoots within the compile plugin configuration i can't
find that in the compile plugin documentation e.g. these links;
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
https://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

John


On Thu, 21 Nov 2019 at 21:14, Tibor Digana  wrote:
>
> Hi John,
>
> Have you used the version 3.0.0-M4?
> There were important fixes for Java 11/Linux (alt. Docker).
> The message "The forked VM terminated without properly saying goodbye." is
> too general error message.
> Can you post the configuration of the plugin with the latest version in
> your POM including the test summary? What provider you use?
>
> Cheers
> Tibor17
>
>
>
> On Sat, Aug 31, 2019 at 7:53 PM John Patrick  wrote:
>
> > evening,
> >
> > i'm having trouble testing a multi-release jar project using
> > toolchains. i want to test it using both java 1.8 and java 11.
> >
> > i've the following structure;
> > src/main/java
> > src/main/java11
> > src/test/java
> > src/test/java11
> >
> > tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3
> >
> > if i set java to 1.8 and do mvn clean install, everything works but it
> > uses java 1.8 for the testing.
> >
> > if i set java to 11 and do maven clean install, it fails starting surefire.
> >
> > [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
> > The forked VM terminated without properly saying goodbye. VM crash or
> > System.exit called?
> > [ERROR] Error occurred in starting fork, check output in log
> > [ERROR] Process Exit Code: 1
> > [ERROR] at
> > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
> >
> > How can I test using java 1.8 then execute tests again using java 11.
> >
> > What profile or toolchain settings can i configure so for a surefire
> > execution it uses the java version i choose?
> >
> > John
> >
> > -
> > 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: 2 issues with maven version range

[John Patrick]

cheers for the information.

I expect this might be asking space vs tabs, but do others feel the
version range of "[4,5)" should exclude anything starting 5, include
5-SNAPSHOT and any 5...-RC* or 5...-alpha

It seams wrong to have to use "[4,4.999)".

I understand from a maths point of view and from a order point of view
the ordering is correct but from an ease of use, end developers point
of view, i should just be able to use "[4,5)"

thoughts?

On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki  wrote:
>
> I believe your cases do not work with version ranges. Version ranges depend
> on the order of the versions, and thus you cannot filter "-guava".
>
> The ordering of version is defined in
> org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
>
> Example code to check:
>
> // GenericVersionScheme is in
> org.apache.maven.resolver:maven-resolver-util:1.3.3
> GenericVersionScheme scheme = new GenericVersionScheme();
> List list = new ArrayList<>();
> list.add(scheme.parseVersion("4.7.0"));
> list.add(scheme.parseVersion("4.9.0"));
> list.add(scheme.parseVersion("5"));
> list.add(scheme.parseVersion("5.0.0"));
> list.add(scheme.parseVersion("5.0.0-RC1"));
> list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
> Collections.sort(list);
> System.out.println(list); // [4.7.0, 4.9.0, 5.0.0-RC1,
> 5.0.0-SNAPSHOT, 5, 5.0.0]
>
> So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
> 4.999]".
>
> Regards,
> Tomo
>
> On Sun, Nov 24, 2019 at 2:46 PM John Patrick  wrote:
>
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
> >
> > 2) i'm trying to use the version range "[4.7.0,5) "for
> > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> > -Dincludes=io.cucumber
> >
> > https://search.maven.org/artifact/io.cucumber/cucumber-core
> >
> > what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?
> >
> > or are other people having similar issue so gave using trying to use
> > maven version ranges when declaring dependencies?
> >
> > John
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> --
> Regards,
> Tomo

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

2 issues with maven version range

[John Patrick]

i'm trying to start using maven version range more but having issues
with things like guava and also it not excluding version i believe
should be excluded.

1) i don't think this is possible but it might be, take a look a
google guava, it has a jre and a android version. using maven version
range how can i say any newer jre version, or any newer android
version?

https://search.maven.org/artifact/com.google.guava/guava

something like [25,) but only the jre maybe [25*-jre,)

2) i'm trying to use the version range "[4.7.0,5) "for
io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
-Dincludes=io.cucumber

https://search.maven.org/artifact/io.cucumber/cucumber-core

what do i need to change "[4.7.0,5)" to do it excludes anything starting 5?

or are other people having similar issue so gave using trying to use
maven version ranges when declaring dependencies?

John

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

Re: mvn versions:display-plugin-updates says I can update from 3 to 2

[John Patrick]

Technically you didn't do anything wrong...
If you don't configure what version of java and maven your project
requires, then versions will tell you about all options available.

So that is saying if you want users to build using maven 2.0.1 then
the maven-war-plugin needs to be 2.0.2.

If you add something like below which says I can run on maven 3.6.0 or
newer, I can also only run on java 1.8, or java 11 or newer, e.g. not
java 9 and not java 10. Then when you re-run versions older versions
of maven won't be shown. Also check your using versions 2.7

  org.apache.maven.plugins
  maven-enforcer-plugin
  3.0.0-M2
  

  enforce-requirements
  
enforce
  
  

  
[1.8,9),[11,)
  
  
[3.6.0,)
  

  

  


Hope that helps.

John

On Fri, 6 Sep 2019 at 16:37, Jason Young  wrote:
>
> Did I do something wrong?
>
> $ mvn versions:display-plugin-updates
> ...
> [INFO] Require Maven 2.0.1 to use the following plugin updates:
> [INFO]   maven-war-plugin ... 3.2.3 -> 2.0.2
>
> --
>
> Jason Young

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

java 1.8 and java 11 using toolchains plus compiler and surefire

[John Patrick]

evening,

i'm having trouble testing a multi-release jar project using
toolchains. i want to test it using both java 1.8 and java 11.

i've the following structure;
src/main/java
src/main/java11
src/test/java
src/test/java11

tried both maven-surefire-plugin v 2.22.2 and 3.0.0-M3

if i set java to 1.8 and do mvn clean install, everything works but it
uses java 1.8 for the testing.

if i set java to 11 and do maven clean install, it fails starting surefire.

[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)

How can I test using java 1.8 then execute tests again using java 11.

What profile or toolchain settings can i configure so for a surefire
execution it uses the java version i choose?

John

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

Re: OS

[John Patrick]

>From my experience maven modules don't care about the operating
system, some might, your code and tests might but what is your issue
with hard coding to a specific OS not a surefire issue.

Modules care about the version of maven being used and the version of
java being used.

Does the version of maven your using and the version of java your
using install correctly on windows 2019?


On Thu, 18 Apr 2019 at 11:17, Tibor Digana  wrote:
>
> I don't have access in the second link, but you can report a bug in our
> Jira https://issues.apache.org/jira/projects/SUREFIRE.
> We won't like to have issues from users in the Jira regarding making the
> on-site support but still you can utilize this user mailing list for
> questions.
>
> On Thu, Apr 18, 2019 at 5:59 AM liname...@outlook.com 
> wrote:
>
> > The previously written project wants to run it on Windows 2019, so
> > investigate whether Windows 2019 supports these modules.
> >
> >
> >
> >
> > 发送自 Windows 10 版邮件应用
> >
> >
> >
> > 
> > 差出人: Tibor Digana 
> > 送信日時: Thursday, April 18, 2019 11:38:37 AM
> > 宛先: Maven Users List
> > 件名: Re: OS
> >
> > It is, Surefire on Windows.
> > Why you are asking?
> >
> > T
> >
> >
> > On Thu, Apr 18, 2019 at 3:50 AM liname...@outlook.com <
> > liname...@outlook.com>
> > wrote:
> >
> > >
> > > Hello, I am doing an investigation.
> > > Does Windows Server 2019 support the following products:
> > >
> > > maven-surefire-plugin  2.17
> > >
> > > Is the other version supported?
> > > Can you tell me, thank you very much.
> > >
> > >
> >

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

Re: How to specify to make use of the latest version of hibernate jars using maven?

[John Patrick]

I would...
1) Look at the dependency tree and see how it's being included.
2) Add an exclude for hibernate for how it's being included.
3) Add a dependency for hibernate to the version you want to use.

I might not do step 2.


On Wed, 3 Oct 2018 at 09:17, Karl Heinz Marbaise  wrote:
>
> Hi,
>
> first do no crosspost into dev list, cause this is a question for the
> users list...
>
> furthermore do not add image links into a mail cause more or less all
> mail clients filter them out..
>
> Best would be two things.
>
> text copied/pasted and description and more helpful a link to a real
> project or an example project which shows the behaviour?...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 02/10/18 10:14, Senthilkumar Jayakumar wrote:
> > Hi There,
> >
> > In my project Spring (4.3.3) and Hibernate (5.0.11.Final) and JPA (2.1)
> > is currently used and I would like to upgrade the Hibernate version from
> > 5.0.11.Final to 5.3.6.Final. There is no specific version of hibernate
> > mentioned in pom.xml but still 5.0.11 version is being downloaded and
> > used.  Also, I tried explicitly specifying the version in the pom.xml
> > but still executing “make clean install “ I could still see both
> > 5.0.11.Final & 5.3.6.Final  version jars are being downloaded, but still
> >   5.0.11.Final version is being used/packaged along with the application
> > jar.
> >
> > It is still unclear to me as to how the hibernate version is chosen as
> > 5.0.11 and how I can specify to start using 5.3.6. I have shared the
> > details of jar’s and repositories being used below.
> >
> > Appreciate your help in this regard.
> >
> > Hibernate related jar used:
> >
> > Spring related jar used:
> >
> > Following repositories are being used:
> >
> > Thanks,
> >
> > Senthil Jayakumar
>
> -
> 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: maven-failsafe-plugin and JPMS module

[John Patrick]

surefire and failsafe plugins appear to work the same

I've had to use the 2.22.0 versions

I defined my plugin in a pluginManagement section and had to add this

${project.custom.failsafe.argLine.jpms}


then in each project I add properties as required like this for
surefire or failsafe depending what they need;
--add-opens 
${project.Automatic-Module-Name}/${project.Automatic-Module-Name}.tests=ALL-UNNAMED
--add-opens 
${project.Automatic-Module-Name}/${project.Automatic-Module-Name}.transform=ALL-UNNAMED
--add-opens 
${project.Automatic-Module-Name}/${project.Automatic-Module-Name}.transform.transformations=ALL-UNNAMED
--add-opens 
${project.Automatic-Module-Name}/${project.Automatic-Module-Name}.testing=com.fasterxml.jackson.databind

project.Automatic-Module-Name is a property in the same pom which
defines it's module name

fyi I'm still trying to get a few differently things working and their
might be other ways of getting it work, but i'm in a multi project
setup and I'm also trying to get the project to work in Java 8, 9, 10
as main development is Java 8 but want to get everything working on
the new releases without denting releases into live.

not sure about OSGi

On Sat, 15 Sep 2018 at 12:17, Alex Sviridov  wrote:
>
> Hi all,
>
> Could anyone of maven-failsafe-plugin give answers to the following short 
> questions:
>
> 1) Does maven-failsafe-plugin support module path and testing JPMS modules?
> 2) When the plugin is used for testing a JPMS module are integration tests 
> executed from another JPMS module? For example pax-exam (for OSGi) creates 
> another temp bundle.
> 3) Is there an example which shows how to use the plugin for integration 
> testing of JPMS module?
>
> I would be helpful for any help.
>
> Best regards, Alex Sviridov
>

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

RE: Looking for recommendations how to best use Maven in a muti-stage Pipeline build to only deploy at the end

[Robert Patrick]

Downloading the artifacts (e.g., maven-dependency-plugin) and deploying them 
(e.g., maven-deploy-plugin) is the easy part, the tricky part is figuring out a 
"unique version number" of the artifacts to pass from one pipeline step to the 
next so that you are picking up the "right artifacts" from the staging 
repositories.  This is particularly important when multiple build pipelines are 
running in parallel...  

We have solved this in various ways in the past; for example, changing the 
version number from a SNAPSHOT version to a concrete version number based on a 
timestamp (e.g., 1.0.0-20180214-092053.123) prior to the running the automated 
build.  Unfortunately, none of the ways we have found so far were particular 
elegant so I it is hard to recommend a particular approach since they all have 
some drawbacks.

Maybe someone else has a better way to solve this problem...

-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca] 
Sent: Wednesday, February 14, 2018 9:16 PM
To: Maven Users List 
Subject: Re: Looking for recommendations how to best use Maven in a muti-stage 
Pipeline build to only deploy at the end

Robert,

I think you misunderstood my problem.  It isn't a problem of defining different 
distributionManagement repos; like you said that is fairly easily handled using 
properties or -D parameters.

It is more the question of what kind of plugin is required to run which
says:
- download all the artifacts that this multi-module project previously built
- deploy all the artifacts that were just downloaded

I cannot think of how to design/configure a project to accomplish something 
like that.  I'm guessing I would have to create a profile which explicitly 
declares each artifact produced by the multi-module project in order to do a 
dependency:copy, and then similarly, use a build-helper:attach all the 
artifacts that were just downloaded.  But that seems like a painful solution.  
Am hoping there is something easier?

Thanks,

Eric


On Wed, Feb 14, 2018 at 9:45 PM, Robert Patrick 
wrote:

> Inline...
>
>
> -Original Message-
> From: Eric B [mailto:ebenza...@gmail.com]
> Sent: Wednesday, February 14, 2018 8:27 PM
> To: Maven Users List 
> Subject: Re: Looking for recommendations how to best use Maven in a 
> muti-stage Pipeline build to only deploy at the end
>
> Hi Robert,
>
> Thanks for the suggestions.  To be honest, I never thought of using 
> regular repositories as staging repos.  That being said, I do see a 
> hiccup with the option that I'm not sure how to address.  In the case 
> where a build is rejected during the pipelline stage, how do I delete 
> it?  I haven't found a plugin that would allow me to delete a build from a 
> repo.
> And with a multi-module project, there are many artifacts that would 
> need to be rolled back.  I guess I could simply configure the repo to 
> allow re-deployment of the same artifact to these "stage" repos, but 
> if ever a deployment fails part way through, I end up with a repo in 
> an unstable manner (ie: there is no way to ensure that all modules are 
> promoted at the same time).
>
> [Robert] Typically, I would solve this problem by simply putting 
> expiration dates on artifacts in the staging repositories.  I have 
> never used Nexus but Artifactory allows you to limit artifacts in the 
> repository by size, last time accessed, etc.  No need to keep 
> artifacts in the "staging repositories" for more than say, one month, 
> anyway since they were either good (and promoted all the way to the 
> release repository) or bad (and are not interesting after they fail).
>
> All that being said, the last question would be how to retrieve and 
> redeploy these artifacts from one repo to another?  Changing the 
> distributionManagement settings is simple enough, but how would I 
> instruct maven to download all the modules from a multi-module build 
> and then deploy them?  I guess I could hack a profile in the parent 
> pom where the different modules are defined with a 
> dependency:copy-dependencies goal, but how do I ensure all artifacts 
> that were just downloaded are then deployed to the next repo in the 
> stage?  I would think the only way to do this would be writing my own 
> custom plugin, unless you can think of some other mechanism to accomplish 
> this?
>
> [Robert] Another way to do this is to use properties for the key 
> values for the repository URLs in the  and 
>  sections of the POM.  You simply set a 
> default value for the properties in the root POM (e.g., with 
> appropriate values for the repositories used by the developers) and 
> then override the property values with Maven command-line -Ds (or 
> profiles) in the Jenkins build steps to handle pulling and promoting to the 
> right plac

RE: Looking for recommendations how to best use Maven in a muti-stage Pipeline build to only deploy at the end

[Robert Patrick]

Inline...


-Original Message-
From: Eric B [mailto:ebenza...@gmail.com] 
Sent: Wednesday, February 14, 2018 8:27 PM
To: Maven Users List 
Subject: Re: Looking for recommendations how to best use Maven in a muti-stage 
Pipeline build to only deploy at the end

Hi Robert,

Thanks for the suggestions.  To be honest, I never thought of using regular 
repositories as staging repos.  That being said, I do see a hiccup with the 
option that I'm not sure how to address.  In the case where a build is rejected 
during the pipelline stage, how do I delete it?  I haven't found a plugin that 
would allow me to delete a build from a repo.  And with a multi-module project, 
there are many artifacts that would need to be rolled back.  I guess I could 
simply configure the repo to allow re-deployment of the same artifact to these 
"stage" repos, but if ever a deployment fails part way through, I end up with a 
repo in an unstable manner (ie: there is no way to ensure that all modules are 
promoted at the same time).

[Robert] Typically, I would solve this problem by simply putting expiration 
dates on artifacts in the staging repositories.  I have never used Nexus but 
Artifactory allows you to limit artifacts in the repository by size, last time 
accessed, etc.  No need to keep artifacts in the "staging repositories" for 
more than say, one month, anyway since they were either good (and promoted all 
the way to the release repository) or bad (and are not interesting after they 
fail). 

All that being said, the last question would be how to retrieve and redeploy 
these artifacts from one repo to another?  Changing the distributionManagement 
settings is simple enough, but how would I instruct maven to download all the 
modules from a multi-module build and then deploy them?  I guess I could hack a 
profile in the parent pom where the different modules are defined with a 
dependency:copy-dependencies goal, but how do I ensure all artifacts that were 
just downloaded are then deployed to the next repo in the stage?  I would think 
the only way to do this would be writing my own custom plugin, unless you can 
think of some other mechanism to accomplish this?

[Robert] Another way to do this is to use properties for the key values for the 
repository URLs in the  and  sections of 
the POM.  You simply set a default value for the properties in the root POM 
(e.g., with appropriate values for the repositories used by the developers) and 
then override the property values with Maven command-line -Ds (or profiles) in 
the Jenkins build steps to handle pulling and promoting to the right places...

Thanks,

Eric



On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick 
wrote:

> While Nexus may not support "staging repositories", it certainly 
> supports more than one repository so why not just create one or more 
> repositories that serve as staging repositories.  For example,
>
> Pipeline Steps:
> 1.) Trigger a build based on source check-in and push to stage1 repo 
> if build "succeeds"
> 2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to 
> stage2 repo if tests succeed.
> 3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to 
> stage3 repo if tests succeed.
> 4.) Pull artifacts from stage3 repo, run UAT tests, and push to 
> release repo if tests succeed.
>
>
>
>
> -Original Message-
> From: Eric B [mailto:ebenza...@gmail.com]
> Sent: Wednesday, February 14, 2018 8:30 AM
> To: Maven Users List 
> Subject: Looking for recommendations how to best use Maven in a 
> muti-stage Pipeline build to only deploy at the end
>
> I'm looking for recommendations for the best way to use Maven in a 
> multi-stage Jenkins pipeline build to deploy only at the end.  At the 
> moment, I'm using Sonatype Nexus 3.x, which means i don't have the benefit
> of staging repos.   Consequently, I have to ensure that the only released
> versions of my libraries/application are final - they've passed QA.
> Additionally, the team wants to ensure that the version numbers are 
> always incremental and every version in the repo is a consumable 
> version (ie: I cannot deploy a version 1.2.3 which has not passed 
> QA/Acceptance Tests, and furthermore, I cannot deploy a 1.2.2 followed by a 
> 1.2.4).
>
> What that requirement translates to is that I have to ensure that the 
> binary built is fully tested before promoting it to Nexus. (and that I 
> shouldn't be appending build numbers to the maven version number).
>
> In my mind, I would like to do something the following in a Pipeline build:
>
> stage('build') { steps { sh 'mvn clean install'} }
>
> stage('Confirm deploy to QA'){
>
> steps {
>
> checkpoint 'test server deployed'
>
> 

RE: Looking for recommendations how to best use Maven in a muti-stage Pipeline build to only deploy at the end

[Robert Patrick]

While Nexus may not support "staging repositories", it certainly supports more 
than one repository so why not just create one or more repositories that serve 
as staging repositories.  For example,

Pipeline Steps:
1.) Trigger a build based on source check-in and push to stage1 repo if build 
"succeeds"
2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to stage2 repo 
if tests succeed.
3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to stage3 repo 
if tests succeed.
4.) Pull artifacts from stage3 repo, run UAT tests, and push to release repo if 
tests succeed.




-Original Message-
From: Eric B [mailto:ebenza...@gmail.com] 
Sent: Wednesday, February 14, 2018 8:30 AM
To: Maven Users List 
Subject: Looking for recommendations how to best use Maven in a muti-stage 
Pipeline build to only deploy at the end

I'm looking for recommendations for the best way to use Maven in a multi-stage 
Jenkins pipeline build to deploy only at the end.  At the moment, I'm using 
Sonatype Nexus 3.x, which means i don't have the benefit
of staging repos.   Consequently, I have to ensure that the only released
versions of my libraries/application are final - they've passed QA.
Additionally, the team wants to ensure that the version numbers are always 
incremental and every version in the repo is a consumable version (ie: I cannot 
deploy a version 1.2.3 which has not passed QA/Acceptance Tests, and 
furthermore, I cannot deploy a 1.2.2 followed by a 1.2.4).

What that requirement translates to is that I have to ensure that the binary 
built is fully tested before promoting it to Nexus. (and that I shouldn't be 
appending build numbers to the maven version number).

In my mind, I would like to do something the following in a Pipeline build:

stage('build') { steps { sh 'mvn clean install'} }

stage('Confirm deploy to QA'){

steps {

checkpoint 'test server deployed'

script {

env.DEPLOY_TO_QA_TEST = input message: 'User input required',

submitter: 'authenticated',

parameters: [choice(name: 'Deploy to acceptance test server', choices:
'no\nyes', description: 'Choose "yes" if you want to deploy the QA test 
server')]

}

}

}

stage('deployQA') {

when {

environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'

}

steps{

/* deploy the build to a QA environment */  }

}


stage('Confirm deploy to UAT'){ // prompt user }

stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance Testing 
enviornment */}


stage('Confirm publish to Nexus'){ // prompt user }

stage('publish') {

steps {

  // mvn deploy -DskipTests (just deploy - don't rebuild)

}

}


Basically, I want to design my Jenkins pipeline to be my staging process.
The problem I have is I'm not sure how I can only deploy at the end of the 
pipeline.  When maven runs the deploy lifecycle, it will run through all the 
other stages and reassemble my binaries, which technically are not longer the 
same as those that were approved.  So consequently, my binary hashes that were 
approved earlier in the pipeline are not the same hashes that are deployed in 
Nexus.

I realize that i can probably do some work and use the Reproducible Build 
plugin 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__zlika.github.io_reproducible-2Dbuild-2Dmaven-2Dplugin_&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nSxyAsyxa1Izff8ULe7vW8u084madbci-hLPsiLpxeU&m=Og2S17jc02JRwm-oHae8UQmiIg_ygbBRL0EQoB_Wvuw&s=zipmYyPLpmFYv1RsnquZtQMf0-HoYoix12SZj6gD2jM&e=),
 but that too comes with drawbacks (I want build timestamps in my Manifest 
files, and zip entries, etc).

Am I sunk?  Is my only hope to wait until Sonatype releases Staging repos for 
Nexus 3.x sometime in Q2?  Or is there some other way I can work around this?

How is everyone else handling this situation?

Thanks for sharing.

Eric

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

Re: Is there another alternative to using maven plug-in ?

[John Patrick]

Change your pom to something like this;

Hi5S
Hi5S
0.0.1-SNAPSHOT
war


UTF-8
1.8
1.8





   org.apache.maven.plugins
   maven-war-plugin
   3.1.0




war, tell maven your wanting to create a war
not a jar, using maven-war-plugin as a plugin as show above tells
maven your wanting to use a specific version of the maven plugin.
there are pros and cons to hard coding a maven plugin version. i
always do because i've been burnt on projects where they needed a
specific version but didn't define what version they needed and whilst
that version was the latest things worked correctly. But then you come
back to bug fixing that project 2-4 years later and the latest maven
plugin works differently.

dependencies are for external code that your java code depends upon




On 26 January 2018 at 11:08, Karen Goh  wrote:
> Hi expert,
>
> I have been running into alot of issue lately and I suspect if it is because 
> I have using Maven plug-in?
>
> Here's how I do the maven-war-plugin:
>
> Hi5S
> Hi5S
> 0.0.1-SNAPSHOT
> war
> 
> 
> UTF-8
> 1.8
> 1.8
> 
>
> 
> 
> org.apache.maven.plugins
> maven-war-plugin
> 3.1.0
> provided
> 
>
> I'd like to know if it is ok I don't use maven to do the compile but used 
> Eclipse to do it instead ?
>
> If it is so, how should I change the maven-war-plugin to ?
>
> I feel that this is the cause that Eclipse is not able to do proper debugging 
> as in showing the stackover of what's happening when I run debug on server.
>
> Correct me if I am wrong..but I am at my wits end and this is the strongest 
> suspect.
>
> Hope someone can tell me how to make pom as simple as possible...I just want 
> to add the relevant dependencies...that's all.
>
> Tks & regards,
> Karen
>
> -
> 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: maven-war-plugin addClasspath useless, because it cannot add absolute paths

[Robert Patrick]

Well...I suspect that it is skipping the dependency because it is 
system-scoped.  If so, this doesn’t make it useless for most people since most 
of use do not use “system-scoped” dependencies...



> On Jan 25, 2018, at 4:43 AM, Basin Ilya  wrote:
> 
> Hi List.
> As far as I know, Class-Path in MANIFEST.MF of a .war file is only useful 
> when you need to add jars that are not in WEB-INF/lib and not provided by the 
> container.
> But can maven add paths that are absolute or relative? I tried this:
> 
>   
>   nah
>   nah
>   1.0.0
>   system
>   /C:/1/ccc.jar
>   true
>   
>   
>   
>...
>
>org.apache.maven.plugins
>maven-war-plugin
>
>  
>
>  true
>
>  
> 
> The Class-Path was indeed added to MANIFEST.MF, but not the "ccc.jar".
> 
> -
> 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: Problems Using ANTLR4 (Packaged Classes Not Found in Generated Code)

[Robert Patrick]

Most likely, you need to add a compile-time dependency on the antlr runtime 
library, where the missing class is located.


org.antlr
antlr4-runtime
4.7



> On Oct 29, 2017, at 2:43 AM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> 
> can make a test project on Github/gitlab etc.
> 
> Kind regards
> Karl Heinz Marbaise
>> On 29/10/17 05:13, R0b0t1 wrote:
>> Is any more information needed? The files are generated properly by
>> ANTLR, but I can not compile the generated files.
>> [INFO] -
>> [ERROR] COMPILATION ERROR :
>> [INFO] -
>> [ERROR] 
>> /C:/Users/R0b0t1/Documents/Code/grammar-mvn/target/generated-sources/antlr4/GrammarParser.java:[32,29]
>> cannot find symbol
>>   symbol:   class Vocabulary
>>   location: class LangParser
>> And so on. I followed
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.antlr.org_api_maven-2Dplugin_latest_usage.html&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=nRiDxwbhq-IuQJmgLg2hhUqK_UsIqKWJAqUcywTbz-Y&s=9YiehKVhRPHh6AA9LGHQ5Fhbj5FKWZ4POGIAyeXDD6Y&e=
>>  and
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.antlr.org_api_maven-2Dplugin_latest_dependency-2Dinfo.html&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=nRiDxwbhq-IuQJmgLg2hhUqK_UsIqKWJAqUcywTbz-Y&s=IjFObLVM57HemB8uaI20Eq7Qe7CY2VNfOQA7O5qQfZ8&e=.
>> I am not very smart. I have spent a few days trying to figure out the
>> best way to compile a Java project. I have tried Ant, CMake, and now
>> Maven. Maven seems like the easiest to use, but I can not solve this
>> problem I am having.
>> Respectfully,
>>  R0b0t1.
> 
> -
> 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: IT test in src/test/java is not executed by failsafe:integration-test, or fails oddly with verify

[Robert Patrick]

In our integration tests' parent POM, we configured the compiler plugin to run 
the test-compile goal:


org.apache.maven.plugins
maven-compiler-plugin


test-compile
test-compile

testCompile







And the failsafe-plugin like this:


org.apache.maven.plugins
maven-failsafe-plugin


system-integration-test
integration-test

integration-test


-Xmx2048m -XX:PermSize=128m 
-XX:MaxPermSize=256m


${project.build.directory}
${a2c-home}



java.io.tmpdir

${project.build.directory}





system-test-verify
verify

verify





In each test submodule POM, we simply add the following:


org.apache.maven.plugins
maven-compiler-plugin


org.apache.maven.plugins
maven-failsafe-plugin



-Original Message-
From: KARR, DAVID [mailto:dk0...@att.com] 
Sent: Wednesday, October 25, 2017 12:56 PM
To: users@maven.apache.org
Subject: IT test in src/test/java is not executed by failsafe:integration-test, 
or fails oddly with verify

I work on a large multiproject build that mostly produces OSGi bundle 
artifacts.  The codebase has a lot of unit tests that work fine from the build.

We also have quite a few IT tests, but we only execute those from Eclipse, as 
the nature of the framework makes those tests unreliable.

I now want to write a small test of IT tests that WILL be run from maven, in a 
CI build.  I verified that the test behaves properly when run from Eclipse.

I put the test in "src/test/java", named it with the "*IT.java" pattern, and 
then tried to run "failsafe:integration-test".  It ran failsafe, but it didn't 
find any tests.

So, on advice from someone on StackOverflow, I added an "executions" block to 
the plugin declaration.  Adding "integration-test" to the goals list didn't 
make any difference, but when I added "verify" and then ran that goal from the 
command line, I got very odd results.

The following is an elided version of the pom:



http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd"xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
4.0.0

...

usl-features-install
usl-features-install

https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.apache.org&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=Gdqqce41TF232jlBHJhZ-SIZC-k-d9PREKAleK9pw0E&s=qa36PW3OrelDpW11bDjEo6LjewMSAUzW7lmp0RUt2OE&e=
 
bundle


UTF-8





org.apache.maven.plugins

maven-failsafe-plugin
2.20.1




verify

integration-test





org.apache.felix

maven-bundle-plugin


org.

Re: Need to pass properties to the dependency POM file

[Robert Patrick]

Why not just use a top-level POM’s dependencyManagement section, in conjunction 
with top-level POM-defined properties if desired, to control the dependency 
versions?

> On Oct 10, 2017, at 6:56 AM, Bikash Chandra Barad 
>  wrote:
> 
> Hi Russell,
> 
> I am not using it as import.
> 
> POM
> 
> 
> 
>org.sonatype.mavenbook
>persistence-deps
>1.0
>pom
>
>
>org.hibernate
>hibernate
>${hibernateVersion}
>
>
>org.hibernate
>hibernate-annotations
>${hibernateAnnotationsVersion}
>
>
>org.springframework
>spring-hibernate3
>${springVersion}
>
>
>mysql
>mysql-connector-java
>${mysqlVersion}
>
>
>
>(5.1,)
>(2.0.6,)
>3.2.5.ga
>3.3.0.ga
>
> 
> 
> Adding dependencies
> =
> 
> 
>This is a project requiring JDBC
>...
>
>...
>
>org.sonatype.mavenbook
>persistence-deps
>1.0
>pom
>
>
> 
> 
> Regards,
> Bikash Chandra
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com] 
> Sent: Tuesday, October 10, 2017 5:13 PM
> To: Maven Users List 
> Subject: Re: Need to pass properties to the dependency POM file
> 
> Sounds as though you may want to use “import” scope 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_guides_introduction_introduction-2Dto-2Ddependency-2Dmechanism.html&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=55zhnJWrLDMAiuaB5pm9kC5cwEZ5DXWtGS3Rkle3obI&s=9YuWlEsrF5dB0MfahK--TN8Ud68aWuMMoilCQf6XGMA&e=
>  
> 
>> On Oct 10, 2017, at 7:26 AM, Bikash Chandra Barad 
>>  wrote:
>> 
>> Hi,
>> 
>> I am trying to grouping the dependencies into a pom(pom-deps.pom)file and 
>> adding that pom file as a dependency in my project.
>> I need to substitute the properties of the dependency pom file(pom-deps.pom) 
>> to get the latest version dependencies, like parent POM,  from the 
>> dependency POM, in my project.
>> Is it possible to do so?
>> 
>> 
>> Regards,
>> Bikash Chandra
>> 
> 
> 
> -
> 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: Local jar not recognized from maven repository

[Robert Patrick]

That error message does not look like a Maven error message.  Try running your 
build with -X and look at the output of the maven-compiler-plugin.  If the 
class was not found during compilation, I would expect a different error 
message from the Java compiler...


> On Oct 5, 2017, at 4:25 AM, Juleian  wrote:
> 
> I need to do edit some code in a maven project. Therefore, I need to include
> a jar I made. I am not really experienced in using maven, however I tried an
> approach I found on StackoverFlow and the web.
> 
> First I added the jar to my m2 repository (just selected some terms for the
> IDs):
> 
> mvn install:install-file -Dfile=C:\Users\Julian\Desktop\SensingCasa.jar
> -DgroupId=mannheim 
> -DartifactId=sas -Dversion=1.0 -Dpackaging=jar
> 
> Then I created the dependency in the correspoing POM file of the project:
> 
>
>mannheim
>sas
>1.0
>
> 
> The actual jar is also showing up under the dependecy list named "sas: 1.0"
> 
> However, if I want to instantiate a Class of my jar file, it says
> "Interaction (Class name) cannot be resolved to a type"
> 
> Why is my Class still unkown?
> 
> 
> 
> --
> Sent from: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__maven.40175.n5.nabble.com_Maven-2DUsers-2Df40176.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=eFL7DugwimraAZBM5kUN0Pnp8CaQdZRbGsq0GKKTl8Q&s=JtujyKKBZepRc2srAi_-w6tIzNWQrWeyucBYYjX3iVc&e=
>  
> 
> -
> 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: Version Information needed.

[Robert Patrick]

[Removing Maven dev list from the email thread via BCC]

This plugin is not part of the Maven core so you can likely use any modern 
version of the plugin with Maven 3.2.5.  As for how to use it, probably best to 
start with http://www.mojohaus.org/cobertura-maven-plugin/ and then ask more 
specific questions if something doesn’t work using the plugin project's mailing 
list (which you can find at 
http://www.mojohaus.org/cobertura-maven-plugin/mail-lists.html)...


-Original Message-
From: jayant sable [mailto:jayants...@gmail.com] 
Sent: Tuesday, September 19, 2017 7:06 AM
To: d...@maven.apache.org; users@maven.apache.org
Subject: Version Information needed.

Hey folks,

I'm using maven 3.2.5 and with that I'm using cobertura-maven-plugin to 
generate code coverage report.

I want to know which version of cobertura-maven-plugin is used in maven 3.2.5??
How can I do that.

Thanks.

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

Re: When time do we need to delete .m2/repository

[John Patrick]

I do similar to Eric for jenkins.

But also for both developer builds and jenkins, I've got all projects
setup to use the
http://www.mojohaus.org/build-helper-maven-plugin/remove-project-artifact-mojo.html
plugin. With both a default and clean phase execution. So when either
jenkins or a developer does a clean, old artifacts are removed. This I
find stops the need to intervention of having to manually clean up the
local repo.

I've also got a local artifactory instance running inside a vagrant
vm, so i can safely delete my local repo if I've trouble and it can
download what i needs to again. It also helps when working offline or
over a slow internet connection as most things I've already download
previously.

John




On 12 September 2017 at 12:56, Eric B  wrote:
> I have my jenkins jobs designed to use private m2 repos per job.  I dont
> find the need to delete them since the only transient changes are the
> snapshots, which get reevaluated at every build anyhow.
>
> Thanks
>
> Eric
>
>
> On Sep 11, 2017 2:43 PM, "Stephen Connolly" 
> wrote:
>
> On Fri 8 Sep 2017 at 11:22, Baptiste Mathus  wrote:
>
>> Le 7 sept. 2017 17:00, "Tushar Kapila"  a écrit :
>>
>> I had to delete a directory once as i had pressed Ctrl-C while it was
>> downloading jars and a 0kb jar was created. This was in 2013, maybe it
>> downloads to a temp file and then create the final file? It took sometime
>> to debug. Builds were failing for no reason only on that test box, but
>> working fine on my dev box, lots of fun.
>>
>> > If you don't, and
>> > you have static (persistent) agents, very bad things will happen at some
>> point.
>>
>> Can you explain this? What agents?
>>
>>
>> Hehe, I was talking about Jenkins agents, sorry just realized I mixed my
>> MLs. I thought I was reading Jenkinsci-users one :).
>
>
> Bad Ba(p)tiste™
>
> ;-)
>
>
>>
>>
>> On Thu, Sep 7, 2017 at 1:59 PM, Baptiste Mathus  wrote:
>>
>> > 2017-09-07 9:17 GMT+02:00 Guang Chao :
>> >
>> > > On Fri, Sep 1, 2017 at 11:31 AM, mingleizhang 
>> > > wrote:
>> > >
>> > > > Hello friends here.
>> > > >
>> > > >
>> > > >  I would like ask a question ,it probably looks silly, but I
>> still
>> > > > want to know. As the subject said, when time do we need to delete
>> > > > .m2/repository files ? Does anyone improve my mind ? Thank you very
>> > much!
>> > > >
>> > > >
>> > > >
>> > > There is no need to do this unless you are out of disk space. It will
>> > cause
>> > > no harm, but maven will redownload all dependencies again. So that
> will
>> > > slow you down a bit.
>> > >
>> >
>> > I am actually going to say the contrary. You should, at I'd even say,
> you
>> > *must* wipe out Maven repositories on a regular basis. If you don't, and
>> > you have static (persistent) agents, very bad things will happen at some
>> > point.
>> >
>> > So, yeah, redownloading it is going to add some time to build, but this
>> is
>> > a matter of speed vs. reproducibility, so better target
>> reproduciblity/non
>> > flakiness then see how to optimize, not the contrary.
>> >
>> > And obviously, *NEVER, EVER share that .m2/repository between running
>> > builds*.
>> >
>> >
>> > >
>> > >
>> > > > Thanks
>> > > > Rice.
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Guang 
>> > >
>> >
>>
>>
>>
>> --
>> Regards
>> Tushar Kapila
>>
> --
> Sent from my phone

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

Re: When time do we need to delete .m2/repository

[John Patrick]

when every your running out of disk space

you can also use this plugin
http://www.mojohaus.org/build-helper-maven-plugin/remove-project-artifact-mojo.html
so when you do a clean or a install, it will also remove that project
from your local repo.

e.g. if your building a JEE project or other war project, then it will
mean you only have the currently build version in your local repo.
which is probably what you actually need. as your build server should
be publishing released versions and putting them into a central
server. so if you need a released version then you can simply download
it.


On 1 September 2017 at 04:31, mingleizhang  wrote:
> Hello friends here.
>
>
>  I would like ask a question ,it probably looks silly, but I still want 
> to know. As the subject said, when time do we need to delete .m2/repository 
> files ? Does anyone improve my mind ? Thank you very much!
>
>
> Thanks
> Rice.

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

Re: dll hell

[Robert Patrick]

What exactly are you trying to do with this class?  This class appears to be an 
internal JDK implementation class related to the javax.imageio package.  I 
wrote a simple example yesterday with only JAVA_HOME defined and 
%JAVA_HOME%/bin in my path and the class loaded fine without me having to 
explicitly load the native library.  In fact, when I tried to load it 
explicitly, I got an error saying that the library had already been loaded...




> On Aug 29, 2017, at 7:14 AM, Martin Gainty  wrote:
> 
> 
> 
> 
> ____
> From: Robert Patrick 
> Sent: Monday, August 28, 2017 5:34 PM
> To: Maven Users List
> Subject: RE: dll hell
> 
> Since you mentioned DLLs in the subject, I assume this is Windows.
> 
> Is the %JAVA_HOME%/jre/bin directory (where jpeg.dll lives) in the PATH?
> 
> MG>%JAVA_HOME%/jre/bin is on the path and %JAVA_HOME%/jre/bin on 
> java.library.path
> MG>
>String mPath = 
> "C:\\Java\\JDK1.8\\jre\\bin";
>String langKey = "java.library.path" ;
>System.setProperty ( langKey, mPath );
> MG>verified by successful System.load("JDK1.8/jre/bin/jpeg.dll")
> 
> MG>C:\MAVEN-~1\MA095B~1\APACHE~1>dir %JAVA_HOME%\jre\bin\jpeg.dll
> MG> Directory of C:\Java\jdk1.8\jre\bin
> MG>   05/03/2015  07:05 PM   185,768 jpeg.dll
> 
> MG> /** Sets up per-writer native structure and returns a pointer to it. */
> MG>private native long initJPEGImageWriter();
> 
> MG>which causes:
> MG>Caused by: java.lang.UnsatisfiedLinkError: 
> JPEGImageWriter.initJPEGImageWriter()J
> 
> MG>openjdk suggests re-making the jpeg.dll with USE_SYSTEM_JPEG=true directive
> MG>https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dopenjdk-2Ddistro-2Dpkg-2Ddev-26m-3D136573001932634-26w-3D2&d=DwIFAw&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=VajCl24eKyVkpuuL2_5eMx4D_cDqnCwFGIiTFU_bVtM&s=inOW5Sns-TKwPr9vvINfZaWS-csOsVFRCMhhjgQVwZ8&e=
>  
> 
> MG>i read somewhere that JNIEXPORT needs to be declared for each function in 
> the C dll for jpeg.dll
> MG>At present i dont know how to to reverse engineer jpeg.dll to add 
> JNIEXPORT signature for these functions
> 
> MG>Which option do you suggest?
> MG>Thanks Patrick
> MG>Martin-
> 
> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Monday, August 28, 2017 4:25 PM
> To: users@maven.apache.org
> Subject: dll hell
> 
> attempting to call native long initJPEGImageWriter(); in JPEGImageWriter 
> ..when i call initJPEGImageWriter i get:
> 
> 
> java.lang.UnsatisfiedLinkError: JPEGImageWriter.initJPEGImageWriter()
> 
> 
> ive read System.loadLibrary("jpeg") in static initialiser is "supposed to 
> load" jpeg library:
> 
> 
> static {
>java.security.AccessController.doPrivileged(
>new java.security.PrivilegedAction()
>{
>public Void run() {
> System.loadLibrary("jpeg");
>  } //end run
>  }); //end doPrivileged/PrivilegedAction } //end static
> 
> 
> is supposed to load library but
> 
> 
> when i call initJPEGImageWriter i get
> 
> 
> java.lang.UnsatisfiedLinkError: JPEGImageWriter.initJPEGImageWriter()
> 
> 
> advice appreciated
> 
> Martin
> __
> 
> 
> -
> 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: dll hell

[Robert Patrick]

Since you mentioned DLLs in the subject, I assume this is Windows.

Is the %JAVA_HOME%/jre/bin directory (where jpeg.dll lives) in the PATH?   


-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com] 
Sent: Monday, August 28, 2017 4:25 PM
To: users@maven.apache.org
Subject: dll hell

attempting to call native long initJPEGImageWriter(); in JPEGImageWriter ..when 
i call initJPEGImageWriter i get:


java.lang.UnsatisfiedLinkError: JPEGImageWriter.initJPEGImageWriter()


ive read System.loadLibrary("jpeg") in static initialiser is "supposed to load" 
jpeg library:


static {
java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction()
{
public Void run() {
System.loadLibrary("jpeg");
  } //end run
  }); //end doPrivileged/PrivilegedAction } //end static


is supposed to load library but


when i call initJPEGImageWriter i get


java.lang.UnsatisfiedLinkError: JPEGImageWriter.initJPEGImageWriter()


advice appreciated

Martin
__


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

Re: How to up date a property in a POM to a specific value

[John Patrick]

If your talking about the codehaus version plugin which is now hosted
at mojohaus, it's a different mailing list i think...

http://www.mojohaus.org/versions-maven-plugin/mail-lists.html



On 23 August 2017 at 21:07, Sandra Parsick  wrote:
> Thanks for your answers.
>
> Passing the property value from command line don't meet my condition,
> because the new value has to be stored in the POM.
>
> I found out that a new mojo called "set-property" was implemented in the
> current master branch of versions maven plugin. This mojo would meet my
> use cases.
>
> Does it exist a target date for the next release of version maven plugin?
>
> Best regards,
>
> Sandra
>
>
> Am 22.08.2017 um 11:07 schrieb Anders Hammar:
>> Specifying property values from command line when doing a release could be
>> bad practice, as the pom deployed would not contain the value from command
>> line. It all depends on what the property is used for.
>>
>> /Anders
>>
>> On Tue, Aug 22, 2017 at 10:34 AM, John Patrick 
>> wrote:
>>
>>> I think I do similar and I simply use
>>> -DpropertyName=newValueForProperty on the command line when executing
>>> the maven command, or via a profile and then activate the required
>>> profile.
>>>
>>> Just checking the property is already defined in a pom e.g.
>>> ..oldValueForProperty>> propertyName>
>>>
>>> At build time I would simply change the command line I'm using to
>>> build. I do this type of thing all the line when testing new
>>> dependencies, different external systems, loading different
>>> properties/config via a different dependency.
>>>
>>> John
>>>
>>>
>>> On 21 August 2017 at 08:50,   wrote:
>>>> Hello mailing,
>>>>
>>>> I use property values, defined in a POM, during resource filtering. I'd
>>> like to change this properties during my release process. I know that the
>>> Maven Version Plugin has a goal named update-properties. But it requires
>>> that the properties are used in the dependency definition. I search for
>>> something like 'set-property -Dname=propertyName
>>> -Dvalue=newValueForProperty'. Do you know a Maven Plugin that supports this
>>> use case?
>>>>
>>>> Thank you and best regards,
>>>>
>>>> Sandra Parsick
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>

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

Re: How to up date a property in a POM to a specific value

[John Patrick]

I think I do similar and I simply use
-DpropertyName=newValueForProperty on the command line when executing
the maven command, or via a profile and then activate the required
profile.

Just checking the property is already defined in a pom e.g.
..oldValueForProperty

At build time I would simply change the command line I'm using to
build. I do this type of thing all the line when testing new
dependencies, different external systems, loading different
properties/config via a different dependency.

John


On 21 August 2017 at 08:50,   wrote:
> Hello mailing,
>
> I use property values, defined in a POM, during resource filtering. I'd like 
> to change this properties during my release process. I know that the Maven 
> Version Plugin has a goal named update-properties. But it requires that the 
> properties are used in the dependency definition. I search for something like 
> 'set-property -Dname=propertyName -Dvalue=newValueForProperty'. Do you know a 
> Maven Plugin that supports this use case?
>
> Thank you and best regards,
>
> Sandra Parsick
>
> -
> 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: rat:check bad default?

[John Patrick]

Does this help?
https://maven.apache.org/settings.html#Plugin_Groups

Maybe something like this...


org.apache.maven.plugins
org.apache.rat
org.mojohaus.mojo
org.codehaus.mojo


With codehaus dead, either moved to github or mojohaus, the scan
ordering might need to be changed for future releases.

Not sure if you can do it within the pom.xml, or it's purely a
settings.xml change needed.

John


On 21 July 2017 at 18:48, Jason Kuster  wrote:
> Hi,
>
> I had a problem which I was fighting with for a few hours before figuring
> out. I was trying to run the rat plugin manually against my project by
> invoking `mvn rat:check`. It was failing to pick up the configuration I was
> putting in my pom no matter what I did.
>
> I finally noticed after a while that I was configuring
> org.apache.rat:apache-rat-plugin in my pom, but that mvn rat:check was
> executing the `rat-maven-plugin` instead. It appears that the codehaus rat
> maven plugin (last developed in 2007) is what is resolved by invoking
> `rat`, and that running the modern rat plugin requires fully qualifying the
> name on the command line. I have two questions.
>
> First, is it possible to set an override in my project's pom to clarify
> that when I or another developer execute `mvn rat:check` I mean
> org.apache.rat:apache-rat-plugin instead of
> org.codehaus.mojo:rat-maven-plugin?
>
> Second, is it possible to fix this on a more global scale so that other
> folks don't run into the same problem in the future?
>
> Best,
>
> Jason

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

RE: Jenkins Maven build not seeing my .mvn folder?

[Robert Patrick]

The problem is that Jenkins always builds from a directory other than your 
project root directory, so it uses -f to point at the root project POM.  Before 
I changed the shell scripts, the search for the .mvn directory was always 
starting at the current directory (which is why Jenkins never found the .mvn 
directory in the project directory.  Now, if -f is specified, we start the 
search for the .mvn directory at the directory where the POM is and search 
upwards.  This has the effect of making the search return the same result 
whether I run Maven from the project directory where the POM lives or run it 
from somewhere else using -f to point to the POM.


-Original Message-
From: Eric B [mailto:ebenza...@gmail.com] 
Sent: Wednesday, June 07, 2017 9:56 AM
To: Maven Users List
Subject: Re: Jenkins Maven build not seeing my .mvn folder?

Thanks for the links and the info, but after reading MNG-5889, I'm even more 
confused.

Am I to understand that MNG-5889 is specifically regarding Maven to look for 
the .mvn folder in the directory of the invoked pom file rather than in the 
current working directory?  Will this break my current structure in which my 
.mvn folder is in my project root rather than the parent-pom folder?

What is the "right" structure for something like this?

Thanks,

Eric

On Tue, Jun 6, 2017 at 2:31 PM, Arnaud Héritier  wrote:

> It is 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
> _jira_plugins_servlet_mobile-23issue_MNG-2D5889&d=DwIFaQ&c=RoP1YumCXCg
> aWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_Oz
> wdxJosG0&m=DKZbfvfOJ877bL08jqrSvN62YONIRSjetJmqdDQOI5c&s=YbXM6yIwnPBd6
> 3HpjgNrJBLFNGJp3iMljW2p0FjVWYg&e=
>
>
> Le mar. 6 juin 2017 à 20:27, Arnaud Héritier  a 
> écrit :
>
> > The problem with extensions is different. And I don't think we'll fix it.
> > The problem .mvn and usage of -f is a maven bug fixed in 3.5.0 or 
> > 3.5.1
> >
> > Le mar. 6 juin 2017 à 19:36, Pascal  a écrit :
> >
> >> The existing bug to support core extensions:
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jenkins
> >> -2Dci.org_browse_JENKINS-2D30058&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQc
> >> xBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> >> m=DKZbfvfOJ877bL08jqrSvN62YONIRSjetJmqdDQOI5c&s=-xoxaqwRjn1MZ3sswGF
> >> -jUbPTk6ZcaTliheKgJ4mcIM&e=
> >>
> >> As I said, the only solution so far is to use a Freestyle project. 
> >> You
> can
> >> find more details in the bug comments.
> >>
> >> Pascal
> >>
> >>
> >> 2017-06-06 19:27 GMT+02:00 Pascal :
> >>
> >> > Hello,
> >> >
> >> > I fear you have done everything correctly and the issue is with 
> >> > the Jenkins Maven plugin. There is already a bug report in the 
> >> > Jenkins
> Maven
> >> > Plugin, but it's hard to find. If I recall how to find it, I will 
> >> > post
> >> it
> >> > here.
> >> >
> >> > Unfortunately, it does not look like an easy bug, so you cannot 
> >> > use
> the
> >> > "Maven" Job type in Jenkins together with the .mvn folder feature.
> >> However,
> >> > what you can do is create a Freestyle Job and add a build step 
> >> > "Call
> >> Maven
> >> > goals".
> >> >
> >> > Cheers,
> >> >
> >> > Pascal
> >> >
> >> >
> >> > 2017-06-06 18:13 GMT+02:00 Eric B :
> >> >
> >> >> Hi,
> >> >>
> >> >> I'm cross posting this to StackOverflow ( 
> >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverfl
> >> >> ow.com_q_44394234_827480&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX
> >> >> 5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> >> >> DKZbfvfOJ877bL08jqrSvN62YONIRSjetJmqdDQOI5c&s=S_n7abikLs0LWBcnJf
> >> >> Z-R-AkRN85ejJyezl_Nvwt4D8&e= ) b/c I'm not truly
> >> convinced
> >> >> this is a maven question per say.  Rather I think it is more
> something
> >> due
> >> >> to my Jenkins job config that is causing some issues, but I am 
> >> >> hoping
> >> that
> >> >> maven users here may have encountered this in Jenkins as well.
> Either
> >> >> that, or maybe someone can point out that I'm using the .mvn 
> >> >> folder incorrectly.
> >> >>
> >> >> Essentially, I have a multi-module maven project that is set up as:
> >> >>
> >> >> |.mvn
> >> >>  \-maven.config
> >> >>  \-jvm.config
> >> >> |superpom
> >> >>  \-pom.xml (main project parent pom, includes module defns)
> >> >> |module1
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)  \src
> >> >>   \...
> >> >> |module2
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)  \src
> >> >>   \...
> >> >>
> >> >> My maven.config file is defined as:
> >> >>
> >> >> -Dsign.alias=cert
> >> >> -Dsign.storepass=changeit
> >> >> -Dsign.keypass=changeit
> >> >> -Dcheckstyle.skip=true
> >> >> -Dcobertura.skip=true
> >> >> -Dpmd.skip=true
> >> >> -DskipTests=true
> >> >> -DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
> >> >> -DuserName=test
> >> >> -Dpassword=test
> >> >> -f superpom/pom.xml
> >> >>
> >> >> If I run my maven build from the command line, everything build

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause this 
can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:
> Hi Karl,
>
> If I define the revision property in the top-level POM, I cannot refer to it 
> in the module POMs'  elements *and* still retain the ability to build 
> from the module directory, right?  I tried this and it failed because it was 
> unable to resolve the revision property variable.
>
> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO] 
> Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for 
> oracle.jcs.lifecycle:util:[unknown-version
> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} 
> in 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwIDaQ&c=RoP1Y
> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr
> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9ucii
> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
> rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the 
> local reposito ry, resolution will not be reattempted until the update 
> interval of repo1 has el apsed or updates are forced and 
> 'parent.relativePath' points at wrong local POM @ line 7, column 13  @ 
> [ERROR] The build could not read 1 project -> [Help 1] [ERROR]
> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] 
> (C:\rpatrick\w
> ork\projects\jcs-las\util\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for 
> oracle.jcs.lifecycle:util:[unknown-ver
> sion]: Failure to find 
> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the 
> local repo sitory, resolution will not be reattempted until the update 
> interval of repo1 ha s elapsed or updates are forced and 
> 'parent.relativePath' points at wrong local POM @ line 7, column 13 -> 
> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors, 
> re-run Maven with the -e swit ch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, 
> please rea d the following articles:
> [ERROR] [Help 1] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRoH
> s2ncTiyaZSJWc3AEyEsUQ&e=
> gException
> [ERROR] [Help 2] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZrq
> XoHWM-jV5GAbTtEvug-bc&e=
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so 
> the only solution is to move the  >  version number outside the POM 
> hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you 
> like and can overwrite the version via command line (-Drevision=...).
>
>
>
>  > While this works, it seems to have some undesirable  > aspects to 
> it.  In my opinion, it would be better if  > Maven could find a way to 
> resolve this issue  > without resorting to -Ds to specify the  > value 
> of the variable.
>  > I am not sure it is possible but I also worry  > about moving the 
> version number outside the POM...
>>
>> Maybe Maven should consider a mechanism by which the proje

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

Hi Karl,

If I define the revision property in the top-level POM, I cannot refer to it in 
the module POMs'  elements *and* still retain the ability to build from 
the module directory, right?  I tried this and it failed because it was unable 
to resolve the revision property variable.

C:\rpatrick\work\projects\jcs-las\util>mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local reposito
ry, resolution will not be reattempted until the update interval of repo1 has el
apsed or updates are forced and 'parent.relativePath' points at wrong local POM
@ line 7, column 13
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
sion]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local repo
sitory, resolution will not be reattempted until the update interval of repo1 ha
s elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 7, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException


Did I miss something?

Thanks,
Robert

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:

> With 3.5, you can now use a variable *but* that variable
 > has to be accessible to the POM prior to finding its  > parent so the only 
 > solution is to move the  >  version number outside the POM hierarchy and 
 > into a -D defined
> variable.

Which is not true. You can define the property inside the pom file if you like 
and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...
>
> Maybe Maven should consider a mechanism by which the project version number 
> can be defined in a separate location that is:
>
> 1.) Well-known so that all resolution can happen directly by interacting with 
> this location directly, without the need to traverse the parent hierarchy
> 2.) It is part of the project structure so that it can be managed in the 
> project's source control system
> 3.) It cannot be overridden at build time with command-line arguments.
> 4.) Has a mechanism by which to reference it from all the necessary locations 
> within the POMs
>
> Maybe something like an optional .mvn/project.version file and a variable 
> that cannot be overridden to refer to it?
>
> -Original Message-
> From: Eric Benzacar [mailto:e...@benzacar.ca]
> Sent: Thursday, May 04, 2017 12:53 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> I've read through Karl's blog 
> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
> the approach, there is still one critical issue that bothers me.  I think 
> this actually reopens an old thread that circulated on this list a few months 
> ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every 
>>single build of a given NON-SNAPSHOT pom file should finish with the same 
>>build.  But by moving a release number or version number outside of the pom, 
>>it eliminates this need.  Furthermore, from 

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

The problem is that I really want to control the version number for a project 
from a single place.  Ideally, this would be the  element of the 
project's top-level POM.  The problem is that there is no way to do this 
because the module POMs have to declare a parent element that can be resolved 
to find the parent (before they actually find their parent).  Prior to 3.5, you 
were forced down the rabbit hole with using hard-coded parent version numbers 
in the module POM and the release plugin was/is the simplest way (that I have 
found) of handling version number changes across a large project.

With 3.5, you can now use a variable *but* that variable has to be accessible 
to the POM prior to finding its parent so the only solution is to move the 
version number outside the POM hierarchy and into a -D defined variable.  While 
this works, it seems to have some undesirable aspects to it.  In my opinion, it 
would be better if Maven could find a way to resolve this issue without 
resorting to -Ds to specify the value of the variable.  I am not sure it is 
possible but I also worry about moving the version number outside the POM...

Maybe Maven should consider a mechanism by which the project version number can 
be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by interacting with 
this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the 
project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations 
within the POMs

Maybe something like an optional .mvn/project.version file and a variable that 
cannot be overridden to refer to it? 

-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca] 
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
the approach, there is still one critical issue that bothers me.  I think this 
actually reopens an old thread that circulated on this list a few months ago, 
but it related to the Idempotence of a pom file.

>From my perspective/view a pom file should be idempotent.  That is every 
>single build of a given NON-SNAPSHOT pom file should finish with the same 
>build.  But by moving a release number or version number outside of the pom, 
>it eliminates this need.  Furthermore, from a traceability perspective, my 
>source control can no longer show me precisely version was being 
>built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but none 
the less, the value can be overridden at build time with a completely different 
value.  Consequently, I can still not be 100% confident that a pom delivered a 
particular version.

I'm still not 100% sure of the best approach going forward, but I'm thinking 
that something like the version-plugin being able to manipulate a revision 
property that can then be committed as part of the pom would be the best of 
both approaches.  In that way, my developers can fix the version number, but my 
build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer  wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with 
> > > > >> small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
> > > > >> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
> > > > >> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
> > > > >> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
> > > > >> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
> > > > >> e=
> > > > >> t-a-version-in-it/
> >
>

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

RE: dependency question

[Robert Patrick]

For example, if I want to depend on the latest version of the artifact un the 
1.1.x version range, I would put:


test
myartifact
[1.1,1.1.9]


This says give me the latest version whose number is greater than or equal to 
1.1 and less than or equal to 1.1. 9 (where I randomly chose 9 
to be greater than any incremental version I will ever create.  

This version range can also be written [1.1, 1.2) where the close parent 
indicates a non-inclusive range end (i.e., less than 1.2).  The thing to be 
aware of with this syntax is that it also includes any pre-release versions of 
1.2 (e.g., 1.2-alpha-1 is included).  For more information, please see section 
3.4.3 of 
http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
 and http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html 


--
Robert Patrick 
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/


-Original Message-
From: Magnanao, Hector [mailto:hector.magna...@sap.com] 
Sent: Friday, April 07, 2017 10:28 AM
To: Maven Users List
Subject: RE: dependency question

Can you give me an example of using a range in the pom file as a dependency ?

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Thursday, April 6, 2017 2:34 PM
To: Maven Users List 
Subject: RE: dependency question

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


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


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


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


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

RE: dependency question

[Robert Patrick]

Typically, whenever you run a build that includes a snapshot dependency, Maven 
will go out to the remote repository(ies), if any, and download the 
maven-metadata.xml file for that dependency to compare it against the snapshot 
stored in your local Maven repository to see if there is a newer version that 
needs to be downloaded.  For example, when I run one of our builds, I see this 
in the build output when there is a newer snapshot version:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.4 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
 (3 KB at 12.5 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
 (43 KB at 25.3 KB/sec)

And this output when there is not:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.7 KB/sec)

Whether it downloads and checks the maven-metadata.xml file every time or 
periodically is (at least somewhat) controlled by the repository declaration in 
your POM/settings.xml for the repository's updatePolicy.  For example, this is 
what one of our builds uses:


false
always
fail



-Original Message-
From: Russell Gold 
Sent: Friday, April 07, 2017 10:30 AM
To: Maven Users List
Subject: Re: dependency question

That’s the way it works: when you specify a snapshot, it takes the latest. 

There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to .
> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector  wrote:
> 
> If the builds for A are always getting a unique build number as a snapshot 
> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
> there a way to name the A snapshot builds with a unique build number each 
> time for this scenario.
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com]
> Sent: Thursday, April 6, 2017 2:27 PM
> To: Maven Users List 
> Subject: Re: dependency question
> 
> The simplest way is simply to use a snapshot version of A. That way B will 
> always use the latest snapshot. When you finally release A, you can have B 
> point to the released version instead of the snapshot.
> 
>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
>> 
>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>> as a dependency.  How do I ensure the whenever the A project has a new 
>> build,  the B project will always use that latest build in A.  A is being 
>> built with a unique build number each time it gets built.  So is A has build 
>> # 10 as the newest build,  the B project has to use build #10 of A.
>> 
>> 
>> Hector Magnanao Jr.
>> SCM Analyst
>> SAP Fieldglass
>> Skype:  (331) 702-6142
>> Mobile:  (847) 857-8401
>> Email: hector.magna...@sap.com
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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


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

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

[Robert Patrick]

ces (default-testResources) @
consumer ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\test\maven-test\multi-module-test\
consumer\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ consume
r ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ consumer ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ consumer ---
[INFO] Building jar: C:\test\maven-test\multi-module-test\consumer\target\consum
er-1.0.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ consumer ---
[INFO] Installing C:\test\maven-test\multi-module-test\consumer\target\consumer-
1.0.jar to C:\Users\RPATRICK\.m2\repository\test\consumer\1.0\consumer-1.0.jar
[INFO] Installing C:\test\maven-test\multi-module-test\consumer\pom.xml to C:\Us
ers\RPATRICK\.m2\repository\test\consumer\1.0\consumer-1.0.pom
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] multi-module-test .. SUCCESS [  0.524 s]
[INFO] generator .. SUCCESS [  3.373 s]
[INFO] consumer ... SUCCESS [  0.245 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 4.864 s
[INFO] Finished at: 2017-04-06T16:07:09-05:00
[INFO] Final Memory: 19M/373M
[INFO] 

C:\test\maven-test\multi-module-test>


-Original Message-
From: David Hoffer [mailto:dhoff...@gmail.com] 
Sent: Thursday, April 06, 2017 3:26 PM
To: Maven Users List
Subject: Re: How to add class file to build & classpath?

I'll try to reply to the last 3 posts...

Unfortunately the code uses compiled classes from other modules.  So I can't 
change the phase to prior to compile, if I do that then it doesn't generate the 
sources.

I did find a way to generate sources instead of class files as I agree that is 
a lot nicer...its not quite as easy as javassist but close enough.

However I could not find any combination of moving phases around/etc to make 
this work...as I mentioned above if I changed the exec plugin phase to be prior 
to compile then it didn't do anything so there was no generated sources to 
compile.  It seems Maven just just does not like subprocesses that generate 
more sources using the compiled code.

I will look at the above sample projects to see what I missed.

For now I have changed things so that I put my generated code right in the 
src/main/java folder then wrap the exec plugin in a profile so I can manually 
run that when needed.  Not ideal but its working.  Will investigate the other 
projects.

-Dave

On Thu, Apr 6, 2017 at 1:27 PM, Robert Patrick 
wrote:

> I also built a little sample project where I simulated a generated 
> class using the maven-resources-plugin to copy a class into the 
> target/classes directory during the process-resources phase.  My unit 
> test in that module works fine and the other module that consumes that 
> class (via a normal
> dependency) works fine in a multi-module build.  Maybe the issue you 
> are having can be solved by simply moving the exec-maven-plugin 
> execution to the process-resources phase?
>
>
>
> -Original Message-
> From: David Hoffer [mailto:dhoff...@gmail.com]
> Sent: Thursday, April 06, 2017 12:45 PM
> To: Maven Users List
> Subject: Re: How to add class file to build & classpath?
>
> Yes that is the location the class file(s) are being created in.  And 
> yes I am binding the exec-maven-plugin to the compile phase in my pom 
> (see prior email).  Also the class(s) file is being included in the 
> resulting jar.
> However all this is not sufficient for Maven to notice the class(s) 
> file was generated and add to the build and classpath.
>
> I think part of the reason is that in multi-module maven builds it 
> does not use the jars for the classpath but rather the pre-jar content 
> (not 100% certain of that).  However I don't know why Maven doesn't 
> add/use all files in the ./target/classes folder but only uses files that it 
> put there itself.
>
> What am I missing here?  It seems this should just work because the 
> files are in the ./target/classes folder.
>
> -Dave
>
> On Thu, Apr 6, 2017 at 10:55 AM, Robert Patrick 
>  >
> wrote:
>
> > Can't you generated class files in the expected location (in 
> > ${project.build.directory}/classes directory) during the compile phase?
> > I would expect these classes to be included in classpath for later 

RE: dependency question

[Robert Patrick]

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
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: How to add class file to build & classpath?

[Robert Patrick]

I also built a little sample project where I simulated a generated class using 
the maven-resources-plugin to copy a class into the target/classes directory 
during the process-resources phase.  My unit test in that module works fine and 
the other module that consumes that class (via a normal dependency) works fine 
in a multi-module build.  Maybe the issue you are having can be solved by 
simply moving the exec-maven-plugin execution to the process-resources phase?



-Original Message-
From: David Hoffer [mailto:dhoff...@gmail.com] 
Sent: Thursday, April 06, 2017 12:45 PM
To: Maven Users List
Subject: Re: How to add class file to build & classpath?

Yes that is the location the class file(s) are being created in.  And yes I am 
binding the exec-maven-plugin to the compile phase in my pom (see prior email). 
 Also the class(s) file is being included in the resulting jar.
However all this is not sufficient for Maven to notice the class(s) file was 
generated and add to the build and classpath.

I think part of the reason is that in multi-module maven builds it does not use 
the jars for the classpath but rather the pre-jar content (not 100% certain of 
that).  However I don't know why Maven doesn't add/use all files in the 
./target/classes folder but only uses files that it put there itself.

What am I missing here?  It seems this should just work because the files are 
in the ./target/classes folder.

-Dave

On Thu, Apr 6, 2017 at 10:55 AM, Robert Patrick 
wrote:

> Can't you generated class files in the expected location (in 
> ${project.build.directory}/classes directory) during the compile phase?
> I would expect these classes to be included in classpath for later 
> pahses and in the JAR created during the packaging phase of the module 
> build (assuming packaging type is "jar").  Have you tried that?
>
>
>
> -Original Message-
> From: Curtis Rueden [mailto:ctrue...@wisc.edu]
> Sent: Thursday, April 06, 2017 11:34 AM
> To: Maven Users List
> Subject: Re: How to add class file to build & classpath?
>
> Hi Dave,
>
> > I'm using exec-maven-plugin to call a main in my code that uses 
> > javassist to generate a class file at build time.
>
> The more common pattern is to generate .java source files, and then 
> include them in the build.
>
> Since you are generating .class file(s), could you do it in a separate 
> module of a multi-module build, then add that module as a dependency 
> to your main project module?
>
> Could you post an MCVE, particularly your POM, which shows your 
> current approach?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.proofpoint&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=hpzCbX-p3CruRsEhA_MZO805q6XsrzWSSqkZCm7IfAs&s=K-Fe2PmitKUNWXWy2vB1JvN-Ih5TBC0VwxThPwDenU8&e=
>  .
> com/v2/url?u=https-3A__loci.wisc.edu_software&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=
> yDl8PjVnueV1WAKs6W36AGN5yriHr-5eTXTPZi_k0kk&e=
> ImageJ2 lead, Fiji maintainer - 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.proofpoint&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=hpzCbX-p3CruRsEhA_MZO805q6XsrzWSSqkZCm7IfAs&s=K-Fe2PmitKUNWXWy2vB1JvN-Ih5TBC0VwxThPwDenU8&e=
>  .
> com/v2/url?u=https-3A__imagej.net_User-3ARueden&d=DwIBaQ&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=
> sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=
> biFYk60WuoVvD5FQonUNvMwQmBxfAOcXn6XyvvRRVDw&e=
>
>
> On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer  wrote:
>
> > I'm using exec-maven-plugin to call a main in my code that uses 
> > javassist to generate a class file at build time.  My code places 
> > the class file in the ./target/classes folder so it gets included in 
> > the modules normal binary jar.
> >
> > However the rest of the build and other code needs to know that the 
> > class exists.  I've added that module/artifact as a dependency but 
> > the build
> and
> > the runtime classpath has no idea that class exists.
> >
> > How do I add it to the build and runtime classpath?
> >
> > -Dave
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

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

[Robert Patrick]

Can't you generated class files in the expected location (in 
${project.build.directory}/classes directory) during the compile phase?  I 
would expect these classes to be included in classpath for later pahses and in 
the JAR created during the packaging phase of the module build (assuming 
packaging type is "jar").  Have you tried that?



-Original Message-
From: Curtis Rueden [mailto:ctrue...@wisc.edu] 
Sent: Thursday, April 06, 2017 11:34 AM
To: Maven Users List
Subject: Re: How to add class file to build & classpath?

Hi Dave,

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

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

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

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

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__loci.wisc.edu_software&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=yDl8PjVnueV1WAKs6W36AGN5yriHr-5eTXTPZi_k0kk&e=
ImageJ2 lead, Fiji maintainer - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__imagej.net_User-3ARueden&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=sAgPJflD39NrfRATxD1qVSvbRHcZlzbPxQqHpteGc0M&s=biFYk60WuoVvD5FQonUNvMwQmBxfAOcXn6XyvvRRVDw&e=
 


On Thu, Apr 6, 2017 at 10:48 AM, David Hoffer  wrote:

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

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

Re: Is there a way to make mvn default to Java 8?

[John Patrick]

If you only have Java 8 installed, would that work? Or does target
still default to something older? I've got Java 7, 8 and 9 on my
machine so can't easily test myself.


On 13 January 2017 at 17:04, Chris Barlock  wrote:
> Most projects I've been on have a notion of a "parent" or "common" script
> (whether Ant, Maven or just about anything else).  With Maven, you could
> define a  POM that contains all the common stuff.  Of course, you
> would have to add the parent element to all child POMs, but if you ever
> want to change something in the parent (such as this Java version), you
> would only have to do it once.
>
> Chris
>
>
>
>
> From:   Dean Schulze 
> To: users@maven.apache.org
> Date:   01/13/2017 11:51 AM
> Subject:Is there a way to make mvn default to Java 8?
>
>
>
> I would like to avoid having to add
>
> 
> 1.8
> 1.8
> 
>
> to every pom.xml.  Is there a global setting I can set in mvn to make Java
> 8 the default so I don't have to add this to every pom.xml?
>
>
>
>

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

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

[Robert Patrick]

Right, it looks at versions to try to find the latest version number.  

If you don’t want to compute the value dynamically, The simplest way to set a 
property is using -Dgrandparent.version=1.2.3 on the command-line (or in the 
project's .mvn/maven.config file).  Another way that you might solve the 
problem is simply by chaining properties.  In any one of the parent hierarchy 
POMs, set ... and then in the module 
POM, just say ${grandparent.version}.  For example, if you 
put this in the parent POM, just set 
${project.parent.version}.



-Original Message-
From: Florian Schätz [mailto:fscha...@assona.net] 
Sent: Monday, December 05, 2016 7:51 AM
To: users@maven.apache.org
Subject: Re: ${project.parent.parent.version} does not work

Am Sonntag, den 04.12.2016, 14:56 -0600 schrieb Robert Patrick:

> versions:update-property seems like a good choice.

Unfortunately, the important word is "seems". versions:update-property does 
some complicated stuff, I have not yet found a way to simply use it to set 
property X to value Y. It does some strange range stuff, etc.

> Sent from my iDevice
> 
> > On Dec 4, 2016, at 8:22 AM, Florian Schätz  wrote:
> > 
> > Hello,
> > 
> >> For now, you can make that property a constant in the grandparent 
> >> like "1.0.0-SNAPSHOT" 
> >> and use that property itself in the grandparent like 
> >> "${grandparent.version}". Should not override 
> >> that property in modules, of course.
> > 
> > But that would require me to always update that property somehow whenever I 
> > call versions:set, too. Will have to search for an easy way to do so. Any 
> > suggestions?
> > 
> > Regards,
> > 
> > Florian
> > 
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

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

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

[Robert Patrick]

versions:update-property seems like a good choice.


Sent from my iDevice

> On Dec 4, 2016, at 8:22 AM, Florian Schätz  wrote:
> 
> Hello,
> 
>> For now, you can make that property a constant in the grandparent like
>> "1.0.0-SNAPSHOT" and use that
>> property itself in the grandparent like
>> "${grandparent.version}". Should not override that
>> property in modules, of course.
> 
> But that would require me to always update that property somehow whenever I 
> call versions:set, too. Will have to search for an easy way to do so. Any 
> suggestions?
> 
> Regards,
> 
> Florian
> 
> -
> 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: Structuring bigger Maven projects

[John Patrick]

I've worked on several large 'enterprise' projects, several could have
been 4-6 projects in their own right so maybe 12 ear's, one had 120
pom files. Lucky it got refactored and split into I think 40 repos.

I would suggest;
) branching, using git flow method.

) jgit-flow plugin (https://bitbucket.org/atlassian/jgit-flow), not
maven-release-plugin

) deployment, now only using Ansible as finding easier to use than chef/puppet

) versioning, using
http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html
have a release profile in the companies parent pom

) for code quality, using atlassian stash which is forcing 1
successful build and 1 approver before for code to be merged into
develop, successful build also means code, test, findbugs etc.

) cim, still using jenkins v1, not upgraded to v2 yet. have a mix of
jobs, most deployable artifacts have a pipelines checking develop and
waiting for 15 mins before kicking off a build to allow multiple
merges, then automatically building, deploying and configuring using
ansible to the development environment, running qa step(s) either
cucumber or selenium, if they all pass then automatically creating a
release candidate and closing the release branch and merging into
master

) 1 git repo for each deployable artifact
) git repo for shared code/framework, logically group so not all in 1
repo but not all with their own repo.

) each logical cucumber project was it's own git repo, so if it
changed it was easier to automatically trigger it's execution

) jenkins or what every cim you pick, use multiple slaves to run the
tasks, yes you could get everything running on the master jenkins node
but it will quickly become overload.

) this is how I do release, with the mvn -Pdo-release -N validate, it
will bump the version numbers create the release branch, automatically
finish it, tag it, so develop branch always see -SNAPSHOT's and master
never sees -SNAPSHOT's http://pastebin.com/DbAGACk7


John


On 30 November 2016 at 18:44, Karl Heinz Marbaise  wrote:
> Hi,
>
>
>
> On 30/11/16 19:18, Florian Schätz wrote:
>>>
>>> A library project to be
>>> shared between multiple applications each having its own release-cycle
>>> should not be part of a multi-module project used to build such an
>>> application and should be an independent project with its own
>>> release-cycle.
>>
>>
>> While this is of course a good idea, especially when starting to create
>> new applications, the library projects will grow with the applications
>> and not independently of them. We cannot start by first investing months
>> to create the perfect will-work-for-ten-years library and only then
>> start coding the application that will, in the first months, only use
>> 10% of all these features. So, realistically, during a development
>> cycle, both the application and the library will grow... (which doesn't
>> mean that we cannot separate them)
>>
>> Which leads me, for example, to the problem that I still want to
>> automate as much as possible. I would like, for example, to click one
>> button in my build server, perhaps enter some parameters and get a new
>> release candidate of the libraries from the current release branch,
>> update the dependency version of the application to this rc version,
>> make the application an rc (from the application's release branch),
>> install them both into the repository, tag the current status on git and
>> deploy the rc application onto the server.
>>
>> Especially for bigger projects, I want to keep the amount of manual work
>> needed as small as possible. As much building should be done
>> automatically, if possible. And I would like not having to code a
>> jenkins or maven plugin for that purpose (but of course, I would, if
>> needed, no problem there).
>
>
>
> You can simply use maven-release-plugin (in Maven itself) which you can used
> to  fully automatically create releases of your project...This will need
> only a plugin in Jenkins which handles all those stuff...correctly
> configured things like scm entries in your pom file tagging in Git will be
> done as well
>
> Sometimes you might need to improve that using the versions-maven-plugin in
> combination with some pipeline steps in Jenkins...which prevents some
> drawbacks of the maven-release-plugin
>
>
> May be you need to think about using the Maven integration in Jenkins or
> using freestyle projects or better start using pipelines ...(I often
> observed performance drawbacks in relationship with Maven integration in
> Jenkins)...
>
>
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

-
To unsubsc

RE: Maven Compiler Plugin 3.5.1 bug

[Robert Patrick]

Agreed, I didn’t intend to start a religious war over IDEs.

It seems like Eclipse requires a plugin to understand a Maven plugin.  IntelliJ 
takes the opposite approach in that it simply requires this one time manual 
operation instead of a plugin to understand a Maven plugin.   While IntelliJ is 
"inferior" due to requiring this manual configuration, it is really not a big 
deal to do this one-time operation... :-)


-Original Message-
From: Christopher [mailto:ctubb...@apache.org] 
Sent: Sunday, October 23, 2016 12:02 PM
To: Maven Users List; Robert Patrick
Subject: Re: Maven Compiler Plugin 3.5.1 bug

I agree. You can also manually add the directory as a source directory in 
Eclipse. I'd want the IDEs to be able to do this automatically. I don't want to 
get into an IDE war on this thread, though. I just used Eclipse as an example, 
because I know how that currently works. However, it only works because of the 
availability of the build-helper eclipse plugin.
Establishing the convention in the compiler plugin itself might make it easier 
to automate the behavior across IDEs without the need for added plugins.

On Sun, Oct 23, 2016 at 12:56 PM  wrote:

> Manually marking a directory as source is not what I would define as 
> „understands Maven“. Eclipse finds thise directories automatically (if 
> a know plugin is used)
>
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> From Win 10 Mobile
>
> Von: Robert Patrick
> Gesendet: Sonntag, 23. Oktober 2016 18:45
> An: Maven Users List
> Betreff: RE: Maven Compiler Plugin 3.5.1 bug
>
> That's why we use IntelliJ :-)
>
> It understands Maven projects and uses Maven to build them.  In the 
> IDE, you simply cancel the exclusion on the target directory and mark the
> appropriate subdirectory(ies) as a generated sources root.   Nothing to do
> on the IDE side.
>
>
> -Original Message-
> From: Christopher [mailto:ctubb...@apache.org]
> Sent: Sunday, October 23, 2016 11:42 AM
> To: Maven Users List
> Subject: Re: Maven Compiler Plugin 3.5.1 bug
>
> The build-helper-maven-plugin method has the advantage of having a 
> corresponding build-helper plugin in Eclipse, to automatically add the 
> generated sources to the project build path in Eclipse (with m2e). If 
> the compiler plugin started using one of the directories in /target/ 
> as a source directory by default (maybe 
> /target/generated-src/{main,test}/java),
> it might be nice, but at least for me, it'd only really be useful if 
> IDEs also followed that behavior. For now, build-helper is required 
> for this to work in Eclipse (I don't know about other IDEs). If the 
> compiler plugin did this, and IDEs followed suit, I'd think that would be 
> useful.
>
> On Sat, Oct 22, 2016 at 6:50 PM Robert Patrick 
> 
> wrote:
>
> > Thanks, I am aware of that plugin and have used it before.  It sure 
> > seems like the compiler plugin should provide this capability 
> > without the need for yet another plugin to fill the functionality 
> > gaps...don't
> you think?
> >
> >
> > -Original Message-
> > From: Curtis Rueden [mailto:ctrue...@wisc.edu]
> > Sent: Saturday, October 22, 2016 5:48 PM
> > To: Maven Users List
> > Subject: RE: Maven Compiler Plugin 3.5.1 bug
> >
> > You can add source directories using the build-helper-maven-plugin.
> >
> > On Oct 22, 2016 4:39 PM, "Robert Patrick" 
> > 
> > wrote:
> >
> > > I am using the  section of the POM, not my own plugin, 
> > > to populate some tokens in a Java source file that we use to get 
> > > build information (version, git commit/branch info, build timestamp, etc).
> > >
> > > 
> > > 
> > > src/main/resources/templates
> > > 
> > > *.java
> > > 
> > > true
> > >
> > > ${project.build.directory}/generated-sources/
> > > annotations
> > > 
> > >   
> > >
> > > The documentation claims that the default value for the 
> > > generatedSourcesDirectory is this directory so you are saying that 
> > > somehow the fact that the maven-compiler-plugin no longer includes 
> > > the directory in the build is a feature?
> > >
> > > I looked through the compiler plugin's documentation and couldn't 
> > > figure out a way to add a directory to the build.  I know how to 
> > > add the directory to the build if I write my own plugin but that 
> > > seems pretty heavy-handed for something that shoul

RE: Maven Compiler Plugin 3.5.1 bug

[Robert Patrick]

That's why we use IntelliJ :-)

It understands Maven projects and uses Maven to build them.  In the IDE, you 
simply cancel the exclusion on the target directory and mark the appropriate 
subdirectory(ies) as a generated sources root.   Nothing to do on the IDE side.


-Original Message-
From: Christopher [mailto:ctubb...@apache.org] 
Sent: Sunday, October 23, 2016 11:42 AM
To: Maven Users List
Subject: Re: Maven Compiler Plugin 3.5.1 bug

The build-helper-maven-plugin method has the advantage of having a 
corresponding build-helper plugin in Eclipse, to automatically add the 
generated sources to the project build path in Eclipse (with m2e). If the 
compiler plugin started using one of the directories in /target/ as a source 
directory by default (maybe /target/generated-src/{main,test}/java),
it might be nice, but at least for me, it'd only really be useful if IDEs also 
followed that behavior. For now, build-helper is required for this to work in 
Eclipse (I don't know about other IDEs). If the compiler plugin did this, and 
IDEs followed suit, I'd think that would be useful.

On Sat, Oct 22, 2016 at 6:50 PM Robert Patrick 
wrote:

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

[Robert Patrick]

Thanks, I am aware of that plugin and have used it before.  It sure seems like 
the compiler plugin should provide this capability without the need for yet 
another plugin to fill the functionality gaps...don't you think? 


-Original Message-
From: Curtis Rueden [mailto:ctrue...@wisc.edu] 
Sent: Saturday, October 22, 2016 5:48 PM
To: Maven Users List
Subject: RE: Maven Compiler Plugin 3.5.1 bug

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

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

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

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

RE: Maven Compiler Plugin 3.5.1 bug

[Robert Patrick]

I am using the  section of the POM, not my own plugin, to populate 
some tokens in a Java source file that we use to get build information 
(version, git commit/branch info, build timestamp, etc).  



src/main/resources/templates

*.java

true

${project.build.directory}/generated-sources/annotations

  

The documentation claims that the default value for the 
generatedSourcesDirectory is this directory so you are saying that somehow the 
fact that the maven-compiler-plugin no longer includes the directory in the 
build is a feature?  

I looked through the compiler plugin's documentation and couldn't figure out a 
way to add a directory to the build.  I know how to add the directory to the 
build if I write my own plugin but that seems pretty heavy-handed for something 
that should be trivial.  What am I missing? 


-Original Message-
From: Thomas Broyer [mailto:t.bro...@gmail.com] 
Sent: Saturday, October 22, 2016 4:29 PM
To: Maven Users List
Subject: Re: Maven Compiler Plugin 3.5.1 bug

This is not a bug, it's a bug fix! Bug introduced in 3.2, fixed in 3.5.1 (see 
release notes for that version).

Your plugin should use its own output directory and add it as a source root.

Le sam. 22 oct. 2016 23:18, Robert Patrick  a écrit :

> Periodically, I update the versions of the Maven plugins for my projects.
> Today was one of those days.  What I found is that the 
> maven-compiler-plugin 3.5.1's compile goal no longer seems to not be 
> including the ${project.build.directory}/generated-sources/annotations
>
> directory in the compile.
>
>
>
> My project generates a Java file in the process-resources phase and 
> puts the file in this directory.  Other files in the normal 
> src/main/java location include/depend on this generated file.  When I 
> run my build with 3.5, it works perfectly.  When I run the exact same 
> build with 3.5.1, it fails.
>
>
>
> I logged into my Apache Jira account but the compiler plugin project does
> not seem to want to let me create an issue for this.   Is there some sort
> of special permission required to create an issue on the 
> maven-compiler-plugin?
>
>
>
>
>
>
>

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

Re: Maven Compiler Plugin 3.5.1 bug

[John Patrick]

hi robert,

what is the plugin that creates files and puts them into the
generated-sources/annotations directory

as from how i understand it works, the plugin should on execution
dynamically register that new extra directory into the list of source
directories that the maven-compiler-plugin will look at.

as if i manually create
${project.build.directory}/generated-sources/annotations i would not
expect maven-compiler-plugin to know about it, and so compile files
from that directory. if that is how maven-compiler-plugin works then
it would need to be preloaded with all possible generated source
directories of all plugins that generate source.

do you explicit state all plugins your using within your pom? could
the source generation plugin have been updated???

John


On 22 October 2016 at 22:17, Robert Patrick  wrote:
> Periodically, I update the versions of the Maven plugins for my projects.  
> Today was one of those days.  What I found is that the maven-compiler-plugin 
> 3.5.1's compile goal no longer seems to not be including the 
> ${project.build.directory}/generated-sources/annotations
>
> directory in the compile.
>
>
>
> My project generates a Java file in the process-resources phase and puts the 
> file in this directory.  Other files in the normal src/main/java location 
> include/depend on this generated file.  When I run my build with 3.5, it 
> works perfectly.  When I run the exact same build with 3.5.1, it fails.
>
>
>
> I logged into my Apache Jira account but the compiler plugin project does not 
> seem to want to let me create an issue for this.   Is there some sort of 
> special permission required to create an issue on the maven-compiler-plugin?
>
>
>
>
>
>

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

Maven Compiler Plugin 3.5.1 bug

[Robert Patrick]

Periodically, I update the versions of the Maven plugins for my projects.  
Today was one of those days.  What I found is that the maven-compiler-plugin 
3.5.1's compile goal no longer seems to not be including the 
${project.build.directory}/generated-sources/annotations

directory in the compile.

 

My project generates a Java file in the process-resources phase and puts the 
file in this directory.  Other files in the normal src/main/java location 
include/depend on this generated file.  When I run my build with 3.5, it works 
perfectly.  When I run the exact same build with 3.5.1, it fails.  

 

I logged into my Apache Jira account but the compiler plugin project does not 
seem to want to let me create an issue for this.   Is there some sort of 
special permission required to create an issue on the maven-compiler-plugin?

 

 

 

testCompile goal fails periodically on Windows because it cannot find test-classes directory

[Robert Patrick]

Hi,

 

I am seeing a periodic error when running our builds on Windows.  When running 
"mvn clean verify" I occasionally see errors like the following:

 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.5.1:testCompile (test-compile) 
on project single-application-test: Fatal error compiling: directory not found: 
C:\projects\myproject\system-test\tests-v2\singleApplicationTest\target\test-classes
 -> [Help 1]

[ERROR]

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR]

[ERROR] For more information about the errors and possible solutions, please 
read the following articles:

[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

[ERROR]

[ERROR] After correcting the problems, you can resume the build with the command

 

[ERROR]   mvn  -rf :single-application-test

 

If I immediately rerun the same "mvn clean verify" command, it works.  Has 
anyone else seen such problems?

 

Thanks,

Robert

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

[Robert Patrick]

But in a large corporate environment, the centralized repository manager can 
house hundreds/thousands of repositories so unless you want to virtualize the 
entire set of repositories (which tends to make the repository manager slower), 
you still need to specify the repositories to search, right? 


-Original Message-
From: Curtis Rueden [mailto:ctrue...@wisc.edu] 
Sent: Tuesday, October 18, 2016 8:14 AM
To: Maven Users List
Subject: Re: Comparing specifying repositories in pom vs. settings.xml?

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

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

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


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

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

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

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

[Robert Patrick]

My team always favors defining repos in the top-level (parent) POM.  If we 
require special project-specific settings that must be in settings.xml, we put 
settings.xml in the top-level of the project source tree and check it in...

For publishing projects to our binary repo for consumption by other groups, we 
simply use the flatten-maven-plugin to strip out the repo (and other 
build-related stuff) from the published POM.


-Original Message-
From: KARR, DAVID [mailto:dk0...@att.com] 
Sent: Monday, October 17, 2016 3:03 PM
To: users@maven.apache.org
Subject: Comparing specifying repositories in pom vs. settings.xml?

One thing I run into when jumping between different projects is different 
expectations for what maven repos I need to be using.  In the past, I had to 
have multiple copies of "~/.m2/settings.xml" lying around, and I would hack the 
specified repos when I needed to.

Recently, I saw a situation where the required repositories were simply defined 
in the top-level pom for the project.  If this is done consistently, there's no 
longer any need to hack the settings.xml file.

I seem to remember seeing some advice that specifying repositories in the POM 
is a bad practice.  If I'm remembering this correctly, this seems odd.  Forcing 
the correct repos to be defined in the settings.xml works against "repeatable 
builds".

What is the recommended advice here?

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


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

RE: Jenkins and Maven

[Robert Patrick]

To make concurrent Jenkins builds work, simply enable the "Use private Maven 
repository" option in the Jenkins Maven build jobs and select the appropriate 
"Strategy" (e.g., "Local to the workspace" or "Local to the executor").  This 
works fine for us...


-Original Message-
From: Nigel Magnay [mailto:nigel.mag...@gmail.com] 
Sent: Thursday, October 13, 2016 10:54 AM
To: Maven Users List
Subject: Re: Jenkins and Maven

You install
https://github.com/takari/takari-local-repository

Or fix the bug from, like, 2007 ?
https://issues.apache.org/jira/browse/MNG-2802

On Thu, Oct 13, 2016 at 4:41 PM, Benson Margulies 
wrote:

> So, here's a specific puzzle. I want to enable multiple branches in 
> the Jenkins job and concurrent builds. How do I avoid two jobs trying 
> to write the same local repo at the same time?
>
> -
> 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: Jenkins and Maven

[Robert Patrick]

I wasn't attacking your opinion or your credentials.  The lack of detailed 
justification for statements simply made me question how applicable they were 
to me (and others).  As such, I wanted to provide another point of view.  

Granted, the Maven jobs hide a lot of what they are doing so if your project 
does things that break the assumptions made by these jobs, then debugging it is 
probably challenging.  In my projects, I try to follow the KISS principle in 
designing and implementing my builds.  I have yet to meet a project where the 
Maven job did not work for me unless I ran into a Maven bug/limitation (like 
MNG-5889).


-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Thursday, October 13, 2016 9:39 AM
To: Maven Users List
Subject: Re: Jenkins and Maven

When they work, they work... when they don't work they blow up in your face... 
and they break how maven is supposed to work... so anyone that actually has a 
good understanding of Maven will be surprised by the evil things the evil one 
does...

Having been a Jenkins committer since 2006, and given that my day job is 
actually developing Jenkins... feel free to take my opinions however you see fit

On 13 October 2016 at 15:24, Robert Patrick 
wrote:

> Well...  Some of us, my team included, are using the Maven jobs in 
> Jenkins and they generally works fine for our projects (and is much 
> simpler to configure).  Be warned that Maven 3.3 support is still 
> busted for projects that use .mvn/maven.config waiting on 
> https://issues.apache.org/
> jira/browse/MNG-5889 to be merged...
>
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Thursday, October 13, 2016 9:16 AM
> To: Maven Users List
> Subject: Re: Jenkins and Maven
>
> https://javaadventure.blogspot.ie/2013/11/jenkins-
> maven-job-type-considered-evil.html
> is the message from your friendly neighbourhood Apache Maven PMC 
> member and Jenkins committer!
>
> Two options:
> 1. (oldschool) Freestyle Job with a Maven build step 2. (coolkids) 
> Multibranch Pipeline Job with a Jenkinsfile in the repository... At 
> present the Jenkinsfile will have to invoke Maven via a shell/batch 
> step... which gets a tad ugly
>
> node() {
>   withMaven(...) {
>   if (isUnix()) {
> sh 'mvn clean verify'
>   } else {
> bat 'mvn clean verify'
>   }
>   junit '**/target/surefire-reports/*.xml, **/target/failsafe-reports/*.
> xml'
>   // plus whatever else you are having yourself
>   }
> }
>
> There is a dedicated `mvn` step in the works... not here yet... and 
> there is a newer better syntax for Jenkinsfile in progress:
> https://github.com/jenkinsci/pipeline-model-definition-plugin
>
> So hopefully, you'll soon be able to do
>
> pipeline {
>   agent label:'linux'
>   stages {
> stage('Build') {
>   // the syntax to specify the Maven tool version is still in progress
>   steps {
> mvn 'clean verify'
> // remains to be seen if the `mvn` step will auto-junit
>   }
> }
>   }
>   notifications {
> always {
>   mail ...
> }
>   }
> }
>
> On 13 October 2016 at 14:59, Benson Margulies 
> wrote:
>
> > We've about had it with bamboo, and are dusting off our old Jenkins 
> > instance.
> >
> > I recall some messages here about things _not_ to do with Jenkins 
> > and Maven. Do we avoid the 'maven build type' altogether and just 
> > run Maven from the shell, or is my memory faulty? Anything else.
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

RE: Jenkins and Maven

[Robert Patrick]

Well...  Some of us, my team included, are using the Maven jobs in Jenkins and 
they generally works fine for our projects (and is much simpler to configure).  
Be warned that Maven 3.3 support is still busted for projects that use 
.mvn/maven.config waiting on https://issues.apache.org/jira/browse/MNG-5889 to 
be merged...


-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Thursday, October 13, 2016 9:16 AM
To: Maven Users List
Subject: Re: Jenkins and Maven

https://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html
is the message from your friendly neighbourhood Apache Maven PMC member and 
Jenkins committer!

Two options:
1. (oldschool) Freestyle Job with a Maven build step 2. (coolkids) Multibranch 
Pipeline Job with a Jenkinsfile in the repository... At present the Jenkinsfile 
will have to invoke Maven via a shell/batch step... which gets a tad ugly

node() {
  withMaven(...) {
  if (isUnix()) {
sh 'mvn clean verify'
  } else {
bat 'mvn clean verify'
  }
  junit '**/target/surefire-reports/*.xml, **/target/failsafe-reports/*.xml'
  // plus whatever else you are having yourself
  }
}

There is a dedicated `mvn` step in the works... not here yet... and there is a 
newer better syntax for Jenkinsfile in progress:
https://github.com/jenkinsci/pipeline-model-definition-plugin

So hopefully, you'll soon be able to do

pipeline {
  agent label:'linux'
  stages {
stage('Build') {
  // the syntax to specify the Maven tool version is still in progress
  steps {
mvn 'clean verify'
// remains to be seen if the `mvn` step will auto-junit
  }
}
  }
  notifications {
always {
  mail ...
}
  }
}

On 13 October 2016 at 14:59, Benson Margulies  wrote:

> We've about had it with bamboo, and are dusting off our old Jenkins 
> instance.
>
> I recall some messages here about things _not_ to do with Jenkins and 
> Maven. Do we avoid the 'maven build type' altogether and just run 
> Maven from the shell, or is my memory faulty? Anything else.
>
> -
> 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: Aw: Re: Re: [Regression] Declared properties could not be modified anymore within a plugin

[Robert Patrick]

I can confirm that it is not possible to override a project property in a 
plugin with Maven 3.3.9.  I am not sure what the expected behavior is but 
trying to override a pre-initialized value (from command-line -Ds, 
.mvn/maven.config, or the POM) from a plugin has no effect...


-Original Message-
From: M. Richey [mailto:mric...@gmx.de] 
Sent: Monday, October 10, 2016 4:16 AM
To: users@maven.apache.org
Cc: Maven Users List
Subject: Aw: Re: Re: [Regression] Declared properties could not be modified 
anymore within a plugin

Thanks Benson, but it does not work for me.

During the execution it says:

[main] [DEBUG] define property osgi-version = "1.0.0.v20161010082844"

But in the MANIFEST.MF it says:

Manifest-Version: 1.0
Built-By: maik
demo: bad
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_66

So, as I said before, during the execution the property gets set and the 
pre-initialized value is used afterwards.

Best regards,

Maik


> Gesendet: Samstag, 08. Oktober 2016 um 16:45 Uhr
> Von: "Benson Margulies" 
> An: "Maven Users List" 
> Betreff: Re: Re: [Regression] Declared properties could not be 
> modified anymore within a plugin
>
> https://github.com/benson-basis/prop-override-example
> 
> Seems to be a demo that
> 
> https://github.com/basis-technology-corp/basis-build-helper-maven-plug
> in
> 
> overrides properties.
> 
> Using:
> 
> private void defineProperty(String name, String value) {
> if (getLog().isDebugEnabled()) {
>   getLog().debug("define property " + name + " = \"" + value + "\"");
> }
> project.getProperties().put(name, value); }
> 
> 
> On Tue, Oct 4, 2016 at 4:03 PM, Benson Margulies  
> wrote:
> > On Tue, Oct 4, 2016 at 5:35 AM, M. Richey  wrote:
> >> Thanks Benson to point that out, it's a good example.
> >>
> >> We have several use cases where we modify properties with our plugins. We 
> >> have a large variety of our software which to build for up to three 
> >> brands. For which brand a specific software is to build is defined outside 
> >> the poms and provided by our plugin. As we all know you can't loop inside 
> >> the poms. So we execute a plugin once for each brand to find out if this 
> >> variant should be build for the brand specified. Therefore we defined a 
> >> property in the pom.xml, pre-initialized with a default value, and if the 
> >> software should be build for one brand, the brand is appended to the list, 
> >> i.e. the value of the property, during the execution of our plugin. So the 
> >> value of the property may be something like "default,brand1,brand3" after 
> >> the executions of the plugin.
> >>
> >> So for us it is a blocker at the moment that one can't modify properties 
> >> during the execution of a plugin anymore.
> >>
> >> Benson, you said you have some of these working with 3.3.9. Can you give 
> >> an example of a plugin where this is working? I would like to see how they 
> >> are doing it in their code.
> >
> > I'd better do a test to ensure that they are working as well as I 
> > think they are and then get back to you.
> >>
> >> Kind regards,
> >>
> >> Maik
> >>
> >>
> >>
> >>> Gesendet: Sonntag, 02. Oktober 2016 um 22:04 Uhr
> >>> Von: "Benson Margulies" 
> >>> An: "Maven Users List" , i...@soebes.de
> >>> Betreff: Re: [Regression] Declared properties could not be 
> >>> modified anymore within a plugin
> >>>
> >>> On Fri, Sep 30, 2016 at 1:50 PM, Karl Heinz Marbaise  
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > On 30/09/16 15:20, mric...@gmx.de wrote:
> >>> >>
> >>> >> Hi all,
> >>> >>
> >>> >> we discovered a problem with properties defined in a pom.xml.
> >>> >>
> >>> >> Properties could be defined in a pom.xml like:
> >>> >>
> >>> >> 
> >>> >> default
> >>> >> 
> >>> >>
> >>> >> In a maven plugin we fetch all the properties by calling:
> >>> >>
> >>> >> Properties projectProps = project.getProperties();
> >>> >>
> >>> >> Running all this with maven 2 we were able to modify the value of 
> >>> >> "myProp"
> >>> >> within the plugin by:
> >>> >>
> >>> >> projectProps.put("myProp", "newValue");
> >>> >>
> >>> >> So after the execution of the plugin, the property  has 
> >>> >> the value "newValue".
> >>> >>
> >>> >> Running all this with maven 3 that does not work anymore.
> >>> >
> >>> >
> >>> >
> >>> > First I would say this is by design wrong, cause if you define a 
> >>> > property in the pom file I would like to be sure that it will be 
> >>> > kept the value I have given and if a plugin (which could it be) 
> >>> > will change that I will be really astonished.
> >>> >
> >>> >
> >>> > Apart from that my question: Why do you need to change existing 
> >>> > properties and why not changing the in the pom which is more 
> >>> > clearer than mysteriously chaning a property by a plugin?...
> >>> >
> >>> > Can you give more details about your use case ? Best would be 
> >>> > having a real workign example and what kind of problems you are 
> >>> > trying to solve with this approach?
> >>> >
> >>> >
> >>> > Kind reg

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

That one is even worse, pom parsing fails...

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for myproject:util:jar must not 
contain any of these characters \/:"<>|?* but found * @ 
myproject:zip-installer:[unknown-version], C:\myproject\zipinsall\pom.xml, line 
196, column 22



-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 5:17 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/23/16 um 23:38 schrieb Robert Patrick:
> This is nice, but it doesn’t work in Maven 3.3.9...
> 
> [ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
> Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
> project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies 
> version ordering: [0.8.min,0.8.max) for project 
> myproject:zip-installer:pom:0.9-SNAPSHOT at 
> C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]

I have no test project at hand. Did you try "[0.8.*]" as well?

Regards,
-- 
Christian


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


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

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

This is nice, but it doesn’t work in Maven 3.3.9...

[ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version 
ordering: [0.8.min,0.8.max) for project 
myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml 
-> [Help 1]

--
Robert Patrick 
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/


-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?  
> According to 
> https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/m
> aven/artifact/versioning/ComparableVersion.html, the range 
> [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0 
> prerelease versions but not the 2.0 GA release so there is no reason 
> you need [1.0,2.0) to do the exact same thing... :-)
> 

I haven't tested this but I think what is written here also applies to Maven. 
You would need to test that yourself.

<http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges>

Regards,
--
Christian


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


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

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

There is already a syntax to give you pre-release versions, right?  According 
to 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html,
 the range [1.0,2.0-SNAPSHOT] will give you the newest release including all 
2.0 prerelease versions but not the 2.0 GA release so there is no reason you 
need [1.0,2.0) to do the exact same thing... :-)

Mark D's workaround is a pragmatic approach.

As for why I don’t get involved, I tend to be selective about where I spend my 
time and since we eliminated the use of version ranges in our projects for 
multiple reasons, addressing this issue doesn't really meet my bar for 
investing my time to contribute.  I do contribute periodically, still waiting 
on my latest bug fix to be integrated 
(https://issues.apache.org/jira/browse/MNG-5889)... 

Cheers,
Robert

-Original Message-
From: Curtis Rueden [mailto:ctrue...@wisc.edu] 
Sent: Friday, September 23, 2016 3:45 PM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range

Hi Robert,

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

Personally, I want prerelease versions included.

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

> There should be a simple way to achieve this

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

Regards,
Curtis


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


On Fri, Sep 23, 2016 at 3:41 PM, Robert Patrick 
wrote:

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

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

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

Well...like I said, I understand the relationship but clearly, most people that 
use version ranges that use a non-inclusive top-end specification do not want 
prerelease versions included.  I have yet to hear you or anyone else give me a 
use case where you want this.

The fact that I have to fight Maven to achieve this is a pain--and I have been 
using Maven for many years now.  There should be a simple way to achieve this 
that does not require me to do something like this:

[1.0,1.999)


-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Friday, September 23, 2016 3:30 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range

Hi,

On 23/09/16 18:38, Robert Patrick wrote:
>
> What I am questioning is the "engineer's approach" to version range 
> resolution without
 > a valid use case for why Maven should consider  > pre-released versions as 
 > within the "not including 2.0" version  > range semantics.

The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final 
release (2.0) so must be defined as before...

Kind regards
Karl Heinz Marbaise



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


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

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

So then the right range to keep all 2.0 pre-release artifacts out of the build 
is [1.0,2.0-a)?



-Original Message-
From: Guillaume Boué [mailto:gb...@apache.org] 
Sent: Friday, September 23, 2016 12:12 PM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is documented 
in ComparableVersion: 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.

Guillaume

Le 23/09/2016 à 18:49, Robert Patrick a écrit :
> I was not suggesting that it could be changed...only that it doesn't make 
> sense (except from a pure mathematical point of view).
>
> Given this "engineer's approach" to version range resolution, it seems like a 
> better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this 
> eliminates 2.0-SNAPSHOT versions.  However, what I have not verified is what 
> happens when you have other pre-release versions (e.g., 2.0-alpha-1).  Is 
> 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release 
> versions like alpha, beta, etc?
>
>
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com]
> Sent: Friday, September 23, 2016 11:47 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Fair enough. From the purely engineering/mathematical point of view it might 
> not make sense. But I dont see a way to get that changed with breaking a TON 
> of other stuff. And I am not even sure if it would be more intuitive instead 
> of just being different.
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
>
>> No, you are making an invalid assumption about what I understand!  I 
>> completely understand the relationship of SNAPSHOTs and other 
>> pre-release artifacts and released versions.
>>
>> What I am questioning is the "engineer's approach" to version range 
>> resolution without a valid use case for why Maven should consider 
>> pre-released versions as within the "not including 2.0" version range 
>> semantics.
>>
>>
>> -Original Message-
>> From: Manfred Moser [mailto:manf...@simpligility.com]
>> Sent: Friday, September 23, 2016 11:32 AM
>> To: users@maven.apache.org
>> Subject: Re: [EXTERNAL] Re: help with version range
>>
>> What you are misunderstanding is how snapshots are meant to be used.
>> 2.0-SNAPSHOT means that it is a development version working towards 
>> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>>
>> If you mislike this you can change how you work with your own 
>> projects at least. .. you can just call your snapshot version 
>> 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 
>> ..
>>
>> Manfred
>>
>> Robert Patrick wrote on 2016-09-23 08:56:
>>
>>> This does seem non-intuitive.If I say that I want versions  between 1.0
>>> and
>>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>>> would I ever want this to resolve to 2.0-SNAPSHOT or any other 
>>> pre-release 2.0 artifact?
>>> Personally, I cannot think of a single one.
>>>
>>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>>> nothing related to 2.0...
>>>
>>> -Original Message-
>>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>>> Sent: Friday, September 23, 2016 10:11 AM
>>> To: Maven Users List
>>> Subject: RE: [EXTERNAL] Re: help with version range
>>>
>>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>>> something, so I can at least move forward with that.
>>>
>>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>>> release version why would I want the pre-release versions?
>>>
>>> -Original Message-
>>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>>> Behalf Of Curtis Rueden
>>> Sent: Friday, September 23, 2016 9:01 AM
>>> To: Maven Users List
>>> Subject: [EXTERNAL] Re: help with version range
>>>
>>> Hi Justin,
>>>
>>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would 
>>> match the versions you want in practice.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>>>
&

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

I was not suggesting that it could be changed...only that it doesn't make sense 
(except from a pure mathematical point of view).

Given this "engineer's approach" to version range resolution, it seems like a 
better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this 
eliminates 2.0-SNAPSHOT versions.  However, what I have not verified is what 
happens when you have other pre-release versions (e.g., 2.0-alpha-1).  Is 
2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release versions 
like alpha, beta, etc?


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com] 
Sent: Friday, September 23, 2016 11:47 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:

> No, you are making an invalid assumption about what I understand!  I 
> completely understand the relationship of SNAPSHOTs and other 
> pre-release artifacts and released versions.
> 
> What I am questioning is the "engineer's approach" to version range 
> resolution without a valid use case for why Maven should consider 
> pre-released versions as within the "not including 2.0" version range 
> semantics.
> 
> 
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com]
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards 
> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> 
> If you mislike this you can change how you work with your own projects 
> at least. .. you can just call your snapshot version 1.99-SNAPSHOT or 
> whatever while developing and at releas time switch to 2.0 ..
> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 08:56:
> 
>> This does seem non-intuitive.If I say that I want versions  between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other 
>> pre-release 2.0 artifact?
>> Personally, I cannot think of a single one.
>> 
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>> nothing related to 2.0...
>> 
>> -Original Message-
>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>> 
>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>> something, so I can at least move forward with that.
>> 
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>> release version why would I want the pre-release versions?
>> 
>> -Original Message-
>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>> 
>> Hi Justin,
>> 
>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>> 
>>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and 
>>> it had been going well. However I wanted to start working on 1.2.0 
>>> of the parent, so I published a 1.2.0-alpha-1 version. And all the 
>>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this 
>>> is in keeping with the implementation that x.y.z-(alpha|beta|…) 
>>> precedes x.y.z, but it is unintuitive to me. First in that I’ve 
>>> stated I don’t want 1.2.0, and second that once I do release 1.2.0 
>>> the projects which were receiving the alpha builds will not get 
>>> 1.2.0. I tried with both
>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorge...@lgc.com* 
>>>
>>> Fo

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

No, you are making an invalid assumption about what I understand!  I completely 
understand the relationship of SNAPSHOTs and other pre-release artifacts and 
released versions.  

What I am questioning is the "engineer's approach" to version range resolution 
without a valid use case for why Maven should consider pre-released versions as 
within the "not including 2.0" version range semantics.


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com] 
Sent: Friday, September 23, 2016 11:32 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

What you are misunderstanding is how snapshots are meant to be used. 
2.0-SNAPSHOT means that it is a development version working towards the release 
of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects at 
least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever 
while developing and at releas time switch to 2.0 .. 

Manfred

Robert Patrick wrote on 2016-09-23 08:56:

> This does seem non-intuitive.If I say that I want versions  between 1.0 
> and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 
> 2.0 artifact?
> Personally, I cannot think of a single one.
> 
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
> nothing related to 2.0...
> 
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
> 
> Yeah, I was hoping there was something more elegant like 1.1+ or 
> something, so I can at least move forward with that.
> 
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
> has excluded 1.2.0 from their range? If I explicitly don't want the 
> release version why would I want the pre-release versions?
> 
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
> Behalf Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
> 
> Hi Justin,
> 
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
> the versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> 
>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and 
>> it had been going well. However I wanted to start working on 1.2.0 of 
>> the parent, so I published a 1.2.0-alpha-1 version. And all the 
>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this 
>> is in keeping with the implementation that x.y.z-(alpha|beta|…) 
>> precedes x.y.z, but it is unintuitive to me. First in that I’ve 
>> stated I don’t want 1.2.0, and second that once I do release 1.2.0 
>> the projects which were receiving the alpha builds will not get 
>> 1.2.0. I tried with both
>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorge...@lgc.com* 
>>
>> Follow Halliburton: *LinkedIn*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>> s 
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> e 
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
>> & 
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
>> V 
>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>> | *Facebook*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o 
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r 
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Psk
>> v 
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uy
>> u 
>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-w
>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>> | *Twitter*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o 
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r 
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtE
>> U 
>> DK7wuWU-tIg6oKuGYBRbr

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

This does seem non-intuitive.If I say that I want versions  between 1.0 and 
up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever 
want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact?  
Personally, I cannot think of a single one.

Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing 
related to 2.0...

-Original Message-
From: Justin Georgeson [mailto:jgeorge...@lgc.com] 
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

Yeah, I was hoping there was something more elegant like 1.1+ or something, so 
I can at least move forward with that.

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

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of 
Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

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

Regards,
Curtis

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

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it 
> had been going well. However I wanted to start working on 1.2.0 of the 
> parent, so I published a 1.2.0-alpha-1 version. And all the projects 
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in 
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes 
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t 
> want 1.2.0, and second that once I do release 1.2.0 the projects which 
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
>  t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
>  st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
>  st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
>  t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
>  t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
>  utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> --
> This e-mail, including any attached files, may contain confidential 
> and privileged information for the sole use of the intended recipient.
> Any review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive 
> information for the intended recipient), please contact the sender by 
> reply e-mail and delete all copies of this message.
>

--

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

[Robert Patrick]

This should be treated as a bug.  Many builds, including ours, relies on being 
able to override properties defined in the parent hierarchy in a module POM.  
This change you are describing would break a lot of builds...

> On Aug 12, 2016, at 8:41 AM, Samuel Langlois  
> wrote:
> 
> 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...
> 
> We have a submodule where the "parent" pom contains a dependency with
> scope=import, but with the version set using a property:
>   
>  
> 
>org.alfresco
>alfresco-platform-distribution
>${alfresco.version}
>pom
>import
> 
> 
> In the submodule itself, we override this version to be a more recent one:
>   
>  5.1.e
>   
> 
> In Maven 3.3 and before, the override is working, and we inherit version
> 5.1.e of the dependencies.
> In maven 3.4, it doesn't any more, so we get older versions of the
> dependencies.
> 
> It works fine if I move the property override to the parent pom, i.e. the
> one where the import dependency is defined.
> I've just retested using the latest 3.4.0-SNAPSHOT from 2016-08-06
> 
> Thanks for your insight
> --
> Samuel
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877660.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Cobertura Maven Plugin works locally, but not in Jenkins

[John Patrick]

I've had similar, where versions between locally and jenkins where
different. Question to ask yourself to see if you have checked;
) maven version used locally vs jenkins
) java version used locally vs jenkins
) operating system? same? both 32bit or 64bit?
) does your jenkins project have a private repo?
) do you define all plugins used within your pom?

I've had issues so now I always define all plugins used in the pom, I also
use the prerequisites to define maven version, plus the following
properties, maven.compiler.source, maven.compiler.target,
project.build.sourceEncoding, project.build.outputEncoding,
project.reporting.outputEncoding.

If your able to log into the jenkins box, if you manually execute the same
command as you do locally does it work?

Try deleting the jenkins repo.

After several issues, I always setup each jenkins project to use a separate
maven repo i.e. per workspace. Always define exact plugin version to use,
checking with versions:display-plugin-updates to make sure non are being
pulled in from the super pom. I've not had anymore issues, but saying that
I don't know if things have got better or not.

John


On 12 July 2016 at 15:48, Hohl, Gerrit  wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service the
> Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't see
> an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION: BUILD FAILURE
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Total time: 35.284s
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Finished at: Tue Jul 12 15:43:15 CEST 2016
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Final Memory: 24M/174M
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> sessionEnded
>
> INFORMATION:
> --

Re: Is there any way to have archetype:generate fill in "boilerplate" fields?

[John Patrick]

What about creating a company/personal pom, publish that to your local repo
or company repo, then simply have that as the parent of all the projects
you work on. You can version it and update it as things develop.

It's what I do, if you have a standard setup you can even use parameters
for scm urls i.e. HOST/${project.groupdId}-${project.artifactId}.

John


On 5 July 2016 at 19:30, Mark H. Wood  wrote:

> It's a small thing, but it would be handy if I could stash some
> settings somewhere that would cause the archetype generator to fill in
> my  and  and the like.
>
> --
> 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
>