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
