Re: Resource plugin - LifecycleExecutionException - Input length = 1

[Mark Prins]

Op wo 12 aug. 2020 om 21:47 schreef Tobias :

>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.2.0:testResources
> (default-testResources) on project XXX: Input length = 1
>
> See [2] below for a more detailed stack trace.
>
> Do you know what goes wrong and how this can be fixed?
>
>
I ran into this as well, after updating the list of "
nonFilteredFileExtensions" this seems to be fixed, see eg.
https://github.com/B3Partners/brmo/pull/901/files

run "mvn -X process-test-resources" to get the list of filtered files


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

mismatch between maven-release-plugin site and available artifacts

[Mark Prins]

There is a mismatch between the published site and the available artifact.

https://maven.apache.org/maven-release/maven-release-plugin/index.html 
lists 3.0.0-M2 published 2020-04-07 as the current release, but it 
cannot be downloaded from eg. 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-plugin/


can anyone resolve this?

TIA, Mark

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

Re: Best Practice for distributing test utilities?

[Mark Prins]

refactor foo to a multimodule one with the test utilities as an artifact 
and one with the code + tests for original foo, you can then depend on 
the test module with scope test in the main module and keep everything 
in source repo making it easy to stay in sync


On 12-03-2020 14:55, Andreas Sewe wrote:

Hi,

I am struggling to figure out what the Maven Way is for distributing
test utils.

Say I have a project "foo" along with some unit tests for it. Moreover,
I have some utilities that help in testing "foo" (e.g., test data
builders or test fixtures). These utilities are used by the unit tests
for "foo", but may also be useful to projects depending on "foo" (e.g.,
a FooTestDataBuilder that produces Foo instances could also be used in
the tests of a dependent project "bar").

The question is where to place these test utilities and how to depend on
them.

1. I could follow the "guide to using attached tests" [1], place the
test utilizes in foo/src/test/java, and attach the test-jar to "foo".
Then, a dependent project "bar" could depend on the test-jar in its test
scope. Alas, as the test scope is not transitive, I would need to
declare all test-dependencies of "foo" again in "bar", even though I may
not even use them directly (e.g., if the FooTestDataBuilder uses them
only internally).

2. I could split "foo" into three projects: "foo", "foo-test-utils", and
"foo-tests", with the latter depending on both "foo-test-utils" and
"foo-tests". A project "bar" would then simply depend on "foo" in
compile scope and "foo-test-utils" in test scope. This would make all
dependencies explicit, but would result in some oddities, e.g.,
foo-tests/src/main/java being empty, as all tests need to be placed in
tests/src/test/java to be picked up by Surefire.

3. I could split "foo" into just two projects, "foo" and "foo-testing".
foo-testing/src/main/java would the contain the test utilities for
"foo", whereas foo-testing/src/test/java would contain the actual tests.
This is again somewhat odd, as the tests in foo-testing/src/test/java
are not testing "foo-testing" but "foo".

4. Option 4 is the most natural way, but unfortunately it doesn't work,
because it introduces a cyclic dependency: Have "foo" and
"foo-test-utils" and let the tests of "foo" depend on "foo-test-utils".

Am I missing something? In particular, why is [1] apparently the
recommended approach, even though it requires you to duplicate
dependency information?

Any suggestions are greatly appreciated.

Best wishes,

Andreas

[1] 




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

Re: Configure default execution phase

[Mark Prins]

You should be able to change the default execution phase of a plugin (as 
well as bind a goal to any other phase) by configuring explicit 
executions bound to a phase


see: https://maven.apache.org/guides/mini/guide-default-execution-ids.html

You would need to use an id of "default-update" to override the update goal.

-M


On 22-12-19 18:04, Stanimir Stamenkov wrote:

I'm having a POM like:

     
     
     
     
     org.liquibase
     liquibase-maven-plugin
     3.8.3
     
     ...
     
     
     
     
     

I don't want the plugin executed as part of the build but I want to be 
able to execute its goals [1] explicitly.  The goals get executed 
directly (no build phases get triggered), f.e.:


     mvn liquibase:update

but then it usually (while not necessarily, depending on project 
configuration) require "process-resources" to be completed, so I have to:


     mvn process-resources liquibase:update

Is it possible to trigger "process-resources" automatically via plugin 
configuration in POM (a`la Gradle's dependsOn [2]), or this is just 
hard-coded in the plugin itself?


[1] https://www.liquibase.org/documentation/maven/index.html
[2] https://docs.gradle.org/current/userguide/more_about_tasks.html




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

Re: is there a maven plugin to identify ancient pom dependencies

[Mark Prins]

On 21-12-19 21:02, Maarten Mulders wrote:
Maybe this can help you: 
https://github.com/portofrotterdam/versiondebt-plugin
As far as I can see, it doesn't allow you to configure "what is old". It 
does tell you how old dependencies are.


not really; it seems that it uses the "last modified" from a 
URLConnection to the artifact in a repository, so unlikely to provide a 
date related to the time of release. it will be unreliable in any 
situation that a maven proxy is used.


see:
https://github.com/portofrotterdam/versiondebt-plugin/blob/e500e2d2a1fce4eb350633c7515b04107dae42d6/versiondebt-maven-plugin/src/main/java/com/portofrotterdam/versiondebt/VersiondebtMojo.java#L218-L229


Important disclaimer at the end of the page: it isn't maintained on a 
regular basis.


Cheers,

Maarten

On December 21, 2019 at 18:50, Enrico Olivelli wrote:


Something like this:
https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html 



Hope that helps
Enrico

Il sab 21 dic 2019, 18:31 mark  ha scritto:

On 2019-12-20 13:39, Marlow, Andrew wrote:
Hello everyone,

I am using the owasp maven dependency plugin to tell me when I am
using components that have CVEs. That's great. I was wondering if
there was something similar that would tell me when I am using very
old components (where the judgement about what is old is configurable,
e.g number of years, months etc).

never seen one, it would be hard without querying the source repository
for the release tag/branch for the moment the release was cut (which is
problematic in case a minimal release pom is in use. The current pom
does not have this/a timestamp for this and you cannot use the file date.

I guess you could look at the date of the (class) files inside the
artifact (jar) to determine build/release date, not sure how that would
work out with shaded dependencies or provided manifest files

-M

*Andrew Marlow*

Software Engineer Specialist, Apex

38^th Floor, 25 Canada Square,

Canary Wharf, London E14 5LQ

*T*:  020-8081-2367 / 07966-451-521
*E*: andrew.mar...@fisglobal.com 

*FIS | Advancing the way the world pays, banks and invests(tm) *

cid:image004.png@01D542DF.1DA72090
cid:image005.png@01D542DF.1DA72090
cid:image008.png@01D542DF.1DA72090


The information contained in this message is proprietary and/or
confidential jadajadajada...


-
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 Release Plugin Message Format

[Mark Prins]

don' t recall any commits like that, generally I see that the last commit
in a tag is "[maven-release-plugin] prepare release

..."
and in my master branch I see "[maven-release-plugin] prepare release
..."
and then "[maven-release-plugin] prepare for next development iteration

"

looking at
https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
there
seems to be no option to do what you want.
-M

Op do 31 okt. 2019 om 09:12 schreef Scott Rossillo :

> We're using the maven-release-plugin and all our tags end up looking like:
>
> vX.Y.Z copy for tag vX.Y.Z
>
> With git "copy for tag" is pretty nonsensical. Preferably, the message
> would be "Release X.Y.Z". I looked at the source code and see the actual
> tagging is delegated to another package, org.apache.maven.shared.release.
>
> Anyway, is there a way to override the commit message and if not, which
> component should a ticket be file or suggested change be recommended to?
>
> Best,
>
> Scott
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: Not a chance to show conflicts in dependency tree?

[Mark Prins]

On 11-09-18 10:56, Nicolas Peifer wrote:

Hi,

I'm trying to show dependency conflicts using "mvn dependency:tree 
-Dverbose -Dincludes=commons-collections" as described in the 
documentation[1]. Unfortunately, this gives the following error:


"Verbose not supported since maven-dependency-plugin 3.0"

I tested it with Maven 3.3.9 and 3.5.4. Does anyone know a solution 
(apart from downgrading the plugin)?


verbose probably needs a value, also see the note: 
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose


Using a different or specific version is as easy as specifying that (eg. 
2.10):

"mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree"

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

Re: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter ->

[Mark Prins]

On 30-06-18 16:39, Karen Goh wrote:

Hi expert,

I used maven build and run goal : deploy to see how my spring framework project 
run but I got the above error.


There is this stackoverflow person which has similar problem as mine:

https://stackoverflow.com/questions/27153024/repository-element-was-not-specified-in-the-pom-inside-distributionmanagement-el/39439911


So, I read up the below:
https://maven.apache.org/pom.html#Distribution_Management

My question is since I am doing this on a stand alone basis and do not need to 
share the POM denpendencies, how do I get rid of this message?

you seem confused as to what "mvn deploy" actually does, it places an 
artifact in a repository, see: 
https://maven.apache.org/plugins/maven-deploy-plugin/

if that is not what you want then using mvn install should suffice.


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

Re: site with file copy

[Mark Prins]

On 03-05-18 08:03, Philipp Kraus wrote:

Hello,

I’m using „mvn site“ command to build for my project the project website as 
HTML code,
During the site goal is running I need to copy some files into the target/site 
directory, how can I do this?
I need to copy some single files to the output director, but only on the site 
goal.


You could use the anrun plugin during the (pre-)site phase or stick the 
files into src/site/resources/ (with optional directories) so the site 
plugin picks them up.


-Mark

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

Re: How to hide internal build details from deployed pom.xml ?

[Mark Prins]

You can deploy artifacts using a custom, cleaned up pom that doesn't have a
build section

-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: maven-war-plugin addClasspath useless, because it cannot add absolute paths

[Mark Prins]

2018-01-25 11:43 GMT+01:00 Basin Ilya :

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

this really depends on the classloader of the container running the war and
the way it is configured.


> But can maven add paths that are absolute or relative? I tried this:
>
>
>nah
>nah
>1.0.0
>system
>/C:/1/ccc.jar
>true
>
>
>
>

Optional dependencies are not required at runtime and should not be
expected to be part of the war


> ...
> 
> org.apache.maven.plugins
> maven-war-plugin
> 
>   
> 
>   true
> 
>   
>
> The Class-Path was indeed added to MANIFEST.MF, but not the "ccc.jar".
>

makes sense to me.


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

On 21-01-18 08:21, Debraj Manna wrote:

Mark

One more query if some other dependency (let's say elasticsearch for
example) leaks its usage of guava then it may happen I end up again with
two incompatible versions of guava. What is the recommended way of handling
this?


You would need to find and settle on a guava version that is compatible 
between all the versions or get the other projects to release updated 
versions or make a version by yourself (of hbase or elasticsearch or...) 
that is compatible


-M


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

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

That's the idea, you cannot otherwise control which classes or which
version of guava are loaded by the classloader at runtime.

Op 20 jan. 2018 14:55 schreef "Debraj Manna" :

Ok. But then I think I have to change the import of guava in all the places
in my code?

On Sat, Jan 20, 2018 at 1:44 PM, Mark Prins  wrote:

> You could try shading the new guava to a different package and use that in
> your code.
> E.g. jena-shaded-guava does that
>
> Op 20 jan. 2018 09:02 schreef "Debraj Manna" :
>
> > Mark
> >
> > hbase and hadoop is using the old guava. Is there a way I can use the
> > latest guava in my code and let hadoop and hbase use the old guava.
> >
> > On 20-Jan-2018 1:19 PM, "Mark Prins"  wrote:
> >
> > > It seems that the guava versions are not API compatible, so shading is
> > > unlikely to help. You will need to downgrade to a compatible version
of
> > > guava or get the other projects to upgrade.
> > > -M
> > >
> > > Op 20 jan. 2018 07:51 schreef "Debraj Manna"  >:
> > >
> > > I have posted more details in stackoverflow
> > > <https://stackoverflow.com/questions/48140339/guava-23-5-
> > > conflict-with-hbase-testing-util-1-2>.
> > > I could not add all the details here because of size limitation.
> > >
> > > In a project I am using Guava 23.5 but some of the dependencies
> (hadoop &
> > > hbase) are using old Guava 14. This is causing an exception during
> > runtime
> > >
> > > As mentioned here <https://www.elastic.co/blog/
> to-shade-or-not-to-shade>
> > I
> > > tried to shade the Hbase dependency in a new module named shadedcdh.
> > > pom.xml
> > > looks like below
> > >
> > > ?xml version="1.0" encoding="UTF-8"?>
> > >
> > > 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";>
> > > 
> > > main
> > > com.vnera
> > > 0.001-SNAPSHOT
> > > 
> > > 4.0.0
> > >
> > > shaded-cdh
> > > jar
> > >
> > > 
> > > 
> > > org.apache.hbase
> > > hbase-testing-util
> > > 1.2.0-cdh5.7.0
> > > 
> > > 
> > > org.apache.hadoop
> > > hadoop-client
> > > ${hadoop.version}
> > > 
> > > 
> > > org.apache.hadoop
> > > hadoop-common
> > > ${hadoop.version}
> > > 
> > > 
> > > org.apache.hbase
> > > hbase-client
> > > 
> > > 1.2.0-cdh5.7.0
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > > org.apache.maven.plugins
> > > maven-shade-plugin
> > > 2.4.1
> > > 
> > > 
> > > package
> > > 
> > > shade
> > > 
> > > 
> > > 
> > > 
> > > com.google.common pattern>
> > >
> > > shaded.com.google.common
> > > 
> > > 
> > > 
> > >  > > implementation="org.apache.maven.plugins.shade.resource.
> > > ManifestResourceTransformer"
> > > />
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > 
> > > 
> > > cloudera
> > > https://repository.cloudera.com/artifactory/
> > > cloudera-repos/
> > > 
> > > 
> > > 
> > > 
> > >
> > > I excluded hbase and hadoop dependency from my project and added
> > > shadedcdh as dependency. But this is still giving me the same
> > > exception. The dependency tree I have posted in the stackoverflow. I
> > > could not post here because of size limitation. Can someone let me
> > > know how can I avoid the conflict?
> > >
> >
>

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

You could try shading the new guava to a different package and use that in
your code.
E.g. jena-shaded-guava does that

Op 20 jan. 2018 09:02 schreef "Debraj Manna" :

> Mark
>
> hbase and hadoop is using the old guava. Is there a way I can use the
> latest guava in my code and let hadoop and hbase use the old guava.
>
> On 20-Jan-2018 1:19 PM, "Mark Prins"  wrote:
>
> > It seems that the guava versions are not API compatible, so shading is
> > unlikely to help. You will need to downgrade to a compatible version of
> > guava or get the other projects to upgrade.
> > -M
> >
> > Op 20 jan. 2018 07:51 schreef "Debraj Manna" :
> >
> > I have posted more details in stackoverflow
> > <https://stackoverflow.com/questions/48140339/guava-23-5-
> > conflict-with-hbase-testing-util-1-2>.
> > I could not add all the details here because of size limitation.
> >
> > In a project I am using Guava 23.5 but some of the dependencies (hadoop &
> > hbase) are using old Guava 14. This is causing an exception during
> runtime
> >
> > As mentioned here <https://www.elastic.co/blog/to-shade-or-not-to-shade>
> I
> > tried to shade the Hbase dependency in a new module named shadedcdh.
> > pom.xml
> > looks like below
> >
> > ?xml version="1.0" encoding="UTF-8"?>
> >
> > 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";>
> > 
> > main
> > com.vnera
> > 0.001-SNAPSHOT
> > 
> > 4.0.0
> >
> > shaded-cdh
> > jar
> >
> > 
> > 
> > org.apache.hbase
> > hbase-testing-util
> > 1.2.0-cdh5.7.0
> > 
> > 
> > org.apache.hadoop
> > hadoop-client
> > ${hadoop.version}
> > 
> > 
> > org.apache.hadoop
> > hadoop-common
> > ${hadoop.version}
> > 
> > 
> > org.apache.hbase
> > hbase-client
> > 
> > 1.2.0-cdh5.7.0
> > 
> > 
> >
> > 
> > 
> > 
> > org.apache.maven.plugins
> > maven-shade-plugin
> > 2.4.1
> > 
> > 
> > package
> > 
> > shade
> > 
> > 
> > 
> > 
> > com.google.common
> >
> > shaded.com.google.common
> > 
> > 
> > 
> >  > implementation="org.apache.maven.plugins.shade.resource.
> > ManifestResourceTransformer"
> > />
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > cloudera
> > https://repository.cloudera.com/artifactory/
> > cloudera-repos/
> > 
> > 
> > 
> > 
> >
> > I excluded hbase and hadoop dependency from my project and added
> > shadedcdh as dependency. But this is still giving me the same
> > exception. The dependency tree I have posted in the stackoverflow. I
> > could not post here because of size limitation. Can someone let me
> > know how can I avoid the conflict?
> >
>

Re: Avoid guava version conflict with hbase by shading

[Mark Prins]

It seems that the guava versions are not API compatible, so shading is
unlikely to help. You will need to downgrade to a compatible version of
guava or get the other projects to upgrade.
-M

Op 20 jan. 2018 07:51 schreef "Debraj Manna" :

I have posted more details in stackoverflow
.
I could not add all the details here because of size limitation.

In a project I am using Guava 23.5 but some of the dependencies (hadoop &
hbase) are using old Guava 14. This is causing an exception during runtime

As mentioned here  I
tried to shade the Hbase dependency in a new module named shadedcdh. pom.xml
looks like below

?xml version="1.0" encoding="UTF-8"?>

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

main
com.vnera
0.001-SNAPSHOT

4.0.0

shaded-cdh
jar



org.apache.hbase
hbase-testing-util
1.2.0-cdh5.7.0


org.apache.hadoop
hadoop-client
${hadoop.version}


org.apache.hadoop
hadoop-common
${hadoop.version}


org.apache.hbase
hbase-client

1.2.0-cdh5.7.0






org.apache.maven.plugins
maven-shade-plugin
2.4.1


package

shade




com.google.common

shaded.com.google.common














cloudera
https://repository.cloudera.com/artifactory/cloudera-repos/





I excluded hbase and hadoop dependency from my project and added
shadedcdh as dependency. But this is still giving me the same
exception. The dependency tree I have posted in the stackoverflow. I
could not post here because of size limitation. Can someone let me
know how can I avoid the conflict?

Re: Package failed

[Mark Prins]

2017-10-31 10:27 GMT+01:00 Oleg Lempert :

> Hi
> I running project with option / -Dmaven.test.skip=true
>

this hint is just for the compiler/surefire/failsafe plugin, but does not
mean that dependency resolution will not happen for this artifact because
in fact it will (and fail)
perhaps you could change the scope to optional instead
-m


> I have dependency : project *Auth *depend on *persistence*
>
> from auth pom.xml:
>
>   
> ${groupId}
> persistence
> ${project.version}
> 
> 
> ${groupId}
> persistence
> ${project.version}
> test-jar
> test
> 
> the package task failed  :
> [ERROR] Failed to execute goal on project auth: Could not resolve
> dependencies for project com.emc.cloud_dr:auth:jar:1.0-SNAPSHOT: Failure
> to
> find com.emc.cloud_dr:persistence:jar:tests:1.0-SNAPSHOT in
>
> but I suppose that /persistence-tests:jar /would not in use cause  *
> test*
> Please help me to understand why is it failed ?
>
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

Re: failsafe: proper shutdown on failure

[Mark Prins]

On 02-10-17 12:12, Veit Guna wrote:

Hi.

I'm using maven failsafe 2.20.1 to setup my test environment (redis, via 
fabric8/docker-maven-plugin) before ITs using pre-integration-test and shut it down on 
post-integration-test. It works just fine when tests are succeeding or failing 
"normally". But when failing "hard" like this:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test 
(default) on project crs-it: Execution default of goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test failed: 
There was an error in the forked process
[ERROR] org.testng.TestNGException:

Due to some class not found exceptions,

or just executing:

mvn clean verify -Dit.test=nonExistingTest

It seems that post-integration-test phase isn't executed properly then, leaving 
my docker container still running.


I think the build is halted after the failure, so no further phases are 
processed. Using "-fae" (fail-at-end) may help, but I may be wrong.


Mark

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

Re: Maven not getting latest artefact after deploy:deploy-file

[Mark Prins]

On 03-08-17 17:57, Mehul Sanghvi wrote:

I will do my best to illustrate with as simple an example as I can.
Hopefully I don't miss anything by simplifying it.


Project-A:
com.my.dept
dept-artefact
11.3.0.1.0-SNAPSHOT

The above is uploaded to Nexus using deploy:deploy-file


Project-B depends on Project-A artefact and so has the following in its POM
file.


   
 com.my.dept
 dept-artefact
 11.3.0.1.0-SNAPSHOT
   




Nexus is setup to keep the latest 5 versions of the SNAPSHOTS.
So I see the following before the upload:

com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--5-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--4-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--3-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--2-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--1-all.zip

I have not shown the POM file and the MD5 and SHA1 files above, but they
also exist with similar names.

Now when I run Project-A, and it deploys a new build of the artefact to
Nexus, then from the above list of files the -1-all.zip file gets deleted,
  and a -6-all.zip file is added, which is the latest version.

When a build of Project-B is triggered, it will pick up the -5-all.zip
rather than the -6-all.zip.  I have to manually update
the metadata in order for Project-B to pick up the latest snapshot.


this reads like a bug in Nexus, or maybe it can't keep up.
there is no way to control nexus from mvn deploy unless you use a nexus 
specific plugin or extension.
You may want to look into using an up-2-date Nexus, current is 
2.14.5-02 and upgrading is only 10mins work





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

[Mark Prins]

Op 13 jan. 2017 18:15 schreef "John Patrick" :

If you only have Java 8 installed, would that work? Or does target
still default to something older?


The default value for the compiler plugin is 1.5 even when using java 8
runtime.
You may want to look into toolchains as well.

Re: Uploading of parent pom of third party library to nexus.

[Mark Prins]

On 13-12-16 17:31, Tester wrote:

Hi,

I'm able to use the mvn deploy-file commando to upload all the child
libraries (powermock-core, powermock-reflect, ...), with for example, the
following command:

mvn deploy:deploy-file -DpomFile=xxx\powermock-core-1.2.5.pom
-Dfile=xxx\powermock-core-1.2.5.jar -DrepositoryId=third-party-repo -Durl=
http://xxx/repository/3rd_party/

However, I'm still missing the parent pom file powermock-1.2.5.pom on my
nexus. However, with deploy-file I'm unable to upload only the parent file.

Any idea how I can get the parent pom file uploaded as well?


You probably want to specify the packaging option to upload a pom 
artifact: 
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html#packaging



Note: The reason why we need to upload it to our own nexus, is because
powermock 1.2.5 is not available on the maven repository anymore.

With kind regards,

Frederik




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

Re: AW: Maven-Site-Plugin: Generated content?

[Mark Prins]

You probably want to create a reporting plugin that you can add to your pom
to create that eXtra content, it 's how maven works

Re: Building maven project and certain specified dependencies to a certain jdk version

[Mark Prins]

On 08-09-16 14:16, Johan Iskandar wrote:

Can you please show me how to do it?


in the dependencies section of your pom add a dependency

javax.validation
validation-api
  YOUR JAVA 5 VERSION 


all available versions are at: 
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.validation%22%20AND%20a%3A%22validation-api%22


good luck; personnaly I would rather upgrade to a current version of 
java and weblogic first





On Sep 8, 2016, at 6:29 PM, Mark Prins  wrote:

You might be able to get away with explicitly declaring a java 5 version of
validation-api in your pom and hope it's api compatible.
-m


--
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.



-
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: Building maven project and certain specified dependencies to a certain jdk version

[Mark Prins]

You might be able to get away with explicitly declaring a java 5 version of
validation-api in your pom and hope it's api compatible.
-m


-- 
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may contain information that is not intended for you or that
you don't understand.

RE: [EXTERNAL] SCM APIs cause "ref HEAD is not a symbolic ref"

[Mark Prins]

Op 15 jun. 2016 16:10 schreef "Justin Georgeson" :
>
> Is the failure happening during CI with a shallow clone? I've seen a few
systems
>
> > -Original Message-
> > From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On
> > Behalf Of Simone Tripodi
> > Sent: Tuesday, June 14, 2016 6:14 PM
> > To: Maven Users List 
> > Subject: [EXTERNAL] SCM APIs cause "ref HEAD is not a symbolic ref"
> >
> > Hi all mates,
> > I've been happily using the Maven SCM APIs to perform few operations
"under
> > the hood" for my users, everything was working fine until stumbled in
the
> > SCMException "Detecting the current branch failed: fatal: ref HEAD is
not a
> > symbolic ref"
> > The scenario is: I am using the libraries below
> >
> >
> > org.apache.maven.scm
> > maven-scm-api
> > ${maven.scm.version}
> > 
> > 
> > org.apache.maven.scm
> > maven-scm-provider-gitexe
> > ${maven.scm.version}
> > 

> > The error happens when invoking the checkIn, do
> > you have any recommendation on how to modify the operations sequence in
> > order to make it working, when checking out a tag?
> >

When you check out a tag in git, the head becomes unattached, you need to
create a branch from the tag and you can then commit to the branch, you
should not attempt to commit to any tag.

Re: Problem With Maven Compiler Plugin

[Mark Prins]

On 10-05-16 16:12, michael.ctr.taru...@faa.gov wrote:

When attempting to build with Maven from Eclipse I am getting the following 
error:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on 
project camel-activemq: Fatal error compiling: tools.jar not found: 
C:\Dev\Java\jre1.8.0_51\..\lib\tools.jar -> [Help 1]

I'm confused about why the plugin is looking in the JRE for tools.jar, when 
this JAR exists in the JDK.



I think the eclipse maven plugin uses the JVM that eclipse is running 
in, so you need to specify either a specific JDK or run eclipse in a JDK 
VM (this is configured in eclipse.ini if I recall correctly)


(or -not recommended- specify a specific compiler in your pom/compiler 
plugin)


-M

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

integration testing a plugin when using a forked lifecycle

[Mark Prins]

I'm trying (but failing) to reliably test a reporting plugin that 
requires some code analysis to be done to produce report input. (code 
analysis produces xml that is xsl transformed to html)


Sometimes my test works, sometimes it doesn't; the test just uses the 
org.apache.maven.it.Verifier#verifyErrorFreeLog() method.


It seems that in some cases the xml has not been (completely) written to 
disk yet causing a plugin execution failure during the transform; and 
basically I'm looking to prevent that from happening.


Any pointers are welcome.


My report plugin is decared as follows:

@Mojo(name = "scss-lint-report",
defaultPhase = LifecyclePhase.SITE,
requiresDependencyResolution = 
ResolutionScope.COMPILE_PLUS_RUNTIME,  threadSafe = false)

@Execute(goal = "scss-lint")
public class SCSSLintReportMojo extends AbstractMavenReport {

   // some code here to call a POJO that does
   // XSL transform produced by the scss-lint goal to produce
   // the HTML page

}

Source code at: 
https://github.com/GeoDienstenCentrum/sass-maven-plugin/blob/master/src/main/java/nl/geodienstencentrum/maven/plugin/sass/report/SCSSLintReportMojo.java



The scss-lint mojo executes a JRuby script to produce a checkstyle-like 
xml report


Source code at: 
https://github.com/GeoDienstenCentrum/sass-maven-plugin/blob/master/src/main/java/nl/geodienstencentrum/maven/plugin/sass/report/SCSSLintMojo.java



Source code for the test is available at: 
https://github.com/GeoDienstenCentrum/sass-maven-plugin/blob/master/src/test/java/nl/geodienstencentrum/maven/plugin/sass/BourbonReportIntegrationTest.java#L78



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

Re: disabling default plugin from phase?

[Mark Prins]

On 04-12-15 02:58, Martin Gainty wrote:

was asked by a local resource to look into resurrecting flex-mojos for a local 
company

Thanks to Jeff, Mirko and Adrien I was able to exec thru all the phases to make 
flexmojos operational ..but..
I am disturbed by EOL notice from code.google.com to take place at end of 
2015http://code.google.com/p/flex-mojos/
Remembering that codehaus projects have been re-provisioned  from codehaus to 
apache servers this year


i'd just hit the "Export to Github" button on 
https://code.google.com/archive/p/flex-mojos/ and switch over



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