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
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
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
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
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
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/
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
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
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
.
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):
>
> &g
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;
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
>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.
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
.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
> &
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
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
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
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
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
gt; 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 i
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
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
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
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
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
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
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
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?
hing 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 mo
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;
$
>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
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
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
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
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
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 w
oo 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,
&
m.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
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
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
>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
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,
>
>
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
y 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
On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick <robert.patr...@oracle.com>
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 repositori
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
Change your pom to something like this;
Hi5S
Hi5S
0.0.1-SNAPSHOT
war
UTF-8
1.8
1.8
org.apache.maven.plugins
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
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
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
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
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,
[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
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
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
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 <mgai...@hotmail.com> wrote:
>
>
>
>
> ___
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:
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 <nhoj.patr...@gmail.com>
>> wrote:
>>
>>&g
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
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.
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
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
..@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 i
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
Patrick <robert.patr...@oracle.com>
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 an
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
e 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 <robert.patr...@oracle.com>
wrote:
> I also built a little sample project where I simulated a generated
> class using the
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
er 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 Pat
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
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"
[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.
Unfortunat
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
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
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:
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 <robert.patr...@oracle.com>
wrote:
&g
]
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" <robert.patr...@oracle.com> wrote:
> I am using the
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 <robert.patr...@oracle.com> a écrit :
> Periodically, I update the versions of the Maven plugi
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 <robert.patr...@oracle.com> wrote:
> Periodically, I update the
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
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
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?
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
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
opinions however you see fit
On 13 October 2016 at 15:24, Robert Patrick <robert.patr...@oracle.com>
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
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
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
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 Rob
: [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 <robert.patr...@oracle.com>
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872
Frisco, TX 7
016 at 3:41 PM, Robert Patrick <robert.patr...@oracle.com>
wrote:
> Well...like I said, I understand the relationship but clearly, most
> people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included. I have yet to
> he
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"
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 :
>
h 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 SNA
th 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
>
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,
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
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
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
1 - 100 of 382 matches
Mail list logo