Re: how to run compile and packaging before test?

2013-12-13 Thread Malte Skoruppa

Just scanning http://maven.apache.org and its not obvious by the
content on the page where the books are.

Its over in the menu on the left under Documentation > Books and Resources

I wonder if we should add a section under "Learning about Maven".

When you might have gone looking, where would you expect to find this info?



I actually only learned about the books from this mailing list. A new 
user won't usually read the entire menu. They will just scan it.
To get started with Maven on the website, I only read the documentation 
links under "User Centre". I think it would be a good idea if at least 
the "Getting Started Guide" had one sentence at the very end that went 
something like "To find out more about Maven, check out the href=...>books!" Then, at least everybody who checks out the Getting 
Started Guide at least KNOWS that there are books ;-)


Meanwhile, one doesn't necessarily have to buy a book to learn about the 
Maven lifecycle. This is also explained on the website:

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
A link to the Guides index (guides/index.html) at the end of the Getting 
Started Guide would also be a good idea, for the same reasons.



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



Re: how to run compile and packaging before test?

2013-12-13 Thread Barrie Treloar
On 13 December 2013 19:48, Malte Skoruppa  wrote:
>> Just scanning http://maven.apache.org and its not obvious by the
>> content on the page where the books are.
>>
>> Its over in the menu on the left under Documentation > Books and Resources
>>
>> I wonder if we should add a section under "Learning about Maven".
>>
>> When you might have gone looking, where would you expect to find this
>> info?
>>
>
> I actually only learned about the books from this mailing list. A new user
> won't usually read the entire menu. They will just scan it.
> To get started with Maven on the website, I only read the documentation
> links under "User Centre". I think it would be a good idea if at least the
> "Getting Started Guide" had one sentence at the very end that went something
> like "To find out more about Maven, check out the books!"
> Then, at least everybody who checks out the Getting Started Guide at least
> KNOWS that there are books ;-)

Ok, I'll get around to patching that.

> Meanwhile, one doesn't necessarily have to buy a book to learn about the
> Maven lifecycle. This is also explained on the website:
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Yes, but it doesn't go into enough details.

The *free* books do.

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



Re: how to run compile and packaging before test?

2013-12-13 Thread Malte Skoruppa



Meanwhile, one doesn't necessarily have to buy a book to learn about the
Maven lifecycle. This is also explained on the website:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Yes, but it doesn't go into enough details.

The *free* books do.


This actually surprised me. Free?
Looking at the "Books and Resources" page more closely, I found but 
*one* book that is free, namely the "Better Builds with Maven" (2006, 
covers Maven 2.0.4 - i.e., rather old).

For all the other books, there are Amazon (and similar) links.

If these other books are also freely available, this should certainly be 
put forward more clearly on the page, with appropriate links.


Apart from the books, the "Books and Resources" page links to a plethora 
of articles on this and that about Maven. But that is not what you'd 
call a structured introduction to Maven, let alone a "book". (Well, at 
least, that's not where I'd go digging if I wanted to find out more 
about, say, the build lifecycle. I'd go to the Guides index in that 
case. At least that's sorted by category.)


On a sidenote, I also noticed that the page links to "JavaBlackBelt's 
Maven Exam" on javablackbelt.com under "Miscellaneous on Maven". 
However, javablackbelt.com does not exist anymore [1], and the "Maven 
Exam" link is dead. [2]


[1] http://en.wikipedia.org/wiki/Javablackbelt
[2] 
http://www.javablackbelt.com/QuestionnaireDefDisplay.wwa?questPublicId=01559


** 


Re: how to run compile and packaging before test?

2013-12-13 Thread Malte Skoruppa
Oh, and I forgot to mention that "Maven: The Definitive Guide" book 
which apparently is also free, although you can also buy a printed version.


However, the http link to the book on sonatype.com is dead. It should be 
updated.


It would also be helpful for users who scan that page if the free books 
were somehow better visually highlighted. Like a big green button that 
says "Free!" beside the corresponding book or whatever.



On 12/13/2013 11:34 AM, Malte Skoruppa wrote:


Meanwhile, one doesn't necessarily have to buy a book to learn about 
the

Maven lifecycle. This is also explained on the website:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html 


Yes, but it doesn't go into enough details.

The *free* books do.


This actually surprised me. Free?
Looking at the "Books and Resources" page more closely, I found but 
*one* book that is free, namely the "Better Builds with Maven" (2006, 
covers Maven 2.0.4 - i.e., rather old).

For all the other books, there are Amazon (and similar) links.

If these other books are also freely available, this should certainly 
be put forward more clearly on the page, with appropriate links.


Apart from the books, the "Books and Resources" page links to a 
plethora of articles on this and that about Maven. But that is not 
what you'd call a structured introduction to Maven, let alone a 
"book". (Well, at least, that's not where I'd go digging if I wanted 
to find out more about, say, the build lifecycle. I'd go to the Guides 
index in that case. At least that's sorted by category.)


On a sidenote, I also noticed that the page links to "JavaBlackBelt's 
Maven Exam" on javablackbelt.com under "Miscellaneous on Maven". 
However, javablackbelt.com does not exist anymore [1], and the "Maven 
Exam" link is dead. [2]


[1] http://en.wikipedia.org/wiki/Javablackbelt
[2] 
http://www.javablackbelt.com/QuestionnaireDefDisplay.wwa?questPublicId=01559


** 




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



Re: how to run compile and packaging before test?

2013-12-13 Thread Anders Hammar
> However, the http link to the book on sonatype.com is dead. It should be
> updated.
>

Hm, ok. I asked Sonatype some time ago to fix that. I'll remind them.

/Anders



>
> It would also be helpful for users who scan that page if the free books
> were somehow better visually highlighted. Like a big green button that says
> "Free!" beside the corresponding book or whatever.
>
>
>
> On 12/13/2013 11:34 AM, Malte Skoruppa wrote:
>
>>
>>  Meanwhile, one doesn't necessarily have to buy a book to learn about the
 Maven lifecycle. This is also explained on the website:
 http://maven.apache.org/guides/introduction/
 introduction-to-the-lifecycle.html

>>> Yes, but it doesn't go into enough details.
>>>
>>> The *free* books do.
>>>
>>
>> This actually surprised me. Free?
>> Looking at the "Books and Resources" page more closely, I found but *one*
>> book that is free, namely the "Better Builds with Maven" (2006, covers
>> Maven 2.0.4 - i.e., rather old).
>> For all the other books, there are Amazon (and similar) links.
>>
>> If these other books are also freely available, this should certainly be
>> put forward more clearly on the page, with appropriate links.
>>
>> Apart from the books, the "Books and Resources" page links to a plethora
>> of articles on this and that about Maven. But that is not what you'd call a
>> structured introduction to Maven, let alone a "book". (Well, at least,
>> that's not where I'd go digging if I wanted to find out more about, say,
>> the build lifecycle. I'd go to the Guides index in that case. At least
>> that's sorted by category.)
>>
>> On a sidenote, I also noticed that the page links to "JavaBlackBelt's
>> Maven Exam" on javablackbelt.com under "Miscellaneous on Maven".
>> However, javablackbelt.com does not exist anymore [1], and the "Maven
>> Exam" link is dead. [2]
>>
>> [1] http://en.wikipedia.org/wiki/Javablackbelt
>> [2] http://www.javablackbelt.com/QuestionnaireDefDisplay.wwa?
>> questPublicId=01559
>>
>> ** 
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Multi-modules projects

2013-12-13 Thread Michael Priess
Hi,

our projects have the following structure:

- parent pom
-- pom.xml
cpp--pom.xml
java--pom.xml

To build a project like this we must invoke different build steps. For the
CPP build we like to invoke gcc for the java build we like to invoke javac
and many other steps. In our enviroment we have a lot of builds which are
similar.

Is there a way to define the builds steps in one place to avoid
duplications of the javac and gcc build configuration. I like to inherite
or get the build steps from one central place and use this steps in a multi
module project. Any idea howto resolve this?

Cheerrs,

Michael


Re: Multi-modules projects

2013-12-13 Thread Stephen Connolly
 is your friend

The C++ code should be using a different packaging type, that way it can
bind the plugins that your C++ packaging needs to the corresponding
lifecycle phases and then...

mvn compile

will do just that, irrespective of whether you are in the C++ or the Java
module, and likewise for

mvn test

mvn package

mvn install

mvn deploy

etc


On 13 December 2013 12:24, Michael Priess wrote:

> Hi,
>
> our projects have the following structure:
>
> - parent pom
> -- pom.xml
> cpp--pom.xml
> java--pom.xml
>
> To build a project like this we must invoke different build steps. For the
> CPP build we like to invoke gcc for the java build we like to invoke javac
> and many other steps. In our enviroment we have a lot of builds which are
> similar.
>
> Is there a way to define the builds steps in one place to avoid
> duplications of the javac and gcc build configuration. I like to inherite
> or get the build steps from one central place and use this steps in a multi
> module project. Any idea howto resolve this?
>
> Cheerrs,
>
> Michael
>


AW: Multi-modules projects

2013-12-13 Thread Christofer Dutz
I have similar Projects consisting of Java, Flex and .Net artifacts.
I usually configure the plugins in the root of the maven Project and use 
self-activating maven profiles.

Flex is active if a Directory src/main/flex exists, Npanday is used if i have 
src/main/csharp and so on.


java-project


src/main/java


...

flex-project


src/main/flex


...

csharp-project


src/main/csharp


...

Gesendet: Freitag, 13. Dezember 2013 13:24
An: users@maven.apache.org
Betreff: Multi-modules projects

Hi,

our projects have the following structure:

- parent pom
-- pom.xml
cpp--pom.xml
java--pom.xml

To build a project like this we must invoke different build steps. For the
CPP build we like to invoke gcc for the java build we like to invoke javac
and many other steps. In our enviroment we have a lot of builds which are
similar.

Is there a way to define the builds steps in one place to avoid
duplications of the javac and gcc build configuration. I like to inherite
or get the build steps from one central place and use this steps in a multi
module project. Any idea howto resolve this?

Cheerrs,

Michael

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



Re: how to run compile and packaging before test?

2013-12-13 Thread Ron Wheeler

Malte,
Great points.
File a few JIRA issues describing the problems that you are finding.
That way they will get on the list of things to do.

I think that you might find some of the books are free in their 
electronic formats but are not free if you want paper.


Ron

On 13/12/2013 5:34 AM, Malte Skoruppa wrote:


Meanwhile, one doesn't necessarily have to buy a book to learn about 
the

Maven lifecycle. This is also explained on the website:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html 


Yes, but it doesn't go into enough details.

The *free* books do.


This actually surprised me. Free?
Looking at the "Books and Resources" page more closely, I found but 
*one* book that is free, namely the "Better Builds with Maven" (2006, 
covers Maven 2.0.4 - i.e., rather old).

For all the other books, there are Amazon (and similar) links.

If these other books are also freely available, this should certainly 
be put forward more clearly on the page, with appropriate links.


Apart from the books, the "Books and Resources" page links to a 
plethora of articles on this and that about Maven. But that is not 
what you'd call a structured introduction to Maven, let alone a 
"book". (Well, at least, that's not where I'd go digging if I wanted 
to find out more about, say, the build lifecycle. I'd go to the Guides 
index in that case. At least that's sorted by category.)


On a sidenote, I also noticed that the page links to "JavaBlackBelt's 
Maven Exam" on javablackbelt.com under "Miscellaneous on Maven". 
However, javablackbelt.com does not exist anymore [1], and the "Maven 
Exam" link is dead. [2]


[1] http://en.wikipedia.org/wiki/Javablackbelt
[2] 
http://www.javablackbelt.com/QuestionnaireDefDisplay.wwa?questPublicId=01559


** 




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



Re: Multi-modules projects

2013-12-13 Thread Michael Priess
@Stephan Connolly Thanks for the hint. But can I bind a profile to a self
defined package or could you provide a example project :)


2013/12/13 Christofer Dutz 

> I have similar Projects consisting of Java, Flex and .Net artifacts.
> I usually configure the plugins in the root of the maven Project and use
> self-activating maven profiles.
>
> Flex is active if a Directory src/main/flex exists, Npanday is used if i
> have src/main/csharp and so on.
>
> 
> java-project
> 
> 
> src/main/java
> 
> 
> ...
>  
> flex-project
> 
> 
> src/main/flex
> 
> 
> ...
>  
> csharp-project
> 
> 
> src/main/csharp
> 
> 
> ...
> 
> Hope this helps.
>
> Chris
>
>
> 
> Von: Michael Priess 
> Gesendet: Freitag, 13. Dezember 2013 13:24
> An: users@maven.apache.org
> Betreff: Multi-modules projects
>
> Hi,
>
> our projects have the following structure:
>
> - parent pom
> -- pom.xml
> cpp--pom.xml
> java--pom.xml
>
> To build a project like this we must invoke different build steps. For the
> CPP build we like to invoke gcc for the java build we like to invoke javac
> and many other steps. In our enviroment we have a lot of builds which are
> similar.
>
> Is there a way to define the builds steps in one place to avoid
> duplications of the javac and gcc build configuration. I like to inherite
> or get the build steps from one central place and use this steps in a multi
> module project. Any idea howto resolve this?
>
> Cheerrs,
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Question: Maven Pathes includes and others

2013-12-13 Thread Hoffmann Martin (UniCredit Business Integrated Solutions)
Dear All,

I'm trying to get the Junit tests for an multi module Project running. All test 
run fine, expect one test.

I don't use the standard maven hierarchy, because the project is very old and 
yet we start to mavenize it.

First of all a snippet of my Child Pom:


${project.groupId}_${project.artifactId}
./src



${project.build.sourceDirectory}


src/de/hvb/roldial3/core/xml/*.xml

src/de/hvb/roldial3/core/xml/*.xsl


de/hvb/roldial3/core/xml/



${project.build.sourceDirectory}


src/de/hvb/roldial3/core/castor/*.xml


de/hvb/roldial3/core/castor/


${project.parent.basedir}


config/application/MQ/ugiscerts_V20

config/application/MQ/mdrKeyStore

.





com.google.code.maven-replacer-plugin
replacer
1.5.2


validate

replace





${project.parent.basedir}/rochade730/appl/rochade.ini



D:\MavenProjects\roldial3\default

${project.parent.absolutePath}





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


org.apache.maven.plugins
maven-surefire-plugin
2.16


true

${project.build.sourceDirectory}

${project.build.directory}/classes/


${basedir}/${project.parent.relativePath}


**/*Test.java

true
always

${user.dir}

true





src

*.xml




src/de/hvb/roldial3/core/xml

*.xsl
*.xml


de/hvb/roldial3/core/xml



src/de/hvb/roldial3/core/castor

*.xml


de/hvb/roldial3/core/castor






In my Java class I use the following line, which makes the problem:

String cgfFileName = getSystemProperty("hvbappsdata")
+ "/config/application/mq.properties";


The property file looks like this:

WMQ_KEYSTORE_LOCATION=../../MQ/mdrKeyStore
WMQ_TRUSTSTORE_LOCATION=../../MQ/ugiscerts_V20


The problem is, that maven doesn't find the path

Re: Question: Maven Pathes includes and others

2013-12-13 Thread Adrien Rivard
Hi,

I would try systemPropertyVariables and not  in the
maven-surefire-plugin

like

true






On Fri, Dec 13, 2013 at 3:37 PM, Hoffmann Martin (UniCredit Business
Integrated Solutions)  wrote:

> Dear All,
>
> I'm trying to get the Junit tests for an multi module Project running. All
> test run fine, expect one test.
>
> I don't use the standard maven hierarchy, because the project is very old
> and yet we start to mavenize it.
>
> First of all a snippet of my Child Pom:
>
> 
>
> ${project.groupId}_${project.artifactId}
> ./src
> 
> 
>
> ${project.build.sourceDirectory}
> 
>
> src/de/hvb/roldial3/core/xml/*.xml
>
> src/de/hvb/roldial3/core/xml/*.xsl
> 
>
> de/hvb/roldial3/core/xml/
> 
> 
>
> ${project.build.sourceDirectory}
> 
>
> src/de/hvb/roldial3/core/castor/*.xml
> 
>
> de/hvb/roldial3/core/castor/
> 
> 
>
> ${project.parent.basedir}
> 
>
> config/application/MQ/ugiscerts_V20
>
> config/application/MQ/mdrKeyStore
> 
> .
> 
> 
> 
> 
>
> com.google.code.maven-replacer-plugin
> replacer
> 1.5.2
> 
> 
> validate
> 
>
> replace
> 
> 
> 
> 
>
> ${project.parent.basedir}/rochade730/appl/rochade.ini
> 
> 
>
> D:\MavenProjects\roldial3\default
>
> ${project.parent.absolutePath}
> 
> 
> 
> 
> 
> org.apache.maven.plugins
>
> maven-compiler-plugin
> 3.1
> 
> 
> org.apache.maven.plugins
>
> maven-surefire-plugin
> 2.16
> 
>
> true
>
> ${project.build.sourceDirectory}
>
> ${project.build.directory}/classes/
> 
>
> ${basedir}/${project.parent.relativePath}
> 
> 
>
> **/*Test.java
> 
>
> true
> always
>
> ${user.dir}
>
> true
> 
> 
> 
> 
> 
> src
> 
> *.xml
> 
> 
> 
>
> src/de/hvb/roldial3/core/xml
> 
> *.xsl
> *.xml
> 
>
> de/hvb/roldial3/core/xml
> 
> 
>
> src/de/hvb/roldial3/core/castor
> 
> *.xml
> 
>
> de/hvb/roldial3/core/castor
> 
> 
> 
>
>
>
> In my Java class I use the following line, which makes the problem:
>
> String cgfFileName = getSystemProperty("hvbappsdata")
> +
> "/config/application/mq.properties";
>
>
> The property file looks like this:
>
> WMQ_KEYSTORE_LOCATION=../../MQ/mdrKeyStore
> WMQ_TRUSTSTORE_LOCATION=../../MQ/ugiscerts_V20
> 
>
> The problem is, that maven doesn't find the pathes mentioned in the
> property file and therefore the junit test fails. For sure it's only an
> TestResource problem.
>
> My Folder hierarchy looks likes:
>
> Project
> |_config
> |_application
> |   Property file
> |   |___MQ
> |   |__mdrKeyStore
> |   Ugiscerts_v20
> |
> Workspace
> |__module
> |_child.pom
> |
> |__s

maven deploy plugin fails with artifact-not-found

2013-12-13 Thread Sankaran, Nambi
I’m trying to deploy a snapshot version of the artifact for the first time.
Maven deploy fails with error “could not find artifact in the remote repository”
Obviously the artifact was never deployed in the remote repository, so it is 
not available in the remote repository.

Tried with various versions of “deploy” plugin, the issue happens in all of 
them.

How to deploy a snapshot version on an empty repository?


$mvn  org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.ebay.platform:platform-root:pom:2.0.0.RC3-SNAPSHOT
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: javax.servlet:jstl:jar -> version 1.2 vs 1.2_1 @ line 515, 
column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: com.sun.xml.bind:jaxb-impl:jar -> duplicate declaration of 
version 2.2.3.20110115 @ line 536, column 16
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING]
[INFO]
[INFO] 
[INFO] Building platform root pom 2.0.0.RC3-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-deploy-plugin:2.8.1:deploy (default-cli) @ platform-root ---
Downloading: 
http://repocorp.com/content/repositories/snapshots/com/ebay/platform/platform-root/2.0.0.RC3-SNAPSHOT/maven-metadata.xml
Uploading: 
http://repocorp.com/content/repositories/snapshots/com/ebay/platform/platform-root/2.0.0.RC3-SNAPSHOT/platform-root-2.0.0.RC3-20131213.165021-1.pom
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.576s
[INFO] Finished at: Fri Dec 13 08:50:21 PST 2013
[INFO] Final Memory: 9M/156M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy (default-cli) on 
project platform-root: Failed to deploy artifacts: Could not find artifact 
com.platform:platform-root:pom:2.0.0.RC3-20131213.165021-1 in snapshots 
(http://repocorp.com/content/repositories/snapshots/) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException



Re: maven deploy plugin fails with artifact-not-found

2013-12-13 Thread Thorsten Heit
Hi,

> I’m trying to deploy a snapshot version of the artifact for the first 
time.
> Maven deploy fails with error “could not find artifact in the remote
> repository”
> Obviously the artifact was never deployed in the remote repository, 
> so it is not available in the remote repository.
> 
> Tried with various versions of “deploy” plugin, the issue happens in
> all of them.
> 
> How to deploy a snapshot version on an empty repository?
> 
> 
> $mvn  org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy

You try to deploy something that has to be built first, a step that is 
skipped in your case. Try "mvn deploy" instead.


HTH

Thorsten


Re: maven deploy plugin fails with artifact-not-found

2013-12-13 Thread Sankaran, Nambi
Yes, did try ³mvm deploy². But it fails in an empty repo.

This is a parent pom file ( packaging = pom ).
This pom contains  section and
 section that¹s all.



On 12/13/13, 10:07 AM, "Thorsten Heit"  wrote:

>Hi,
>
>> I¹m trying to deploy a snapshot version of the artifact for the first
>time.
>> Maven deploy fails with error ³could not find artifact in the remote
>> repository²
>> Obviously the artifact was never deployed in the remote repository,
>> so it is not available in the remote repository.
>> 
>> Tried with various versions of ³deploy² plugin, the issue happens in
>> all of them.
>> 
>> How to deploy a snapshot version on an empty repository?
>> 
>> 
>> $mvn  org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy
>
>You try to deploy something that has to be built first, a step that is
>skipped in your case. Try "mvn deploy" instead.
>
>
>HTH
>
>Thorsten


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



Re: Painless way to update a frameworks group id?

2013-12-13 Thread Mirko Friedenhagen
Just a guess:

* Deploy a new relocation pom at the old coordinates with a bigger version.
* Include this new relocation version.

Regards Mirko
-- 
Sent from my mobile
On Dec 12, 2013 1:26 PM, "Anders Hammar"  wrote:

> > Think some sort of "artifact-transformer" mechanism in Maven would be
> >> really cool ("Map the following groupId to otherGroupId").
> >
> >
> > There is some discussion around this feature for a future POM model. Any
> > year now. :-)
> >
>
> Oh, I should prabably stress that this "discussion" is no promise for this
> feature. It might require a change to the Maven repository structure.
>
> /Anders
>
>
> >
> > /Anders
> >
> >
> >
> >> But I guess something like that would fit into the same drawer as the
> >> which to hace a "configuration-check" mechanism that allows a plugin to
> >> validate the configuration used (Would really like to implement some
> >> validator and "best-practice" validator component guiding users on how
> to
> >> use the plugin)
> >>
> >> Chris
> >>
> >>
> >> 
> >> Von: anders.g.ham...@gmail.com  im Auftrag
> >> von Anders Hammar 
> >> Gesendet: Donnerstag, 12. Dezember 2013 11:37
> >> An: Maven Users List
> >> Betreff: Re: Painless way to update a frameworks group id?
> >>
> >> I don't think that will work. The "bad" deps are still used in compile
> >> time
> >> and only not used in runtime.
> >>
> >> The correct solution (until there are new releases that don't pull in
> the
> >> "bad" transitive deps) is to excluded them. And that probably can't be
> >> automated in any other way than providing means to detect them (the
> >> enforcer rule).
> >>
> >> What you could do is try this and release a beta or something and see
> what
> >> sort of problems people run into. Changing coordinates is always a
> >> problem.
> >>
> >> My two cents,
> >> /Anders
> >>
> >>
> >> On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz <
> >> christofer.d...@c-ware.de
> >> > wrote:
> >>
> >> > What do you think about this Option?
> >> >
> >> > I created a tool that mavenizes a non-maven Flex SDK and genereates
> all
> >> > sorts of maven artifacts ... one artifact that is generated is a
> Special
> >> > pom that contains only a dependency Management section that can be
> used
> >> to
> >> > automatically configure the Versions of dependencies in the Flex SDK
> >> ... I
> >> > could automatically generate dependency manangement entries for the
> old
> >> > Group id that set the dependencies to "provided". So as soon as
> someone
> >> > imports that pom containing the dependencyManagement entries for the
> >> good
> >> > artifacts, the "exclude" entries are automatically in place.
> >> >
> >> > Chris
> >> >
> >> >
> >> > 
> >> > Von: anders.g.ham...@gmail.com  im Auftrag
> >> von
> >> > Anders Hammar 
> >> > Gesendet: Donnerstag, 12. Dezember 2013 11:07
> >> > An: Maven Users List
> >> > Betreff: Re: Painless way to update a frameworks group id?
> >> >
> >> > AFAIK there is not painless way to solve this.
> >> >
> >> > What you could add to the docs is instructions on how to use an
> enforcer
> >> > rule to ensure that no "bad" libs are pulled in by accident (if the
> miss
> >> > some exclusion). Use the banned deps [1] rule.
> >> >
> >> > /Anders
> >> >
> >> > [1]
> >> >
> http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
> >> >
> >> >
> >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > >
> >> > >
> >> > > I am the current maintainer of the Flexmojos Maven Plugin and
> >> contributor
> >> > > to the Apache Flex Project.
> >> > >
> >> > > Currently I am working on a new Version of Flexmojos which is able
> to
> >> > work
> >> > > with Flex SDKs that have a groupId of org.apache.flex instead of the
> >> old
> >> > > com.adobe.flex. While building applications with the new groupId was
> >> no
> >> > big
> >> > > Problem, we are now facing a Problem, that I don't quite know how to
> >> > > elegantly solve it.
> >> > >
> >> > >
> >> > >
> >> > > Assuming I am building a Project and I switched the groupId of the
> >> Flex
> >> > > Framework to "org.apache.flex". As Long as I am building all
> >> artifacts in
> >> > > the Project this is fine. But as soon as I am using a Flex library
> >> that
> >> > was
> >> > > built for com.apache.flex Maven correctly adds that artifacts
> >> > dependencies
> >> > > to the build. Unfortunately this way I have several artifacts in my
> >> build
> >> > > twice ... once with com.adobe.flex and once with org.apache.flex
> >> groupId.
> >> > >
> >> > >
> >> > >
> >> > > Now I was suggesting to manually exclude Framework artifacts when
> >> using
> >> > an
> >> > > external lib, but I would like to automate this. Therefore I
> >> suggested to
> >> > > add all the org.apache.flex artifacts as com.adobe.flex artifacts,
> >> but to
> >> > > set the scope on These to "provided". But it still sort of doesn't
> >> f

Re: how to run compile and packaging before test?

2013-12-13 Thread Manfred Moser
The link to the free html and pdf books is now

http://books.sonatype.com

These books are cc licensed and we do take pull requests of enhancements.

The source is at

https://github.com/sonatype/maven-reference-en
https://github.com/sonatype/maven-example-en

I have created a patch for the Maven site that fixes the links and
attached it to

https://jira.codehaus.org/browse/MNGSITE-194

Feel free to apply the patch and push a new site out. Also let me know if
you need anything else so that the patch can be applied.

Regards

manfred

>> However, the http link to the book on sonatype.com is dead. It should be
>> updated.
>>
>
> Hm, ok. I asked Sonatype some time ago to fix that. I'll remind them.
>
> /Anders
>
>
>
>>
>> It would also be helpful for users who scan that page if the free books
>> were somehow better visually highlighted. Like a big green button that
>> says
>> "Free!" beside the corresponding book or whatever.
>>
>>
>>
>> On 12/13/2013 11:34 AM, Malte Skoruppa wrote:
>>
>>>
>>>  Meanwhile, one doesn't necessarily have to buy a book to learn about
>>> the
> Maven lifecycle. This is also explained on the website:
> http://maven.apache.org/guides/introduction/
> introduction-to-the-lifecycle.html
>
 Yes, but it doesn't go into enough details.

 The *free* books do.

>>>
>>> This actually surprised me. Free?
>>> Looking at the "Books and Resources" page more closely, I found but
>>> *one*
>>> book that is free, namely the "Better Builds with Maven" (2006, covers
>>> Maven 2.0.4 - i.e., rather old).
>>> For all the other books, there are Amazon (and similar) links.
>>>
>>> If these other books are also freely available, this should certainly
>>> be
>>> put forward more clearly on the page, with appropriate links.
>>>
>>> Apart from the books, the "Books and Resources" page links to a
>>> plethora
>>> of articles on this and that about Maven. But that is not what you'd
>>> call a
>>> structured introduction to Maven, let alone a "book". (Well, at least,
>>> that's not where I'd go digging if I wanted to find out more about,
>>> say,
>>> the build lifecycle. I'd go to the Guides index in that case. At least
>>> that's sorted by category.)
>>>
>>> On a sidenote, I also noticed that the page links to "JavaBlackBelt's
>>> Maven Exam" on javablackbelt.com under "Miscellaneous on Maven".
>>> However, javablackbelt.com does not exist anymore [1], and the "Maven
>>> Exam" link is dead. [2]
>>>
>>> [1] http://en.wikipedia.org/wiki/Javablackbelt
>>> [2] http://www.javablackbelt.com/QuestionnaireDefDisplay.wwa?
>>> questPublicId=01559
>>>
>>> ** 
>>>
>>>
>>
>> -
>> 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



AW: Painless way to update a frameworks group id?

2013-12-13 Thread Christofer Dutz
Good Idea ...

Unfortunately as we are not allowed to publish the Adobe artifacts (Flash 
Player / Air libs) we decided not to publish the Flex artifacts at all. Then a 
redirect seems rather problematic. Currently each user has to locally deploy 
the Flex SDK using a special tool in order to be on the safe side :-(

Chris

-Ursprüngliche Nachricht-
Von: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com] 
Gesendet: Freitag, 13. Dezember 2013 21:26
An: Maven Users List
Betreff: Re: Painless way to update a frameworks group id?

Just a guess:

* Deploy a new relocation pom at the old coordinates with a bigger version.
* Include this new relocation version.

Regards Mirko
--
Sent from my mobile
On Dec 12, 2013 1:26 PM, "Anders Hammar"  wrote:

> > Think some sort of "artifact-transformer" mechanism in Maven would 
> > be
> >> really cool ("Map the following groupId to otherGroupId").
> >
> >
> > There is some discussion around this feature for a future POM model. 
> > Any year now. :-)
> >
>
> Oh, I should prabably stress that this "discussion" is no promise for 
> this feature. It might require a change to the Maven repository structure.
>
> /Anders
>
>
> >
> > /Anders
> >
> >
> >
> >> But I guess something like that would fit into the same drawer as 
> >> the which to hace a "configuration-check" mechanism that allows a 
> >> plugin to validate the configuration used (Would really like to 
> >> implement some validator and "best-practice" validator component 
> >> guiding users on how
> to
> >> use the plugin)
> >>
> >> Chris
> >>
> >>
> >> 
> >> Von: anders.g.ham...@gmail.com  im 
> >> Auftrag von Anders Hammar 
> >> Gesendet: Donnerstag, 12. Dezember 2013 11:37
> >> An: Maven Users List
> >> Betreff: Re: Painless way to update a frameworks group id?
> >>
> >> I don't think that will work. The "bad" deps are still used in 
> >> compile time and only not used in runtime.
> >>
> >> The correct solution (until there are new releases that don't pull 
> >> in
> the
> >> "bad" transitive deps) is to excluded them. And that probably can't 
> >> be automated in any other way than providing means to detect them 
> >> (the enforcer rule).
> >>
> >> What you could do is try this and release a beta or something and 
> >> see
> what
> >> sort of problems people run into. Changing coordinates is always a 
> >> problem.
> >>
> >> My two cents,
> >> /Anders
> >>
> >>
> >> On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz < 
> >> christofer.d...@c-ware.de
> >> > wrote:
> >>
> >> > What do you think about this Option?
> >> >
> >> > I created a tool that mavenizes a non-maven Flex SDK and 
> >> > genereates
> all
> >> > sorts of maven artifacts ... one artifact that is generated is a
> Special
> >> > pom that contains only a dependency Management section that can 
> >> > be
> used
> >> to
> >> > automatically configure the Versions of dependencies in the Flex 
> >> > SDK
> >> ... I
> >> > could automatically generate dependency manangement entries for 
> >> > the
> old
> >> > Group id that set the dependencies to "provided". So as soon as
> someone
> >> > imports that pom containing the dependencyManagement entries for 
> >> > the
> >> good
> >> > artifacts, the "exclude" entries are automatically in place.
> >> >
> >> > Chris
> >> >
> >> >
> >> > 
> >> > Von: anders.g.ham...@gmail.com  im 
> >> > Auftrag
> >> von
> >> > Anders Hammar 
> >> > Gesendet: Donnerstag, 12. Dezember 2013 11:07
> >> > An: Maven Users List
> >> > Betreff: Re: Painless way to update a frameworks group id?
> >> >
> >> > AFAIK there is not painless way to solve this.
> >> >
> >> > What you could add to the docs is instructions on how to use an
> enforcer
> >> > rule to ensure that no "bad" libs are pulled in by accident (if 
> >> > the
> miss
> >> > some exclusion). Use the banned deps [1] rule.
> >> >
> >> > /Anders
> >> >
> >> > [1]
> >> >
> http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.htm
> l
> >> >
> >> >
> >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > >
> >> > >
> >> > > I am the current maintainer of the Flexmojos Maven Plugin and
> >> contributor
> >> > > to the Apache Flex Project.
> >> > >
> >> > > Currently I am working on a new Version of Flexmojos which is 
> >> > > able
> to
> >> > work
> >> > > with Flex SDKs that have a groupId of org.apache.flex instead 
> >> > > of the
> >> old
> >> > > com.adobe.flex. While building applications with the new 
> >> > > groupId was
> >> no
> >> > big
> >> > > Problem, we are now facing a Problem, that I don't quite know 
> >> > > how to elegantly solve it.
> >> > >
> >> > >
> >> > >
> >> > > Assuming I am building a Project and I switched the groupId of 
> >> > > the
> >> Flex
> >> > > Framework to "org.apache.flex". As Long as I am building all
> >> artifacts in
> >> > > the Project this is fine. But as soon as I am using a Flex 
> >> >

downloading artifacts from maven repo

2013-12-13 Thread Alejandro . Endo
I am trying to create a maven project that needs to package a bunch of 
maven artifacts to finally invoke jwrapper using the exec-maven-plugin. 
Because this project is mostly an integration task (jars are already 
compiled and deploy in a maven repo) i am wondering what are the tools 
available to download artifacts from a repo. Something like 
dependency:copy-dependencies or dependency:get but that would let me work 
in a more generic way such as "download every jar under 
com.mycompany.projectA.* and put it in target/libA"
Having an explicit list of dependencies in the pom itself is not an option 
since 1) there are hundreds of jars 2) it introduces having to maintain a 
list of jars to use. I want to use instead "coordinate wildcards" to 
download whole areas of the repo.

I was planning on writing such a library (which later could be easily made 
into a maven plugin) but i wanted to know if there is something similar 
already in existence.

Apart from the question of whether such a thing exists, I also want to 
know what are the philosophical arguments against it, if any. I have heard 
here talk about anything remotely touching integration should not be a job 
for maven, is that really the case? in this case i am still building an 
application, just not by compiling code but by integrating multiple jars

Any thoughts?

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.


Re: downloading artifacts from maven repo

2013-12-13 Thread Holger Hoffstätte
On Fri, 13 Dec 2013 16:35:04 -0500, Alejandro.Endo wrote:

> I am trying to create a maven project that needs to package a bunch of
> maven artifacts to finally invoke jwrapper using the exec-maven-plugin.
[..]
> I was planning on writing such a library (which later could be easily
> made into a maven plugin) but i wanted to know if there is something
> similar already in existence.

Yes: http://eclipse.org/aether/

Don't even start thinking of reinventing that particular wheel.

-h


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



Re: AW: Painless way to update a frameworks group id?

2013-12-13 Thread Mirko Friedenhagen
Christofer,

this depends on your definition of "we" :-). In a company context with an
internal repository manager you might deploy a "vendor" release into your
patched thirdparty repository. Or tell your users to manually install the
patched version. I did similar stuff for this strange
m2e-maven-plugin-configuration-holder (
http://stackoverflow.com/questions/7905501/get-rid-of-pom-not-found-warning-for-org-eclipse-m2elifecycle-mapping
)

Regards Mirko
-- 
Sent from my mobile
On Dec 13, 2013 10:13 PM, "Christofer Dutz" 
wrote:

> Good Idea ...
>
> Unfortunately as we are not allowed to publish the Adobe artifacts (Flash
> Player / Air libs) we decided not to publish the Flex artifacts at all.
> Then a redirect seems rather problematic. Currently each user has to
> locally deploy the Flex SDK using a special tool in order to be on the safe
> side :-(
>
> Chris
>
> -Ursprüngliche Nachricht-
> Von: Mirko Friedenhagen [mailto:mfriedenha...@gmail.com]
> Gesendet: Freitag, 13. Dezember 2013 21:26
> An: Maven Users List
> Betreff: Re: Painless way to update a frameworks group id?
>
> Just a guess:
>
> * Deploy a new relocation pom at the old coordinates with a bigger version.
> * Include this new relocation version.
>
> Regards Mirko
> --
> Sent from my mobile
> On Dec 12, 2013 1:26 PM, "Anders Hammar"  wrote:
>
> > > Think some sort of "artifact-transformer" mechanism in Maven would
> > > be
> > >> really cool ("Map the following groupId to otherGroupId").
> > >
> > >
> > > There is some discussion around this feature for a future POM model.
> > > Any year now. :-)
> > >
> >
> > Oh, I should prabably stress that this "discussion" is no promise for
> > this feature. It might require a change to the Maven repository
> structure.
> >
> > /Anders
> >
> >
> > >
> > > /Anders
> > >
> > >
> > >
> > >> But I guess something like that would fit into the same drawer as
> > >> the which to hace a "configuration-check" mechanism that allows a
> > >> plugin to validate the configuration used (Would really like to
> > >> implement some validator and "best-practice" validator component
> > >> guiding users on how
> > to
> > >> use the plugin)
> > >>
> > >> Chris
> > >>
> > >>
> > >> 
> > >> Von: anders.g.ham...@gmail.com  im
> > >> Auftrag von Anders Hammar 
> > >> Gesendet: Donnerstag, 12. Dezember 2013 11:37
> > >> An: Maven Users List
> > >> Betreff: Re: Painless way to update a frameworks group id?
> > >>
> > >> I don't think that will work. The "bad" deps are still used in
> > >> compile time and only not used in runtime.
> > >>
> > >> The correct solution (until there are new releases that don't pull
> > >> in
> > the
> > >> "bad" transitive deps) is to excluded them. And that probably can't
> > >> be automated in any other way than providing means to detect them
> > >> (the enforcer rule).
> > >>
> > >> What you could do is try this and release a beta or something and
> > >> see
> > what
> > >> sort of problems people run into. Changing coordinates is always a
> > >> problem.
> > >>
> > >> My two cents,
> > >> /Anders
> > >>
> > >>
> > >> On Thu, Dec 12, 2013 at 11:24 AM, Christofer Dutz <
> > >> christofer.d...@c-ware.de
> > >> > wrote:
> > >>
> > >> > What do you think about this Option?
> > >> >
> > >> > I created a tool that mavenizes a non-maven Flex SDK and
> > >> > genereates
> > all
> > >> > sorts of maven artifacts ... one artifact that is generated is a
> > Special
> > >> > pom that contains only a dependency Management section that can
> > >> > be
> > used
> > >> to
> > >> > automatically configure the Versions of dependencies in the Flex
> > >> > SDK
> > >> ... I
> > >> > could automatically generate dependency manangement entries for
> > >> > the
> > old
> > >> > Group id that set the dependencies to "provided". So as soon as
> > someone
> > >> > imports that pom containing the dependencyManagement entries for
> > >> > the
> > >> good
> > >> > artifacts, the "exclude" entries are automatically in place.
> > >> >
> > >> > Chris
> > >> >
> > >> >
> > >> > 
> > >> > Von: anders.g.ham...@gmail.com  im
> > >> > Auftrag
> > >> von
> > >> > Anders Hammar 
> > >> > Gesendet: Donnerstag, 12. Dezember 2013 11:07
> > >> > An: Maven Users List
> > >> > Betreff: Re: Painless way to update a frameworks group id?
> > >> >
> > >> > AFAIK there is not painless way to solve this.
> > >> >
> > >> > What you could add to the docs is instructions on how to use an
> > enforcer
> > >> > rule to ensure that no "bad" libs are pulled in by accident (if
> > >> > the
> > miss
> > >> > some exclusion). Use the banned deps [1] rule.
> > >> >
> > >> > /Anders
> > >> >
> > >> > [1]
> > >> >
> > http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.htm
> > l
> > >> >
> > >> >
> > >> > On Wed, Dec 11, 2013 at 9:01 AM, Christofer Dutz
> > >> > wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > >
> > >> > >
> > >> > > I am the current mainta