Am 01.02.11 05:17, schrieb Adam Murdoch:
> Hi,
>
> Recently, Rene Groeschke contributed an 'application' plugin, which adds 
> tasks for running your application and building a distribution for it 
> (including generating launcher scripts). Many thanks for this, Rene.
>
> I have a few comments/questions about this plugin:
>
> * I don't really like the name 'application plugin'. The term 'application' 
> is much too general, whereas the plugin is really intended for applications 
> with a main method. Some possible names for this plugin: command-line 
> application plugin, j2se application plugin, main-method application plugin. 
> Any other suggestions?
In my opinion 'j2se-application' actually fits quite good here. In
future, we may split it to allow other kinds of applications.
> * The plugin adds an 'install' task, which will conflict with the maven 
> plugin's 'install' task. I think we should rename the maven plugin's task to 
> something like 'publishMavenLocal'. While we're doing this, we should think 
> about renaming upload<config> to publish<config>.
The name 'install' of the maven task is taken from the original maven
goal right? I've never understand why maven called pushing artifacts
into a repository "install".
> * Should the plugin handle multiple applications per project?
I think as a default one application per project should be fine. The
application plugin may work like the war plugin adds a default war task,
but allows additional war tasks.
> * Should the plugin handle multiple distributions per application (eg 
> -bin.zip, -src.zip, etc) ?
>
> * Should we generate a .tgz distribution as well?
Every serious application distibutes multiple distributions (the
defaults -bin.zip, -src.zip and the -all.zip) The plugin should be
supportive here. For me, an addionally .tgz based archives is a nice to
have. But it doesn't seem to be a problem either. For griffon we
generate a dmg file as well.
> * Should we include javadoc and source zips/directories in the distribution? 
> How about other documentation, such as user guides, etc.
It should depend on the type of dist archive (-src.zip with sources,
-all.zip with sources and javadoc). For now, generating a userguide may
be another story/plugin
> Some thoughts about future work:
>
> * It might be nice to have some conventional location in the source tree to 
> look for files to be included in the distribution, such as src/dist. Things 
> such as readme, license files and so on can be added here, and automatically 
> included in the distribution.
I already thought about that and like 'src/dist' or 'src/toplevel'
> * Perhaps we could add a 'dists' configuration which publishes the 
> distribution(s)? This would automatically add an uploadDists task, for 
> example.
>
> * I think we should add an equivalent 'library' plugin, which does things 
> such as adding a source and javadoc jar, and creating a distribution zip file.
Common tasks and concepts like the src/dist convention can be moved to a
library plugin. The application plugin just needs to extend this library
plugin and add the pure application related issues like the run task and
the start scripts related issues.
> * Some way to make an executable, self-contained jar
>
> * Some way to make a mac application bundle would be nice.
Bundling a singleJar shouldn't be a big problem, generating a .app macos
bundle would be very cool, but I havn't any experience with generating
these plist files. But huxi mentioned some experience here.

regards,
René

-- 
------------------------------------
Rene Groeschke

[email protected]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to