On 2/9/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
Tim O'Brien wrote:
> On 2/8/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > Revision
>> >     3256 <http://fisheye.codehaus.org/changelog/mojo/?cs=3256>
>> > Author
>> >     tobrien
>> > Date
>> >     2007-02-06 16:11:49 -0600 (Tue, 06 Feb 2007)
>> >
>> >
>> >       Log Message
>> >
>> > Added a few parameters to the DebPlugin:
>> >
>> >   * libTargetDirectory - default usr/share/java/${project.group.id}
>> >
>> > From what I could see, most Debian packages install jars in
>> usr/share/java - so libcommons-lang-java, puts a jar file in
>> > usr/share/java/commons-lang-2.1.jar.   While we could probably get
>> away with
>> > putting JARs in this same directory, it didn't feel appropriate to
>> just use the artifactId and the version number.  I've added another
>> directory that captures the groupId.   This is a break from what
>> > the original DebPlugin did, the originial plugin put jars in
>> usr/local/jars which isn't compatible with what the Debian project.
>> (And, I know, it isn't that we have to be Debian compliant, but why
>> > not start with compatibility and let people override if they need to.)
>> >
>> >   * includeJavaDocs - Added a boolean flag (default true)
>> >
>> > allows you to specify whether or not the deb plugin should bundle
>> Javadoc in the deb file.  Again, I added this after looking at the DEB
>> > packages distributed by both the Debian and Ubuntu projects.   All
>> of them have Javadoc available in /usr/share/doc.
>>
>> This should not default to true. The Debian binary packages are always
>> split into two packages. See junit for an example [1].
>>
>
> OK, I'll change this to be false by default.
>
>> >   * docSourceDirectory - default ${basedir}/site/apidoc
>> >
>> > Allows you to specify where the deb plugin to copy Javadoc from.
>> This only works if you put associate with javadoc goal with the
>> package stage.
>> >
>> >   * docTargetDirectory - default
>> usr/share/doc/${project.groupId}/${project.artifactId}/api
>> >
>> > Again this directory is consistent with how debian already packages
>> libraries like the commons libraries.
>>
>> One issue here is that Debian ignores the group id part and only uses
>> the artifact id.
>>
>> [1]: http://packages.debian.org/stable/source/junit
>>
>
> Right, so, in general, how should this plugin behave.  Should we
> simply use the artifactId or should we insert the groupId?    Let me
> know, and I can update the plugin.

I'm not sure really, I guess perhaps it would be best for the group id
to be in there. The plugin was not intended to support package packages
for Debian in itself given their silly required to everything so my
focus is for making packages of my applications. That said I have no
objections to defaults that make it easier to create packages that
follow any existing conventions. Your call.


OK  Trygve, I'll add a flag that omits the groupId for compatibility
purposes, but I'll default to including the groupId.


--
Trygve

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

    http://xircles.codehaus.org/manage_email




--
------
Tim O'Brien

Phone: (847) 863-7045
Fax: (866) 314-3323
SkypeIn: (347) 410-9085
Skype: tmobrien
AIM: TimNinja

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

   http://xircles.codehaus.org/manage_email

Reply via email to