Apache Maven 4.0.0-alpha-3 and org.apache.maven.plugins.enforcer.RequirePluginVersions?

[Mirko Friedenhagen]

Hello,

we have configured this rule for ages and now when executing enforcer, I get:

[INFO] --- enforcer:3.1.0:enforce (default-enforce) @  ---
[INFO] Adding ignore: module-info
[INFO] Adding ignore: META-INF/versions/*/module-info
[ERROR] Rule 19: org.apache.maven.plugins.enforcer.RequirePluginVersions failed 
with message:
Some plugins are missing valid versions or depend on Maven 4.0.0-alpha-3 
defaults: (LATEST RELEASE SNAPSHOT are not allowed)
com.unitedinternet.portal.maven2.plugin:portal-manifest-maven-plugin. The 
version currently in use is 3.1.3 via super POM or default lifecycle bindings
net.oneandone.maven.plugins:bill-of-materials-maven-plugin. The version 
currently in use is 3.1 via super POM or default lifecycle bindings
org.codehaus.mojo:buildnumber-maven-plugin. The version currently in use is 
3.0.0 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-source-plugin. The version currently in use is 
3.2.1 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-site-plugin. The version currently in use is 
3.12.1 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-resources-plugin. The version currently in use 
is 3.1.0 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-toolchains-plugin. The version currently in use 
is 3.1.0 via super POM or default lifecycle bindings
com.unitedinternet.portal.maven2.plugin:portal-dependency-maven-plugin. The 
version currently in use is 4.4.42 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-compiler-plugin. The version currently in use is 
3.10.1 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-surefire-plugin. The version currently in use is 
3.0.0-M7 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-jar-plugin. The version currently in use is 
3.3.0 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-clean-plugin. The version currently in use is 
3.2.0 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-failsafe-plugin. The version currently in use is 
3.0.0-M7 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-wrapper-plugin. The version currently in use is 
3.1.0 via default lifecycle bindings
org.apache.maven.plugins:maven-dependency-plugin. The version currently in use 
is 3.4.0 via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-install-plugin. The version currently in use is 
3.1.0 via super POM or default lifecycle bindings
pl.project13.maven:git-commit-id-plugin. The version currently in use is 4.9.10 
via super POM or default lifecycle bindings
org.apache.maven.plugins:maven-deploy-plugin. The version currently in use is 
3.0.0 via super POM or default lifecycle bindings
net.rumati.maven.plugins:velocity-maven-plugin. The version currently in use is 
0.3.1 via super POM or default lifecycle bindings
org.jacoco:jacoco-maven-plugin. The version currently in use is 0.8.8 via super 
POM or default lifecycle bindings
org.cyclonedx:cyclonedx-maven-plugin. The version currently in use is 2.7.3 via 
super POM or default lifecycle bindings
org.apache.maven.plugins:maven-enforcer-plugin. The version currently in use is 
3.1.0 via super POM or default lifecycle bindings
Best Practice is to always define plugin versions!

All of these versions are managed in the company-pom’s pluginManagement 
section. But maybe this is a followup error because we overrode the default 
lifecycle bindings in a component.xml of an extension 
(https://lists.apache.org/thread/lgvbnw4qq30rbx4osn8qzyy2y9ro4hdy). 

In the extension’s component.xml file we did not specify any versions, but rely 
on pluginManagement of the including POM. Works fine with Maven 3.8.6 but now 
behaves differently with 4.0.0.

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

Re: maven 4 alpha

[Mirko Friedenhagen]

Hi John,

I do not think you need a special Windows build, just unpack the ZIP or tar.gz 
from 
https://repo1.maven.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-3/.

Please see my previous post 
(https://lists.apache.org/thread/g40p4ytdlnczpo3bwvht1thhg9l0d566), Maven 4 
behaves sometimes differently.

Regards
Mirko


> Am 19.12.2022 um 16:20 schrieb John Lilley 
> :
> 
> Is maven 4.0 a drop-in replacement for maven 3.x?  Would you expect all of 
> the plugins to be compatible?
> If there is a windows install available I would like to test it and see if it 
> resolves a hang issue I’ve been trying to get around.
> Thanks
> John
>  
> 
>    
> John Lilley 
> Data Management Chief Architect, Redpoint Global Inc.
> 888 Worcester Street, Suite 200 Wellesley, MA 02482
> M: +1 7209385761  | john.lil...@redpointglobal.com 
> 
> PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is 
> confidential and is intended solely for the use of the individual(s) to whom 
> it is addressed. If you believe you received this e-mail in error, please 
> notify the sender immediately, delete the e-mail from your computer and do 
> not copy, print or disclose it to anyone else. If you properly received this 
> e-mail as a customer, partner or vendor of Redpoint, you should maintain its 
> contents in confidence subject to the terms and conditions of your 
> agreement(s) with Redpoint.

MavenXpp3Reader.read: difference between Maven 3.8.6 and 4.0.0-alpha-3

[Mirko Friedenhagen]

Hello,

please see 
https://github.com/mfriedenhagen/cyclonedx-maven-plugin-maven4-logging for an 
example of the problem. 

When running `mvn -V -q clean cyclonedx:makeBom` with Maven 4 an error message 
is shown while with Maven 3 the error path is not reached. 

It looks like MavenXpp3Reader.read behaves differently.

The error is understandable, the cyclonedx plugin does inspect the embedded 
pom.xml beneath META-INF/maven/ and that one for 
net.logstash.logback:logstash-logback-encoder:jar:6.6 is not a valid POM (there 
is an element  in a plugin but outside of an execution, see 
https://github.com/logfellow/logstash-logback-encoder/blob/logstash-logback-encoder-6.6/pom.xml#L232).


https://github.com/CycloneDX/cyclonedx-maven-plugin/blob/59e71a6b74b07f65d9fa1046ff7ad881dbd6c96f/src/main/java/org/cyclonedx/maven/BaseCycloneDxMojo.java#L759-L759

Is Maven 4 stricter while parsing XML?

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

Overriding/extending Default XXXLifecycleMappingProvider

[Mirko Friedenhagen]

Hi,

in the past we have used a Maven jar where we just placed a 
src/main/resources/META-INF/plexus/components.xml which did override the called 
goals for different types resp. even created new types (e.g. a 
spring-boot-jar). We included this jar as `extension` in the `build` section of 
our company pom. This allowed us to easily enforce execution of e.g. 
failsafe:verify for JARs, WARs and SPRING-BOOT-JARs while excluding this for 
POMs.


With 
https://github.com/apache/maven/commit/6c7d105916bb288b1f0f7010035c718f16e11240#diff-e56beaf8ffd2642855c03d4bbcc8bd7a33a4e50582b8bd540b3bea6aee63f683
 the old XML structures are gone and replaced by Java classes.

Is it possible to somehow override/replace the existing standard 
JarLifecycleMappingProvider, PomLifecycleMappingProvider and 
WarLifecycleMappingProvider without patching the Maven distribution?

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

Apache 3.8.5 installAtEnd not working when another repository is defined

[Mirko Friedenhagen]

Hello,

I just ran into this issue:
* In some Maven projects we activate additional repositories in settings.xml 
with the help of a marker file in a project.
* With 3.8.4 using `installAtEnd` resp. `deployAtEnd` do work properly, with 
3.8.5 and 3.8.6 nothing is installed or deployed.
* I created a small sample project with instructions how to reproduce at 
https://github.com/mfriedenhagen/atend.

Maybe this is related to https://issues.apache.org/jira/browse/MNG-6802?

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

[ANN] Versions Maven Plugin 2.8.1 released

[Mirko Friedenhagen]

Hi,

The Mojo team is pleased to announce the release of the Versions Plugin version 
2.8.1.

The Versions Plugin is used when you want to manage the versions of artifacts 
in a project's POM.

https://www.mojohaus.org/versions-maven-plugin/

To get this update, simply specify the version in your project's plugin 
configuration:


  org.codehaus.mojo
  versions-maven-plugin
  2.8.1


Release Notes:

https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.8.1

Enjoy,

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

Re: Finding out what the versions plugin did

[Mirko Friedenhagen]

Hello,

we do something similar:

GIT_MESSAGE=/tmp/git-message.txt
mvn -B -V -e -l /tmp/maven-logfile versions:use-latest-releases 
versions:update-properties
cat << EOF > ${GIT_MESSAGE}
mvn -B -V -e -l /tmp/maven-logfile versions:use-latest-releases 
versions:update-properties

https://git.example.com/tpq/divpom/builds/${CI_JOB_ID} 


EOF
grep '\[INFO\] Updated ' /tmp/maven-logfile >> ${GIT_MESSAGE} && mvn -B -V -e 
verify || echo "No updates detected“

Regards
Mirko

> Am 07.07.2019 um 13:59 schrieb Tomo Suzuki  >:
> 
> Hi Mark,
> 
> I would either
> 
> 1. try display-dependency-updates and other display-* goals:
> 
> https://www.mojohaus.org/versions-maven-plugin/examples/display-dependency-updates.html
>  
> 
> 
> https://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html
>  
> 
> 
> 
> 2. leverage the backup file(s) created by the versions plugin
> before committing.
> 
> “diff pom.xml pom.xml.versionsBackup”
> 
> Both approaches still require parsing the output though.
> 
> Regards,
> Tomo
> 
> On Sun, Jul 7, 2019 at 06:09 Mark Raynsford
>  wrote:
> 
>> Hello!
>> 
>> Is there a machine-readable way I can find out what the Versions plugin
>> did after I've executed it? I'm writing a CI task that tries to
>> periodically update the dependencies of a project.
>> 
>> Essentially, the task does this:
>> 
>> $ mvn clean verify
>> $ mvn -DallowMajorUpdates=false \
>>  versions:use-latest-releases \
>>  versions:update-properties
>> $ mvn clean verify
>> 
>> If the second "clean verify" execution succeeds, then we assume that
>> all the new dependency versions are fine. The task then goes on to
>> commit the pom.xml changes.
>> 
>> The problem: I'd like to retrieve the list of dependencies that were
>> updated (their previous and current versions) so that I can produce a
>> nice commit message and changelog entry. I can't seem to get this
>> information out of the plugin.
>> 
>> I've seen the documentation for the dependency-updates-report goal, so
>> I tried doing this:
>> 
>> $ mvn clean verify
>> $ mvn \
>>  -DallowMajorUpdates=false \
>>  -DdependencyUpdatesReportFormats=xml
>>  -DoutputDirectory=. \
>>  versions:dependency-updates-report \
>>  versions:use-latest-releases \
>>  versions:update-properties
>> $ mvn clean verify
>> 
>> But this just doesn't appear to produce any output. Am I doing
>> something wrong?
>> 
>> Is there some better way to do this?
>> 
>> --
>> Mark Raynsford | http://www.io7m.com
>> 
>> --
> Regards,
> Tomo

Re: Finding out what the versions plugin did

[Mirko Friedenhagen]

Hello,

we do something similar:

GIT_MESSAGE=/tmp/git-message.txt
mvn -B -V -e -l /tmp/maven-logfile versions:use-latest-releases 
versions:update-properties
cat << EOF > ${GIT_MESSAGE}
mvn -B -V -e -l /tmp/maven-logfile versions:use-latest-releases 
versions:update-properties

https://git.example.com/tpq/divpom/builds/${CI_JOB_ID} 


EOF
grep '\[INFO\] Updated ' /tmp/maven-logfile >> ${GIT_MESSAGE} && mvn -B -V -e 
verify || echo "No updates detected“

Regards
Mirko

> Am 07.07.2019 um 13:59 schrieb Tomo Suzuki  >:
> 
> Hi Mark,
> 
> I would either
> 
> 1. try display-dependency-updates and other display-* goals:
> 
> https://www.mojohaus.org/versions-maven-plugin/examples/display-dependency-updates.html
>  
> 
> 
> https://www.mojohaus.org/versions-maven-plugin/display-property-updates-mojo.html
>  
> 
> 
> 
> 2. leverage the backup file(s) created by the versions plugin
> before committing.
> 
> “diff pom.xml pom.xml.versionsBackup”
> 
> Both approaches still require parsing the output though.
> 
> Regards,
> Tomo
> 
> On Sun, Jul 7, 2019 at 06:09 Mark Raynsford
>  > wrote:
> 
>> Hello!
>> 
>> Is there a machine-readable way I can find out what the Versions plugin
>> did after I've executed it? I'm writing a CI task that tries to
>> periodically update the dependencies of a project.
>> 
>> Essentially, the task does this:
>> 
>> $ mvn clean verify
>> $ mvn -DallowMajorUpdates=false \
>>  versions:use-latest-releases \
>>  versions:update-properties
>> $ mvn clean verify
>> 
>> If the second "clean verify" execution succeeds, then we assume that
>> all the new dependency versions are fine. The task then goes on to
>> commit the pom.xml changes.
>> 
>> The problem: I'd like to retrieve the list of dependencies that were
>> updated (their previous and current versions) so that I can produce a
>> nice commit message and changelog entry. I can't seem to get this
>> information out of the plugin.
>> 
>> I've seen the documentation for the dependency-updates-report goal, so
>> I tried doing this:
>> 
>> $ mvn clean verify
>> $ mvn \
>>  -DallowMajorUpdates=false \
>>  -DdependencyUpdatesReportFormats=xml
>>  -DoutputDirectory=. \
>>  versions:dependency-updates-report \
>>  versions:use-latest-releases \
>>  versions:update-properties
>> $ mvn clean verify
>> 
>> But this just doesn't appear to produce any output. Am I doing
>> something wrong?
>> 
>> Is there some better way to do this?
>> 
>> --
>> Mark Raynsford | http://www.io7m.com 
>> 
>> --
> Regards,
> Tomo

Re: xml validation plugin against xsd

[Mirko Friedenhagen]

Hello Aitor,

https://www.mojohaus.org/xml-maven-plugin/examples/validate-schema.html might 
be what you are looking for as you said _x_html which is xml.

Best Regards 
Mirko Friedenhagen
— 
Sent from my mobile 

Am 30.11.18 um 19:01 schrieb Aitor Iturriondobeitia

> hello
> do you know any maven plugin for validating xml against xsd?
> thanks

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

Re: invoker tests using multiple maven versions

[Mirko Friedenhagen]

Hello Matthieu,

I always enforce using different versions in the CI. 

Sample for Travis:
* https://github.com/1and1/ono-maven-shared/blob/master/.travis.yml 
 - (uses 
Maven Wrapper)

Sample for GitLab:
* https://gitlab.com/mfriedenhagen/foss-parent/blob/master/.gitlab-ci.yml 
 (uses 
curl to install Maven)

And the Maven developers use Jenkins to test plugins with different JDKs and 
Maven versions:

https://gitbox.apache.org/repos/asf?p=maven-deploy-plugin.git;a=blob;f=Jenkinsfile;h=e9f05f7d979850fecae9ce1b5c4f499d052e8d4b;hb=HEAD
 


Definition of `asfMavenTlpPlgnBuild` at 
https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;hb=HEAD
 


Regards
Mirko


> Am 26.11.2018 um 11:35 schrieb Matthieu BROUILLARD :
> 
> Hi all,
> 
> I would like to know the best ways to test a plugin against different maven
> versions?
> Especially is there a way to run maven-invoker-plugin using different maven
> versions?
> 
> I can think of some scripting for CI and usage of wrapper but I wanted to
> know how people do currently.
> 
> Thanks.
> 
> Matthieu Brouillard

Re: Username/password not sent for altDeploymentRepository?

[Mirko Friedenhagen]

Maybe you run into 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MDEPLOY-244. 
maven-deploy-Plugin 3.0x has a slightly different syntax for specifying 
alt*Repositories.

Best Regards 
Mirko Friedenhagen
— 
Sent from my mobile 

Am 04.11.18 um 22:47 schrieb Mark Raynsford

> I've been completely unable to get this work. It seems like
> altDeploymentRepository just doesn't pick up credentials for whatever
> reason.
> 
> I've instead taken this approach: In my organization-wide POM, I've
> added a profile:
> 
> 
> 
>   io7m-alternate-repository
>   
> 
>   io7m.useAlternateRepository
> 
>   
>   
> 
>   ${io7m.repository.releases.id}
>   ${io7m.repository.releases.url}
> 
> 
>   ${io7m.repository.snapshots.id}
>   ${io7m.repository.snapshots.url}
> 
>   
> 
> 
> I then deploy with:
> 
> $ mvn \
>   -Dio7m.useAlternateRepository=true  
>  \
>   -Dio7m.repository.releases.id=example-releases  
>  \ 
>   
> -Dio7m.repository.releases.url=https://packages.example.com:8443/repository/example-releases/
> \
>   -Dio7m.repository.snapshots.id=example-snapshots
>  \ 
>   
> -Dio7m.repository.snapshots.url=https://packages.example.com:8443/repository/example-snapshots/
>   \
>   clean deploy 
> 
> I have a  element in settings.xml that supplies credentials for
> repositories with ids "example-releases" and "example-snapshots" and
> the credentials are picked up correctly by the deploy plugin.
> 
> -- 
> Mark Raynsford | http://www.io7m.com

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

Re: Specifying a deployment repository *only* by ID?

[Mirko Friedenhagen]

Hello Mark,

you may put the property in a profile of your settings.xml and just call „mvn 
-P releases deploy“ given the profile is called releases.

Best Regards 
Mirko Friedenhagen
— 
Sent from my mobile 

Am 03.11.18 um 17:55 schrieb Mark Raynsford

> Hello.
> 
> If I want to deploy to a different repository, I can use the
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository
> property:
> 
>   $ mvn deploy 
> -DaltDeploymentRepository=releases::default::https://packages.example.com/repository/releases
> 
> This is cumbersome, because I've already provided that URI and layout
> in the ~/.m2/settings.xml file. I'd much rather do:
> 
>   $ mvn deploy -DaltDeploymentRepository=releases
> 
> Is there some way I can achieve this without putting anything in the
> project's pom.xml?
> 
> -- 
> Mark Raynsford | http://www.io7m.com

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

Re: Extension works from lib/ext and CLI but not extensions.xml

[Mirko Friedenhagen]

Hello,

I think extensions are looked up in pluginRepositories, not the standard 
repositories. Maybe that’s your problem?

Best Regards 
Mirko Friedenhagen
— 
Sent from my mobile 

Am 26.10.18 um 17:41 schrieb Karl Heinz Marbaise

> Hi,
> 
> On 26/10/18 10:16, Matthieu BROUILLARD wrote:
> > Not sure but I think the mechanism extension does not work for SNAPSHOT
> > versions.
> 
> 
> No. There is something else different/wrong...
> 
> 
> > Try to install a non SNAPSHOT version in your local maven repository.
> > I think I have already faced the same in the past while producing with my
> > own extension https://github.com/jgitver/jgitver-maven-plugin
> > 
> > Hope it helps.
> > 
> > Matthieu
> > 
> > On Fri, Oct 26, 2018 at 7:39 AM J. Lewis Muir  wrote:
> > 
> >> Hello, all!
> >>
> >> I'm trying to use the EL Profile Activation Maven Extension
> >>
> >>https://github.com/kpiwko/el-profile-activator-extension
> >>
> >> to activate a profile when the foo_env system property is either not
> >> set, or set to "development".  I'm using the "help:active-profiles" goal
> >> of the Maven Help plugin and the "validate" phase to test whether or not
> >> a profile is active.
> >>
> >> The extension works when I install it in
> >>
> >>/lib/ext
> >>
> >> and it works when I specify it on the command line with
> >>
> >>-Dmaven.ext.class.path=
> >>
> >> but it does *not* work when I put it in the project's
> >>
> >>.mvn/extensions.xml
> >>
> >> Does anyone know why?!
> >>
> >> This is Maven 3.5.4, the latest Git snapshot of EL Profile Activation
> >> Maven Extension, and MVEL 2.4.2.Final.
> >>
> >> The el-profile-activator-extension artifact is not published in the
> >> Central Repository, but I installed it into my local repository (i.e.,
> >> ~/.m2/repository) with
> >>
> >>git clone https://github.com/kpiwko/el-profile-activator-extension.git
> >>cd el-profile-activator-extension
> >>: JAVA_HOME has been set to a Java 8 SDK to compile
> >>mvn install
> >>
> >> That should be fine, right?  My local repository will be searched first
> >> for any artifacts listed in extensions.xml, and I don't get a warning
> >> nor error about it not being found, so my understanding is that this is
> >> OK.
> >>
> >> For the case where the extension does not work, I have a test-01 project
> >> directory containing the following pom.xml file
> >>
> >>
> >>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
> >>  org.example.foo
> >>  foo
> >>  1.0.0
> >>  pom
> >>  
> >>
> >>  foo_env-development
> >>  
> >>
> >>  mvel
> >>  (!isdef foo_env) || (isdef foo_env  foo_env
> >> == "development")
> >>
> >>  
> >>
> >>  
> >>
> >>
> >> and the following .mvn/extensions.xml file
> >>
> >>http://maven.apache.org/EXTENSIONS/1.0.0;
> >>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >>xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> >>http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
> >>  
> >>com.redhat.jboss.maven
> >>el-profile-activator-extension
> >>1.0.0-SNAPSHOT
> >>  
> >>
> >>
> >> I invoke Maven like this
> >>
> >>mvn help:active-profiles validate
> >>
> >> and it shows that the foo_env-development profile is not active (i.e.,
> >> it lists no active profiles)
> >>
> >>The following profiles are active:
> >>
> >> but it should be!
> >>
> >> A transcript of this and with the "-X" option is attached as
> >>
> >>test-01-extensions-dot-xml.txt
> >>
> >> Removing the .mvn directory and adding
> >>
> >>  

Re: Maven best practices for easily developer tweakable config file

[Mirko Friedenhagen]

Another possible solution could be to activate your custom logging.properties 
would be to use a profile

Given the following layout:
pom.xml
src/main/resources/logging.properties

Now normally the maven-resources-plugin will copy this file to 
target/classes/logging.properties during build and test runs and you may load 
it from the class-path (I did not check whether java.util.logging.config.file 
may do a class path lookup, though)

Add a profile to your pom.xml like this:

local-logging.properties


${user.dir}/debug-resources/logging.properties





${user.dir}/debug-resources/





Create your modified logging.properties at 
`./debug-resources/logging.properties`, add `debug-resources/` to .gitignore

Then this should override the one from src/main/resources (not tested!)

Regards
Mirko

> Am 05.09.2018 um 20:08 schrieb Robert Scholte :
> 
> bq. I have the logging.properties file the app uses at a particular place.
> 
> So it seems specify the location of this file somewhere, probably with the 
> java.util.logging.config.file property.
> How about changing the value of this property?
> 
> Robert
> 
> On Tue, 04 Sep 2018 16:15:00 +0200, Matthew Cline  
> wrote:
> 
>> I'm currently migrating from Ant to Maven, and am wondering how to
>> translate the following:
>> 
>> My project uses java.util.logging.  I have the logging.properties file
>> the app uses at a particular place.  To see what's going on I'll often
>> lower the level of a certain class or package in order to get more
>> logging output, then change it again once I'm done.  Since I'm
>> frequently changing it, this file isn't tracked by git.  However, I do
>> have a default version of logging.properties tracked by git.  If the
>> logging.properties which the app is pointed at is missing, then ant
>> copies the default version there.
>> 
>> However, I get the feeling that this isn't the way to do things with
>> Maven.  So what is the Maven way?
>> 
>> 
>> -
>> 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 tell maven where to look for extensions (instead of central repository)

[Mirko Friedenhagen]

Hello,

I observed that extensions seem to be fetched from pluginRepositories.

Best regards
Mirko
-- 
Sent from my mobile

Am 17.03.2018 11:59 schrieb "Anders Hammar" :

> You need to provide more info to understand your questions.
> "obviously everything else fails"? why obviously?
> "why are plugin repositories being ignored? they shouldn't for plugins and
> their deps. If it is it's most likely due to a misconfiguration on your
> end, but it could be a bug in maven.
>
> /Anders
>
> On Fri, Mar 16, 2018 at 8:21 AM, Salvatore  wrote:
>
> > That is a bigger change than I expected...
> > I've configured a * pointing to my repo to test it
> > out, and now the extension is being downloaded, but obviously everything
> > else fails. I cannot modify nexus configuration myself, so it seems I
> will
> > have to download the jar manually for now :(
> >
> > Can I ask why is this needed? Why are plugin repositories being ignored?
> Is
> > it bad to have multiple repositories configured or is this a bug?
> >
> > Thank you Karl.
> > Regards,
> > Salva
> >
> > 2018-03-15 20:35 GMT+01:00 Karl Heinz Marbaise :
> >
> > > Hi,
> > >
> > > On 15/03/18 20:12, Salvatore wrote:
> > >
> > >> Hello,
> > >> I have tried with maven 3.3.9 and 3.5.0. I will try with 3.5.3
> tomorrow
> > >> too.
> > >> The repos are configured via settings.xml. I have them both as
> > >>  and as . If the docs are right, the
> > plugin
> > >> repositories should be the important ones for extensions but all I see
> > when
> > >> I run any goal on that project, with debug enabled, is:
> > >>
> > >> [WARNING] Failed to read extensions descriptor
> > >> /home/my-user/git/my-project/.mvn/extensions.xml: Plugin
> > >> com.our-company:kompile-maven-extension:1.0 or one of its
> dependencies
> > >> could not be resolved: Could not find artifact
> > >> com.our-company:kompile-maven-extension:jar:1.0 in central (
> > >> https://repo.maven.apache.org/maven2)
> > >>
> > >> There is no line showing that maven tried to download the extension
> from
> > >> any other repo. Thats the only one that is checking out apparently.
> > That's
> > >> why I thought that maybe extensions are not ready to be downloaded
> from
> > >> custom repos yet...
> > >>
> > >> I have posted this question in StackOverflow too:
> > >> https://stackoverflow.com/questions/49284462/failed-to-read-
> > >> extensions-descriptor-could-not-find-artifact-in-central
> > >>
> > >> Maybe our Sonatype is outdated and we have to updated it to support
> > >> extensions? I have to admit I don't know what version are we using,
> but
> > I
> > >> can check that out if it makes sense.
> > >>
> > >
> > > It looks like you have configured many repositories in your
> settings.xml
> > > instead of having a single group[1] and the configuration put to the
> > > repository manager like Nexus...
> > >
> > > Furthermore have you checked that the extension you are trying to get
> is
> > > really under the given coordinates and the same version available ?
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > > [1]: https://books.sonatype.com/nexus-book/2.8/reference/maven-
> > > sect-single-group.html
> > >
> > >
> > >> Thank you Karl, I appreciate your help.
> > >>
> > >> 2018-03-15 19:54 GMT+01:00 Karl Heinz Marbaise  > >> >:
> > >>
> > >> Hi,
> > >>
> > >> On 15/03/18 11:51, Salvatore wrote:
> > >>
> > >> Hello, first time here. I have a quick question:
> > >> Is it possible to use a maven extension that is not in maven
> > >> central
> > >> without downloading the jar manually? nor doing a mvn install
> > >> locally?
> > >>
> > >> Cause I have been trying to find out why is my extension not
> > being
> > >> downloaded by maven from my own repository, but maybe the
> > >> problem is that
> > >> this is not possible!
> > >>
> > >> And that's pretty much it. If it is indeed possible then I
> will
> > >> have to ask
> > >> a new question, cause maven doesn't seem to care about my
> repos
> > >> at all haha.
> > >>
> > >>
> > >> First question related to that. Which Maven version do you use?
> > >> How have you configured your own repositories? Via settings.xml or
> > >> via repository manager ?
> > >>
> > >> Kind regards
> > >> Karl Heinz Marbaise
> > >>
> > >>
> > >>
> >
>

Re: javadoc:jar and generated sources

[Mirko Friedenhagen]

Hello there,

one other idea:
* see https://maven.apache.org/pom.html#The_Super_POM
* release:perform activates the release-profile
* inside of the release-profile an execution attach-sources is
defined, which maybe does not inherit your configuration?

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 15, 2018 at 7:11 PM, Laird Nelson  wrote:
> On Thu, Mar 15, 2018 at 1:38 AM Thomas Broyer  wrote:
>
>> Be careful in your testing: javadoc:javadoc forks a lifecycle at
>> 'generate-sources' phase (and javadoc:aggregate at 'compile' phase),
>> whereas javadoc:jar does not!
>>
>
> An excellent point.
>
>
>> So running 'mvn javadoc:jar' alone indeed won't run your protoc plugin,
>> which won't add the generated sources as a compile source root.
>
>
> OK, so that's the explanation for my debugging session.
>
> Best,
> Laird

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

Re: How to solve dependency convergence issue

[Mirko Friedenhagen]

Hello Niranja,

you may find more details at
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.

Basically a version you manage in your project is more important than
one managed in your project's parent which is more important than a
version coming into the tree transitively.

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 7, 2018 at 8:26 AM, Anders Hammar  wrote:
> This shouldn't be solved via exclusions but rather by specifying the wanted
> version in the dependencyManagement section of your project.
>
> /Anders
>
> On Tue, Mar 6, 2018 at 10:37 PM, Niranjan Rao  wrote:
>
>> Greetings,
>>
>>
>> I am using maven-enforcer-plugin to ensure only one version of jar files
>> is loaded. In case of conflicts, I normally would use exclusions to weed
>> out unwanted jars. Normally I would pick latest version of library.
>>
>> I am not clear how to solve following problem reported by maven enforcer
>> plugin. I am adding dependency on org.hibernate:hibernate-core which in
>> turn has dependency on org.hibernate.common:hibernate-commons-annotations.
>> Both these are pulling different versions on jboss-logging.
>>
>>
>> If I add exclusion on jboss-logging, which will get dropped? How do I
>> force to drop dependency from 
>> org.hibernate.common:hibernate-commons-annotations
>> where it seems to be using older version.
>>
>>
>> Dependency convergence error for org.jboss.logging:jboss-logging:3.3.1.Final
>> paths to dependency are:
>> +group:artifcat:version
>>   +-org.hibernate:hibernate-core:5.2.14.Final
>> +-org.jboss.logging:jboss-logging:3.3.1.Final
>> and
>> +group:artifcat:version
>>   +-org.hibernate:hibernate-core:5.2.14.Final
>> +-org.hibernate.common:hibernate-commons-annotations:5.0.1.Final
>>   +-org.jboss.logging:jboss-logging:3.3.0.Final
>>
>>
>> Thanks,
>>
>>
>> Niranjan
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

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

Re: per-warm the maven cache for 2 stage Docker build

[Mirko Friedenhagen]

Hello Adam,

as stated on the goal page[0] dependency:go-offline "Requires
dependency resolution of artifacts in scope: test". In multi-module
projects it might even fail because of unresolvable SNAPSHOT modules
of the current reactor.

I use this shell script (I call it mvn-go-offline):
--- snip ---
#!/bin/sh
# DESC: Try to download everything needed for building/testing the project.
MVN=${MVN:-mvn}
VERSION=3.0.2
PLUGIN=org.apache.maven.plugins:maven-dependency-plugin:${VERSION}
exec ${MVN} -e -V $* $PLUGIN:resolve-plugins $PLUGIN:go-offline $PLUGIN:sources
--- snap ---
and call e.g. `mvn-go-offline test-compile`.

Regards
Mirko

[0] 
https://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html

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

Re: warning messages

[Mirko Friedenhagen]

Hello Bill,

~/Library/Java/Extensions crossed my mind as well. You could even create
this folder  at root level, i.e. /Library/...

Personally I would stay away from putting stuff in these folders, as
afterwards your build might not be reproducible.

Best regards
Mirko
-- 
Sent from my mobile

Am 28.02.2018 22:52 schrieb "Bill Tantzen" <tantz...@umn.edu>:

> It works!  The final solution was to remove EVERY jar file from
> ~/Library/Java/Extensions, and voila, all is good.  A next step might
> be to add the jars back one-by-one to find the culprit, but I will
> save that for another day...  There was nothing suspicious looking
> there, but obviously, there was a conflict in at least one of the
> libraries.
>
> Thanks a million!
> --Bill
>
> On Wed, Feb 28, 2018 at 3:41 PM, Mirko Friedenhagen
> <mfriedenha...@gmail.com> wrote:
> > Hello Bill,
> > sorry for the confusion, MAVEN_OPTS does not need to be set but might
> > influence e.g. your classpath.
> >
> > Please write what you are doing exactly.
> > Is this a general problem or only a problem for one project.
> >
> >  I use 3.5.2 day by day and never saw these messages.
> >
> > Best regards
> > Mirko
> > --
> > Sent from my mobile
> >
> > Am 28.02.2018 15:13 schrieb "Bill Tantzen" <tantz...@umn.edu>:
> >
> >> Thanks Mirko -- I've tried it both ways (brew and download) with
> >> exactly the same results.  There seems to be something interfering
> >> with Maven's built-in slf4j support, but I cannot find what it is.
> >>
> >> I don't have any MAVEN_OPTS -- can you share an example?
> >>
> >> Thanks!
> >> --Bill
> >>
> >> On Tue, Feb 27, 2018 at 4:43 PM, Mirko Friedenhagen
> >> <mfriedenha...@gmail.com> wrote:
> >> > Hello Bill,
> >> >
> >> > I am running Maven 3.5.2 on macOS high sierra with Oracle JDK 1.8.162
> and
> >> > do not see these messages. I installed Maven using brew.
> >> >
> >> > Did you just download and unpack the tar.gz?
> >> >
> >> > Do you set MAVEN_OPTS either in your .bashrc or maybe .mavenrc file?
> >> >
> >> > Best regards
> >> > Mirko
> >> > --
> >> > Sent from my mobile
> >> >
> >> > Am 27.02.2018 22:51 schrieb "Bill Tantzen" <tantz...@umn.edu>:
> >> >
> >> >> Friends:
> >> >>
> >> >> mac os sierra
> >> >> maven 3.5.2
> >> >> java 1.8.0_25
> >> >>
> >> >> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> >> >> SLF4J: Defaulting to no-operation (NOP) logger implementation
> >> >> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
> >> >> further details.
> >> >>
> >> >> I have added the following to my classpath in an attempt to eliminate
> >> >> these wanings:
> >> >>
> >> >> slf4j-api-1.7.25.jar
> >> >> slf4j-nop-1.7.25.jar
> >> >>
> >> >> I no longer see the warnings -- is this all I need to do?  Am I
> losing
> >> >> any output to my console by using the nop binding?
> >> >>
> >> >> -- Regards,
> >> >> Bill
> >> >>
> >> >> 
> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> >>
> >> >>
> >>
> >>
> >>
> >> --
> >> Human wheels spin round and round
> >> While the clock keeps the pace... -- John Mellencamp
> >> 
> >> Bill TantzenUniversity of Minnesota Libraries
> >> 612-626-9949 (U of M)612-325-1777 (cell)
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
>
>
> --
> Human wheels spin round and round
> While the clock keeps the pace... -- John Mellencamp
> 
> Bill TantzenUniversity of Minnesota Libraries
> 612-626-9949 (U of M)612-325-1777 (cell)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: warning messages

[Mirko Friedenhagen]

Hello Bill,
sorry for the confusion, MAVEN_OPTS does not need to be set but might
influence e.g. your classpath.

Please write what you are doing exactly.
Is this a general problem or only a problem for one project.

 I use 3.5.2 day by day and never saw these messages.

Best regards
Mirko
-- 
Sent from my mobile

Am 28.02.2018 15:13 schrieb "Bill Tantzen" <tantz...@umn.edu>:

> Thanks Mirko -- I've tried it both ways (brew and download) with
> exactly the same results.  There seems to be something interfering
> with Maven's built-in slf4j support, but I cannot find what it is.
>
> I don't have any MAVEN_OPTS -- can you share an example?
>
> Thanks!
> --Bill
>
> On Tue, Feb 27, 2018 at 4:43 PM, Mirko Friedenhagen
> <mfriedenha...@gmail.com> wrote:
> > Hello Bill,
> >
> > I am running Maven 3.5.2 on macOS high sierra with Oracle JDK 1.8.162 and
> > do not see these messages. I installed Maven using brew.
> >
> > Did you just download and unpack the tar.gz?
> >
> > Do you set MAVEN_OPTS either in your .bashrc or maybe .mavenrc file?
> >
> > Best regards
> > Mirko
> > --
> > Sent from my mobile
> >
> > Am 27.02.2018 22:51 schrieb "Bill Tantzen" <tantz...@umn.edu>:
> >
> >> Friends:
> >>
> >> mac os sierra
> >> maven 3.5.2
> >> java 1.8.0_25
> >>
> >> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> >> SLF4J: Defaulting to no-operation (NOP) logger implementation
> >> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
> >> further details.
> >>
> >> I have added the following to my classpath in an attempt to eliminate
> >> these wanings:
> >>
> >> slf4j-api-1.7.25.jar
> >> slf4j-nop-1.7.25.jar
> >>
> >> I no longer see the warnings -- is this all I need to do?  Am I losing
> >> any output to my console by using the nop binding?
> >>
> >> -- Regards,
> >> Bill
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
>
>
> --
> Human wheels spin round and round
> While the clock keeps the pace... -- John Mellencamp
> 
> Bill TantzenUniversity of Minnesota Libraries
> 612-626-9949 (U of M)612-325-1777 (cell)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: warning messages

[Mirko Friedenhagen]

Hello Bill,

I am running Maven 3.5.2 on macOS high sierra with Oracle JDK 1.8.162 and
do not see these messages. I installed Maven using brew.

Did you just download and unpack the tar.gz?

Do you set MAVEN_OPTS either in your .bashrc or maybe .mavenrc file?

Best regards
Mirko
-- 
Sent from my mobile

Am 27.02.2018 22:51 schrieb "Bill Tantzen" :

> Friends:
>
> mac os sierra
> maven 3.5.2
> java 1.8.0_25
>
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
> further details.
>
> I have added the following to my classpath in an attempt to eliminate
> these wanings:
>
> slf4j-api-1.7.25.jar
> slf4j-nop-1.7.25.jar
>
> I no longer see the warnings -- is this all I need to do?  Am I losing
> any output to my console by using the nop binding?
>
> -- Regards,
> Bill
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

[Mirko Friedenhagen]

Hello,

I use the combined aggregator/parent pom as well. While multiple poms may
be cleaner because of separation of concerns, you might easily end in
duplications for e.g. plugin definitions, which is a shame as well.

Regards
Mirko
-- 
Sent from my mobile

Am 05.12.2016 10:56 schrieb "Sander Verhagen" :

> Simple and easy may be in the eye of the beholder. I get a lot of your
> points (except for the cycles breaking your build, I'm not recognizing
> that), but my environment is just dramatically different, and the things
> that you are describing as necessary for your environment, would be
> unneeded complexity for mine. We have a lot more entirely separate
> projects, each of which with their own (smaller) constellation (ancestry)
> of Maven projects. There's a company POM. Each project has a parent POM,
> that inherits the company POM, and yes, it's an aggregator too. That's
> never a problem, because the child projects are all unique and different,
> and aside from a few shared plugin configurations, that we are perfectly
> happy to have in the company POM, and a few enforcer rules that we are
> happy to share across the entire project, all the real meat is in the leaf
> node POM files. I don’t know what JSP compilation you speak of, nor do we
> have any significant WAR configuration to be shared across modules. I
> currently have 716 POM files checked out locally (just a quick "find"),
> just to give you some feeling that my application of Maven isn't just
> trivial. But it is DIFFERENT than yours. And I like my shared
> aggregator/parent POMs. Maybe if it hadn't been designed like this, by
> Maven, for many years now as it is, whatever the world would look like
> would've been fine too, but now I'm fond of this approach, to be honest :)
>
> One more note, I have learned to be sparse on what to put into the
> inheritance hierarchy (composition over inheritance, that good stuff), so
> our parent POMs are also a lot leaner than what I've seen (myself and
> others do) in the past. Something like this may play into your observations
> also.
>
> Thanks for everyone's perspective on this, it's interesting!
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net  ]
>
> NOTICE: my e-mail address has changed. Please remove verha...@sander.com
> now and start using san...@sanderverhagen.net from now on. Please update
> your address book. Thank you!
>
> -Original Message-
> From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com]
> Sent: Sunday, December 4, 2016 17:16
> To: Maven Users List 
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
>
> Indeed, combining the parent and aggregator concerns in one POM is not a
> good idea. I would go so far as to call it an anti-pattern. A very common
> one, unfortunately.
>
> First, you get a cycle per module. Cycles are never a good thing, though
> sometimes they are unavoidable. Maven seems to be fine with this particular
> type of cycle but you still get strange behaviour on occasion. A build may
> break (especially when starting with an empty
> repository) with a strange error message but a second attempt may succeed.
> That's also (probably) why it is usually not recognised as a problem. If
> the second build succeeds you tend to shrug your shoulders and move on.
>
> Let's say you have an enormous Java file of 10,000 lines of code. I don't
> think anyone would consider that good design. Similarly, if you have a
> single project with some 4,000 Java files. Again, I don't think anyone
> would consider that an example of good design. In both cases, we would
> argue that it needs to be broken up because, clearly, separate/independent
> concerns have been conflated. And it is all just too hard to understand,
> too hard to test, and too hard to maintain.
>
> So why would it be a good idea to put all POM related concerns in one
> place? Especially when it comes to modules, they are *only* relevant at
> compile time. There is absolutely no reason to know about this at any other
> time. In fact, my aggregator POMs have a version "modules"
> (that looks nice in the build output) that never changes and they all set
> .
>
> But it goes beyond that. If you have a JAR project and a WAR project then
> it makes sense to have a separate parent-jar-pom and parent-war-pom. The
> parent-jar-pom would only need to know about compiling Java code and
> putting it in a JAR. Very simple. The parent-war-pom, however, would need
> to know about JSP compilation
> (e.g.) and how to run the WAR with Tomcat or Jetty. Perhaps the
> parent-war-pom extends the parent-jar-pom but in any case there is no need
> for this additional complexity to be in the parent-jar-pom.
>
> I think the core difference between these philosophies is choosing between
> "easy" and "simple". It may be easy to put everything in one POM, but it
> will cost you in maintenance effort. It takes more effort and thought to
> 

Re: Create test jar during build without attaching

[Mirko Friedenhagen]

Hello Christopher,

it seems the jar is a test resource, so it is not different from a jpg
which could be included as well in this way IMO.

Regards
Mirko
-- 
Sent from my mobile

Am 19.08.2016 03:47 schrieb "Christopher" :

If this were a personal project, I'd probably do that... but this is for an
ASF project, and I don't want to put us in a position where we are
releasing with binaries in the source artifact.

On Thu, Aug 18, 2016 at 9:39 PM jieryn  wrote:

> Create the jar and then put it under src/test/resources/my.jar and
> then refer to that my.jar in your testcase. It seems like an awful lot
> of trouble to dynamically create this test artifact, when you could
> just create it once and then add it to your repository. Yes, adding
> jars to your scm is generally bad, but this seems like a perfect
> exception.
>
> On Thu, Aug 18, 2016 at 9:36 PM, Christopher  wrote:
> > Hi Maven Users list,
> >
> > What's the best way to create a jar during a build without attaching it?
> >
> > Currently, our pom is configured to use the maven-jar-plugin to create
> it,
> > but that plugin attaches an artifact, which gets deployed. We don't want
> > that. That doesn't seem to be configurable.
> >
> > We could create a mini project and use maven-invoker-plugin to package
> it,
> > but that's a lot of overhead (configuration and processing time) for a
> very
> > small test jar containing a single file (used to test a classloader).
> >
> > We've also considered just using maven-exec-plugin to execute the jar
> > command-line tool, but that's tricky to get right, accounting for
> > JAVA_HOME, toolchains, etc.
> >
> > Any suggestions, or is maven-invoker-plugin the best option?
> >
> > I think the maven-assembly-plugin might be able to do it, and it has an
> > false option, but I've never used it like this before.
> If
> > that's the best option, does anybody have any examples of that kind of
> > thing?
> >
> > Thanks.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Fail fast for 401 Unauthorized failures

[Mirko Friedenhagen]

Hello,

maybe
https://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication
could help.
Regards
Mirko
-- 
Sent from my mobile

Am 25.07.2016 15:11 schrieb "Tomasz Juchniewicz" :

> Hi,
>
> I'm working in corporate environment with strict password locking policies.
> After 5 authentication errors my account is locked.
>
> My problem is that Maven tries to download artifacts and not every error
> (e.g. downloading maven-metadata.xml) causes to stop the build and this
> leads to account lock. Any idea to make Maven fail fast after first
> authentication problem.
>
>
>
> --
> TJu
>

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

[Mirko Friedenhagen]

Hello,

I just published a Docker image at
https://hub.docker.com/r/mfriedenhagen/docker-maven/. However, because
I often use Maven in a CI environment I replaced the gossip and jansi
jars with slf4j-simple.
After adapting findbugs-maven-plugin to 3.0.4 my projects run successfully.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sat, Jul 23, 2016 at 11:41 PM, Dan Tran  wrote:
> Looks good on my 170 modules with Takari's  smart builder build.  Except
> one module with one transitive dependency disappears and causes compilation
> error.
>
> Any suggestion how to troubleshoot is very much reproducible build failure?
>
> Thanks
>
> -Dan
>
>
>
> On Fri, Jul 22, 2016 at 3:14 PM, Mark Derricutt  wrote:
>
>> On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
>> wrote:
>>
>> > This is only a current state of development (Git hash:
>> > 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
>> > community...
>> >
>>
>> Have been using daily HEAD builds as my daily driver for the past few
>> weeks, so far no issues on any of our projects, so here's my pre-emptive +2
>> :)
>>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>>

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

Re: Possible to alter project.distributionManagement.repository.url at build time?

[Mirko Friedenhagen]

Hello Dan,
we use a property in distributionManagement which has is set in
settings.xml (may be overridden on the CLI), something like:
${distribution.snapshot.url}
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Jul 5, 2016 at 3:06 AM, Dan Tran  wrote:
> quick prototype shows I can make changes to maven project, but deploy
> plugin does not see my changes.
>
> so is not possible?
>
> Thanks
>
> -Dan
>
> On Mon, Jul 4, 2016 at 5:14 PM, Dan Tran  wrote:
>
>> Hi I have a need to push a key/value pair into release URL
>>
>> is maven project immutable once constructed?
>>
>> Thanks
>>
>> -Dan
>>

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

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mirko Friedenhagen]

So maybe I got all scopes wrong, however the new version seems
basically quite incompatible with 3.3.9.
On a side note I like to use org.slf4j.simpleLogger.showDateTime=true
during CI runs. With the new logger the build time does not show
anymore, the only thing that happens is that there is no coloring
anymore.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sun, Jun 12, 2016 at 10:55 PM, Anton Tanasenko
 wrote:
> It would be great if there was a way to enable/disable color using a
> separate option or system property.
> Adding -B could disable color by default, but explicitly enabling it might
> prove useful in, say, Jenkins with AnsiColor plugin.
>
> 2016-06-12 23:39 GMT+03:00 Baptiste Mathus :
>
>> Well, as I hadn't tested this version and was just guessing /by intuition/
>> on what I generally use --batch-mode for, I'd disagree on your last
>> statement :).
>> But agreed it might be interesting to have some words about it in the help.
>> Patches/PR are always welcome.
>>
>> 2016-06-12 22:15 GMT+02:00 Oliver B. Fischer :
>>
>> > Yes, running with -B disables the colorized output.
>> >
>> > But at least the description of this option should mention this too
>> > because IMHO it is not intuitive that -B disables the colors.
>> >
>> >
>> > WDYT?
>> >
>> > Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
>> >
>> >> Didn't test it, but using batch mode would seem natural for that IMO.
>> >>
>> >> My 2 cents
>> >>
>> >> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer > >:
>> >>
>> >> The colorized output is very nice, but I would like to have also a
>> >>> commandline option to disable it. I often redirect the output of Maven
>> >>> to a
>> >>> file to check the build. All the escape sequences are disturbing in
>> this
>> >>> case.
>> >>>
>> >>> Running mvn --help I didn't see an option to disable it. Could such an
>> >>> option be added?
>> >>>
>> >>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
>> >>>
>> >>> --
>> >>> N Oliver B. Fischer
>> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> >>> P +49 30 44793251
>> >>> M +49 178 7903538
>> >>> E o.b.fisc...@swe-blog.net
>> >>> S oliver.b.fischer
>> >>> J oliver.b.fisc...@jabber.org
>> >>> X http://xing.to/obf
>> >>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >>> For additional commands, e-mail: users-h...@maven.apache.org
>> >>>
>> >>>
>> >>>
>> > --
>> > N Oliver B. Fischer
>> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > P +49 30 44793251
>> > M +49 178 7903538
>> > E o.b.fisc...@swe-blog.net
>> > S oliver.b.fischer
>> > J oliver.b.fisc...@jabber.org
>> > X http://xing.to/obf
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
>
>
> --
> Regards,
> Anton.

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

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mirko Friedenhagen]

Hello Christian,

that I could fix. Although hamcrest is transitive in junit. Concerning
https://github.com/1and1/testlink-junit/:
I now invoked the project as 'mvn340  -P '!foss-parent-verification'
clean verify' and get other stack traces. This might be because the
parent pom of the project manages logback as having scope test, that
means probably that the project class path is leaking into the plugin
class path.
When I try to manage the dependencies as scope runtime, the version
number is not picked up from the parent.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sun, Jun 12, 2016 at 10:27 AM, Christian Schulte <c...@schulte.it> wrote:
> Am 06/12/16 um 00:03 schrieb Mirko Friedenhagen:
>> Hello Karl-Heinz,
>>
>> I tried this with 2 projects, firstly an inhouse project and it choked with:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
>> (default-test) on project ui-mamido-qamove: Execution default-test of
>> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
>> There was an error in the forked process
>>
>> [ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
>> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> You are managing a transitive dependency to 'test' scope which isn't
> transitive. You need to move that transitive dependency up one level to
> make it a direct dependency.
>
>
>
> -
> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mirko Friedenhagen]

Forgot to mention: Both projects run fine with 3.3.9.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sun, Jun 12, 2016 at 12:03 AM, Mirko Friedenhagen
<mfriedenha...@gmail.com> wrote:
> Hello Karl-Heinz,
>
> I tried this with 2 projects, firstly an inhouse project and it choked with:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19:test
> (default-test) on project ui-mamido-qamove: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
> There was an error in the forked process
>
> [ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> [ERROR] at 
> org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:76)
>
> [ERROR] at 
> org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
>
> [ERROR] at 
> org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
>
> [ERROR] at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
>
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
>
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
>
> [ERROR] at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
>
> [ERROR] Caused by: java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
>
> [ERROR] at java.lang.ClassLoader.defineClass1(Native Method)
>
> [ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>
> [ERROR] at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>
> [ERROR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>
> [ERROR] at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>
> [ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>
> [ERROR] at java.security.AccessController.doPrivileged(Native Method)
>
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> [ERROR] at org.junit.runner.Computer.getSuite(Computer.java:28)
>
> [ERROR] at org.junit.runner.Request.classes(Request.java:75)
>
> [ERROR] at org.junit.runner.Request.classes(Request.java:91)
>
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> [ERROR] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> [ERROR] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
>
> [ERROR] at 
> org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
>
> [ERROR] ... 6 more
>
> [ERROR] Caused by: java.lang.ClassNotFoundException: 
> org.hamcrest.SelfDescribing
>
> [ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> [ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> [ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> [ERROR] ... 26 more
>
> [ERROR] -> [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/PluginExecutionException
>
>
> then I tried this with https://github.com/1and1/testlink-junit and it
> choked like this:
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs (findbugs) on
> project tljunit-parent: Unable to parse configuration of mojo
> org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
> pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
> with value '${plugin.artifacts}' of type
> java.util.Collections.UnmodifiableRandomAccessList to property of type
> java.util.ArrayList -&g

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Mirko Friedenhagen]

Hello Karl-Heinz,

I tried this with 2 projects, firstly an inhouse project and it choked with:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19:test
(default-test) on project ui-mamido-qamove: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test failed:
There was an error in the forked process

[ERROR] org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing

[ERROR] at 
org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:76)

[ERROR] at 
org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)

[ERROR] at 
org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)

[ERROR] at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)

[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)

[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)

[ERROR] at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)

[ERROR] Caused by: java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing

[ERROR] at java.lang.ClassLoader.defineClass1(Native Method)

[ERROR] at java.lang.ClassLoader.defineClass(ClassLoader.java:763)

[ERROR] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

[ERROR] at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)

[ERROR] at java.net.URLClassLoader.access$100(URLClassLoader.java:73)

[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:368)

[ERROR] at java.net.URLClassLoader$1.run(URLClassLoader.java:362)

[ERROR] at java.security.AccessController.doPrivileged(Native Method)

[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:361)

[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

[ERROR] at org.junit.runner.Computer.getSuite(Computer.java:28)

[ERROR] at org.junit.runner.Request.classes(Request.java:75)

[ERROR] at org.junit.runner.Request.classes(Request.java:91)

[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

[ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)

[ERROR] at 
org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)

[ERROR] ... 6 more

[ERROR] Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing

[ERROR] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)

[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

[ERROR] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

[ERROR] ... 26 more

[ERROR] -> [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/PluginExecutionException


then I tried this with https://github.com/1and1/testlink-junit and it
choked like this:

[ERROR] Failed to execute goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs (findbugs) on
project tljunit-parent: Unable to parse configuration of mojo
org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for parameter
pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts'
with value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs
(findbugs) on project tljunit-parent: Unable to parse configuration of
mojo org.codehaus.mojo:findbugs-maven-plugin:3.0.3:findbugs for
parameter pluginArtifacts: Cannot assign configuration entry
'pluginArtifacts' with value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList

at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:214)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:155)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:147)

at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions
(MojoExecutor.java:354)

at 

Re: mvn deploy without rebuilding?

[Mirko Friedenhagen]

Hello,

what about enhancing the install plugin with a list of the latest installs
and creating a mojo deploy:deploy-latest-install?

Regards
Mirko
-- 
Sent from my mobile
Am 03.05.2016 18:15 schrieb "Stephen Connolly" <
stephen.alan.conno...@gmail.com>:

> I think that if your SCM supports the options and your MRM supports staging
> then you can get the workflow you want by basically making every build a
> release build e.g.
>
> mvn -DreleaseVersion=1.0.0.${BUILD_NUMBER} \
>   -DdevelopmentVersion=1.0.0.0-SNAPSHOT \
>   -DsuppressCommitBeforeTag=true \
>   -DpushChanges=false \
>   -DlocalCheckout=true \
>   -DpreparationGoals=initialize \
>   release:prepare \
>   release:perform && git push --tags
>
> That should basically just create the tag and build from the tag and then
> only push the tag upstream if the release is successful.
>
> The developers pom stays on 1.0-SNAPSHOT (but as we do not push commits
> back to master it doesn't matter) and the release versions get their
> version number from Jenkins.
>
> On 2 May 2016 at 19:08, thully  wrote:
>
> > Hi,
> >
> > Our project has many Maven artifacts, the vast majority of which are OSGi
> > bundles. These bundles are distributed together as part of our
> application
> > (Cytoscape), but may also be used by third-party developers using our
> API.
> >
> > Given this, we have been deploying our artifacts to a Maven repository
> each
> > time we make a new release of our application. However, we've run into an
> > issue with this - every time we run mvn deploy, the bundles are rebuilt
> > with
> > new time-stamps and checksums. This makes it impossible to ensure that
> > what's in the Maven repository matches a tested release version of the
> code
> > unless we deploy when we build (suboptimal when we have code we're not
> sure
> > is release-ready, but has non-SNAPSHOT version numbers in preparation for
> > release).
> >
> > I've seen that mvn deploy:deploy supposedly should do what we want
> (deploy
> > without rebuilding). However, this fails on every one of our bundles with
> > an
> > error like the following:
> >
> > "The packaging for this project did not assign a file to the build
> > artifact."
> >
> > mvn deploy:deploy-file works, but has to be done a file at a time with
> each
> > POM and artifact specified on the command line. That would be a pain with
> > 100+ artifacts/POMs in different locations. Does anybody know of a better
> > way to do this?
> >
> >
> >
> > --
> > View this message in context:
> >
> http://maven.40175.n5.nabble.com/mvn-deploy-without-rebuilding-tp5866812.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: iText 4.2.0 - Could a software licence be changed from MPL/LGPL to AGPL by simply redistributing the pom.xml?

[Mirko Friedenhagen]

Hello Siegfried,

I do not think this was an accident, see
https://issues.sonatype.org/plugins/servlet/mobile#issue/MVNCENTRAL-760.

The relocation does break builds as the package is different as well. I am
not a lawyer but at I think it is not a nice move to cause breaking builds
and licensing issues two years after something is published.
Regards
Mirko
-- 
Sent from my mobile
Am 19.01.2016 23:58 schrieb "Siegfried Goeschl" :

> Hi folks,
>
> I have a simple simple question - is it possible/legal to change the
> software licence by simply re-distributing a POM a couple of years later?
>
> During a code review I came across a project using itext-4.2.0-jar.
>
> AFAIK iText 2.1.7 was the last version under MPL/LGPL and later they moved
> to AGPL V3 - I suggested to remove the library but the developer insisted
> that the library was indeed under MPL :-O
>
> * He showed me itext-4.2.0.jar/META-INF/maven/com.lowagie/itext/pom.xml
> clearly displaying a MPL/LGPL licence
> * I pointed him to
> http://search.maven.org/#artifactdetails%7Ccom.lowagie%7Citext%7C4.2.0%7Cpom
> clearly displaying a AGPL V3 licence
>
> But the
> http://search.maven.org/remotecontent?filepath=com/lowagie/itext/4.2.0/itext-4.2.0.pom
> actually contains a "relocation" section
>
> 
> 
> GNU Affero General Public License v3
> http://www.fsf.org/licensing/licenses/agpl-3.0.html
> 
> 
> 
> 
> com.itextpdf
> itextpdf
> 5.5.6
> After release 2.1.7, iText moved from the MPLicense to
> the AGPLicense.
> The groupId changed from com.lowagie to com.itextpdf and the
> artifactId from itext to itextpdf.
> See http://itextpdf.com/functionalitycomparison for more
> information.
> 
> 
>
> Mhmm, that puzzled me because itext-4.2.0.jar still has "com.lowagie"
> package name so I started digging through Maven Central
>
>
> 1) What Maven Central Says
> ===
>
> http://repo1.maven.org/maven2/com/lowagie/itext/4.2.0/
>
> itext-4.2.0-bundle.jar.asc 20-Sep-2012 16:34
>490
> itext-4.2.0-bundle.jar.asc.md5 20-Sep-2012 16:34
> 32
> itext-4.2.0-bundle.jar.asc.sha120-Sep-2012 16:34
> 40
> itext-4.2.0-javadoc.jar20-Sep-2012 16:34
>4498819
> itext-4.2.0-javadoc.jar.asc20-Sep-2012 16:34
>490
> itext-4.2.0-javadoc.jar.asc.md520-Sep-2012 16:34
> 32
> itext-4.2.0-javadoc.jar.asc.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0-javadoc.jar.md520-Sep-2012 16:34
> 32
> itext-4.2.0-javadoc.jar.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0-sources.jar20-Sep-2012 16:34
>4061295
> itext-4.2.0-sources.jar.asc20-Sep-2012 16:34
>490
> itext-4.2.0-sources.jar.asc.md520-Sep-2012 16:34
> 32
> itext-4.2.0-sources.jar.asc.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0-sources.jar.md520-Sep-2012 16:34
> 32
> itext-4.2.0-sources.jar.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0.jar20-Sep-2012 16:34
>2243043
> itext-4.2.0.jar.asc20-Sep-2012 16:34
>490
> itext-4.2.0.jar.asc.md520-Sep-2012 16:34
> 32
> itext-4.2.0.jar.asc.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0.jar.md520-Sep-2012 16:34
> 32
> itext-4.2.0.jar.sha1   20-Sep-2012 16:34
> 40
> itext-4.2.0.pom10-Jul-2015 08:16
>   2156
> itext-4.2.0.pom.asc10-Jul-2015 08:16
>821
> itext-4.2.0.pom.asc.md509-Jul-2015 12:33
> 32
> itext-4.2.0.pom.asc.sha1   09-Jul-2015 12:33
> 40
> itext-4.2.0.pom.md510-Jul-2015 08:16
> 32
> itext-4.2.0.pom.sha1   10-Jul-2015 08:16
> 40
>
> Interesting - the pom.xml was re-distributed a couple of months ago while
> the iText library is still from 2012. I guess the redistribution was caused
> by the additional "relocation" section of the pom.xml
>
> > wget
> http://repo1.maven.org/maven2/com/lowagie/itext/4.2.0/itext-4.2.0.jar
> > wget
> http://repo1.maven.org/maven2/com/lowagie/itext/4.2.0/itext-4.2.0.jar.asc
> > gpg --verify itext-4.2.0.jar.asc
>
> itext> gpg --verify itext-4.2.0.jar.asc
> gpg: assuming signed data in `itext-4.2.0.jar'
> gpg: Signature made Thu Sep 20 17:24:41 2012 CEST using 

Re: [VOTE] Retire Maven Application Skin, Maven Classic Skin, Maven Stylus Skin

[Mirko Friedenhagen]

+1

Regards
Mirko
-- 
Sent from my mobile
Am 24.12.2015 23:34 schrieb "Michael Osipov" <1983-01...@gmx.net>:

> Hi,
>
> as previously suggested, it makes sense to retire those skins because
> they haven't been updated for a long time and we don't have the resources
> to maintain them properly [1].
>
> Last releases:
> Maven Application Skin: 2012-01-18
> Maven Classic Skin: 2012-01-18
> Maven Stylus Skin: 2012-07-30
>
> I therefore propose that we retire these skins.
>
> If this vote is successful I will make one final release of the skin,
> making
> it clear on the skin site that it has been retired. After that the source
> code
> will be moved into the "retired" area in our Subversion repository.
>
> The process for retiring a skin is described here:
> http://maven.apache.org/developers/retirement-plan-plugins.html
> (Though these aren't plugins, the process is universal)
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> I would ask kindly those who have already cast their vote to revote to
> make it
> "official".
>
> [1]
> http://mail-archives.apache.org/mod_mbox/maven-dev/201512.mbox/%3Ctrinity-8ab6577c-ab69-4f9f-86e6-533e0b309a94-1450902628141%403capp-gmx-bs54%3E
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How Maven solves the problem of long builds on large projects?

[Mirko Friedenhagen]

Hello Sergey,

you may try to use
https://github.com/timgifford/maven-buildtime-extension to identify
which plugins contribute most to your long build times.

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Dec 21, 2015 at 1:53 PM, Sergey Saraev  wrote:
> Hello!
>
> I am developing a project with 67 modules.
> I use Apache Maven 3.0.4.
>
> Reassembly of the project take 1 hour and 50 minutes although usually commit 
> change only one module.
>
> The project is very large. It contains 5948 java classes (Basically, time 
> spent on their compilation.).
> Build command: mvn clean install pmd:pmd checkstyle:checkstyle 
> cobertura:cobertura
>
> Plugins versions:
> maven-compiler-plugin:2.3.2
> maven-antrun-plugin:1.6 (use wlappc task: 
> http://docs.oracle.com/cd/E21764_01/web./e13706/splitbuild.htm#WLPRG224)
> maven-surefire-plugin:2.10
> maven-jar-plugin:2.3.2
> maven-install-plugin:2.3.1
> maven-pmd-plugin:2.7.1
> maven-checkstyle-plugin:2.6
> cobertura-maven-plugin:2.7
>
> How to speed up the assembly?
> (Maybe skip modules, which sources have not changed or something else)
>
> Regards,
>
> Sergey Saraev | Research & Development | Office: +7 (846) 270-7800 ext. 2662 
> | Mobile: +7 (917) 813-5604 | --www.NetCracker.com--
> Proven Partner to Communications Service Providers
>
>
>
>
> 
> The information transmitted herein is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.

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

[Mirko Friedenhagen]

Hello Martin,

as a hack you may override this in your pluginManagement by specifying
an invalid phase.

org.apache.maven.plugins
maven-source-plugin
${maven-source-plugin.version}
true



attach-sources
DISABLE_FORKED_LIFECYCLE_MSOURCES-13


default-jar-no-fork

jar-no-fork




Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Dec 2, 2015 at 9:57 PM, Martin Gainty  wrote:
> Folks-
> is there any way to disable a particular plugin (which is somehow declared as 
> a default plugin for that phase )from executing in that phase?
>
> Thanks!
> Martin
> __
>
>

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

Re: Running tests using failsafe from a shaded jar?

[Mirko Friedenhagen]

sisu-maven-plugin helped a lot:
https://github.com/mfriedenhagen/mavenembeddedtest
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Nov 24, 2015 at 4:53 PM, Mirko Friedenhagen
<mfriedenha...@gmail.com> wrote:
> Hello Tamás, hello Jason,
>
> thanks for your tips, I will try to understand and digest your input :-).
>
> Regards
> Mirko
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Tue, Nov 24, 2015 at 10:17 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
>> Mirko,
>>
>> or just run the index goal of sisu-maven-plugin in pre-package phase, like
>> it is done here (to create the META-INF/sisu/javax.inject.Named index for
>> WAR that contains many things).
>>
>> https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-webapp/pom.xml#L336
>>
>> See
>> https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.mojos/index-mojo.html
>>
>> On Mon, Nov 23, 2015 at 2:23 PM Jason van Zyl <ja...@takari.io> wrote:
>>
>>> Mirko,
>>>
>>> You’ll notice if you look at the source that it’s a JSR330 component. So
>>> there is a the sisu-maven-plugin which generates a
>>> META-INF/sisu/javax.inject.Named as part of the build. You will want to
>>> look in your shaded JAR and make sure you have one of those files, I’m not
>>> certain if there is a resource transformer that deals with this file so you
>>> might have to make one of those. I say might because it depends on how you
>>> start up the container for Maven. If you don’t particularly care about
>>> startup speed you can make the container scan the classpath and it will
>>> create all the bindings from the classes in the scan. By default in Maven
>>> we get the container to use the index file cited above because it’s much
>>> faster at creating all the bindings. Your error results from there being no
>>> binding for the DefaultClassRealmManager so it’s likely not finding the
>>> javax.inject.Named file.
>>>
>>> If you look at some of the test cases[1] in maven-core you’ll see where
>>> the container is created and see how the scanning behaviour is changed. To
>>> try something quickly you can just turn the classpath scanning on and see
>>> if it’s fast enough. You might also have to lift a few bits from the
>>> PlexusTestCase class itself but it’s very similar to how the container if
>>> created in the MavenCli class which also serves as an example.
>>>
>>> [1]:
>>> https://github.com/apache/maven/blob/master/maven-core/src/test/java/org/apache/maven/AbstractCoreMavenComponentTestCase.java
>>>
>>> > On Nov 22, 2015, at 2:03 AM, Mirko Friedenhagen <mfriedenha...@gmail.com>
>>> wrote:
>>> >
>>> > Hello Stephen, I will share how to do this in general. As it it not as
>>> easy
>>> > as I hoped I will firstly extract a POC project and share that on GitHub
>>> > immediately with the risk of never succeeding :-)
>>> >
>>> > Regards
>>> > Mirko
>>> > --
>>> > Sent from my mobile
>>> > Am 21.11.2015 23:34 schrieb "Stephen Connolly" <
>>> > stephen.alan.conno...@gmail.com>:
>>> >
>>> >> If you get this working, any chance you could share your work?
>>> >>
>>> >> On 21 November 2015 at 21:20, Mirko Friedenhagen <
>>> mfriedenha...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Hello,
>>> >>>
>>> >>> I want to use to run tests on machine, where Maven is not installed
>>> >>> and access to a repository is not allowed.
>>> >>> However I want to (ab-)use the failsafe plugin so I may use the fine
>>> >>> machinery which allows to specify tests and get XML reports.
>>> >>>
>>> >>> Using maven-embedded I created an App class which just runs
>>> >>> failsafe:integration tests, all dependencies are found in a shaded
>>> >>> jar.
>>> >>> I already used
>>> >>>
>>> org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
>>> >>> so a complete looking META-INF/plexus/components.xml is created.
>>> >>>
>&g

Re: Running tests using failsafe from a shaded jar?

[Mirko Friedenhagen]

Hello Tamás, hello Jason,

thanks for your tips, I will try to understand and digest your input :-).

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Nov 24, 2015 at 10:17 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> Mirko,
>
> or just run the index goal of sisu-maven-plugin in pre-package phase, like
> it is done here (to create the META-INF/sisu/javax.inject.Named index for
> WAR that contains many things).
>
> https://github.com/sonatype/nexus-oss/blob/nexus-2.11.x/components/nexus-webapp/pom.xml#L336
>
> See
> https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.mojos/index-mojo.html
>
> On Mon, Nov 23, 2015 at 2:23 PM Jason van Zyl <ja...@takari.io> wrote:
>
>> Mirko,
>>
>> You’ll notice if you look at the source that it’s a JSR330 component. So
>> there is a the sisu-maven-plugin which generates a
>> META-INF/sisu/javax.inject.Named as part of the build. You will want to
>> look in your shaded JAR and make sure you have one of those files, I’m not
>> certain if there is a resource transformer that deals with this file so you
>> might have to make one of those. I say might because it depends on how you
>> start up the container for Maven. If you don’t particularly care about
>> startup speed you can make the container scan the classpath and it will
>> create all the bindings from the classes in the scan. By default in Maven
>> we get the container to use the index file cited above because it’s much
>> faster at creating all the bindings. Your error results from there being no
>> binding for the DefaultClassRealmManager so it’s likely not finding the
>> javax.inject.Named file.
>>
>> If you look at some of the test cases[1] in maven-core you’ll see where
>> the container is created and see how the scanning behaviour is changed. To
>> try something quickly you can just turn the classpath scanning on and see
>> if it’s fast enough. You might also have to lift a few bits from the
>> PlexusTestCase class itself but it’s very similar to how the container if
>> created in the MavenCli class which also serves as an example.
>>
>> [1]:
>> https://github.com/apache/maven/blob/master/maven-core/src/test/java/org/apache/maven/AbstractCoreMavenComponentTestCase.java
>>
>> > On Nov 22, 2015, at 2:03 AM, Mirko Friedenhagen <mfriedenha...@gmail.com>
>> wrote:
>> >
>> > Hello Stephen, I will share how to do this in general. As it it not as
>> easy
>> > as I hoped I will firstly extract a POC project and share that on GitHub
>> > immediately with the risk of never succeeding :-)
>> >
>> > Regards
>> > Mirko
>> > --
>> > Sent from my mobile
>> > Am 21.11.2015 23:34 schrieb "Stephen Connolly" <
>> > stephen.alan.conno...@gmail.com>:
>> >
>> >> If you get this working, any chance you could share your work?
>> >>
>> >> On 21 November 2015 at 21:20, Mirko Friedenhagen <
>> mfriedenha...@gmail.com>
>> >> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I want to use to run tests on machine, where Maven is not installed
>> >>> and access to a repository is not allowed.
>> >>> However I want to (ab-)use the failsafe plugin so I may use the fine
>> >>> machinery which allows to specify tests and get XML reports.
>> >>>
>> >>> Using maven-embedded I created an App class which just runs
>> >>> failsafe:integration tests, all dependencies are found in a shaded
>> >>> jar.
>> >>> I already used
>> >>>
>> org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
>> >>> so a complete looking META-INF/plexus/components.xml is created.
>> >>>
>> >>> When I start the jar with java -jar MY_SHADED_JAR.jar I always get the
>> >>> following error:
>> >>>
>> >>> 22:09:57.365 [main] WARN  Sisu - Error injecting:
>> >>> org.apache.maven.project.DefaultProjectBuildingHelper
>> >>>
>> >>> com.google.inject.ProvisionException: Unable to provision, see the
>> >>> following errors:
>> >>>
>> >>>
>> >>> 1) No implementation for org.apache.maven.classrealm.ClassRealmManager
>> >>> was bound.
>> >>>
>> >>>  while locating org.apache.maven.project.DefaultPr

Re: Running tests using failsafe from a shaded jar?

[Mirko Friedenhagen]

Hello Stephen, I will share how to do this in general. As it it not as easy
as I hoped I will firstly extract a POC project and share that on GitHub
immediately with the risk of never succeeding :-)

Regards
Mirko
-- 
Sent from my mobile
Am 21.11.2015 23:34 schrieb "Stephen Connolly" <
stephen.alan.conno...@gmail.com>:

> If you get this working, any chance you could share your work?
>
> On 21 November 2015 at 21:20, Mirko Friedenhagen <mfriedenha...@gmail.com>
> wrote:
>
> > Hello,
> >
> > I want to use to run tests on machine, where Maven is not installed
> > and access to a repository is not allowed.
> > However I want to (ab-)use the failsafe plugin so I may use the fine
> > machinery which allows to specify tests and get XML reports.
> >
> > Using maven-embedded I created an App class which just runs
> > failsafe:integration tests, all dependencies are found in a shaded
> > jar.
> > I already used
> > org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
> > so a complete looking META-INF/plexus/components.xml is created.
> >
> > When I start the jar with java -jar MY_SHADED_JAR.jar I always get the
> > following error:
> >
> > 22:09:57.365 [main] WARN  Sisu - Error injecting:
> > org.apache.maven.project.DefaultProjectBuildingHelper
> >
> > com.google.inject.ProvisionException: Unable to provision, see the
> > following errors:
> >
> >
> > 1) No implementation for org.apache.maven.classrealm.ClassRealmManager
> > was bound.
> >
> >   while locating org.apache.maven.project.DefaultProjectBuildingHelper
> >
> >
> > Looking into components.xml DefaultClassRealmManager is not there but
> > is referenced twice.
> >
> > Grepping through the components.xml files in a Maven installation, I
> > do not see where the DefaultClassRealmManager is instantiated.
> >
> > Regards Mirko
> > --
> > http://illegalstateexception.blogspot.com/
> > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> > https://bitbucket.org/mfriedenhagen/
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Running tests using failsafe from a shaded jar?

[Mirko Friedenhagen]

Hello Karl-Heinz,

I found the class but in none of the components.xml  files from plexus is a
hint that DCRM is the default for CRM :-)
Regards
Mirko
-- 
Sent from my mobile
Am 21.11.2015 22:33 schrieb "Karl Heinz Marbaise" <khmarba...@gmx.de>:

> Hi Mirko,
>
> The class DefaultClassRealmManager is contained in maven-core module..
>
> @Named
> @Singleton
> public class DefaultClassRealmManager
> implements ClassRealmManager
> {
> public static final String API_REALMID = "maven.api";
>
> /**
>  * During normal command line build, ClassWorld is loaded by jvm
> system classloader, which only includes
>  * plexus-classworlds jar and possibly javaagent classes, see
> https://issues.apache.org/jira/browse/MNG-4747.
>  * 
>  * Using ClassWorld to determine plugin/extensions realm parent
> classloaders gives m2e and integration test harness
>  * flexibility to load multiple version of maven into dedicated
> classloaders without assuming state of jvm system
>  * classloader.
>  */
> private static final ClassLoade
>
>
> ...
>
> http://maven.apache.org/ref/3.0.5/maven-core/apidocs/org/apache/maven/classrealm/DefaultClassRealmManager.html
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 11/21/15 10:20 PM, Mirko Friedenhagen wrote:
>
>> Hello,
>>
>> I want to use to run tests on machine, where Maven is not installed
>> and access to a repository is not allowed.
>> However I want to (ab-)use the failsafe plugin so I may use the fine
>> machinery which allows to specify tests and get XML reports.
>>
>> Using maven-embedded I created an App class which just runs
>> failsafe:integration tests, all dependencies are found in a shaded
>> jar.
>> I already used
>> org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
>> so a complete looking META-INF/plexus/components.xml is created.
>>
>> When I start the jar with java -jar MY_SHADED_JAR.jar I always get the
>> following error:
>>
>> 22:09:57.365 [main] WARN  Sisu - Error injecting:
>> org.apache.maven.project.DefaultProjectBuildingHelper
>>
>> com.google.inject.ProvisionException: Unable to provision, see the
>> following errors:
>>
>>
>> 1) No implementation for org.apache.maven.classrealm.ClassRealmManager
>> was bound.
>>
>>while locating org.apache.maven.project.DefaultProjectBuildingHelper
>>
>>
>> Looking into components.xml DefaultClassRealmManager is not there but
>> is referenced twice.
>>
>> Grepping through the components.xml files in a Maven installation, I
>> do not see where the DefaultClassRealmManager is instantiated.
>>
>> Regards Mirko
>> --
>> http://illegalstateexception.blogspot.com/
>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
>> https://bitbucket.org/mfriedenhagen/
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Running tests using failsafe from a shaded jar?

[Mirko Friedenhagen]

Hello,

I want to use to run tests on machine, where Maven is not installed
and access to a repository is not allowed.
However I want to (ab-)use the failsafe plugin so I may use the fine
machinery which allows to specify tests and get XML reports.

Using maven-embedded I created an App class which just runs
failsafe:integration tests, all dependencies are found in a shaded
jar.
I already used 
org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer
so a complete looking META-INF/plexus/components.xml is created.

When I start the jar with java -jar MY_SHADED_JAR.jar I always get the
following error:

22:09:57.365 [main] WARN  Sisu - Error injecting:
org.apache.maven.project.DefaultProjectBuildingHelper

com.google.inject.ProvisionException: Unable to provision, see the
following errors:


1) No implementation for org.apache.maven.classrealm.ClassRealmManager
was bound.

  while locating org.apache.maven.project.DefaultProjectBuildingHelper


Looking into components.xml DefaultClassRealmManager is not there but
is referenced twice.

Grepping through the components.xml files in a Maven installation, I
do not see where the DefaultClassRealmManager is instantiated.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

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

[ANNOUNCE] Release extra-enforcer-rules version 1.0-beta-4

[Mirko Friedenhagen]

The Extra Enforcer Rules team is pleased to announce the
extra-enforcer-rules-1.0-beta-4 release!

Extra Enforcer Rules. These are extra rules for Apache Maven's Enforcer Plugin.

Changes in this version include:

New features:
o New rule requireProjectUrl
o Adapt to mojohaus organisation.

Fixed Bugs:
o EnforceBytecodeVersion crashes on maven-enforcer-plugin 1.4.1 with a
NullPointerException

Fixed Issues: 
https://github.com/mojohaus/extra-enforcer-rules/issues?q=milestone%3A1.0-beta-4

Site: http://www.mojohaus.org/extra-enforcer-rules/

SCM Diff: 
https://github.com/mojohaus/extra-enforcer-rules/compare/extra-enforcer-rules-1.0-beta-3...extra-enforcer-rules-1.0-beta-4


Have fun!
-Extra Enforcer Rules team

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

Re: WG: next beta release for mojohaus/extra-enforcer-rules

[Mirko Friedenhagen]

Hello Stephen,

I just forwarded your mail to the mojo-dev list. I could cut a release, but
it will take at least three days to a vote to pass.

Regards
Mirko
-- 
Sent from my mobile
Am 02.11.2015 07:47 schrieb "Krull, Stephan" :

> Hello user list,
>
> I am interested in a release of the mentioned extra-enforcer-rules module
> (see http://www.mojohaus.org/extra-enforcer-rules/ and github:
> https://github.com/mojohaus/extra-enforcer-rules.
>
> There have been some commits since the last release 1.0-beta-3 on
> September 2014. (see
> https://github.com/mojohaus/extra-enforcer-rules/commits/master)
>
> Since there seems to be nobody to get this project out of the "beta" phase
> it would at least be helpful to get a new beta release 1.0-beta-4.
>
> Who is able to do it?
>
> Kind Regards
>
>
> Kind regards
>
>
> Stephan Krull
> Application Developer
> MTS.nom TSO
>
> Phone: +49 341 443-1583
> Fax: +49 341 443-1855
> Email: stephan.kr...@ecg-leipzig.de
> Web: www.ecg-leipzig.de
> 
> ECG Erdgas-Consult GmbH
> 15 Years. Software. Integration. Service.
>
> Föpplstr. 3  -  04347 Leipzig  -  Germany
> Court of Register: Local Court of Leipzig, HRB 16467
> Chief Executive Officer: Dr. Peter Heine, Oliver F. Hill
> 
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

[ANNOUNCE] Release buildnumber-maven-plugin version 1.4

[Mirko Friedenhagen]

Hi,

the Build Number Maven Plugin team is pleased to announce the
buildnumber-maven-plugin-1.4 release!

This plugin is designed to give you a build number. So when you might
make 100 builds of version
 1.0-SNAPSHOT, you can differentiate between them all.

Changes in this version:
* Add basic Git Integration Test
* README.md: make sure IT tests are executed
* Add README.md
* Add configuration for travis-ci.org
* Update to new mojo-parent
* Change issue tracking link
* Correct link to License
* Change scm entry after migration to github

Diff: 
https://github.com/mojohaus/buildnumber-maven-plugin/compare/buildnumber-maven-plugin-1.3...buildnumber-maven-plugin-1.4

Have fun!
-Build Number Maven Plugin team

--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

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

Re: Specified destination directory cannot be created

[Mirko Friedenhagen]

Hello Michael,

just guessing:

- sometimes spaces in the path may lead to problems.
- sometimes Windows encounters a problem when a path is too long.

Could you try setting setting localRepository  as outlined in
http://maven.apache.org/settings.html to c:/tmp/m2.

Regards
Mirko
-- 
Sent from my mobile
Am 14.08.2015 21:07 schrieb michael.ctr.taru...@faa.gov:

 Can anyone tell me why I'm getting the following error?

 Failed to execute goal
 org.apache.karaf.tooling:features-maven-plugin:2.4.0.redhat-620133:add-features-to-repo
 (add-features-to-repo) on project jboss-a-mq:
 Can't resolve bundle
 org.apache.karaf.management.mbeans:org.apache.karaf.management.mbeans.scr:jar:2.4.0.redhat-620133:
 Could not transfer artifact
 org.apache.karaf.management.mbeans:org.apache.karaf.management.mbeans.scr:jar:2.4.0.redhat-620133
 from/to jboss.fs.public (
 http://repository.jboss.org/nexus/content/repositories/fs-public/):
 Specified destination directory cannot be created: C:\Users\Michael CTR
 Tarullo.FAA\.m2\repo\org\apache\karaf\management\mbeans\org.apache.karaf.management.mbeans.scr\2.4.0.redhat-620133

 Mike

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

[Mirko Friedenhagen]

Hello Dan,

I started as a normal Python developer, then built and led a team of test
automation engineers while the management decided to switch to Java 10
years back and inherited CruiseControl, which we dropped for Hudson. I had
some small scale operating experience as well (email server/router). One of
my nowadays colleagues has been test automation engineer as well, the other
one was always into building completely.

I think because release processes are often very company/product specific
(at least when you got a huge legacy baggage), building engineers are
easiest trained or formed internally. However, without input from the
outside, you might miss fresh ideas.

Regards
Mirko
-- 
Sent from my mobile
Am 01.06.2015 02:59 schrieb Dan Tran dant...@gmail.com:

 
 
  I'm sure I've said it before, but part of Maven's problem is that this is
  all magically taken care of behind the scenes and less people need to
 know
  how it works to make it work.
  The downside is that there are then less people who can fix things when
  they need fixing.
 

 Exactly, it is hard to learn magical thing

 I used to train a QA turned dev with java j2ee server testing backround,
 and
 it took a couple of years

 is it norm here by slowly training internally from start ( ie java)?

 Thanks

 -Dan

 BTW, i full understand that this type of discussion my be touchy, so I also
 very appreciated to any one who is able to share with private email

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

[Mirko Friedenhagen]

Hello Dan,

we treat tooling like software as well. Ticket creation is an automated 2
click process and the package qa will not take more than 5 minutes for
small changes.

External libraries from central may be used at free will, but we recommend
stuff in a so called toolbox, these dependencies are managed in the
department pom.

The (programming) architects and we help discovering alternatives in our
toolbox, stuff from repositories outside central is mostly put in a
third-party repo in Artifactory.

Regards
Mirko
-- 
Sent from my mobile
Am 31.05.2015 00:06 schrieb Dan Tran dant...@gmail.com:

 Hi Mirko

 Looks like you have Artifactory to store all of release artifacts and
 another 'release' repo to store the final approved release

 Is internal tooling, thirdparty upload  going thru the same release
 process?

 Thanks

 -Dan

 On Sat, May 30, 2015 at 2:41 PM, Mirko Friedenhagen 
 mfriedenha...@gmail.com
  wrote:

  Hello Dan,
 
  - Every developer may deploy SNAPSHOTs, however this is normally done
  by Jenkins.
  - We do not enforce staging from Jenkins, however almost all projects
  do this. We do not enforce this, so Jenkins outages do not inhibit
  releasing hot fixes.
  - Releases are deployed to a staging repository in Artifactory and we
  have a process called package-qa where for every staged release a
  corresponding JIRA ticket has to be created with information (changes,
  Wiki page, diff link since last release, ticket queue). This is a
  central place where you may see all releases in one place.
  - This ticket is parsed by a script from Jenkins which procures
  artifacts from staging to a releases repository and adds general
  quality information from SonarQube and Jenkins as well as the SHA1
  sums to the ticket so we have a second record which may be used to
  detect forgery. Additionally the script checks for the existence of
  the SCM tag and retrieves the number of changed lines between
  releases.
  - No blocker or critical and no new major issues are allowed in
  SonarQube, otherwise procurement will fail.
  - The reporter and the mover have to be different persons to enforce
  a four eyes principle.
  - The mover (sometimes someone from development QA, most of the
  times nowadays another developer) has to check some things and must
  inspect the diff to detect whether all changes are explained.
  - Our operations teams will only pick production releases from the
  final releases repository, other stages may pick up artifacts from the
  staging repository.
  - We do not sign artifacts.
 
  Regards
  Mirko
  Regards Mirko
  --
  http://illegalstateexception.blogspot.com/
  https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
  https://bitbucket.org/mfriedenhagen/
 
 
  On Sat, May 30, 2015 at 7:31 PM, Dan Tran dant...@gmail.com wrote:
   Thanks Mirko
  
 * What about snapshot and release policy, do developers/qa have
 access
  to
   deploy snapshot and release artifacts?
 * do you use artifact signing similar to Maven Central?
  
  
   Thanks again
  
   -Dan
  
   On Sat, May 30, 2015 at 9:21 AM, Mirko Friedenhagen 
  mfriedenha...@gmail.com
   wrote:
  
   What I forgot:
  
   patience, social skills  and remembering that not every application
   developer needs to be a build specialist are important as well :-)
  
   Regards
   Mirko
   --
   Sent from my mobile
   Am 30.05.2015 07:29 schrieb Dan Tran dant...@gmail.com:
  
Hi
   
   
 I would like to ask if the community can share with me what it
 takes
  to
maintain an enterprise build system with continuous integration of
  100+
developer + QA and growing using Maven.  The build system contains
  many
components with their own release cycle and they do integrate
  together.
   
   
   - is java skill set to develop plugin a must?
   - do you have a team or just a few of deep understanding of Maven
developers?
   - will a none java RelEng able to perform Maven release?
   - does your RelEng maintains the pom or developers?
   - what are your challenges?
   
Thanks
   
-Dan
   
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

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

[Mirko Friedenhagen]

What I forgot:

patience, social skills  and remembering that not every application
developer needs to be a build specialist are important as well :-)

Regards
Mirko
-- 
Sent from my mobile
Am 30.05.2015 07:29 schrieb Dan Tran dant...@gmail.com:

 Hi


  I would like to ask if the community can share with me what it takes to
 maintain an enterprise build system with continuous integration of 100+
 developer + QA and growing using Maven.  The build system contains many
 components with their own release cycle and they do integrate together.


- is java skill set to develop plugin a must?
- do you have a team or just a few of deep understanding of Maven
 developers?
- will a none java RelEng able to perform Maven release?
- does your RelEng maintains the pom or developers?
- what are your challenges?

 Thanks

 -Dan

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

[Mirko Friedenhagen]

Hello Dan,

- Every developer may deploy SNAPSHOTs, however this is normally done
by Jenkins.
- We do not enforce staging from Jenkins, however almost all projects
do this. We do not enforce this, so Jenkins outages do not inhibit
releasing hot fixes.
- Releases are deployed to a staging repository in Artifactory and we
have a process called package-qa where for every staged release a
corresponding JIRA ticket has to be created with information (changes,
Wiki page, diff link since last release, ticket queue). This is a
central place where you may see all releases in one place.
- This ticket is parsed by a script from Jenkins which procures
artifacts from staging to a releases repository and adds general
quality information from SonarQube and Jenkins as well as the SHA1
sums to the ticket so we have a second record which may be used to
detect forgery. Additionally the script checks for the existence of
the SCM tag and retrieves the number of changed lines between
releases.
- No blocker or critical and no new major issues are allowed in
SonarQube, otherwise procurement will fail.
- The reporter and the mover have to be different persons to enforce
a four eyes principle.
- The mover (sometimes someone from development QA, most of the
times nowadays another developer) has to check some things and must
inspect the diff to detect whether all changes are explained.
- Our operations teams will only pick production releases from the
final releases repository, other stages may pick up artifacts from the
staging repository.
- We do not sign artifacts.

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sat, May 30, 2015 at 7:31 PM, Dan Tran dant...@gmail.com wrote:
 Thanks Mirko

   * What about snapshot and release policy, do developers/qa have access to
 deploy snapshot and release artifacts?
   * do you use artifact signing similar to Maven Central?


 Thanks again

 -Dan

 On Sat, May 30, 2015 at 9:21 AM, Mirko Friedenhagen mfriedenha...@gmail.com
 wrote:

 What I forgot:

 patience, social skills  and remembering that not every application
 developer needs to be a build specialist are important as well :-)

 Regards
 Mirko
 --
 Sent from my mobile
 Am 30.05.2015 07:29 schrieb Dan Tran dant...@gmail.com:

  Hi
 
 
   I would like to ask if the community can share with me what it takes to
  maintain an enterprise build system with continuous integration of 100+
  developer + QA and growing using Maven.  The build system contains many
  components with their own release cycle and they do integrate together.
 
 
 - is java skill set to develop plugin a must?
 - do you have a team or just a few of deep understanding of Maven
  developers?
 - will a none java RelEng able to perform Maven release?
 - does your RelEng maintains the pom or developers?
 - what are your challenges?
 
  Thanks
 
  -Dan
 


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

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

[Mirko Friedenhagen]

Hello Dan,

currently I have a team of two (with me three) devops guys.
We provide 30 Jenkins masters with 20 build nodes and about 1800 jobs which
we provision ourselves as well (Debian is already installed and we are able
to login via ssh).
We provide the department pom, some Maven plugins, Artifactory, Gitlab,
several SonarQube instances, several Testlink instances and some other
minor systems as well.

The department has about 200 developers, 150 of them use Java/Maven, the
others objective-c, c++, Scala, Python, PHP, JavaScript and Ruby.

Most teams do have one developer who is more interested in build tooling
and we support them with diagnosis of Jenkins or Maven related problems
(nowadays we try to answer questions for SBT and npm as well..).

We all have a sound knowledge of Java, Python and Shell.

Now: while you may write Maven plugins in Jython, Ant or any other JVM
language, most of the documentation is directed to writing these in Java.

Releasing with Maven is trivial once the project is setup properly, so no
Java knowhow is needed here, IMO.

The poms are maintained by the teams/developers, we help when they
encounter problems (which might to restructuring the project as well).

The challenges are mostly with the non-Maven projects, IMO having a soundly
setup department pom *and* settings will help, Maven is a very good build
tool for company setups.

Because of the many systems (we have to arrange for firewall settings from
build nodes to qa systems as well) we get about 4 support requests per day,
so one of us is ticketeer of the day.

Regards
Mirko
-- 
Sent from my mobile
Am 30.05.2015 07:29 schrieb Dan Tran dant...@gmail.com:

 Hi


  I would like to ask if the community can share with me what it takes to
 maintain an enterprise build system with continuous integration of 100+
 developer + QA and growing using Maven.  The build system contains many
 components with their own release cycle and they do integrate together.


- is java skill set to develop plugin a must?
- do you have a team or just a few of deep understanding of Maven
 developers?
- will a none java RelEng able to perform Maven release?
- does your RelEng maintains the pom or developers?
- what are your challenges?

 Thanks

 -Dan

Hooking into maven-release-plugin:prepare

[Mirko Friedenhagen]

Hello everybody,

we have a company pom with a maybe unusual versioning schema:
- the development version is always 1-SNAPSHOT
- the release version is always 1.${NEXT_MAJOR}

By means of this inactive projects may always stay on
company-pom-1-SNAPSHOT and unusual behaviour is nonetheless provoking
a build error.

Now I want the release procedure for this pom to be:
mvn -B release:prepare release:perform

However I need to determine 1.${NEXT_MAJOR}. I could either ask our
repository manager for the last version CURRENT_MAJOR and just
increase it by one.

Or I could ask the SCM (git) for the latest tag, parse this tag and
increase the version accordingly.

I found a page about binding Mojos to custom lifecycles[0] and tried
something like

plugin
artifactIdmaven-release-plugin/artifactId
extensionstrue/extensions
/plugin

and tried to bind a mojo to a phase release:check-poms. However this
does not seem to work (tried variations like phase
org.apache.maven.plugins:maven-release-plugin:check-poms as well).

As a last resort, I was thinking about implementing a custom VersionPolicy.

Any other ideas?

Regards Mirko
[0] 
http://docs.codehaus.org/display/MAVENUSER/Binding+Mojos+to+custom+LifeCycles+or+inclusion+of+the+Release+Plugin+LifeCycle+into+Maven+Core
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

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

maven-release-plugin: syntax of connectionUrl with git?

[Mirko Friedenhagen]

Hello,

yesterday I already had pushed a git tag by running mvn
release:prepare and while I executed release:perform I remembered I
had the wrong settings.xml activated.

I accidentally deleted release.properties by running release:clean.
Now I just wanted to run something like:

mvn release-plugin:perform
-DconnectionUrl=scm:svn:https://svn.mycompany.com/repos/path/to/myproject/tags/myproject-1.2.3

as outlined at 
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html.

But I did not find the correct syntax for GIT. In the end, I created a
release.properties with the content scm.tag=myproject-1.2.3 and could
run
mvn release-plugin:perform
-DconnectionUrl=scm:git:git://github.com/ORG/PROJ.git

Is there a way to specify the scm.tag on the CLI? I tried release.scm.tag.


Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

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

Re: maven-release-plugin: syntax of connectionUrl with git?

[Mirko Friedenhagen]

Hi Dan,

thanks, but this feels like a workaround as I have special profiles
defined, when performRelease is set and had defined other goals (deploy
sonar:sonar ticket:create).

Of course for a one time operation this a valid alternative. However than
we should state in the documentation of connectUrl that this is only
supported for Subversion :-) .

Regards
Mirko
-- 
Sent from my mobile
On May 7, 2015 9:30 AM, Dan Tran dant...@gmail.com wrote:

 try scm:bootstrap

 make sure to passing the required argument and profile

 -D

 On Thu, May 7, 2015 at 12:18 AM, Mirko Friedenhagen 
 mfriedenha...@gmail.com
  wrote:

  Hello,
 
  yesterday I already had pushed a git tag by running mvn
  release:prepare and while I executed release:perform I remembered I
  had the wrong settings.xml activated.
 
  I accidentally deleted release.properties by running release:clean.
  Now I just wanted to run something like:
 
  mvn release-plugin:perform
  -DconnectionUrl=scm:svn:
  https://svn.mycompany.com/repos/path/to/myproject/tags/myproject-1.2.3
 
  as outlined at
 
 http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
  .
 
  But I did not find the correct syntax for GIT. In the end, I created a
  release.properties with the content scm.tag=myproject-1.2.3 and could
  run
  mvn release-plugin:perform
  -DconnectionUrl=scm:git:git://github.com/ORG/PROJ.git
 
  Is there a way to specify the scm.tag on the CLI? I tried
 release.scm.tag.
 
 
  Regards Mirko
  --
  http://illegalstateexception.blogspot.com/
  https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
  https://bitbucket.org/mfriedenhagen/
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: java import package and maven dependencies

[Mirko Friedenhagen]

Hello Lin,

maybe while struggling with this you could ask for help at the
m2-us...@eclipse.org mailing list.

Gruss
Mirko
-- 
Sent from my mobile
On Mar 25, 2015 1:52 AM, Lin Ma lin...@gmail.com wrote:

 Thanks Gruss,

 Following your guidance I found the maven dependencies, and where is the
 .classpath file you are referring to? I do not find it in workspace of the
 project. I created a new maven project in Eclipse.

 [image: Inline image 2]

 regards,
 Lin

 On Tue, Mar 24, 2015 at 4:38 PM, Bernd Eckenfels e...@zusammenkunft.net
 wrote:

 Am Tue, 24 Mar 2015 16:23:23 -0700
 schrieb Lin Ma lin...@gmail.com:

  How to find Maven updated Classpath and its priority over existing
  Classpath in Eclipse? I use both and Eclipse is less. :)

 Not sure I understand the question, but in Eclipse you can see in the
 (Right click - Project settings - Java Build Path - Libraries in what
 sequence manual/eclipse/maven libs are searched. (Same is true for
 source and generated-source folders). 'You also see this in
 the .classpath file (it must contain:)

 classpathentry kind=con
 path=org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER
 ... attribute name=maven.pomderived
 value=true/

 And when you open Maven Dependencies in the Package Explorer you see
 the dependencies on your build path (inserted by maven). With Alt+F5
 they get refreshed. (It will use eclipse internal maven+settings to
 populate this list).

 Note that there is no 100% match between compile dependencies, pluigins
 and stuff between Eclipse and M2e (but for normal projects its not an
 issue).

 Gruss
 Bernd

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

Re: Takari Lifecycle, takari-war and altDeploymentRepository

[Mirko Friedenhagen]

Thanks, Jason.

Regards
Mirko
-- 
Sent from my mobile
On Jan 17, 2015 8:53 PM, Jason van Zyl ja...@takari.io wrote:

 Hi Mirko,

 I've raised a couple issues [1] and [2]. The first is likely not hard to
 implement so I'll take a look at that. We've had a couple requests for WAR
 support so if some more people ask we'll consider adding support there.

 [1]: https://github.com/takari/takari-lifecycle/issues/7
 [2]: https://github.com/takari/takari-lifecycle/issues/8

 On Jan 17, 2015, at 2:40 PM, Mirko Friedenhagen mfriedenha...@gmail.com
 wrote:

  Hello,
 
  is there a plan to support altDeploymentRepository? We.use release:stage
  and I am guessing that this will not work without this parameter.
 
  And how would I use the plugin for WARs? Right now I had to skip all
  standard plugins, right?
 
  Regards
  Mirko
  --
  Sent from my mobile

 Thanks,

 Jason

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

 To do two things at once is to do neither.

  -- Publilius Syrus, Roman slave, first century B.C.













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

Takari Lifecycle, takari-war and altDeploymentRepository

[Mirko Friedenhagen]

Hello,

is there a plan to support altDeploymentRepository? We.use release:stage
and I am guessing that this will not work without this parameter.

And how would I use the plugin for WARs? Right now I had to skip all
standard plugins, right?

Regards
Mirko
-- 
Sent from my mobile

Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl

[Mirko Friedenhagen]

B

Regards
Mirko
-- 
Sent from my mobile
On Dec 15, 2014 11:40 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 After the run-off round, we are left with two names standing.

 This second vote will be a straight and simple majority wins.

 The vote will be open for at least 72 hours (with the potential of an
 extension until I send a message saying that the polls are closed)

 There will be no discussion in this thread, we have talked it all enough
 already. If you want to discuss something, please use a different thread.

 Vote:

 [A]: Shotgun
 [B]: The Maven Owl

 Thank you very much for your time

 -Stephen

Re: Little documentation issues

[Mirko Friedenhagen]

Barrie,

if I am not wrong you probably have it right ;-)

Regards
Mirko
-- 
Sent from my mobile
On Dec 17, 2014 3:46 AM, Barrie Treloar baerr...@gmail.com wrote:

 On 17 December 2014 at 12:24, Ron Wheeler rwhee...@artifact-software.com
 wrote:
 
  One of the wonderful features about Maven is that no matter how long one
  has been using it or how much one has studied Maven documentation , one
  still feels the necessity of ending every assertion about how it works
 with
  (If I have that right.) .
 
  I am so happy to not be alone!


 You are not the only one (If I have that right)

Re: release plugin issue

[Mirko Friedenhagen]

Stephen,

thanks for these hints, I sometimes used -DperformRelease=true validate as
prepGoal and as git does not force you to push tags and is able to clone
from the local repository as well, your way is much safer. However with svn
removing/readding/recommitting etc. is painful and always leads to problems.

Regards
Mirko
-- 
Sent from my mobile
On Nov 30, 2014 12:40 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Saturday, November 29, 2014, Mirko Friedenhagen 
 mfriedenha...@gmail.com
 wrote:

  Alejandro,
 
  I have a completely different approach as we use a staging maven
 repository
  anyway:
  - make sure your workspace has no extra files by using your SCM clean
  function.
  - only run mvn release:prepare with the following preparationGoals
 property
  -DperformRelease=true -DinstallAtEnd=true -DdeployAtEnd=true clean deploy
  - this ensures that only the tested  and successfully deployed version of
  your software gets the tag.
  - I expect tagging to be the least dangerous part of the process compared
  to tests, integration tests or the whole maven run with all it's plugins.
  - additionally this speeds up the whole process.


 But you are not building the checked out tag. If there are ignores that
 ignore files that get incorporated in the build you could have a
 non-reproducible build.

 (For example, I have a build (zendesk-java-client) where there is a
 .gitignore in src/test/resources to allow testing with a .properties file
 containing the credentials of a test zendesk. That gets released to
 Central. If I had a source assembly as part of it (I cannot recall, I think
 I do though) then releasing your way would publish the credentials to
 Central in that source bundle... Better would be to have preparationGoals
 trivial (ie `initialize`) and then don't push the tag until the very end...
 (Though in my case I keep both as I want the additional tests to run with
 the credentials and the standard tests to run without so that anyone else
 can still build from the tag). The point being that most people just don't
 see all the good stuff the release plugin does for you by default and
 instead they try to hack around it... Your trick may work for you, but we
 can't let people think it should work for everyone and every case)


  Regards
  Mirko
  --
  Sent from my mobile
  On Nov 28, 2014 7:49 PM, alejandro.e...@grassvalley.com javascript:;
  wrote:
 
   That's good to know Robert, thank you
  
   I will add that to our release dryrun and hopefully it will catch more
 of
   the uncaught problems early on
  
   Alejandro Endo | Software Designer/Concepteur de logiciels
  
  
  
  
  
   From:   Robert Scholte rfscho...@apache.org javascript:;
   To: Maven Users List users@maven.apache.org javascript:;,
   Date:   2014-11-28 12:46 PM
   Subject:Re: release plugin issue
  
  
  
   Op Fri, 28 Nov 2014 00:54:29 +0100 schreef
   alejandro.e...@grassvalley.com javascript:;:
  
I'm using the release-plugin v2.5.1 and I'm often encountering two
recurring stories with failed releases
   
1) Now the release can fail due to errors in the javadoc. This is
 not a
problem, the problem is that IF there are problems in the javadoc the
release doesn't complete but the two commits and the tag has been
 done
   so
after fixing the javadoc I need to reset the git repo to right before
   the
failed released AND I have to remove the tag to try again. I am
   releasing
from jenkins so the resume flag is set to false. if something fails
 we
start from the beginning, which makes sense in a build server IMO. My
suggestion here would be to generate all those artifacts (javadoc and
source) before committing and tagging the code, that way if they
 fail,
the
repo is not in an invalid state. Another option would be improvement
 #2
   
2) Very often the dryRun succeeds but the real release fails, to the
point
where the dryRun is meaningless. This defeats the whole purpose of a
dry-run. The problem is that the dry run is over simplified. For
   example,
again, if there are javadoc problems they won't be spotted because
 the
dry-run doesn't run javadoc generation. Anything that's part of the
  real
build should be run on the dry-run except for things that make
   persistent
changes. Another problem I encounter often is that the real release
   fails
because the tag already exists in SCM (leftover from a previous
 failed
release). This should also be validated by the dryRun. If a real
  release
can fail because a tag is already present then the dry run should
 fail
   if
the tag is already present
   
What do you guys think? If these points are considered valid I will
  open
  
a
ticket at least for the second one, which is the worse of the two
   
  
   It's also possible to do a dryrun for the release:perform since version
   2.3 [1]
   That's still not the default of the jenkins m2

Re: release plugin issue

[Mirko Friedenhagen]

Alejandro,

I have a completely different approach as we use a staging maven repository
anyway:
- make sure your workspace has no extra files by using your SCM clean
function.
- only run mvn release:prepare with the following preparationGoals property
-DperformRelease=true -DinstallAtEnd=true -DdeployAtEnd=true clean deploy
- this ensures that only the tested  and successfully deployed version of
your software gets the tag.
- I expect tagging to be the least dangerous part of the process compared
to tests, integration tests or the whole maven run with all it's plugins.
- additionally this speeds up the whole process.

Regards
Mirko
-- 
Sent from my mobile
On Nov 28, 2014 7:49 PM, alejandro.e...@grassvalley.com wrote:

 That's good to know Robert, thank you

 I will add that to our release dryrun and hopefully it will catch more of
 the uncaught problems early on

 Alejandro Endo | Software Designer/Concepteur de logiciels





 From:   Robert Scholte rfscho...@apache.org
 To: Maven Users List users@maven.apache.org,
 Date:   2014-11-28 12:46 PM
 Subject:Re: release plugin issue



 Op Fri, 28 Nov 2014 00:54:29 +0100 schreef
 alejandro.e...@grassvalley.com:

  I'm using the release-plugin v2.5.1 and I'm often encountering two
  recurring stories with failed releases
 
  1) Now the release can fail due to errors in the javadoc. This is not a
  problem, the problem is that IF there are problems in the javadoc the
  release doesn't complete but the two commits and the tag has been done
 so
  after fixing the javadoc I need to reset the git repo to right before
 the
  failed released AND I have to remove the tag to try again. I am
 releasing
  from jenkins so the resume flag is set to false. if something fails we
  start from the beginning, which makes sense in a build server IMO. My
  suggestion here would be to generate all those artifacts (javadoc and
  source) before committing and tagging the code, that way if they fail,
  the
  repo is not in an invalid state. Another option would be improvement #2
 
  2) Very often the dryRun succeeds but the real release fails, to the
  point
  where the dryRun is meaningless. This defeats the whole purpose of a
  dry-run. The problem is that the dry run is over simplified. For
 example,
  again, if there are javadoc problems they won't be spotted because the
  dry-run doesn't run javadoc generation. Anything that's part of the real
  build should be run on the dry-run except for things that make
 persistent
  changes. Another problem I encounter often is that the real release
 fails
  because the tag already exists in SCM (leftover from a previous failed
  release). This should also be validated by the dryRun. If a real release
  can fail because a tag is already present then the dry run should fail
 if
  the tag is already present
 
  What do you guys think? If these points are considered valid I will open

  a
  ticket at least for the second one, which is the worse of the two
 

 It's also possible to do a dryrun for the release:perform since version
 2.3 [1]
 That's still not the default of the jenkins m2-release-plugin, but it
 works.

 Robert

 [1] https://jira.codehaus.org/browse/MRELEASE-736

 
  Alejandro Endo | Software Designer/Concepteur de logiciels
 
 
  DISCLAIMER:
  Privileged and/or Confidential information may be contained in this
  message. If you are not the addressee of this message, you may not
  copy, use or deliver this message to anyone. In such event, you
  should destroy the message and kindly notify the sender by reply
  e-mail. It is understood that opinions or conclusions that do not
  relate to the official business of the company are neither given
  nor endorsed by the company.
  Thank You.

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



 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.

Re: deploying war artifact to nexus is failing; packaging as jar works.

[Mirko Friedenhagen]

Just a wild guess: as a war the artifact will probably be much bigger
because of the packaged dependencies. Running mvn -e deploy will show more
information.
Am 22.11.2014 11:48 schrieb John Smith jszjsm...@googlemail.com:

 Hello,

 I'm trying to distribute my war's artifact to nexus but I'm getting the
 following error below. If I change the packaging in the pom.xml to jar it
 will deploy fine.

 Can anyone see what I am doing wrong?

 thanks,
 John.

 [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ my-webapp
 ---
 [INFO] Downloading:

 http://nexus.lan:38080/nexus/content/repositories/snapshots/me/john/my-webapp/0.0.1-SNAPSHOT/maven-metadata.xml
 [INFO] Downloaded:

 http://nexus.lan:38080/nexus/content/repositories/snapshots/me/john/my-webapp/0.0.1-SNAPSHOT/maven-metadata.xml
 (776 B at 1.9 KB/sec)
 [INFO] Uploading:

 http://nexus.lan:38080/nexus/content/repositories/snapshots/me/john/my-webapp/0.0.1-SNAPSHOT/my-webapp-0.0.1-20141122.103704-6.war
 [INFO] Uploading:

 http://nexus.lan:38080/nexus/content/repositories/snapshots/me/john/my-webapp/0.0.1-SNAPSHOT/my-webapp-0.0.1-20141122.103704-6.pom
 [INFO] Uploaded:

 http://nexus.lan:38080/nexus/content/repositories/snapshots/me/john/my-webapp/0.0.1-SNAPSHOT/my-webapp-0.0.1-20141122.103704-6.pom
 (5 KB at 197.5 KB/sec)
 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 3.133 s
 [INFO] Finished at: 2014-11-22T10:37:04+00:00
 [INFO] Final Memory: 14M/244M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
 on project my-webapp: Failed to deploy artifacts: Could not transfer
 artifact me.john:my-webapp:war:0.0.1-20141122.103704-6 from/to My_Snapshots
 (http://nexus.lan:38080/nexus/content/repositories/snapshots/): unexpected
 end of stream - [Help 1]

[ANN] Apache Maven PMD Plugin 3.3 Released

[Mirko Friedenhagen]

The Maven team is pleased to announce the release of the Apache Maven
PMD Plugin, version 3.3

A Maven plugin for the PMD toolkit, that produces a report on both
code rule violations and detected copy and paste fragments, as well as
being able to fail the build based on these metrics.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-pmd-plugin/artifactId
  version3.3/version
/plugin


Release Notes - Apache Maven PMD Plugin - Version 3.3

Bug
* [MPMD-192] Regression MPMD-89 is showing up with Maven 2.2.1 again
for maven-pmd-plugin-3.3

Improvement
* [MPMD-191] Update to PMD 5.2.1
* [MPMD-189] MavenProject/MavenSession Injection as a paremeter
instead as a component.


Enjoy,

-The Maven team

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

Re: Fwd: JEP 223: New Version-String Scheme

[Mirko Friedenhagen]

And the scheme as I read it is MAJOR.FEATURE_MINOR.SECURITY.PATCHLEVEL and
FEATURE_MINOR and SECURITY are sort of independent, so a bigger minor might
be less secure.

Regards
Mirko
-- 
Sent from my mobile
On Nov 4, 2014 11:10 PM, Paul Benedict pbened...@apache.org wrote:

 Finally, JDK versioning will be 3 numbers... sort of. The qualifier is
 non-standard (plus sign and build number). But it still beats 4 numbers.

 Cheers,
 Paul

 -- Forwarded message --
 From: mark.reinh...@oracle.com
 Date: Tue, Nov 4, 2014 at 4:05 PM
 Subject: JEP 223: New Version-String Scheme
 To: iris.cl...@oracle.com
 Cc: platform-jep-disc...@openjdk.java.net


 New JEP Candidate: http://openjdk.java.net/jeps/223

 - Mark

Re: Don't want to repeat plugin version for both build and reporting

[Mirko Friedenhagen]

Using properties for plugin versions has the additional benefit, that
versions-maven-plugin is able to update plugins as well via
versions:update-properties.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Oct 3, 2014 at 8:01 PM, Laird Nelson ljnel...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 5:02 PM, Paul Benedict pbened...@apache.org wrote:

 I use the maven-javadoc-plugin in both build and reporting. I don't
 want to fall back to properties to share the plugin version. Is there a
 better way than using properties?


 No.

 Best,
 Laird

 --
 http://about.me/lairdnelson

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

Re: Maven site:deploy hosting providers??

[Mirko Friedenhagen]

I havr used scm-publish together with gh-pages branch as well and as
Karl-Heinz already stated, it works like a charm for me as well.

Regards
Mirko
-- 
Sent from my mobile
On Sep 27, 2014 8:05 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi,

  we have scm-publish plugin for that

 http://maven.apache.org/plugins/maven-scm-publish-plugin/


 I've already used that for GitHub pages...works like a charm...

 https://github.com/khmarbaise/smpp
 https://github.com/khmarbaise/uptodate-maven-plugin etc.

 which makes it very ease...

 apart from that you can use github-site-plugin which works as well...

 https://github.com/github/maven-plugins


 Kind regards
 Karl-Heinz Marbaise


 Regards,

 Hervé

 Le samedi 27 septembre 2014 10:09:35 Kevin Burton a écrit :

 I don't think github would work but would love to be wrong.

 Their static page hosting  is acceptable but it's tricky to make sure all
 pages get added and removed properly.

 Their binary hosting uses their own proprietary api which isn't supported
 by wagon.

 On Sep 27, 2014 4:49 AM, Jason van Zyl ja...@takari.io wrote:

 I believe there are tools that will allow you to publish your static
 site
 to Github pages.

 On Sep 27, 2014, at 2:21 AM, Kevin Burton bur...@spinn3r.com wrote:

 This is such an obviously problem I’m amazed there isn’t an easier
 solution.  Bintray looks cool. I just asked them how they feel about


 static

  site hosting?

 I want something that works with mvn site:deploy

 On Fri, Sep 26, 2014 at 10:49 PM, Manfred Moser manf...@mosabuam.com

 wrote:

 If you just want to have the sites hosted any hosting solution will do


 it.

  CDN will be more expensive but I would really wonder if you need that


 for a

  static site. You would have to get a LOT of traffic to make it worth
 it.

 Bintray focuses on binary distribution and not site hosting.

 If you want both you could even just run Nexus OSS on any server and


 host

  the binaries and the site using a Maven repository for the binaries and


 a

  site repository for the site..

 manfred

 Bernd wrote on 26.09.2014 17:41:

 Have a look at bintray

 https://bintray.com/docs/uploads/uploads_uploads.html

 Greetings
 Bernd

 Am 26.09.2014 21:39 schrieb Kevin Burton bur...@spinn3r.com:

 I don’t want to necessarily host our own repositories.

 They’re just static file repositories.

 Are there any hosting providers out there that support dav, SCP or


 HTTP

  PUT

  that would work with wagon?

 Required features are:

 - SSL

 - redundant copies on multiple servers (CDN)

 - dav/scp/ftp/ upload.. anything supported by wagon.

 - HTTP auth

 - domain masking

 … I just want something easy to setup and then never worry about it


 again.

  --

 Founder/CEO Spinn3r.com
 Location: *San Francisco, CA*
 blog: http://burtonator.wordpress.com
 … or check out my Google+ profile
 https://plus.google.com/102718274791889610666/posts
 http://spinn3r.com


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


 --

 Founder/CEO Spinn3r.com
 Location: *San Francisco, CA*
 blog: http://burtonator.wordpress.com
 … or check out my Google+ profile
 https://plus.google.com/102718274791889610666/posts
 http://spinn3r.com


 Thanks,

 Jason

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

 the course of true love never did run smooth ...

   -- Shakespeare


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

[ANN] Apache Maven Changes Plugin 2.11 Released

[Mirko Friedenhagen]

The Maven team is pleased to announce the release of the Apache Maven
Changes Plugin, version 2.11

Creates a release history for inclusion into the site and assists in
generating an announcement mail.

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

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-changes-plugin/artifactId
  version2.11/version
/plugin


Release Notes - Apache Maven Changes Plugin - Version 2.11

Task
* [MCHANGES-343] Update maven-reporting-impl to 2.3
* [MCHANGES-342] Removed dependency
plexus-container-default:1.0-alpha-9-stable-1
* [MCHANGES-341] Externalize JIRA server timeout values to the
configuration section
* [MCHANGES-338] Remove redundant anchors set on headings
* [MCHANGES-337] Improve language style in model and report generator
* [MCHANGES-336] Enum value for type remove is missing
* [MCHANGES-334] RestJiraDownloader doesn't honor proxy settings
* [MCHANGES-307] Check for whitespace on fixVersionIds and statusIds
* [MCHANGES-269] Move anchor location in changes.xml to header


Enjoy,

-The Maven team

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

Re: Why not a forum

[Mirko Friedenhagen]

+1 for mailing lists as well, there are a lot of archiving sites, which
would offer profiles on users and getting emails from a forum which you
would have to answer via a web page again is a pain. The only worthwhile
alternative would be an now sadly underrated technique like news groups.

Regards
Mirko
-- 
Sent from my mobile
On Jul 25, 2014 5:27 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 As a member of the Apache Maven PMC, one of my duties is to foster the
 community AT Apache. That means the mailing lists.

 If you are looking for an official forum (in the original meaning of the
 word) to discuss Maven and its usage, then users@m.a.o is the place to do
 that. We cannot stop people who want to discuss Maven elsewhere, nor do we
 want to stop them. But we do want to encourage everyone who is discussing
 Maven to do so on an Apache hosted mailing list.


 On 25 July 2014 16:03, Ron Wheeler rwhee...@artifact-software.com wrote:

  The Maven group on LinkedIn already has 2090 members and LinkedIn has
  300,000,000 members.
 
  There is also a Meven Developers group with 1,083 members.
 
  I support both but I prefer the more modern approach of LinkedIn as a UI.
  I like having all my groups under a single login.
 
  I also support this mailing list even if it is old and has some funny
  interactions with Thunderbird.
 
  I have not had any problems with their business practices and find it a
  good way to maintain business contacts and participate in discussions.
  A lot of free and open software are represented in groups on LinkedIn.
 
  I think that you would be hard pressed to find an Apache project that is
  not represented.
 
  There are 285 LinkedIn groups that show up in a search for Apache.
  Some are very small and inactive and others are larger and active
 (HADOOP-
  11,310 members; Distributed Computing (6,241), Mahout 3,894, OpenOffice
  1358).
 
  My point is not that everyone should jointhe LinkedIn Maven group but for
  people who don't like mailing lists, there is an alternative that is
  already active.
  There is no need to build another forum.
 
 
  Ron
 
 
 
  On 25/07/2014 10:25 AM, Andrew Todd wrote:
 
  Apache is an independent non-profit dedicated to the dissemination of
 free
  software. The list archives are freely archivable and indexable by
 anyone
  who wants to -- and there are many sites, such as Nabble and MarkMail,
 who
  do. Using email as the primary means of distribution makes it easy for
  third parties to do this.
 
  On the other hand, LinkedIn is a for-profit corporation with a walled
  garden solution. It's free because it forces people to tie themselves
  into LinkedIn's system. It can't be easily archived or indexed without
  LinkedIn's permission. And if they decide to end the service, we're in
  trouble.
 
  There are people like me who will not even create a LinkedIn profile on
  principle. I don't like the company's business practices.
 
  In short, the suggestion is anathema to a free software organization.
 You
  might as well tell us to use Facebook as a discussion medium.
 
 
  On Wed, Jul 23, 2014 at 5:48 PM, Preston, Dale 
  dale.pres...@conocophillips.com wrote:
 
   I do participate in a couple other Linked-In lists.  I'll check that
 one
  out.  As the response to this thread shows, though, replies come pretty
  quickly in the email list.  In any case, the Linked-In list sounds
 worth
  investigating.
 
  Thanks.
 
 
  -Original Message-
  From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
  Sent: Wednesday, July 23, 2014 8:23 AM
  To: users@maven.apache.org
  Subject: [EXTERNAL]Re: Why not a forum
 
  On 23/07/2014 9:03 AM, Mark H. Wood wrote:
 
  On Tue, Jul 22, 2014 at 03:51:54PM +, Preston, Dale wrote:
 
  I was just wondering why this group uses an email list rather than a
 
  forum.  It seems forum software is more searchable and filterable than
  email lists.
 
  If it had been my choice:  because I'd have to go to a forum every day
  (and a hundred others!) while email comes to me.  I have plenty of
  powerful email search and filter tools right here on my workstation.
 
  Every time someone proposes some other medium for this sort of
  communication (forum, Twitter, etc.) my first question is how can I
  get that in email?  I can't think offhand of any forum software I've
  used that isn't uncomfortable, inconvenient and hard to search.
 
   The Maven LinkedIn forum will send you e-mails plus LinkedIn will
  inform
  you of activity in discussions in which you are active in all of the
  groups
  to which you belong.
 
  Ron
 
  --
  Ron Wheeler
  President
  Artifact Software Inc
  email: rwhee...@artifact-software.com
  skype: ronaldmwheeler
  phone: 866-970-2435, ext 102
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
  

Maven plugin which displays the parents of a given project recursively

[Mirko Friedenhagen]

Hello,

does anybody know of a plugin which shows the GAV coordinates of the
parents of a given project recursively? Or is there any feasible
plugin where I could contribute with a goal?

My team of 3 is consulting approx. 200 developers in regards of build
engineering with ca. 1000 Jenkins jobs and we often see they are using
outdated versions of our department POM. Having this information in
the console of a Jenkins job would allow to see this without checking
the POM.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/

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

Re: Maven plugin which displays the parents of a given project recursively

[Mirko Friedenhagen]

Thanks, putting a goal like this in the versions-maven-plugin is a
good idea :-).
Concerning automatic updates:
* We do this in some ways, in the end product teams have the
responsibility for a working release, so I may just advise to do this.
* Unfortunately Maven configurations and usage are to diverse to
enforce this easily.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Jun 20, 2014 at 2:52 PM, jieryn jie...@gmail.com wrote:
 http://mojo.codehaus.org/versions-maven-plugin/

 I have Jenkins jobs which @weekly run a smoke test update all the
 things and see if it works build, for each project. I also have a set
 of jobs which are virtually the same but simply run the display
 versions of the plugin goals.

 If the team gets confident in this process, you can exploit
 scm:checkin to automatically commit these dependency and parent
 updates if the build is successful. It's pretty easy, actually.

 On Fri, Jun 20, 2014 at 8:09 AM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello,

 does anybody know of a plugin which shows the GAV coordinates of the
 parents of a given project recursively? Or is there any feasible
 plugin where I could contribute with a goal?

 My team of 3 is consulting approx. 200 developers in regards of build
 engineering with ca. 1000 Jenkins jobs and we often see they are using
 outdated versions of our department POM. Having this information in
 the console of a Jenkins job would allow to see this without checking
 the POM.

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/

 -
 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 plugin which displays the parents of a given project recursively

[Mirko Friedenhagen]

Ron,

* finding all POMs is not that simple in our case as we have at least
20 SVN repositories with multiple projects and about 100 git
repositories.
* POMs are XML but a lot of projects have at least DEPARTMENT_POM -
TEAM_POM - PROJECT_POM - MODULE_POM relations, so we have to lookup
stuff in Artifactory anyway.
* I think I will implement a goal `display-ancestors` in the
versions-maven-plugin :-).

Regards
Mirko


Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Jun 20, 2014 at 4:22 PM, Ron Wheeler
rwhee...@artifact-software.com wrote:
 Good description of the use case that helps.
 You are not very explicit about how you identify the projects to be checked
 or where (SCM, staging folder) you want to find them.

 Just a thought:
 Couldn't this be accomplished with a batch job that used XSLT or a simple
 Java program with an XML parser to check POMs for outdated references?
 POMs are just XML with a pretty simple structure.
 They always have the same name so finding them in the project is not hard.
 You are always looking down the same XPATH(s?) for the version and you know
 which one is right.

 Is there some magic that Maven includes that is needed here?

 Ron


 On 20/06/2014 8:09 AM, Mirko Friedenhagen wrote:

 Hello,

 does anybody know of a plugin which shows the GAV coordinates of the
 parents of a given project recursively? Or is there any feasible
 plugin where I could contribute with a goal?

 My team of 3 is consulting approx. 200 developers in regards of build
 engineering with ca. 1000 Jenkins jobs and we often see they are using
 outdated versions of our department POM. Having this information in
 the console of a Jenkins job would allow to see this without checking
 the POM.

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/

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




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



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


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

Re: Maven plugin which displays the parents of a given project recursively

[Mirko Friedenhagen]

Ron,

we have developed some tools which try to guess POM resolutions using
Python and getting the same resolution resp. interpolations as Maven
is sometimes hard to do:

* Inheriting POMs do not need to override version and groupId so you
have to interpolate these from the ancestors.
* Same for properties which are inherited as well while other elements
as scm are adding module/artifactIds.

Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Jun 20, 2014 at 6:49 PM, Ron Wheeler
rwhee...@artifact-software.com wrote:
 I understand that you have a few (120) repos but once you have made the
 list, it is easy to maintain.
 Same as the list of active projects. 1000 is a lot of names to list but you
 probably can find one already existing or make one through a partially
 automated process.

 Otherwise it is a clerical task that you can give to a junior tech.

 DEPARTMENT_POM -TEAM_POM - PROJECT_POM - MODULE_POM
 is more interesting but probably not that hard to manage.

 DEPARTMENT_POM -TEAM_POM is a small list.
 You want to eliminate duplicate sub-trees.

 Just a suggestion for a non-maven solution. That is one of the advantages of
 using XML in the POM,
 You are not restricted to using the application for which the files are
 designed.
 There are lots of XML tools - both low level and high level that can be
 applied.

 Ron



 On 20/06/2014 11:55 AM, Mirko Friedenhagen wrote:

 Ron,

 * finding all POMs is not that simple in our case as we have at least
 20 SVN repositories with multiple projects and about 100 git
 repositories.
 * POMs are XML but a lot of projects have at least DEPARTMENT_POM -
 TEAM_POM - PROJECT_POM - MODULE_POM relations, so we have to lookup
 stuff in Artifactory anyway.
 * I think I will implement a goal `display-ancestors` in the
 versions-maven-plugin :-).

 Regards
 Mirko


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Fri, Jun 20, 2014 at 4:22 PM, Ron Wheeler
 rwhee...@artifact-software.com wrote:

 Good description of the use case that helps.
 You are not very explicit about how you identify the projects to be
 checked
 or where (SCM, staging folder) you want to find them.

 Just a thought:
 Couldn't this be accomplished with a batch job that used XSLT or a simple
 Java program with an XML parser to check POMs for outdated references?
 POMs are just XML with a pretty simple structure.
 They always have the same name so finding them in the project is not
 hard.
 You are always looking down the same XPATH(s?) for the version and you
 know
 which one is right.

 Is there some magic that Maven includes that is needed here?

 Ron


 On 20/06/2014 8:09 AM, Mirko Friedenhagen wrote:

 Hello,

 does anybody know of a plugin which shows the GAV coordinates of the
 parents of a given project recursively? Or is there any feasible
 plugin where I could contribute with a goal?

 My team of 3 is consulting approx. 200 developers in regards of build
 engineering with ca. 1000 Jenkins jobs and we often see they are using
 outdated versions of our department POM. Having this information in
 the console of a Jenkins job would allow to see this without checking
 the POM.

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/

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



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



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

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




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


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


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

Re: Maven filter structure in pom.xml

[Mirko Friedenhagen]

Bernd,

shouldn't this be ${project.developers[0].name}?

You try splitting the assignment in two lines as well, one for developer
and one for name.
Am 16.05.2014 11:24 schrieb Prager, Bernd be...@prager.ws:

 All,

 I am using Apache Maven 3.1.1 and I am trying to get the list of
 developers stored in my pom.xml by resource filtering.

 The structure in my pom.xml looks like:
 developers
 developer
 nameBernd/name
 /developer
 /developers

 When I filter by developer= ${project.developers} I get developer=
 [org.apache.maven.model.Developer@78741b96]
 when I try developer= ${project.developers[0].developer} I just get
 developer= ${project.developers[0].developer}

 Eventually I want to get to the name, even better a list of names of the
 developers in the pom.xml.
 Is that possible?

 Thank you,
 -- Bernd


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

Re: Is it possible to exclude .gitignore file from source package?

[Mirko Friedenhagen]

Imesh,

I wonder why you need this, in my usecases the .git directory and
.gitignore are at the same level as pom.xml, the source plugin will
only pick up stuff from src/main/java (and maybe
target/generated-sources/SOURCE_GENERATOR).

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sun, May 4, 2014 at 7:44 PM, Imesh Gunaratne im...@apache.org wrote:
 Hi All,

 I'm trying to exclude the .gitignore file from the source package generated
 with Maven source plugin while executing mvn release:perform, but it did
 not work.

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-source-plugin/artifactId
 executions
 execution
 idattach-sources/id
 phaseverify/phase
 goals
 goaljar-no-fork/goal
 /goals
 configuration
 excludes

 exclude${project.build.directory}/**/*/exclude
 exclude**/.gitignore/exclude
 exclude**/.git/**/*/exclude
 /excludes
 /configuration
 /execution
 /executions
 /plugin

 The pom.xml file could be found here:
 https://github.com/apache/incubator-stratos/blob/4.0.0-incubating/pom.xml

 Really appreciate any thoughts on this.

 Thanks

 --
 Imesh Gunaratne

 Technical Lead, WSO2
 Committer  PPMC Member, Apache Stratos

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

Re: Strange maven central response - do you see the same thing??

[Mirko Friedenhagen]

Dan,

I always use http://repo1.maven.org/maven2/.. e.g.
http://repo1.maven.org/maven2/org/apache/maven/

Two possible explanations:

Browsers by default follow http redirects, with curl you need -L as an
Option.

You have different proxy settings for the CLI and your browser :-)

Regards
Mirko
-- 
Sent from my mobile
On Apr 18, 2014 6:56 AM, Dan Tran dant...@gmail.com wrote:

 Hello Maven friends

 my maven build fails with this

 [INFO]
 [INFO] --- maven-scm-plugin:1.9:checkout (default-cli) @ standalone-pom ---
 Downloading:

 http://repo.maven.apache.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9/maven-scm-provider-cvsexe-1.9.pom
 Apr 17, 2014 9:50:21 PM

 org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultRequestDirector
 tryExecute
 INFO: I/O exception
 (org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException)
 caught when processing request: The target server failed to respond
 Apr 17, 2014 9:50:21 PM

 org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultRequestDirector
 tryExecute
 INFO: Retrying request
 Apr 17, 2014 9:50:31 PM

 org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultRequestDirector
 tryExecute
 INFO: I/O exception
 (org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException)
 caught when processing request: The target server failed to respond
 Apr 17, 2014 9:50:31 PM

 org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultRequestDirector
 tryExecute
 INFO: Retrying request


 I can't even curl

 http://repo.maven.apache.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9/maven-scm-provider-cvsexe-1.9.pom

 C:\Users\dantrancurl

 http://central.maven.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9/maven-scm-provider-cvsexe-1.9.pom
 curl: (52) Empty reply from server

 note central.maven.org and repo.maven.apache.org  are the same host

 But browser can see that file.

 do you see the same thing

 Thanks

 -Dan

 -D

Re: Strange maven central response - do you see the same thing??

[Mirko Friedenhagen]

Same for me, repo.maven.apache.org redirects to central.maven.org with the
given URL.

Regards
Mirko
-- 
Sent from my mobile
On Apr 18, 2014 10:09 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi,

 if i try the given URL:
  http://repo.maven.apache.org/maven2/org/apache/maven/scm/
 maven-scm-provider-cvsexe

 I'm redirected to :

 http://central.maven.org/maven2/org/apache/maven/scm/
 maven-scm-provider-cvsexe/

 ..

 Kind regards
 Karl-Heinz Marbaise

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

Re: Strange maven central response - do you see the same thing??

[Mirko Friedenhagen]

I guess Karl-Heinz and I are accessing from Germany, so maybe there is some
routing problem on your side?

Regards
Mirko
-- 
Sent from my mobile
On Apr 18, 2014 10:27 AM, Dan Tran dant...@gmail.com wrote:

 My browser cannot even browse those links.  perhaps my virus checker is
 culprit?

 It is a strange day!

 -D


 On Fri, Apr 18, 2014 at 1:14 AM, Mirko Friedenhagen 
 mfriedenha...@gmail.com
  wrote:

  Same for me, repo.maven.apache.org redirects to central.maven.org with
 the
  given URL.
 
  Regards
  Mirko
  --
  Sent from my mobile
  On Apr 18, 2014 10:09 AM, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:
 
   Hi,
  
   if i try the given URL:
http://repo.maven.apache.org/maven2/org/apache/maven/scm/
   maven-scm-provider-cvsexe
  
   I'm redirected to :
  
   http://central.maven.org/maven2/org/apache/maven/scm/
   maven-scm-provider-cvsexe/
  
   ..
  
   Kind regards
   Karl-Heinz Marbaise
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 

Re: how to exclude log4j.properties when mvn assembly:single?

[Mirko Friedenhagen]

Hello Li Li,

you might take a look at the maven-shade-plugin as well, which is easier to
use IMO.

Regards
Mirko
-- 
Sent from my mobile
On Apr 4, 2014 3:20 AM, Li Li fancye...@gmail.com wrote:

 I want to make it runnable simply by java -jar xxx.jar
 build jars will copy all other dependencys

 On Thu, Apr 3, 2014 at 8:52 PM, Ron Wheeler
 rwhee...@artifact-software.com wrote:
  Why are you using the assembly-plugin?
  You normally don't need it to build jars.
 
 
 
 
  On 03/04/2014 5:24 AM, Li Li wrote:
 
  I want to jar my program with all the dependencies. I have a
  dependency of hadoop. the log4j.properties is included in my
  application.
  how to exclude it?
  I have tried this but no luck
 
  artifactIdmaven-assembly-plugin/artifactId
  configuration
excludes
exclude**/log4j.properties/exclude
/excludes
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
  --
  Ron Wheeler
  President
  Artifact Software Inc
  email: rwhee...@artifact-software.com
  skype: ronaldmwheeler
  phone: 866-970-2435, ext 102
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 

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

Re: Overriding dependency scope

[Mirko Friedenhagen]

Alexander,

AFAIK you may override the scope in the inheriting poms. If I remember
correctly I did this with junit as I needed it for an selenium test
project, where I had put base tests beneath src/main (to recite Brecht: oh,
don't ask why).

Regards
Mirko
-- 
Sent from my mobile
On Mar 28, 2014 2:59 PM, Alexander Kriegisch alexan...@kriegisch.name
wrote:

 I have a situation as follows:

   - Multi-module project (~30 modules)

   - Certain test dependencies (e.g. groovy-all) needed by nearly all
 sub-modules are declared directly with test scope in the parent POM
 (not just dependencyManagement, but also dependency). I know this is
 considered to be bad practice but it saves a lot of redundant
 dependency duplication.

   - One new sub-module now actually also needs groovy-all, but with a
 compile scope. So my wish (although seemingly unsupported by Maven)
 is to override the default scope for this sub-module so as for the
 dependency to be actually available during runtime.

 How can I do this or work around the need to duplicate my test
 dependencies in 30 modules just so as to be able to define the scope for
 the new module? AFAIK a POM can only inherit from one POM. But can I
 somehow use an included POM in my 30 modules in order to be able to
 centrally manage the test dependencies? Sorry if I am explaining this
 wrong or using incorrect erms, but I am by no means a Maven pro.
 Hopefully I was at least able to make my intent clear. I am looking for
 good advice beyond lecturing about how I should really, really declare
 everything 30 times in order to do it the Maven way. I am looking for
 alternatives, am willing to learn and hoping to get constructive answers.

 Thanks you all in advance
 --
 Alexander Kriegisch

Re: [MNG-5551] Java 8 + Maven status

[Mirko Friedenhagen]

Mark,

the analyze goal depends on the
org.apache.maven.shared:maven-dependency-analyzer:1.4 which depends on
asm 3.3.1. The trunk already moved to 4.2. I will see what happens
when switching to asm 5 :-)
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 27, 2014 at 5:45 AM, Mark Derricutt m...@talios.com wrote:
 What version of the maven-dependency-plugin?  I'm using 2.8 fine under JDK8
 and have been for some time - this is using the `copy-dependencies` goal and
 nothing else tho...



 On 27 Mar 2014, at 6:15, Steven Schlansker wrote:

 Java 8 has now been out for a week and Maven is still not really
 compatible.
 In particular, the maven-shade-plugin and maven-dependency-plugin do not
 work
 due to an old version of ASM that throws ArrayIndexOutOfBoundsException on
 Java 8 class files.

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

Re: [MNG-5551] Java 8 + Maven status

[Mirko Friedenhagen]

Steven, I can not reproduce that maven-dependency-plugin:analyze:2.8
fails with JDK8. I have created a small library with a Lambda (call it
L) and ran dependency:analyze without probems. I installed this
library and made a new component depend on L and ran
dependency:analyze successfully again. As stated in MDEP-439[1], can
you or someone else provide a sample? Otherwise I will close this bug.

[1] http://jira.codehaus.org/browse/MDEP-439
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 27, 2014 at 1:28 PM, Matt Benson gudnabr...@gmail.com wrote:
 Oh, good news on the dependency plugin bit--I almost forgot that you had
 mentioned its underlying library having already upgraded its trunk to
 version 4. I was thinking more about jdependency, which supports the shade
 plugin.

 Matt
 On Mar 27, 2014 7:22 AM, Matt Benson gudnabr...@gmail.com wrote:

 Oh, well... It's no secret that ASM 3, being interface-based, is wholly
 incompatible with ASM 4, which took the approach of using abstract classes
 to significantly reduce the amount of code needed to accomplish a given
 task. ASM 5 claims to be compatible with 4, which is why I, not realizing
 that the plugins in question were based on ASM 3, suggested that simply
 dropping in the new jar should suffice. The good news is that the upgrade
 process is not terribly onerous, if only someone steps to do it.

 Matt
 On Mar 27, 2014 5:25 AM, Mirko Friedenhagen mfriedenha...@gmail.com
 wrote:

 Mark,

 the analyze goal depends on the
 org.apache.maven.shared:maven-dependency-analyzer:1.4 which depends on
 asm 3.3.1. The trunk already moved to 4.2. I will see what happens
 when switching to asm 5 :-)
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 27, 2014 at 5:45 AM, Mark Derricutt m...@talios.com wrote:
  What version of the maven-dependency-plugin?  I'm using 2.8 fine under
 JDK8
  and have been for some time - this is using the `copy-dependencies`
 goal and
  nothing else tho...
 
 
 
  On 27 Mar 2014, at 6:15, Steven Schlansker wrote:
 
  Java 8 has now been out for a week and Maven is still not really
  compatible.
  In particular, the maven-shade-plugin and maven-dependency-plugin do
 not
  work
  due to an old version of ASM that throws
 ArrayIndexOutOfBoundsException on
  Java 8 class files.

 -
 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: [MNG-5551] Java 8 + Maven status

[Mirko Friedenhagen]

Steven,

thanks, I now could reproduce this. Installing a local SNAPSHOT of the
shared library and plugin did resolve this.
So I guess we have to release both pretty soon :-).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 27, 2014 at 8:37 PM, Steven Schlansker
stevenschlans...@gmail.com wrote:
 Here is a reproduction case:

 https://github.com/stevenschlansker/mdep-439-analyze-java8

 On Mar 27, 2014, at 10:26 AM, Mirko Friedenhagen mfriedenha...@gmail.com 
 wrote:

 Steven, I can not reproduce that maven-dependency-plugin:analyze:2.8
 fails with JDK8. I have created a small library with a Lambda (call it
 L) and ran dependency:analyze without probems. I installed this
 library and made a new component depend on L and ran
 dependency:analyze successfully again. As stated in MDEP-439[1], can
 you or someone else provide a sample? Otherwise I will close this bug.

 [1] http://jira.codehaus.org/browse/MDEP-439
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 27, 2014 at 1:28 PM, Matt Benson gudnabr...@gmail.com wrote:
 Oh, good news on the dependency plugin bit--I almost forgot that you had
 mentioned its underlying library having already upgraded its trunk to
 version 4. I was thinking more about jdependency, which supports the shade
 plugin.

 Matt
 On Mar 27, 2014 7:22 AM, Matt Benson gudnabr...@gmail.com wrote:

 Oh, well... It's no secret that ASM 3, being interface-based, is wholly
 incompatible with ASM 4, which took the approach of using abstract classes
 to significantly reduce the amount of code needed to accomplish a given
 task. ASM 5 claims to be compatible with 4, which is why I, not realizing
 that the plugins in question were based on ASM 3, suggested that simply
 dropping in the new jar should suffice. The good news is that the upgrade
 process is not terribly onerous, if only someone steps to do it.

 Matt
 On Mar 27, 2014 5:25 AM, Mirko Friedenhagen mfriedenha...@gmail.com
 wrote:

 Mark,

 the analyze goal depends on the
 org.apache.maven.shared:maven-dependency-analyzer:1.4 which depends on
 asm 3.3.1. The trunk already moved to 4.2. I will see what happens
 when switching to asm 5 :-)
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 27, 2014 at 5:45 AM, Mark Derricutt m...@talios.com wrote:
 What version of the maven-dependency-plugin?  I'm using 2.8 fine under
 JDK8
 and have been for some time - this is using the `copy-dependencies`
 goal and
 nothing else tho...



 On 27 Mar 2014, at 6:15, Steven Schlansker wrote:

 Java 8 has now been out for a week and Maven is still not really
 compatible.
 In particular, the maven-shade-plugin and maven-dependency-plugin do
 not
 work
 due to an old version of ASM that throws
 ArrayIndexOutOfBoundsException on
 Java 8 class files.

 -
 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 push .zip from assembly to repo?

[Mirko Friedenhagen]

Jvsrvcs,

how do you run assembly? As stated on plugin-info[0] you only should
use goal single.
The mojo documentation for single[1] states, that the assembly should
be attached (and therefore deployed) as of version 2.2 of the plugin.

[0] https://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html
[1] 
https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 27, 2014 at 9:50 PM, Jvsrvcs jvsr...@gmail.com wrote:
 I do not see anything in the assembly .xml or the release plugin that would
 push the zip created to a local maven repo.  There must be something
 missing.

 I looked at the release plugin options and it appears to be related to SCM,
 but not a maven repo.  If you have more information, it would be greatly
 appreciated.



 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/how-to-push-zip-from-assembly-to-repo-tp5789728p5789750.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: Forcing Integration Tests Before a Release

[Mirko Friedenhagen]

performRelease is only set during release:perform :-)

Regards
Mirko
-- 
Sent from my mobile
On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote:

 I have tried to get this working, but it does not seem to work. When I do

   mvn release:prepare

 I get

   [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn
 -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml
 clean verify site --no-plugin-updates -Psonatype-oss-release -P
 user,local-repository

 In the output I can see the 'clean' and the 'site' happen, but the
 failsafe integration tests do not run. If I do

   mvn verify -P run-it

 then the integration tests run as normal.

 Cheers, Eric

   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-failsafe-plugin/artifactId
   version2.17/version
   executions
 execution
   iddefault-integration-test/id
   goals
 goalintegration-test/goal
   /goals
 /execution
 execution
   iddefault-verify/id
   goals
 goalverify/goal
   /goals
 /execution
   /executions
 /plugin
 plugin
   artifactIdmaven-release-plugin/artifactId
   version2.5/version
 /plugin
   /plugins
 /pluginManagement
 plugins
   plugin
 artifactIdmaven-release-plugin/artifactId
 configuration
   preparationGoalsclean verify site/preparationGoals
 /configuration
   /plugin
 . . .

   profiles
 profile
   idrun-it/id
   activation
 property
   nameperformRelease/name
   valuetrue/value
 /property
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
 executions
   execution
 goals
   goalintegration-test/goal
   goalverify/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /profile
   /profiles

 On 3/21/2014 1:10 PM, Eric Kolotyluk wrote:

 Cool, that is what I am looking for. Thanks so much.

 Cheers, Eric

 On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote:

 Eric,

 when you use the maven-release-plugin a property performRelease is set
 during release:perform.

 So define in the pluginManagement section a definition for the
 maven-failsafe-plugin in your build section:

 build
 pluginManagement
 plugins
plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  version2.17/version
  executions
  execution
 iddefault-integration-test/id
  goals
 goalintegration-test/goal
  /goals
  /execution
  execution
  iddefault-verify/id
  goals
  goalverify/goal
  /goals
  /execution
  /executions
  /plugin
 /plugins
 /pluginManagement
 /build

 and later on in your pom

  profile
  idrelease-run-failsafe/id
  activation
  property
  nameperformRelease/name
  valuetrue/value
  /property
  /activation
  build
   plugins
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  /plugin
  /plugins
  /build
  profile

 So only during release:perform your integration tests will be executed
 and success is verified.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk
 eric.koloty...@gmail.com wrote:

 I am looking for some way to force my integration tests before a
 release,
 without explicitly using a profile.

 For example,

plugin
 artifactIdmaven-release-plugin/artifactId
  configuration
preparationGoalsclean verify site/preparationGoals
  /configuration
/plugin

 But that doesn't work because unless the failsafe plugin is defined, it
 won't run the tests.

 I thought of doing something like

profiles
  profile
idrun-it/id
activation
  file
 missingtarget/failsafe-reports/missing
  /file
/activation
build

Re: Forcing Integration Tests Before a Release

[Mirko Friedenhagen]

Eric,

you might modify the preparationGoals parameter to include
-DperformRelease=true.

Regards
Mirko
-- 
Sent from my mobile
On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote:

 I have tried to get this working, but it does not seem to work. When I do

   mvn release:prepare

 I get

   [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn
 -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml
 clean verify site --no-plugin-updates -Psonatype-oss-release -P
 user,local-repository

 In the output I can see the 'clean' and the 'site' happen, but the
 failsafe integration tests do not run. If I do

   mvn verify -P run-it

 then the integration tests run as normal.

 Cheers, Eric

   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-failsafe-plugin/artifactId
   version2.17/version
   executions
 execution
   iddefault-integration-test/id
   goals
 goalintegration-test/goal
   /goals
 /execution
 execution
   iddefault-verify/id
   goals
 goalverify/goal
   /goals
 /execution
   /executions
 /plugin
 plugin
   artifactIdmaven-release-plugin/artifactId
   version2.5/version
 /plugin
   /plugins
 /pluginManagement
 plugins
   plugin
 artifactIdmaven-release-plugin/artifactId
 configuration
   preparationGoalsclean verify site/preparationGoals
 /configuration
   /plugin
 . . .

   profiles
 profile
   idrun-it/id
   activation
 property
   nameperformRelease/name
   valuetrue/value
 /property
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
 executions
   execution
 goals
   goalintegration-test/goal
   goalverify/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /profile
   /profiles

 On 3/21/2014 1:10 PM, Eric Kolotyluk wrote:

 Cool, that is what I am looking for. Thanks so much.

 Cheers, Eric

 On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote:

 Eric,

 when you use the maven-release-plugin a property performRelease is set
 during release:perform.

 So define in the pluginManagement section a definition for the
 maven-failsafe-plugin in your build section:

 build
 pluginManagement
 plugins
plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  version2.17/version
  executions
  execution
 iddefault-integration-test/id
  goals
 goalintegration-test/goal
  /goals
  /execution
  execution
  iddefault-verify/id
  goals
  goalverify/goal
  /goals
  /execution
  /executions
  /plugin
 /plugins
 /pluginManagement
 /build

 and later on in your pom

  profile
  idrelease-run-failsafe/id
  activation
  property
  nameperformRelease/name
  valuetrue/value
  /property
  /activation
  build
   plugins
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  /plugin
  /plugins
  /build
  profile

 So only during release:perform your integration tests will be executed
 and success is verified.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk
 eric.koloty...@gmail.com wrote:

 I am looking for some way to force my integration tests before a
 release,
 without explicitly using a profile.

 For example,

plugin
 artifactIdmaven-release-plugin/artifactId
  configuration
preparationGoalsclean verify site/preparationGoals
  /configuration
/plugin

 But that doesn't work because unless the failsafe plugin is defined, it
 won't run the tests.

 I thought of doing something like

profiles
  profile
idrun-it/id
activation
  file
 missingtarget/failsafe-reports/missing
  /file

Re: Forcing Integration Tests Before a Release

[Mirko Friedenhagen]

Eric,

I do only use release:prepare, see
https://github.com/1and1/foss-parent/blob/master/release line 47ff.

Regards
Mirko
-- 
Sent from my mobile
On Mar 25, 2014 10:05 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote:

 I have tried to get this working, but it does not seem to work. When I do

   mvn release:prepare

 I get

   [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn
 -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml
 clean verify site --no-plugin-updates -Psonatype-oss-release -P
 user,local-repository

 In the output I can see the 'clean' and the 'site' happen, but the
 failsafe integration tests do not run. If I do

   mvn verify -P run-it

 then the integration tests run as normal.

 Cheers, Eric

   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-failsafe-plugin/artifactId
   version2.17/version
   executions
 execution
   iddefault-integration-test/id
   goals
 goalintegration-test/goal
   /goals
 /execution
 execution
   iddefault-verify/id
   goals
 goalverify/goal
   /goals
 /execution
   /executions
 /plugin
 plugin
   artifactIdmaven-release-plugin/artifactId
   version2.5/version
 /plugin
   /plugins
 /pluginManagement
 plugins
   plugin
 artifactIdmaven-release-plugin/artifactId
 configuration
   preparationGoalsclean verify site/preparationGoals
 /configuration
   /plugin
 . . .

   profiles
 profile
   idrun-it/id
   activation
 property
   nameperformRelease/name
   valuetrue/value
 /property
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
 executions
   execution
 goals
   goalintegration-test/goal
   goalverify/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /profile
   /profiles

 On 3/21/2014 1:10 PM, Eric Kolotyluk wrote:

 Cool, that is what I am looking for. Thanks so much.

 Cheers, Eric

 On 2014-03-20, 1:50 PM, Mirko Friedenhagen wrote:

 Eric,

 when you use the maven-release-plugin a property performRelease is set
 during release:perform.

 So define in the pluginManagement section a definition for the
 maven-failsafe-plugin in your build section:

 build
 pluginManagement
 plugins
plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  version2.17/version
  executions
  execution
 iddefault-integration-test/id
  goals
 goalintegration-test/goal
  /goals
  /execution
  execution
  iddefault-verify/id
  goals
  goalverify/goal
  /goals
  /execution
  /executions
  /plugin
 /plugins
 /pluginManagement
 /build

 and later on in your pom

  profile
  idrelease-run-failsafe/id
  activation
  property
  nameperformRelease/name
  valuetrue/value
  /property
  /activation
  build
   plugins
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
  /plugin
  /plugins
  /build
  profile

 So only during release:perform your integration tests will be executed
 and success is verified.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk
 eric.koloty...@gmail.com wrote:

 I am looking for some way to force my integration tests before a
 release,
 without explicitly using a profile.

 For example,

plugin
 artifactIdmaven-release-plugin/artifactId
  configuration
preparationGoalsclean verify site/preparationGoals
  /configuration
/plugin

 But that doesn't work because unless the failsafe plugin is defined, it
 won't run the tests.

 I thought of doing something like

profiles
  profile
idrun-it/id
activation
  file
 missingtarget/failsafe-reports/missing

Re: Site Repository Property was: Open Source Best Practices with Maven - distributionManagement

[Mirko Friedenhagen]

Hello Robert,

reading the information at
https://maven.apache.org/plugins/maven-site-plugin/deploy-mojo.html I
do not think there is an easy way to do this and probably never will
be.

1) AFAIK there is no (central) server available which hosts sites by default.
2) As stated on above page, there are a lot of different means to
deploy the site via wagon (ftp, http, ssh)
3) As a workaround you might think about using the site:stage-deploy
goal instead for your local builds.

Regards
Mirko

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 20, 2014 at 8:29 PM, Robert Kuropkat
rkurop...@t-sciences.com wrote:

 So is there an equivalent to altReleaseDeploymentRepository and
 altSnapshotDeploymentRepository for the Site Deployment information also?
 Since all three are in the Distribution Management directive, I was hoping I
 could define this last one in the settings.xml also.

 Robert Kuropkat


 On 03/19/2014 05:15 PM, Mirko Friedenhagen wrote:

 Hello Eric,

 as outlined in
 https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
 in your settings.xml you might define properties
 altReleaseDeploymentRepository and altSnapshotDeploymentRepository in
 a profile internal-repository which is activated by default while you
 do not define any repository at all in your pom.
 Now while developing you just invoke mvn deploy and everything should
 go to your local Nexus.
 When invoking mvn -P!internal-repository everything should go to central.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/



 snip

 -
 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: Forcing Integration Tests Before a Release

[Mirko Friedenhagen]

Eric,

when you use the maven-release-plugin a property performRelease is set
during release:perform.

So define in the pluginManagement section a definition for the
maven-failsafe-plugin in your build section:

build
   pluginManagement
   plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
version2.17/version
executions
execution
iddefault-integration-test/id
goals
goalintegration-test/goal
/goals
/execution
execution
iddefault-verify/id
goals
goalverify/goal
/goals
/execution
/executions
/plugin
   /plugins
   /pluginManagement
/build

and later on in your pom

profile
idrelease-run-failsafe/id
activation
property
nameperformRelease/name
valuetrue/value
/property
/activation
build
 plugins
plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-failsafe-plugin/artifactId
/plugin
/plugins
/build
profile

So only during release:perform your integration tests will be executed
and success is verified.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk
eric.koloty...@gmail.com wrote:
 I am looking for some way to force my integration tests before a release,
 without explicitly using a profile.

 For example,

   plugin
 artifactIdmaven-release-plugin/artifactId
 configuration
   preparationGoalsclean verify site/preparationGoals
 /configuration
   /plugin

 But that doesn't work because unless the failsafe plugin is defined, it
 won't run the tests.

 I thought of doing something like

   profiles
 profile
   idrun-it/id
   activation
 file
 missingtarget/failsafe-reports/missing
 /file
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-failsafe-plugin/artifactId
 version2.17/version
 executions
   execution
 goals
   goalintegration-test/goal
   goalverify/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
 /profile
   /profiles

 But that will cause the integration tests to be run after every clean.

 Is there some way I can trigger the integration tests when doing a release

mvn release:prepare

 without having to do

mvn release:prepare -P run-it

 Cheers, Eric

 -
 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: Open Source Best Practices with Maven - distributionManagement

[Mirko Friedenhagen]

Hello Eric,

as outlined in 
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
in your settings.xml you might define properties
altReleaseDeploymentRepository and altSnapshotDeploymentRepository in
a profile internal-repository which is activated by default while you
do not define any repository at all in your pom.
Now while developing you just invoke mvn deploy and everything should
go to your local Nexus.
When invoking mvn -P!internal-repository everything should go to central.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 19, 2014 at 9:39 PM, Stevo Slavić ssla...@gmail.com wrote:
 Hello Eric,

 I'd consider using Sonatype OSS with Sonatype OSS parent pom and everything
 that goes along (see more details at
 https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide)
 For OSS development maybe use private (and not local) Nexus as proxy only,
 with mirrors defined in local settings.xml, but publish both snapshots and
 releases to Sonatype OSS repositories which get synced to Maven Central.
 Why run Nexus on local machine? To control dependencies and their metada
 for yourself only? Still looks as overkill to me, if you're the sole user
 and plan on developing OSS. You already have local repository, and you
 should have same experience as your OSS users (so no custom local metadata
 of dependencies, depend only on stuff available on Maven Central, with
 metadata as it is published on Maven Central).

 Kind regards,
 Stevo Slavic


 On Wed, Mar 19, 2014 at 9:23 PM, Eric Kolotyluk 
 eric.koloty...@gmail.comwrote:

 Does anyone know of any good documentation on 'Open Source Best Practices
 with Maven'

 For example, in my POM, I want to set up

   distributionManagement
 downloadUrlhttp://localhost:8081/nexus/content/groups/public
 /downloadUrl
 repository
   uniqueVersionfalse/uniqueVersion
   idnexus-kolotyluk/id
   nameLocal Release Repository/name
 urlhttp://localhost:8081/nexus/content/repositories/releases/url
   layoutdefault/layout
 /repository
 snapshotRepository
   idnexus-kolotyluk/id
   nameLocal Snapshot Repository/name
 urlhttp://localhost:8081/nexus/content/repositories/snapshots/url
   layoutdefault/layout
 /snapshotRepository
   /distributionManagement

 But that is my local repository on my development computer.

 If I want to push my project to Maven Central some day, I don't think I
 want this in my POM.

 Should I put this in a parent POM, or inside a profile of my
 settings.xml file?

 If I put it in a parent POM, then I need to push that to Maven Central
 too, so that does not sound like a good idea.

 Cheer, Eric

 -
 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

[Mirko Friedenhagen]

Hello,

I had the same questions :-).

Vishai, you could invoke mvn compile, switch to the target/classes
directory and execute time jar cvf ../foo.jar . to see how long the
original jar command takes and compare this to the time needed by the
maven-jar-plugin.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Mar 14, 2014 at 12:23 AM, Benson Margulies
bimargul...@gmail.com wrote:
 How long is too long? How big is the jar?

 On Thu, Mar 13, 2014 at 2:31 PM, Vishal Kumar Gupta groups...@gmail.com 
 wrote:
 Hi Team,

 OS- Ubuntu 12.04 TLS
 Maven version - 3.2.1

 maven-jar-plugin:2.4:jar is taking too long to generate jar.

 pom.xml for plugin

 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-jar-plugin/artifactId
   version2.4/version
   configuration
forceCreationtrue/forceCreation
archive
 manifest
   addClasspathtrue/addClasspath
   /manifest
 /archive
   /configuration
 /plugin


 DEBUG log:-

 [DEBUG] Configuring mojo org.apache.maven.plugins:maven-jar-plugin:2.4:jar
 from plugin realm
 ClassRealm[pluginorg.apache.maven.plugins:maven-jar-plugin:2.4, parent:
 sun.misc.Launcher$AppClassLoader@262505b7]
 [DEBUG] Configuring mojo
 'org.apache.maven.plugins:maven-jar-plugin:2.4:jar' with basic configurator
 --
 [DEBUG]   (s) addClasspath = true
 [DEBUG]   (s) manifest =
 org.apache.maven.archiver.ManifestConfiguration@7be2e01
 [DEBUG]   (f) archive =
 org.apache.maven.archiver.MavenArchiveConfiguration@56be479f
 [DEBUG]   (f) classesDirectory = /Test/target/classes
 [DEBUG]   (f) defaultManifestFile =
 /Test/target/classes/META-INF/MANIFEST.MF
 [DEBUG]   (f) finalName = Test-0.0.1-SNAPSHOT
 [DEBUG]   (f) forceCreation = true
 [DEBUG]   (f) outputDirectory = /Test/target
 [DEBUG]   (f) project = MavenProject:
 com.ericsson.esip:cw-ws-server:0.0.1-SNAPSHOT @ /Test/pom.xml
 [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@ed1bb57
 [DEBUG]   (f) skipIfEmpty = false
 [DEBUG]   (f) useDefaultManifestFile = false
 [DEBUG] -- end configuration --



 Need help
 Thanks in advance.

 Regards,
 vishal

 -
 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: [Failsafe] How to properly conduct integration tests on executable jar files

[Mirko Friedenhagen]

Well with Netbeans you just add the following:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version${surefire.version}/version
configuration
systemPropertyVariables

shadedJarPath${project.build.directory}/${project.artifactId}-${project.version}-shaded.jar/shadedJarPath
/systemPropertyVariables
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
version${surefire.version}/version
executions
execution
iddefault-integration-test/id
goals
goalintegration-test/goal
/goals
/execution
/executions
configuration
systemPropertyVariables

shadedJarPath${project.build.directory}/${project.artifactId}-${project.version}-shaded.jar/shadedJarPath
/systemPropertyVariables
/configuration
/plugin

and using the Java-task from Ant:

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.ExitStatusException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.taskdefs.Java;
import org.apache.tools.ant.types.Commandline;

public class ShadedIT {
@Test
   public void testShaded() throws Exception {
Java java = new Java();
java.setProject(new Project());
java.setFailonerror(true);
java.setFork(true);
java.setJar(shadedJar);
Commandline.Argument arg = java.createArg();
arg.setFile(csvFile);
java.execute();
}
}

This will be executed by failsafe from the CLI and you may run the
class from Netbeans without any special settings.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Thu, Mar 13, 2014 at 10:50 AM, Adrien Rivard adrien.riv...@gmail.com wrote:
 If you are using Eclipse you could also pass the system property directly
 to the JRE. ( Windows/Preferences/installed JRE/ edit /default VM arguments)
 It require less work than putting it in all run configuration, but all your
 process will have it.



 On Thu, Mar 13, 2014 at 8:56 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 You could use test resource filtering to put the path into a resource file
 on the test classpath.

 That way the IDE will pick up the same path.

 On Thursday, 13 March 2014, Alex Karasulu akaras...@apache.org wrote:

  Hello,
 
  I've got a module that builds an executable jar file using the Maven
  Assembly Plugin. I'm trying to setup an integration test (in the same
  module) that runs this executable jar file as a separate process and
  interacts with it. To fire up the executable jar file, my integration
 test
  requires the path to the executable jar file.
 
  I'm trying to achieve this by passing a property to the integration-test
  via system properties. This makes me feel really really dirty though and
 it
  has issues: although the test runs on the CLI it does not in any IDE
  without requiring further configuration (i.e. the property has to be
  manually added to a run configuration).
 
  After googling around a bit and reading the documentation there seems to
 be
  no other option for this scenario. In case I'm overlooking something, I
  wanted to ask here if there is a better way to start up this executable
 jar
  file or pass in the needed parameters to do so in the integration test?
 
  --
  Best Regards,
  -- Alex
 


 --
 Sent from my phone




 --
 Adrien Rivard

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

Re: list all unique dependencies of multi-module project

[Mirko Friedenhagen]

Hello Max,

what about switching this to  a jar project without sources (maybe a readme
txt as resource), which is not deployed or installed?

Regards
Mirko
-- 
Sent from my mobile
On Mar 13, 2014 12:24 AM, Max Calderoni max.calder...@gmail.com wrote:

 Hi Curtis,
 thanks for answering. Yes, that was the first thing i tried, like you said,
 i had done:

 cd topPomDir
 mvn dependency:list

 but that does not print out the same nice report that i see in the
 Dependency Management section of the generated site, which is what i
 want.

 So, i did:
 mvn dependency:list  depsFile.txt
 cat depsFile.txt | grep \[INFO\][^:]*:[^:]*:[^:]*:[^:]*:.* | cut -d] -f2-
 | sort -u  depsFileSorted.txt

 to get the unique sorted list, but again, i would have thought there would
 be a direct way of doing this.
 In the end, i would like to get the Dependency Management report of the
 entire project (from the top container pom, like you said) on the generated
 website.
 That report does not produce the aggregate list of dependencies: i am not
 sure what it produces, but that is not it.

 So i guess the question is how to get that aggregate report into the site
 generation.

 With that txt file i create above i get by, but i wished its content got
 generated automatically for me with the site and displayed in html like the
 other reports. I am not quite sure why the maven site does not already do
 that for the top container pom.

 Max


 On Wed, Mar 12, 2014 at 1:16 PM, Curtis Rueden ctrue...@wisc.edu wrote:

  Hi Max,
 
  You could create a module (in the same build or outside of it) with pom
  packaging and which depends on all the modules of your build. Then when
 you
  list its dependencies, you'll get them all (excluding non-transitive ones
  such as optional scope deps).
 
  Regards,
  Curtis
 
 
  On Mon, Mar 10, 2014 at 4:31 PM, Max Calderoni max.calder...@gmail.com
  wrote:
 
   Hi,
   was not able to find a quick way to list a consolidated list of all
   dependencies in your project.
   What i am looking for is something along the lines of dependency:list,
 or
   dependency:resolve of the maven dependency plugin, but for the entire
   multi-module project.
  
   What i see the maven dependency plugin does is to list by module. For
 our
   release though, we are not interested in a per-module break-down, we
 are
   interested in the overall list of unique dependencies, and unique per
  GAV,
   classifier, scope.
  
   The only thing i could find is this:
  
 http://grep.codeconsult.ch/2010/07/08/list-all-your-maven-dependencies/
   but, do i really have to use a script? is there some goal of some
 plugin
   out there that generates that or a better report for the entire
 project's
   dependencies for me?
   The report generated in the Dependency Management section of the maven
  site
   does it, but again, on a per-module basis.
   Then the next question would be: how do i publish that in my maven
 site?
  
  
   --
   Max
  
 



 --
 Max Calderoni

Re: Fail assembly plugin if symbols are unknown

[Mirko Friedenhagen]

Bernd,

what about using enforcer's requireProperty rule?

Regards
Mirko
-- 
Sent from my mobile
On Mar 7, 2014 10:20 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:

 Hello,

 we use in a lot of projects special assembly descriptors, which
 typically use the following pattern:

 assembly
 ...
 iddistribution/id
 baseDirectory/baseDirectory
 files
 file

 outputDirectory${dist.x}/${dist.base.software.lib}/outputDirectory
 source${project.build.directory}/x.jar/source
 /file
 /files
 /assembly

 We are currently cleaning up some POMs and there is a risk that some of
 the properties are no longer defined. This produces ZIP files which
 have directory or file names in there with unexpanded ${dist*} symbols
 (file name not filters).

 Is it possible to make the assembly (archiver?) plugin (and
 others) fail in a situation where ${} cannot be interpolated?

 The same would be nice for manifest headers in the maven archiver
 (filter in this case)?

 Greetings
 Bernd


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

Re: JJTree with maven-compiler-plugin

[Mirko Friedenhagen]

Hello,

there is a special plugin for this at codehaus, just Google javacc maven
plugin and follow the *first* link.

Regards
Mirko
-- 
Sent from my mobile
On Mar 4, 2014 5:36 AM, Umashanker, Srividhya srividhya.umashan...@hp.com
wrote:

 I want to compile .jjt files into .java files using maven with
 javacc/jjtree.

 The maven-antrun-plugin wiki
 http://maven.apache.org/plugins/maven-antrun-plugin/usage.html says  :



 Some Ant expressions have their respective counterparts in Maven. Thus,
 one can simply invoke the corresponding Maven expression instead of using
 maven-antrun-plugin to avoid the unneccessary overhead.

 Ant expression

 Plugin

 JavaCC

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

 JJDoc

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

 JJTree

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



 Can someone point me to an example on how to use JJtree with
 maven-compiler-plugin?  Could not find much details on how to use other
 compilers.

 -Vidhya

Re: Releasing clean company parent Poms

[Mirko Friedenhagen]

Hello Bernd,

you could think about having a multi-module pom project with an
aggregation-pom, having life cycle/configuration jar module and your
company pom. Testing would be defined in the aggregation pom. Only ugly
thing that you have to duplicate some plugin versions in the aggregate and
company pom.

Regards from Karlsruhe
Mirko
-- 
Sent from my mobile
On Mar 1, 2014 2:26 AM, Bernd Eckenfels e...@zusammenkunft.net wrote:

 Hello,

 I am currently wondering what the best way would be to deploy a
 company wide parent POM (with maven release plugin) but have only the
 information in the parent POM which is actually about the object model
 of the clients (and not the definitions for deploying and testing the
 parent).

 I have seen that the ASF and Maven parents have moved some release
 related code to a second site-pom. So you dont have the site-specific
 definitions cluttering up the parent pom.

 However there is still SCM information and plugins in the parent pom.

 So, basically there are multiple ways, one would be to use deploy-file,
 another would be to attach a source file as a deployed artifact. I
 wonder if there is a prefered way to do this. Or is there a reason not
 to do it.

 My main question is, how the coordinates of the build project and the
 build artifacts would overlap?

 So, I was thinking to have a repository like:


 poms/pom.xml modules=company,... (com.pany.poms:aggregator:1.0)
  company/pom.xml (com.pany.poms:company-build:1.0)
  company/src/pom/pom.xml (com.pany.parent:pom:1.0)

 When releasing poms/pom.xml the result would be a released company wide
 parent pom which does by itself only contain project/company metadata
 and not plugins for itself.

 (I guess the easiest would be to manually deploy a static file, but in
 that case I could not automate that with some testing and site
 creation).

 I guess this topic is somewhat more relevant since there have been some
 discussions about seperating the public visible models from (its own)
 build instructions in later POM schema versions.


 Gruss
 Bernd

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

Re: Releasing clean company parent Poms

[Mirko Friedenhagen]

Sorry Bernd and everyone,

I did not see that you just outlined the solution I proposed yourself.

Regards
Mirko
-- 
Sent from my mobile
On Mar 1, 2014 1:11 PM, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:

 Hello Bernd,

 you could think about having a multi-module pom project with an
 aggregation-pom, having life cycle/configuration jar module and your
 company pom. Testing would be defined in the aggregation pom. Only ugly
 thing that you have to duplicate some plugin versions in the aggregate and
 company pom.

 Regards from Karlsruhe
 Mirko
 --
 Sent from my mobile
 On Mar 1, 2014 2:26 AM, Bernd Eckenfels e...@zusammenkunft.net wrote:

 Hello,

 I am currently wondering what the best way would be to deploy a
 company wide parent POM (with maven release plugin) but have only the
 information in the parent POM which is actually about the object model
 of the clients (and not the definitions for deploying and testing the
 parent).

 I have seen that the ASF and Maven parents have moved some release
 related code to a second site-pom. So you dont have the site-specific
 definitions cluttering up the parent pom.

 However there is still SCM information and plugins in the parent pom.

 So, basically there are multiple ways, one would be to use deploy-file,
 another would be to attach a source file as a deployed artifact. I
 wonder if there is a prefered way to do this. Or is there a reason not
 to do it.

 My main question is, how the coordinates of the build project and the
 build artifacts would overlap?

 So, I was thinking to have a repository like:


 poms/pom.xml modules=company,... (com.pany.poms:aggregator:1.0)
  company/pom.xml (com.pany.poms:company-build:1.0)
  company/src/pom/pom.xml (com.pany.parent:pom:1.0)

 When releasing poms/pom.xml the result would be a released company wide
 parent pom which does by itself only contain project/company metadata
 and not plugins for itself.

 (I guess the easiest would be to manually deploy a static file, but in
 that case I could not automate that with some testing and site
 creation).

 I guess this topic is somewhat more relevant since there have been some
 discussions about seperating the public visible models from (its own)
 build instructions in later POM schema versions.


 Gruss
 Bernd

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

Re: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

[Mirko Friedenhagen]

Hello Karl-Heinz,

thanks for you suggestions, I replaced classifier tests with type
test-jar. As you stated release:prepare does not work because I do not
have a SNAPSHOT-version. My other concern is still true, running:
env revision=NULL mvn321 clean install
still has the non-resolved property ${revision} in the installed pom
in my localRepository.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Feb 24, 2014 at 11:05 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 Hi Mirko,




 I just tried this with a small multimodule pet project, see the mvn321
 branch (https://github.com/1and1/testlink-junit/compare/master...mvn321).


 Just forked it give it a try..



 Now giving revision as a property (mvn321 -Drevision=NULL clean
 verify) does *not* work, enforcer complains about being not able to
 resolve the reactor artifacts. You have to put revision into the
 environment, so
 env revision=NULL mvn321 clean verify does the trick.


 that looks strange...cause if i do that i get the following:

 [INFO]
 [INFO] --- maven-enforcer-plugin:1.3.1:enforce (default-enforce) @
 tljunit-surefire ---
 Downloading:
 http://localhost:8081/nexus/content/groups/public/net/oneandone/testlinkjunit/tljunit-parent/3.0.3-${revision}/tljunit-parent-3.0.3-${revision}.pom
 [WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireNoRepositories
 failed with message:
 Could not transfer artifact
 net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision} from/to
 nexus (http://localhost:8081/nexus/content/groups/public): Illegal character
 in path at index 100:
 http://localhost:8081/nexus/content/groups/public/net/oneandone/testlinkjunit/tljunit-parent/3.0.3-${revision}/tljunit-parent-3.0.3-${revision}.pom

   net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision}

 from the specified remote repositories:
   nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
 snapshots=true)


 That looks like a issue with maven-enforcer ...i will start writing an
 integration tests for that

 Furthermore i have taken a look into the project and found something
 strange:

 in the dependencyManagement of the parent:

  dependency
 groupIdnet.oneandone.testlinkjunit/groupId
 artifactIdtljunit-surefire/artifactId
 version${project.version}/version
 classifiertests/classifier
  /dependency

 Should this reference the test-jar which is produced in the sub-module by
 using maven-jar-plugin:test-jar goal ?

 Yes...than the dependency entry is wrong. It must be done like the
 following:

  dependency
 groupIdnet.oneandone.testlinkjunit/groupId
 artifactIdtljunit-surefire/artifactId
 version${project.version}/version
 typetest-jar/type
 scopetest/scope
  /dependency

 And this dependeny is used in the  module:

 artifactIdtljunit-eclipse/artifactId

 which produces your error about the not resolvable artifact in the
 reactor


 If you are using the maven-release-plugin you need to give the parameters in
 a different way cause maven-release-plugin calls maven a second time which
 will result in the following:

 mvn -Drevision=NULL -Darguments=-Drevision=NULL release:prepare

 This looks a bit strange but it works except that i get a message about not
 existing SNAPSHOT version...but no failure.
 If you enhance your configuration of the maven-release-plugin with the
 following line:

 arguments-Drevision=${revision}/arguments

 You can reduce the above call to:

 mvn -Drevision=NULL release:prepare


 Kind regards
 Karl-Heinz Marbaise
 --
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de


 -
 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: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

[Mirko Friedenhagen]

Hello,

I just tried this with a small multimodule pet project, see the mvn321
branch (https://github.com/1and1/testlink-junit/compare/master...mvn321).

Now giving revision as a property (mvn321 -Drevision=NULL clean
verify) does *not* work, enforcer complains about being not able to
resolve the reactor artifacts. You have to put revision into the
environment, so
env revision=NULL mvn321 clean verify does the trick.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Feb 24, 2014 at 9:23 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 Hi Dan,

 now you can write on your GAV definition a thing like:

 groupId.../groupId
 artifactId.../artifactId
 version1.0-${revision}-SNAPSHOT/version

 and via command line you can now do the following:

 mvn -Drevision=3456 clean test

 If you done that via Maven 3.1.1 you get a warning with Maven 3.2.1 you
 don't.

 Kind regard
 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: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

[Mirko Friedenhagen]

Hello,

I now tried running `env revision=123456 mvn321 release:prepare`, but
this does not work as release:prepare does not seem to use the
information from the environment, I get:
--- snip ---
There are still some remaining snapshot dependencies.
: Do you want to resolve them now? (yes/no) no: : no
--- snap ---
and release:prepare about:
--- snip ---
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare
(default-cli) on project tljunit-parent: Can't release project due to
non released dependencies :
[ERROR] 
net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision}-SNAPSHOT
[ERROR] in project 'tljunit surefire RunListeners'
(net.oneandone.testlinkjunit:tljunit-surefire:jar:3.0.3-123456-SNAPSHOT)
 [ERROR] - [Help 1]
--- snap ---
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Feb 24, 2014 at 9:31 PM, Dan Tran dant...@gmail.com wrote:
 Thanks, that helps

 -D


 On Mon, Feb 24, 2014 at 12:23 PM, Karl Heinz Marbaise 
 khmarba...@gmx.dewrote:

 Hi Dan,

 now you can write on your GAV definition a thing like:

 groupId.../groupId
 artifactId.../artifactId
 version1.0-${revision}-SNAPSHOT/version

 and via command line you can now do the following:

 mvn -Drevision=3456 clean test

 If you done that via Maven 3.1.1 you get a warning with Maven 3.2.1 you
 don't.

 Kind regard
 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: about https://jira.codehaus.org/browse/MNG-5576 (Allow continuous delivery friendly versions)

[Mirko Friedenhagen]

Hello,

I now removed -SNAPSHOT from the version strings, what I get now when running:
env revision=123456 mvn321 clean install
is:
Installing /Users/mirko/workspace/foss/testlink-junit/pom.xml to
/Software/nobackup/m2repo/net/oneandone/testlinkjunit/tljunit-parent/3.0.3-123456/tljunit-parent-3.0.3-123456.pom

and, which is really bad, when inspecting
tljunit-parent-3.0.3-123456.pom, the version is still
3.0.3-${revision}!

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Mon, Feb 24, 2014 at 9:51 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I now tried running `env revision=123456 mvn321 release:prepare`, but
 this does not work as release:prepare does not seem to use the
 information from the environment, I get:
 --- snip ---
 There are still some remaining snapshot dependencies.
 : Do you want to resolve them now? (yes/no) no: : no
 --- snap ---
 and release:prepare about:
 --- snip ---
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare
 (default-cli) on project tljunit-parent: Can't release project due to
 non released dependencies :
 [ERROR] 
 net.oneandone.testlinkjunit:tljunit-parent:pom:3.0.3-${revision}-SNAPSHOT
 [ERROR] in project 'tljunit surefire RunListeners'
 (net.oneandone.testlinkjunit:tljunit-surefire:jar:3.0.3-123456-SNAPSHOT)
  [ERROR] - [Help 1]
 --- snap ---
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Mon, Feb 24, 2014 at 9:31 PM, Dan Tran dant...@gmail.com wrote:
 Thanks, that helps

 -D


 On Mon, Feb 24, 2014 at 12:23 PM, Karl Heinz Marbaise 
 khmarba...@gmx.dewrote:

 Hi Dan,

 now you can write on your GAV definition a thing like:

 groupId.../groupId
 artifactId.../artifactId
 version1.0-${revision}-SNAPSHOT/version

 and via command line you can now do the following:

 mvn -Drevision=3456 clean test

 If you done that via Maven 3.1.1 you get a warning with Maven 3.2.1 you
 don't.

 Kind regard
 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: Looking for org.apache.poi 3.10-FINAL

[Mirko Friedenhagen]

David,

just guessing:
- indexing takes it's time, there are only two hours difference between the
commit (??l and end of indexing.
- commit (tag creation), artifact creation (jar build), deployment (upload
to staging),  promotion (move of staged to released) and synchronization
from oss.sonatype.org to repo1 add delays :-)

Regards
Mirko
-- 
Sent from my mobile
On Feb 16, 2014 9:43 AM, David Law m2ecli...@apconsult.de wrote:

 Hi,

 I'm new to maven  thought I'd try it out on the recently checked-in:
 org.apache.poi3.10-FINAL

 I'm using m2eclipse standard config with Eclipse Kepler.  Repo defaults to:
 http://repo.maven.apache.org/maven2

 The Problem:
 m2eclipse does not know the  org.apache.poi  3.10-FINAL  artifact.

 Now, I guess the problem could be any combination of:
 a) me  b) POI  c) maven  d) m2eclipse  e) eclipse?

 QUESTION) Can anyone help to localise it?

 Here's what I've found out so far:

 0) repo is: http://repo.maven.apache.org/maven2

 1) org.apache.poi  3.10-FINAL was committed @ 09-Feb-2014 11:50

 2) as of now repo Timestamp is: 09-Feb-2014 13:50
 (nexus.index.timestamp=20140209134945.568 +)
 (found in
 http://repo.maven.apache.org/maven2/.index/nexus-maven-
 repository-index.properties)

 3) - so repo has been reindexed since org.apache.poi  3.10-FINAL commit
 (6 days ago).

 4) exit eclipse

 5) deleted the index
 C:\...\Eclipse\workspace\.metadata\.plugins\org.eclipse.m2e.core\nexus

 6) start eclipse - updating index

 7) org.apache.poi  3.10-FINAL is still not there (that is: here) in my
 list of artifacts

 All the best,
 DaveLaw

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

Re: Why is dependency:analyze lying to me?

[Mirko Friedenhagen]

Hello,

you see this a lot with runtime dependencies (which should probably be
ignored during analyze anyway), so I mostly just ignore these in the
output. It would be a cool thing, if you could suppress warnings for gavs
directly in the analyze goal, so you see new stuff coming up more easily.

Regards
Mirko
-- 
Sent from my mobile
On Feb 13, 2014 11:01 PM, Wayne Fay wayne...@gmail.com wrote:

  This may fall into the “How the hell is Maven supposed to know?”
 category,

 Yes, it most certainly does.

  [WARNING]
 
 org.springframework.security:spring-security-taglibs:jar:3.1.1.RELEASE:compile
 ...
  Anyway, not sure if the plugin can be configured to detect these kind of
  things, but a guy can dream, can’t he??

 You would need to write code that performs the following tasks:
 1. look in jar files related to dependencies
 2. find taglib files and other configuration files [each file type
 needs its own parser]
 3. store tag uris that are discovered along with the associated jar
 4. check those tag uris vs what is in your code (keep in mind some may
 be in config files you wrote, so gotta parse those too - more code to
 write)
 5. output the list of jars (dependencies) which are not actually used
 in code or config

 This is nontrivial, so no one has done it. I'm sure we'd take a
 contribution if you did the work.

 Wayne

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