Hi Carlos,

These files aren’t sources therefore they don’t belong to a source directory, 
from a maven point of view. They should be added to the resource directories 
which are handled by the resources plugin.
The thing is, that we could eventually simply configure the 
maven-resources-plugin to copy the resources to our desired output directory 
/target/javascript/bin/debug-js or release-js ... 
That would be the better approach. I don’t think the compiler should deal 
copying of resources.

And what are you talking about flexmojos? I thought we were talking about 
flexjs and this uses the flexjs-maven-plugin.

Chris

Am 04.11.16, 17:51 schrieb "carlos.rov...@gmail.com im Auftrag von Carlos 
Rovira" <carlos.rov...@gmail.com im Auftrag von carlos.rov...@codeoscopic.com>:

    mmm...certainly, I think that was what we use to do in old Flex dev. maybe
    that's the reason why my jpg is not getting copied...we need to add
    'src/resources/fles' to the pom.xml as an additional source directory
    
    @Chris what do you think? could we add in flexmojos a secondary source dir?
    
    Thanks
    
    
    
    2016-11-04 17:21 GMT+01:00 Alex Harui <aha...@adobe.com>:
    
    >
    >
    > On 11/4/16, 2:13 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
    > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
    > wrote:
    >
    > >I think Chris is on the track on this issue.
    > >
    > >As a user, If I have a resource on a folder, is because I want it on 
final
    > >output, so I'll expect to be copied, since output folder is what I'll be
    > >putting on server (and not any source code related resource).
    > >
    > >btw, I think this should be IDE agnostic, and it scares me if we think it
    > >should depend on that. people should be able to use it from command line,
    > >so I think this is in the flexjs sdk domain.
    > >
    > >In traditional flex development:
    > >
    > >*  I used a path like this "/assets/image.jpg" and that would work as an
    > >absolute path.
    >
    > From my experience, a leading slash only worked in IDEs and did not work
    > from the command line.
    >
    > >* The other way is relative to the resource, without the first slash, and
    > >you can up and down the hierarchy starting from the source file in which
    > >you write that code.
    > >
    > >I use a maven style folder structure (so src/main/flex/App.mxml and so
    > >on),
    > >other will use src/App.mxml... we need to support all of this in a easy
    > >way, since this is basic.
    > >
    > >I think If users start to be kept in this basic things, is what could 
make
    > >them to not continue trying flexjs.
    > >
    >
    > Somehow, I think everybody on this email list was able to use the regular
    > Flex SDK and manage their resources without the Flex SDK MXMLC compiler
    > having any ability to copy resources.  So I really am curious as to how
    > folks managed resources in the past.
    >
    > That said, I'm fine with having the compiler look in a few places to find
    > and copy assets.  Currently, only certain kinds of files are copied from
    > an assets folder that is a sibling of the main class file's location.  If
    > we add src/main/resources, should you have to specify a relative path to
    > it?  I think not, since the relative path would affect the layout in the
    > target folder, so maybe the developer will have to specify a second source
    > path for src/main/resources.
    >
    > Thoughts?
    >
    > -Alex
    >
    >
    
    
    -- 
    
    Carlos Rovira
    Director General
    M: +34 607 22 60 05
    http://www.codeoscopic.com
    http://www.avant2.es
    
    
    Este mensaje se dirige exclusivamente a su destinatario y puede contener
    información privilegiada o confidencial. Si ha recibido este mensaje por
    error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
    proceda a su destrucción.
    
    De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
    que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
    S.A. La finalidad de dicho tratamiento es facilitar la prestación del
    servicio o información solicitados, teniendo usted derecho de acceso,
    rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
    oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
    necesaria.
    

Reply via email to