Re: mojo help
Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) You should start by copying wagon:download and tweak that from there -Stephen On 25 May 2010 05:40, Lachlan Deck lachlan.d...@gmail.com wrote: Anyone more familiar with mojo development able to answer? Or am I on the wrong list? On 25/05/2010, at 2:00 PM, Dan Tran wrote: I would suggest you cut and paste wagon:download code then That doesn't help answer my questions below. On Mon, May 24, 2010 at 6:54 PM, Lachlan Deck lachlan.d...@gmail.com wrote: Hi there, I'm trying to get a very simple utility working which downloads a zip file for subsequent use. I can successfully do this via an execution in the pom[1] but can't seem to get it working programatically (which I need to be able to run the mojo independently). In order to create a stand alone utility that could run outside a project (mvn some.groupId:project-id:downloadzip ...) I seem to be missing something. i.e., when I've got the mojo with @requiresProject false the 'settings' and 'wagonManager' in AbstractMojo aren't initialised. Thus when I call createWagon(serverId, url) I get a NullPointerException: org.apache.maven.plugin.MojoExecutionException: Unable to create a Wagon instance for scp://foo.bar.net/ at org.codehaus.mojo.wagon.AbstractWagonMojo.createWagon(AbstractWagonMojo:83) ... Caused by: java.lang.NullPointerException at org.apache.maven.artifact.manager.DefaultWagonManager.getWagon(DefaultWagonManager.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getWagon(DefaultWagonManager.java:128) at org.codehaus.mojo.wagon.shared.WagonUtils.createWagon(AbstractWagonMojo:53) at org.codehaus.mojo.wagon.AbstractWagonMojo.createWagon(AbstractWagonMojo:79) ... 21 more Essentially, how do I utilise the scp wagon programatically? - if the mojo is running outside a project, how do @component annotated fields (like Settings or WagonManager) get populated? etc Thanks! with regards, -- Lachlan Deck [1] build ... extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh/artifactId version1.0-beta-6/version /extension /extensions plugins ... plugin groupIdorg.codehaus.mojo/groupId artifactIdwagon-maven-download/artifactId version1.0-beta-3/version executions execution idfoo/id phaseverify/phase goals goaldownload/goal /goals configuration serverIdbar/serverId urlscp://bar.foo.net/ /url fromDir/some/dir//fromDir includesmyzip.zip/includes toDir/tmp/toDir /configuration /execution /executions /plugin /plugins /build - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
Lachlan Deck wrote: I'm not sure I understand your question? My dependencies already contains wagon-maven-plugin which is a very bad idea unless you intend to run in Maven 3 only. Due to classloader constraints in M2 you should never use a different plugin as dependency. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
See http://old.nabble.com/Re%3A-Trying-to-extend-AbstractAssemblyMojo-p28662893.html On 25 May 2010 07:41, Lachlan Deck lachlan.d...@gmail.com wrote: On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
when @parameter is not initialized, it means you need to pass in some value via system properties if allows ( -Dxuy=... ) or pom configuration. Picking a medium complex mojo like wagon plugin to twist it is quite trouble some. I would strongly suggest to read up artifact like http://maven.apache.org/guides/introduction/introduction-to-plugins.html first -D On Mon, May 24, 2010 at 11:41 PM, Lachlan Deck lachlan.d...@gmail.com wrote: On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - 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: mojo help
On 25/05/2010, at 4:26 PM, Jörg Schaible wrote: Lachlan Deck wrote: I'm not sure I understand your question? My dependencies already contains wagon-maven-plugin which is a very bad idea unless you intend to run in Maven 3 only. Nup. 2.1.0 atm. Due to classloader constraints in M2 you should never use a different plugin as dependency. Ah, right. So the annotations don't work unless those classes are in your plugin project. That's a real bummer. Moving forward... thanks. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
I think that it's because he's tried to extend WagonMojo and had wagon-maven-plugin as a dependency and therefore hit the maven-plugin-plugin not merging plugin metadata design issue ;-) -Stephen On 25 May 2010 08:10, Dan Tran dant...@gmail.com wrote: when @parameter is not initialized, it means you need to pass in some value via system properties if allows ( -Dxuy=... ) or pom configuration. Picking a medium complex mojo like wagon plugin to twist it is quite trouble some. I would strongly suggest to read up artifact like http://maven.apache.org/guides/introduction/introduction-to-plugins.html first -D On Mon, May 24, 2010 at 11:41 PM, Lachlan Deck lachlan.d...@gmail.com wrote: On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - 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: mojo help
On 25 May 2010 07:26, Jörg Schaible joerg.schai...@gmx.de wrote: Lachlan Deck wrote: I'm not sure I understand your question? My dependencies already contains wagon-maven-plugin which is a very bad idea unless you intend to run in Maven 3 only. Due to classloader constraints in M2 you should never use a different plugin as dependency. It's not just classloader constraints. Maven-plugin-plugin will not merge the plugin metadata so if you extend a mojo from a different plugin all it's @parameter fields will be null. The classloader issue will bite you in the ass if you are just using other classes from the maven-plugin or if you hand craft the plugin metadata to work around the issue with maven-plugin-plugin (unless you run Maven 3) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
what I did with my maven-plugins is that I unpacked the source file where the javadoc annotations are and included this into sources. but excluded that source from being packaged. I am not sure if there are more complications . . . regards Kristian On Tue, May 25, 2010 at 12:38 PM, Stephen Connolly steph...@apache.org wrote: See http://old.nabble.com/Re%3A-Trying-to-extend-AbstractAssemblyMojo-p28662893.html On 25 May 2010 07:41, Lachlan Deck lachlan.d...@gmail.com wrote: On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Kristian Meier + Saumya Sharma + Sanuka Meier Vadakkethu House, Edayanmula West PO - 689532, Pathanamthitta District, Kerala, INDIA tel: +91 468 2319577 protect your privacy while searching the net: www.ixquick.com _=_ q(-_-)p '_) (_` /__/ \ _(_ / )_ (__\_\_|_/__) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mojo help
you'll hit classloader issues. best solution is just to copy whole the maven-plugin you want to extend and delete the stuff you don't want. to summarize the issues: 1. Classloader issues with maven-plugin dependencies (i.e. in Maven 2.x the first version of any ___maven-plugin___ loaded in the reactor is the only version loaded) 2. Plugin metadata issues (i.e. maven-plugin-plugin does not merge metadata from maven-plugin dependencies) So the end result is keep the packagingmaven-plugin/packaging modules as small as possible, essentially just enough to hook into maven, and have them depend on a packagingjar/packaging module which does the heavy lifting (jar dependencies are not subject to the classloader issues of maven-plugin dependencies that Maven 2.x has)... oh and bonus, you are now not tied to Maven as a build tool. Maven Best Practice #1 Do not tightly tie your build to a specific build tool. We believe that Maven is the best Java build tool out there, but competition is good and helps us make things better, so we'd like it to be as easy as possible to migrate away from Maven so that either you can realise that we are the best and switch back, or we sit up and take notice and improve ourselves until you switch back. -Stephen On 25 May 2010 08:16, kristian m.krist...@web.de wrote: what I did with my maven-plugins is that I unpacked the source file where the javadoc annotations are and included this into sources. but excluded that source from being packaged. I am not sure if there are more complications . . . regards Kristian On Tue, May 25, 2010 at 12:38 PM, Stephen Connolly steph...@apache.org wrote: See http://old.nabble.com/Re%3A-Trying-to-extend-AbstractAssemblyMojo-p28662893.html On 25 May 2010 07:41, Lachlan Deck lachlan.d...@gmail.com wrote: On 25/05/2010, at 4:11 PM, Stephen Connolly wrote: Dan Tran is pretty darn familiar with mojo development (#2 on http://www.ohloh.net/p/mojo/contributors) Apologies Dan :) I just wasn't getting it. You should start by copying wagon:download and tweak that from there I'm still wondering why various @parameters weren't being initialised - but thanks. I'll start from there. with regards, -- Lachlan Deck - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Kristian Meier + Saumya Sharma + Sanuka Meier Vadakkethu House, Edayanmula West PO - 689532, Pathanamthitta District, Kerala, INDIA tel: +91 468 2319577 protect your privacy while searching the net: www.ixquick.com _=_ q(-_-)p '_) (_` /__/ \ _(_ / )_ (__\_\_|_/__) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Why is maven trying to download installed jars?
A question here... Let's say that my project depends on project A that depends on project B. Project A has a correct pom but project B does not. Can I do something that makes maven generate a pom for project B when looking for dependencies? /Ludwig -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: den 25 maj 2010 06:48 To: Maven Users List Subject: Re: Why is maven trying to download installed jars? Please remember that this generated minimal pom just holds the required GAV info. There is no info about dependencies, which makes it...well, minimal. Maven will then not be able to help you with transitive deps and dependency management. So, you should always create a correct pom (including dependency info) IMO. /Anders On Mon, May 24, 2010 at 23:13, Wayne Fay wayne...@gmail.com wrote: So is this flag (generatePom) not default because of a bug or should I just add it every time I add file to the repository? It is the default in sufficiently recent versions of the install plugin. To be safe, just add the -D flag when you install artifacts locally. Wayne - 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: Why is maven trying to download installed jars?
No, there is currently no such feature out-of-the-box. There are several tools that can help you though. I use CDA ( http://www.dependency-analyzer.org) and jaranalyzer ( http://www.kirkk.com/main/Main/JarAnalyzer). /Anders On Tue, May 25, 2010 at 09:26, Ludwig Magnusson lud...@itcatapult.comwrote: A question here... Let's say that my project depends on project A that depends on project B. Project A has a correct pom but project B does not. Can I do something that makes maven generate a pom for project B when looking for dependencies? /Ludwig -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: den 25 maj 2010 06:48 To: Maven Users List Subject: Re: Why is maven trying to download installed jars? Please remember that this generated minimal pom just holds the required GAV info. There is no info about dependencies, which makes it...well, minimal. Maven will then not be able to help you with transitive deps and dependency management. So, you should always create a correct pom (including dependency info) IMO. /Anders On Mon, May 24, 2010 at 23:13, Wayne Fay wayne...@gmail.com wrote: So is this flag (generatePom) not default because of a bug or should I just add it every time I add file to the repository? It is the default in sufficiently recent versions of the install plugin. To be safe, just add the -D flag when you install artifacts locally. Wayne - 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: Sharing a version among different modules
I keep all version numbers in the dependencyManagement section of my
parent POM, which is different from my aggregator POM and is parent to
the aggregator and all its modules. In this way I specify each version
exactly once. Something like:
dependencyManagement
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
version140/version
/dependency
/dependencyManagement
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
dependency
groupId${project.parent.groupId}/groupId
artifactIdsibling-one/artifactId
version${project.parent.version}/version
/dependency
Thanks a lot Kristian, this indeed improves the situation a *lot*. Instead of
10 references for 3 modules, I am now able to reduce it to:
1 + (1 per module)
However, I'll continue my quest to further reduction of replication, as my
ultimate goal is still to have the version number in one place. Perhaps
XInclude or so will do the trick.
Thanks heaps!
Ernst
-
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: Sharing a version among different modules
Thanks, Nicola. Interesting alternative!
So if I understand you correctly, you have version numbers on the
aggregator and on modules below that, but you just keep those to a
fixed vale (say 0) and use the root parent version to the outside
world?
Cheers,
Ernst de Haan
Op 25 mei 2010 om 14:28 heeft Nicola Musatti nicola.musa...@objectway.it
het volgende geschreven:\
I keep all version numbers in the dependencyManagement section of my
parent POM, which is different from my aggregator POM and is parent
to the aggregator and all its modules. In this way I specify each
version exactly once. Something like:
dependencyManagement
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
version140/version
/dependency
/dependencyManagement
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent
pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
dependency
groupId${project.parent.groupId}/groupId
artifactIdsibling-one/artifactId
version${project.parent.version}/version
/dependency
Thanks a lot Kristian, this indeed improves the situation a *lot*.
Instead of 10 references for 3 modules, I am now able to reduce it
to:
1 + (1 per module)
However, I'll continue my quest to further reduction of
replication, as my ultimate goal is still to have the version
number in one place. Perhaps XInclude or so will do the trick.
Thanks heaps!
Ernst
-
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: Sharing a version among different modules
I use this method described by Nicole as well. Its described in great detail in
the definitive guide.
http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependencies.html
-Original Message-
From: Ernst de Haan [mailto:er...@ernstdehaan.com]
Sent: Tuesday, May 25, 2010 8:58 AM
To: Maven Users List
Cc: Maven Users List
Subject: Re: Sharing a version among different modules
Thanks, Nicola. Interesting alternative!
So if I understand you correctly, you have version numbers on
the aggregator and on modules below that, but you just keep
those to a fixed vale (say 0) and use the root parent
version to the outside world?
Cheers,
Ernst de Haan
Op 25 mei 2010 om 14:28 heeft Nicola Musatti
nicola.musa...@objectway.it het volgende geschreven:\
I keep all version numbers in the dependencyManagement
section of my
parent POM, which is different from my aggregator POM and
is parent to
the aggregator and all its modules. In this way I specify
each version
exactly once. Something like:
dependencyManagement
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
version140/version
/dependency
/dependencyManagement
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent
pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
dependency
groupId${project.parent.groupId}/groupId
artifactIdsibling-one/artifactId
version${project.parent.version}/version
/dependency
Thanks a lot Kristian, this indeed improves the situation
a *lot*.
Instead of 10 references for 3 modules, I am now able to reduce it
to:
1 + (1 per module)
However, I'll continue my quest to further reduction of
replication,
as my ultimate goal is still to have the version number in
one place.
Perhaps XInclude or so will do the trick.
Thanks heaps!
Ernst
-
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: Sharing a version among different modules
Ernst de Haan wrote:
Thanks, Nicola. Interesting alternative!
So if I understand you correctly, you have version numbers on the
aggregator and on modules below that, but you just keep those to a
fixed vale (say 0) and use the root parent version to the outside
world?
No, once version numbers are specified in your parent POM's
dependencyManagement element you don't need to specify them again. To
give an example in a module POM I would specify a dependency to
bcprov-jdk13 as
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
/dependency
/dependencies
Cheers,
Nicola
Cheers,
Ernst de Haan
Op 25 mei 2010 om 14:28 heeft Nicola Musatti
nicola.musa...@objectway.it het volgende geschreven:\
I keep all version numbers in the dependencyManagement section of my
parent POM, which is different from my aggregator POM and is parent
to the aggregator and all its modules. In this way I specify each
version exactly once. Something like:
dependencyManagement
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
version140/version
/dependency
/dependencyManagement
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
dependency
groupId${project.parent.groupId}/groupId
artifactIdsibling-one/artifactId
version${project.parent.version}/version
/dependency
Thanks a lot Kristian, this indeed improves the situation a *lot*.
Instead of 10 references for 3 modules, I am now able to reduce it to:
1 + (1 per module)
However, I'll continue my quest to further reduction of replication,
as my ultimate goal is still to have the version number in one
place. Perhaps XInclude or so will do the trick.
Thanks heaps!
Ernst
-
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
[ANN] Sonar 2.1 released
The Sonar Team is pleased to announce the release of Sonar 2.1. There are two key features in this new version, both related to architecture : * A service to display the libraries cartography : what project is using which library and how ? * New coding rules on Squid to detect dead methods and calls to deprecated methods To find out more on those 2 features, you can explore them in screenshots [1]. On top of those 2 features, the new version also contains 50 improvements and bug-fixes [2]. To enjoy the new version, you can download it [3] straight away. - The Sonar team Links [1] Sonar 2.1 in screenshots : http://www.sonarsource.org/sonar-2-1-in-screenshots/ [2] Release notes : http://www.sonarsource.org/downloads/#2.1 [3] Download : http://sonar.codehaus.org/downloads -- View this message in context: http://old.nabble.com/-ANN--Sonar-2.1-released-tp28668257p28668257.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: POM is invalid...
On 05/24/2010 07:21 PM, Wayne Fay wrote:
[DEBUG] For dependency Dependency {groupId=javafx, artifactId=javafxc,
version=1.3.0, type=jar}: system-scoped dependency must specify an
absolute path systemPath.
Don't use system scope and thus don't use systemPath.
That is not that easy. I depend on JavaFX jars. And it is additional
work to add those (that are about 15) to the repository for every developer.
Setting a system property (javafx.home) is much easier
I think I have found the bug report:
http://jira.codehaus.org/browse/MNG-4148
Johannes
Use mvn:install install-file to put the jar where it belongs in the
local Maven repo cache, and use a proper compile (or whatever)
dependency scope.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Johannes Schneider - blog.cedarsoft.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: POM is invalid...
I don't know anything about javafx but I did find this...
http://blogs.jfrog.org/2009/05/maven-and-javafx-story-of-twitterfx-pom.html
Not sure if it will help any.
-Original Message-
From: Johannes Schneider [mailto:maili...@cedarsoft.com]
Sent: Tuesday, May 25, 2010 9:22 AM
To: users@maven.apache.org
Subject: Re: POM is invalid...
On 05/24/2010 07:21 PM, Wayne Fay wrote:
[DEBUG] For dependency Dependency {groupId=javafx,
artifactId=javafxc,
version=1.3.0, type=jar}: system-scoped dependency must specify an
absolute path systemPath.
Don't use system scope and thus don't use systemPath.
That is not that easy. I depend on JavaFX jars. And it is
additional work to add those (that are about 15) to the
repository for every developer.
Setting a system property (javafx.home) is much easier
I think I have found the bug report:
http://jira.codehaus.org/browse/MNG-4148
Johannes
Use mvn:install install-file to put the jar where it belongs in the
local Maven repo cache, and use a proper compile (or whatever)
dependency scope.
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Johannes Schneider - blog.cedarsoft.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: Chaining Maven goals of different Base Directories
1.) and 2.) are different projects. There are much more projects in 'myproject', so I can´t execute mvn on 'myproject' (without deleting the other projects from my myproject pom), because I don´t want the other projects to be build. Daniel P.S.: I don´t think it makes any differences, but I am using m2e. 2010/5/19 Jesse Farinacci jie...@gmail.com Hi Daniel, On Wed, May 19, 2010 at 9:47 AM, Daniel Hoffmann biggibig...@googlemail.com wrote: 1.) myproject/makewar clean install 2.) myproject/makeear clean install cargo:deploy Daniel Why not attach cargo:deploy to the deploy phase and then call mvn clean deploy? -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Chaining Maven goals of different Base Directories
Profiles to the rescue ;-) Define a profile in the top-level pom containing just the the war and ear modules in the modules/ section. -Peter Daniel Hoffmann-6 wrote: 1.) and 2.) are different projects. There are much more projects in 'myproject', so I can´t execute mvn on 'myproject' (without deleting the other projects from my myproject pom), because I don´t want the other projects to be build. Daniel P.S.: I don´t think it makes any differences, but I am using m2e. 2010/5/19 Jesse Farinacci jie...@gmail.com Hi Daniel, On Wed, May 19, 2010 at 9:47 AM, Daniel Hoffmann biggibig...@googlemail.com wrote: 1.) myproject/makewar clean install 2.) myproject/makeear clean install cargo:deploy Daniel Why not attach cargo:deploy to the deploy phase and then call mvn clean deploy? -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://old.nabble.com/Chaining-Maven-goals-of-different-Base-Directories-tp28608528p28670270.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: POM is invalid...
That is not that easy. I depend on JavaFX jars. And it is additional work to add those (that are about 15) to the repository for every developer. Setting a system property (javafx.home) is much easier The best solution is to get the JavaFX jars into Central or another Maven repository. Spend some of your energy on that... Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: POM is invalid...
That is not that easy. I depend on JavaFX jars. And it is additional work to add those (that are about 15) to the repository for every developer. Setting a system property (javafx.home) is much easier The best solution is to get the JavaFX jars into Central or another Maven repository. Spend some of your energy on that... True. We had the same problem with Android and hope to get into central soon. In the meantime I wrote a tool that deploys a whole bunch of jars. You can follow the pattern I used to create your own for javafx. http://github.com/mosabua/maven-android-sdk-deployer The flex mojos guys have another tool that might be even better that you can use too. Check out the bundle publisher maven plugin. More here https://docs.sonatype.org/display/FLEXMOJOS/Installing+Flex+SDK+into+maven+repository manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dependency analysis through wars
I'm trying to perform an analysis of the entire dependency tree for a large set of projects with deep transitive dependencies. Some of the dependencies at various levels are war type projects. The dependency plugin appears to stop at war projects as if they have no dependencies of their own. Does anyone have suggestions as to how I can build a full dependency tree, including war dependencies and their transitive dependencies? I'm not opposed to building a custom plugin, but advice regarding how it should be done would be very welcome. Thanks. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28672012.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: Dependency analysis through wars
at various levels are war type projects. The dependency plugin appears to stop at war projects as if they have no dependencies of their own. Does anyone have suggestions as to how I can build a full dependency tree, Could you temporarily change the packaging to jar for those war projects, just to get past the issue so you could complete your analysis, and then change them back? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
I don't think I can do that easily since that would require rebuilding and redeploying the modified projects as the new packaging type. Maybe I could fetch all of the dependency POMs with something like go-offline and modify them in my local repository? Yuck. I hope there is a nicer way, but I'll consider this if there are no alternatives. I'm thinking that modifying the existing dependency plugin tree builder code might be a better solution. Wayne Fay wrote: at various levels are war type projects. The dependency plugin appears to stop at war projects as if they have no dependencies of their own. Does anyone have suggestions as to how I can build a full dependency tree, Could you temporarily change the packaging to jar for those war projects, just to get past the issue so you could complete your analysis, and then change them back? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28672240.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
cargo-maven2-plugin, java.lang.ClassNotFoundException: org.mortbay.jetty.Server
Hi guys, I have a problem! I'm trying start a jetty6x embedded with the maven using the cargo-maven2-plugin, but, when i execute the command: mvn cargo:start , it throw a exception: [INFO] Trace org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 6.x Embedded container. at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:168) ... Caused by: org.codehaus.cargo.container.ContainerException: Failed to create Jetty Server instance at org.codehaus.cargo.container.jetty.internal.AbstractJettyEmbeddedLocalContainer.createServerObject(AbstractJettyEmbeddedLocalContainer.java:78) Caused by: java.lang.ClassNotFoundException: org.mortbay.jetty.Server at java.net.URLClassLoader$1.run(URLClassLoader.java:202) My configuration in the pom.xml contains: plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.0/version configuration container containerIdjetty6x/containerId typeembedded/type /container /configuration /plugin Anyone know what's the problem? att, -- Everton Cardoso http://vertocardoso.wordpress.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Sharing a version among different modules
Nicola and Todd,
This is *exactly* what I was looking for! The article Todd mentioned
explains it very well, both the challenges and the solutions.
Cheers!
Ernst de Haan
Op 25 mei 2010 om 15:03 heeft Thiessen, Todd (Todd) tthies...@avaya.com
het volgende geschreven:\
I use this method described by Nicole as well. Its described in
great detail in the definitive guide.
http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependencies.html
-Original Message-
From: Ernst de Haan [mailto:er...@ernstdehaan.com]
Sent: Tuesday, May 25, 2010 8:58 AM
To: Maven Users List
Cc: Maven Users List
Subject: Re: Sharing a version among different modules
Thanks, Nicola. Interesting alternative!
So if I understand you correctly, you have version numbers on
the aggregator and on modules below that, but you just keep
those to a fixed vale (say 0) and use the root parent
version to the outside world?
Cheers,
Ernst de Haan
Op 25 mei 2010 om 14:28 heeft Nicola Musatti
nicola.musa...@objectway.it het volgende geschreven:\
I keep all version numbers in the dependencyManagement
section of my
parent POM, which is different from my aggregator POM and
is parent to
the aggregator and all its modules. In this way I specify
each version
exactly once. Something like:
dependencyManagement
dependencies
dependency
groupIdbouncycastle/groupId
artifactIdbcprov-jdk13/artifactId
version140/version
/dependency
/dependencyManagement
dependencyManagement is a direct child of the project element.
Cheers,
Nicola Musatti
Ernst de Haan wrote:
- in the parent pom.xml, to denote the project version
you need this
- in each module, to denote the module version
just leave out the version and it will inherit it from the parent
pom
- in each module's reference to the parent
you need this
- in each module's reference to a sibling
dependency
groupId${project.parent.groupId}/groupId
artifactIdsibling-one/artifactId
version${project.parent.version}/version
/dependency
Thanks a lot Kristian, this indeed improves the situation
a *lot*.
Instead of 10 references for 3 modules, I am now able to reduce it
to:
1 + (1 per module)
However, I'll continue my quest to further reduction of
replication,
as my ultimate goal is still to have the version number in
one place.
Perhaps XInclude or so will do the trick.
Thanks heaps!
Ernst
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency analysis through wars
For now, my plan is to : 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for the top-level POM 2. Traverse the tree and find each war Node 3. Serialize the node tree to disk 4. Separately run the dependency node serializer on each of the war projects found in step 2. 5. Deserialize all of the separate trees and assemble an aggregate dependency node tree. I'll wait to see if I'm missing some sort of filter configuration that's simply chucking out war dependency results, but I have a suspicion that Maven just doesn't resolve transitive war dependencies and that it would take a lot of work to make it do so. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.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: cargo-maven2-plugin, java.lang.ClassNotFoundException: org.mortbay.jetty.Server
Hi guys, I was looked the maven-jetty-plugin and i discovered that it was possible running in daemon mode. That it solves my problem already that i want to start the jetty before of execute the integration tests. [...] execution idstart-jetty/id phasepre-integration-test/phase goals goalrun/goal /goals configuration daemontrue/daemon /configuration /execution [...] On Tue, May 25, 2010 at 1:06 PM, Everton Cardoso ercard...@gmail.comwrote: Hi guys, I have a problem! I'm trying start a jetty6x embedded with the maven using the cargo-maven2-plugin, but, when i execute the command: mvn cargo:start , it throw a exception: [INFO] Trace org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 6.x Embedded container. at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:168) ... Caused by: org.codehaus.cargo.container.ContainerException: Failed to create Jetty Server instance at org.codehaus.cargo.container.jetty.internal.AbstractJettyEmbeddedLocalContainer.createServerObject(AbstractJettyEmbeddedLocalContainer.java:78) Caused by: java.lang.ClassNotFoundException: org.mortbay.jetty.Server at java.net.URLClassLoader$1.run(URLClassLoader.java:202) My configuration in the pom.xml contains: plugin groupIdorg.codehaus.cargo/groupId artifactIdcargo-maven2-plugin/artifactId version1.0/version configuration container containerIdjetty6x/containerId typeembedded/type /container /configuration /plugin Anyone know what's the problem? att, -- Everton Cardoso http://vertocardoso.wordpress.com att, -- Everton Cardoso http://vertocardoso.wordpress.com
Re: Dependency analysis through wars
On 26 May 2010 01:02, leonfranzen leon_fran...@tvworks.com wrote: For now, my plan is to : 1. Build the DependencyNode tree with the maven DependencyTreeBuilder for the top-level POM 2. Traverse the tree and find each war Node 3. Serialize the node tree to disk 4. Separately run the dependency node serializer on each of the war projects found in step 2. 5. Deserialize all of the separate trees and assemble an aggregate dependency node tree. I'll wait to see if I'm missing some sort of filter configuration that's simply chucking out war dependency results, but I have a suspicion that Maven just doesn't resolve transitive war dependencies and that it would There is a components.xml that defines the war packaging. in that components.xml it says that war is not a classpath dependency type (which is correct because war files usually contain their dependencies), so the net result is that when you build the classpath from the list of dependencies, the transitive deps of war files will be ignored by design. But AFAIK dependency:tree will show those deps take a lot of work to make it do so. -- View this message in context: http://old.nabble.com/Dependency-analysis-through-wars-tp28672012p28674916.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
