copy-flex-applications

[zalym]

Is there any example for this? I dont see any and the documentation
in the plugin site is sparse.

I would like to know when this goal is used and what is the
configuration for it. Help appreciated.

[VELO]

Well,

I copy using Maven Dependency Plugin:
http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html


VELO

[Christian Edward Gruber]

There's an example here of how to put it into the war project

http://www.israfil.net/projects/mojo/maven-flex2-plugin/examples/simple_war_project.html

As to docs, when you talk about the site, do you mean the googlecode
site, or the project documentation site. The latter is at http://www.israfil.net/projects/mojo/maven-flex2-plugin/
and is generated afresh for each release, and has examples and
plugin parameters, etc.

Christian.

[zalym]

I meant the project site.

I have some modules, which are namespaced, and copy dependencies
doesn't copy them into the correct folders. for eg if i had a module
- com.zalym.module1 when i use the copy dependencies, it doesn't copy
it into the correct location ie com/zalym/module1, rather it copies
into the root folder. this is an issue, as my module loader fails
then.

how does this plugin work with modules? do we have any examples for
this?

BTW, can we have multiple modules in one project and have the plugin
support it? FlexBuilder supports it.

On Apr 1, 3:35 pm, Christian Edward Gruber

<christianedwardgru...@gmail.com> wrote:
> There's an example here of how to put it into the war project
>

> http://www.israfil.net/projects/mojo/maven-flex2-plugin/examples/simp...

>
> As to docs, when you talk about the site, do you mean the googlecode

> site, or the project documentation site. The latter is athttp://www.israfil.net/projects/mojo/maven-flex2-plugin/

[VELO]

You can define destination.

                            <outputDirectory>${project.build.directory}/${project.build.finalName}/com/zalym/whatever/.../.../</outputDirectory>

VELO

[Christian Edward Gruber]

Interesting. It currently doesn't. I can make that happen.

So you're saying that each plugin's namespace needs to be the
directory in which the .swf files goes? Let me ask a different way -
what things are different about compiling and deploying a module from
any-old swf?

Christian.

[Mohammed Saleem]

I was hoping not to go that route for the obvious maintenance reasons.  There should be a better way.  Any ideas.

--
Regards,
Mohammed Saleem

"Jack of all trades. Master of some."

[Christian Edward Gruber]

I can add a further "namespace" optional parameter so you can put it in teh right context location.

Christian.

[Mohammed Saleem]

Yea, thats how FlexBuilder does it, and hence we should support it as well to make it look seamless.  The modules are loaded based on the namespace and hence the current situation doesn't work.

Regarding the differences between a module and application, the current scenario works for application, but for modules, so far I think only this namespace thing is the issue.  what does the rest think about it?

[Mohammed Saleem]

That is still the same issue right?  I mean having it in the namespace attribute or finalName is the same for me - duplicating the information in pom.

How about this?  Modules do not work standalone, they need to be loaded by an application, basically either through the ModuleLoader or ModuleManager.  So how about having a packaging of module type - and while creating the artifact, create an archive of the module and then while deploying it, unzip the archive.  It could be a copy-modules goal.  This can solve having more than module in a project as well.  What do you think?

[Christian Edward Gruber]

No.  Finalname is the name of the artifact (not the location), whereas the namespace isn't it.  It's that maven defines its metadata, but is ignorant (in its essentials) of Flex internals.  So we have to do the mapping.  Having a module packaging might be the ohter way to go on that, true. You could even use the same copy goal - it would just be module aware.

Christian.

[Mohammed Saleem]

I feel the module packaging is a cleaner solution, because it can solve two issues.  One is this namespace, and the other is having multiple modules in one project instead of having one for each.  Is this the way to go?

[Christian Edward Gruber]

You should still have one module per project.  Maven uses one-artifact-per-project.  It's just that you would have several module projects and a parent project. 

I have to look up modules again, as I think (now that it's coming back to me) there's an inversion of that parent/child logic.  This may not entirely work, but we can look at it.  Is there a good document to see how they're defined on the file system (the projects, from flexbuilder's perspective?

Christian.

[Mohammed Saleem]

try this document - this is what started me up on modules - http://blogs.adobe.com/flexdoc/pdfs/modular.pdf

regarding more than one module in a project, if the artifact is an archive, it could have more than one module.  its like a jar containing a lot of classes. 

[Jeremy Anderson]

What I think Christian is trying to say isn't that a project couldn't use more than one module, but rather that in order to not violate one of maven's core tenets, you could never have more than module as an output for a project.

[VELO]

Another reason to put each module on a separated project is prevent casting errors at runtime.

If the module A access some value object and Module B access the same, you can't transfer data from module A to module B, because, at runtime, they are not the same class.

Doing separeted modules you prevent some bad developer praticles like on Module A he does new ModuleB(), doing this Module A will attach all sources from Module B

You can use all in the same source, but need a big work around.
1 - Change the project pom.xml type to pom.
2 - create a module folder
3 - create a pom.xml and point source folder to ../src/main/flex
4 - add this module on project pom.
5 - repeat 1 to 4 for each modules and to application
6 - compile


VELO

[Christian Edward Gruber]

Exactly.  Remember also that a maven project doesn't have to track to a flex-builder project.  There could be a cloud of maven projects that are all, collectively one flex builder project.  That isn't how it's set up now, but it's not infeasible, if that's necessary to make this structure work.

I'll check the provided pdf reference.  Thanks.

Christian.

[VELO]

If you wanna a sample, mail me of topic.


VELO

[zalym]

I agree with the maven tenet, i understand it all. But in maven we do
have multiple artifacts for a project using the assembly plugin. And
I can distinguish based on classifiers etc.

One qstn, who decided that a module is an artifact? Open qstn, love
to hear ur views.

On Apr 10, 10:29 am, VELO <velo...@gmail.com> wrote:
> If you wanna a sample, mail me of topic.
>
> VELO
>

[VELO]

I never used assembly to that

Can you show how?


VELO

[Christian Edward Gruber]

No one decided, since the flex plugin doesn't yet support them. ;)

But I have to start somewhere, conceptually, and usually I find that a
file is an artifact, unless someone can tell me a good reason otherwise.

The problem is that classifiers aren't really suited for "multiple-
file-output" artifacts, since they're more like different views of the
same artifact. (source, javadoc, etc.)

Having said that, I think I need to whip up a sample module project to
see how it plays out in general use... unless someone has a good
sample project with modules.

As to assemblies: an assembly isn't an artifact. It's an archive of
resources, including dependent artifacts (if desired). There is still
one artifact for that project that uses the assembly plugin (even if
it's only metadata .pom file). You can assemble multiple projects
into a zip file if you like, but that assembly doesn't have a groupId,
artifactId, and version that uniquely identifies it by definition.
You can have a gazillion assemblies generated by your project, but you
still only have one artifact.

Christian.

[Mohammed Saleem]

Well assemblies can be used to create different classifiers.  I have seen projects where they use assemblies to ensure that there is a 1.4 and 1.5 version of the binary.  Likewise, I have seen projects where there is a lean war to be deployed as part of the ear and then an actual war that can be deployed standalone.  So these are finally artifacts from one project. 

My only concern is that we make a decision and turn away people because of that.  I am sure we all agree on that.  From my experience in the Flex forums, people dont get this concept of one module and one project. General practice is to have all modules in another project or part of the main application project itself.  We need to come up with a solution where we don't turn away the majority of the flex users. 

In the current project I am working on, I have an example:  All customer related screens are in one FB project.  Now if I need to mavenize them, I need to separate them into 10 different projects!!! 

I definitely want a way to say that these is a module archive in the plugin, and configure more than one module in it.  Maybe it needn't be the default or if it can be another packaging type. 

[Mohammed Saleem]

So how are we going on this?

[Christian Edward Gruber]

I don't think we've yet arrived at a consensus of approach.  Could someone create an example project of how they imagine this working?  (ie, an FB project or group of projects, with some example pom files.)  Obviously it would be non-working, but I want to really make sure I understand what we're trying to do here, given the rather orthogonal ways of looking at modules.

Christian.