Kenny,
I definitely overlooked the generated sources. The rest of it seems
pretty superficial, but there definitely doesn't seem to be a very
good way to collect those generated sources via the assembly plugin.
Thanks for the insight.
On 1/18/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
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]
--
Gregory Kick
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
