maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: artifact types/extensions
Date Wed, 23 Jun 2004 10:57:49 GMT

> -----Original Message-----
> From: Brett Porter []
> Sent: Wednesday, June 23, 2004 10:33 AM
> To: Maven 2 Developers List
> Subject: Re: artifact types/extensions

> Ok, so there are two alternatives that satisfy the requirements: make 
> more types, and only use some for artifact types and the rest are 
> derivatives of types, and live with having to always generate all 
> different derivatives. Otherwise, this becomes an extra 
> distringuishing 
> part of the id, like so:
> ..
> <version>1.3.0</version>
> <type>distribution</type>
> <derivatives>
>   <derivative>src-targz</derivative>
>   <derivative>src-zip</derivative>
>   <derivative>exe</derivative> <!-- A plugin would have registered 
> itself as a handler for distribution:exe -->
> </derivative>
> <dependency>
>  ... this gets the ejb ...
>   <type>ejb</type>
> </dependency>
> <dependency>
>  ... this gets the ejb ...
>   <type>ejb</type>
>   <derivative>client</derivative>
> </dependency>

As for me ejb-client is simply a jar and so we should have <type>jar</type> 
IN the worst case when distinction between ordinary jars and ejb clients is
really needed 
(I don't know why - but I am not an expert :) ) we can live with

> This is getting complicated admittedly, but I prefer clarity 
> to magic, 
> especially when it is optional (types like distribution-src-targz are 
> kind of like the whole id = groupId+artifactId thing that we have 
> eradicated from maven 1).
> I'm going down the big type in the artifact plugin for now as 
> it is all 
> I need, but it'd be good to sort this out in the m2 use cases.
> Perhaps one of the problems is that the distribution example blows it 
> out of proportion. Do we envisage a "dist" being able to generate all 
> these different types, or would be have a targz plugin chained to a 
> srcdist plugin?

I have couple more use cases.
I know of some projects distributing obfuscated jars to customers. 
Sometimes from the same set of sources they create two jars: normal one
(used for debugging, profiling etc)
and other one being the result of obfuscation process.

I doesn't happen often but I guess this is a valid use case.

Other point.
javac compiler supports such options:

    Generate all debugging information, including local variables. By
default, only line number and source file information is generated.

    Do not generate any debugging information.

-g:{keyword list}
    Generate only some kinds of debugging information, specified by a comma
separated list of keywords. Valid keywords are:

        Source file debugging information 
        Line number debugging information 
        Local variable debugging information 

I don't know if there are some people willing to generate two versions of
the same jar:
one with -g second with -g:none option.
I never used this option and I am wondering is some people are needing to
create jars with or without debug information and if sometimes
both version are needed.

There is also oher optoin
    Note: the -O option does nothing in the current implementation of javac
and oldjavac.
    Optimize code for execution time. Using the -O option may slow down
compilation, produce larger class files, and make the program difficult to

I wonder if somebody ever creates 3 jars from single project:  with
debugging info, normal and optimimized for execution speed :)

So my point is that even if project type = jar - we can still have more then
one artifact.

I suppose that what I am writting about is representing less then 1% of
situtations and probably we can reject such use cases.
But I am not sure about it ( maybe I am wrong?). 
That's why I am asking if somebody ever participated in the project which
needed such things and how often they are actually needed?
I myself can live well withouth them :)


View raw message