You download the install artifacts to your production server and install them. Just like how you would install any software today.
For example, how did you install Maven? You downloaded the artifacts, extracted them and followed the instructions either on the web page or in the extracted readme file. Much of the details depends on how complex your install is and the target your are installing to. In your case, it sounds like you just have some jars. So build an uber jar and have your admins download that jar and run it. If you don't want to build an uber jar, your build should produce a zip which contains all the artifacts your product needs and include a readme file in the zip which clearly details what your end users needs to do to get your product working. If you wish to simplify it further for your end users, your build should build an install artifact for the target system you wish to install it on. For Linux, you would build an rpm. Then your admins would simply download the rpm and install it. If you support running your product on windows, then you could also provide a windows installer artifact. To start though it sounds like you want something very simple so I would recommend you going with an uber jar and build from that. The key here is that you don't need to know what tool was used to build your product in order for an end user to install it. --- Todd Thiessen > -----Original Message----- > From: eyal edri [mailto:[email protected]] > Sent: Tuesday, January 19, 2010 10:06 AM > To: Maven Users List > Subject: Re: install maven project from repository to local fs > > so how do you suggest on doing so? > > let's say you're the sys admin and you know the JARs are in > the repository. > and you need to install them (with dependencies) on the server. > > what do you do? > > (btw, we don't use java application server yet, since we only > deploy classic runnalbe java jars (not web or anything like that). > > On Tue, Jan 19, 2010 at 4:54 PM, Todd Thiessen > <[email protected]> wrote: > > > 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] > > > > > > > -- > Eyal Edri > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
