Maven profiles vs Archetypes
Hello, Being a avid Maven user for years, I have been drilled to avoid using or minimize profiles usage in a Maven build. Even more when it is geared to adapt for a runtime context. I always managed to find a way to convice people to do otherwise until now ... A solution was provided, via Maven profiles, to support different type of build geared to use or not shared libraries for our web applications and our different types of web application servers. Since the basic use case does not require changing the type of build once the archetype is generated, I suggested to do it via templating in the in house archetypes, thus avoiding bloated pom.xml files and scoping the profile use to environment configuration. Other possibilities would be to have completely seperated achetypes, but I think the templating can cover most of our usecases. I got redirected to this link: http://maven.apache.org/guides/introduction/introduction-to-profiles.html Which kind of states the use of profiles for something very similar to what I am trying to prevent. I have looked at the Maven Reference guide, but have not found other literature that could tip the scale. I don't want to end up in a philosophical argument either, so I want to keep thing constructive. Questions : Are there other, more elegant solution that I could propose ? Am I on the right track in my suggestion to use our in-hous archetypes to do the heavy lifting ? Is there 'official' documentation that I could use as references or best practices to try to avoid that kind of profile abuse (or point me in the proper direction if I am wrong to argue) ? Thanks in advance for all the help Patrick In theory, there is no difference between theory and practice, but in practice, there is ...
Re: Maven profiles vs Archetypes
Re, Basically, the end result would be to support multiple teams with multiple web application servers and setup (shared libs vs non shared libs). Thus each internal team does not go back and forth between setups/server. For a vast majority of cases, the decision is done once, at the start of the project, and you live with it. As for the question, like I said previously, the release drives a single artifact 'type', not a portfolio. The profile idea is basically used only to support the initial branching for the teams. Never thought about the Invoker plugin that way. I had suggested of using it to test the templating of the archetypes themselves, but not more. Since using profiles means that you have to execute the build itself to validate, while using the archetype, you test the structure and content of the created project, which I find easier. Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies <bimargul...@gmail.com> wrote: > Once you've run an archetype, you have a new project. And you're stuck > with it, in the sense that you have to keep it maintained. > > An important question is this: what artifacts do you want to make as > part of a release? If you want a portfolio of artifacts, each for one > of your scenarios, then profiles aren't very useful, but the invoker > plugin might be. > > On the other hand, if you never make releases, and you just want to > run various build with various results, then profiles can be > convenient. > > The invoker is generally used for testing, and I've never tried it as > a solution to DRY-ing up a build that has to produce multiple small > variations. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven profiles vs Archetypes
Re, The installer concept *could* fit the bill with some adjustments, it's just that the build process is tweaked dependending on the target web server/deployement type. This would require changes which I don't have much weight to throw at. Has for the multi pom solution, it's actually the thing that the group which is pushing the profile solution want to avoid, because this would require them to build multiple archetype based on the wanted target deployement. That's the reason I was pushing to build it directly into the archetype, thus, having the question asked during the archetype invocation. One archetype could be built to support all the permutations if bonified with some additionnal questions (target container and deploiement type) aside version/groups/artifacts ... Since I went throught profile hell in another life, I want to avoid their abuse and am just trying to build a solid, documented argument and solution that would fit the bill while minimizing the overhead cost. It's a knowned fact from the community to avoid abusing profiles, there is just not a lot of 'official documentation' to ggo with it. Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Mon, Oct 19, 2015 at 1:12 PM, Ben Podgursky <bpodgur...@gmail.com> wrote: > What if your profiles lived in a couple of parent POMs, and the child POMs > inherited from the appropriate parent POMs? We use this setup for many of > our projects. It avoids child POM bloat and lets us update the shared > logic without pushing changes to every project. > > Only limitation is that maven has no multi-inheritance / mixins so you have > to be careful setting up inheritance trees. > > On Mon, Oct 19, 2015 at 9:58 AM, Benson Margulies <bimargul...@gmail.com> > wrote: > > > If each project picks a style and sticks to it, then archetypes are > > appropriate. > > > > On Mon, Oct 19, 2015 at 11:26 AM, Patrick Sansoucy > > <patrick.sanso...@gmail.com> wrote: > > > Re, > > > > > > Basically, the end result would be to support multiple teams with > > multiple > > > web application servers and setup (shared libs vs non shared libs). > Thus > > > each internal team does not go back and forth between setups/server. > For > > a > > > vast majority of cases, the decision is done once, at the start of the > > > project, and you live with it. > > > > > > As for the question, like I said previously, the release drives a > single > > > artifact 'type', not a portfolio. The profile idea is basically used > only > > > to support the initial branching for the teams. > > > > > > Never thought about the Invoker plugin that way. I had suggested of > using > > > it to test the templating of the archetypes themselves, but not more. > > Since > > > using profiles means that you have to execute the build itself to > > validate, > > > while using the archetype, you test the structure and content of the > > > created project, which I find easier. > > > > > > > > > > > > Patrick Sansoucy > > > In theory, there is no difference between theory and practice, but in > > > practice, there is ... > > > > > > On Mon, Oct 19, 2015 at 11:07 AM, Benson Margulies < > > bimargul...@gmail.com> > > > wrote: > > > > > >> Once you've run an archetype, you have a new project. And you're stuck > > >> with it, in the sense that you have to keep it maintained. > > >> > > >> An important question is this: what artifacts do you want to make as > > >> part of a release? If you want a portfolio of artifacts, each for one > > >> of your scenarios, then profiles aren't very useful, but the invoker > > >> plugin might be. > > >> > > >> On the other hand, if you never make releases, and you just want to > > >> run various build with various results, then profiles can be > > >> convenient. > > >> > > >> The invoker is generally used for testing, and I've never tried it as > > >> a solution to DRY-ing up a build that has to produce multiple small > > >> variations. > > >> > > >> - > > >> 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: skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
We use the skinny wars / ear and never had this issue. Maybe a dependency issue with your poms? It may sound stupid, but did you take a look at the dependency tree to make sure the resolution was OK ? On Aug 2, 2013 1:18 PM, Wayne Fay wayne...@gmail.com wrote: Yes, sorry I wasn't clear. I don't want developers who never have to touch research-jpa to be forced to build that project everyday. I was thinking more along the lines of some sort of POM hack... Maven is diametrically opposed to hacks. If there is a good solution to your problem, it should not involve a hack. But there may not (today) be a good solution to your problem (yet). I'm not certain as I haven't been using skinny wars (or ears) lately. Hopefully someone else will pipe up. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3: Problems with SNAPSHOT updates
I always refer people to this Jira ... http://jira.codehaus.org/browse/MNG-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel But Brian's post explains it very well. Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Oct 21, 2011 at 6:29 AM, Brian Parker onebrianpar...@gmail.com wrote: I ran in to this. See http://stackoverflow.com/questions/5249342/maven-3-0-2-u-option-does-not-update-snapshot/7081166#7081166 Brian On Fri, Oct 21, 2011 at 5:13 AM, Dreier Ruediger ruediger.dre...@bdal.dewrote: Hello! Thanks for your answer, but both solutions do not work for me with Maven 3 - both work perfectly with Maven 2.2.1. With Maven 3 only a metadata file is updated, not the artifact itself. Regards, Ruediger -Original Message- From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] Sent: Thursday, 20 October, 2011 17:09 To: Maven Users List Subject: RE: Maven 3.0.3: Problems with SNAPSHOT updates There are two ways. You can force maven to update snapshot by using the - U option. Ie: mvn -U install Or you can change when maven updates snapshots by default by changing the updatePolicy in your settings.xml file. http://maven.apache.org/ref/3.0.3/maven-settings/settings.html -Original Message- From: Dreier Ruediger [mailto:ruediger.dre...@bdal.de] Sent: Thursday, October 20, 2011 11:02 AM To: 'users@maven.apache.org' Subject: Maven 3.0.3: Problems with SNAPSHOT updates Hello! We are currently using Maven 2.2.1 and Artifactory 2.3.4 (rev. 13017) as repository server and I am now evaluating if we can migrate to Maven 3. I am testing Maven 3 in the following environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows I used a very simple POM file for this check: dependencies dependency groupIdde.bdal.common.bcl/groupId artifactIdsettings/artifactId version0.0.0.1-SNAPSHOT/version classifierbinaries/classifier typezip/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.2/version executions execution phaseprocess-resources/phase goals goalunpack-dependencies/goal /goals configuration copyPomtrue/copyPom outputDirectory./target/references/outputDirectory /configuration /execution /executions /plugin /plugins /build On a second PC (our Jenkins build system, still using Maven 2.2.1) the project de.bdal.common.bcl:settings can be build. With an empty local repository, everything works well: 'mvn install' downloads the newest version of de.bdal.common.bcl:settings to my local repository and the dependency plugin extracts it. Then I use Jenkins on the build system to create a new SNAPSHOT build of de.bdal.common.bcl:settings. Now I try to use this new version: 'mvn -U install' only downloads metadata: Downloading: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml Downloaded: http://hbeswbinaries1/repo/de/bdal/common/bcl/settings/0.0.0.1- SNAPSHOT/maven-metadata.xml (319 B at 4.0 KB/sec) and my local repository contains updated files maven-metadata- inhouse.xml, maven-metadata-inhouse.xml.sha1 and resolver- status.properties. But all other files are not changed (especially settings-0.0.0.1-SNAPSHOT-binaries.zip is not updated). However maven- metadata-inhouse.xml contains the correct value for lastUpdate (build time on the server). What am I doing wrong? How do I get updates of snapshot dependencies without deleting my local repository? Thanks for any help, i.A. Rüdiger Dreier Project Manager Bruker Daltonik GmbH Fahrenheitstr. 4 28359 Bremen, Germany Phone: +49 421 2205-393 Fax: +49 421 2205-3005 ruediger.dre...@bdal.demailto:ruediger.dre...@bdal.de www.bruker.comhttp://www.bruker.com/ Sitz der Gesellschaft / Registered Office Bremen; Handelsregister Amtsgericht Bremen HRB 8150 / Commercial Register District Court Bremen HRB 8150; Geschäftsführer / Managing Directors: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich für die
Re: Maven not pulling down latest snapshot jar issue
Is'nt rather related to this Jira that's been there for a while ? http://jira.codehaus.org/browse/MNG-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Sep 30, 2011 at 2:44 PM, Kurt T Stam kurt.s...@gmail.com wrote: Thanks Robert, I tried replacing the aether jar from 1.11 to 1.12 but that did not fix my issue. In my case the meta data is nicely updated by the actual jar and pom etc are still old. I guess I will spend some time with the debugger over the weekend to see what's going on. If anyone has some hints in where to look first then plz let me know! --Kurt On 9/30/11 12:40 PM, Robert Scholte wrote: Sounds like http://jira.codehaus.org/browse/MNG-5087 -Robert Date: Fri, 30 Sep 2011 11:46:19 -0400 From: kurt.s...@gmail.com To: users@maven.apache.org Subject: Maven not pulling down latest snapshot jar issue 1. I'm using maven-3.0.3 and does anyone else have the issue where the latest snapshot jar is NOT downloaded while the meta data IS updated? It sounds a lot like what's being described in this bug report, although the title is misleading http://jira.codehaus.org/browse/MNG-4142, ad it happens when uniqueVersionfalse/uniqueVersion for that repository. 2. I tried applying the patch attached to MNG-4142 to the current trunk, but code seems to have been moved around on the trunk. Maybe someone can point to the current relevant code, so I can maybe submit a patch for it. This issue is pretty nasty as it makes for non reproducible builds. Thx, --Kurt - 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 not pulling down latest snapshot jar issue
My pleasure, Since M2 does the job, most people I've spoken to (including at my own workplace) hold back on M3 ... On top of that, there is the timestamped artifact workaround. I wish this could be higher up in the priority list, just for the fact it will push M3 adoption :( Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Sep 30, 2011 at 5:24 PM, Kurt T Stam kurt.s...@gmail.com wrote: Thanks Patrick, Yep that one is just what I am seeing. Looks like there is more to it then I thought.. Thanks for pointing me in the right direction.. Why aren't more people complaining about this? Is everyone using products like Artifactory to keep the number of snapshot of each artifact down? --Kurt On 9/30/11 3:42 PM, Patrick Sansoucy wrote: Is'nt rather related to this Jira that's been there for a while ? http://jira.codehaus.org/browse/MNG-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Fri, Sep 30, 2011 at 2:44 PM, Kurt T Stamkurt.s...@gmail.com wrote: Thanks Robert, I tried replacing the aether jar from 1.11 to 1.12 but that did not fix my issue. In my case the meta data is nicely updated by the actual jar and pom etc are still old. I guess I will spend some time with the debugger over the weekend to see what's going on. If anyone has some hints in where to look first then plz let me know! --Kurt On 9/30/11 12:40 PM, Robert Scholte wrote: Sounds like http://jira.codehaus.org/browse/MNG-5087 -Robert Date: Fri, 30 Sep 2011 11:46:19 -0400 From: kurt.s...@gmail.com To: users@maven.apache.org Subject: Maven not pulling down latest snapshot jar issue 1. I'm using maven-3.0.3 and does anyone else have the issue where the latest snapshot jar is NOT downloaded while the meta data IS updated? It sounds a lot like what's being described in this bug report, although the title is misleading http://jira.codehaus.org/browse/MNG-4142, ad it happens when uniqueVersionfalse/uniqueVersion for that repository. 2. I tried applying the patch attached to MNG-4142 to the current trunk, but code seems to have been moved around on the trunk. Maybe someone can point to the current relevant code, so I can maybe submit a patch for it. This issue is pretty nasty as it makes for non reproducible builds. Thx, --Kurt - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Issue with mvn3 timestamp snapshots being downloaded in local repository
Maybe a bit harder to implement, and to be honest, I have not opened Maven's hood since the beginning of V2. But why not create the non timestamped snapshot and meta data on the fly locally from the timeshot version, but add meta data to make it behave like some sort of symbolic link/reference to the timestamped version ? Patrick Sansoucy In theory, there is no difference between theory and practice, but in practice, there is ... On Tue, Mar 8, 2011 at 11:31 AM, Wayne Fay wayne...@gmail.com wrote: @Wayne: Do you need that I create a Jira ? That would be the correct next step. But again, I'm not making any statements as to whether or not this will actually occur. It will need to be discussed on the Dev list and in the Jira. I can think of an awful lot of reasons why this should not be implemented -- for one, changing the file name will break the manifest.mf in the archive and possibly other similar files. And I'm not sure the positive side effects of such a change would outweigh the negative ones. 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: Maven 3.0 doesn't update snapshot artifacts
We witnessed the same issue here at work. While the latest Maven 2 works properly, our developpers using Maven 3 had the problem and had to go through the same procedure of deleting the jar within the local repo. We, on the other hand, use archiva for our artifact deployement. It is a major blocker for our dev team to upgrade to M3. I don't know the culprit and I have not tried using the uniqueVersion toggle to timestamp the snapshot, since I need to discuss this change with our CM's. -Patrick On Tue, Nov 23, 2010 at 9:43 AM, Moser, Christian c...@metrohm.com wrote: I'm unable to download the newest artifacts (compiled jar) with maven 3.0 and 3.0.1-RC1 from cmd line. The artifacts were deployed to artifactory 2.3.1. After calling mvn -U on a dependend artifact, maven just updates the metadata, but doesn't override the old artifacts contained in the local repository. I have to delete the local repository to receive the newest artifacts from remote after calling mvn -U. the artifacts are all snapshots version. Is there another, new way to force update snapshots? -Chris - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
