@Bryan T.: Thanks for you help, but <sources><source/></sources> did not do
the trick.
My current understanding of compileSourceRoots is this, and please correct
me if I'm wrong:
Flexmojos has a property compileSourceRoots that makes it configurable:
see AbstractFlexCompilerMojo.java
and the configuration for that looks like this:
<compileSourceRoots>
<compileSourceRoot>path1</compileSourceRoot>
<compileSourceRoot>path2</compileSourceRoot>
</compileSourceRoots>
1) How does the configuration get set on the mojo?
Plexus with its Configurators takes this configuration section and tries to
set it on the mojo.
In this
case,
org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter
It inherits from AbstractConfigurationConverter.
2) Default and custom configuration
The interesting bit is that the configuration that is finally used by the
CollectionConverter is the one specified by my POM merged with the default
mojo configuration.
This happens in the Maven
class
org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator
in the method
finalizeMojoConfiguration().
The problem with this merged configuration is this:
It has a value of ${project.compileSourceRoots}
because of the javadoc in AbstractFlexCompilerMojo.
And it also has a child list containing the paths the I've set in my POM.
For the different properties,
see org.codehaus.plexus.configuration.PlexusConfiguration
3) Here's the problem:
When trying to set compileSourceRoots:
CollectionConfigurator calls the method fromExpression() of its super class,
which tries to retrieve the value of the configuration by calling
configuration.getValue()
which returns ${project.compileSourceRoots}.
This expression is evaluated and returned, see
CollectionConverter.fromConfiguration(), first 4 lines
The problem is that after those four lines, about in the middle of that
method, the child list of the configuration is used to populate the desired
collection.
The child list contains the paths that I've set in my POM.
But because configuration.getValue() returns ${project.compileSourceRoots}
this code section is never reached, and my configuration does not overrule
the default config.
Alger
On Mon, Feb 14, 2011 at 12:22 AM, Bryan Turner <[email protected]>wrote:
> Try it. Try to @Embed an image file that isn't on the source path and see
> what the Flex compiler does. Try to add an <mx:Style source="styles.css"/>
> directive for a .css file that isn't on the source path and see what the
> Flex compiler does. Compilation fails, because, unlike javac, compc and
> mxmlc require that these types of resources be available on the compile
> path. All of our images and icons are in src/main/assets, and all of our CSS
> files are in src/main/styles. Therefore, they *must* be source paths. So
> what should we do? Collapse it all down into src/main/flex? That's foolish.
> The result would be much more difficult to navigate. Part of the reason
> Maven supports the concepts of source paths and resource paths is to allow
> splitting files out into logical groupings to make it clear where to find a
> given file.
>
> The resource inclusion is unfortunate, that's true. Sadly, at least in
> FlexMojos 3.8, FlexMojos isn't very good at finding bundles without a little
> help. I've tried removing directives related to paths containing our
> resource bundles and doing so causes the build to fail because the compiler
> can't find them anymore. And don't say use FlexMojos 4. Our project can't
> use Maven 3 at the moment. There are politics involved in that decision that
> *I*, as a developer, do not have control over, and that's just how it is.
> Maybe our project is structured oddly, but you seem rather more interested
> in denouncing sins than elaborating solutions. If this isn't the way you
> feel it should be done, maybe you can find 5 minutes to write a
> useful e-mail making some coherent suggestions on how we could layout our
> project better, instead of saying we're doing something wrong but offering
> no insight on how we could do it right. Such an e-mail could benefit the
> entire FlexMojos community, instead of stirring up resentment. I'm certainly
> open to hearing your suggestions. The fact that you have the skills and
> understanding of the Flex toolkit that it takes to build and maintain
> FlexMojos is more than proof that you have insight to offer. This structure
> was laid out before I was even hired to work on this code. *I *did not do
> this. But given a choice between building this with Ant and building it with
> FlexMojos, even if I have to do some unfortunate things with my POMs, I'm
> going to build it with Maven every time. So here we are, living with
> reality, and it stays reality because we don't know another way to do it.
>
> Bryan Turner
>
> On Sun, Feb 13, 2011 at 2:35 PM, Marvin Froeder <[email protected]> wrote:
>
>> Ow you are.. adding all path for bundles is just one example on what you
>> shouldn't be doing... and still, I don't think all other are needed as
>> well.... at least no as an source entry.
>>
>> Sent from Android
>>
>> Em 13/02/2011 15:50, "Bryan Turner" <[email protected]>escreveu:
>>
>>
>> We're doing nothing wrong, and we're not "abusing" source paths. The Flex
>> compiler requires that resources like .css files, images, fonts, etc., in
>> addition to ActionScript and MXML code, be on the *source path* when it
>> compiles. This is not a requirement that the Java compiler has, by
>> comparison. As a result, we have a choice: Either we stuff *everything*into
>> src/main/flex so we can play nicely with the 1 source path FlexMojos
>> has by default, since even src/main/resources is not included as a
>> sourcePath by default, or we use the build helper plugin to add additional
>> sourcePaths, allowing us to separate our various resources out in a
>> sensible, clear manner that is readily intuitive to all of the developers on
>> the project. It's a decision that was imposed by the realities of the Flex
>> compiler, and is reinforced and supported by the same.
>> Please know, if the Flex compiler did not function the way it does, we
>> wouldn't have to muck with source paths to allow us to have a clean project
>> layout. Achieving the separation we want on a Java project is trivial, and
>> doesn't require a lot of sourcePaths. Unfortunately, on Flex, that's not the
>> case.
>>
>> Bryan Turner
>>
>> On Sun, Feb 13, 2011 at 12:39 PM, Marvin Froeder <[email protected]>
>> wrote:
>>
>>> >
>>> > You are doing something seriously wrong if you need to abuse of extra
>>> source paths like that.......
>>>
>>>
>>> >>
>>> >> Em 13/02/2011 15:26, "Bryan Turner" <[email protected]>escreveu:
>>> >>
>>> >>
>>> >> Apologies, it l...
>>>
>>> --
>>>
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Flex Mojos" group.
>>> > ...
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Flex Mojos" group.
>> ...
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Flex Mojos" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/flex-mojos
>>
>> http://flexmojos.sonatype.org/
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Flex Mojos" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/flex-mojos
>
> http://flexmojos.sonatype.org/
>
--
Alger
--
You received this message because you are subscribed to the Google
Groups "Flex Mojos" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/flex-mojos
http://flexmojos.sonatype.org/
