Re: resources are not aggregated from parent to child pom
Maven is almost always right. Figure out why your methodology is not following Best Practices and change the way that you work so that maven does it for you automatically. You can fight Maven as much as you want but it will always win. If you can identify why you are building an application that is so unusual that no one else has your workflow, then you may be able to get a solution. In most cases, the application is pretty normal, it is the newbee's workflow that is broken. If you are pioneering some new application platform, you may have a problem but I think that I have seen ejbs with dependent libraries being used in applications before. Mavenize your workflow. I hope that this helps. Ron On 04/10/2010 6:49 AM, Caoilte O'Connor wrote: It bites in quite a lot of places. I wanted to define one execution of the build-helper-maven-plugin in a parent pom and another in one of it's children then have the two merged together. However, Maven overrode the parent configuration in the child. Given that some sections of the pom (eg dependencies, properties) merge so seamlessly it is disappointing to discover sections which don't. Perhaps future versions of Maven will improve things. c On Sat, Oct 2, 2010 at 3:41 PM, Marshall Schorm...@schor.com wrote: On 10/2/2010 7:42 AM, Benjamin Bentmann wrote: Xavier D. wrote: My pom structure is: pom.xml has a parent: parent-pom.xml. Both have aresourcessection to include files. The (child) pom.xml is executed directly and has the effect of only copying the child's resources. Commenting out this resource section, results in the parent's resources being copied. This is expected behavior,resources given in a child POM are not merged withresources in the parent but completely override those. I'm curious as to why this design decision was taken, versus an approach which allows merging, or perhaps some kind of user (pom - specified) choice. I was bitten by this also. -Marshall Schor Benjamin - 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: Company-wide settings
On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell ssh...@gmail.com wrote: The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Multiple projects - one artifact
Hello, is it possible to build one artifact out of multiple projects. We are trying to modularize the development. Example: MyProject |-- core | |--api | |--impl | |--web |-- users | |--api | |--impl | |--web |-- admin | |--api | |--impl | |--web this should results in the following ear file myproject.ear |--lib/myproject-api.jar (the entity classes, service interfaces, etc) |--myproject-impl.ear (the ejb module) |--myproject-web.ear (the web module) So, if I add a module MyProject/myproject-web, is there a configuration, so that this war module merges the contents of the existing */web modules to one war file? Thanks Dirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Failsafe (aggregate?) reports???
Thanks,
I can get that to work with maven 2.2.1 but modifying the configuration to work
with maven 3 RC3 like this
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
configuration
reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version2.6/version
reportSets
reportSet
idintegration-tests/id
reports
reportreport-only/report
/reports
configuration
aggregatetrue/aggregate
outputNamefailsafe-report/outputName
reportsDirectories
reportsDirectory${project.basedir}/target/failsafe-reports/reportsDirectory
/reportsDirectories
/configuration
/reportSet
/reportSets
/plugin
/reportPlugins
/configuration
/plugin
/plugins
I can't get any output related to failsafe reports although I think the plugin
is running ( I get a surefire-reports.html page that shows 0 tests).
Has anyone gotten this to work with maven 3?
thanks
david jencks
On Oct 2, 2010, at 11:37 PM, Stephen Connolly wrote:
The
Reporting integration test results
Section on http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html
-Stephen
On 3 October 2010 02:42, David Jencks david_jen...@yahoo.com wrote:
The maven-failsafe-plugin claims it's possible to produce failsafe reports
using the maven-surefire-report-plugin but neither plugin has documentation
I can find on how to do it. Ideally I'd like to aggregate all the reports
into one top-level report.
Does anyone know if this is documented anywhere or know of a working example?
thanks
david jencks
-
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: Company-wide settings
One issue with this approach is that m2eclipse will not use this settings.xml file (by default, as it has it's own embedded Maven). I guess this could be solved by configuring the standalone Maven installation in m2eclipse. Anyone that has actually tried the approach of having a corporate settings.xml bundled with a custom Maven distro? /Anders On Mon, Oct 4, 2010 at 11:46, Wendy Smoak wsm...@gmail.com wrote: On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell ssh...@gmail.com wrote: The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: resources are not aggregated from parent to child pom
Hi Ron, That's a very noble sentiment. Thanks. I think it would help if Best Practices were codified. I'm quite prepared to believe that there is a cogent and reasoned position for why some parts of the pom are merged and others not but like Marshall I am not familiar with it. Regards Caoilte On Mon, Oct 4, 2010 at 1:03 PM, Ron Wheeler rwhee...@artifact-software.com wrote: Maven is almost always right. Figure out why your methodology is not following Best Practices and change the way that you work so that maven does it for you automatically. You can fight Maven as much as you want but it will always win. If you can identify why you are building an application that is so unusual that no one else has your workflow, then you may be able to get a solution. In most cases, the application is pretty normal, it is the newbee's workflow that is broken. If you are pioneering some new application platform, you may have a problem but I think that I have seen ejbs with dependent libraries being used in applications before. Mavenize your workflow. I hope that this helps. Ron On 04/10/2010 6:49 AM, Caoilte O'Connor wrote: It bites in quite a lot of places. I wanted to define one execution of the build-helper-maven-plugin in a parent pom and another in one of it's children then have the two merged together. However, Maven overrode the parent configuration in the child. Given that some sections of the pom (eg dependencies, properties) merge so seamlessly it is disappointing to discover sections which don't. Perhaps future versions of Maven will improve things. c On Sat, Oct 2, 2010 at 3:41 PM, Marshall Schorm...@schor.com wrote: On 10/2/2010 7:42 AM, Benjamin Bentmann wrote: Xavier D. wrote: My pom structure is: pom.xml has a parent: parent-pom.xml. Both have aresources section to include files. The (child) pom.xml is executed directly and has the effect of only copying the child's resources. Commenting out this resource section, results in the parent's resources being copied. This is expected behavior,resources given in a child POM are not merged withresources in the parent but completely override those. I'm curious as to why this design decision was taken, versus an approach which allows merging, or perhaps some kind of user (pom - specified) choice. I was bitten by this also. -Marshall Schor Benjamin - 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: Maven deploy plugin increments buildNumber twice during a single invocation of mvn deploy
On 2 October 2010 13:37, Benjamin Bentmann benjamin.bentm...@udo.eduwrote: In case you refer to the pde-maven-plugin ( http://mojo.codehaus.org/pde-maven-plugin/), you should fill this as a bug at http://jira.codehaus.org/browse/MOJO/component/12535, its EclipsePDEAttachMojo.java uses the wrong way to attach the artifact. Thanks Benjamin. I'll file an issue report. Just wanted to check first if anyone else had encountered similar issues, and that I wasn't doing anything stupid! Regards Daniel
Re: Multiple projects - one artifact
On Sun, 03 Oct 2010 17:09:54 +0200 Dirk Reske d...@studiorga.de wrote: Hello, this was, what I'm looking for. Is something like this also possible for my api (normal jar files) and ejb projects? Usually, you would want to add all the EJBs and JARs into an EAR file, so there is no reason for merging them into one file. Also, every war file usually deploys to a different context path, so again no reason to merge them together, that is exactly what EAR was invented for. Everything else is just bad design. Maven helps you in this way that when you build the EAR, it will download the dependent JARs/EJBs from the repository. Stefan thanks Dirk Am 03.10.2010 16:55, schrieb Justin Edelson: Yes, you can do this with war overlays (see the docs for maven-war-plugin) and/or the assembly plugin. On Oct 3, 2010, at 10:27 AM, Dirk Resked...@studiorga.de wrote: Hello, so I will get a separation by project type (web, ejb, ear). But want I want, is a separation by functionality. Lets take a webshop example. I have the core module, which includes the main web.xml in the web sub-module, some core services in the api/impl sub-modules. Than I have the admin module, which includes the webpages for the shop administrators in the web submodule and the needed services in api/impl. etc. In the end a super-web module should merge the contents of core/web, admin/web, etc to one webapp. A super impl module should merge the contents of the core/impl and admin/impl to one ejb module And than a ear module should build an ear out of these thwo artifacts. So it should be possible that a developer only checks out the admin module from the scm an have all webpages, services, entities needed by the admin functionalities in the sub-modules. Dirk Am 03.10.2010 16:07, schrieb Martin Gainty: Dirk- i would configure a separate war-artifact pom.xml in MyProject folder something like artifactIdwar-artifact/artifactId groupId.. version.. !-- assuming the /core/web contents are copied to folder called core-web in MyProject folder -- !-- ASSUMING users/web contents are copied to folder called users-web in MyProject folder -- !-- ASSUMING admin/web contents are copied to folder called admin-web in MyProject folder -- !-- which contains these modules -- modules modulecore-web/module moduleusers-web/module moduleadmin-web/module /modules for building the ear ..follow antonios advice Viel Gluck! Martin Gainty __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Date: Sun, 3 Oct 2010 15:48:04 +0200 Subject: Re: Multiple projects - one artifact From: antonio.petre...@gmail.com To: users@maven.apache.org 2010/10/3 Dirk Resked...@studiorga.de: is it possible to build one artifact out of multiple projects. We are trying to modularize the development. Example: MyProject |-- core | |--api | |--impl | |--web |-- users | |--api | |--impl | |--web |-- admin | |--api | |--impl | |--web this should results in the following ear file myproject.ear |--lib/myproject-api.jar (the entity classes, service interfaces, etc) |--myproject-impl.ear (the ejb module) |--myproject-web.ear (the web module) So, if I add a module MyProject/myproject-web, is there a configuration, so that this war module merges the contents of the existing */web modules to one war file? I think that this link might answer all your questions about JEE development with Maven: http://docs.codehaus.org/display/MAVENUSER/Developing+JEE+projects+with+Maven Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Mit freundlichen Grüßen, Stefan Seidel Software-Entwickler VUB Printmedia GmbH Chopinstraße 4, 04103 Leipzig tel.+49 (341) 9 60 50 93 fax.+49 (341) 9 60 50 92 mail. ssei...@vub.de web.www.vub.de VUB Printmedia GmbH HRB Köln 24015 GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
Can't you put all these settings into a company wide parent pom that is the parent of each project pom (but not located in the file system parent)? You can certainly do this with profiles. All the apache projects that use maven that I know of do this. And, there's an apache wide pom that sets up stuff shared by pretty much all apache projects that use maven. david jencks On Oct 3, 2010, at 2:34 PM, Phillip Hellewell wrote: I see that Maven can have a settings.xml at both the Global Level and User Level. Is there a way to have a settings.xml that can be referenced (or included) from a pom.xml, whose settings would apply first but could be overridden by a global or user settings.xml. The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. Phillip - 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
Hudson project: build a Maven project and also run a script (chekin code from vss- chekout)
Hi, I work with Hudson and i want to create a project that build a Maven project and it does also other things like checkin the code from vss (Visual Source Safe) then checkout it after the build! Some one know how to do this? -- View this message in context: http://maven.40175.n5.nabble.com/Hudson-project-build-a-Maven-project-and-also-run-a-script-chekin-code-from-vss-chekout-tp3117319p3117319.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: Multiple projects - one artifact
Hi, for web try war overlays. Create one master war project that merges all other war subprojects regards Thomas Am 03.10.2010 15:26, schrieb Dirk Reske: Hello, is it possible to build one artifact out of multiple projects. We are trying to modularize the development. Example: MyProject |-- core | |--api | |--impl | |--web |-- users | |--api | |--impl | |--web |-- admin | |--api | |--impl | |--web this should results in the following ear file myproject.ear |--lib/myproject-api.jar (the entity classes, service interfaces, etc) |--myproject-impl.ear (the ejb module) |--myproject-web.ear (the web module) So, if I add a module MyProject/myproject-web, is there a configuration, so that this war module merges the contents of the existing */web modules to one war file? Thanks Dirk - 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: Company-wide settings
We do. It is simply a requirement for the AppDev team to implement. So, even when they forget, we catch it in the build process since those builds happen on our servers where the settings.xml is definitely set to use our internal repository. Curt Yanko | Continuous Integration Services Making IT Happen, one build at a time -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Monday, October 04, 2010 6:29 AM To: Maven Users List Subject: Re: Company-wide settings One issue with this approach is that m2eclipse will not use this settings.xml file (by default, as it has it's own embedded Maven). I guess this could be solved by configuring the standalone Maven installation in m2eclipse. Anyone that has actually tried the approach of having a corporate settings.xml bundled with a custom Maven distro? /Anders On Mon, Oct 4, 2010 at 11:46, Wendy Smoak wsm...@gmail.com wrote: On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell ssh...@gmail.com wrote: The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. This is what we do for the most part. We checkout the global settings.xml file to the conf folder of the maven install. This way, if settings ever change, all a dev needs to do is an svn update on the file. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Failsafe (aggregate?) reports???
You might have to add the defaults for surefire reports as the maven3
changes might mean that you are no-longer inheriting the defaults when
within the site plugin configuration section :-(
-Stephen
On 4 October 2010 08:27, David Jencks david_jen...@yahoo.com wrote:
Thanks,
I can get that to work with maven 2.2.1 but modifying the configuration to
work with maven 3 RC3 like this
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
configuration
reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version2.6/version
reportSets
reportSet
idintegration-tests/id
reports
reportreport-only/report
/reports
configuration
aggregatetrue/aggregate
outputNamefailsafe-report/outputName
reportsDirectories
reportsDirectory${project.basedir}/target/failsafe-reports/reportsDirectory
/reportsDirectories
/configuration
/reportSet
/reportSets
/plugin
/reportPlugins
/configuration
/plugin
/plugins
I can't get any output related to failsafe reports although I think the
plugin is running ( I get a surefire-reports.html page that shows 0 tests).
Has anyone gotten this to work with maven 3?
thanks
david jencks
On Oct 2, 2010, at 11:37 PM, Stephen Connolly wrote:
The
Reporting integration test results
Section on
http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html
-Stephen
On 3 October 2010 02:42, David Jencks david_jen...@yahoo.com wrote:
The maven-failsafe-plugin claims it's possible to produce failsafe
reports using the maven-surefire-report-plugin but neither plugin has
documentation I can find on how to do it. Ideally I'd like to aggregate all
the reports into one top-level report.
Does anyone know if this is documented anywhere or know of a working
example?
thanks
david jencks
-
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: Company-wide settings
One issue with this approach is that m2eclipse will not use this settings.xml file (by default, as it has it's own embedded Maven). I guess this could be solved by configuring the standalone Maven installation in m2eclipse. That is exactly what we do. Anyone that has actually tried the approach of having a corporate settings.xml bundled with a custom Maven distro? We do have a custom corporate maven distro that developers can checkout. However, we have a number of teams that are using different versions of maven so our recommended approach for the organization is to simply checkout the settings.xml file to whatever maven installation they want. For example, I have been trying to stay on the somewhat cutting edge of maven releases and have downloaded and tried the beta version of maven 3. Other teams are using fairly old versions. Not all teams are the same so we found that a common Maven distro for all devs to be overkill. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
We ask maven devs to checkout to their maven/conf folder. Their ~/.m2 can contain things like their personal passwords and profile information so we try not to copy the global settings.xml file to the local location. -Original Message- From: Nathan Sowatskey (nsowatsk) [mailto:nsowa...@cisco.com] Sent: Monday, October 04, 2010 6:55 AM To: Maven Users List Cc: Maven Users List Subject: Re: Company-wide settings In our project we have a project wide settings.xml in Subversion, and we ask all developers to put that into their ~/.m2 directory. Regards Nathan Nathan Sowatskey (nsowa...@cisco.com) - Technical Leader, ScanSafe - +34- 638-083-675 On 4 Oct 2010, at 12:30, Anders Hammar and...@hammar.net wrote: One issue with this approach is that m2eclipse will not use this settings.xml file (by default, as it has it's own embedded Maven). I guess this could be solved by configuring the standalone Maven installation in m2eclipse. Anyone that has actually tried the approach of having a corporate settings.xml bundled with a custom Maven distro? /Anders On Mon, Oct 4, 2010 at 11:46, Wendy Smoak wsm...@gmail.com wrote: On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell ssh...@gmail.com wrote: The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. -- Wendy - 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: resources are not aggregated from parent to child pom
It bites in quite a lot of places. I wanted to define one execution of the build-helper-maven-plugin in a parent pom and another in one of it's children then have the two merged together. However, Maven overrode the parent configuration in the child. Given that some sections of the pom (eg dependencies, properties) merge so seamlessly it is disappointing to discover sections which don't. Perhaps future versions of Maven will improve things. c On Sat, Oct 2, 2010 at 3:41 PM, Marshall Schor m...@schor.com wrote: On 10/2/2010 7:42 AM, Benjamin Bentmann wrote: Xavier D. wrote: My pom structure is: pom.xml has a parent: parent-pom.xml. Both have aresources section to include files. The (child) pom.xml is executed directly and has the effect of only copying the child's resources. Commenting out this resource section, results in the parent's resources being copied. This is expected behavior, resources given in a child POM are not merged with resources in the parent but completely override those. I'm curious as to why this design decision was taken, versus an approach which allows merging, or perhaps some kind of user (pom - specified) choice. I was bitten by this also. -Marshall Schor Benjamin - 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: Company-wide settings
In our project we have a project wide settings.xml in Subversion, and we ask all developers to put that into their ~/.m2 directory. Regards Nathan Nathan Sowatskey (nsowa...@cisco.com) - Technical Leader, ScanSafe - +34-638-083-675 On 4 Oct 2010, at 12:30, Anders Hammar and...@hammar.net wrote: One issue with this approach is that m2eclipse will not use this settings.xml file (by default, as it has it's own embedded Maven). I guess this could be solved by configuring the standalone Maven installation in m2eclipse. Anyone that has actually tried the approach of having a corporate settings.xml bundled with a custom Maven distro? /Anders On Mon, Oct 4, 2010 at 11:46, Wendy Smoak wsm...@gmail.com wrote: On Sun, Oct 3, 2010 at 5:34 PM, Phillip Hellewell ssh...@gmail.com wrote: The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. One way is to make a custom Maven distribution for your organization, with a modified settings.xml. This also has the advantage of having all developers use the same version, which makes support easier. Many organizations don't allow developers to download and install random stuff off the internet anyway, so this becomes your corporate/approved/official Maven distro. -- Wendy - 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: resources are not aggregated from parent to child pom
On 04/10/2010 8:29 AM, Caoilte O'Connor wrote: Hi Ron, That's a very noble sentiment. Thanks. I think it would help if Best Practices were codified. You are right. This causes almost all of the traffic on this site. Everyone starts out with an existing methodology that serves their non-Maven ways. Making the workflow changes without any guides just takes a lot of chatter in the forum. On the good side, you should not feel to bad about this. Everyone goes through it but once the workflow is Mavenized, most of the pain vanishes. It will build any normal application out of the box. There are some good books and higher level technical materials from Sonatype and others that are very good things to read to get an understanding of the Maven Way. Runing Maven without Nexus (or another repository) is a very frustrating way to start out. My biggest regret about starting with Maven was that we did not have Nexus from the beginning. It would have made Maven much, much easier to use. We wasted so much time and energy for nothing. We have had it for 6 months and I wish we had got it going 2 years ago. I'm quite prepared to believe that there is a cogent and reasoned position for why some parts of the pom are merged and others not but like Marshall I am not familiar with it. You will likely get more useful advice if you describe what you are trying to build and try to get workflow advice. One of the issues in the forum, is that the experts are so good and know Maven so well, that they will tell you how to make Maven do the most bizarre and intricate things if you ask a question that is too focused on a detail and not about workflow. It is great to have people in the forum, who I think must dream in Maven, but sometimes solving a technical problem with a plug-in is not better than changing the problem to match what Maven expects to do for you if you are building a standard XYZ (Java App, Tomcat, JBoss, etc.) application. Maven does a great job of automating your workflow, IF your workflow fits Maven's idea of a good workflow. If you want to fight Maven, it can be made follow your workflow but it will turn and bite you every chance it gets. You will get it going nicely in the end and the people in the forum are really helpful and very smart. Ron Regards Caoilte On Mon, Oct 4, 2010 at 1:03 PM, Ron Wheeler rwhee...@artifact-software.com wrote: Maven is almost always right. Figure out why your methodology is not following Best Practices and change the way that you work so that maven does it for you automatically. You can fight Maven as much as you want but it will always win. If you can identify why you are building an application that is so unusual that no one else has your workflow, then you may be able to get a solution. In most cases, the application is pretty normal, it is the newbee's workflow that is broken. If you are pioneering some new application platform, you may have a problem but I think that I have seen ejbs with dependent libraries being used in applications before. Mavenize your workflow. I hope that this helps. Ron On 04/10/2010 6:49 AM, Caoilte O'Connor wrote: It bites in quite a lot of places. I wanted to define one execution of the build-helper-maven-plugin in a parent pom and another in one of it's children then have the two merged together. However, Maven overrode the parent configuration in the child. Given that some sections of the pom (eg dependencies, properties) merge so seamlessly it is disappointing to discover sections which don't. Perhaps future versions of Maven will improve things. c On Sat, Oct 2, 2010 at 3:41 PM, Marshall Schorm...@schor.comwrote: On 10/2/2010 7:42 AM, Benjamin Bentmann wrote: Xavier D. wrote: My pom structure is: pom.xml has a parent: parent-pom.xml. Both have aresources section to include files. The (child) pom.xml is executed directly and has the effect of only copying the child's resources. Commenting out this resource section, results in the parent's resources being copied. This is expected behavior,resourcesgiven in a child POM are not merged withresourcesin the parent but completely override those. I'm curious as to why this design decision was taken, versus an approach which allows merging, or perhaps some kind of user (pom - specified) choice. I was bitten by this also. -Marshall Schor Benjamin - 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: Hudson project: build a Maven project and also run a script (chekin code from vss- chekout)
I work with Hudson and i want to create a project that build a Maven project and it does also other things like checkin the code from vss (Visual Source Safe) then checkout it after the build! I would probably ask this on the Hudson Users list... Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
Thanks all for the great suggestions. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Problem unpacking dependencies
-Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] On Fri, Oct 1, 2010 at 4:23 PM, Jon Paynter kittl...@gmail.com wrote: Glad it has helped. but id still like to know why unpack-dependencies tries to unpack a pom file Well I did have typepom/type in my dependency in the dependencies section. But yeah, it still shouldn't try to unpack a pom. Perhaps it is a bug? er... well unpack-dependencies is supposed to unpack things, and you were explicitly giving it a pom type artifact, so it seems like it was doing approximately what it should. I'm thinking of this setup as a (more verbose) way of saying: jar -xf pom.xml Looking at it from another point of view, what *should* it do with a pom artifact? Simply copying it seems wrong, since there's an explicit copy-dependencies goal for doing that. I don't think I'd consider this a bug. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem unpacking dependencies
On Mon, Oct 4, 2010 at 9:30 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: Looking at it from another point of view, what *should* it do with a pom artifact? Simply copying it seems wrong, since there's an explicit copy-dependencies goal for doing that. I don't think I'd consider this a bug. It could copy it or just skip it, but giving an error could be problematic. How about a warning instead? Consider this scenario. What if I had a pom artifact that didn't include a zip or jar or anything, but I need to depend on it because I need to get everything it depends on, and I want those dependencies to get unpacked? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Which repository is used
First qAre repositories Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem unpacking dependencies
On 10/4/10 12:00 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 9:30 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: Looking at it from another point of view, what *should* it do with a pom artifact? Simply copying it seems wrong, since there's an explicit copy-dependencies goal for doing that. I don't think I'd consider this a bug. It could copy it or just skip it, but giving an error could be problematic. How about a warning instead? Consider this scenario. What if I had a pom artifact that didn't include a zip or jar or anything, but I need to depend on it because I need to get everything it depends on, and I want those dependencies to get unpacked? Then you can use the various exclude/include parameters to tune the artifacts which will be unpacked. Justin Phillip - 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: Which repository is used
On Mon, Oct 4, 2010 at 10:01 AM, Phillip Hellewell ssh...@gmail.com wrote: First qAre repositories Sorry about that. Stupid gmail client. First question: When downloading dependencies, are the repositories defined in settings.xml are always checked in order and before the Maven central repository? Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Thanks, Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can't specify distributionManagement in settings.xml
I can specify repositories in a profile in my settings.xml for downloading artifacts, but I don't seem to be able to specify distributionManagement in there. No matter what I try it gives an error Unrecognised tag: 'distributionManagement'. I don't want to have to specify the url of my company repository in every single POM. What could I be doing wrong? Thanks, Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 12:07 PM, Phillip Hellewell ssh...@gmail.com wrote: I can specify repositories in a profile in my settings.xml for downloading artifacts, but I don't seem to be able to specify distributionManagement in there. No matter what I try it gives an error Unrecognised tag: 'distributionManagement'. Google 'Maven settings model' to find http://maven.apache.org/ref/2.2.1/maven-settings/settings.html and look at what is allowed in settings.xml. As you've already discovered, distributionManagement doesn't go there. I don't want to have to specify the url of my company repository in every single POM. What could I be doing wrong? Put it in a top-level organization level pom, from which all of your projects inherit. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem unpacking dependencies
On Mon, Oct 4, 2010 at 10:03 AM, Justin Edelson justinedel...@gmail.com wrote: On 10/4/10 12:00 PM, Phillip Hellewell wrote: Consider this scenario. What if I had a pom artifact that didn't include a zip or jar or anything, but I need to depend on it because I need to get everything it depends on, and I want those dependencies to get unpacked? Then you can use the various exclude/include parameters to tune the artifacts which will be unpacked. Hmm, would a simple excludeTypespom/excludeTypes do the trick maybe? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 10:10 AM, Wendy Smoak wsm...@gmail.com wrote: On Mon, Oct 4, 2010 at 12:07 PM, Phillip Hellewell ssh...@gmail.com wrote: I don't want to have to specify the url of my company repository in every single POM. What could I be doing wrong? Put it in a top-level organization level pom, from which all of your projects inherit. Thanks. That worked just great. It does feel kinda inconsistent though, that I can specify repositories to download from in settings.xml, but I can't specify a default repository to upload to when deploying. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell ssh...@gmail.com wrote: Thanks all for the great suggestions. Do you think using a parent pom for the settings would also be a workable solution? I'm already going to have to use a parent pom anyways, for the default distributionManagement (since that can't go in settings.xml), so maybe I should just do all my company-wide settings in a shared pom that every project includes using parent. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Common Artifact Filters 1.3 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters, version 1.3 This shared library provides a set of implementations for the org.apache.maven.artifact.resolver.filter.ArtifactFilter interface, found in maven-artifact. Most notable are the implementations allowing the use of wildcard patterns for including and excluding artifacts. http://maven.apache.org/shared/maven-common-artifact-filters-1.3 To use this library, specify the following dependency in your pom.xml: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.3/version /dependency Release Notes - Maven Common Artifact Filters - Version 1.3 ** Bug * [MSHARED-162] - actTransitively wildcard patterns can fail on pattern-based filters Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
I wouldn't personally. This blog at Sonatype explains why. http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 12:55 PM To: Maven Users List Subject: Re: Company-wide settings On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell ssh...@gmail.com wrote: Thanks all for the great suggestions. Do you think using a parent pom for the settings would also be a workable solution? I'm already going to have to use a parent pom anyways, for the default distributionManagement (since that can't go in settings.xml), so maybe I should just do all my company-wide settings in a shared pom that every project includes using parent. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Common Artifact Filters 1.3 Released
The Maven team is pleased to announce the release of the Maven Common Artifact Filters, version 1.3 This shared library provides a set of implementations for the org.apache.maven.artifact.resolver.filter.ArtifactFilter interface, found in maven-artifact. Most notable are the implementations allowing the use of wildcard patterns for including and excluding artifacts. http://maven.apache.org/shared/maven-common-artifact-filters-1.3 To use this library, specify the following dependency in your pom.xml: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-common-artifact-filters/artifactId version1.3/version /dependency Release Notes - Maven Common Artifact Filters - Version 1.3 ** Bug * [MSHARED-162] - actTransitively wildcard patterns can fail on pattern-based filters Enjoy, -The Maven team -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
It wouldn't work for other reasons as well. Here's one case: You're developing your Maven project. You specify the corp parent as the parent. But that pom is in the corp repo and not on your hard drive. And as the info about that repo is in the parent, Maven doesn't know of the repo and can't get the corp parent. It has to be defined in settings.xml. /Anders On Mon, Oct 4, 2010 at 18:57, Thiessen, Todd (Todd) tthies...@avaya.comwrote: I wouldn't personally. This blog at Sonatype explains why. http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 12:55 PM To: Maven Users List Subject: Re: Company-wide settings On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell ssh...@gmail.com wrote: Thanks all for the great suggestions. Do you think using a parent pom for the settings would also be a workable solution? I'm already going to have to use a parent pom anyways, for the default distributionManagement (since that can't go in settings.xml), so maybe I should just do all my company-wide settings in a shared pom that every project includes using parent. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
Right. The blog entry explains this bootstrapping problem quite well. -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Monday, October 04, 2010 1:02 PM To: Maven Users List Subject: Re: Company-wide settings It wouldn't work for other reasons as well. Here's one case: You're developing your Maven project. You specify the corp parent as the parent. But that pom is in the corp repo and not on your hard drive. And as the info about that repo is in the parent, Maven doesn't know of the repo and can't get the corp parent. It has to be defined in settings.xml. /Anders On Mon, Oct 4, 2010 at 18:57, Thiessen, Todd (Todd) tthies...@avaya.comwrote: I wouldn't personally. This blog at Sonatype explains why. http://www.sonatype.com/people/2009/02/why-putting-repositories-in- your-poms-is-a-bad-idea/ -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 12:55 PM To: Maven Users List Subject: Re: Company-wide settings On Mon, Oct 4, 2010 at 9:11 AM, Phillip Hellewell ssh...@gmail.com wrote: Thanks all for the great suggestions. Do you think using a parent pom for the settings would also be a workable solution? I'm already going to have to use a parent pom anyways, for the default distributionManagement (since that can't go in settings.xml), so maybe I should just do all my company-wide settings in a shared pom that every project includes using parent. Phillip - 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: Which repository is used
Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Install a Maven Repo Manager like Nexus and configure Maven via settings.xml to go to it for all repos (mirror-of *). This is a must-do for real corporate use of Maven. Ron will pipe up shortly, I'm sure. ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Right. The blog entry explains this bootstrapping problem quite well. I'm not sure I will have the bootstrap problem, because I'm thinking about having this company pom be in SVN in a directory that all other components get automatically upon checkout via svn:externals. Since I am treating this pom as a settings file, I don't even care about it being in a repository, ever. In fact, if possible I would like to make it impossible for it to get deployed to a repository. I really want it to just be a settings file. Of course I'd much rather use the settings.xml for all this, but if I have to use a pom to specify the distributionManagement, then why not put the repositories in there too, as that keeps them all in the same place, will be easier to maintain, and everyone gets updates to it automatically. If putting repositories in POMs is a Bad Idea, then I'd argue that putting distributionManagement in POMs is a Bad Idea too, but for some reason the settings.xml doesn't allow distributionManagement in there. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which repository is used
On 04/10/2010 1:10 PM, Wayne Fay wrote: Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Install a Maven Repo Manager like Nexus and configure Maven via settings.xml to go to it for all repos (mirror-of *). This is a must-do for real corporate use of Maven. Ron will pipe up shortly, I'm sure. ;-) +1 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: Which repository is used
On Mon, Oct 4, 2010 at 11:10 AM, Wayne Fay wayne...@gmail.com wrote: Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Install a Maven Repo Manager like Nexus and configure Maven via settings.xml to go to it for all repos (mirror-of *). This is a must-do for real corporate use of Maven. Ron will pipe up shortly, I'm sure. ;-) So there is absolutely no way to do this short of purchasing and setting up a repository proxy server like Maven? Why can't there be like a simple setting in settings.xml that says any artifact with group ID of com.mycompany should not attempt to contact Maven central? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which repository is used
On 04/10/2010 1:37 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 11:10 AM, Wayne Faywayne...@gmail.com wrote: Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Install a Maven Repo Manager like Nexus and configure Maven via settings.xml to go to it for all repos (mirror-of *). This is a must-do for real corporate use of Maven. Ron will pipe up shortly, I'm sure. ;-) So there is absolutely no way to do this short of purchasing and setting up a repository proxy server like Maven? Free version of Nexus will get you started Why can't there be like a simple setting in settings.xml that says any artifact with group ID of com.mycompany should not attempt to contact Maven central? No need. Phillip - 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: Which repository is used
So there is absolutely no way to do this short of purchasing and setting up a repository proxy server like Maven? Why can't there be like a simple setting in settings.xml that says any artifact with group ID of com.mycompany should not attempt to contact Maven central? Nexus has a free OSS version. Only Nexus Pro is not-free. There are other MRM options as well. Have fun if you try to seriously use Maven in your org without an MRM! Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] maven-issues-plugin
Antonio Petrelli wrote: Cool! But since you already licensed with Apache License v2, why don't you donate it to the Maven Changes Plugin? Hello Antonio, thank you for your reply! One reason for not trying to contribute to the changes plugin was that this plugin requires to run on Java 1.4, but the issues plugin uses a Mylyn library which is based on Java 1.5. There is already a patch for an unresolved JIRA issue provided by Matthew Beermann [1] of 2007 that has not been applied. I assume for this reason. Kind regards Robert [1] http://jira.codehaus.org/browse/MCHANGES-58 -- View this message in context: http://maven.40175.n5.nabble.com/ANN-maven-issues-plugin-tp3046637p3192503.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: Which repository is used
On Mon, Oct 4, 2010 at 11:47 AM, Wayne Fay wayne...@gmail.com wrote: Nexus has a free OSS version. Only Nexus Pro is not-free. There are other MRM options as well. Have fun if you try to seriously use Maven in your org without an MRM! Ah, ok. Thanks Wayne and Ron. Yeah, for efficiency I think we'll need a MRM no matter what. I suppose we could simply mirror most of the plugins to the company repository that we think we'll need. But that could be a major pain whenever someone wants to use another plugin that they have to go through whoever to get it downloaded to the company repository before they can actually use it. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Remote Repository Under Subversion
Hi. I have artifact repository under Subversion Server. Server URL: https://my.server.com/my/libs I need to configure maven settings to download artifacts from this subversion server. Is that possible or not. What configuration is needed to do this. Thanks Patrick
Re: Remote Repository Under Subversion
On 4 October 2010 11:09, Patrick Weege patrick.we...@t-systems.com.br wrote: Hi. I have artifact repository under Subversion Server. Server URL: https://my.server.com/my/libs I need to configure maven settings to download artifacts from this subversion server. Is that possible or not. Yes. What configuration is needed to do this. See https://wagon-svn.dev.java.net/. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which repository is used
I suppose we could simply mirror most of the plugins to the company repository that we think we'll need. But that could be a major pain whenever someone wants to use another plugin that they have to go through whoever to get it downloaded to the company repository before they can actually use it. Please read up on how a Maven Repository Manager works and you'll very soon realize that you're worrying about issues that doesn't exist! It's smooth ride and there is no real alternative! /Anders
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 10:25 AM, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Oct 4, 2010 at 10:10 AM, Wendy Smoak wsm...@gmail.com wrote: Put it in a top-level organization level pom, from which all of your projects inherit. Thanks. That worked just great. Crap, this is not working out. Now I'm getting an error later on when I try to depend on this project because the parent pom can't be found. But I don't want to put the parent pom in the repository or anything. I just wanted to use it to provide the distributionManagement setting. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
Philip, with all due respect, but reading your posts I get the impression you're doing your best not to follow Maven best practice. Maven is all about convention and best practice patterns. Please acknowledge that our advice is based on actual experience and going your own path will surely get you into trouble! It's not really a matter of what you think, but rather what Maven thinks. :-) /Anders On Mon, Oct 4, 2010 at 19:29, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Right. The blog entry explains this bootstrapping problem quite well. I'm not sure I will have the bootstrap problem, because I'm thinking about having this company pom be in SVN in a directory that all other components get automatically upon checkout via svn:externals. Since I am treating this pom as a settings file, I don't even care about it being in a repository, ever. In fact, if possible I would like to make it impossible for it to get deployed to a repository. I really want it to just be a settings file. Of course I'd much rather use the settings.xml for all this, but if I have to use a pom to specify the distributionManagement, then why not put the repositories in there too, as that keeps them all in the same place, will be easier to maintain, and everyone gets updates to it automatically. If putting repositories in POMs is a Bad Idea, then I'd argue that putting distributionManagement in POMs is a Bad Idea too, but for some reason the settings.xml doesn't allow distributionManagement in there. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
Are you seeing the pattern yet? Don't fight Maven! /Anders On Mon, Oct 4, 2010 at 20:24, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Oct 4, 2010 at 10:25 AM, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Oct 4, 2010 at 10:10 AM, Wendy Smoak wsm...@gmail.com wrote: Put it in a top-level organization level pom, from which all of your projects inherit. Thanks. That worked just great. Crap, this is not working out. Now I'm getting an error later on when I try to depend on this project because the parent pom can't be found. But I don't want to put the parent pom in the repository or anything. I just wanted to use it to provide the distributionManagement setting. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
You only need distribution management to specify what you deploy to, not where you get artifacts from. Very different. Deploying to has none of the issues described in the blog entry. This is a good use of the distro mangement section and you should put that in a parent pom somewhere and is not a bad thing as you are alluding to. Your solution of svn externals sounds very complicated ;-). I am sure you will run into a number of problems with it. There are also a couple of other issues that the blog discusses that you have not mentioned here: 1. If a transitive pom specifies a repository, you are going to hit the internet to try and download that dependency and not from your corporate repository. 2. Once you put repository information in your pom it is burned there forever. So if an artifact moves to another repository, you tags will not build and you will have to track down artifacts manually. While this is less of a problem for the Enterprise, it can and does happen. -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 1:29 PM To: Maven Users List Subject: Re: Company-wide settings On Mon, Oct 4, 2010 at 11:07 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Right. The blog entry explains this bootstrapping problem quite well. I'm not sure I will have the bootstrap problem, because I'm thinking about having this company pom be in SVN in a directory that all other components get automatically upon checkout via svn:externals. Since I am treating this pom as a settings file, I don't even care about it being in a repository, ever. In fact, if possible I would like to make it impossible for it to get deployed to a repository. I really want it to just be a settings file. Of course I'd much rather use the settings.xml for all this, but if I have to use a pom to specify the distributionManagement, then why not put the repositories in there too, as that keeps them all in the same place, will be easier to maintain, and everyone gets updates to it automatically. If putting repositories in POMs is a Bad Idea, then I'd argue that putting distributionManagement in POMs is a Bad Idea too, but for some reason the settings.xml doesn't allow distributionManagement in there. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar and...@hammar.net wrote: Philip, with all due respect, but reading your posts I get the impression you're doing your best not to follow Maven best practice. Maven is all about convention and best practice patterns. Please acknowledge that our advice is based on actual experience and going your own path will surely get you into trouble! It's not really a matter of what you think, but rather what Maven thinks. :-) Ok, slow down everyone. No worries. I just did a test and have found that this approach fails miserably. It apparently wants the parent pom to be available whenever I depend on this project, so obviously this doesn't work. So no worries, I'm fully convinced that I want to use settings.xml to specify repositories. But I'm still trying to find the best way to specify a distributionManagement in each of my poms without duplicating the url. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Which repository is used
Nexus is free Phil. We use the free version for some pretty complicated builds and works very well. You would of have it setup by now. Very easy. -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 1:37 PM To: Maven Users List Subject: Re: Which repository is used On Mon, Oct 4, 2010 at 11:10 AM, Wayne Fay wayne...@gmail.com wrote: Second question: Is there any way to disable checking Maven central completely? None of my artifacts will ever live in the central Maven repository, so why should it waste time and resources checking it? Install a Maven Repo Manager like Nexus and configure Maven via settings.xml to go to it for all repos (mirror-of *). This is a must-do for real corporate use of Maven. Ron will pipe up shortly, I'm sure. ;-) So there is absolutely no way to do this short of purchasing and setting up a repository proxy server like Maven? Why can't there be like a simple setting in settings.xml that says any artifact with group ID of com.mycompany should not attempt to contact Maven central? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which repository is used
On Mon, Oct 4, 2010 at 12:34 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Nexus is free Phil. We use the free version for some pretty complicated builds and works very well. You would of have it setup by now. Very easy. No worries everyone. I get the picture :) Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which repository is used
Yes, one more converted soul...:-) /Anders On Mon, Oct 4, 2010 at 20:36, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Oct 4, 2010 at 12:34 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Nexus is free Phil. We use the free version for some pretty complicated builds and works very well. You would of have it setup by now. Very easy. No worries everyone. I get the picture :) Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar and...@hammar.net wrote: Are you seeing the pattern yet? Don't fight Maven! Hehe, yeah I am. But using a parent pom for this setting is still not making complete sense to me, so I've got to play with it some more and hopefully it will. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 2 3 + Hudson + Nexus
Hi all, I think I've kind of painted myself into a corner. I have a fairly common setup of Maven (2.2.1) + Nexus + Hudson. This all works like a charm (of course). Locally, I've been using Maven 3 (beta 3, RC1, RC2) to make sure that we would be able to make the jump without problems. Apparently, I did something (presumably a release) that screwed things up. One of the builds is now failing on Hudson and I can reproduce the issue locally ... if I use Maven 2. With Maven 3 it all works as it should. I first thought I'd simply tell Hudson to start using Maven 3 too but Hudson does not support this (it can't even start Maven 3). I don't understand what the issue is, really. I can't see a difference between the old metadata and the new (not that I paid much attention to it before, of course :-) ). Maven 2 doesn't even make a request to Nexus and therefore doesn't find the snapshot POM it's looking for. Maven 3 does make the request and everything works. I redeployed (through Hudson) the relevant snapshot POM but the problematic build still fails because it can't find this POM. Any ideas how I can fix this? Any ideas as to what the problem is exactly? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 12:43 PM, Phillip Hellewell ssh...@gmail.com wrote:
On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar and...@hammar.net wrote:
Are you seeing the pattern yet? Don't fight Maven!
Hehe, yeah I am. But using a parent pom for this setting is still not
making complete sense to me, so I've got to play with it some more and
hopefully it will.
Ok, I figured out what I feel is a valid and good solution. Not sure
why I didn't think of this before, but in the default profile in my
settings.xml I can simply define a property called repos.url, right
where I define my repository. Then I can use that same property in my
distributionManagement section in any of my poms that I want to.
So something like this goes in my settings.xml:
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
repos.urlfile:///c:/test123/repos.url
/properties
repositories
repository
idtest123/id
nametest/name
url${repos.url}/url
/repository
/repositories
/profile
/profiles
And something like this goes in my pom files:
distributionManagement
repository
idmyrepos/id
url${repos.url}/url
/repository
/distributionManagement
The other advantage here is that I can pass in repos.url on the
command-line with -D if I want to deploy to another repository.
I hope you won't tell me this is the wrong way, because it seems
like a perfectly valid approach to me.
Phillip
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
-Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar and...@hammar.net wrote: Philip, with all due respect, but reading your posts I get the impression you're doing your best not to follow Maven best practice. Maven is all about convention and best practice patterns. Please acknowledge that our advice is based on actual experience and going your own path will surely get you into trouble! It's not really a matter of what you think, but rather what Maven thinks. :-) Ok, slow down everyone. No worries. I just did a test and have found that this approach fails miserably. It apparently wants the parent pom to be available whenever I depend on this project, so obviously this doesn't work. So no worries, I'm fully convinced that I want to use settings.xml to specify repositories. But I'm still trying to find the best way to specify a distributionManagement in each of my poms without duplicating the url. fwiw, I'm using a (globally installed) settings.xml here to specify where to retrieve artifacts from (a local nexus proxy). Most of the projects I work with use a parent pom that specifies a distributionManagement section, and it seems to work ok for the most part, but there are some drawbacks. Specifically, you'll run into issues when you need to change the distribution urls. To do that I need to either deploy a new release of the parent pom and change *all* of the other project poms to refer to the new release, or go manually remove the parent pom from nexus and deploy a changed one (which has all sorts of other problems). bleh. eric (btw, you'll hear a lot of people with a very fixed mindset regarding the supposed one true maven way, but don't think that everyone agrees with that. I, for one, think the tools you use should guide you to a good methodology, but should have at least a little bit of flexibility to allow for the inevitable differences that pop up in real world projects without throwing up tons of roadblocks) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
-Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Are you seeing the pattern yet? Don't fight Maven! So what IS the pattern here? How do you actually configure the distribution management if you're not going to put it in a parent pom? Saying don't fight maven is rather useless if you don't explain how you're actually supposed to get things to work. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
Hehe. Not so sure I'd say wrong, but definitely unnecessary.
Why are you opposed to putting this information in a the distribution
management section of a parent pom?
-Original Message-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: Monday, October 04, 2010 3:05 PM
To: Maven Users List
Subject: Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 12:43 PM, Phillip Hellewell ssh...@gmail.com
wrote:
On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar and...@hammar.net
wrote:
Are you seeing the pattern yet? Don't fight Maven!
Hehe, yeah I am. But using a parent pom for this setting is still not
making complete sense to me, so I've got to play with it some more and
hopefully it will.
Ok, I figured out what I feel is a valid and good solution. Not sure
why I didn't think of this before, but in the default profile in my
settings.xml I can simply define a property called repos.url, right
where I define my repository. Then I can use that same property in my
distributionManagement section in any of my poms that I want to.
So something like this goes in my settings.xml:
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
repos.urlfile:///c:/test123/repos.url
/properties
repositories
repository
idtest123/id
nametest/name
url${repos.url}/url
/repository
/repositories
/profile
/profiles
And something like this goes in my pom files:
distributionManagement
repository
idmyrepos/id
url${repos.url}/url
/repository
/distributionManagement
The other advantage here is that I can pass in repos.url on the
command-line with -D if I want to deploy to another repository.
I hope you won't tell me this is the wrong way, because it seems
like a perfectly valid approach to me.
Phillip
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
-Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Hehe. Not so sure I'd say wrong, but definitely unnecessary. Why are you opposed to putting this information in a the distribution management section of a parent pom? See the email I wrote in the Company-wide settings thread (Message-ID: 9d29fd18cbd74a478cba86e6ef6dbad40590a...@chi4evs04.corp.transunion.com ). If you put this in a parent pom, it becomes very hard to change it, and this feels like arbitrary, mutable, local configuration that shouldn't get hard coded into the builds. Phillip's idea of using a property sounds pretty useful to me. (thanks!) eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 1:23 PM, Haszlakiewicz, Eric ehas...@transunion.com wrote: If you put this in a parent pom, it becomes very hard to change it, and this feels like arbitrary, mutable, local configuration that shouldn't get hard coded into the builds. Yeah, I think Eric pretty much nailed it. In addition to what Eric said, for me it is also the fact that why should I mess with another pom file unnecessarily? That and the fact that I tried it and couldn't get it working, even after deploying the parent pom. So anyway, setting a property in the settings.xml seems like the best approach to me. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
Wrong :-)
Let me try to explain ...
Your approach to allow to override this parameter using a property is good.
I'm doing it to validate a new version of my repository manager and so on.
But how you are doing it is wrong.
You should avoid to use a profile with activeByDefault activation. Why ?
Because unlike its name could make you think, by default isn't always activated
but only if no other profile is used. Thus as soon as you'll use another
profile (for a release, a ci server, ...) this one won't be here, your property
won't be set, and your deployment will fail.
The recommended solution is to define a default value in the property of you
pom outside of any profile.
This one will be the real default. You'll have it in any case except if you
override the value :
- with a property set in a profile activated in the project
- with a property set in a profile activated in your user settings
- with a property set in the command line (-D)
You can find a sample of that in my corporate pom :
http://svn.exoplatform.org/projects/parent/trunk/pom.xml
You'll notice I'm using a lot of properties to allow users/projects to easily
override settings they want to change without having to wrige a large block of
xml settings.
Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com
Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier
Blog : http://aheritier.net
On Oct 4, 2010, at 9:04 PM, Phillip Hellewell wrote:
On Mon, Oct 4, 2010 at 12:43 PM, Phillip Hellewell ssh...@gmail.com wrote:
On Mon, Oct 4, 2010 at 12:31 PM, Anders Hammar and...@hammar.net wrote:
Are you seeing the pattern yet? Don't fight Maven!
Hehe, yeah I am. But using a parent pom for this setting is still not
making complete sense to me, so I've got to play with it some more and
hopefully it will.
Ok, I figured out what I feel is a valid and good solution. Not sure
why I didn't think of this before, but in the default profile in my
settings.xml I can simply define a property called repos.url, right
where I define my repository. Then I can use that same property in my
distributionManagement section in any of my poms that I want to.
So something like this goes in my settings.xml:
profiles
profile
iddefault/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
repos.urlfile:///c:/test123/repos.url
/properties
repositories
repository
idtest123/id
nametest/name
url${repos.url}/url
/repository
/repositories
/profile
/profiles
And something like this goes in my pom files:
distributionManagement
repository
idmyrepos/id
url${repos.url}/url
/repository
/distributionManagement
The other advantage here is that I can pass in repos.url on the
command-line with -D if I want to deploy to another repository.
I hope you won't tell me this is the wrong way, because it seems
like a perfectly valid approach to me.
Phillip
-
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: Can't specify distributionManagement in settings.xml
2010/10/4 Arnaud Héritier aherit...@gmail.com: Wrong :-) Let me try to explain ... Your approach to allow to override this parameter using a property is good. I'm doing it to validate a new version of my repository manager and so on. But how you are doing it is wrong. I didn't know I could define properties outside of a profile section. Let me give it a try... Thanks, Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
I don't think it is arbitary. Where you deploy your artifacts TO, I think should be fixed. I think that is the intent. It is a one off thing that is applicable to the build at hand and isn't something you will want to try and reproduce at a later date (like building from a tag). In this case it is good to know that if you run a mvn deploy, you'll know exactly where the artifact will go. Using it as a property or variable in this case I think isn't a good thing. Think of this way. You want to have complete control over the artifacts that your build produces. Something fixed... predicatable. The artifacts that are produced by some other project that you need as depedendencies; you should have control over where they will be found and that may change over time. These are thus not fixed. But that is my view. Fill your boots if you wish to define it as a property ;-). -Original Message- From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] Sent: Monday, October 04, 2010 3:24 PM To: Maven Users List Subject: RE: Can't specify distributionManagement in settings.xml -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Hehe. Not so sure I'd say wrong, but definitely unnecessary. Why are you opposed to putting this information in a the distribution management section of a parent pom? See the email I wrote in the Company-wide settings thread (Message-ID: 9d29fd18cbd74a478cba86e6ef6dbad40590a...@chi4evs04.corp.transunion.com ). If you put this in a parent pom, it becomes very hard to change it, and this feels like arbitrary, mutable, local configuration that shouldn't get hard coded into the builds. Phillip's idea of using a property sounds pretty useful to me. (thanks!) 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: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com wrote: 2010/10/4 Arnaud Héritier aherit...@gmail.com: Wrong :-) Let me try to explain ... Your approach to allow to override this parameter using a property is good. I'm doing it to validate a new version of my repository manager and so on. But how you are doing it is wrong. I didn't know I could define properties outside of a profile section. Let me give it a try... Crap, you can't do that in a settings.xml. To do it outside of a profile section it has to be in a pom, so that leads me back to having to use a parent or corporate pom :( Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
Hehe. It always gets back to that. Not sure why your hung up over it ;-). What Arnaud is saying does make more sense to me. There is at least a fixed place in some POM in source control which defines the default location of where to deploy to. At least this is tracable. I am not really all that found of making it a variable though. That just sounds like extra work for very little gain. -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 3:40 PM To: Maven Users List Subject: Re: Can't specify distributionManagement in settings.xml On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com wrote: 2010/10/4 Arnaud Héritier aherit...@gmail.com: Wrong :-) Let me try to explain ... Your approach to allow to override this parameter using a property is good. I'm doing it to validate a new version of my repository manager and so on. But how you are doing it is wrong. I didn't know I could define properties outside of a profile section. Let me give it a try... Crap, you can't do that in a settings.xml. To do it outside of a profile section it has to be in a pom, so that leads me back to having to use a parent or corporate pom :( Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I don't think it is arbitary. Where you deploy your artifacts TO, I think should be fixed. I think that is the intent. It is a one off thing that is applicable to the build at hand and isn't something you will want to try and reproduce at a later date (like building from a tag). In this case it is good to know that if you run a mvn deploy, you'll know exactly where the artifact will go. Using it as a property or variable in this case I think isn't a good thing. I can see where you're coming from, and of course I don't plan on having where we deploy to change very often, but I don't see any big reason to prevent an override. But anyway, that is neither here nor there for me. The big problem issue for me right now is why should I be forced to do everything through a parent pom instead of in a settings.xml file? I don't understand why certain settings should have to be in a pom that has to be deployed. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
yes, which is a best practice :-) It can work like that too : - In your pom you put the distributionMgt with the property - in your settings you create a profile with this property but instead of using an activation activateByDefault you define it in activatedProfiles list. It will work but I think Maven 3 will write a warning because your build is dependent of your environment (which is wrong). In Maven 3 we didn't touch to settings nor pom but we have always in mind to propose more interesting features in a near future. Like mixins which will allow to integrate several parts of pom or settings Arnaud On Oct 4, 2010, at 9:39 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com wrote: 2010/10/4 Arnaud Héritier aherit...@gmail.com: Wrong :-) Let me try to explain ... Your approach to allow to override this parameter using a property is good. I'm doing it to validate a new version of my repository manager and so on. But how you are doing it is wrong. I didn't know I could define properties outside of a profile section. Let me give it a try... Crap, you can't do that in a settings.xml. To do it outside of a profile section it has to be in a pom, so that leads me back to having to use a parent or corporate pom :( Phillip - 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: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 1:43 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Hehe. It always gets back to that. Not sure why your hung up over it ;-). Well, I'm going to do some more tests now to see if I can get this working with a parent pom. If I run into an error that I can't figure out you'll probably hear from me :) But I do have one question first. Is there any possible way to do a deploy without any distributionManagement section in your pom, and to just pass the URL on the command-line? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
I think where you deploy to isn't in the settings.xml file because there there is no need for it. Where you get artifacts from does have a specific need. It sounds like a nice to have feature, but I don't think there is a dire need for it from the community. But anyway, that is neither here nor there for me. The big problem issue for me right now is why should I be forced to do everything through a parent pom instead of in a settings.xml file? I don't understand why certain settings should have to be in a pom that has to be deployed.
RE: Can't specify distributionManagement in settings.xml
-Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] I don't think it is arbitary. Where you deploy your artifacts TO, I think should be fixed. I think that is the intent. It is a one off thing that is applicable to the build at hand and isn't something you will want to try and reproduce at a later date (like building from a tag). In this case it is good to know that if you run a mvn deploy, you'll know exactly where the artifact will go. Using it as a property or variable in this case I think isn't a good thing. Think of this way. You want to have complete control over the artifacts that your build produces. Something fixed... predicatable. The artifacts that are produced by some other project that you need as depedendencies; you should have control over where they will be found and that may change over time. These are thus not fixed. Sure, it makes sense to have complete control for what actually gets created as the artifact. Where you deploy it to can depend on where you happen to be building. For instance, where I work we recently starting using a new set of servers for our development environment. The url that our nexus server is at is different for one environment than the other. (in one environment it's actually a transparent proxy that forwards connections over a tunnel that was only available for use by that one server) To get things to work, we had to change every single project that we have to use a new parent pom. And once we changed a project, we could no longer build in the old environment. We still ended up with the exact same artifacts as before, but we were just deploying them to a different server. We had no need to perform a new release of any of our projects for any other reason, but we still needed to change everything. That sucks. Anyway, it sounds like Phillip's solution with the property references would eliminate these issues. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
It is interesting to have it variable in several cases : - You want to validate your builds on several environments. I'm just moving my infrastructure and I'm very happy to have that because I'm able to run a secondary build environment (svn/hudson/nexus) without touching our production used by developers - You want to deploy the project in another repository because you are forking it (for an OSS project) and you can redefine this property instead of using the -DaltDeploymentRepository of the deploy plugin which has severals bugs. On Oct 4, 2010, at 9:43 PM, Thiessen, Todd (Todd) wrote: Hehe. It always gets back to that. Not sure why your hung up over it ;-). What Arnaud is saying does make more sense to me. There is at least a fixed place in some POM in source control which defines the default location of where to deploy to. At least this is tracable. I am not really all that found of making it a variable though. That just sounds like extra work for very little gain. -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Monday, October 04, 2010 3:40 PM To: Maven Users List Subject: Re: Can't specify distributionManagement in settings.xml On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell ssh...@gmail.com wrote: 2010/10/4 Arnaud Héritier aherit...@gmail.com: Wrong :-) Let me try to explain ... Your approach to allow to override this parameter using a property is good. I'm doing it to validate a new version of my repository manager and so on. But how you are doing it is wrong. I didn't know I could define properties outside of a profile section. Let me give it a try... Crap, you can't do that in a settings.xml. To do it outside of a profile section it has to be in a pom, so that leads me back to having to use a parent or corporate pom :( Phillip - 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: Can't specify distributionManagement in settings.xml
The pattern I was talking about was all the issues Philip runs into as he was trying to not follow the Maven way. /Anders On Mon, Oct 4, 2010 at 21:07, Haszlakiewicz, Eric ehas...@transunion.comwrote: -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Are you seeing the pattern yet? Don't fight Maven! So what IS the pattern here? How do you actually configure the distribution management if you're not going to put it in a parent pom? Saying don't fight maven is rather useless if you don't explain how you're actually supposed to get things to work. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
mvn deploy -DaltDeploymentRpository=... But some times ago there was a bug which disallow to use it without a distribMgt part in the pom :( Arnaud Héritier Software Factory Manager http://www.exoplatform.com Phone : +33 (0)6 89 74 64 24 Skype : aheritier Twitter : @aheritier Blog : http://aheritier.net On Oct 4, 2010, at 9:48 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 1:43 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Hehe. It always gets back to that. Not sure why your hung up over it ;-). Well, I'm going to do some more tests now to see if I can get this working with a parent pom. If I run into an error that I can't figure out you'll probably hear from me :) But I do have one question first. Is there any possible way to do a deploy without any distributionManagement section in your pom, and to just pass the URL on the command-line? Phillip - 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: Company-wide settings
Specifically, you'll run into issues when you need to change the distribution urls. To do that I need to either deploy a new release of the parent pom and change *all* of the other project poms to refer to the new release, or go manually remove the parent pom from nexus and deploy a changed one (which has all sorts of other problems). bleh. Oh no, never NEVER remove (or alter) an artifact from a maven repo! /Anders
Re: Maven 2 3 + Hudson + Nexus
Is it the snapshot metadata? Are you using Nexus 1.7.2 or earlier? If so, search the nexus mailing list for a patch or upgrade to Nexus 1.8.0. /Anders On Mon, Oct 4, 2010 at 20:58, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: Hi all, I think I've kind of painted myself into a corner. I have a fairly common setup of Maven (2.2.1) + Nexus + Hudson. This all works like a charm (of course). Locally, I've been using Maven 3 (beta 3, RC1, RC2) to make sure that we would be able to make the jump without problems. Apparently, I did something (presumably a release) that screwed things up. One of the builds is now failing on Hudson and I can reproduce the issue locally ... if I use Maven 2. With Maven 3 it all works as it should. I first thought I'd simply tell Hudson to start using Maven 3 too but Hudson does not support this (it can't even start Maven 3). I don't understand what the issue is, really. I can't see a difference between the old metadata and the new (not that I paid much attention to it before, of course :-) ). Maven 2 doesn't even make a request to Nexus and therefore doesn't find the snapshot POM it's looking for. Maven 3 does make the request and everything works. I redeployed (through Hudson) the relevant snapshot POM but the problematic build still fails because it can't find this POM. Any ideas how I can fix this? Any ideas as to what the problem is exactly? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
That makes sense to me (to a certain extent). It is nice to have it as an override feature. But in my view I think it important to have that default deploy location defined in a pom somewhere. We went through a very similar transition scenario that you explain here and I found it very useful to keep this information in the parent pom and simply use a SNAPSHOT version for a while until the bugs were ironed out. It was good to know that version X of our project was deploying to repository A and version X+1 was deploying repository B. You make this a variable and you don't know what version of your software deployed to where. This I think can making debugging more difficult and confusing. -Original Message- From: Arnaud Héritier [mailto:aherit...@gmail.com] Sent: Monday, October 04, 2010 3:52 PM To: Maven Users List Subject: Re: Can't specify distributionManagement in settings.xml It is interesting to have it variable in several cases : - You want to validate your builds on several environments. I'm just moving my infrastructure and I'm very happy to have that because I'm able to run a secondary build environment (svn/hudson/nexus) without touching our production used by developers - You want to deploy the project in another repository because you are forking it (for an OSS project) and you can redefine this property instead of using the -DaltDeploymentRepository of the deploy plugin which has severals bugs. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
2010/10/4 Arnaud Héritier aherit...@gmail.com: mvn deploy -DaltDeploymentRpository=... But some times ago there was a bug which disallow to use it without a distribMgt part in the pom :( Thanks. Unfortunately, it appears that Maven 2.2.1 still has this bug :( Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 3 + Hudson + Nexus
On 4 October 2010 13:01, Anders Hammar and...@hammar.net wrote: Is it the snapshot metadata? Are you using Nexus 1.7.2 or earlier? If so, search the nexus mailing list for a patch or upgrade to Nexus 1.8.0. I'm not sure whether it's the snapshot metadata or not. I can't see anything special there. How can I tell? Like I said, Maven doesn't seem to be even asking Nexus for data. It just stops and complains it can't find the POM. I've already upgraded to Nexus 1.8.0. Hudson is 1.379. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Can't specify distributionManagement in settings.xml
-Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On The pattern I was talking about was all the issues Philip runs into as he was trying to not follow the Maven way. So, again, I ask: what IS the pattern? What IS the Maven way in this situation? It is not at all clear. You're claiming he's not following it, but you haven't explained just what it is about what he is doing that you think deviates from the way things are supposed to work. eric On Mon, Oct 4, 2010 at 21:07, Haszlakiewicz, Eric ehas...@transunion.comwrote: -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Are you seeing the pattern yet? Don't fight Maven! So what IS the pattern here? How do you actually configure the distribution management if you're not going to put it in a parent pom? Saying don't fight maven is rather useless if you don't explain how you're actually supposed to get things to work. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On The pattern I was talking about was all the issues Philip runs into as he was trying to not follow the Maven way. So, again, I ask: what IS the pattern? What IS the Maven way in this situation? It is not at all clear. You're claiming he's not following it, but you haven't explained just what it is about what he is doing that you think deviates from the way things are supposed to work. Yeah, part of the problem is I still haven't got this working with a parent pom, and I don't even know exactly what is meant by a parent pom (I assume it was using the parent tag, but I'm running into issues there...) I do appreciate everyone's responses, and I do want to follow the Maven way as much as possible, but I also want to avoid making things more difficult for no reason. I am getting a better picture now of how many feel it is good to have the default deploy location in a pom somewhere, but I still haven't been convinced that it is absolutely necessity, and I'm not sure it is worth dealing with the hassle when moving the repository to a new server. I'll play with it some more to see if I can get it working. But at the moment I'm still leaning towards just putting a property in settings.xml, since that seems easy and I don't see any problem. And as long as I use the activatedProfiles instead of activateByDefault (as Arnaud suggested) I can avoid the issue of that profile not being active. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On 04/10/2010 3:46 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I don't think it is arbitary. Where you deploy your artifacts TO, I think should be fixed. I think that is the intent. It is a one off thing that is applicable to the build at hand and isn't something you will want to try and reproduce at a later date (like building from a tag). In this case it is good to know that if you run a mvn deploy, you'll know exactly where the artifact will go. Using it as a property or variable in this case I think isn't a good thing. I can see where you're coming from, and of course I don't plan on having where we deploy to change very often, but I don't see any big reason to prevent an override. But anyway, that is neither here nor there for me. The big problem issue for me right now is why should I be forced to do everything through a parent pom instead of in a settings.xml file? I don't understand why certain settings should have to be in a pom that has to be deployed. Phillip I did warn you that you were going to get help from some very smart people with a lot of experience!!! As a less qualified person, I found it pretty easy to think of this problem as follows: 1) I use the dependency repository to specify where any external or internal artifact comes from. Their source for dependencies does not depend on which project one is working on. It depends on where the dependency lives. This is immutable and not project specific. Nexus proxies all sources so people only have to specify Nexus to get any dependency regardless of whether it is our code, an artifact from Maven Central, an artifact from a third party Maven repository or a dependency that I had to download and manually add to my repo because of licensing issues. Thus the dependency repository information goes in settings.xml since that is used for all projects and contains the developers credentials to access the Nexus repo. 2) Deployment could be project specific so it goes in the project's parent POM which is almost immutable for the entire release and the deployment management is completely immutable in our case, since we deploy to our Nexus repo in either the SNAPSHOT repo or the release repo. Both deployment destinations are defined in the POM and Maven knows what to do without being told. Maven uses the person's credentials from their settings.xml so they are not in the project POM. We are not using Hudson, so we do not have to worry about that. Ron - 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 2 3 + Hudson + Nexus
Check policy settings of any repository definition from where problematic (snapshot) dependency is supposed to be fetched from. Maybe you'll reproduce issue locally once you clean your local repository (probably dependency artifact is there so you can build locally but hudson can not access repository where dependency artifact resides). Also if you're using alternate settings.xml to configure repository access there's a known bughttp://issues.hudson-ci.org/browse/HUDSON-4693in hudson. Regards, Stevo. On Mon, Oct 4, 2010 at 10:16 PM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 4 October 2010 13:01, Anders Hammar and...@hammar.net wrote: Is it the snapshot metadata? Are you using Nexus 1.7.2 or earlier? If so, search the nexus mailing list for a patch or upgrade to Nexus 1.8.0. I'm not sure whether it's the snapshot metadata or not. I can't see anything special there. How can I tell? Like I said, Maven doesn't seem to be even asking Nexus for data. It just stops and complains it can't find the POM. I've already upgraded to Nexus 1.8.0. Hudson is 1.379. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
On 10/4/10 2:34 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 12:30 PM, Anders Hammar and...@hammar.net wrote: Philip, with all due respect, but reading your posts I get the impression you're doing your best not to follow Maven best practice. Maven is all about convention and best practice patterns. Please acknowledge that our advice is based on actual experience and going your own path will surely get you into trouble! It's not really a matter of what you think, but rather what Maven thinks. :-) Ok, slow down everyone. No worries. I just did a test and have found that this approach fails miserably. It apparently wants the parent pom to be available whenever I depend on this project, so obviously this doesn't work. No, there's a lot of cause to worry. Because some poor shmuck is going to read this thread a year from now and think that there's actually a valid debate about where to put distributionManagement. There's not. It goes in the pom. The failure is that you need to deploy your parent POM to a Maven repository. That's the bootstrap problem. It's been discussed and documented. So no worries, I'm fully convinced that I want to use settings.xml to specify repositories. But I'm still trying to find the best way to specify a distributionManagement in each of my poms without duplicating the url. Put the URL in a parent POM. Deploy the parent POM to a repository. End of story. Justin Phillip - 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: Can't specify distributionManagement in settings.xml
On Mon, Oct 4, 2010 at 4:28 PM, Phillip Hellewell ssh...@gmail.com wrote: I am getting a better picture now of how many feel it is good to have the default deploy location in a pom somewhere, but I still haven't been convinced that it is absolutely necessity, and I'm not sure it is worth dealing with the hassle when moving the repository to a new server. How often do you expect that to happen? The repository is central to the build infrastructure and needs to be very, very stable. Not only uptime, but as you're anticipating, not moving around too much. In practice though, changing the repo url once every few years provides an excuse to force projects who are lagging behind to update to the latest corporate parent pom and pick up all the new configuration you've tried to impose on them. ;) ) In any case you can reduce the need to change the repo url by putting something in front of it (VIP device, httpd as a proxy, etc.) -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
One of the absolutely best way to understand some of the patterns/best practice is to look at examples. For instance, look at how things (like parent poms) are structured at Apache, Codehaus or even Sonatype. One example: http://repo2.maven.org/maven2/org/codehaus/codehaus-parent/3/codehaus-parent-3.pom /Anders On Mon, Oct 4, 2010 at 22:33, Ron Wheeler rwhee...@artifact-software.comwrote: On 04/10/2010 3:46 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: I don't think it is arbitary. Where you deploy your artifacts TO, I think should be fixed. I think that is the intent. It is a one off thing that is applicable to the build at hand and isn't something you will want to try and reproduce at a later date (like building from a tag). In this case it is good to know that if you run a mvn deploy, you'll know exactly where the artifact will go. Using it as a property or variable in this case I think isn't a good thing. I can see where you're coming from, and of course I don't plan on having where we deploy to change very often, but I don't see any big reason to prevent an override. But anyway, that is neither here nor there for me. The big problem issue for me right now is why should I be forced to do everything through a parent pom instead of in a settings.xml file? I don't understand why certain settings should have to be in a pom that has to be deployed. Phillip I did warn you that you were going to get help from some very smart people with a lot of experience!!! As a less qualified person, I found it pretty easy to think of this problem as follows: 1) I use the dependency repository to specify where any external or internal artifact comes from. Their source for dependencies does not depend on which project one is working on. It depends on where the dependency lives. This is immutable and not project specific. Nexus proxies all sources so people only have to specify Nexus to get any dependency regardless of whether it is our code, an artifact from Maven Central, an artifact from a third party Maven repository or a dependency that I had to download and manually add to my repo because of licensing issues. Thus the dependency repository information goes in settings.xml since that is used for all projects and contains the developers credentials to access the Nexus repo. 2) Deployment could be project specific so it goes in the project's parent POM which is almost immutable for the entire release and the deployment management is completely immutable in our case, since we deploy to our Nexus repo in either the SNAPSHOT repo or the release repo. Both deployment destinations are defined in the POM and Maven knows what to do without being told. Maven uses the person's credentials from their settings.xml so they are not in the project POM. We are not using Hudson, so we do not have to worry about that. Ron - 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 2 3 + Hudson + Nexus
On 4 October 2010 13:38, Stevo Slavić ssla...@gmail.com wrote: Check policy settings of any repository definition from where problematic (snapshot) dependency is supposed to be fetched from. The Nexus setup is as follows: Public Repositories (group) contains Public Snapshot Repositories (group) contains Company Snapshots (proxy) uses Remote Repository (snapshots). The proxy has policy snapshots. The group repositories don't seem to have a policy. This has been working before so I think it's okay. Maybe you'll reproduce issue locally once you clean your local repository (probably dependency artifact is there so you can build locally but hudson can not access repository where dependency artifact resides). Actually I *can* reproduce the issue locally. All I need to do is remove the problematic POM from my local repository and use Maven 2. With Maven 3, however, there is no issue. Also if you're using alternate settings.xml to configure repository access there's a known bughttp://issues.hudson-ci.org/browse/HUDSON-4693in hudson. I am not using an alternate settings.xml. It's all in /home/user/.m2/settings.xml. Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 3 + Hudson + Nexus
OK. There is currently a vote for Maven 3.0 (final) on the dev list, so if you've found an issue this would be the time to tell them about it. /Anders On Mon, Oct 4, 2010 at 22:50, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 4 October 2010 13:38, Stevo Slavić ssla...@gmail.com wrote: Check policy settings of any repository definition from where problematic (snapshot) dependency is supposed to be fetched from. The Nexus setup is as follows: Public Repositories (group) contains Public Snapshot Repositories (group) contains Company Snapshots (proxy) uses Remote Repository (snapshots). The proxy has policy snapshots. The group repositories don't seem to have a policy. This has been working before so I think it's okay. Maybe you'll reproduce issue locally once you clean your local repository (probably dependency artifact is there so you can build locally but hudson can not access repository where dependency artifact resides). Actually I *can* reproduce the issue locally. All I need to do is remove the problematic POM from my local repository and use Maven 2. With Maven 3, however, there is no issue. Also if you're using alternate settings.xml to configure repository access there's a known bughttp://issues.hudson-ci.org/browse/HUDSON-4693in hudson. I am not using an alternate settings.xml. It's all in /home/user/.m2/settings.xml. Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't specify distributionManagement in settings.xml
On 04/10/2010 4:28 PM, Phillip Hellewell wrote: On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On The pattern I was talking about was all the issues Philip runs into as he was trying to not follow the Maven way. So, again, I ask: what IS the pattern? What IS the Maven way in this situation? It is not at all clear. You're claiming he's not following it, but you haven't explained just what it is about what he is doing that you think deviates from the way things are supposed to work. Yeah, part of the problem is I still haven't got this working with a parent pom, and I don't even know exactly what is meant by a parent pom (I assume it was using theparent tag, but I'm running into issues there...) ??? Should not be any there. I do appreciate everyone's responses, and I do want to follow the Maven way as much as possible, but I also want to avoid making things more difficult for no reason. You shouldn't have to pioneer any of this. It does not appear that your environment or development goals are really outside of normal practice so you should not have to derive new ways to get your projects built. I am getting a better picture now of how many feel it is good to have the default deploy location in a pom somewhere, but I still haven't been convinced that it is absolutely necessity, and I'm not sure it is worth dealing with the hassle when moving the repository to a new server. If you use a virtual hostname for addressing your Nexus, you can move your repo without changing everyone's settings.xml. Not something that happens every year anyway. I'll play with it some more to see if I can get it working. But at the moment I'm still leaning towards just putting a property in settings.xml, since that seems easy and I don't see any problem. And as long as I use the activatedProfiles instead of activateByDefault (as Arnaud suggested) I can avoid the issue of that profile not being active. Never used profiles. Phillip - 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
first plugin
Hello,
I'm currently writing my first plugin and am struggling with very basics.
From the guide
(http://maven.apache.org/guides/plugin/guide-java-plugin-development.html)
I understood that if I
specify a goal in a javadoc annotation I will able to call it later
directly, but I fail to achieve it. In my plugin I'm annotating the
code with generate:
/**
* Generates ano-doc classes.
*
* @goal generate
* @phase generate-sources
* @execute phase=generate-sources
*
*/
public class GeneratorMojo extends AbstractMojo{
public void execute() throws MojoExecutionException,
MojoFailureException {
getLog().info(Y HEI);
}
}
After the packaging, and installing, and running from the directory I
want to use it:
anot...@colin:~/projects/aos/ano-site$ mvn ano-doc:generate
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Required goal not found: ano-doc:generate in
net.anotheria:maven-ano-doc-plugin:1.0-SNAPSHOT
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Oct 04 23:48:07 CEST 2010
[INFO] Final Memory: 8M/81M
My plugin pom looks like this:
project
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIdmaven-ano-doc-plugin/artifactId
packagingmaven-plugin/packaging
version1.0-SNAPSHOT/version
nameAnoDoc Generator for Maven/name
distributionManagement
!--omited--
/distributionManagement
dependencies
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-plugin-api/artifactId
version2.0/version
/dependency
/dependencies
/project
my pom in which I intend to use the new project :
build
plugins
plugin
groupIdnet.anotheria/groupId
artifactIdmaven-ano-doc-plugin/artifactId
version1.0-SNAPSHOT/version
executions
execution
phasegenerate-sources/phase
goals
goalgenerate/goal
/goals
/execution
/executions
/plugin
/plugins
/build
any help would be greatly appreciated
regards
Leon
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 3 + Hudson + Nexus
Hilco Wijbenga wrote: Any ideas how I can fix this? Any ideas as to what the problem is exactly? I personally find it helpful to start with a precise description of what the issue actually is before trying to solve it. After all, there's a reason why the build produces a log and even if you can't spot the relevant pieces in there, others might be able to. So sharing the log of the failing module would be a good start. And with log, I don't mean the single line that says [ERROR], I mean the entire log that shows the actions taken by Maven that eventually lead to the error and contribute to the context required to understand the issue. If the log cannot be attached to the mail, using pastebin.com or similar can help. Other things that are nice to know is the directory listing of the directory in the local repo that contains the POM in question. Last but not least, the contents of all maven-metadata-*.xml in that directory can help to troubleshoot that issue. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: first plugin
Hard to tell from this code. Check the plugin.xml file which is being
generated. Also mvn help:describe (which uses the plugin.xml
descriptor IIRC).
Also, my guess is that you don't actually want to include this line:
* @execute phase=generate-sources
But I doubt that's the source of the error below.
Justin
On Mon, Oct 4, 2010 at 5:50 PM, Leon Rosenberg rosenberg.l...@gmail.com wrote:
Hello,
I'm currently writing my first plugin and am struggling with very basics.
From the guide
(http://maven.apache.org/guides/plugin/guide-java-plugin-development.html)
I understood that if I
specify a goal in a javadoc annotation I will able to call it later
directly, but I fail to achieve it. In my plugin I'm annotating the
code with generate:
/**
* Generates ano-doc classes.
*
* @goal generate
* @phase generate-sources
* @execute phase=generate-sources
*
*/
public class GeneratorMojo extends AbstractMojo{
public void execute() throws MojoExecutionException,
MojoFailureException {
getLog().info(Y HEI);
}
}
After the packaging, and installing, and running from the directory I
want to use it:
anot...@colin:~/projects/aos/ano-site$ mvn ano-doc:generate
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Required goal not found: ano-doc:generate in
net.anotheria:maven-ano-doc-plugin:1.0-SNAPSHOT
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Oct 04 23:48:07 CEST 2010
[INFO] Final Memory: 8M/81M
My plugin pom looks like this:
project
modelVersion4.0.0/modelVersion
groupIdnet.anotheria/groupId
artifactIdmaven-ano-doc-plugin/artifactId
packagingmaven-plugin/packaging
version1.0-SNAPSHOT/version
nameAnoDoc Generator for Maven/name
distributionManagement
!--omited--
/distributionManagement
dependencies
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-plugin-api/artifactId
version2.0/version
/dependency
/dependencies
/project
my pom in which I intend to use the new project :
build
plugins
plugin
groupIdnet.anotheria/groupId
artifactIdmaven-ano-doc-plugin/artifactId
version1.0-SNAPSHOT/version
executions
execution
phasegenerate-sources/phase
goals
goalgenerate/goal
/goals
/execution
/executions
/plugin
/plugins
/build
any help would be greatly appreciated
regards
Leon
-
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 2 3 + Hudson + Nexus
When I mentioned repository policy settings, I actually meant on repository definition in your pom.xml or settings.xml and it's update policy. By default it's daily. Have you tried forcing updating snapshots with -U switch? Regards, Stevo. On Tue, Oct 5, 2010 at 12:37 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 4 October 2010 14:57, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hilco Wijbenga wrote: Any ideas how I can fix this? Any ideas as to what the problem is exactly? I personally find it helpful to start with a precise description of what the issue actually is before trying to solve it. After all, there's a reason why the build produces a log and even if you can't spot the relevant pieces in there, others might be able to. So sharing the log of the failing module would be a good start. And with log, I don't mean the single line that says [ERROR], I mean the entire log that shows the actions taken by Maven that eventually lead to the error and contribute to the context required to understand the issue. If the log cannot be attached to the mail, using pastebin.com or similar can help. Other things that are nice to know is the directory listing of the directory in the local repo that contains the POM in question. Last but not least, the contents of all maven-metadata-*.xml in that directory can help to troubleshoot that issue. Here you go. I didn't see anything useful in the log files but you're right of course, somebody else might. I've attached the results of running Maven 2.2.1 (maven2.txt) and the (partial, until just after the successful retrieval of the problematic POM) results of running Maven 3.0 (RC2) (maven3.txt). (The download link to RC3 is no longer valid so I have not been able to try it with RC3.) I've emptied the local repository directory with the problematic POM file so that Maven has to redownload it. So nothing useful there. (It stays empty because Maven 2 doesn't download anything.) After running Maven 3, I get: hi...@centaur $ ls ~/.m2/repository/com/xyz/test-dependencies-pom/5-SNAPSHOT/ _maven.repositories maven-metadata-all-mirror.xml maven-metadata-all-mirror.xml.sha1 resolver-status.properties test-dependencies-pom-5-20101004.184333-6.pom test-dependencies-pom-5-20101004.184333-6.pom.sha1 test-dependencies-pom-5-SNAPSHOT.pom The maven-metadata.xml that Nexus sees: metadata groupIdcom.igniteplay/groupId artifactIdtest-dependencies-pom/artifactId version5-SNAPSHOT/version versioning snapshot timestamp20101004.184333/timestamp buildNumber6/buildNumber /snapshot lastUpdated20101004184339/lastUpdated /versioning /metadata and the directory listing that Nexus sees: maven-metadata.xml maven-metadata.xml.md5 maven-metadata.xml.sha1 test-dependencies-pom-5-20101002.073647-5.pom test-dependencies-pom-5-20101002.073647-5.pom.sha1 test-dependencies-pom-5-20101004.184333-6.pom test-dependencies-pom-5-20101004.184333-6.pom.sha1 I hope that sheds some light on things. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 3 + Hudson + Nexus
On 4 October 2010 15:49, Stevo Slavić ssla...@gmail.com wrote: When I mentioned repository policy settings, I actually meant on repository definition in your pom.xml or settings.xml and it's update policy. By default it's daily. Have you tried forcing updating snapshots with -U switch? Thanks, I really appreciate the help. Given that I've removed the entire directory in my local repository, the update policy in my settings.xml should not matter, right? Anyway, I tried it and it did not make any difference. Same for the -U. :-( - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
On Mon, Oct 4, 2010 at 2:49 PM, Justin Edelson justinedel...@gmail.com wrote: On 10/4/10 2:34 PM, Phillip Hellewell wrote: Ok, slow down everyone. No worries. I just did a test and have found that this approach fails miserably. It apparently wants the parent pom to be available whenever I depend on this project, so obviously this doesn't work. No, there's a lot of cause to worry. Because some poor shmuck is going to read this thread a year from now and think that there's actually a valid debate about where to put distributionManagement. There's not. It goes in the pom. This was the email thread about where to put repositories, not distributionManagement. For repositories I have been told settings.xml is the best place. Put the URL in a parent POM. Deploy the parent POM to a repository. End of story. Yes, I'm going to try this for distributionManagement again tomorrow and try to get it working. I'm not sure why it was giving me trouble today. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Company-wide settings
Hi Phillip, This is easy enough to solve IME. Commit a Maven installation to your preferred repository (CVS, SVN, etc.), then all your developers can obtain that installation by checking it out of the repository. If something is changed you can modify settings.xml and commit to the repo, then everyone just has to update. If you need multiple versions just keep multiple copies in the repo. (This is how it works at my company. When Maven 3.0 is released I'll put it in my local workspace, update the settings.xml to point to our Nexus installation, and commit everything. Then I'll send out an email letting everyone know it's there.) Note that if you're using m2eclipse you'll want to point it to this installation (rather than using the embedded installation). ~Daniel -Original Message- From: Phillip Hellewell [mailto:ssh...@gmail.com] Sent: Sunday, October 03, 2010 5:34 PM To: Maven Users List Subject: Company-wide settings I see that Maven can have a settings.xml at both the Global Level and User Level. Is there a way to have a settings.xml that can be referenced (or included) from a pom.xml, whose settings would apply first but could be overridden by a global or user settings.xml. The idea is to have a shared company-level settings.xml with settings like profiles that most developers will want, and to have them automatically available. The alternative is for everyone to manually append it to their global or user-level settings.xml. Phillip - 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 2 3 + Hudson + Nexus
Hilco Wijbenga wrote: (The download link to RC3 is no longer valid so I have not been able to try it with RC3.) The RCs did they job and have been superseded with https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0/ I've emptied the local repository directory with the problematic POM file so that Maven has to redownload it. So nothing useful there. (It stays empty because Maven 2 doesn't download anything.) Seeing Skipping disabled repository central in the log, the next question is what remote repositories do you have configured in the POM and your settings.xml and what are the release/snapshot policies set on them? For example, if the only repository configured is central and you haven't overriden its definition to enable snapshot downloads, the failure shown by Maven 2.x would be the expected result. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2 3 + Hudson + Nexus
Thanks for your help! On 4 October 2010 16:44, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hilco Wijbenga wrote: I've emptied the local repository directory with the problematic POM file so that Maven has to redownload it. So nothing useful there. (It stays empty because Maven 2 doesn't download anything.) Seeing Skipping disabled repository central in the log, the next question is what remote repositories do you have configured in the POM and your settings.xml and what are the release/snapshot policies set on them? For example, if the only repository configured is central and you haven't overriden its definition to enable snapshot downloads, the failure shown by Maven 2.x would be the expected result. Agreed. But why would only Maven 2 complain and not Maven 3 then? I got the impression that Maven 3 is much stricter. Anyway, I thought I had already included my settings.xml but I guess that was an earlier draft. There are no remote repositories in any of my POMs. My settings.xml: ?xml version=1.0 encoding=UTF-8? settings xmlns=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/settings-1.0.0.xsd; mirrors mirror idall-mirror/id nameMirror of Everything/name urlhttp://www.xyz.com/nexus/content/groups/public/url mirrorOf*/mirrorOf /mirror /mirrors profiles profile idsnapshots/id activation activeByDefaulttrue/activeByDefault /activation repositories repository idcentral/id urlhttp://central/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idcentral/id urlhttp://central/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles /settings I also tried this with activeProfilesactiveProfilesnapshots/activeProfile/activeProfiles but that didn't make any difference. What would get Maven to disable repository central? I don't see any reference to central prior to the message you mentioned. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
