You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by fhomasp <th...@realdolmen.com> on 2010/12/07 12:05:04 UTC

Create complicated client jar release target(s)

Hey,

I don't quite know how to put this, but I'll give it a shot.

Basically there are 3 client applications with Swing UI that need to get
released.  These have common dependencies bundled in a common dir.  For this
part, I don't see much of a problem, I'll get a super pom to get that
working, however I'm unsure which plugin I should use.  The global release
structure should look like this:
\application 1
\application 2
\application 3
\common


However each application also has an internal release structure, which is
more or less similar for each of them.  The client applications all have
packaging jar.  The target release dir structure should go like this:

\bin (holds a service wrapper, and a .bat executable)
\conf (holds property files)
\lib (holds the actual application jar, so the actual mvn package target)
\log (the log files)

For this problem someone already did an attempt with the
appassembler-maven-plugin with groupId org.codehaus.mojo.


Any suggestions on this matter are appreciated.


-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295582.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
Start a new thread, I cannot help here.

2010/12/9 fhomasp <th...@realdolmen.com>:
>
> I guess I'm going to go with the original approach seeing that I got allmost
> everything working.  There is only one problem...  I'll clarify.
>
>
> The 2.2 assembly plugin includes the projects artifacts by default in the
> dependencySet tag.  However there is a tag that *should* resolve this.  I've
> set it (useProjectArtifact set to false) but it does not help.  So I figure
> I'll try a beta version but this has as major setback that the earlier tag
> "useAllReactorProjects" is now an unrecognized tag, breaking my build.  If I
> omit it, none of my modules get built even if I include them.  I mean, uhh.
> I'm at a loss here.  Here's the moduleSet part of my assembly descriptor.
> Is this a bug or something? I thought backward compatibility was rather
> important.
>
> <moduleSets>
>        <moduleSet>
>            <useAllReactorProjects>true</useAllReactorProjects>
>            <!--TODO: add future release modules here !?-->
>            <includes>
>
> <include>com.touchatag.ps.project.coa:JavaClientLauncher-releaseModule</include>
>
> <include>com.touchatag.ps.project.coa:SavingClient-releaseModule</include>
>            </includes>
>
>            <binaries>
>                <outputDirectory>/common/lib</outputDirectory>
>                <unpack>false</unpack>
>                <dependencySets>
>                    <dependencySet>
>                        <outputDirectory>/common/lib</outputDirectory>
>
> <useTransitiveDependencies>true</useTransitiveDependencies>
>                        <useProjectArtifact>false</useProjectArtifact>
>                        <useProjectAttachments>false</useProjectAttachments>
>                        <excludes>
>
> <exclude>com.touchatag.ps.project.coa:JavaClientLauncher</exclude>
>
>
> <exclude>com.touchatag.ps.project.coa:SavingClient</exclude>
>
>
>                        </excludes>
>                    </dependencySet>
>                </dependencySets>
>            </binaries>
>        </moduleSet>
>    </moduleSets>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3299051.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.
I guess I'm going to go with the original approach seeing that I got allmost
everything working.  There is only one problem...  I'll clarify.


The 2.2 assembly plugin includes the projects artifacts by default in the
dependencySet tag.  However there is a tag that *should* resolve this.  I've
set it (useProjectArtifact set to false) but it does not help.  So I figure
I'll try a beta version but this has as major setback that the earlier tag
"useAllReactorProjects" is now an unrecognized tag, breaking my build.  If I
omit it, none of my modules get built even if I include them.  I mean, uhh.
I'm at a loss here.  Here's the moduleSet part of my assembly descriptor. 
Is this a bug or something? I thought backward compatibility was rather
important.

<moduleSets>
        <moduleSet>
            <useAllReactorProjects>true</useAllReactorProjects>
            <!--TODO: add future release modules here !?-->
            <includes>
               
<include>com.touchatag.ps.project.coa:JavaClientLauncher-releaseModule</include>
               
<include>com.touchatag.ps.project.coa:SavingClient-releaseModule</include>
            </includes>

            <binaries>
                <outputDirectory>/common/lib</outputDirectory>
                <unpack>false</unpack>
                <dependencySets>
                    <dependencySet>
                        <outputDirectory>/common/lib</outputDirectory>
                       
<useTransitiveDependencies>true</useTransitiveDependencies>
                        <useProjectArtifact>false</useProjectArtifact>
                        <useProjectAttachments>false</useProjectAttachments>
                        <excludes>
                           
<exclude>com.touchatag.ps.project.coa:JavaClientLauncher</exclude>
                            
                           
<exclude>com.touchatag.ps.project.coa:SavingClient</exclude>
                            
                            
                        </excludes>
                    </dependencySet>
                </dependencySets>
            </binaries>
        </moduleSet>
    </moduleSets>
-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3299051.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.
One for each artifact that needs to be released is ok, that wasn't my
question.

I now also have a distributionmodule that takes info from the release
modules in order to group the libraries and to create one release bundle, as
it is explained in the link you don't like much :-)

I'll take a look at this



Antonio Petrelli wrote:
> 
> 2010/12/9 fhomasp <th...@realdolmen.com>:
>> You're talking about Tiles and accessing the parent directory.  Could you
>> explain a bit further?
> 
> I have a better idea, here is the source:
> http://svn.apache.org/repos/asf/tiles/framework/trunk/assembly/
> 
>> And the idea of an extra "distribution" module, that's not the way to go
>> then?
> 
> I guess that *one* assembly module is enough. In Tiles, within that
> single module, we build source, library, documentation assemblies from
> one single module.
> 
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3298637.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/9 fhomasp <th...@realdolmen.com>:
> You're talking about Tiles and accessing the parent directory.  Could you
> explain a bit further?

I have a better idea, here is the source:
http://svn.apache.org/repos/asf/tiles/framework/trunk/assembly/

> And the idea of an extra "distribution" module, that's not the way to go
> then?

I guess that *one* assembly module is enough. In Tiles, within that
single module, we build source, library, documentation assemblies from
one single module.

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.
Hmm worthless you say...  I did have a "sort of" solution with that
principle.  Especially for the combining of the transitive artifacts does it
seem to work.  Well, except for the jar(s) that are being included in the
<moduleSet><includes> part.
Though if something better, easier to work with and more dynamic is
available then I surely am interested :-)

You're talking about Tiles and accessing the parent directory.  Could you
explain a bit further? 

And the idea of an extra "distribution" module, that's not the way to go
then?
-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3298534.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/8 fhomasp <th...@realdolmen.com>:
> I've been looking at the example of building a distribution with a
> multimodule project
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>
> At this point I made a new module which will assemble the folders with their
> data in the correct structure.  Now I want to build the whole distribution,
> which brought me to the above quoted page.
>
> The problem is, how do I get the newly created release modules' assembly in
> the distribution alongside with the dependencies in this distribution
> assembly?  I already got the dependencies as explained in the link above,
> referencing an original jar (not the new assembly module).  Because the new
> assembly modules are in packaging pom...  I could switch to jar there too,
> but I'd have a jar included that is a dummy of some sort.
>
> I am thinking about excluding the jar, and also the original jar as well.
> This is because the former is a dummy and the latter is already included in
> the new assembly module, which might clash if it's twice on the classpath,
> right?

This one of the reasons I told you to use a separate module, because
you can include all the dependencies you need, filter them in assembly
descriptors, include all the files you want, even in other modules (in
Tiles we include sources from the other modules by accessing to the
parent directory).
I'm sorry so say it, but that link you posted is, essentially,
worthless (in fact I wonder why it has not been removed yet).

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.

That's exactly what I needed, thanks!

I do have another question about the whole setup though.


I've been looking at the example of building a distribution with a
multimodule project
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html

At this point I made a new module which will assemble the folders with their
data in the correct structure.  Now I want to build the whole distribution,
which brought me to the above quoted page.

The problem is, how do I get the newly created release modules' assembly in
the distribution alongside with the dependencies in this distribution
assembly?  I already got the dependencies as explained in the link above,
referencing an original jar (not the new assembly module).  Because the new
assembly modules are in packaging pom...  I could switch to jar there too,
but I'd have a jar included that is a dummy of some sort.

I am thinking about excluding the jar, and also the original jar as well. 
This is because the former is a dummy and the latter is already included in
the new assembly module, which might clash if it's twice on the classpath,
right?  

If I'm not making any sense at all, by all means say so :-)

Thanks for the help given so far.  I do think I'm on the right road





Antonio Petrelli wrote:
> 
> 2010/12/7 fhomasp <th...@realdolmen.com>:
>> using an assembly descriptor in the maven-assembly-plugin, how would I go
>> about getting property files from one my client apps?  I mean...  These
>> property files are of course centralized in the resources dir of that
>> module.  I'd hate to have to tell my project manager that I'll have to
>> get
>> these property files reduntantly into this new module...
> 
> If I understand you correctly, you want to copy a property inside one
> of your dependency inside a directory of your assembly, right?
> Then, prior to your assembly build, unpack part of your dependency:
> http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
> After that, include it in your assembly.
> 
> HTH
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3297315.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
> using an assembly descriptor in the maven-assembly-plugin, how would I go
> about getting property files from one my client apps?  I mean...  These
> property files are of course centralized in the resources dir of that
> module.  I'd hate to have to tell my project manager that I'll have to get
> these property files reduntantly into this new module...

If I understand you correctly, you want to copy a property inside one
of your dependency inside a directory of your assembly, right?
Then, prior to your assembly build, unpack part of your dependency:
http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html
After that, include it in your assembly.

HTH
Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.
Hey,

using an assembly descriptor in the maven-assembly-plugin, how would I go
about getting property files from one my client apps?  I mean...  These
property files are of course centralized in the resources dir of that
module.  I'd hate to have to tell my project manager that I'll have to get
these property files reduntantly into this new module...
-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295850.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.

Ah, I see.  Well, I hadn't thought of that actually, but it's a nice
suggestion.  However they are rather alergic to overhead, as they won't want
to build a release when they don't want to release.  And I would need
different credentials if I were to try and upload something to our remote 



Antonio Petrelli wrote:
> 
> 2010/12/7 fhomasp <th...@realdolmen.com>:
>>
>> Hmm..  I don't really understand.  Could you elaborate?
> 
> I guess that you don't want to see those assemblies in your enterprise
> Maven repository, right?
> In this case, in each assembly module, add:
> <build>
> <plugins>
> ...
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-deploy-plugin</artifactId>
> <configuration>
> <skip>true</skip>
> </configuration>
> </plugin>
> ...
> </plugins>
> </build>
> 
> When you will release or, at least, deploy your parent project,
> deployment of modules configured this way won't be deployed.
> 
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295810.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
>
> Hmm..  I don't really understand.  Could you elaborate?

I guess that you don't want to see those assemblies in your enterprise
Maven repository, right?
In this case, in each assembly module, add:
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
...
</plugins>
</build>

When you will release or, at least, deploy your parent project,
deployment of modules configured this way won't be deployed.

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.
Hmm..  I don't really understand.  Could you elaborate?  


Antonio Petrelli wrote:
> 
> 2010/12/7 fhomasp <th...@realdolmen.com>:
>> I think I'm going to exclude the release modules from the module list,
>> and
>> include them in a seperate profile like this:
>>
>> <profiles>
>>        <profile>
>>            <id>release</id>
>>            <modules>
>>                <module>app1</module>
>>                <module>app2</module>
>>                <module>app3</module>
>>                <module>app1-release</module>
>>                <module>app2-release</module>
>>                <module>app3-release</module>
>>            </modules>
>>        </profile>
>>    </profiles>
> 
> If the problem is the upload to the remote repository, simply skip
> deployment in those modules:
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#skip
> 
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295777.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
> I think I'm going to exclude the release modules from the module list, and
> include them in a seperate profile like this:
>
> <profiles>
>        <profile>
>            <id>release</id>
>            <modules>
>                <module>app1</module>
>                <module>app2</module>
>                <module>app3</module>
>                <module>app1-release</module>
>                <module>app2-release</module>
>                <module>app3-release</module>
>            </modules>
>        </profile>
>    </profiles>

If the problem is the upload to the remote repository, simply skip
deployment in those modules:
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#skip

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.

In the local repository?  I guess they'll get over it :-)

I think I'm going to exclude the release modules from the module list, and
include them in a seperate profile like this:

<profiles>
        <profile>
            <id>release</id>
            <modules>
                <module>app1</module>
                <module>app2</module>
                <module>app3</module>
                <module>app1-release</module>
                <module>app2-release</module>
                <module>app3-release</module>            
            </modules>
        </profile>
    </profiles>

Because there already is a parent pom, which is used to build the
applications in development rather frequently.  If I add the release modules
to the standard module list they will always get included in the build
process.  It's better that no one sees any release being mentioned unless
they invoke a build with release profile on.

If any of my reasoning is flawed, by all means, point it out :-)



Antonio Petrelli wrote:
> 
> 2010/12/7 Antonio Petrelli <an...@gmail.com>:
>> 2010/12/7 fhomasp <th...@realdolmen.com>:
>>> Ok, but that would mean that the extra release modules are built
>>> whenever a
>>> mvn package or clean or ... command is invoked on the parent pom.  I'm
>>> quite
>>> sure that they won't like that.
>>
>> If you don't bind the "assembly:single" goal to the package phase, it
>> won't be built in package phase.
> 
> Just forgot that, anyway, when you install the assembly module, it is
> still a POM-packaged Maven project, and it will be installed in the
> local repository, but I don't think it is much a problem, right? :-D
> 
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295747.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 Antonio Petrelli <an...@gmail.com>:
> 2010/12/7 fhomasp <th...@realdolmen.com>:
>> Ok, but that would mean that the extra release modules are built whenever a
>> mvn package or clean or ... command is invoked on the parent pom.  I'm quite
>> sure that they won't like that.
>
> If you don't bind the "assembly:single" goal to the package phase, it
> won't be built in package phase.

Just forgot that, anyway, when you install the assembly module, it is
still a POM-packaged Maven project, and it will be installed in the
local repository, but I don't think it is much a problem, right? :-D

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
> Ok, but that would mean that the extra release modules are built whenever a
> mvn package or clean or ... command is invoked on the parent pom.  I'm quite
> sure that they won't like that.

If you don't bind the "assembly:single" goal to the package phase, it
won't be built in package phase.
I suggest you to bind it in a specific profile, that is invoked when
the release is done (I mean, when you use the Maven Release plugin).

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.

Ok, but that would mean that the extra release modules are built whenever a
mvn package or clean or ... command is invoked on the parent pom.  I'm quite
sure that they won't like that.  


Antonio Petrelli wrote:
> 
> 
> Add new modules to the module list. This approach proved to be the
> best in the long term, especially if you have a very complicated list
> of dependencies to include in the assembly.
> 
> Antonio
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295706.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
> That does make sense.  So I'd create a release module that has a client
> application as dependency, that's what you mean?

Exactly.

>  So one release module for
> one application.  Kind of like an ear packaging a war, in a broad analogy
> then?

Very broad, since EAR has its own package type.

> In the super pom bundling the modules I then add these modules to the
> modulelist?  Or only in a seperate profile meant for the release?

Add new modules to the module list. This approach proved to be the
best in the long term, especially if you have a very complicated list
of dependencies to include in the assembly.

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by fhomasp <th...@realdolmen.com>.

Thanks..

That does make sense.  So I'd create a release module that has a client
application as dependency, that's what you mean?  So one release module for
one application.  Kind of like an ear packaging a war, in a broad analogy
then?

In the super pom bundling the modules I then add these modules to the
modulelist?  Or only in a seperate profile meant for the release?  





Antonio Petrelli wrote:
> 
> 2010/12/7 fhomasp <th...@realdolmen.com>:
>> I don't quite know how to put this, but I'll give it a shot.
>>
>> Basically there are 3 client applications with Swing UI that need to get
>> released.  These have common dependencies bundled in a common dir.  For
>> this
>> part, I don't see much of a problem, I'll get a super pom to get that
>> working, however I'm unsure which plugin I should use.  The global
>> release
>> structure should look like this:
>> \application 1
>> \application 2
>> \application 3
>> \common
>>
>>
>> However each application also has an internal release structure, which is
>> more or less similar for each of them.  The client applications all have
>> packaging jar.  The target release dir structure should go like this:
>>
>> \bin (holds a service wrapper, and a .bat executable)
>> \conf (holds property files)
>> \lib (holds the actual application jar, so the actual mvn package target)
>> \log (the log files)
> 
> Use the maven-assembly-plugin in a separate module for each assembly
> you need to use:
> http://maven.apache.org/plugins/maven-assembly-plugin/
> You can still use the appassembler plugin, but it is useful only to
> build launch scripts, not to create distributions.
> 
> Antonio
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://maven.40175.n5.nabble.com/Create-complicated-client-jar-release-target-s-tp3295582p3295674.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Create complicated client jar release target(s)

Posted by Antonio Petrelli <an...@gmail.com>.
2010/12/7 fhomasp <th...@realdolmen.com>:
> I don't quite know how to put this, but I'll give it a shot.
>
> Basically there are 3 client applications with Swing UI that need to get
> released.  These have common dependencies bundled in a common dir.  For this
> part, I don't see much of a problem, I'll get a super pom to get that
> working, however I'm unsure which plugin I should use.  The global release
> structure should look like this:
> \application 1
> \application 2
> \application 3
> \common
>
>
> However each application also has an internal release structure, which is
> more or less similar for each of them.  The client applications all have
> packaging jar.  The target release dir structure should go like this:
>
> \bin (holds a service wrapper, and a .bat executable)
> \conf (holds property files)
> \lib (holds the actual application jar, so the actual mvn package target)
> \log (the log files)

Use the maven-assembly-plugin in a separate module for each assembly
you need to use:
http://maven.apache.org/plugins/maven-assembly-plugin/
You can still use the appassembler plugin, but it is useful only to
build launch scripts, not to create distributions.

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org