On 18 March 2013 22:52, Stephen Connolly <stephen.alan.conno...@gmail.com>wrote:
> > > > On 18 March 2013 21:48, Joachim Durchholz <j...@durchholz.org> wrote: > >> Am 18.03.2013 12:45, schrieb Stephen Connolly: >> >> I would not base your opinion on this one thread. >>> >>> Joachim got off on the wrong foot by mistaking us trying to guide him >>> towards a path (where he won't fight maven all the way) for us being >>> evangelical and spouting religious dogma... >>> >> >> Just for the record: I heartily disagree with that view of what happened >> there. >> In fact I have reason to believe that such a path doesn't even exist, and >> in more situations than any Maven proponent would like to admit. >> Of course, Maven proponents would heartily disagree with that view, and >> in fact that part of the debate never reached a conclusion (nor will it >> ever, I think). > > > Well I think there is a path, but let's not re-open that whole thing right > now. > > Perhaps when I revamp the docs you might consider reading them and then > respond because I believe at that point you might agree that I had a valid > point and that there is a path... just a path that you don't want to go > down because your experiences have coloured how you evaluate the set of > trade-offs that need to be made. > > >> >> >> > Some of us in this list may >> >>> have egged on the troll vs troll style of this interaction, but the past >>> is >>> a foreign country that we cannot visit, personally I think it should be >>> left behind, fault on both sides, therefore both sides gave some learning >>> to do. >>> >> >> I can agree with that. >> >> >> I am currently working on trying to find a way to revamp the main maven >>> site to make it easier for people to get up to speed and grok the reasons >>> for maven picking the sides it picks as well as grok *where* maven says >>> "not my problem" (anything after a deployment environment agnostic >>> artifact >>> has been delivered into the maven repository is not maven's problem BTW, >>> use other tools: Chef/Puppet/ANT/Gradle/Buildr/**BASH/etc to turn that >>> into >>> an artifact configured for the specific environment it will be deployed >>> into and put it in that environment) >>> >> >> Good plan. >> >> I'd also add a paragraph that Maven is not a toolbox, with the tools to >> be mixed and matched as a desired workflow mandates. Instead, you're >> supposed to study the workflows available, select the one that best fits >> your requirements, and stick with that no matter what. Of course you can >> configure the workflows, but the extent to which that is possible is >> strictly controlled. >> > > I think you really should wait for me to revamp the docs before making > that kind of proposition. > > Maven has one primary lifecycle and considers its core responsibility to > be delivering artifacts that are target agnostic into the maven repository. > What you can do in that lifecycle is very mix and match and a lot more > flexible than you would suspect, but after the end of that lifecycle you > should not be using Maven. > > Handling the mix and match most likely will involve writing either > extensions (unlikely) or plugins (most likely) which will need to be pushed > to a Maven repository... > > If you don't have an internal Maven repository manager to host such > things, or if you cannot push those plugins/extensions to central, then you > might not realize how flexible Maven is in this respect > > >> >> I consider that approach to be a core mistake in Maven's, but I can agree >> to disagree about that one and move on, in the knowledge that little could >> be done about it even if it's true so there's little to be gained in >> discussing that. > > >> What we probably can agree on is that (a) the workflows are implicit in >> what's available in the plugins and what isn't, which makes it hard to get >> an overview of the available workflows and select the right one; > > > There is 1 primary lifecycle: initialize -> ... -> compile -> ... -> test > -> ... -> package -> ... -> verify -> install -> deploy > > There are different packagings: jar/war/ear/etc > > I am guessing that you are referring to these as workflows. > > Defining custom packaging is actually quite trivial, just an XML file in a > .jar that you add as a build extension (or include in a maven plugin). You > can do quite a lot with that. > > The Maven project can only document our packagings and their lifecycles: > pom/jar/war/ear/rar/ejb-jar > > We cannot be responsible for documenting other people's lifecycles. For > example (and I am pointing now at a personal project) the > jszip-maven-plugin defines its own lifecycle: > https://github.com/jszip/jszip-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xmlThe > documentation of that lifecycle is not the responsibility of the Maven > project (or the ASF unless/until I seek to move that project into the ASF, > but that is a separate story). > > I agree that it can be hard to decide what packaging type to pick for your > use case when there are multiple similar ones, e.g. webjars is solving a > similar problem to jszip so if you are packaging up javascript "modules" > for consumption by Maven projects which should you choose? That is a hard > problem. > > But if you are building a .jar file then you really just have three > choices: > 1. <packaging>jar</packaging> (if you don't give a rats arse about > OSGi); > 2. <packaging>bundle</packaging> (if you need OSGi) > 3. your own custom lifecycle if one of the above does not fit your needs. > > But of course the problem that kicked this whole thread off has a simple > solution, one that I mentioned quite some time ago, but I think you > ignored. Namely making proxy modules for each of the 3rd party jars that > you have to consume. They are just a pom.xml in a directory and they attach > the jar you are getting from the file system into the reactor in place of > the jar produced by jar:jar... they look a little something like this: > > <?xml version="1.0" encoding="utf-8"?> > <project 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/maven-v4_0_0.xsd > "> > <modelVersion>4.0.0</modelVersion> > > <groupId>com.foo.bar</groupId> > <artifactId>manchu</artifactId> > <version>1-SNAPSHOT</version> > <packaging>jar</packaging> > > <build> > <plugins> > <plugin> > <artifactId>maven-antrun-plugin</artifactId> > <version>1.7</version> > <executions> > <execution> > <id>attach-artifacts</id> > <phase>package</phase> > <goals> > <goal>run</goal> > </goals> > <configuration> > <target> > <copy file="foobar.jar" > tofile="${project.build.directory}/${project.build.finalName}.jar" > overwrite="true"/> > </target> > </configuration> > </execution> > </executions> > </plugin> > </plugins> > </build> > > </project> > > > You have one of those for each non maven artifact and you just ensure that > the correct dependencies are listed and that these pom files are referenced > in the root aggregator pom and presto-chango there is your build. AFAIR I > even suggested this when you first came to the list. It's a little hacky... > you could do better with a custom lifecycle and your own plugin, but mostly > around removing some boilerplate and simplification of the pom... but that > would require pushing the maven plugin to a MRM (or central) and off we go > again! > Jo, Just for you, I have taken the 30 minutes out of my life and written a Maven Plugin that will solve your issues with those pesky non-maven dependencies. https://github.com/stephenc/non-maven-jar-maven-plugin You will need to wait a couple of hours for the sync to central before you can use that plugin. But it is designed for your exact use-case (adapted to the Maven way of course ;-) ) -Stephen > > >> and (b) the problem is massively worsened if plugin descriptions are >> vague or incomplete, and that this has in fact grown to be a real problem. >> > > Well docs are a problem, and then the slew of poorly written plugins (99% > of the org.apache.maven.plugins and org.codehaus.mojo plugins are not in > this category) with no documentation that don't follow the Maven principles > (and instead just blindly rely on defaults) which make it harder to deviate > from some aspects of the Maven way when it is needed. > > >> Which is why I wholeheartedly agree that Maven could profit from better >> docs. Even if I disagree about what it should do ;-) >> >> Regards, >> Jo >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >
