Using maven to install in this way is just wrong IMO. You should be able to install your product without the person installing knowing anything about maven.
--- Todd Thiessen > -----Original Message----- > From: eyal edri [mailto:[email protected]] > Sent: Tuesday, January 19, 2010 9:25 AM > To: Maven Users List > Subject: Re: install maven project from repository to local fs > > Another idea came to mind: > > what do you think about the following: > > 1. writing + deploying all the projects to the repository. *(done by > developer).* > 2. write a small maven project on production system (an > install project) : > that uses GMaven (groovy) plugin, to dynamically create a > local pom that will install the required > project. (using http GET or just adding the project as a > dependency and runnnig mvn install...) > > for example, the user can run the project with a parameter > on cli which will contain the project > name to fetch from artifactory. *done by system guy > (installs stuff on > production)* > > anyone used the GMaven plugin? > > Eyal. > > On Tue, Jan 19, 2010 at 4:02 PM, eyal edri > <[email protected]> wrote: > > > I also used the "copy dependencies" option, but again this requires > > you (the developer) to run this from the machine that holds the pom > > file and deploy it (no sure if it supports remote copy). > > > > there might be another option like wayne suggested: > > http://cargo.codehaus.org/ > > > > and using the maven2 plugin: http://cargo.codehaus.org/Maven2+plugin > > > > i'm checking it now... hopefully it help give a solution. > > > > -Eyal > > > > > > > > > > On Tue, Jan 19, 2010 at 3:41 PM, Johannes Schneider < > > [email protected]> wrote: > > > >> On 01/19/2010 11:30 AM, eyal edri wrote: > >> > >>> so you create a 'FAT' jar, as i understand. > >>> > >> > >> Yes. Most of the time. > >> > >> One project uses another approach where all dependencies > are copied > >> to a lib folder. But this has other disadvantages: It > isn't deployed > >> to the > >> repository: > >> ... > >> <plugin> > >> > >> <artifactId>maven-jar-plugin</artifactId> > >> <configuration> > >> <archive> > >> <manifest> > >> > <mainClass>com.cedarsoft.meeting.MeetingTimer</mainClass> > >> <addClasspath>true</addClasspath> > >> <addExtensions /> > >> <classpathPrefix>lib</classpathPrefix> > >> </manifest> > >> </archive> > >> </configuration> > >> </plugin> > >> <plugin> > >> > >> <artifactId>maven-dependency-plugin</artifactId> > >> <executions> > >> <execution> > >> <id>copy-dependencies</id> > >> <phase>package</phase> > >> <goals> > >> <goal>copy-dependencies</goal> > >> </goals> > >> </execution> > >> </executions> > >> > >> <configuration> > >> <includeScope>runtime</includeScope> > >> > <outputDirectory>${project.build.directory}/lib</outputDirectory> > >> </configuration> > >> </plugin> > >> </plugins> > >> ... > >> > >> Other projects use JNLP. There are all jars copied to a lib > >> directory, too. But they are also not deployed to the repository. > >> > >> > >> this can be very troublesome. > >>> > >>> think about a scenario where you need to update one of the > >>> dependencies, and its being used in a lot of application > jars. you > >>> will need to update all the applications jars > >>> > >> > >> Yes, but I have to update all projects anyway: I have to > update the > >> version information within the pom.xml... > >> And "patching" my deployed application (by replacing a dependency > >> jar) seems to be a very bad idea. > >> > >> > >> I see basically two options: > >> - One big super-jar that is deployed to a repository: See shade, > >> minijar and/or assembly plugin). Old versions are > archived, very easy deployment: > >> Just one wget. > >> Disadvantages: Takes more space in the repository (but who cares > >> about disk space today), more to download. > >> > >> - lib directory with dependencies (see example above). > Deployment is > >> a little bit more complicated. I think rsync might be a good > >> solution. Safes disk space and lesser stuff to download. > >> > >> > >> But as long as you don't have problems with disk space, I > suggest the > >> big-jar approach... > >> > >> > >> Sincerly, > >> > >> Johannes > >> > >> > >> > >> > >>> On Tue, Jan 19, 2010 at 12:25 PM, Johannes Schneider< > >>> [email protected] > >>> > >>>> wrote: > >>>> > >>> > >>> On 01/18/2010 07:28 PM, eyal edri wrote: > >>>> > >>>> i'm interested in how people do deploy their apps, even if it's > >>>> not > >>>>> directly > >>>>> connected to maven. > >>>>> > >>>>> > >>>> I create a runnable jar (with all dependencies) or a war > (for web > >>>> applications). That is deployed to the repository. > >>>> That can be downloaded with a one liner using wget. > >>>> > >>>> So I think you shouldn't "install" or do any fancy work on you > >>>> production server but just download the latest > >>>> artifact/jar/war/whatever. > >>>> > >>>> > >>>> Johannes > >>>> > >>>> > >>>> > >>>> maybe i'm biased from our current status, where we use > YUM&RPM to > >>>>> install > >>>>> our perl code on servers. > >>>>> > >>>>> On Mon, Jan 18, 2010 at 8:25 PM, Wayne Fay<[email protected]> > >>>>> wrote: > >>>>> > >>>>> i can't understand how the project goes from being the in > >>>>> repository to > >>>>> > >>>>>> being installed and running on the production server. > >>>>>>> > >>>>>>> > >>>>>> This is outside the domain of Maven. From the website: "Apache > >>>>>> Maven is a software project management and comprehension tool. > >>>>>> Based on the concept of a project object model (POM), > Maven can > >>>>>> manage a project's build, reporting and documentation from a > >>>>>> central piece of information." > >>>>>> > >>>>>> Where does it say "Maven will also help you > deploy/install your > >>>>>> end product into your production environment"? > >>>>>> > >>>>>> How does Ant or another Java build tool support your use case? > >>>>>> > >>>>>> Wayne > >>>>>> > >>>>>> > ----------------------------------------------------------------- > >>>>>> ---- To unsubscribe, e-mail: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------ > >>>>> --- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>>> > >>> > >>> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > Eyal Edri > > > > > > -- > Eyal Edri > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
