It's an argument to the current resolution mechanism that lets you
make a decision on whether to include every artifact. Maven has some
standard filters for passing in lists in certain forms. You could look
at the code of the assembly plugin for how those are used.
How you configure it is up to you, but something like this would be
expected:
<runtimeLinkedLibraries>
<includes>
<include>someGroup:*</include>
</includes>
</runtimeLinkedLibraries>
<mergedLinkedLibraries>
<excludes>
<exclude>someGroup:*</include>
</excludes>
</mergedLinkedLibraries>
Cheers,
Brett
On 05/06/2008, at 11:57 AM, Marvin Froeder wrote:
Can you give me some light about how this plugins filters works?
A where to start...
VELO
On Wed, Jun 4, 2008 at 10:45 PM, Brett Porter <[EMAIL PROTECTED]>
wrote:
It's debatable whether the artifact resolution mechanism should
support
customisable scopes - I can see some justification from this, but
these
would all be flex specific, not blended in with the current set.
I would suggest that the best approach for you to take is to
configure
filters on the plugins to apply these types of linking to certain
artifacts
from the Maven runtime scope set.
Cheers,
Brett
On 05/06/2008, at 9:41 AM, Marvin Froeder wrote:
Flex has 2 types of binaries SWC (jar like) and SWF runnable file,
but is
not a library.
Just keep in mind flex is very different from java. SWF files
must be all
required libraries bounded into it own binary in order to run or
load at
runtime.
Flex compiler has 5 ways to link libraries to application
* merged
* internal
* external
* runtime
* caching
Merged will copy all required classes into the SWF.
Internal will copy all available classes into SWF
External will not copy (and in some situations application will
not work,
but this is flex way to do things)
Runtime will load the library over internet on runtime (means 2
SWC will
be
on server)
Caching will load some special optimized libraries like runtime.
Just to be clear.
If I compile myLibrary with all external libraries will generate a
very
small SWC. If all are merged will generate a little bigger SWC.
If all
are
internal will generate a huge SWC file. Caching, runtime and
external will
all generate the smaller file, but caching and runtime are only
for SWF,
so
no transitive problem. SWF are dead ends. Runnable, but no
extendable.
Right now, I define this on scopes. ie:
<dependency>
<groupId>com.adobe.flex.sdk</groupId>
<artifactId>playerglobal</artifactId>
<version>10.0.0-beta-051508</version>
<type>swc</type>
<scope>external</scope>
</dependency>
Well, when myLibrary has merged or internal libraries, those
libraries
doesn't need to be transitive. myLibrary will be compiled with all
required
data. So transitivity make no sense.
When I have a library with external libraries and this library is
used to
compile a application as merged, I need to merge all libraries,
because my
library have externalized others libraries content.
Its a little confuse, specilly for who comes from Java.
VELO
On Wed, Jun 4, 2008 at 8:15 PM, Jason van Zyl <[EMAIL PROTECTED]>
wrote:
I think you need to explain more about what the problem is. I'm
not sure
you will need a new scope.
On 4-Jun-08, at 2:22 PM, Marvin Froeder wrote:
Hi guys,
I try this on users list, but now answer.
I have develop my on plugin for compiling flex with maven (
http://blog.flex-mojos.info/).
Flex is different from Java in several ways. One of this ways are
related
to libraries scopes.
Was need to add other scopes in order to compile flex. Now I
need to
customize maven dependency resolution mechanism to use some of
this
dependencies as non transitive. The big question is, how?
Pexus will
accept that? I will need to right my own resolution mechanism?
Can
anyone
give me a light on this matter?
VELO
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our
worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
