Hi,
the sources and javadoc jars can be used for IDE's. For instance,
in eclipse, if you have a jar classpath element, you only get
the binary, and no javadoc or other functionality. If you attach
the source or javadoc to that jar classpath entry, that helps
with programming in terms of documentation and in terms of debugging
and tracing. That's why those plugins exist.
I think you're using the 'src' assembly descriptor. If so, here are
the differences between using that and the source plugin:
- the source plugin knows about all the project sources, even generated ones,
and the assembly plugin doesn't. The descriptor has 'src/' hardcoded in it.
The assembly plugin only knows files, directories, dependencies and modules.
- The 'src' assembly descriptor in the assembly plugin packages up the 'src/'
dir,
harcoded. Say you have some plugin that generates sources (like antlr) hooked
up
in your pom that uses src/main/antlr/grammar.g to generate
target/generated-sources/antlr/my/package/Parser.java.
Now if you list the contents of the assembly archive it will be
src/main/java/my/package/My.java
src/main/resources/app.properties
src/main/antlr/grammar.g
The contents of the source jar will be:
my/package/My.java
my/package/Parser.java
app.properties
- The assembly descriptor generates a tar.bz2, tar.gz and a zip.
The source plugin generates a jar.
- The source:jar and javadoc:jar are both automatically executed during
a release or deployment of a non-snapshot artifact, and both
jar archives will be deployed. The assembly plugin will not automatically
be called.
As for javadoc, the javadoc plugin knows where it generated the javadoc
api documentation and knows what to zip up. With the assembly plugin you'd
have to make a custom descriptor, duplicating some configuration.
Hope it's a bit clearer now.
-- Kenney
Gregory Kick wrote:
I originally started this thread on the users list and Franz suggested
that we move it over to the dev list. Does anybody have any thoughts
on all of this?
---------- Forwarded message ----------
From: Gregory Kick <[EMAIL PROTECTED]>
Date: Jan 17, 2007 11:10 PM
Subject: Re: Source Archives: Source Plugin vs. Assembly Plugin
To: Maven Users List <users@maven.apache.org>
Franz,
On 1/14/07, franz see <[EMAIL PROTECTED]> wrote:
Good day to you, Gregory,
Actually, the plugin does not define the lifecycle. Rather, it's the
packaging type which defines the default goal bindings to the lifecycle
phases.
That's what I meant. Sorry for misspeaking.
Regarding consolidating the functionality in order to minimize the effort
across pugins - if you're referring to implementation-wise, I think
they are
using a common component for the assembly.
I hadn't really looked into it in the source, but like I said in the
my message to Dennis, we end up with multiple goals with the same
parameters. Not a huge deal, but it seems a bit silly...
Also, IMHO, eventhough source and javadoc are both "auxiliary" artifacts,
they're both common functionalities just like the jars, wars, etc.
Thus, I
don't find any fault with the existence of source:jar and javadoc:jar.
The
assembly plugin is usually used for the uncommon use cases.
Yes, I think that that is what Dennis was saying as well. My thought
was that now that the assembly plugin seems to have matured into
something more stable, it might be worth using it in the common cases
as well.
As for knowing all the artifacts being generated by a build, maybe
creating
a report would be better ( though I am not sure how though :) ).
Actually, I made one. It was a pain to get it to work correctly and
it's pretty hackish. I'd much rather just be able to manage the
assembly plugin and be done with it.
But if you want, you can take this up in the maven dev list to get more
inputs :)
Alright, lets see what they have to say.
Just my 2 cents worth.
Franz
Gregory Kick-2 wrote:
>
> Franz,
>
> The difference that I see between the sources and javadoc plugins and
> jar, war, etc. is that plugins like the jar plugin actually define the
> lifecycle for that particular packaging. Since source and javadoc
> jars are "auxiliary" artifacts, it seems as though it would make more
> sense to consolidate that functionality in order to minimize effort
> across the plugins. Also, it seems like it would be much more
> convenient to look look at the descriptorRefs tag and see __every__
> artifact that was being generated (aside from the default, "main"
> artifact).
>
> Aside from it already being implemented, was there a specific reason
> for sources and javadoc to create their own jars?
>
> On 1/12/07, franz see <[EMAIL PROTECTED]> wrote:
>>
>> Good day to you, Gregory,
>>
>> I think it is simply for ease of use. Intead of configuring the
assembly
>> plugin, you can simply do mvn sources:jar. Same goes for the other
>> packaing
>> goals ( jar:jar, javadoc:jar, ejb:ejb, ejb3:ejb3, war:war, ear:ear,
etc
>> ).
>> Usually, you don't have to use the assembly plugin because the other
>> packaging goals are much easier to use. But if those goals are not
enough
>> for your needs, then go for the assembly plugin.
>>
>> As for the difference between -sources and -src, I am not sure
myself :-)
>>
>> Cheers,
>> Franz
>>
>>
>> Gregory Kick-2 wrote:
>> >
>> > After looking through the documentation for each of these plugins, I
>> > am left with a few questions:
>> >
>> > - Isn't the functionality of the source plugin just a subset of the
>> > assembly plugin (i.e. couldn't I just use the assembly plugin to do
>> > the same thing and only have to worry about one plugin)?
>> >
>> > - Is there a reason that the assembly plugin uses -src for its
>> > archives while the sources plugin uses -sources?
>> >
>> > - Should the Source Plugin be deprecated for a pre-defined assembly
>> > descriptor with the same behavior?
>> >
>> > --
>> > Gregory Kick
>> > [EMAIL PROTECTED]
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8292765
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Gregory Kick
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Source-Archives%3A-Source-Plugin-vs.-Assembly-Plugin-tf2963424s177.html#a8350410
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Gregory Kick
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
