maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Kolotyluk <eric.koloty...@gmail.com>
Subject Re: Deployment
Date Sat, 02 Mar 2013 03:40:30 GMT
I was not thinking of adding to Maven, rather I was soliciting insight 
from the Maven community because I value their inventiveness.

I am half way toying with the idea of building something myself, but 
first I want to make sure I am not reinventing the wheel.

I have been toying with the idea for a while as a software developer who 
has had to build installers for applications and services, and I am 
often dissatisfied with the experience I get using other people's 
installers. At one time I was playing with the idea of my own installer 
that would be cross platform, but the initial bootstrap would be 
platform dependent, and install enough platform independent stuff, to do 
the rest in a standard way.

For example, a couple years ago I built an installer for a service I was 
working on. It is a very simple .NET Setup.exe, single file executable. 
The first thing it does is make sure there is a JVM present, and 
installs one if there is not. The next thing is does is creates a 
Windows Service. The Windows Service is very simple, it uses jni4net and 
starts up a file called service.jar, which then completed the rest of 
the installation. The whole thing used fat binaries so it worked on a 
variety of Windows platforms, both 32-bit and 64-bit. For OSX and Linux 
I had intended a similar simple executable, that in turn launched the 
same service.jar.

The part I was not too happy with was my service.jar was this ginormous 
uber-jar created with the Assembly plug-in. Sure, everything worked 
perfectly well, and was simple, but when I say ginormous I am very 
serious. If I had had the time, the next thing I was going to do was 
have my installer install Maven, and then bootstrap the rest of the 
pieces by just choosing the right artifact names and versions given the 
system environment I found. Basically, replace the uber-jar with a 
common system-wide repository of jars, and configure the classpath 
appropriately.

I am just thinking out loud and trying to get ideas from people.

Cheers, Eric


On 2013-03-01 5:31 PM, Ron Wheeler wrote:
> My feeling is that this would be a major addition to Maven and would 
> still be missing a lot of stuff.
> It looks more like a CMS with some rules and some processes that 
> construct a zip or an installer.
> You need a lot of flexibility in defining how assets are assembled 
> into the required artifact.
>
> Of course, one could extend Maven but it would almost be a complete 
> rewrite.
>
> I think that we would be better served by looking at what Maven does 
> well and specifying a downstream process that incorporates the ideas 
> that you identified below but into a system that focuses on deployment.
>
> It probably will attract a different type of person to the project.
> I would expect that the Maven team is heavily weighted towards 
> developers as committers.
>
> The design and implementation of this new facility should be driven by 
> system administrators and infrastructure support types who spend their 
> days making applications run in production.
>
>
> Ron
>
>
>
>
>
> On 01/03/2013 8:06 PM, Eric Kolotyluk wrote:
>> Thanks for the pointers Stephen,...
>>
>> http://wiki.opscode.com/display/chef/Chef+Basics
>>
>> https://puppetlabs.com/puppet/what-is-puppet/
>>
>> Ron,...
>>
>> Yes, I remember that deployment was outside the scope of Maven, but 
>> one of the things I like about Maven is the repository concept. I was 
>> advocating extending this concept from the development realm to the 
>> deployment realm sort of the way Microsoft's Global Assembly Cache 
>> (GAC) works, but for open-source artifacts. In particular, we could 
>> leverage existing technology and tools such as Maven, Nexus, Maven 
>> Central, etc.
>>
>> For example, in terms of bootstrapping, you might have a simple 
>> open-source installer the checks to see if there exists a local 
>> system or network GAR (Global Artifact Repository), and if not, 
>> creates one. Then it follows an embedded script, or remote script via 
>> URI, to start populating the GAR with the artifacts needed. Finally, 
>> when it starts deploying actual applications and services, it can 
>> simply build a classpath by referencing locations in the GAR.
>>
>> I was installing Akka recently, and it seemed to be doing something 
>> similar to what I was looking for. There was a small bootstrap 
>> installers, that just kept pulling more and more stuff in.
>>
>> I have a project that is Maven based, and every time I setup my 
>> development environment on a new system, I am simply amazed while I 
>> watch Maven download hundreds of artifacts, and then it just builds 
>> my project. I would like to have this kind of awesome experience in 
>> production deployment tools.
>>
>> Cheers, Eric
>>
>> On 2013-03-01 2:07 PM, Ron Wheeler wrote:
>>> On 01/03/2013 4:26 PM, Eric Kolotyluk wrote:
>>>> A while back we had some interesting discussions on using Maven, or
>>>> maven-like technology for deploying production software. I was 
>>>> wondering if
>>>> anything new has been happening since then.
>>>>
>>>> Basically what I am hoping to see is a generic installer framework 
>>>> that
>>>> bootstraps deployment of a production system or service the way Maven
>>>> bootstraps a development environment.
>>>>
>>>> Can anyone point me to anything happening on that front?
>>>>
>>>> Cheers, Eric
>>>>
>>> My recollection of the conversation is that deployment is outside 
>>> the scope of Maven and there are other tools that approach this from 
>>> a more effective base functionality.
>>> Maven works best at giving you 1 artifact for a project whereas 
>>> deployment needs to be able to generate a whole set of artifacts 
>>> based on configurations that include
>>> - software artifacts
>>> - configuration files
>>> - branding
>>> - documentation
>>> - release notes
>>> - license agreements
>>> - installer
>>> each of which may have to be customized for each client or each 
>>> deployment architecture(OS, database, etc.) or each deployment 
>>> environment(production, test, QA) .
>>>
>>>
>>> Ron
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message